OOスレ9 なぜオブジェクト指向は普及しないのか

過去ログ
part 1 http://pc11.2ch.net/test/read.cgi/prog/1183255047/
part 2 http://pc11.2ch.net/test/read.cgi/prog/1184258633/
part 3 http://pc11.2ch.net/test/read.cgi/prog/1185378099/
part 4 http://pc11.2ch.net/test/read.cgi/prog/1188396264/
part 5 http://pc11.2ch.net/test/read.cgi/prog/1189946678/
part 6 http://pc11.2ch.net/test/read.cgi/prog/1190731526/
part 7 http://pc11.2ch.net/test/read.cgi/prog/1192703383/
part 8 http://pc11.2ch.net/test/read.cgi/prog/1201610928/

おじゃばは簡潔に書け　自演とオレオレルールも禁止
その他はスルー技術を身につけれ
おじゃばの低能はデフォ　熱くなった方が負け

ガンダムOOが面白いって評判なんだけど。

自演はデフォ

ひたいはデコ

OOは結局誰が生き残ったのさ

オブジェクト指向プログラミングは普及してると思うが

分析と設計は普及していない

てかOO以降の流れって、実装能力のある人がデザインする前提じゃね？
日本はプログラムを書けないSEが中間層に挟まりすぎ。
そんでOODのアウトプットって、顧客に「なんとなく分かったよーな錯覚を持たせる」
力があるから、結局日本だと、
「無能SEが下流に責任を押し付けるための都合のよい道具」として
悪用されているだけって気がするよ。

おまえ等、前スレが消化しきれてないことを忘れちゃいないか？

もうおなかいっぱい

>>6
あんまり普及してないんじゃね?

なんか前スレ読めないのだが。

馬鹿には読めない

>>8
わたしは思うんですが、こうした細部が外部の部外者からは「意味が
読めない」仕組みである、プログラミングという知的システムの持つ
宿命的な性質に由来していて、それはN88BASICの時代から実は
それほど変化してはいないと思うのです。

簿記の内容とかは常識で考えればそれほど敷居は高くはない。
建築構造設計ならそれなりのソフトに書ければ安全かどうかぐらいは
すぐにわかる。

しかし、込み入った内部構造が実装されているプログラミングという
高度な知的資産んついては、外部の部外者の人間にはそう簡単には
解読し理解できない。そこにこの世界の生産性の限界、保守性の限界
が宿命的に運命付けられていて、構築する側の労働の性質として特徴
的な困難が横たわっていると思う。

それを解決する手段がいままでいろいろ提案されてきたと言う中でこの
OOもあるだけで、しかし、この根本的な困難を決定的に解決するには
至っておらず、業界の労働の性質はほとんど永遠に変わることはない
のではないか。OOの次がまだ見えていない現状から見るとそう思えて
ならない。

>>14
別に大量生産すればいいって物でもないのだから、生産性を上げたりしなくてもいいんじゃね？

前スレが見えなくなってしまったので、もう一度DVDレンタルの設計過程を書こう。
アクター一人でやる方法は思いつかないので、出来る奴に任せる。

俺はカウンターや入荷棚をシステムの一部として、客や業者をアクターにする事にする。
「システムに触る=コンピュータの操作をする」と言う解釈ではなく、カウンターにDVDを置くのも
システムに触ると言う解釈をすれば問題ないと思っている。
となると、アクターは、
「店員」「店長」「会員」「業者」になる。店長はこの前やってみて必要だと思ったので追加した。
システムは大きい括りでは「レンタルシステム」だが、先ほどアクターを追加したため、
中に「カウンター」「返却箱」「仕入れ棚」「廃棄棚」を含むとしよう。
上記オブジェクト分けしたとすると、レンタルシステムを構成する残りの要素も分類しよう。
あとは、「商品棚」「DVD」「料金表」こんな所だろうか。
手順としてシステムを要素に分割していいのか分からないが、とりあえずこれでやってみようかと思う。
システムは、「レンタルシステム」で、
構成要素は「カウンター」「返却箱」「仕入れ棚」「廃棄棚」「商品棚」「DVD」「料金表」とする。

さて次はユースケースだ。まず会員。
会員--（入会申請を行う）-->カウンター
会員--（退会申請を行う）-->カウンター
会員--（DVDを選ぶ）-->商品棚
会員--（DVDを持って行く）-->カウンター
会員<--（DVDを受け取る）--カウンター
会員--（DVDを返す）-->返却棚
会員--（延滞料金を払う）-->カウンター
会員<--（延滞警告される）--カウンター
次に店員。
店員<--（入会のチェック）--カウンター
店員<--（退会のチェック）--カウンター
店員<--（貸し出し条件のチェック）--カウンター
店員<--（返却条件のチェック）--返却棚
店員<--（延滞チェック）--カウンター
店員<--（仕入れチェック）--仕入れ棚
店員<--（廃棄チェック）--商品棚
こう見るとチェックばかりだが、バイトにも触らせる事を考えると、システム的には良い物かもしれない。

次は店長。
店長と業者間には何か噛ませようと思うが、新しく何かを作るのは面倒なので、仕入れ棚で代用する。
廃棄はどうしようか。一つ一つチェックするのは難しいと思うので、廃棄条件を入れて置くと、
自動的に廃棄することにしよう。とりあえず、商品棚に対して廃棄条件の設定で考えて見る。
あとは料金変更かな。
店長<--（新作DVD一覧の参照）--仕入れ棚
店長--（DVD発注）-->仕入れ棚
店長--（廃棄条件の設定）-->商品棚
店長--（料金の設定）-->料金表
最後に業者だ。
業者--（新作DVD一覧の設定）--仕入れ棚
業者<--（注文DVD一覧の参照）--仕入れ棚
業者--（納入）-->仕入れ棚
業者<--（廃棄）--廃棄棚

あまりに全スレ最後が的確で大笑いだ。
>988 名前: 仕様書無しさん Mail: sage 投稿日: 2008/03/29(土) 17:01:20
>おじゃばは「客が店に入る」とか「客がお金を払う」とかも
>ユースケースに書きそうだな
>989 名前: 仕様書無しさん Mail: sage 投稿日: 2008/03/29(土) 17:48:23
>>>988
>客が1万円札を出す、とか客が棚のDVDの配置を変える、とかまで入るかも
>990 名前: 仕様書無しさん Mail: sage 投稿日: 2008/03/29(土) 18:11:42
>客がDVDのケースと中身を入れ替える　とか　万引きする　とか
>991 名前: 仕様書無しさん Mail: sage 投稿日: 2008/03/29(土) 18:27:42
>起業から倒産までフォローして欲しい
>992 名前: 仕様書無しさん Mail: sage 投稿日: 2008/03/30(日) 00:09:26
>客を装った強盗が刃物を持ってカウンタへ押し入る、とか
>993 名前: 仕様書無しさん Mail: sage 投稿日: 2008/03/30(日) 00:15:46
>客がエロビデオをカウンターに持っていったら店員がかわいい女の子で気まずい思いをする、とか

>>18
こんな感じ？


ユースケース　〜レンタルシステムの戦い〜
　∧＿∧　　　　　　 　　　　　　∧＿∧
　(　･ω･)＝つ≡つ ⊂≡⊂＝(･ω･　)
　(っ　≡つ＝つ　　　　⊂＝⊂≡　⊂)
　./　　　) ﾊﾞﾊﾞﾊﾞﾊﾞ 　ﾊﾞﾊﾞﾊﾞﾊﾞ (　　　＼
　( /￣∪　　　　　　 　　　　　　 ∪￣＼)


[会員の行動選択]
会員--（入会申請を行う）-->カウンター

　∧＿∧　　　　身構えて反撃してやんよ
　(　･ω･)
　(っ　　つ
　/　　　)
　( /￣∪

[店員の行動選択]
会員<--（延滞警告される）--カウンター

　　　　　　　　　⊂≡⊂＝
　　　　　　　　⊂≡⊂＝
　　　　 ∧＿∧ ⊂≡⊂＝
　；;;；;、(･ω(:;(⊂＝⊂≡
　　　　(っΣ⊂≡⊂＝
　　　　/　　　⊂≡⊂＝
　　　　( /￣∪ ⊂≡⊂＝
　　　　　　　　　⊂≡⊂＝
　　　　　　　　⊂≡⊂＝
　　　　　　ﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞ

[店長の行動選択]
店員<--（丹念にじっとりとチェック）--店長
　∧＿∧　　まとめてアッーしてやんよ
　(　･ω･)
　(っ　　っ　　｡　　ﾋﾟｭﾋﾟｭﾋﾟｭﾋﾟｭﾋﾟｭ
　/　　二つ ゜｡ﾟ　° 。
　( /￣∪　　　｡゜　｡　｡

OO分析、設計は、「じっくり分析設計して」、「初期の開発は冗長に時間がかかったとしても」「将来の変更を楽にする」、というのが基本だからな。



こんなの流行るわけがない。
競争原理で動いている社会なのに、そんなゆっくりやる余裕がある会社なんてほんの一握り。

おじゃばじゃないけど、そこまでおじゃばのユースケース図（？）は間違ってない
ただ、一番大事なところが不足している
システムの境界線が無い
客がどうこうってのはユースケース図に書いてもいいがシステムの境界外
もし「先に言ってるからいいだろ」的なことを言い出したら、それこそユースケース図の目的を分かってない

>>15
というか、システム構築の生産性とは、低コストにして開発サイクルの
短期化が可能かどうか、そしてメンテナンス性の向上がどれだけ画期的
に見込めるかという視点でして。

これについては、あと10年経っても状況に変化はあるような気がしない
のです。ということで。

くだらないレスですまないが
開発における生産性が向上し続ければ。ある段階で保守の必要性はなくなる。
「保守するより作ったほうが早くて安い」という分岐点に到達するということだ。
これを過去に試算した人間がいる。十年ほど前だが。
この分岐点に到達するには「生産性が100倍向上すれば良い」とのこと。
・・・すまない。全然現実性のない話だ。

>>23
その基本ってだれがいいだしたんだろうな。どっかのコンサル屋かね。
ときどき聞くけど。
そんなんでできるわけないのに。
基本といってもその背後には色々と前提とか裏があるから、そのまま実行に移してもムリポ。

>>27
ぇぇぇぇ・・・・・・・・

Jランボーさんのオブジェクト指向方法論OMT読んだ？
はっきり書いてあるよ。

前スレは読めなくなってしまったので、俺の最後の書き込み以降は読んでない。
誰かがアクター店員だけのクラス図書いたのか？それとも19に書かれている事程度の話か？
19に書いてある事なら、「アクターに店員と業者を入れるために無理してシステム化した」と何度も
言っているので理解して欲しい。気に入らないならアクター一人で設計してみてくれ。

>>20
20の最初の表は的確だ。確かにこのままだと打ち合いになる。これでいいのかは謎だ。
ほとんどの要求はアクターからのリクエストに変更出来ると思うが、会員登録とレンタルと返却は
無理な気がする。システム側からアクターに対して通知がある場合はどうすればいいのだろうか。
あくまでもアクターが主体としてイベントがないか確認すると言う形式にしなければならないのだろうか？

>>24
システムの境界線としては、
「カウンター」「返却箱」「仕入れ棚」「廃棄棚」「商品棚」「DVD」「料金表」
がシステム側で、それを統括して「レンタルシステム」としてみた。
これらと、「店員」「店長」「業者」「会員」の間がシステムの境界線となる。

>>28
読んでない。検索してみたが絶版らしいし図書館にも無い。
はっきりなんて書いてあるの？

>>23に書いてあることのうち、「じっくり分析設計」は良いとして
後の2つは今日的にはむしろ否定的な考えが主流じゃないの？

そういうポリシーを何て呼ぶのかは忘れたけど、
「仕様の変更や拡張への備えは必要最小限で」やった方が結局は無駄がないんだよね。

もちろん「必要最小限」の部分は程度問題なんだけど

>>28
絶版だったのか。OO分析設計の原点というか、聖典だったはずだが。


１．４　オブジェクト指向開発の有効性の根拠
（略）
オブジェクト指向開発による主な利益は開発時間の短縮ではない。
オブジェクト指向開発は従来の開発方法と比べてより時間のかかるものである。
（略）

>>32
それだけ読むとえらい予防線はってる、と思うわけだがw

>>25,26
その生産性の向上と言うのは、いくつかの方法で進んでいる。
OOもその一つと言えなくもないが、もっと劇的なのはミドルウェアの充実と、簡易言語の登場だろう。
ミドルウェアの充実と言うのは、DBのような物も含む。もしDBと同じ事をファイル操作関数で
やっていたら、大変な手間になっているだろう。またPHPなどの用途を特化した言語の登場も見逃せない。
PHPで簡単に作れる物でも、Cでゼロから作ったら大変な手間だろう。
だからその点では確実に進んでいる。
しかし逆に足を引っ張っている所がある。それは人員管理だ。
能力主義が普及してからかなりの時間が経ち、今の中堅PGは先輩から何も教えてもらわなかった世代だ。
彼らは人により能力に大きな開きがある。しかも我流の人が多く、教える事に慣れていない人も多い。
25の言う生産性を向上させる方法で、最も有効なのは、作った人間に保守させる事である。
しかし通常、ベテランを保守に占有させることは、営業的な面から困難だ。
そのため、普通はベテランに新人を付けて、開発時から一緒にやらせて、保守フェーズになったら
新人に引き継ぐという方法をとる。しかし今やこの方法は崩れてしまった。
まず新人を入れる予算がない。あっても、ベテランが新人を教育しない。ベテランのスキルもまばらだ。
それ以前に、製造を海外に丸投げする例も多い。結果、優秀な人間なら数人で作れる物を、
数倍の人間をかけて作成し、誰が作ったかも分からない物を、システムの目的も知らない人が保守する。
これが生産性を落としている原因となっている。

・開発側：将来の保守性のためにしっかり分析設計してきっちり作りたい。やっぱりOO。
・営業側：いいから安く早く作れよ。客の気分に合わせて当初の想定外の機能も作れよな。1日で。予算3万円で。死んでもやれ。



OOの普及以前の問題。

>34
で？

開発の生産性が上がらない理由に、
なぜ開発後の保守が関係するのかさっぱりわからん

>>23
適材適所だろう。
常に変更が見込まれる分野においては、劇的な効果がある事もある。
DVDレンタルシステムにしても、もし店舗での貸出しかなければ、構造化で最小限作った方が早い。
しかし、正しく設計してあれば、アクターやシステム要素の変更も容易なはずだ。
つまりネットでの貸し出しや、CDや本の貸出への変更も容易なはずだ。
ただ、DVDレンタルではやはり効果は薄いと思う。ネット対応は作り直した方が早いかもしれない。

最も効果があるのは、ネットゲームだろう。今のネットゲームは新しい要素を入れて行かないと、
すぐにユーザに飽きられてしまう。新しいマップ、アイテム、魔法、モンスター、シナリオなどを増やす
必要があるし、場合によっては基本システムすらを拡張する必要さえある。
新しい要素を入れるたびに作り直していたのでは間に合わない。
逆に言うとこのような特殊な分野で効果を発揮する物であって、全てに対して効果がある物ではないだろう。

>>38
それからどした

なんもかんもダンプ出力するのをやめろ

>>40
しーっ、この子はこれで何かした気になってるんだからそっとしておこうよ。

ネトゲしたことないのか

>>35
粗製乱造する仕事ばかりさせられてると、プログラマーもいやになっちまうよな。
長年修行した大工なのにほったて小屋ばかり作らされるというか。
プログラミングは本来、芸術的なものだと思うんだが、仕事ならそんなことはいってられない。

漏れは仕事で書くのやめて趣味で書くようになったんだが、今すげーおもしろいよ。
無数のクラスがまるで生き物のように分裂・変化をくりかえしながら成長していく過程や
自分の知識が一つのアプリに結晶化していくのをみると幸せ。

趣味で書くなら、もうクラスベースな言語自体使わないなぁ
クラスベースだと所詮は静的な設計が先にありきになるから、変化に弱いでしょ
弱いってか、ちょっとした変化を起こすための実装コストがやたらと高い

>>44
規模によると思う。小さいアプリだとクラスベースにしても割高。
アプリの成長過程で分岐点があって、クラスベースでないとつらくなってくる地点があると思う。
この地点を知ると、クラスの粒度をどのあたりに設定するか、それまでとは切り口が変わってくる。
この分岐点に直面したことがあるかないかが、ＰＧたちの主義を二分するんじゃないかな。

テレビカメラだの音声ユニットだのそういうパーツを作るのがミクロ的だとすると、
それを組み合わせてロボットをこさえるのはマクロ的という意味合いなんだけど、
設計の変化にはマクロ的な視点での変化とミクロ的な変化があって、
オブジェクト指向はマクロ的なところでの変化には強いと思うけど。

最終的にはオブジェクト指向も用途によるということなんだが。

規模というより人数ではないか？
OOの柔軟性を利用して、素人が作ったひどい部分を後から作り直すのだろう？

>>44
クラスベースは変化に強い。作り方を間違っているのだろう。
ちなみにクラスを使って構造化で作ると、とんでもなく変化に弱い物になる。

さて、DVDレンタルシステムのユースケース図を作成したが、これをどうやってクラス図にするのだろうか？
普通の考えれば、システムとその要素をクラスにして、ユースケースをメソッドにする。
しかしシステムから通知される部分はどうなるのだろうか？またアクターはどう表現するのだろうか？
アクターをクラスにしないとすると、ただの構造化でマスターメンテを作るのと違いが分からない。
まあ、よく分からないので、全部クラスにしてみる。
アクターもクラス、システムの要素もクラスにしよう。そうなるとアクターとシステムの殴り合いになるが、
その間のやり取りをレンタルシステムと言うクラスで、カバーしてみようかと思う。
かなり無茶だが面白そうだ。明らかに構造化とは違うし、成功すれば柔軟性も出る気がする。

class カウンター{
　set入会申請();
　set退会申請();
　setDVDを借りる();
　set延滞料金を払う();
　get延滞警告される();
　get入会のチェック();
　get退会のチェック();
　get貸し出し条件のチェック()
　get延滞チェック();
};
class 商品棚{
　getDVDを選ばせる();
　get廃棄チェック();
　set廃棄条件の設定();
};
class 返却棚{
　setDVDを返す();
　get返却条件のチェック();
};

class 仕入れ棚{
　get仕入れチェック();
　get新作DVD一覧の参照();
　setDVD発注();
　set新作DVD一覧の設定();
　get注文DVD一覧の参照();
　set納入();
};
class 廃棄棚{
　get廃棄();
};
class 料金表{
　set料金の設定();
};

>48
なにいってるんだ?
ってか、相手しちゃだめな人?

レスはすべてsageないし、他人の意見には耳を貸さない
まともに相手にされなくともレスし続ける自分をかっこいいとすら思ってる
いつも同じことしかできない壊れたジュークを相手にしちゃいけない

>52
ｔｈｘ
登録しとくｗ

>>48-50
基礎からやり直せ

>>49-50
俺の部下がこんな設計出してきたらどうしよう・・・

今までのはただの馬鹿な設計者レベルだったが
>>49-50は犯罪レベルだな

>>49-50
ｸｿﾜﾛﾀｗｗｗ

バカおじゃば、おまいは素直で応用のきかない園児か
だから俺理論を展開するんじゃなくてせめて本読んで基礎を押さえてからにしろとあれほd(ry

>>49-50に足りないであろうクラスを補完して
クラス図をおこそうとしたら、テラカオスな状態にｗｗｗ

　get廃棄();
が秀逸すぎる。
呼ぶのはバイトか？ホームレスか？

相互参照と循環参照が発生しまくりそうなんだけど

>>60
ﾌｲﾀｗｗｗｗｗｗｗｗ

class おじゃばさま {
　getクラス設計();
　get煽られる();
　getクラス再設計();
};

class 名無し {
　get煽る();
};


出来た！

かなりひどいが分析も設計もできない子だから仕方ないんだろ
おじゃば、ヒントやるよ
商品棚クラス、返却棚クラスは不要だ
業態を考えればわかるはず
メソッドも変だな　DVDを選ばせる、じゃなくて、客が何かを選ぶ　が正解

よく考えてみろ
ステータスが変わるものはなんだ？
客の状態が変わるのか？違うだろ
根本のクラスは、商品（CD、DVD、VHS）だろ
それらが、店にあるかないか、誰が借りてるか、いくらか、いつ購入したか、廃棄したか、
だろ
ちょっといかんぞ

ヒントじゃなくて答え

カススレだな
タイトルだけでお気に入りにいれたが、削除しよう……

なんで自己アピールしてるの？
おじゃばがレスしたらどうすんだよ

予想外のレスが付いているので一応書くけど

>趣味で書くなら、もうクラスベースな言語自体使わないなぁ

の後ろは当然
「プロトタイプベースな言語を使うよ」

が省略されています。
（クラスベース⇔プロトタイプベースってのは常識だと思うけど・・・）

オブジェクト指向vs構造化みたいな話は誰もしてないです。

おじゃばじゃないんだから常識とか言うなよ

googleで「クラスベース」で検索した結果からも、
これはまぁ常識と言っていいんじゃ？

見習いの俺がプロトタイプベースについて勉強してきた。

で…
クラスベースとプロトタイプベースを併せたら最強？

二兎追うものは一兎も得んぞ。利便性と性能はいつでもトレードオフ。
お手軽にやりたい時はプロトタイプベースかもなぁ。作ってて面白いし。

お手軽な言語ではお手軽なもんしかつくれんよ
そこもトレードオフな

>>72
プロトタイプベースな言語は具体的になにを使ってるの？

>>71
rubyか？

とりあえず「-->」をset、「<--」をgetにしてみた。

>>58
ユースケース図をクラス図に変換する方法が書かれた物は見たことがない。

>>59、61
確かにカオスだ。本当にユースケースからクラス図が作れるのか疑問に思っている。
もしかしたらユースケース図は、要求仕様を抽出ためだけの物のような気がしてきた。

>>64
ユースケースを見ると「getDVDを選ばせる();」は間違いなので、「setDVDを選ぶ();」にする。
ただ、「基本クラスはDVD〜」については、言いたい事は分かるが、ユースケース図をクラス図にすると
言う企画なので、DVDを出すならユースケースから書いてくれ。

カウンターが気になる。入会処理とレンタル処理は種類が違う気がする。分けよう。
class 入会カウンター{
　set入会申請();　set退会申請();
};
class レンタルカウンター{
　setDVDを借りる();　set延滞料金を払う();
　get延滞警告される();　get入会のチェック();　get退会のチェック();
　get貸し出し条件のチェック();　get延滞チェック();
};
class 商品棚{
　setDVDを選らぶ();
　get廃棄チェック();　set廃棄条件の設定();
};
class 返却棚{
　setDVDを返す();
　get返却条件のチェック();
};
class 仕入れ棚{
　get仕入れチェック();　get新作DVD一覧の参照();　get注文DVD一覧の参照();
　setDVD発注();　set新作DVD一覧の設定();　set納入();
};
class 廃棄棚{
　get廃棄();
};
class 料金表{
　set料金の設定();
};

アクターをクラスにしたとして、メソッドはどうするか。
システム要素クラスのメソッドのうち、setをアクター側に持って行ってみようか。

そもそも、ユースケースは「システム化の範囲」を示すもの
ユースケースからクラス図が作れるというのが間違いのもと

それ以前のもんだいとしてgetter/setterしかないクラスってすごい違和感がある
例えば会員IDとかDVDのIDは最低必要じゃないのか？
そして、そのIDは誰が管理するのかを決める必要はないのか？

これではOOPLを使ってスパゲティコードを作っているだけだ

OOP => オブジェクト オリエンテッド パスタ

おじゃばの擬似コード？、getだのsetだのつけてるからjavaっぽく見えるだけだよ。
getsetとっぱらって、各メソッド？名の後ろに処理()ってつけてみなよ。
OOどころか見事に手続き型設計だから。それでも穴ありまくりだけどさ。
module 仕入れ棚{
　仕入れチェック処理();　新作DVD一覧の参照処理();　注文DVD一覧の参照処理();
　DVD発注処理();　新作DVD一覧の設定処理();　納入処理();
};
module 廃棄棚{
　廃棄処理();
};
module 料金表{
　料金の設定処理();
};

なぜ処理だけ先に書きたがるかといえば、本人が言うとおり
「コーディングから入る」程度の仕事しかしてないからだろうねぇ。
分析なんて背伸びしないで設計の基礎から勉強したらどうかなぁ？

>>75
orz 俺、殆どクラスベースの使い方しかしてないYO。
perlから乗り換えたらマジ使いやすくて尿漏れた。

>>77
　・メンバ変数の定義
　・パブリックメソッドは、メンバ変数の値をどう変更すべきかの定義

を教えてくれ。
データ構造、メンバ変数はパブリックメソッドによりどう変わって行くかがわからんと
『おじゃば様の頭の中では』プログラムはどう動いているのかが
全然理解できん。

>>77
クラス図もどきを描くほうがいい気はする。
上から順にクラス名、変数、メソッド。

例)
　 　---------------------------
　 　ユーザー
　 　---------------------------
　 　- ユーザー名
　 　- 現在借りてるDVD(可変長配列)
　 　- 一時登録されたDVD(可変長配列)
　 　---------------------------
　 　+ 返却(DVD名) : OK / NG
　　 + 延滞金額算出() : 延滞してるDVD全ての、延滞金額
　 　+ 延滞金支払い(金額) : OK / NG
　 　+ 一時登録(DVD名) : 一時登録OK or　延滞ありで貸し出せない or 貸出本数MAXまで到達
　 　+ 新規貸出金額算出() : 一時登録されたDVDの、合計金額
　 　+ 本登録(金額) : OK/NG
　 　+ 一時登録クリア
　 　+ ユーザー名取得 : ユーザー名
　 　- 貸出本数チェック() : (一時登録されたDVDの本数 + 現在借りてるDVDの本数)
　 　---------------------------

　+ 返却(DVD名) = 「- 現在借りてるDVD」から、指定されたDVDを削除。空文字はエラー。
　 　 　 　 　 　 　 　 　なけりゃ、ポップアップでエラーメッセージ出す。
　+ 延滞金額算出 = 「- 現在借りてるDVD」から延滞しているものを見つけ、延滞金額を合算。
　 　 　 　 　 　 　 　 　なけりゃ0円を返す。
　+ 延滞金支払い(金額) = 金額と「+ 延滞金額算出」の額を比較。金額のほうがデカければ
　 　 　 　 　 　 　 　 　「現在借りているDVD」の延滞金額を全てゼロにする。金額に0円以下の入力はエラー。
　+ 一時登録(DVD名) = 「- 一時登録されたDVD」にDVDを登録。空文字はエラー。
　 　 　 　 　 　 　 　 　内部的に「-貸し出し本数チェック()」で、貸出本数をチェック。
　 　 　 　 　 　 　 　 　貸出本数チェックでエラーが出たら「もう貸し出せんわ」とエラーをポップアップ。
　+ 新規貸出金額算出　= 「- 一時登録されたDVD」のリストから、貸出金額を算出する
　+ 本登録(金額) = 金額と「+ 新規貸出金額算出」の額を比較。金額の方がデカければ、
　 　 　 　 　 　 　 　 　「一時登録されたDVD」にあるDVDすべてを「現在借りているDVD」に移動する。
　 　 　 　 　 　 　 　 　金額に0円以上の入力はエラー。
　+ 一時登録クリア = 「- 一時登録されたDVD」の配列をクリア。要素を0コにする。
　+ ユーザー名取得 = ユーザー名を返す。たぶんレジのモニタに名前出すときに使う。

orz DVDの定義してないから意味不明だ。

一回目の書き出しだから、バグってても文句言わんでくれ。
二、三度書き直さないと上手く行かんのが常。

ほらほらｗ
いい加減DOAに戻ろうよｗ
みんなでテーブル考えようよｗ

>>79
やっぱりユースケースとクラス図は関係無いのか？
俺もそう思うのだが、さんざん名無し連中はユースケース図書けって言っているぞ。
ユースケース図からクラス図は作れないでOK？作れる人はいるのか？
get/setは矢印の方向に合わせて付けてみた。

>>81
だからアクターなくして、システム側だけにメソッド付けたら、構造化のマスターメンテと変わらない
のではないかと、前から言っているだろう？次にどうすればいいか教えてくれ。

>>83
アクター側に全メソッドを付けるって事か？
で、このクラス図はどうやって作った？アクターを主体にして、アクターの行動をメソッドにした
のかと思ったが違うようだし。

>>83
アクター側に全メソッドを付けるって事か？
で、このクラス図はどうやって作った？アクターを主体にして、アクターの行動をメソッドにした
のかと思ったが違うようだし。

なんか、妙なクラス設計になってない？
いいのかなぁ……

せっかく途中までやったので、アクターも登場させよう。setは全部アクターに持って行く。

class 会員{　set入会申請();　set退会申請();　setDVDを借りる();　set延滞料金を払う();
　setDVDを選らぶ();　setDVDを返す();};
class 店長{　setDVD発注();　set廃棄条件の設定();　set料金の設定();};
class 業者{　set新作DVD一覧の設定();　set納入();　get廃棄();};
class 入会カウンター{};
class レンタルカウンター{
　get延滞警告される();　get入会のチェック();　get退会のチェック();
　get貸し出し条件のチェック();　get延滞チェック();};
class 商品棚{　get廃棄チェック();};
class 返却棚{　get返却条件のチェック();};
class 仕入れ棚{　get仕入れチェック();　get新作DVD一覧の参照();　get注文DVD一覧の参照();};
class 廃棄棚{};
class 料金表{};

>>87
ユースケース図描けたぁだーれもいってねーよ、バカ。
だからその、やることがはっきりしてねーのにコーディングしたがんなってるだけ。
何をやるかまず決めろってるだろがよ。

>>91
クラス変数とかインスタンス変数は？

>>87
じゃ、それでいいじゃん、マスタメンテに合ってる仕事なんだろ。
無理にOOにして何がいいのよ。

>>87
ユースケース駆動型開発の1つの例。
まずは誰かがやってることを真似て来いよ。

ttp://csx.jp/~marunomaruno/ood01.html?c=indexum00

おじゃばはレンタルビデオの話を続けたいなら
在庫管理、レンタル屋、他のもいいと思うんで、
デタラメでも、ここにある図、表、仕様書を
一通り書いてきてから、話を進めてくれ。


まぁ各人RUPとか名詞抽出法の良し悪しとか思うところあるだろうけど、
おじゃばに言っても始まらないだろ

>>95
おじゃばはリンク先は読まないぞ、ユースケースからクラスを抽出する方法だけ要約すると

まず、ユースケースは「ユースケース記述」＋「ユースケース図」＝「ユースケース」で
この「ユースケース記述」の名詞に着目してエンティティを抽出してクラス図を作成する
レンタル屋だと「会員」「商品」「レンタル」
俺もこれは良し悪しあると思うが、これが一般的で標準だ

>>79
>ユースケースからクラス図が作れるというのが間違いのも
>>87
>>>79
>やっぱりユースケースとクラス図は関係無いのか？
>俺もそう思うのだが、さんざん名無し連中はユースケース図書けって言っているぞ。
普段は人の意見を聞かないのに、なんでこんな素人のアホを信じるんだ　自演か？
とにかく、ユースケース記述を書け

ユースケースからいきなりクラスへの変換は無謀だろうよ。いきなりアクターをクラスにとか無茶すぎる。
とりあえずDVD貸出しについて殴り書きしてみたけど、分析手順としては下のような感じじゃねぇの？

（1）概要分析（by ユーザへのヒアリング）
[ユースケース]
・DVDを貸し出す

[シナリオ検討]
・客は店員に借りるDVDを伝え会員カードを渡す。
・店員は会員カードの有効性を確認する。
・客は泊数に応じた料金を支払う。
・店員は客にDVDを渡し会員カードを返却する。

-事前条件
・DVDの在庫があること。

-事後条件
・DVDを貸し出す。
・DVDの在庫を-1する。

（2）詳細分析（by さらにヒアリング）
・会員カードの有効性はどのように確認するのか？
・在庫の有無はどのように確認しているのか？
・泊数に応じた料金はどのように設定すのか？
:

【クラス候補（名詞）の洗い出し】
DVD、客、店員、会員カード、有効性、泊数、料金、在庫

------続き

（3）整理（わかるところから妥当性を考慮しながらクラスに分類）
●【DVD】
・DVD管理No.
・タイトル
---
・貸し出す()
・返却する()
:

●【客】
・会員番号
・名前
---
・入会する()
・退会する()

●【会員カード】（※客に従属）
・会員番号
・有効期限

●【料金】（※DVDに従属）
・泊数


。。。てな具合に（1）〜（3）を繰り返しながらクラスの抽出、関連、役割分担などを詰めていく感じだとおもうが。
合わせて、MVCに則して、モデル、それと上の分析で出現していないコントローラの役割をになうクラスを検討するなど。

なぜ、DVD自身に
・貸し出す()
・返却する()
が？
なぜ、客自身に
・入会する()
・退会する()
が？

DVD, 会員には管理簿があって、
DVD管理簿に 貸出(), 返却()
会員管理簿に 入会(), 退会()

貸し出し/返却管理GUI(笑) が レンタル を生成
DVD, 会員 をレンタルで紐付け

>>99
オブジェクト指向だから

設計が変だからでしょ。
「取引」みたいなデータ型を持ち込んだ方が直感的だと思うよ

設計からダメダメさが如実に伝わってくる
これはデスマの予感

総員第一種撤退準備！

デスマにはならんだろ
下から設計修正できる内容だから

でもおじゃばが相手だと修正厳しいか？

OOA/D/Pを使うことを前提にした開発プロセスってユースケース駆動以外に何があんのかな？

>>99-100
殴り書きって書いてあるし、とりあえず手順としてだから、
分析結果が怪しいのはしょうが無いんじゃない？

そもそもユースケースにシステムの境界が無くて
シナリオにシステムが出てこない訳で、出発点から怪しい。


おじゃばは(俺には)アクターに客、店員をクラス化したい(システム内部に含めたい)らしい。
「客、店員」と「それらが利用するサブシステム」の両方を含むシステムを作りたいようなので
さらにその大きなシステムを利用するアクターが必要。

システム分析では、アクターは「利用者」なので、アクターはクラスになりえない。

>>97-98
駄目だな、OOが分かってない
おじゃばよりレベル低いぞ

とりあえず納期をまず決めてだな

>>98
料金ってｗ

>>92
なにそれ、現実逃避？コミュニケーション拒否？前スレ読んでないとか？

>>94
一般業務を無理にOOにしたらどうなるかって言う企画だ。

>>95
読んでみた。つーか95、読んでないだろう？
クラス図の作成方法が書いてないつーか、クラス図リンク切れしている上に、中途半端のまま終わってる。
内容も項目抽出はDOAだし、途中からO/Rマッピングもどきの話になっているし、無駄なUMLを大量に作っている
割りには、クラス図1つすら出来てない。これUMLだけ勉強して挫折した人のHPだ。
人に勧めるならせめて1回は読んでくれよ。

>>96
レンタルは違うが、会員、商品はDOAだ。95のHPでの項目抽出も完全にDOAだ。DB設計してるし。
一般的って言うのはDOAで一般的と言う話だろう？あと、普段から出来るだけ人の意見を聞いてるぞ。

VB2005で
期限付きプログラムってどうやれば作れるんですか？

>>109
>一般業務を無理にOOにしたらどうなるかって言う企画だ。
そーだったのかｗ誰が始めたコトやら。
おじゃばが手続き型でしか設計できない、つかコーディングしかしないし、
いままでまともなOOA?OODだかの同意とれるようなもんも出てないから
一般業務(なにが一般なんだかおじゃばは相変わらず自分の世界だけど)では
OOは役立たずっつことでおｋ？それとも分析や設計には要らないけど、
コーディングにはあとのメンテが楽、ちゅう客には理解できない理由で役に立つから、
使わなきゃ、先端だし周りは知らないし俺教えてあげてかっこいいしくらいなもん？

>>97
>【クラス候補（名詞）の洗い出し】
>DVD、客、店員、会員カード、有効性、泊数、料金、在庫
DOAでない事は認めよう。抽出ポリシーは読み取れないが。
DVDのフィールドはいいとして、貸し出しすると返却するがメソッドになるのか？
DVDクラスではなく、DVD管理簿クラス？
あと、会員カードをクラスにするのか？客に従属って何？フィールド変数か継承か？
あとMVCってOOとはむしろ逆の考え方だが、それに則するってどういうことだ？ビュークラスを分離するのか？

つーか名詞で抽出ではなくて、〜する人（物）で抽出と言う意味ではないのかな？
〜erで抽出ならオブジェクト指向的だが。翻訳間違えているのではないか？

>>105
別に店員だけでもいい。ユースケースとクラス図が出来れば。
つーかクラス図だけでもいいから、そのクラス図を作る手順を説明しないと、他の人が設計出来ないだろう。
その手順でやれば誰がやっても同じようなクラス図が出来ると言うのが、「確立されている」と言う意味
なのだから。

>>111
俺は前から、通常の業務は構造化設計で設計して、オブジェクト指向プログラミングでプログラムすれば、
何の問題もなく出来ると言っている。
オブジェクト指向設計が役に立つのは、シミュレーションやゲームの分野ぐらいだろうと言った。
オブジェクト指向として設計する手順としては、システムを実際の物体として捉えて、その後に
その構成要素を抽象化して設計する方法を在庫管理で示した。それが良いのか悪いのかは分からないが。

そうしたら、OOは一般業務でも役に立つから、ビデオレンタルで設計してやると言う事になった。
設計法方としては、ユースケース図を書いてから、どうにかすると言う話だった。
で、設計者が逃走したので、俺が引き継いでいる訳だ。
だから無理に俺と張り合う必要はない。この方法は俺も分からないし、RESがなかった所を見ると、
誰も分かってない。間違えても文句は言わないからやってみたらどうだ？

>>113
そうか。俺は別におじゃばと張り合う？ことはなにもないし、
一般業務とおじゃばが呼ぶもんにはOOPなんかいらねぇと思うから、それ以外は納得。
しかたなくJavaでは書いてるけど、OOPなんかじゃないシステムの方が多いだろ。
じゃ本来のスレタイにそって言えば、
(おじゃばの言う)一般業務にはオブジェクト指向は普及する必要はない
でおｋ？それともコーディングに便利程度にはあったほうがいい、つことでいいかな？

そもそもOOを理解できていないおじゃばが何を言っても（ｒｙ

> 設計者が逃走したので
>>101, >>106 がその設計者様のような気がしてならないんだが。
違ってたらスマン

反対するんだったらさ、対案出そうよ。馬鹿じゃないんだろ？
対案出さないんだったら、煽りとしか思えないだろ？それぐらい分かるよな？

>>117 だな。特に w で終わってる奴は馬鹿の煽りの典型。
そして本人は馬鹿だということが分かっていない最悪のパターン。
ﾔﾚﾔﾚ┐(´ー｀)┌だな。悔しかったら(Ry...

>>117
誰が何に反対してるのかさっぱり分からんが
いい加減な設計をしておいて
だからOOAは使えないという結論に持っていこうとすることに自分は反対だ

>>109
＞つーか95、読んでないだろう？
読んだっつの。

＞無駄なUMLを大量に作っている
無駄かどうかOOA分からないくせに勝手に判断するなよ。
守破離とか、そういう言葉知らないのか？
まずは真似ろ。

面倒くさいとか良く分からないとかなら、まずちゃんとしたユースケース図を描け。
>>17はオブジェクト指向でのユースケース図じゃない。
表記法の問題ではなくて、内容としておかしい。
何度も言われているように、システムの範囲が分からない。
システムで分からなきゃ、この際プログラムと言いかえても良いよ。
それと原則として、プログラムと直接やり取りしないことは、ユースケース図には含めない。

ユースケース図を作ったら、1つ1つのユースケースに対してユースケース記述を書く。

そこまで終わってから、ようやく次に分析の粒度の粗いクラス図(ドメインモデル)の作成だ。
ユースケース図からクラス図を直接作る方法なんてねぇよ。(俺が知らないだけかも知れないが)

>>120
ユースケースって何？っておじゃばにいっても無駄。つか
＞分からないくせに勝手に判断するなよ。
は誰が何度言っても、おじゃばの本質に関わる部分らしいのでｗ
言うだけ無駄。無駄無駄。

>>120
システムを含まないものもユースケース図に書いていいよ
逆に書かないとダメ
その上でシステムの境界線を明確にすることが大事なんだから

>>99
>なぜ、DVD自身に
>・貸し出す()
>・返却する()
>が？
貸し出しや返却があった時にDVDインスタンスへ送るメッセージのつもりなんだがまずいかな？
コードにすると次のような感じ

　 class DVD {
　　:
　　貸し出す() {
　　　:
　　　update( { rent => true } );
　　}
　　返却する() {
　　　:
　　　update( { rent => false } );
　　}
　}

ORM使えば、update()でrent フィールド（貸し出し中フラグ）を更新することになる。

>>100
まぁ分析進めてけば当然、関連クラス（レンタル）も抽出されてくると思う。
管理簿クラス？の必要性は、俺にはまだちょっとわからない。

[コントローラ]　　　[DVD]　　　[レンタル]
　　　｜　貸し出す()｜　　　　　　｜
　　　｜−−−−＞｜　　　　　　｜
　　　｜　　　　　　　｜　　　　　　｜
　　　｜　　　　生成する()　　　　｜
　　　｜−−−−−−−−−＞｜
　　　｜　　　　　　　｜　　　　　　｜

>>108
料金クラスはちょっとやりすぎかもしれない。まぁ、とっかかりの分析ということで。
泊数に応じた料金を得るのに、[DVD].[料金list].get料金(泊数) みたいなのを想像
したんだが...

おじゃばへのレスは.... めんどくさいからいいや。

...と読み直してて思ったんだが、貸し出し中フラグじゃなくて、貸し出し数
の増減で管理した方がいいのかもしれない。同一タイトルなのに別インスタンス
ってのは冗長だったな。やっぱり管理簿クラスみたいなものの方がいいのかもしれん。

　　貸し出す() {
　　　:
if (rentCount < stock) // 在庫があれば
　　　 update( { "rentCount" => ++rentCount } );
}
　　}

俺がビデオ屋でバイトしていたときによくあったこと。

　・カウンターで、誰にどのＤＶＤを貸したか、その履歴を確認したい。
　⇒過去１週間のカウンター処理を時系列でさかのぼって貸し出し履歴が見たい。
　・ある客が棚からＤＶＤを持ってきて、
　　「自分が過去に借りたかどうか調べてほしい」という。
　⇒その客の貸し出し履歴（過去１年）を時系列でさかのぼって確認したい。

以上２つの要望に応えてくれないか。
俺が実務で設計する中で、こういう
"普段ほとんど使わないのに、必ず必要になり、なおかつその管理に負荷がかかるデータ"
の扱いに困ることがあるから。参考にしたい。
125 の DVD クラスではこの要望に応えるには無理があるだろう。
どんな設計が良いだろうか？

さて、そろそろOOが普及しない理由が具体例と共に見えてきた頃だね。

客は設計者との打ち合わせなんか無視して当初の想定外の要求を出してくるよ。
何度念押ししても言ってなかったことを言い出す。
きちんと打ち合わせすれば大丈夫だとか、契約範囲外だとか、
実際の金が動いている現場でそんな強弁できるという考えが大間違い。

>>127
だからそれは皆わかった上であえてやって「みてる」んだっての。
スレ嫁

>>127
そこで言いなりになるか交渉のスキルが持てるかが、
奴隷か技術者かの分かれ目でもある。
結局我々はシステムを作るだけの作業者ではなく、
システムとユーザとのインタフェースでもあるからだ。

なんて言えたらカコイイけどなｗ

>>126
「レンタル」自体を取り引きデータとして残しておけば、それを使って要件を満たせるんじゃね？
もしくは、別に履歴クラスみたいなのをつくって、取り引き履歴を残していくみたいな。
実装はDBだったら、SQLごりごりか、ORM使ってってなると思うんで、OO設計的な工夫は特にいら
ないような気もするが。そういう意味じゃなくて？

>>130
うん、まぁそうなんだけど。
当然ながら、履歴に数百、数千件の DVD インスタンスを持たせるわけにはいかない。
そしたら、やっぱ各 DVD には何かしら ID を持たせるしかないわけでしょ。
(履歴クラスみたいなのにはその ID だけ持たせる、と)

となると、システム全体を再度見渡してみるに、
ID で管理するほうが DVD クラスを作るより、軽量に済ませられる部分が出てくるはず。
となると、DVD クラスが必要になる場面って結構少なくなるんじゃなかろうかと。
システムのあらゆるところで ID ベースの設計になり、
実装するとなると結局管理簿クラス(≒DBのラッパ)になっちゃう。

となると、"無理やりＯＯでやってみよう!"の主旨からずれてしまわない？
と疑問が沸くわけで。
しかしそれでもどこまでＯＯで表現できるのか、見てみたいわけだ。
いや、問いが漠然としてて済まないが。

OODBで終了

>>131
OOとRDBをいっしょくたに扱おうとする場合に生じる問題はずっと言われてるな。
必要とされた背景や概念が違うからしょうが無いんだけど。だけど、

・過去１週間のカウンター処理を時系列でさかのぼって貸し出し履歴が見たい。
・その客の貸し出し履歴（過去１年）を時系列でさかのぼって確認したい。

については、仮りにデータは何百万件でも、最終的に取り出すデータはせいぜい何百
件というレベルだろうから、DAOパターンを使って、抽出はSQLで、メモリに取り込ん
だ後は、OOでって考え方でやるケースが多いんじゃなかろうか。
仮りに抽出対象が何千件だったとしても、それをいっぺんに画面表示しても、見るの
が大変だと思うんで、数十件単位のページング処理いれて、抽出処理もその単位でやる
とか。
あと、最近のORMは、関連するクラス（テーブル）が実際に必要になった時に読み込む
遅延読み込みとか、独自のキャッシュ機構をもってたりして、パフォーマンスの問題や
排他の問題も工夫されているんで、全てをOOでやりたいという場合は、ORMを使うこと
になるんだと思う。ただなんにしても、この部分はある程度の工夫と妥協（あきらめ？）
が必要で、慣れるまでが大変なんで、ここがOOが敬遠される理由のひとつにもなってる。

なにこの独り言。

要するにOOは現実の開発には適していないんだよね。
趣味でやる分にはいいんだけど。

いらね、ですむことだな。

class Cashier{

get貸し出し履歴（期間）｛

　foreach（this.rentals as rental）{


}

OOって全部一人でやれれば便利なところも多いんだけど、チームや外部とやるとなると、
わかってない奴、間違った覚えかたしてる奴、ポリシーが違う奴、いろいろいるから、
かえってカオスになりやすいというか、気の合う人同士じゃないといろいろめんどい。

ユースケースから直で実装クラス図に行くからおかしくなる

ユースケース→概念モデル出し→大枠のアーキ仮決め→ユースケース廻るかチェック
→ユースケース（シナリオ追加）→概念モデル追加→アーキ拡張→・・・
これがいわゆるOOAだろ
いうまでも無くここで一番だいじなのは概念モデル導出で、昔でいうところのDBテーブル設計にあたる部分

概念ユースケース書いたらロバストネス図くらい用意しようよ。

>履歴に数百、数千件の DVD インスタンス
はぁ？履歴はあくまで履歴だろ？なんでDVDインスタンスまで必要なの？

>>133
RDBを一つのオブジェクトとして扱えば、上手くまとまる気がする。

俺のチンコはシングルトンだが、俺のハートはマルチインスタンス。
神さまも罪な事をしてくれるぜ...

メッセージの送り先が無いのか
それは神さまからの罰なんだろう
受け入れ先が無いことを受け入れろ

>>114
普通はJavaで書いたらOOPでやるだろう。基本システム（継承、例外）や標準クラスはOOP向きだから、
OOPでやらないと面倒な事になる。OODが一般業務に有効なのかは分からないしが、OOPは十分有効だ。

>>120
読んだなら何でクラス図がリンク切れで、クラス図への変換方法も書いてないのに書かせる？
ユースケースも何で自分で書かない？俺のを修正するぐらいなら手間もかからないだろう？
何でUMLと作成手順には詳しいのに、実際のシーケンス図やドメインモデルも出して来ない？

>>145
>基本システム（継承、例外）や標準クラスはOOP向きだから、
さすが現実に大きな仕事したことがないヤツは言うことが違うねぇ。
コーディング規約とか、ドキュメント標準があるような仕事してから
一般業務だのを語ったほうが、って他のヤツもさんざん言ってたね。
まぁいいや。

>>146
クラスを使うな、って規約があるの？

…まさか、カプセル化やモジュール化を妨げる規約？

>>145
つか>>95のページでリンク切れてる図なんて、俺のところだと無いわけだが。
おじゃばの通信環境が悪いだけじゃないの？

＞ユースケースも何で自分で書かない？俺のを修正するぐらいなら手間もかからないだろう？
＞何でUMLと作成手順には詳しいのに、実際のシーケンス図やドメインモデルも出して来ない？

そんなの面倒くさいからに決まってんじゃん。
仕事でも無いのに、おじゃばのためになんぞでそんな面倒くさいことやってられない。
何で俺が面倒くさいことまでして書かにゃならないの？

まぁ面倒くさくないところで、ユースケース図だけ。
http://www.dotup.org/uploda/www.dotup.org12559.jpg.html

大体おじゃばこそ、前スレで「次に何をするんだ？」と聞いておきながら、
散々言われてる「ユースケース記述を書く」ということをしないのは何故よ？

床屋の看板だから。

>>146
何言っている？JavaでOO禁止などのコーディング規約があるのか？
確かにCの規約を流用したままの所もあるかもしれないが、それでも普通は修正するだろう？

>>148
店員--（DVDを登録する）-->システム
店員--（DVDを削除する）-->システム
店員--（DVDを貸し出す）-->システム
店員--（DVDを返却する）-->システム
店員--（会員を登録する）-->システム
店員--（会員を削除する）-->システム
つまりこういう事だな。で次は？
ユースケース記述ってユースケース図じゃないのか？97のか？シーケンス図か？
つーか97やシーケンス図を全ユースケースに対して書くのか？膨大じゃないか？
とりあえず、148のユースケース図からクラス図を作ってくれよ。

ユースケース図からクラス図なんて直に作れるわけねぇだろ。アホの相手は疲れる。

ユースケース記述ってユースケース図じゃない

「じゃない」は「とは違う」の方の意味だ、念のため

ユースケース記述ってのは自然言語で表現されるシナリオのこと

ちなみに、ユースケ・サンタマリアはUMLとは関係ない。

だからさ、ちゃんと基礎から学ぶ方法を身につけずに、行き当たりばったりで
流行の言葉身につけたような気になってるバカがあばれるからって
その上さらに中途半端に物教えようとしてどーすんのよ。

つ　おじゃばの低能はデフォ　熱くなった方が負け

OOおよびUMLがダメなのは、カタカナ語の濫用しすぎなところ
ドメイン、モデル、クラス、など一般的には聞きなれない言葉を平気に持ち出してくる
これから学ぼうとする技術者や、見せられる顧客がうんざりするのは当然

ユースケース図も、業務分析図とか業務領域図とかの名前にすればいいのに、
完全な和訳をやろうとしすぎて逆に断念し、
知らない人からすると「ユースケースってなに？」となり本末転倒

パッケージ図、コンポーネント図、アクティビティ図、コラボレーション図、ステートチャート図
ここまでくると一般的な純正日本人は完全にお手上げ
名前からどういう図なのか全く想像できない

技術者の努力不足もよくないが、
やる前にやる気を削ぐぐらい敷居を高く見せるのは完全に失敗してる

では和名案をどうぞ↓
ユースケース図：
パッケージ図：
コンポーネント図：
アクティビティ図：
コラボレーション図：
ステートチャート図：

なんかもう、ユースケースからクラス図は絶望的っぽくなって来たので、ドメイン図をやるか。
つーかこのドメイン図ってER図だろう？完全にDOAだが仕方ない。
普通にテーブル設計してみる。
----------------------------------------------------------------------------------------
会員（会員番号、住所、氏名、生年月日、入会日、退会日）
商品（シリアル番号、DVD番号、入荷日、廃棄日）
DVD情報（DVD番号、タイトル、ジャンル、年令制限、発売日、レンタル開始日）
料金表（料金番号、期間、金額）
料金管理（料金番号、優先順位、開始レンタル開始日、終了レンタル開始日、DVD番号、ジャンル）
貸出管理（貸出番号、シリアル番号、会員番号、貸出日、返却予定日、料金、延滞料金）
----------------------------------------------------------------------------------------
料金の所は難しいので、貸し出し時に料金管理から初期表示させて、特別料金なら手動で変更可能とする。
料金管理はレンタル開始日、DVD番号、ジャンルのANDで指定可能。省略時はNULLを指定。
貸出管理には料金表から料金と延滞料金を設定する。料金表の期間には延滞も含む。

>なんかもう、ユースケースからクラス図は絶望的っぽくなって来たので、ドメイン図をやるか。

絶望しているのはみんなからあんたです。
いえ、もう1スレ目からだけど。

ユースケース図：業務分析図
パッケージ図：ソフトウェア依存関係図
コンポーネント図：物理的依存関係図
アクティビティ図：拡張フローチャート
コラボレーション図：相互作用図
ステートチャート図：拡張状態遷移図

ちなみに、「ユースケース」＝「ユースケース図」＋「ユースケース記述」なんだが
http://www.atmarkit.co.jp/im/carc/serial/renew_uml08/renew_uml08.html
お前がやっていることはプログラム＝データ構造＋アルゴリズムなのに
アルゴリズムのみを定義してみたが、一向にプログラムにならんと言っているだけだ

おじゃばは、リンク先みないし冗長な説明が嫌い。
おじゃばは、リンクも張るし冗長な説明しかしない。

>>162
ちょｗ　リンク先ｗ

ttp://java-house.jp/ml/archive/j-h-b/020739.html#body
からの流れで高木さんにフルボッコにされた、あの萩本順三か。

>>148 >>150
…のユースケースでシステムが用意する必要があるデータ↓

・DVD情報
・会員情報

ここからクラス図を作るんでしょ？
ちがうの？

デスマーチがなくなる？ IT業界に義務付け「工事進行基準」ってなんだ
http://www.atmarkit.co.jp/news/analysis/200803/31/sier.html

>>166
そんなもんいいから、近代的な開発手法の一つでも取り入れろよ。

>>162
で、ユースケース記述を書くとクラス図が出来るのか？
ユースケース図ですら関係無さそうなのに、ユースケース記述はもっと関係ないのではないか？
148から1つでいいからクラス図を作ってくれ。

>>164
「デザインパターン使えばOOだと思っている」+「UML使えばOOだと思っている」の人か。
オブジェクト指向設計が普及しない訳が分かって来たな。

で、ユースケース図からは無理だと言う事は分かったが、ドメイン図からは出来るのかな？
テーブル設計なら160でやった内容で、DOAならもう作れると思うが、OOはこの後どうするんだ？

久しぶりに、書いてみる
>>79　ユースケースからクラス図を書く人間はいっぱいいるぞ
>>109 >内容も項目抽出はDOAだし、途中からO/Rマッピングもどきの話になっているし、無駄なUMLを大量に作っている
何をもってDOAと言っているのか分からん、見てみたが一般的なオブジェクト指向分析だと思う
>>125 それは構造化
>>126 俺ならレスポンスが要求されるから、クラスメソッドで実装し直にDBにアクセスする
この時のO/Rマッピングはストアドプロシージャで行なう
>>127 それはウォーターフォール開発の問題点で、オブジェクト指向とは関係ない
ウォーターフォール開発の弱点を解決するのが反復型開発で、オブジェクト指向との相性も良い
>>131 >となると、"無理やりＯＯでやってみよう!"の主旨からずれてしまわない？
なにをもってオブジェクト指向らしいと言っているのかが分からん
>>140 ロバストネス図はそんなに詳しく無いが、ユースケースから書ける物か？概念クラス図はいらないのか？
>>146 >さすが現実に大きな仕事したことがないヤツは言うことが違うねぇ。
お前は、大規模開発やった事があるのか？あれば、それはウォーターフォール開発・反復型開発のどっちだった？
>>151 今回は皆がある程度業務理解しているレンタル屋で要件も少ないから、書けなくない（社内SEが詳しい仕様を聞かなずに作るレベル）
>>160 >つーかこのドメイン図ってER図だろう？完全にDOAだが仕方ない。
ドメイン図って何だ？パッケージ図の事かそれともクラス図か？

で、おじゃばはオブジェクト指向をお前のやってる業務に普及させたいのか？
普及なんかしてないのは十分わかった。
だれもおじゃばが望む分析から設計はOOではできてない。
お前自身、分析設計はDOAでしかできない。なのになんで、
JavaにはOOPの仕組みがあるからOOは役に立つ、って話になるんだ？
OOって、COBOLで十進演算があるから便利、VBでイベント処理が簡単で便利、
それくらいの話になっちまうぞ？そんならそれでいいけどな。

>>170
そんなに聞いても逃げたヤツはだめだ、ってことになると思うよ。
君OOかぶれのバカとしか見られてないし。

> >>127 それはウォーターフォール開発の問題点で、オブジェクト指向とは関係ない
> ウォーターフォール開発の弱点を解決するのが反復型開発で、オブジェクト指向との相性も良い

それはOOを勘違いしてるよ。
ちゃんと勉強しようね。

OO分析設計は分析設計初期開発段階で保守段階の変更の可能性を十分に検討し尽くす
という前提だから効果があるのに、現実ではそんなことが不可能だから使い物にならない。

OOは、分析設計及び最初の開発のコストを高めて、保守段階のコストを下げるトレードオフ手法。
ところが現実にはOOをきちんと理解している奴がほとんどいなくて、当初のコストが上がっていることを理解せず、
平気でさらにコスト高なことをさせてしまうから「分析設計及び最初の開発のコストを高めた」のがさらに数倍のコストになり、しかも、保守段階のコストも下がらない。

結局OOは使われず、またOO離れが進み、OO理解者が減り、たまに出てくるOO好きもOO無理解者のコスト増大法によって鬱になってつぶれていく。

>>173
だとするよ、理解する価値が最初から無いもんじゃない？せんずりじゃん。

>>174
正解。
研究者が描いたズリネタで、マニア技術者がセンズリしてるだけ。

OOで一番効率よいのはCOM辺りの貼り付けだけでコードがほとんど無いプログラミングじゃないか？

･･･といって、それはXXのことじゃん？ってちゃんと･･･むりむり。

関係者全員が完璧に理解していれば、後は設計方針とか宗教的な話だけで済むのに
そもそも全員が完璧に理解できる程易しいものじゃないので無意味。
きちんとdeployされていればうまく使える手法のはずなのに、そのdeployment手法が
まったくダメってのが悲しいね。

その良い例がおじゃば。



なんというか、OOの手詰まり感って、
超高速で動くリニアモーターカーを作ったけれど、線路は作れませんでした、
みたいな感じ。

おじゃばは理解するんじゃなくて理解しろだからな〜。
おじゃばが言ってるのは結局自分に対する共感であって
現実に対する妥協じゃないだよな。

>>178
そこまでOOに幻想もてるのがすけーな。宗教だろそれ。俺だけが知ってることにしたいのか？

>>180
いちおう博士号まで取ったからね。
だからダメさも良く分かってる。

良く言う、1人のOO理解者と99人のソルジャーのためのモデルって、
そもそも現実はそうじゃないからね。

1人のお客さん、1人のOO理解者、99人のソルジャー、
最初の1人を無視してる時点でダメ。
お客様は予想不可能、この前提が入ってないと使えない。

ダメなもんで博士号をとったら、そのひとはえらい、のかも知れないね。
俺は一緒に仕事はしたくないなぁ。

>>183
ソフトウェア工学の研究者なんて、みんな絵に書いたモチだけで論文書いてる。
この50年で現実に使い物になった研究なんて形式言語理論やら構文木がｺﾝﾊﾟｲﾗに利用されてる部分くらいだろうし。

>>184
俺OOはともかくアンタには会いたくないな。プライドがないもん。

>>185
たぶん研究ってものに対する見方が研究をしたことがある奴とない奴で違うからだろうけど、
研究の成果なんて失敗100個で成功1個出てくればいい方だよ。
失敗は成功の元だよ。
一度誰かが失敗して、問題を明らかにすることも重要。


話を戻すと、OOは失敗作。

とは言え、条件付では現時点でほぼ最良の手法。
まぁ、その条件ってのが、現実では成立しない条件だから意味が無いわけだが・・・

>>173
>それはOOを勘違いしてるよ。
>ちゃんと勉強しようね。
オブジェクト指向と関係ないと言っているが

>>127
>客は設計者との打ち合わせなんか無視して当初の想定外の要求を出してくるよ。
>何度念押ししても言ってなかったことを言い出す。
>きちんと打ち合わせすれば大丈夫だとか、契約範囲外だとか、
>実際の金が動いている現場でそんな強弁できるという考えが大間違い。
これがオブジェクト指向特有の問題だと思うのか？
構造化では、この問題はないと思うのか？
それとも構造化を使わなければ、解決出来ると思っているのか？
そもそもUPを理解しているのか？

お前は、何だったら勉強しているんだ？

間違い
×それとも構造化を使わなければ、解決出来ると思っているのか？
○それとも構造化を使えば、解決出来ると思っているのか？

さすがにお勉強なさっておられる人は言葉遣いに知性が現れているな。

>>187
だから、OOと関係無い、と思ってるのはそもそもOOを勘違いしてるからという指摘だよ。

OO特有の問題なんだよ。
意図的にサイクルの前半のコストを上げて、後半のコストを下げるという、ただのトレードオフだということを理解していない奴が多すぎる。

ほぼ最古のOOの聖典、Jランボーの「オブジェクト指向方法論OMT」の１０ページ目の１２行目。
「オブジェクト指向開発は従来の開発方法と比べてより時間のかかるものである。」

従来と比べてより時間がかかる方法なんだよ。
それを理解せず、これまでと同じ程度の「再設計」「手戻り」を出せば、
従来の手法と比べて飛躍的にコストが増大する。

>>190
俺はOOはモジュール化の手法だと思ってるんだけど、ちがうの？

>>191
広義というか、特定のソフトウェア開発に対してOOを適用することを
高い抽象度で捉えたら、OOは、前半苦労して後半楽するための道具。

それが毎回適しているとも限らないし、
前半の苦労が場合によっては数倍になる可能性が高い場合には使うべきではない道具。

だから1人で長く一つのソフトを開発するにはいいんだけどね。
金を払っているということでお客さんの立場が強くて、
「どうしても」の一言でいままでの打ち合わせの話を覆される可能性があるなら
使うべきではないんだよね。

というか君が前提としている内容「OOは、前半苦労して後半楽するための道具」を
誰も受け入れていないので話がかみ合わない

>>192
何をどうすればコストが数倍になるんだ…

>>193

http://www.ijinden.com/_c_04/James_E_Rumbaugh.html

オブジェクト指向開発についての一般的な誤解の一つに、開発が容易になり短期間で
すむはずだという見解が根強くあるが、ランボー氏は上記著書の中でその考えを明快に
否定している。

「オブジェクト指向開発による主な利益は開発時間の短縮ではない。
オブジェクト指向開発は従来の開発方法と比べてより時間のかかるものである」

「オブジェクト指向方法論ＯＭＴ」より

オブジェクト指向開発の最も顕著な利益は、コンピュータ・システムの構造が人間に分
かり易い形に構成されるという点にある。このことはそのシステムの変更時や、そのシ
ステムを土台にした次のシステムの開発時に威力を発揮する。つまり、最初に作って
それでおしまいではなく、「継続的な改変と成長の過程にこそ生きたシステムがある」
という観点に立ったときに初めてオブジェクト指向開発の本領が発揮されるのである。
このことは通常の一回限りの受託開発では往々にして忘れられるか理解されないことが
多く、特にマネージャクラスがわかっていないとプロジェクトは予算と納期の狭間で深刻
な困難に直面することになる。

>>195
…それ、再開発や手戻りがあっても大丈夫って結論にならないか？

>>195
わかってないなあ。

君の言葉で説得しないと意味がないんだよ。
「本を読めば書いてある」と言いたいんだろうが、
本を読んだ人は君の言葉なんか聞く意味がない。
だって君はその本に書いてある以上のことを何一つ言っていないだろう？

>>196
良い指摘。
再開発や手戻りがあっても大丈夫、というのも程度の問題なんだよね。
お客さんが話を根底から覆すことは無い、が成立していないとダメ。

>>192
＞金を払っているということで（以降

そら違うよ。
＞「どうしても」の一言でいままでの打ち合わせの話を覆される可能性があるなら
覆されるときに、さらに金と時間(というか仕様変更にかかるコスト)を客から取れ、つー話。
そこでなぁなぁに仕事を受けるからデスマーチ化する。

お客様は確かに受注側にとっては尊重すべき存在だけど、
客先の1つ2つ切っても生きていける体力が会社になければ、
まともな職場環境なんて作れない。

OOは全然関係ないな。スマン。

>>198
お前はプロジェクトを白紙に戻すお客が居ると思っているのか。
それは、現実的にありえんよ。

>>190
>意図的にサイクルの前半のコストを上げて、後半のコストを下げるという、ただのトレードオフだということを理解していない奴が多すぎる。
それと
>客は設計者との打ち合わせなんか無視して当初の想定外の要求を出してくるよ。
>何度念押ししても言ってなかったことを言い出す。
>きちんと打ち合わせすれば大丈夫だとか、契約範囲外だとか、
>実際の金が動いている現場でそんな強弁できるという考えが大間違い。
は別の話だ、ライフサイクルの話をしているだが
本当に分かっているのか？

>>196 >>198
ちょっと補足。

お客さんが可能性A,B,C,D,Eを最初に提示して、
それに対応できるよう設計、開発しておき、実際Aのみ対応しておいて、
あとから、B,C・・・と変わっても対応可能、というのがOOの強み。

ところが現実は、お客さんが示す可能性A,B,C,D,Eどころか、
後でX,Y,Z等を出してくる。当然、A,B,C,D,E対応で高コストな分析設計開発を
していたのに、さらに再度高コストなA,B,C,D,E,X,Y,Z対応をやりなおすことになる。

そもそもOOというのは系のダイナミズムに注目したところが新しいと思う。
それが適した場面はもちろんあるだろうけど、
多くの業務は「帳票」が中心にどーんと座っているわけで。
そこにインピーダンスミスマッチがあると感じるんだよな。
所詮モデリングの核心がvalue objectなんだもの。

>>199
それも良い指摘なんだけど、客がOOのコスト高を理解していないから、
往々にして「なんでやり直しにそんなに時間、金、人がかかるんですか？」
となってしまうのよ。

>>200
白紙というか、人によっては、今までの打ち合わせを完全無視するのが平気な人も
いるんだよね。不思議な感覚だけど。まぁ決定権がある場合、1度で関係切るけど。
でも、その1回は仕方なくやるハメになる。

>>201
ライフサイクルの開始をどこに想定してる？

>>202
別に再設計する必要はないだろ。
本当にOOなら。

>>202
ダイアグラムのIN/OUTを柔軟に設計しておけば
想定範囲内での拡張には構造化設計でも十分に対応できますが。

>>205
そもそもOOがうまく使える前提の場合はそうだね。再設計は不要。
たとえば一人で分析、設計、開発するケース。

ただ現実のチーム開発のほとんどはOOがうまく使えないケースが多いということ。

>>206
そうだね。対応できるね。
まぁOOはその対応に主眼を置いただけって感じだしね。

>>207
こうゆうレスを見る度に思うんだけど、
一体普段はどうやってチーム開発してるんだろうって。

>>209
チームが悪いというか、現実のお客さんが理想的な客ばかりではなく、むしろ
無茶言い出す方が多いということよ。

>>202
それはOOであるとか構造化であるとかというより、
アジャイルとか、そういう開発手法そのもの問題にならないか？

例えばプロトタイピングして、要件定義から覆るような要望があったとしたら、
OO、構造化に関わらず今までの全ての作業が無駄になる可能性が高いのでは？

その上でOOでは、許容できる手戻りや機能変更の範囲が構造化よりも大きいと思う。

>>210
例えばどんな？

>>210
時間をかけて設計しても、どうせ客が無茶言い出して引っくり返すから無駄
という主張にしかなっていないような気がする
分析設計手法とは無関係で、単にウォーターフォールは駄目という結論にしかならない

>>211
お。良い理解してる希ｶﾞｽ。
ほぼそのとおりなんだけど、OOは許容できない程に手戻りした時のダメージが
構造化より大きいという感じ。

許容できる手戻りなら、その範囲も従来より広いし、ダメージも少ない。
ただ許容できない場合、一気にﾃﾞｽﾏ化。

>>213
ちがう。ひっくり返って無駄になるコスト、再度やりなおすコストが
従来と比べてでかすぎる、と。

>>215
そりゃウォーターフォールを前提にして設計に時間かけてるからだろ

「ひっくり返って無駄」という発想そのものが
ウォーターフォールに凝り固まったオールドタイプの発想だと気付け

>>214
俺はOOは構造化の発展だと思ってるんだけど、ちがうの？

>>216
現実はウォーターフォールから逃れられない面があるわけよ。
開発の外側の話も含んでしまうけど。

>>217
発展という面もあるけど、コストは全然高くなっている。
それは上の方に書いたJランボーの言葉のとおり。

ドメイン図とはなんだ？
しかもERがどうとかってなんの関係があるんだ？
ドメインの意味を分かってないだろ

>>218
ひっくり返ったら無駄って発想にツッコミが入ってるんですけど…

つか、設計に時間をかけてモジュール化をすると、変更に強くなるから逆にコストが下がるんですけど。

>>220
だから変更範囲の問題なのよ。
結局、想定している変更範囲、または暗黙のうちに想定に入る変更に対応している設計開発してるだけで、想定を超えたら終了ってこと。

開発はともかく人生はウォーターフォールから逃れられないから
学問に費やしたコストはちゃんと回収しないとな

>>221
…モジュール化の意味分かってる？

>>223
モジュール化による利点は隠蔽、な。
でもそのモジュール使わない話になったら無意味ってこと。

ちょっと極端すぎる例かもしれないが、
画像表示ソフト作ってください、という話で進めてたら、客が望んでいたのは動画再生ソフトしかも表示不要でストリーミングするだけ、とかな。
モジュール化以前の問題。
まぁ極端すぎる例だが、このとき分析設計、初期開発にコストをかければかける程、
ダメージが大きい、という話。

一体おまいらは何についての解を求めようとしてるんだ？

>>225
客はアホだという話。

客というか営業かもな。

んー、再設計について実務経験からだけど、ちょっと思ったことがある。
とりとめもないし、個人的な短い実務経験だから、これが真だとは言えないけど。

構造化もOOもどちらも使うことがあるけど、大体許容出来ない仕様変更があった場合、
そもそも設計思想を潰してゴリ押しすることが多いように思う。実務では。
つまり仕様変更直後の開発中に、もう一度構造化やOOで分析からやり直したりはしない。

例えばグローバルなメソッドやフラグが交差するようなスパゲッティな設計とコードになる。

で、一段落してからリファクタリングする、と。
リファクタリングする時に分析から見直して、分析結果がドラスティックに変わるようなら、
OOを使っていた方が、既存の部分で利用可能なコードは少なくなるような気は、確かにする。
分析結果があまり変わらなかったら、どちらでも大して手間は変わらないかな。

まぁそういうことを言いたいわけじゃないんだろうけどね。

>>224
一言いいか？愚痴スレ池

例はともかく、客自身がどういうシステムが欲しいのか
自分自身でうまく表現できないことはよくあるからな
紙芝居を作って客からOKでても、やっぱり違うと言いだす客はいるし

営業：「この案件、前にやったあれとかなり似てるよね？
　 　 　5000万で取ってきたけど大丈夫だよね？」

開発：「全然違いますから・・・
　 　 　 前回、赤字でもあれほど使いまわしが効くように作ったのに、
　 　 　 全く違うものなの取ってきたら前回の苦労は水の泡ですが」

これはある。

>>229
愚痴じゃなくて質問に淡々と答えていただけなのによ・・・

>>231
良くある。
そして結局無理に使いまわすことになって、とんでもないことになることも良くある。

なんか自演臭がするんだが

>>224
なんで隠蔽するのか分かってる？

>>235
変更による影響範囲を小さくするためな。

ところが、モジュールを設計、開発したこと自体が無駄なケースもある、というケースでは
モジュールの設計に時間をかければかけるほど無駄と。

>OOを使っていた方が、既存の部分で利用可能なコードは少なくなるような気は、確かにする。

OOだとデータと振る舞いが結合しているからな。
「分析結果がドラスティックに変わる」というのは大抵の場合
クラスへの責任の持たせ方が変わるということで
その段階でそれまでのデータと振る舞いの結合が一旦切られて
組み直されることになる。こうなるとOO設計を前提に作られている
システムは却って再利用がきかない。

一貫してアゲまくってるのが俺

アジャイル宣言以前のオブジェクトテクノロジについて批判してるやつは自重しろよ
ランボーの本だってウォーターフォールしかなかった20年以上前の話だろ

>>236
一体どんなケースだよ…
ん〜と…

・白紙に戻される(これは追加料金とるよな…)
・扱うデータがかわる
・別のプログラムとコンバート

くらい？

>>200
某信販会社や某銀行で実際に起こってるよ
結局債務不履行と客に訴えられ訴訟にもなってるね

銀行の方は要件レベルでおかしかったのに続行したからな・・・

>>240
・白紙に戻される(これは追加料金とるよな…)
・扱うデータがかわる
はあった

・別のプログラムとコンバート
ってのは無かった希ｶﾞｽ

>>236
>>240だとイマイチ決定打に欠けるんで今後の為に聞いておきたい。

どんなケース？

>200
中止するお客はいるよ?

>で、ユースケース記述を書くとクラス図が出来るのか？
>ユースケース図ですら関係無さそうなのに、ユースケース記述はもっと関係ないのではないか？

ユースケース図、って単なる見出しでしかないだろ？
そのユースケースにおいてシステム(=たいていは複数のオブジェクトの連携)が何をするのかを書き出さなきゃ
話はそれからだ

ついでにいうと ロバストネス図≒概念クラス図 がユースケースから作れる

OOはウォーターフォールが前提、という斬新な人がいるスレはここですか？

>>170
簡単に言うと、DBのテーブル設計をDOAと言うんだよ。
あとドメイン図の事だが、俺も良く分からないがER図もどきらしい。誰かのリンク先に書いてあった。

>>171
JavaではOOPの仕組みがあるから、OODは役に立つとは言っていないだろう？
OODを普及させたいとも言っていない。
JavaやC++を使うならOOPは必須だし、どんな分野にも使えるし、普及している。
OODは特定分野にしか有効でないと思うが、どんな分野でも使えると言う名無しがいるので検証してみた
ところだ。

>>173
>OO分析設計は分析設計初期開発段階で保守段階の変更の可能性を十分に検討し尽くす
はっきり言っておくと、これは間違いだ。
設計の初期段階で変更の可能性を検討し尽くすのは構造化設計の手法で、それに限界があるので、
OO設計が出て来た。OO設計の特徴は、全てをオブジェクト単位で抽象化する事によって、
変更があろうがなかろうが、オブジェクト単位での変更を容易にするという手法だ。
初期開発コストは増大するが2倍にはならない。ソースコード換算だと構造化に比べて約1.2倍程度だ。
これを高いと見るか低いと見るかは場合によるだろう。

こいつのレスは場合に寄らず間違いだらけ

>>178
関係者全員が完璧に理解って、普通はOOでなくてもありえないだろう。
あと、ダメなのは俺じゃなくて、「俺の示した例」だろう？
それに、OOに幻想持ち過ぎじゃないか？

>>179
では現実に対する妥協例を見せてくれ。

>>181
誰にでも分かるように出した例だから、博士じゃなくでも分かるだろう。
あと博士ならダメでない方法でクラス図まで作ってくれ。

>>245,246
つーか、自分では書けないのか？
UMLの種類と内容に詳しいが、実務ではクラス図1枚書けない人がいる。
この人はプログラムの作成経験が殆ど無いが、UMLの本だけ読みあさった、なんちゃって学者だ。
もしかして245,246は、なんちゃって学者か？

おじゃばはうぜーから黙ってろ。
このクソキチガイ。

>>251
いや、おじゃばはつっこめそうなヤツにしかレスしないし、
自分へのつっこみは手に負えないのはスルーしちゃうから
クソキチガイというよりはただの卑怯者「だと思う」よ。
自分よりできる存在に目をつぶって、ここで語りたいだけだよ。

>>248 おじゃば
>あとドメイン図の事だが、俺も良く分からないがER図もどきらしい。誰かのリンク先に書いてあった。

自分が理解できてないものをどうやって書くつもりだったんだ？
分析や設計についてお前が正しいだの間違いだのいう発言すること自体が、間違いだろ
クラス図うんぬん言ってるが、
要件定義を聞いていきなりコーディングするお前に書けるとは思えんな
今の流れを見ても悲惨すぎて、かわいそうなぐらいだ

それが分かるほどの知能は無い

>>248
>簡単に言うと、DBのテーブル設計をDOAと言うんだよ。
それは違うだろ、DBを使わないシステムではDOAは不可能になる
DOAはPOAの対比で生まれたものだから、モジュールを設計する視点の違いだ

昨日は開発ライフサイクルの手法と開発手法を一緒にするアホが
いたから話が反れた、元に戻す為に俺なりのクラス図まで書いてみる
要件は：会員登録・貸出し・返却の基本業務から始める
まず、ユースケース図は>>148で良いと思う
抽出した要素は
　★　ＤＶＤ　★　　　　★　会員　★　　　　　★　レンタル　★
　　タイトル　　　　　　　カード番号　　　　　　　 貸出日
　　入荷日　　　　　　　 氏名　　　　　　　　　　　返却予定日
　　　　　　　　　　　　　　生年月日　　　　　　　　返却日
　　　　　　　　　　　　　　電話番号　　　　　　　　料金
　　　　　　　　　　　　　　郵便番号
　　　　　　　　　　　　　　住所

これから、概念レベルのクラス図を書くと、こんな感じになる
http://www.dotup.org/uploda/www.dotup.org14203.jpg
多重渡やロールの確認もまだしていないし、クラス自体も
まだまだ荒いと思うが「おじゃばさま」追加・修正してくれ

ねぇ。あのさぁ。みなさん、特定の一人の遊び場をいつまで維持してあげるつもりなの？
全員が飽きる前に新しい人が来るからエンドレスになっているように見えるんだけど。

自分で答えを言ってるじゃん

ゴールド会員とか家族会員とかはどっから出てきたんだ？

なんで業者と店の人間ことかかないで
借りる関係だけ記述してるんだよ

おまえしばくぞ前○だろ貴様

どちらかと言うと、DVDとビデオが分かれてるのが気になる・・・

>>259
概念クラス図にアクターなんて出て来ないべ？
釣られたか？

>>255
レンタルビデオ店に法人会員なんてあるんだ。知らなかった。
これって、「レンタル」に関するクラス図だよね。オーソドックスで悪くない
クラス図だとは思うけど、家族会員と個人会員の関連がこのクラス図だとよく
分からんな。誰が誰の家族ってどうやって分かるんだろ？

ユースケースを分析した
結果も出さずにいきなり実装に
近いクラス図出してくるのはどうなのよｗ
概念クラスじゃ無いだろうそれ

何も心配することはない。仕様なんてものはみんなの心の中にあるんだよ。
ほら目を閉じてごらん。きっと見えてくるから。みんなのひきった笑顔が。

何コレ

なんつーか・・・何が不足してるんだろ？
センスとか経験とかそういう根本的な部分？

>>264
自分が何をしているのか、という認識がうまくできないレベルの話。
もう、おじゃばと393のキテレツOOモドキ漫才でもいいような気がしてきたよ。

文系大学でてSE職してて勘違いしてるんだろきっと

デスマ突入に備えてもう少しキャラが欲しいとこだな
もっとこう絶望的な雰囲気を醸し出せるような

>>251
図星か。でも恥かくのがここで良かっただろう？仕事だったら悲惨だぞ。

>>252
俺は自分より出来る存在と戦ってみたいと思っている。
で、俺が無視した出来る存在って誰だ？ほとんどがレス無しか、他の人に撃沈させられてるようだが。
番号指定してくれれば、俺が参戦するが。

>>253
設計が出来ないのに、要求仕様聞いてコーディングが出来る訳ないだろう？
愚痴る暇があったら、俺のドメイン図もどきを修正して本物にしてくれよ。

どっちかというと都合の悪いレスほどスルーしている傾向があるように記憶しているが

>>255
簡単に言い過ぎたが、DBのテーブル設計の手法で、モジュール設計すると言う意味だ。まあ言うまでもないかな。
では本題に入ろう。ユースケースから名詞を抽出して、「DVD」「会員」「レンタル」にしたののか？
-----------------------------------------------------------------
店員--（DVDを登録する）-->システム
店員--（DVDを削除する）-->システム
店員--（DVDを貸し出す）-->システム
店員--（DVDを返却する）-->システム
店員--（会員を登録する）-->システム
店員--（会員を削除する）-->システム
-----------------------------------------------------------------
ユースケースが上記だとすると、DVD、会員はいいとして、レンタルはどこから持って来た？
DVDの登録〜返却を「レンタル」にしたのか？
そうすると、会員の登録、削除も「何か」にするのではないか？

>>269
だからどれだ？気にも止めなかったやつかな？
一例をあげてみろ。

自覚がないっておそろしい

>>267
これ以上絶望的なってどんなヤツがいるのよｗ

>>273
知識もなければ空気も読めないくせに
ムードメーカーを気取ってより悪いほうへヨイショする奴がほしい
アイディアに対して反対や批判ばかりでは冷戦状況を作りだすことは難しい

>>268
質問にちゃんと答えな

>あとドメイン図の事だが、俺も良く分からないがER図もどきらしい。誰かのリンク先に書いてあった。

自分が理解できてないものをどうやって書くつもりだったんだ？

おじゃばはそろそろおばかに改名した方がいいぞ

>俺は自分より出来る存在と戦ってみたいと思っている。
こんなレス乞食の相手は393だけで十分。やらせておけ。

>>275
>>あとドメイン図の事だが、俺も良く分からないがER図もどきらしい。誰かのリンク先に書いてあった。
>自分が理解できてないものをどうやって書くつもりだったんだ？
ドメイン図は良く分からないが、ER図もどきと理解したので、テーブル設計を書いただろう？
書くつもりではなく、すでに160に書いてある。ER図の意味が分からなかったのか？

>>276
つまり俺は答えを言っていたのに、275にはどれが答えか分からなかった訳だな。
で、俺がバカになるのか？それは厳しいな。

>>277
虚勢を張っても、クラス図1枚出せない277は、怪しくてもクラス図を出した俺や393以下である事には変わりない。
つまり俺が乞食なら、277は乞食以下と言う事だ。

らしいとかもどきとかそんな理解度で胸を張れるお前にはがっかりだ

レス乞食は仕方ないなぁ。これでいいのか、ほれほれ。

>>281
ヤッター！！バカレスGET！！アリガトー！！

ﾊｲﾊｲﾊﾞﾛｽﾊﾞﾛｽ

なんでおじゃばはこのスレに粘着してるの？

>>271
一例か。おれは >>269 ではないけど挙げてみるか。

>>182 からの議論がこのスレにしては珍しくそこそこまともに盛り上がっていたが
それがひとしきり終わった後のおじゃばのレス↓

> >>181
> 誰にでも分かるように出した例だから、博士じゃなくでも分かるだろう。
> あと博士ならダメでない方法でクラス図まで作ってくれ。
>
> >>245,246
> つーか、自分では書けないのか？

完全スルー。

>>285
おじゃばは、お客相手にしたこと無いから言えないんだろうね。
前スレでCの呼び出し規約の話が出てアセンブリのことになっても、
嘘つき呼ばわりされるまで知らん顔決め込んでたし。
臆病、つか卑怯なんだよ、おじゃばって。そのくせ乞食だし。

どっちかというと卑怯とか意図してやってるわけではなく
妄想を書いた時点で証明責任レベルまで果たしたつもりになっちゃうキチガイ系かと

つーか「証明」に必要なプロセス（所謂ソース提示など）か
ソースとしてどんなものが認められるか
このどちらかないしは両方がわかってないと思われ
理解していればここまで純粋に憶測や妄想だけ書き殴って胸を張れるわけがない

>>287
そうか。キチガイならしかたないな。

>>278
よくあるドメインモデルの図はクラス図だけど。
クラス図自体がER図を参考にしてる上に、
ドメインモデルにゃ操作を書かない手法もあるらしいので、
そうなると見分けは付きづらいかもな。

おじゃばって、ユースケース図から名詞抽出とか、クラス図を作らせようとして、ほらほら作ってみろって、
煽っているようにみえるんだけど、これは気のせいか？ それとも本当ににおじゃばはよくわかってないのか。
それにしては妙に自身満々だし...　ユースケース図で要件の全てが表現できるなんて信じるほど素人でも
あるまいし、まさか、ユースケース図とユースケース記述を取り違えているのか、それともユースケース図の
目的が本当にわかってないのか、よく、わからん。不思議な男だ。釣り？

おじゃばは何がしたいん？
ユースケース図もどきを書きたいのかアクティビティ図の出来そこないを書きたいのか、
UMLにないドメイン図（意味不明）とやらを書きたいのか、
一体どうしたいん？
UMLを学習したいってことでいいの？

素直に俺らにどうか教えてくださいって
頭下げりゃいいのになこれだから変に
プライドのあるバカは扱いにくくて困る

ちょっと対人関係障害気味のイタイ人だろ
ちょっと値段聞いただけで、自分の世界に入ってひたすら技術の話しまくる頭のおかしそうな秋葉原あたりの店員みたいな奴だな

>290
ハッタリでしょ　どう見てもわかってる人間の発言じゃないし
それでいて自分の言ってることが正しいと思ってるみたいだから手に負えないが

>292
> プライドのあるバカは扱いにくくて困る
たまに居るけどホント手に負えない

>>261
>クラス図だとは思うけど、家族会員と個人会員の関連がこのクラス図だとよく
>分からんな。誰が誰の家族ってどうやって分かるんだろ？
確かに間違っているな、修正してみる
まず家族用のクラスを追加するとして
この場合、法人会員にも同じ事が言えるから、法人・家族会員より上位の抽象概念「団体会員」を
導入する、これに「メンバー」(家族用のクラス)を関連付ける、
あと団体会員用カードも追加する、これで大丈夫か？
http://www.dotup.org/uploda/www.dotup.org15092.jpg

>>277
>では本題に入ろう。ユースケースから名詞を抽出して、「DVD」「会員」「レンタル」にしたののか？
俺は名詞から抽出しない、別の方法を使っている、メジャーじゃないがなかなか良い!!

>ユースケースが上記だとすると、DVD、会員はいいとして、レンタルはどこから持って来た？
レンタルはDVDと会員の関連として抽出した（関連クラス）

>DVDの登録〜返却を「レンタル」にしたのか？
>そうすると、会員の登録、削除も「何か」にするのではないか？
今回は「要件：会員登録・貸出し・返却の基本業務」だけ行なう
全て俺が行なうのも駄目だと思う、そこは誰か別の奴がやってくれ

しかし概念クラス図に対するつっこみが少ないな、かなり基本的な間違いや
小さい間違いも多いだが？
一応、俺から質問だしてみる、今回のクラス図では商品の新作・準新作・旧作が
上手く表現出来ていない（入荷日からの判定と思ったが、再入荷の場合は最初から旧作になるとか問題もある）
これを上手く表現してくれ

295=393 名前忘れた

>俺は自分より出来る存在と戦ってみたいと思っている。
こう言ってるんだから、勝負したいだけだろ。
なにがしたいのかったら、それだけ。OOも実はどうでもいいの。
勝ちたいだけだから、別に学習しなくてもいい。つか学ぶ気ナシ。
「出してみろ」「教えてくれ」を字面どおりとってはだめ。ただの挑発。
残念だが勝負の相手は393くらいしか無理。がんがれ。

つ KY

弱いからこそ俺TUEEEEEしたい
という見本か

>>295
＞俺は名詞から抽出しない、別の方法を使っている、
＞メジャーじゃないがなかなか良い!!
なかなか良いなら参考にしたいんで、もうちょい具体的に説明頼む。

根本的な話だが、
ユースケース図はいつ出来上がるんだ？

>>300
見識ぶった言いかたをしたかっただけで、実際はそんな大した方法じゃないと思うよ。
>>295
「商品の新作・準新作・旧作」が入荷日からの判定でまずければ、レンタル開始日からの
判定とか、新旧フラグとかで判定すればいいんじゃねぇの？　でもこれって、仕様の話で、
OOとはあまり関係ない。

>>278
もう少し社会人としてまともな回答があると思ってたが、
それをお前に求めるのは無理があったようだ

>店員--（DVDを貸し出す）-->システム
とりあえずここ、97にシナリオあるじゃん
んで、99〜100あたりにクラスが

>>295
とりあえず、個人会員、家族会員、法人会員の違い（何ができて、何ができない？）だけでも説明してくれ。
過去ログに見当たらないんだが。つか、要件決めないで、よく設計なんてできるな。
まぁ、お前の頭ん中では完結してるんだろうが、こういうことは明示しとかないとデスマの元だからな。

>>305
誰が質問していいと言った？
末端のコーダには知る必要も資格もない
黙って俺たちの考えたとおりに作ればいいんだよ

とかいうキャラを393氏に望むのはちょっと無理かな

>>285
>>OO分析設計は分析設計初期開発段階で保守段階の変更の可能性を十分に検討し尽くす
>はっきり言っておくと、これは間違いだ。
>中略
>初期開発コストは増大するが2倍にはならない。ソースコード換算だと構造化に比べて約1.2倍程度だ。
248で言っているが、議題の前提条件が間違っているので、そのあたりに関する議論は意味がない。
次に誰かが言っていた、改修時の変更が容易だというのは同意だし、俺がオブジェクト単位で変更が容易
と言っている所から読み取れると思う。また大変更があった場合に対処が大変だというのは、
構造化に比べて約1.2倍と言っているので、作り直した時の影響度も読み取れるだろう。
ちなみに、客の要求が全然違っていた場合の対応を、OOでカバーしようと言うのは問題外だと言うのは
同意だし、そのあたりは他の人の意見で決着がついているように見えた。
つまり議論の大半が的外れで、それについても数人の指摘で決着がついていたので参加しなかった訳だ。

オブジェクト単位で変更が容易に設計するのが大変だと言っている様に見えるのだが・・・。
おじゃばは、他人の保守や改修の経験ないが無いやり捨てＳＥ？

>>308
大規模開発の経験もないみたい。ちっちゃなとこで自分だけがお山の大将してんじゃね？

しかしなんだな
OOをちゃんと理解していないとOOの利点を生かせないとなると
大規模開発ではちゃんと理解していないSE/PGが一人でも混じっていたらアウトということになる
派遣や偽装請負が盛んなこのご時世に背信者を完全に排除するのは無理のような気がするが

>>290
前にも書いたが、ユースケース図からクラス図を作る方法は分からない。
俺はユースケース図は要求仕様をまとめるだけの物と思っていたが、違うと言っている名無しがいるので
検証している。

>>291
前から言っているが、ユースケース図からクラス図が作れるのかを見たい。
ダメなら別の方法でもいいから、俺の抽象化以外の方法で、クラス図を作る方法が見たい。

>>292
教えてください、お願いします。つまらないプライドはありません。

>>311
嘘くせぇよｗ、つか嘘もそこまで図々しけりゃ大変なもんだ。
みんな言ってるけど、何したいんだお前？こんなとこで勝負してるヒマあったら
本なりネットなりで勉強すればいいじゃん。お山の大将だから勝負したいだけだろ？

>>307
的外れはお前。
つーかOOを何一つ理解せずにOOを語ろうとするな。
このクソ荒らしが。

>>295
DVD、会員、レンタルを抽出した方法が分からないので、コメントが難しい。
ユースケース図とは関係ないと言う事だな。本人も抽出方法は認識していないように思える。
手順を明確化しないと本人しか出来ないので、分析してみる。
システムは、「会員」が「DVD」を「レンタル」する物との認識で、「誰」が「何」を「どうする」で
抽出したのだろうか？それぐらいしか思い当たらない。

次にクラス図を見てみよう。
まず、抽出された会員、DVD、レンタルの使われ方が良く分からない。
会員はすでに分割されているし、DVDは要素のひとつに追いやられている（レンタル商品に変わった？）し、
レンタルはレンタルするになった（？）ようだ。イマイチ抽出したのかな要素との関連が不明だ
次に、俺の考えていた仕様では、ツタヤの店舗貸しを想定していたので、ゴールドカードも、
家族会員もない。ビデオも捨ててDVDのみにしたと思うし、料金も通常料金と特別料金の分類で
ツタヤの料金体系を表現出来るのか謎だ。電話と住所を分けた理由も不明だ。俺は延滞時の連絡先
を想定していたが、別の用途を想定しているのか？
つまり、ツタヤの店舗レンタルとは全く別物に見える。
ツタヤレンタルではなく、295の考えるオリジナルレンタルを想定しているのか？
それともツタヤレンタルをベースに、今後考えられる拡張を想定して設計したのか？
どうも関連や目的が掴みにくくて、コメントが難しい。

ボケるならちゃんとボケろ、つっこむなら上手くつっこめ、あ゛ーイライラする、この馬鹿コンビ

空気読まずに暇つぶしの結果を投下。

>>148のユースケースを4つぐらいあわせて機械的に分析してみた。
http://www.uploda.org/uporg1363351.zip.html

実務でこんなやり方はしないケド。

原田ウイルス入りとか
舐めてるなｗ

* バウンダリ
* エンティティ
* コントロール
が、いろはのい
だよ

>システムは、「会員」が「DVD」を「レンタル」する物との認識で、「誰」が「何」を「どうする」で
>抽出したのだろうか？それぐらいしか思い当たらない。

またロバストネス厨か

ユースケース図とユースケース記述は違うと何度言ったら(ry

も前さんは見出しタイトルだけ見て内容が分かるエスパーかw

おじゃばが、
ユースケース図 →　ユースケース記述 （→　ロバストネス分析） →　クラス図
でなく、
ユースケース図 →　クラス図
と思いこんでるのはもはや確定。まさかと思っていたが。
というか、こんだけ指摘されてもまるで気づかないバカさ加減にうんざりする。
おじゃばの頭の中は、「ユースケース＝ユースケース図」 という観念で凝り固まっているのだろう。

訂正。
どうやら、おじゃばは
「ユースケース＝ユースケース図＝ただのお絵書き」
と思っている節がある。要求分析を完全になめてる。

>>322
なめてる、ってかコーディングからはじめちゃって他のヤツより仕事早いぜすげぇだろ俺、
とかマジで言うバカ丸出しのヤツがそんなもん理解できるワケねぇだろ。高望みするなよｗ

おじゃばがバカ理論を展開しながら偉そうに、「まず」とか「次に」とか
書く度に俺のイライラ具合は次第に最高潮に達していく。
「熱くなった方が負け」なのは分かっているんだが。

気持ちはわからんでもないが・・・
こーゆータイプの人間はウザいしな

接続語があるがゆえに一見それっぽい文章なくせして
全て根拠のない自信を拠り所にしてるため
まともなところがひとつもないのが特に手に負えない
つーか接続語の使い方も滅茶だし
挙げ句妄想だけで話を進めておきながらわからないヤツが悪いと来る
所謂キチガイなんでしょうな

・妄想なのに勝ち気
・自分が理解できないと罵倒する

とにかくおじゃばは最低レベルの人間

245 ：>168：2008/04/09(水) 01:07:15
>で、ユースケース記述を書くとクラス図が出来るのか？
>ユースケース図ですら関係無さそうなのに、ユースケース記述はもっと関係ないのではないか？

ユースケース図、って単なる見出しでしかないだろ？
そのユースケースにおいてシステム(=たいていは複数のオブジェクトの連携)が何をするのかを書き出さなきゃ
話はそれからだ


246 ：245：2008/04/09(水) 01:12:38
ついでにいうと ロバストネス図≒概念クラス図 がユースケースから作れる

> >>245,246
> つーか、自分では書けないのか？

完全スルー。

>>327
おじゃばは自分でわからないことはそうやって挑発するから、
余り指摘するような親切はしないほうがいいだろ、
それしたって、そうだったごめんとは言わないから。
キチガイを論理的にやりこめようとするのは無駄なことだし。

くやしぃのう

だから、>>1にあるようにスルー技術を、だな。
どうしてもむかついたらキチガイ乙、とでも書く程度のがいいんじゃまいか。

>>300 >>302見たいな奴がいるから書かない
>>301 >>148が書いていたが
>>302
>「商品の新作・準新作・旧作」が入荷日からの判定でまずければ、レンタル開始日からの
>判定とか、新旧フラグとかで判定すればいいんじゃねぇの？　でもこれって、仕様の話で、
>OOとはあまり関係ない。
オブジェクト指向の話をしているんだが、なんで構造化なんだ？分かっているか？
「仕様の話で、OOとはあまり関係ない。」仕様をどうモデリングしてシステムに組込むか、を話しているんだが．．．
>>308　それは最初は、>>127の話か？それなら、「博士号」が間違っているが
>>311 業務知識も無く、いきなりユースケース「図」だけ渡されても概念クラス図は完成出来ないが、誰が言ったんだ？

>>314
>DVD、会員、レンタルを抽出した方法が分からないので、コメントが難しい。
>ユースケース図とは関係ないと言う事だな。本人も抽出方法は認識していないように思える。
概念クラスの抽出方法と言うことか？簡単に説明するが自分で勉強しろ
まず、初期段階にはユースケースが必ず必須と言う訳では無い『手法』による
（自分が知っている手法だけが正しいと思っている奴が多すぎる）
今回の「DVD」と「会員」は、『もの』として抽出した
これは何でか分かるよな？、レンタル店業務を『もの』『こと』で分類した場合『もの』は「DVD」と「会員」となる
その「DVD」・「会員」の関連として「レンタル」を抽出した、ここまでが静的モデルになる

>会員はすでに分割されているし、DVDは要素のひとつに追いやられている（レンタル商品に変わった？）し、
拡張を想定して作ってある、実装はしないが拡張を想定して分析・設計した方が良い（この段階ならコストもあまり掛からない）
将来「Blu-ray Disc」などが追加されても、このモデリングなら一商品が増えるだけだから、修正コストも軽減できると思うが

わはは、がまんできねぇででてきやがんのｗ

プロジェクトが妄想なら顧客もいないわけで
モデルが正しいかどうか誰がどうやって決めるんだろう

>>333
本人が決めるんだろ。本人が設計して、本人が正しいかどうか判断する。
お気楽、極楽。くだらんお遊びだな。

聖火ゲームの仕様
つくろうよ

>>391
「仕様をどうモデリングしてシステムに組込むか、を話しているんだが」

だからその仕様の話をちゃんとしてくれよ。お前の頭の中にあるレンタル業務
での「家族会員」、「法人会員」、「ゴールドカード」の要件をちゃんと説明
してくれよ。それがわからなきゃ分析しようもないだろ。それぐらい分からんか？
まるで馬鹿な客か素人を相手にしてるようだ。俺たちゃエスパーじゃねぇっつうの。

>>391 に期待

来るよエスパー

待たせたな私が>>391だ。そして私はこのスレの>>331であり。またの名は前スレの393でもある。

では続けてどうぞ↓

なんだバカか。

>393
なんでそんなに相手をイラつかせるような書きぶりをするの？

>394
ですね、わかります。

>395
それは違うだろ

>>317
JPEG17枚zipで固めただけで原田扱いﾋﾄﾞｽ・・・
か、入れたつもりないけど、マジでどっかでウィルス混入してた？
だったらｽﾝﾏﾍﾝ。

>>344
博士、最低

>>312
嘘つきはお前だろう。クラス図の書き方を教えてくれるのではなかったのか？

>>313
いくら本を読んでも、実務経験が少なくて本の内容を実感出来ないと、筆者の意図と違った解釈をする。

>>316
テキストでここに書いてくれ。

>>318
なぜここでバウンダリーとエンティティーが出て来るのか分からない。

>>320-328
だから俺の書いたユースケース図に対して、全てのユースケース記述を書けというのか？
膨大な量になるぞ。それに誰かの書いたユースケース記述には、数を-1するとかあったが、
数をどこに持つのかもも決まってないのに、そんなの書けないだろう？
大体、オブジェクト分割がされてないのに、複数のオブジェクトの連携をどうやって書くのだ？
270の簡単なユースケース図からも、どれぐらいの詳細度で書けばいいの分からない。
だから、327が書いてくれ。

キチガイ乙

できないことを丸投げしておきながらなんでこんな態度になるんだろ

>>346
氏ね。

>>346
＞テキストでここに書いてくれ。
断る

>>331
「もの」と「こと」で分類して、「もの」を抽出した後に、その「もの」たちの関連（？）を抽出するのか？
いまいちよく分からないな。業務を日本語にして、そこから抽出したのか？
それだと人によっては、かなり違った抽出になると思うが。
デパートの売上管理とかだと、客、商品、とかなるのか？店員や売り場はどうなる？
銀行の預金システムだと、客、金か？普通預金とか定期預金とかの種類はどうなる？

クラス図は拡張を想定して作ったのか？この段階ならコストも低く抑えられる？
DVDのレンタル商品化はいいとしても、ゴールド会員や家族会員のシステムは高くつくのではないか？
実際に必要とも思えないし。大体、どういう会員システムなのか分からないな。
内容も生年月日が複数の所にあったり、メンバーとレンタル会員と会員カードが別れていたりと、
俺には到底理解出来ない構造だ。誰かが言っていたが、会員の種類によって何が変わるのかさっぱり読めない。
料金が変わるのか？ポイントが共有出来るとかか？携帯電話とクレジットカードが混じってないか？
第一、OOとは抽象化して変更を容易にするシステムだ。レンタル会員を会員として抽象化して実装するのは
いいとしても、ゴールド会員とか家族会員とかまだ必要ない物を特化して実装する意味があるのか？
ちなみにこの先、どう変更すればいいのかは分からない。俺が無理なので多分誰でも無理だろう。
きっと、331がやるしかない。クラス図完成させてみてくれ。

・まず日本語がおかしい
・頼むなら下手に出ろカス
・質問事項の合間にある「思う」の理由を書け

はい、再提出。

レンタルシステム程度のユースケース記述が膨大とか、今までどんなもん作ってきたんだよ。
おじゃばは「腹が減ったが箸は持ちたくない。口元まで運んでくれ」と言ってるようなもの。

OOのプロジェクトってOOでの設計・開発経験者じゃないと敷居高いでしょ。

自分で本読んで勉強しましたって言っても、実務じゃないもんなぁ

＞内容も生年月日が複数の所にあったり、メンバーとレンタル会員と会員カードが別れていたりと、
＞俺には到底理解出来ない構造だ。
うｐされてたクラス図保存して無いんで確認出来ないんだが、
コイツ、クラス図読めてないんじゃ無いか？


まぁ393のクラス図もどう分析した結果なのか
良く分からなかったと思った憶えがあるけども。

>>351
こいつもう駄目じゃね？

どっちにしてもDVDレンタルなんて今どき儲けの主力じゃないから
どうでもいい業務のIT化のために命削ってる奴らがいると思うと
無理な仕変を要求してストレス解消したくなる気持ちも分からなくもないか・・・な？

>>351
>「もの」と「こと」で分類して、「もの」を抽出した後に、その「もの」たちの関連（？）を抽出するのか？
>いまいちよく分からないな。業務を日本語にして、そこから抽出したのか？
なんて説明すれば分かるんだ？テーブルの「マスタ」と「トランザクション」と言えば分かるか?

>それだと人によっては、かなり違った抽出になると思うが。
もちろん違うが間違いとも言えない、正解は多数あるからな

>デパートの売上管理とかだと、客、商品、とかなるのか？店員や売り場はどうなる？
デパート売上管理のシステムが分からないから推測だが
「店舗」「フロアｰ」「販売員」「商品」なんかが「もの」(マスタ)になると思う
>銀行の預金システムだと、客、金か？普通預金とか定期預金とかの種類はどうなる？
これもは、「預金通帳」「本店・支店」とかが「もの」(マスタ)になると思うが

>クラス図は拡張を想定して作ったのか？この段階ならコストも低く抑えられる？
>DVDのレンタル商品化はいいとしても、ゴールド会員や家族会員のシステムは高くつくのではないか？
>内容も生年月日が複数の所にあったり、メンバーとレンタル会員と会員カードが別れていたりと、
>俺には到底理解出来ない構造だ。誰かが言っていたが、会員の種類によって何が変わるのかさっぱり読めない。
>料金が変わるのか？ポイントが共有出来るとかか？携帯電話とクレジットカードが混じってないか？
「ゴールド会員」「家族会員」「ビデオ」は実装しないし、仕様にも無い
しかし、違った角度のクラスを導入し将来のクラス拡張を考えるのはいい事
今あるクラスだけで拡張性を考えても、なかなか上手く出来ないが
「個人会員」と違う「団体会員」を考える事で汎用性のあるクラス図に成っていく
これは俺のやり方だから、違和感があるなら、その部分は見るな
と言うか、お前らも書け

意味の無い長文をどれだけ意味ありげに書けるかを競うスレはここですか？

>>359
永遠にノレンに腕押しするスレです

>>346
＞だから俺の書いたユースケース図に対して、全てのユースケース記述を書けというのか？
＞膨大な量になるぞ。
RUPじゃ書くんだよ。
ユースケース10や20は全然膨大じゃないが(メンドクサイけどな)
練習でやるには多いと思うなら、ユースケース削れ。機能を削れ。
ちなみに俺はオブジェクト指向開発プロセスはRUPしか知らんので、あしからず。
他のプロセスについては、むしろ俺が聞きたい。

＞どれぐらいの詳細度で書けばいいの分からない。
>>270ぐらいだったら単純なもんだろ。
この程度のルールでメインフローだけ書いてみ。
[ルール]
1. 「(通し番号). 店員(またはシステム)は〜〜を〜〜する」という形式で書く
2. ユースケースの通し番号1は店員、システムのどちらから始めても良い
3. 動詞は、番号1つにつき基本的に1つ。多くても2つ
4. 店員から見えることだけを書く

> 318 ：>314：2008/04/12(土) 01:14:50
> * バウンダリ
> * エンティティ
> * コントロール
> が、いろはのい
> だよ
>
> >システムは、「会員」が「DVD」を「レンタル」する物との認識で、「誰」が「何」を「どうする」で
> >抽出したのだろうか？それぐらいしか思い当たらない。
>
> 346 ：おじゃばさま ◆GxjxF3yEw6 ：2008/04/14(月) 09:57:05
> >>318
> なぜここでバウンダリーとエンティティーが出て来るのか分からない。

...店員が"バウンダリ"を使うことで、"コントローラ"「レンタル」を生成し、それは"エンティティ"「会員」「DVD」とひもづく
とか説明があればいいんですか？ ＞＜

ロバスト房の言うことにマジレスいくない

>>358
すまんが分からない。
デパートと銀行の例を見た限りでは、少なくとも俺は358と同じ抽出は出来ないと言う事は分かった。
抽象化のために別の観点から見るのは分かったが、358やUML厨のやり方でクラス図を書くのは無理だ。
仕方ないので、俺のやり方で書いて見る。前に言った通り、設備から業務を抽象化する方法だ。
レンタルシステムはDVDを会員に移動する事によって、業務が発生するシステムだと考える。
包含関係は以下の通り。
------------------
レンタルシステム
　ショップ
　　DVD...
　　料金表
　会員...
　　DVD...
　倉庫
　　DVD...
------------------
「...」は複数存在するリストのような物と言う意味。
レンタルシステムはショップ、会員リスト、倉庫から出来ている。
ショップはDVDと料金表から出来ているとする。

次にクラス化。とりあえずクラスと管理する要素を書いて見る。
-------------------------------
class ショップ{
　DVDリスト、料金表
}
class DVD extends 作品{
　シリアル番号、作品番号、入荷日
}
class 作品{
　タイトル、ジャンル、年令制限、発売日、レンタル開始日
}
class 料金表{
　期間、金額
}
class 会員{
　DVDリスト
}
class 倉庫{
　DVDリスト
}
-------------------------------

次に足りない要素を追加してみる。
前述の構成では現在のDVDの場所は分かっても、過去の貸し出し履歴は分からない。
class 貸出履歴{
　シリアル番号、会員番号、貸出日、返却予定日、返却日、料金、延滞料金
}
次に貸し出し業務の動作をメソッドとして追加する。
貸出、返却、入荷、廃棄はレンタルシステムに、入会、更新、脱会は会員に持たせる。
貸出履歴には、登録、検索を持たせる。あとは適当に加えて完成とする。細かいメソッドは省略する。
-----------------------------------------------------------------------------------------------
class レンタルシステム{ショップ、会員、倉庫：貸出()、返却()、入荷()、廃棄()};
class ショップ{DVDリスト、料金表};
class DVD extends 作品{シリアル番号、作品番号、入荷日、貸出日：検索()};
class 作品{作品番号、タイトル、ジャンル、年令制限、発売日、レンタル開始日：一括登録()、検索()};
class 料金表{期間、金額：料金算出()、登録()、更新()、削除()};
class 会員{会員番号、DVDリスト：入会()、更新()、脱会()、延滞検索()};
class 倉庫{DVDリスト：入庫()、出庫()};
class 貸出履歴{シリアル番号、会員番号、貸出日、返却予定日、返却日、料金、延滞料金：登録()、検索()};
-----------------------------------------------------------------------------------------------

>>361
面倒だがやってみるか。本当にクラス図に出来るのだろうな？
----------------------------------------------------------------
店員--（DVDを登録する）-->システム
01.店員はDVDの情報を入力する。
02.店員は登録ボタンを押す。
店員--（DVDを削除する）-->システム
01.店員はDVDの一覧を表示する。
02.店員は一覧から削除するDVDを選択する。
03.店員は削除ボタンを押す。
店員--（DVDを貸し出す）-->システム
01.店員は会員からDVDと会員証を受け取る。
02.店員は会員証が有効かをチェックする。
03.店員は会員から貸し出し期間を聞く。
04.店員はDVDを貸し出し登録する。
店員--（DVDを返却する）-->システム
01.店員は返却ボックスからDVDを取り出す。
02.店員はDVDを返却登録する。
店員--（会員を登録する）-->システム
01.店員は会員から必要書類を受け取る。
02.店員は会員の情報を入力する。
03.店員は登録ボタンを押す。
店員--（会員を削除する）-->システム
01.店員は会員の一覧を表示する。
02.店員は一覧から削除する会員を選択する。
03.店員は削除ボタンを押す。

ここ３スレほど見てるが
何がおじゃばをここまで駆り立てるのか全く理解できない

俺もこうなんというかうまく言えないんだが、おじゃばって、素質が無いんじゃなかろうか。

>>367
ごめん。
おじゃばがソコまでユースケースについて知らなかったとは思ってなかった。

ユースケースは「アクターとシステムのやり取り」を書くものなんだ。
アクターとアクターのやり取りとか、アクターがシステムと関係なく行う行動とかは書かないんだよ。
例えば
＞03.店員は会員から貸し出し期間を聞く。
とか
＞01.店員は返却ボックスからDVDを取り出す。
とか。

それと、>>367のフローだと、システムは店員に対して、一切動かないことになる。
システムが主語の文が無いから。
店員が操作しても画面は全く動かなくて、システム内部では何がしかの処理が行われている、
そういうシステムを想定してるなら、ユースケースとしてアリだとは思う。
が、多分対話的に動作することを想定してると思うので、
「客は〜〜」「システムは〜〜」が必ず交互になるように書いてみると、
ソレっぽくなるかもしれない。

例えばこんな感じ
店員--（DVDを削除する）-->システム
01.店員はDVD一覧表示ボタンを押す。
02.システムはDVDの一覧を表示する。
03.店員は一覧から削除するDVDを選択する。
04.システムは選択されたDVDを表示する。
05.店員は削除ボタンを押す。

単純に自分が間違っていないという前提に立っているだけだろう。

正しいからその論理に則るというが常人だが、自分が正しいから
その倫理が正しいというのがおじゃば。

>>370
おじゃばに教えてやっても無駄だよ。教えたとおりに解釈しないし。無限ループのもとだよ。
おじゃばに教えるのは、馬の耳に拡声器で念仏を唱えるよなもんだよ。後ろ足で蹴られるよ。

このスレの状況

while (true) {
if (おじゃば->set知識(名無し->知識) == ERROR)
continue;
}

店員--（DVDを登録する）-->システム
01.店員はDVDの情報を入力し、システムに登録を指示する。
02.システムはDVDの情報を保持する。

店員--（DVDを削除する）-->システム
01.システムは店員の指示に従ってDVDの一覧を表示する。
02.店員は一覧から削除するDVDを選択し、システムに削除を指示する。
03.システムはDVDの情報を削除する。

店員--（DVDを貸し出す）-->システム
01.店員はシステムに会員証の情報を入力する。
02.システムは会員証が有効かをチェックする。←どんなルール？あと貸し出し限度とかあるのでは？
03.店員システムにDVDの情報と貸し出し期間を入力する。←タイトルによっては期間に制限があるとか？
04.システムはDVDの貸し出し情報を保持する。←料金計算が必要だろ？

店員--（DVDを返却する）-->システム
01.店員は返却DVDの情報をシステムに登録する。
02.システムはDVDの返却情報を保持する。←ここは、貸し出し情報とつき合わせる必要があるし


こんな感じでおｋ

おじゃばがユースケース図と言って書いてるものは、アクティビティ図もどき
UMLでは「ロールがアクティビティをする」という言い方になる

アクターとユースケースは事前に客からヒアリングした結果から導き出したアクティビティ図から抽出する
ユースケース図より、システムの境界を判定する

そのあとにコンポーネントの抽出を行う
おじゃばに分かるように言えば、コンポーネントの組み合わせでユースケースが実現されているってこと
商品管理だとか販売管理だとか顧客管理だとかだな

コンポーネントのつながりを表すのがコラボレーション図
当然アクターもコンポーネントとして表現できる
店員　―　在庫管理　みたいな感じ

ここからシナリオの抽出になるんだが、
教えてほしければ「教えてください」と言え

おじゃばはUMLが不便なものだと言いたげだが、
そんなに不便なものではないし、
己の知識不足の八つ当たりにしか見えない

>ここからシナリオの抽出になる

いや違うなw そこじゃない
>ユースケース図より、システムの境界を判定
の次でおｋ
コンポーネント、コラボレーションはその後で

>376
374じゃないけどそれは変だろ
どこでインターフェースの抽出を行うんだ？

いんたーふぇーすなんてもっと詳細化してからじゃまいか？
ユースケースて概要レベルでそ？

あ、377のいうインターフェースって対ユーザなのかな？
だとすると「シナリオと同時に」

おいおい
まさかクラス図からインターフェースをひっぱりだすとか
おじゃばみたいなこと言うつもりじゃないだろうな？

>クラス図からインターフェースをひっぱりだす
一緒もしくはインターフェースが先では内科医？

>381
クラスと一緒ってのはないな
アクターからコンポーネントとかコンポーネント間の接続がインターフェース
レンタルシステムでいえば、こんな感じ
アクター：店員→インターフェース：「在庫を確認する」→コンポーネント：在庫管理

>375が書いてるシナリオってのはインターフェースに着目してからのことだと思う
今までの流れだとおじゃばはそこが分かってないからあえて書いてないのかも
なので俺も書かないｗ

＞ttp://java-house.jp/ml/archive/j-h-b/020739.html#body
＞からの流れで高木さんにフルボッコにされた、あの萩本順三か。

おまえ見る目がない。
H氏の対応は大人的で、技術的にも正しい事言っていたぞ。

結局おじゃばはユースケースを理解してなかったんだな。いつものオレ解釈だったんだな。やれやれ。

よく分からないことは、分からないです。で十分なわけだけどねー。

>>370
だから、俺はユースケース記述とか、他の図が書きたい訳ではない。見たいのはクラス図だ。
店員とシステムが交互になるなら、読む時に自分で補完して解釈してくれ。
で、ここから概要クラス図とか言うのが作れると言う話だが。作ってくれ。

>>375-385
話が通じないのはオマエラだろう。俺は別にUMLの図の説明が聞きたい訳ではない。
クラス図を作ってくれと言っている。書き方が分からなければ、366の形式でいい。
第一、UMLの用途と問題点については、過去スレで何度も書いている。また俺に説明させたいのか？

何のためにクラス図がみたいんだっけ？

これだからコーダは困るよ。

やっぱり無理か。オマエラ全員正座な。

よくわからないんですが、ＤＢ使わない縛りなんですか？
ＤＢ使うとおじゃばとか言う人のクラス図は使いたくないって感じなんですが。

>>386
作ったが。
http://www.dotup.org/uploda/www.dotup.org19684.jpg.html

やっぱ367じゃシステムの振る舞いがさっぱり見えないわ。
ユースケースがショボすぎて、まともな図にならなかった。
ホントは分析を反復して、ユースケースともども修正していくんだけどな。

>>386
よほどUMLを理解した自信が有るようですね。

な、後ろ足で蹴られただろ。おじゃばを相手にすると知能が吸い取られるからやめとけ。

おじゃばはクラス図が欲しいとかいってるが、この調子じゃクラス図の見方もろくに
知らないんじゃないか。
>>386がせっかく作ったクラス図みても、これが正しいのかわからんだろ。だから、
自分のユースケース記述がいかに間違いだらけで見当違いなものかということにも気づ
かんだろ。もしこれで奇跡的に自分のバカさ加減に気づくことができたら、おじゃばは
>>386に感謝した方がいいな。

あ、まちがった俺が馬鹿だ。↑は>>386じゃなくて、>>391ね。

とりあえず、一人でクラス図を作ってみる
前に質問した「商品の新作・準新作・旧作」を考えて行く
まず『汎化』する、ここまでは定石だから分かると思うが
http://www.dotup.org/uploda/www.dotup.org19898.jpg

しかし、この関連では一つの商品に対して関連付けられているが
実際のレンタル店ではタイトル別に新旧を決めているから
商品の『カテゴリー化』が必要になり、これに新旧状態を関連付けると
http://www.dotup.org/uploda/www.dotup.org19899.jpg
こんな感じになる

>>396
あ・・・ありえねぇ・・・。
まずそもそも新旧状態はまだ属性だろ。
新旧状態が何かしら属性や操作を持つことが判明してからクラスにするべきじゃね？
けどまぁ1つ目の図はまだわかる。

でも2つ目、明らかにおかしいだろ。てか、意図が全然見えない。
「レンタル商品」に「タイトル」属性があって、
さらに「ビデオ名」「DVD名」クラスが存在した上属性に「タイトル」がある。
意味が分からん。
DVD名とビデオ名を分けた理由も分からないし、汎化したクラスは出て来ないのか？
DVD名とDVD、ビデオ名とビデオに集約が無いし、
2つ目の図は一体何が言いたいの？

新旧がタイトルに付随してることを強調したいなら、
「レンタル商品」の属性から「タイトル」を削って(てかクラスにする)、
「レンタル商品」と新しく作った「タイトル」クラスを集約で繋いで、
「タイトル」クラスに「新旧状態」を集約すべきじゃねぇの？
タイトルの無いレンタル商品が今後出てくるのか？
それとも、DVD名とビデオ名で何か違うの？

まぁ前提の「新旧がタイトルに付随してること」自体ビミョーだと思うけど・・・。
新作か旧作かはタイトルによらず商品で決まると思うんだがな。
別の商品でたまたまタイトルが同じ商品だとおかしくなる。
それかもしくは「〜〜名」クラスが、すでにクラス名として正しくなく、
DVDやビデオの名前以外の何かを表しているのかもしれない。

うー・・・言葉で書いてもうまく説明できねぇ。
長文スマン。

>>390
OOなので記憶方式には依存しない。つまり、例えば「会員」オブジェクトがあったとすると、
要素（会員番号、DVDリストなど）が管理出来て、動作（入会、更新など）が実装出来る物なら、
DBだろうがファイルだろうが、社会保険庁のDBだろうが記憶力のいいバーテンだろうが、何でもいい。
ただ今回の場合は、メソッド実行の度に、複数または1つのテーブルを検索に行く方式になるだろう。

このようにオブジェクト単位で、変更が容易なのがオブジェクト指向の特徴だ。
作品オブジェクトを外部のDBにするのも簡単だろう。しかし、この時点でパフォーマンスや構造が問題になる
事もある。その場合はキャッシュ機能を組み込んだり、人によってはデザインパターンを参考にしたりする。
ただ、390も分かっていると思うが、ビデオレンタル程度なら>>160で作ったテーブルに対して、
処理を行うプログラムを作った方が早い。

みんな、よけいな口出ししないでおじゃばと393にまかせたらいいのに。
きっといいものできると、思うﾌﾟよ。

>>391,394,396
俺のユースケース記述が見当違いだから391になった？システム側の記述がないなら付け足せばいいだろう。
391のクラス図が正しいか分からない？一目見れば間違っているのは分かる。
391は間違いだが、396の方は無茶苦茶だ。397が混乱するのも当然だろう。
391、396は何をOOと言っているのか分からないが、基礎が全然違う。
オブジェクトというのは、「状態（情報）を保持し、動作を提供する」物だ。
構造化で以下の処理があるとする。構造化の場合は状態と動作の関連がない。
------------------------------------
DVD登録()、DVD更新()、DVD削除()、
会員登録()、会員更新()、会員削除()
------------------------------------
OOだと以下になる。状態はクラスを構成する情報と考えてもいい。
------------------------------------
class DVD{DVD状態、登録()、更新()、削除()}
class 会員{会員状態、登録()、更新()、削除()}
------------------------------------
なぜこうするのかの目的とか利点は、398に書いた通り。つーかこれ基礎なのだが。

ところで、同タイトルのDVD複数ある場合が普通なので在庫数と出荷数と延滞数とかも
加えないといけないと思うのもれだけ？
漏れ、商店や倉庫関連のアプリ組んだ事一回しかないけど、在庫数と出荷数を
作らないクラス設計ってありなの？

VDのタイトルと在庫管理は別にしないと冗長になると思うんだけど。
DB使うんならおじゃばのはアリでも良いけど、メモリやExcelなら簡便だな〜。

結局Excelでちまちま帳票作ったのが一番安上がりで確実で汎用性も高いってことでFAなのか・・・
現場はバーコード管理でコード入力の手間を省くだけで全然満足なんだよな・・・

おまいらお払い箱だpgrpgrpgr

>>398
>このように〜変更が容易
どのように？なんら事例なり根拠がないのに「このように」とか書かれても分からんよ。
>DBだろうがファイルだろうが
ってことはオブジェクト指向でなくてもいいだろうし...

おじゃばはなんでどうでもいいような低レベルの話をまるで自分だけが知っている高度な話のようにくどくど書くんだろうな。次元が低すぎるから話が噛み合わないんだろうな。

>>400
> ------------------------------------
> class DVD{DVD状態、登録()、更新()、削除()}
> class 会員{会員状態、登録()、更新()、削除()}
> ------------------------------------

全然違う。
なんでDVDが、自分自身がどう管理されてるかを知ってるんだよ？

------------------------------------
class DVD{DVD状態、更新()}
class 会員{会員状態、更新()}
class DVD一覧{登録()、削除()}
class 会員一覧{登録()、削除()}
------------------------------------

＞オブジェクトというのは、「状態（情報）を保持し、動作を提供する」物だ。
モジュール指向の機能モジュールと、どう違うんだ？

おじゃばは多分OOPも分かってない。
OOPLの機能を便利に使ってるだけだ。

おじゃばのOOの理解は、
構造体に変数と関数をパッケージ化できて、アクセス制限がつけられて、再利用できる。
って程度のもんだろ。多分本質はなんもわかってない。
くどくどと初心者レベルのくだらない説明を得意気に語っているところをみてもそんな気がする。

おじゃばさまにクラスベースとプロトタイプベースのどちらが好みか聞いてみたい。
あと、多重継承よりミックスインを断固支持するかとか、ジェネリックプログラミング
とOOの両方が適用できる場面でどちらの方法を重要視するかとか、その判断基準とか。
まぁ、なにがなんでもOOがベストってわけじゃないのは常識だよね。ダイナミックバイ
ンディング使うよりCase文でさらっとやっちゃった方がお手軽だし。その辺、おじゃば
さま的にはどう思うわけよ？　OOは好きなのか？ 得意の演説ぶちかましてくれよ。

>>400
＞391のクラス図が正しいか分からない？一目見れば間違っているのは分かる。
どこが間違えてる？

>>397,400
長文だから一応説明するが、レベル的に分かるかが心配だ
>あ・・・ありえねぇ・・・。
>まずそもそも新旧状態はまだ属性だろ。
>新旧状態が何かしら属性や操作を持つことが判明してからクラスにするべきじゃね？
ここはモデラーなら基礎だと思って説明を省いたが、分からないか．．．
まず、新旧状態はレンタル商品の要素だ、このように状態を持つ場合
状態をクラスで表現するのが定石になる、詳しく説明するのも疲れるから『状態(STATE)パターン』を勉強してくれ
（こんな当然の事も「ありえねぇ」とか「無茶苦茶だ」とかは、こっちが「ありえねぇ」と思うが、素人だと思って我慢するか）

>でも2つ目、明らかにおかしいだろ。てか、意図が全然見えない。
>「レンタル商品」に「タイトル」属性があって、
>さらに「ビデオ名」「DVD名」クラスが存在した上属性に「タイトル」がある。
>意味が分からん。
『カテゴリー化』を知っているか？　まっ知っていたら、こんな事は書かないか．．．
『カテゴリー化』は共通のカテゴリーを抽出してクラスにすること、例えば
「ハリーポッター・秘密の部屋」のDVDが複数のあったとする、システム上一つ一つのDVDで管理する場合と
「ハリーポッター・秘密の部屋」のDVDとして複数のDVDを管理したい場合がある、このような時DVDの『カテゴリー』をクラスで表現する
『汎化』とは関係ないから、『汎化』のタイトルと『カテゴリー化』のタイトルは同じ属性でもかまわない
分かるか？

もう、面倒くさくなってきた、後は明日書く（つもり）

新→旧の一つの状態遷移のためだけにstateパターン使うの？

>新旧状態が何かしら属性や操作を持つことが判明してからクラスにするべき
　↑
　↓
>状態をクラスで表現するのが定石

「ありえねぇ」

>DVD名とビデオ名を分けた理由も分からない
>DVD名とDVD、ビデオ名とビデオに集約が無い
　↑
　↓
>システム上一つ一つのDVDで管理する場合と
>複数のDVDを管理したい場合がある、このような時DVDの『カテゴリー』をクラスで表現する

「無茶苦茶だ」

>>407
気持ちは分からなくもないが、おじゃばはそもそもOOもジェネリックプログラミングも全く理解していないので、
その質問自体を正しく受け止めてくれないよ。
言葉のキャッチボール不可能。

こちらがどれだけ優しくボール投げても、おじゃばのマブタはアロンアルファでくっついているような状態。
こちらのボールは取る気無しだし、おじゃばからは四方八方にウンコが投げられてくる。

>396

おもくそ吹いた
コンポーネントが分からんｽｸﾞﾙ

>>392
392もUMLの本当の歴史を知れば、全部の図を覚えることがどれだけ馬鹿げた事かわかるよ。

>>401
レンタルの場合は同じ作品でもディスクが違えば別の人が借りるので、別々に管理が必要。

>>402
ツタヤでExcelは無理だろう。またExcelしかない銀行に金を預けたいと思うか？

>>403
このようにの例が分からない？その前に書いてあるだろう？
オブジェクト指向でなくてもいい？全然話が通じてないようだな。悪いが何故通じないのか分からない。

>>404,405
知っていたらあのようなクラス図にはならないんじゃないか？
あと確かに厳密に言えば405の方が適切かもしれないが、391の図はそうにもなってないだろう。
何で391にコメントしない？リンクだから見なかっただけか？

>>406
だって初心者レベルをクリアしてないだろう？

>>407
クラスベースが好み。多重継承反対。ジェネリックとOO？OOではなくてポリフォーフィズムの事かな？
それはジェネリックが使えればジェネリックだろう。
ダイナミックバインディングの代わりにcase文？WEBサービスのダイナミックバインディングと、
C構文のswitch〜caseを言っているのか？イマイチ分からないが、用途によるだろう。
少々質問が変だな。無理してないか？

>>408
貸し出し、返却など、機能でクラスが別れている所。

>>409
無茶苦茶だと言ったのは悪かった。俺には理解不能に訂正する。
理解不能なので、もしかしたら出来るのかもしれない。
とりあえずクラス図完成させてくれ。主要部分だけでもいいから。

>>412
>ダイナミックバインディング使うよりCase文でさらっとやっちゃった方がお手軽だし。
>その辺、おじゃばさま的にはどう思うわけよ？
これの意味が分からないから説明してくれ。

自分の無知ゆえに人にものを頼むときに
なんでそんな態度になるんだお前は

>>407 >>412 涙目ｗ　予言どおりになってるｗ

おじゃばにレスをするのがいかに無駄かってこと。
これは、今までどれだけの人間が指摘してきたか。

リンクだと見ない人がいるようなので、書いてみる。
まず391のクラス構成だ。適当に書いてみた。間違っていたら修正してくれ。
------------------------------------------
class DVD登録画面{実行()}
class DVD登録{}
class DVD削除画面{実行()}
class DVD削除{}
class DVD貸出画面{実行()}
class DVD貸出{}
class DVD返却画面{実行()}
class DVD返却{}
class DVD{DVD情報：貸出()、返却()}
class 会員登録画面{実行()}
class 会員登録{}
class 会員削除画面{実行()}
class 会員削除{}
class 会員{会員情報：取得()}
class 一覧{取得()}

修正する気も起こらん位・・・

次に396。こっちは途中から分からなくなったので、最初のベースのを書く。修正してくれ。
------------------------------------------------
class レンタル会員{名称}
class 会員カード{カード番号、有効期限}
class 通常会員カード extends 会員カード{}
class 団体会員カード extends 会員カード{}
class コールド会員カード extends 会員カード{}
class メンバー{氏名、生年月日}
class 電話{電話番号}
class 住所{郵便番号、住所}
class 個人会員 extends レンタル会員{}
class 団体会員 extends レンタル会員{}
class 法人会員 extends 団体会員{}
class 家族会員 extends 団体会員{}
class レンタル商品{タイトル、入荷日}
class レンタルする{貸出日、返却日、返却予定日}
class DVD extends レンタル商品{}
class ビデオ extends レンタル商品{}
class 料金表{}
class 通常料金表 extends 料金表{}
class 割引料金表 extends 料金表{}

おまいらの気持ちは今、ひとつになっていると思うｗ

もうなんつーかダメだな、このひと。

だろ？やっと分かってくれたか。

で？

>>414
>>398の前半は「方式に依存しない」の「方式」を羅列しているだけだ。
「変更が容易」の説明ではない。

でもって、「記憶方式に依存しない」「変更が容易」になるように意識すれば、OO以外でも可能だろう？
おじゃばの好きな構造化とかも、繰り返し研究されてきた成果じゃないのか？（まあ素人のおれには良く分からんが）
ことさら「OOならでは」みたいに主張する意味はないんじゃないか。

>>405
＞なんでDVDが、自分自身がどう管理されてるかを知ってるんだよ？

＞------------------------------------
＞class DVD{DVD状態、更新()}

これでも、自分がどう管理されてるか知っている、もしくは知らされている事になると思うんだけど。


>>406
本質ｵｼｴｰﾃ

これは．．．OOは普及しないな
おじゃばのクラスの実装はPL/SQLで実装すべき
間違ってもJavaで実装すべきではないな

おじゃば、とんだ道化だな。俺は決してお前が嫌いではない。
時として虚勢を張ってみせることも大事なことだ。しかし、...
人間には向き不向きがあるということもそろそろ学んだ方がいい。

おじゃばという生物は何故ここまで理解力が無いんだ？

>>430
ヒント：そういう指摘さえ、煽りと受け取るため。

>>414
>レンタルの場合は同じ作品でもディスクが違えば別の人が借りるので、別々に管理が必要。

>class DVD extends 作品{
>　シリアル番号、作品番号、入荷日
>}
>class 作品{
>　タイトル、ジャンル、年令制限、発売日、レンタル開始日
>}
>class ショップ{
>　DVDリスト、料金表
>}

これって、一個一個のDVDはDVDリストで管理して、DVDクラスの中に
DVDの情報が入っているとしか思えないだけど。
一個一個のDVDを管理しているシリアル番号だから、継承でＤＶＤクラス作る
必要性はないだけなんだけど・・・。そうすれば、数分の一に在庫管理情報が減る。

だから、
>タイトルと在庫管理は別にしないと冗長になると思うんだけど
といったわけなんだが。

ポンチ図レベルでこれ位パッと思い浮かばないと後々影響出るぞ。
こういったポンチ図は共通情報とか固有情報とか固定情報の洗い出しに使うわけだから。

おじゃばは、帰納法も演繹法も知らんのか。
「〜だ」、「以前に書いた」、「〜してくれ」
常に断定的で、自己中な記憶頼りで、他人任せ。
悲しいかな、根拠を書かない。書く習慣がない。
前に書いたというなら、せめて引用するぐらい
の配慮が欲しい。
おじゃばの文章には、「〜だから〜となる」と
いう書き方が皆無だ。これじゃぁ人を納得させ
る文章は書けない。ただの落書き。

おじゃば！！！

これで開発(分析、設計、コーディング)すればいいんだよ！！１
ホントおじゃばに最適だと思うよ！

http://yuukiremix.s33.xrea.com/chirashi/

おじゃばはリンク先は見ないよ、つぅか、見ても
難しそうだったら、見なかったことにする。

あ、でもこれは飛びつくかも。

続き
>>397
>DVD名とDVD、ビデオ名とビデオに集約が無いし、
お前クラス図読めないのか？「関連」で書いたのが間違いだと言いたいのか？
「集約」「関連」「コンポジション」の違い分かっているか？
「集約」と「関連」は機能的には同じだぞ、分かっているか？
俺は概念的意味合いで使い分けしているが、人が「集約」を「関連」で書いても間違いだとは言わない

>新旧がタイトルに付随してることを強調したいなら、
>「レンタル商品」の属性から「タイトル」を削って(てかクラスにする)、
だから「汎化」の属性と「カテゴリー化」の属性を一緒にするな

>「レンタル商品」と新しく作った「タイトル」クラスを集約で繋いで、
お前の「集約」の基準はなんだ？カテゴリーはDVDの発売前に作ったり
DVDが全て無くなってもカテゴリーを残して置くこともある（再入荷もあるしな）
俺はこれだけ、繋がりが弱い場合「関連」と判断する
逆に、「集約」で繋がっている「DVD名」「ビデオ名」と「新旧状態」は
「新旧状態」が「DVD名」「ビデオ名」の要素で関連が強いから「集約」を使っている

>「タイトル」クラスに「新旧状態」を集約すべきじゃねぇの？
>タイトルの無いレンタル商品が今後出てくるのか？
>それとも、DVD名とビデオ名で何か違うの？
あとから考えたら、そっちの方が良いと思ったが、それでも「ありえねぇ」と言われるほど間違ったクラス図じゃない

>まぁ前提の「新旧がタイトルに付随してること」自体ビミョーだと思うけど・・・。
>新作か旧作かはタイトルによらず商品で決まると思うんだがな。
同じタイトルのレンタル商品で、新作と旧作が別にあるレンタル店見たことあるか？
お前の言っている「商品」はDVD一つ一つの商品じゃなく「カテゴリー化」された「商品」の事を言ってないか？
例えば「カローラ」と言う商品(車)があるが、これは「カテゴリー化」された商品で
実際自分で運転する商品は「車台番号」ごとの商品になるがそれ毎に値段を設定するのか？

>別の商品でたまたまタイトルが同じ商品だとおかしくなる。
オブジェクト指向分かっているか？実際に関連付けるときは
「クラス」(DVD名)じゃ無く、「オブジェクト」を関連付けるだが
タイトルなんて関連付けには関係ない、その「カテゴリー化」した
オブジェクトの属性がタイトルだと言う事だが、分かっているのか？
なんで、こんな発想になるんだ？意味がわからん

>>436-437 お前OO分かっているか？

「タイトル」という言葉の合意形成ができていないな。
2種の意味で用いられている。

こんな馬鹿なモデラーの作ったクラス図でコード書かされたら発狂するな

>>436　いってることは、正しいよ。でもむかつく
関連も解らない奴に、そこまで書く必要あるの？

＞長文クン
簡潔に書く努力をしろ
相手の読む気を失うようであれば意味がない

>>397
>うー・・・言葉で書いてもうまく説明できねぇ。
>長文スマン。
長文書いといて、最後にまとめられないってｗ
謝れば済む問題じゃないだろｗ

開発ごっこやるんだったら、誰か依頼人役をやったら？

おじゃば氏が>>414でTSUTAYAの名を出したことからして
依頼企業もそれくらいの規模を妄想しているんだろう
既にTSUTAYAはネットレンタルまでやってるってのに
それと同規模の企業を想定しても全然面白くない

つべやニコがある時代に空気も読めずに脱サラして
レンタルDVD店をはじめたという設定ならやってもいい

つーか、おじゃばって学生だよな？
まさかその知識で仕事してないよな？

>>446 学生じゃないはず。多分社会人5年目ぐらい？ にしてはだいぶ御粗末だが。

>>447
まじかよ・・・・・・・・・・・（(；ﾟДﾟ)ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
絶対一緒に仕事したくないな

中二病だろ

普通の神経なら恥ずかしくて言えないようなことを得意気にに語るからな。
しかもそれが大概間違った解釈してるし。しかし俺は意外とおじゃばは30近いか
下手すっと超えてるんじゃないかと思ってるんだが。妙におっさん臭いとこあるし。
..にしては文章が稚拙でやはりまだ20代かと思ったりもするが。

お前20代に謝れ

>>415
亀レスすまSo。ダイナミックバインディングは端的に言うと「仮想関数の呼び出し」のことだよ。
ここまでゆえば、Case文との対比もピンとくるよねすけ。
そうか、おじゃばさまはクラスベースが好きか。つぅかできればその根拠も書いて欲しかったな。
俺は、試験的にちゃっちゃっとアイデアを試してみる分にはプロトタイプベースでやっちゃうな。
でもやっぱりシステムを本格的に構築する時にはクラスベースになっちゃうかなぁ。ま、俺が言語
自体がプロトタイプベースをサポートしているコンパイラ言語を知らないというのもあるんだけど
ね。ジェネリックプログラミングについては、・・・まんまとひっかかったね。ウシシシシシシッ
ジェネリックとOOは相反するものだと言う人がたまにいるけど、そんなことはない。ちゃんと設計
すればうまく融合してくれるよ。例えば、ん〜何がいいかなぁ、簡単な例でいくと、例えばオブジェ
クトの大小を判定する処理が必要なケースで、OOでIComaparableとかいうインターフェースこ
さえたり、<オペレータをオーバライドして、C++の場合だと、
template <class T>
const T& max(const T& a, const T& b) { return a < b ? b : a; }
とかね。これはおじゃばさまには初心者レベルすぎて失礼すぎたかな。でもまんまとひっかかった
しぃ。うふ
ま、今日はこの辺で、実は飲み会帰りで酔っ払ってて、もしかしたら変なこと言ってたかも、そん
時はごみんちゃいませ。
あ、あと、多重継承断固反対の根拠もよろぴくぅ。ミックスインが好きってことでいいんだよね？

つぅか、そろそろ誰か>>415の『ポリフォーフィズム』に遠慮せずにつっこめよ

>>453
はげわろすｗ　見逃してたｗ

長文スルーされてる証拠だフォーーーーーーーーッ！！！
今時HG、フォーーーーーーーッ！！！

単なるtypoじゃなくて、その用語を言いなれてない、
めったに口にしない、日常的に用いてない感があふれてフォーッ！

これに対するクソみたいな弁明も予想されてフォーッ！

こういうどうでもいいことは素直に謝る気もするな。
「これは気づかなかった。ただのtypoだ。わかるだろう？」
みたいな。
でも「本質ではないところにしか突っ込めない(ry」みたいに煽ってくるかもな。

http://www.google.co.jp/search?q=%E3%83%9D%E3%83%AA%E3%83%95%E3%82%A9%E3%83%BC%E3%83%95%E3%82%A3%E3%82%BA%E3%83%A0

ポリフォーフィズム の検索結果 約 258 件中 1 - 10 件目 (0.15 秒)

結構いるんだな。

ついでに調べたらﾌｲﾀｗｗｗ

「ポリフォーミズム の検索結果 約 137 件中 1 - 10 件目 (0.56 秒) 」

>>458
おじゃば並の知性の持ち主が日本に結構な数いるということなのか、恐ぇよ。。
そん中でおじゃばの発言がはやくも8番目に登場してるしw

おじゃばは、自分の知らないことはオウム返しするからわかりやすいぞ。
>>169
>で、ユースケース図からは無理だと言う事は分かったが、ドメイン図からは出来るのかな？
ドメイン図がなんだかさっぱりわからないときはこーやって煽る。

>>450
前スレのディストリビューション知らないで機種とか言ってたり、
知ってるgccのバージョンが2.xx止まりだったり、
Cマスター(笑)でperlモジュールの話してるあたりとか、
なんだかんだ言って構造化もちゃんとできてない手続きロジックしか
出せないとこからして、実は３０代後半の線もあると思う。

周りに相手にされてなくて、自分だけOO知ってるぞ、が支えになってる。

おまえ等まだおじゃばのことがよくわかってないようだな。
おじゃばがこのスレでやりたいことは学校ごっこなんだよ。
おじゃばがやりたいのはもちろん先生。そしておじゃばが
おまえ等に期待してるのはOOを習いたてのちょっと出来の
悪い生徒たちだ。「カプセル化って意味あるんですか？」
とか、「継承って何が便利なんですか？」とか聞いてくる
ような生徒を期待してるんだよ。先生より出来のいい生徒
や先生の揚げ足取りしてくるような生徒なんか想定してな
いんだよ。あと他の先生役がいてもいいが、その先生はお
じゃばより出来が悪く、おじゃばより生徒からの人気がな
い先生でなくてはならない。そういう環境をおじゃばは望
んでいるんだよ。

だから、おまえ等がぐっと我慢して、出来の悪い生徒を演
じてくれれば、おじゃばも気持ち良くカキコできるし、こ
のスレも安泰だというわけだ。というわけで協力してやれ。

>>463

120点。
長文にして分かりにくく書いたつもりなんだろうけど、
目的がしっかりしていて文章が飛ばないので長文でも分かりやすい。

>>464 てれるなぁ。
ついでに言っとくと、おじゃばがよく、俺等にやれって言ってるのは
本人的には多分、先生気取りで宿題出してるつもりだから。

いや、これ難しいだろ。
どこを縦読み？

>>466
左上から斜め読みじゃないか？

>>466は縦読みだな

>>409
亀レスやけども。
＞状態をクラスで表現するのが定石になる、詳しく説明するのも疲れるから『状態(STATE)パターン』を勉強してくれ
まぁポリシーやらプロセスやらの違いかも知れんけど、
分析レベルでデザパタ考え始めるのは、ちょいと早過ぎるんとちゃうか？
概念モデル作っとんの？それとも設計のクラス図作っとんの？

その通りだな　デザパタは必要ない
しかし間違っていることがある
理解できる相手では無いということだ

>>426
だから前から言っているように、構造化は変更を予測してモジュール化された所は変更が容易だが、
OOは全てのクラス単位で変更が容易だと言う所が違う。つまりOOの場合は、変更を予測しなくていいと言う事。

>>432
すまんが、作品に作品番号が抜けていたので、366では追加しておいた。
継承は不要だな。DVDと作品を分離する時に失敗したようだ。やっとまともな指摘が入って安心した。

>>433
自分が基礎知識だと思っている事を、他人が知らないと認識するのは結構難しい。
だから分からない所は質問してくれ。

>>436,437
421を修正してくれ最新版にしてくれ。不要なのは削ってくれ。あれで完成か？

>>446-451
で、366,419,421のうち、どのクラス図が正しいと思うのか、意見を聞かせてくれよ。
どれでもないなら自分で書いてみろよ。

>>452
仮想関数かcaseかなら、OOなら仮想関数呼び出しの方だろう。OOならcaseは排除すべきだ。
クラスベースの方が好みなのは、大きいシステムを作った場合に奇麗に作れるからだ。
まあ適材適所だから、JavaScriptでいいレベルなら、JavaScript使うがな。
ジェネリックは、ひっかかってないだろう？OOではなくてポリモーフィズムではないかと言っている。
第一、ジェネリックとOOが相反する物だと言う話は聞いた事がない。
つーか、452がポリモーフィズムが分かっていないって事かな。それとも酔っ払っているだけか。
多重継承反対の理由は、分かりにくくなるからだ。まあ想像はついていただろう？
つまり用語の使い方が少し間違っていたというのは、わざとだと言う事だな。それなら納得出来る。

>>453-459
ポリモーフィズムの間違いだ。

>>462
不当な評価だ。ちなみにディストリビューションは知っている。
長いから意味は少し異なるが、機種という表現にしただけだ。
462の全ての評価がこのレベルのくだらない事なので、全部にコメントするのは面倒だからやめておく。

> 長いから意味は少し異なる

？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？

ディストリビューションと言う言い方は長いから、意味は少し異なるが、読めば意味は伝わると思ったので、
機種という表現にしただけだ。
でいいかな。
ダリィ

>>474
要するに、意味は少し異なるが、読めば意味は伝わると思うので
>>462　にあることはまったくその通りで反論できない
ということでいいかな。

>>475
462は洞察力も分析力も低い上に、内容もどうでもいい事だから、反論するのもかったるいって事。

使い方は間違ってるけど、伝わらないのは読み手が悪い。と。

おじゃば氏の態度は協力しようという気を萎えさせるのに十分だ
これまで何人の猛者がこうして撃破されていったのだろう

>>476
>475

つまりおじゃばくんは「鳥」等の表現も知らないのですな

なぜオブジェクト指向は普及しないのかって？おじゃばみたいのがいるからだろ。

>>472
おじゃばなぁ、不当な評価だという主張にも根拠が必要だわな当然。
名無しは誰だかわからないんだから、その都度ネゴシエートしないとだめ。
2chで特定の「オマエラ」なるヤツに向かってするのがバカなんだよ。
うわっつらのOO先生ごっこがしたけりゃmixiにでも自分でブログでもすればいいのに
度胸もなくて2chのネタ板で常時ageでコテハン。恥ずかしくないんだろうか？
勝負したきゃせめてム板ででもやりゃいいのに、怖いんだろこのおくびょうもんが。

つまり、はっきり「くだらない」とおじゃばがいうのは
もはや反論もできない事実、でいいな。

>>463
初心者の質問や怪しい設計を放置するから、俺が基礎を教える事になっているだけだ。
ダメな生徒を演じなくていいから、初心者の質問に答えたり、怪しい設計にコメントしたりしてくれよ。

>>465
誰よりも俺が宿題やってると思うが。

>>481
俺じゃなくて、UML厨とデザパタ厨のせいだろう。

>>482
このスレで度胸のあるのは3人いる。クラス図を書いた3人だ。
その次に度胸のあるのは、そのクラス図に対してコメントをした人だ。
残りを臆病者と呼ぶ。オマエはどれだ？

>継承は不要だな。DVDと作品を分離する時に失敗したようだ。やっとまともな指摘が入って安心した。

継承が不要じゃなくて、商品名(作品)と管理処理を別にするのは基本中の基本だ。

>>484
あの、ここでそれをするという合意形成がまるでできないから
誰もまともに相手してないんだよ。
おじゃばとは言葉が通じないな、とわかって誰もが通り過ぎる。
ここはそういうスレ、にお前がしたの。バカだから。

おじゃばをひたすらおだてて生態を観察するスレ
ならできるぞ

>>487
それはそれで毎日の餌やりがたいへんではないかと。
長文で「と思う」連発するまで飢えさせるのもいいかもしれんけどね。

>>484
> 初心者の質問や怪しい設計を放置するから、俺が基礎を教える事になっているだけだ。
> ダメな生徒を演じなくていいから、初心者の質問に答えたり、怪しい設計にコメントしたりしてくれよ。

お前の設計、散々指摘されとるじゃないか

>>489
おじゃばは自分は初心者じゃないからいくら指摘されてもいい、ちう頭だから。
言うだけ無駄。

なんだかんだでもう9スレも続いてるのかよ
継続は力というやつか

＞ディストリビューションと言う言い方は長い

？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？

確かにあれだけ冗長な文章を書いておきながら
こんなところでキータイプ回数節約されてもなぁｗ
そらコイツの文章読みにくくて当然だわ

なんか、このスレってず〜〜〜〜〜っつとこの調子だな。

1)おじゃばがボケる。
　↓
2)名無しがツッこむ。
　↓
3)おじゃばが逆切れする。
　↓
4)名無しがあきれる。←今ここ。
　↓
5) 1)へ戻る。

そろそろ飽きたわ。

>>494
393氏のが意外と教科書どおりなのでちょっと期待している

>で、366,419,421のうち、どのクラス図が正しいと思うのか、意見を聞かせてくれよ。
>どれでもないなら自分で書いてみろよ。

>374 ベースで
class DVD登録画面{登録実行()}
class DVD削除画面{削除実行()}
class DVD貸出画面{is妥当な会員()、is貸出可能()、料金計算()、貸出実行()}
class DVD返却画面{is返却可能()、延滞料金計算()、返却実行()}
class DVD{タイトル、料金、状態、状態更新()}
class DVD管理簿{一覧()、登録()、削除()}
class レンタル管理簿{一覧()、登録()、削除()}
まぁ要求があいまいすぎるので不明な点が多すぎて全然納得いかんが

う〜ん、
>362 の言うとおり "レンタル"コントローラがあったほうがよさげ...orz

まぁ会員関係も考慮してないしw

新旧状態を入れた形でクラス図を修正する
http://www.dotup.org/uploda/www.dotup.org23690.jpg

次にレンタルを考えていくが、その前に誰も指摘しないので
このクラス図の間違いを修正する
(いまのクラス図だと、同じDVDを2度と借りれない)
http://www.dotup.org/uploda/www.dotup.org23692.jpg

レンタルを考える前に、先に質問に答えとく
>>469
>まぁポリシーやらプロセスやらの違いかも知れんけど、
>分析レベルでデザパタ考え始めるのは、ちょいと早過ぎるんとちゃうか？
>概念モデル作っとんの？それとも設計のクラス図作っとんの？
「動的分類は概念レベルに入るか？」と言う事か
これは、人や手法によって違うが、俺は「動的分類・多重分類」は概念レベルに
入らないと思う。しかし今回は規模が小さいから「概念レベル」「実装レベル」で
書いていこう思っている、そう考えると「実装レベル」ではない
とりあえず、「概念レベル」と次の段階の「仕様レベル」で書いてみる
http://www.dotup.org/uploda/www.dotup.org23693.jpg
こんな感じになる。

>498
いや、だから新旧状態がなんでクラスなのさ？
a.状態を保持しているか、b.処理を行うか、c.判断するか
しないならクラスの意味ないだろ...

>>499
たとえば新しい状態を追加する必要がでてきたような場合に
「新旧状態」を親とする新しいクラスを追加するだけですむので
（無論そうなるようにインターフェースが予め適切に設定されている必要があるが）
変更箇所を限定できるというメリットがある

料金表、ってちょっと考えると新旧状態に関係するよね。
「旧作一律100円の日」とか。
そういうのはどこに載るんだろう？

>500
いや、だから「新しい状態」って何するのよ？

>501
料金を計算するところ
"料金表"が計算するところならそこだけど...

>>502
たとえば「新作」、「準新作」、「旧作」に加えて「古典」というようなカテゴリーを追加して
別扱いにするような場合

そこまでいうとジャンルがいるんでは。
邦画・洋画・時代劇・ドラマ・アニメ・特撮・アダルト
これらも追加とか「邦画100円の日」とか考えると属性じゃなくて
クラスにしたほうがいいのかな？

>>504
それは設計が大分進んだ段階（もしくは納期直前）で仕様変更（というか抜け）とすべき
新しいWebサービスを作るのではなく既存の業務をシステム化する話だから
顧客の業務に存在しない・顧客に要求されない事項についての設計は基本的に不要
それこそ使われないシステムというやつだ

>>505
その線引きが脳内にしかないから、ユースケースちゃんと作らないとね
ってこったろ。でもさ。これDVDレンタルだろ？
ビデオがありでジャンルがないのは実用に足るのかねぇ

だいたい、あるのかどうかも分からない法人会員だの家族会員だの
拡張性のためにとやらでいきなり妄想で作ってんのに、
現実のレンタルにあるジャンルやらレンタル形態、
m泊n日とか何本組でいくらとかがごそっとないのがなー。
クラス図いじる前に店行って何本か借りてこいっつーの。
これだからすぐモノ作りたがる奴は困るよ。

>>498
現状で新旧状態によって変わることって、あんまりなくない？
料金を変えようにも、レンタルは料金を商品に聞きに行くのではなくて、独立した料金表を見に行く。
かつ、商品から状態を取得してるわけでもない。(料金表に商品、商品名、新旧状態との関連がない)
要望としてすら出てきてないんで想像だけど、返却予定日が変わんのかなぁ・・・。

状態をクラス化するメリットって「複数の」振る舞いが状態によって変わる場合ではない？
あとづけで新旧状態を属性からクラスに変えても、
カプセル化のおかげでそれほど修正の範囲が狭そうなんで、
個人的には、まだ属性にしておく方がよいと考えてる。(あくまで個人的には)


そういや今の関連だと、商品も商品名も料金表(料金)と何の関係も無いように見えるんだけど。
クラズ図には無いけど「料金種別(属性もしくは操作の返値)」的なものが商品にあって、
レンタルは料金種別を商品から取得して、それをキーに料金表を参照する。
って風になんのかね？

393はどういう意図で描いた？
特に商品や新旧で料金変えるつもりは無し？

>>486-494
哀れだな。設計の内容は全く分からないのか？

>>496
419はOOと言うより、MVCを意識しているだけだろう。
MVCはWEB画面を設計する際に、表示系を変えやすくするための物で、OOとは直接関係ない。
画面系をMVCにするのは構わないが、今回設計すべき所は、MVCを使うとするとコントロールクラス内部で
使用するクラスの部分だ。もしDVD貸出コントロールクラスで、直接テーブルを更新し、
DVD返却コントロールクラスでも、直接テーブルを更新しているなら、構造化と変わらない。
DVDが変更になったら、複数のクラスが影響を受けるだろう。
496はもっとひどい。MVCからビューとコントロールを結合したようだな。そして全体のコントロールの
行き場がなくなったか。とりあえずMVCは忘れた方がいいのではないか？

>>498
いろいろあるが、まず最初に507とほぼ同意見。
不要なクラスは消して欲しいな。あれで完成と言う事なら、次の問題点を指摘するが。

おじゃばが哀れとかくだらんと言うのは、図星で悔しいという内容の表現。
読めば意味が伝わると思う。

>>509
>まず最初に507とほぼ同意見。
お前んのもねーじゃねーか。人の尻馬に乗るなよｗ

>510
伝わるねぇ。
ついに反論ごっこすらもできなくなったみたいだし。

>511
今更言うなよ。
コイツいつもそうじゃん。

>>498
タイトルなんて同じものがいくらでもあるのにそれはないだろ。
最新作、新作、旧作全てに共通する要素を基本クラスにするべきだと思う。
共通するものとはなんだ？
当然、商品情報だよな。

あれ？クラス図って基本クラス中心に書くの？

>>510
正直言って、洞察力も解析力も低い人間の指摘は、妄想としか思えないだろう。
妄想は図星に程遠いし、悔しいと言う感情が起こるはずもない。
起こるとすれば哀れだと言う感情ぐらいなので、そう言った訳だ。

>>514
もはや反論のしようもなく、なんと言えばいいかわからずこの時間でやっと３行書けた。
読めば意味が伝わると思う。

515のほうが不思議と説得力があるな
妄想しか並べられない人間が負け惜しみで妄想は〜とかどんな自虐なのかと

>>>486-494
>哀れだな。設計の内容は全く分からないのか？

なんだ、オレに対するレスはなしか。

>>515
いや正直な気持ちを書いたんだよ。マジで。納得出来る内容だろう？

>>517
俺って485か？それならば、485の言う通りだ。ただ、作品番号入れたら継承は不要なので外す。

納得させたかったらディストリビューションという単語を
「あえて使わなかった」「まっとうな」理由を述べたほうがよくね？

つーかディストリビューションという単語の意味をよくわかってません
って素直に吐いたほうが納得してもらえると思うけど？

>>518
いや正直に反論できないって書いたんだよ、マジで。読めば意味が伝わるだろう？

まぁ、これ以上いまどき「redhatは雑誌の付録」とか言った時代遅れにかまってもしょうがねぇだろ。
ほっといてやんなよ。

　､＿＿＿＿＿＿＿＿＿＿＿
　 ､＞　　　　　　　　　　　　　　.|
　　＞＿＿＿＿＿＿＿＿　　 .|
　　￣ 　　.|./＿　　 ＿＼ |　　 |
　　　　　　| /　 ヽ／　 ヽ　|　　|
.　　　　　 | | 　 ・ | ・　　|　 V⌒ｉ
　　　＿　 |.＼　 人＿_ノ　　　6 |
　　　＼￣　　○　　　　　　　　/
.　　　　 ＼　　　　　　 　　　厂
　　　　　／　 ＿＿＿＿_／
　　　　　￣￣, -/へ／＼/｀- ､
　　　　　　 ／./　 ./o　　　　i.　＼
　　　　　　∧
／￣￣￣　　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
昼飯のスパゲティナポリタンを眺めながら、積年の疑問を考えていた。
それは「なぜナポリタンは赤いのだろうか」という問いである。
簡単に見えて、奥の深い問題だ。
「赤いから赤いのだ」などとトートロジーを並べて悦に入る浅薄な人間もいるが、
それは思考停止に他ならず、知性の敗北以外なにものでもない。
「赤方偏移」という現象がある。
宇宙空間において、地球から高速に遠ざかる天体ほどドップラー効果により、
そのスペクトル線が赤色の方に遷移するという現象である。
つまり、本来のナポリタンが何色であろうとも、ナポリタンが我々から
高速で遠ざかっているとすれば、毒々しく赤く見えるはずなのだ。
目の前のナポリタンは高速で動いているか否か？
それはナポリタンの反対側に回ってみることでわかる。
運動の逆方向から観察することで、スペクトルは青方遷移し、
青く見えるはずなのだ。
逆に回ってみたところ、ナポリタンは赤かった。
よってこのナポリタンは高速移動をしていないと言える。

>>522
「Linuxのgcc」よりはそっちのほうが読めば意味は伝わるな。

流れぶったぎるけど、もうレンタルシステムはやめようや
いつまで経っても要件がはっきりしないし、
OO分析をする以前の話で止まってるし、
「お前は馬鹿」の応酬で生産性が無いし

既存のをやろうよ
例えばWindows付属のゲームのフリーセルやスパイダーを作る、
とかした方が明確に分かりやすいじゃん
拡張性と妄想を同一視するようなこともないしね

　　　　　 　＿＿__
　　　 　／'':::::::::::::::''＼　　　　　　　　　　　　 　　__,,,──,,,_
　─　/:::::::::::::::::::::::::::::::ヽ　　　　　　　　　　　 ∠:::::::::::::::::::::＼
　￣ （::::::::::::::::::::::::::::::::::::|　　　　　　　　　　　│|:::::::::::::::::::::::ヽ
　　　　|＼:::::::::::::::::::::::::丿　　　　　　　　　　　├|::::::::::::::::::::::::::|
　　　　|　||)ヽ:::::::::::::::／　　　　　　　　　＿___＿.| |)、:::::::::::::::::::ﾉ
　＿＿ヽ ／::|｀ヽvv, |::＼　　　　　 　　|＼＿_　.| 　＼_::∧:_／
　── ./::::/⌒ヽ'￣ ｀＼|.　　　　　　　|＼||￣　＼＿_ |　　|
　　 　　 W |______,　　　,.−'−、.　　　　|＼||＿＿_　　/──ヽ
　　 　　　　 |　　|　 ／　＿＿＿＼　 　|＼||＿__|　／ ￣￣￣ヽ
　　　　　　　| 　|ヽ/ ／、　　　ﾉ|｀.|　　 |　 ||　 　　|＿_|　　　　　|
　　　　　　　|　 |　| /　　＼_／ |:ﾉ　　　|　.|| ........　|　 |　　　 　　|
　　　　　(,⌒ 丿　|::|　　./::| 　 ￣⌒ヽ　＼ｼｭｯ l|i|! !丿　 　　　　|
　　　　　　￣　　　｀|　　⌒ヽ｀─ |　　|　 ｼｭｯ i||!|i|!i|!,＿＿＿＿|
　　　　　　　　　　　　＼|　　|　 　'─ ′ 　 　（￣￣|:::::::::::::::::::::ﾉ
　　　　　　　　　　　　　'─-′　　　　　_,,..i'"':,｀-─└───
　　　　　　∧
／￣￣￣　　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
ナポリタンが赤いことは証明されたがなぜ赤いかは不明なままだわ。
そこで、集合論的な考えを取り入れて考察することにしたの。
すると１つの疑問が浮かぶ。「ナポリタンだけが赤いのか？」。
一般的にスパゲッティは赤いわよね。少なくともわたしはこの数十年の人生で
青いスパゲッティや緑、橙、それら不気味と形容できうる色彩のスパゲッティを見たことが無いの。
だけど今からさかのぼること数時間、わたしは黒のスパゲッティを目の当たりにしたわ。
黒いスパゲッティが存在することから
逆説的に背理的に黒いナポリタンも存在することが確認できるのよ。

>>524
何でそんなことをこのスレでいまさらやろうとするんだ？
もっとまともなとこでやりゃいいじゃん。

荒らしてんのアホコテだろ

自動車でいいだろ？
何もソフトに限る必要は無いわけだし

>>おじゃば
真面目に質問させてくれ。
１．なぜお前はここまで反感を買ってると思うか？
２．OO（分析含む）はクラス図があればそれで充足するか？
３．今までに読んだOO本は何？
４．業務時間中にレスしてるのか？
５．質問に質問を返すのはなぜか？

簡潔に頼むわ

>>528
スポーツカーがどうとか、積載量がどうとか、
「拡張性」の名のもとに、何もまとまりそうにない

おじゃばが、OOのエキスパートだというなら、こんな正解の出ないことチンタラやってるより、
その高度なスキルを使った開発手法を示してみせるのが一番だと思うんだが。どうせなら、おじゃば
が何か面白いテーマを決めて、要件定義から製造、或いはテスト、メンテまで一通り開発しながら、
その思考の仮定をつぶさに示して見せればいいんじゃね。それこそ有無を言わせぬ圧倒的な能力を
示してみせればいいんだよ。結果で示せるから客観的に判断できるし、出来が良ければきっと応援
してくれる人もでてくるだろう。いつまでも、「俺は偉い」、「お前は馬鹿だ」じゃ水かけ論だろ？

圧倒的な能力とか夢から醒めて

つか彼はよくわからないことは全て「お前がやれ」とか職場によくいる無能の典型ですがな
そんなやつに無茶な要求してやるなよ　可哀想だろ

１．なぜお前はここまで反感を買ってると思うか？
　　答え： 反感？　お前らがひがんでんだろＷＷＷＷＷ
２．OO（分析含む）はクラス図があればそれで充足するか？
　　答え： あたりまえだろ
３．今までに読んだOO本は何？
　　答え： １０日でわかるオブジェクト指向を読んで３日でマスターしたぜ
４．業務時間中にレスしてるのか？
　　答え： 業務時間なんて暇だろ？　ぷぷっ、お前ら無能だから忙しいんだよＷＷＷ
５．質問に質問を返すのはなぜか？
　　答え： ？　意味がわからないぞ

>>531
まぁ待て。
おじゃばはちゃんと「OOA・OODはよく知らん」的な発言をしてたと思うぞ。

発言もなにも明らからにわかっとらんだろこいつ。分かっとらんのに口だけは達者

>>518
おめえ顔が真っ赤だぞ。

>>534
その割には、オブジェクト指向の向き/不向きな分野など偉そうに語ってましたが...

ttp://itpro.nikkeibp.co.jp/article/COLUMN/20061107/252787/?ST=develop
の中で住井さんがオブジェクト指向の何がいいのかわからない
って書いてあるけど皆さん(除く:おじゃば氏)はどう思います？

お前ら虐めすぎだろ

もっとやれ

>>518
分離するじゃなくてマスターデータ(作品)と在庫管理(ＤＶＤ)は別処理にするのが基本。
なんでそこで、継承なんて事した設計したのかって聞いているんだが。

マスターデータと管理データ一緒くたになるわけどどう処理するつもりだったの？
マスターデータ毎一々管理データ弄くる内容以外方法あるの？

考え中だから間違ったとかって言い訳なんないミスだと個人的に思うんだが。
まあ、おじゃばは違う意見かもしれないので上記と合わせて改めて質問しよう。

１:考え中で間違ったのか？
２:そうでないなら、マスターデータと在庫管理を一緒にするプログラムを構想していた。
３:その他(内容を具体的に書いてね)

どれ？

>>499,502,507
新旧状態を「動的分類」と分析した、つまり「責務」が動的変わると思っている
実装レベルで変更可能な「責務」(メソッド)が追加されると思う、まだ概念レベルだから
「責務」(メソッド)はクラス図に実装していない、これで分かるか？
あと、多分これはインターフェースで実装すると思う
前のスレで、インターフェースと継承の使い分け方を聞いたが、
こんな場合などを想定して聞いた（あまり納得出来る回答は無かったが）

>>500,503
その通りだと思うが補足を書いとく、「動的分類」の簡単表現方法としてフラグがある
前に>>302もそう回答したが、この場合、条件文でその都度処理を振り分ける事になる
これが何故駄目か？　それはオブジェクト視点になっていないからだ
オブジェクト自身が今どのような状態（新旧）を分かっているのに
毎回条件文で判定する必要はない（その状態に必要な要素(フィールド)と責務(メソッド)があれば良い）
クラス視点で考えるから、毎回判定を必要とする考えになる
何度も言うが、オブジェクト指向はオブジェクト視点で考えないといけない

>>501,504,507 レンタルを考える時に、料金・期間を考えようと思っている

>>509
>いろいろあるが、まず最初に507とほぼ同意見。
>不要なクラスは消して欲しいな。あれで完成と言う事なら、次の問題点を指摘するが。
まだ完成でないが、問題点の指摘しても構わない、そうやって
徐々に作って行くつもりだが、「おじゃばさま」は別に設計するんじゃなかったのか？
それから、なんで「おじゃばさま」はツール使わないんだ？

>538
OCamlなるものの知識は自分には無いが、
ソースが汚いのは理解できた
著者がOOを理解できてないのも理解できた

>>529
>>533も良いがもっと冗長な文章を書くだろうな。
おれもおじゃばの回答予想してみたよ。
1.反感と言うより、お前らは俺の言うことを理解できない僻みから煽っているだけだろう。
2.必ずしも十分ではない（注：何が不足かは語ろうとしない）が、クラス図は必須だろう。
3.有名どころの本はすべて読んだ（注：具体的な書名は語らない）。お前たちは何を読んだんだ？おれの知らない本があったら教えてくれよ。
4.お前の業務時間が俺の業務時間だとは限らないだろう。そんな事も分からないのか？学生か？
5.それはお前たちの質問の意図が分からないからだろう。文章力が足りないのではないか？意図が伝わらないのはお前たちが分かっていない証拠だろう。

似てるｗ
イライラするぞｗ

>>541
＞　オブジェクト自身が今どのような状態（新旧）を分かっているのに

日付変わったら状態変わる。
レンタル屋は24時間営業が多いから。

393 は名前欄に393と入れたり、消したり大変そうだな。

>>538
オブジェクト指向は少なくとも個人開発には絶大な効果があるよ。
複雑な物事をすっきりと整理し、各フェーズで注力すべきことを
分類する手助けをしてくれる。しかしこれがことチーム開発となる
と、優れたチームリーダと設計者、その設計の意図を汲んで実装で
きるPG、そして望むべくは優れたメンターがいるチームでなければ、
中途半端なOO技術は却って足かせとなったり融通がきかなくなる
確率がかなり高くなる。というのが俺の経験上の率直な意見。
ドロドロぐちゃぐちゃなスパゲティよりはまだ、フォークによく絡
まる単純なスパゲティの方がまし。

>>509
おじゃばよ、デザパタの組合せともいえるMVCパターンが、OOと関係ないという
明確な理由を教えてくれよ。あと、MVCはWebだけのものではないぞ。

>393は要するに自分でDVDレンタルの話を振ってはみたが
会員側がなんとなく寂しいのでいろいろ妄想で付け加えた、でいいんだよね？
誰も法人会員や家族会員がDVDレンタルに必要とは言ってねえよなぁ。

>>546
おじゃばに明確な理由を求めてはいけない。おじゃばは何を書いても
読めば意図は伝わると思っているから。

OOが本当に拡張性が優れているのなら、将来のためにどうこう、が必要じゃなくて
いま現在最低限なものを作って、必要になったらそのとき簡単に追加できるよ、
というのを示さなくちゃいかんだろ。将来性のためにいま無いものをつけておく、
なんていったら、逆に拡張性がないちゅう主張にならんか？
だから法人会員だのなんだのは要らんと思うよ。

>>519
519が信じるかどうかはともかく、ディストリビューションは長いから機種にしただけ。
俺的にはLinuxに詳しかったら知っていたら、ディストリビューションを知らないのではないかと言う
発想自体、出て来ないのではないかと思う。
REDHATが雑誌の付録は時代遅れだと言うのは認めるが、519の指摘は的外れだ。
俺なら時代遅れの方を責める。だから洞察力が低いと言った。納得できたか？

>>524
いや、プロセスを見るのが目的だから、今のままでいい。問題点がよく出ていると思う。

>>529
533と543が代わりに答えてくれているので、そんな感じ。

>>531
364-366でやっている。
ただこれは俺のOOのやり方で、名無しは「やり方が違う」と言っている。
実際、俺のと他の二人のを見れば、結果は分かるだろうと思ったのだが、分かっている人と分かっていない
人がいるようなので、これから違いを説明して行くつもり。

>>550
日本語でおｋ

>>550
何も言い返せなかったのでとにかくレスだけでもしてみた、ということだな。
読めば意味は伝わる。

＞Linuxに詳しかったら知っていたら

？
お前様の過去の発言を集約するとお前様が詳しいようには見えないわけですよ
当然時代おくれ発言の件も含めてね
過去にちょっと使ってみました程度の付け焼き刃知識しか持っていないように見える
これが妄想ではない推測ってヤツですよ

あとなんで名無し？
やっぱ名無し荒らしはお前様でしたか？

「長いから言い換えた」
この時点で間違ってるのだから
意味が「大きく変わって」いるのだから
素直に謝ればいいのではなかろうか

何故正当化しようと必死なのかと
正当化したければもう少しまともな理由を捏造すべき

この手のコテハンつけたキチガイって、名無しは誰かひとり、とか数人の特定のヤツ
といった妄想をして、それに向かって吼えるという傾向があるからなぁ。
オマエラ、とか名無し、とか敵を特定したくてしかたないんだろうなぁ。
２ちゃんでは不毛なのに、なぜそんなことするのかは疑問なんだけどね。

糞コテには自分が優秀だと勘違いした目立ちたがりが多い
実際は無知とか無能とか呼ばれるアホそのものなんだけど
ついでにかまってちゃんであることも多い
現実世界では空気扱いか邪魔者扱いだから2chでかまってもらえて嬉しいわけですよ
現実世界では言い負けするから議論の基礎もわからないが
2chの議論ごっこなら実際は負けてても勝ったつもりにはなれるので依存する
支離滅裂な発言で周囲をドン引きさせながらでも
自分はとてもいいことを言ったとトンデモ認識できる人種だから
彼がその典型例
彼の今までの発言を見ればそれがわかるだろう？

相手が少ないとか弱いとか思い込むとか
仮想的を自分の都合のいいように設定するとか
アホの基本中の基本だよ
そして一方的に噛みついて勝手に自滅までワンパターン

>>556
この手の人間のやっかいな理由として、
「自覚がない」を忘れちゃダメだろ。

>>557
そうだな、おじゃばは　俺は違うな（根拠にならない妄言）だから。
とか言いそうだし。

とりあえずお前らに言っておく。

レス番書くなら引用符を忘れるな。

>>542
え〜。むしろ著者が専門外のはずなのに、
オブジェクト指向まともに理解してるから関心たんだけど。
例えばC++ならネームスペース、テンプレート、オーバーライド等
オブジェクト指向以外の言語からの借り物が満載なわけです。
カプセル化、多態、委譲、デザパタの類はオブジェクト指向以外の言語でもできます。
で、どの辺がオブジェクト指向なのか追及すると継承と差分プログラミング
ってことになると思うけど、継承を使いまわすとわかりづらくなるので
避けて通るようなことも確かに多いでしょ。
まさにオブジェクト指向もどきだよなと。

>>540
確かに、マスター管理と在庫を一緒にするプログラムなら面白かったかもしれないが、実際には違う。
最初にDVDは何か継承して作ろうと思ってextendsにした。その後、作品を作ったのでDVDのextendsに
くっつけたが、よく考えて見るとextendsにする必要性がなかった。
そこでDVDに作品番号を追加して分離したつもりが、extendsを取り忘れた。

>>541
364-366で設計済み。
ツール？ソースからのリバースしか使った事がない。

>>546
端的に言うと、データと関連する処理を1つのクラスにすると言うのが、OOの考え方だ。
MVCはデータとはちょっと違うがビューと処理を分離しようと言う考え方だ。だからむしろ逆の考え方だ。
デザパタはOOの（あまり実用性のない）サンプル集として使えるが、それを組み合わせて使っているからと
言って、OOになるとは限らない。OO部品でも処理毎に分類していれば、それは構造化と変わらないだろう。

>確かに、マスター管理と在庫を一緒にするプログラムなら面白かったかもしれないが、実際には違う。

面白くない。ファイルにするにせよ、ＤＢにするにせよデータストアの管理がすごい面倒なわけだが。

>最初にDVDは何か継承して作ろうと思ってextendsにした。その後、作品を作ったのでDVDのextendsに
>くっつけたが、よく考えて見るとextendsにする必要性がなかった。

つまり、そこら辺推敲せずに上げたわけね。
作品番号で関連付けされているから問題ないだろと言いたいわけだな。

それはともかく、基幹データ系を何かに継承して作るの？
基幹データ系を元に継承して作るのが基本じゃね？

というのがクラスの基本だと思うわけだが違うの？

>>547,549
俺もそう思う。

>>553
Cコンパイラの件を見れば、少なくとも商用Linux3種で、コンパイル出来る環境にアクセス出来ると言うのが
分かるだろう。素直に考えれば、過去に触った付け焼き刃程度か分かるのではないか？
まあ、俺が無理して見栄を張っていると考えるのは勝手だが。
あと名前が名無しに変わってた。550,561は俺の発言だ。

>>554
正当化するつもりはない。些細な事だし、分かる人には分かっているのだから。
俺が言いたいのは、俺の心理を読んでいるみたいだけど、間違っているよと言う忠告だけだ。

>>555-557
俺は違うな。

>>561,562
あはは、とうとうコテハンやめたけどageはかわらないのな。
いつもの自作自演はともかく、またもや基幹データ系なる言葉出してるし。

読めば意図が伝わる、からいいんだけどさ(笑)

>>563
はいはい、分けてるつもりなのね。意図はわかったw

>>562
そう思う。反論する所はない。おっしゃる通りだ。
ああ、面白いというのは無茶だから面白いと言う意味だ。

なんだよ
結局荒れてるじゃん

>>566
「商用Linux3種 の検索結果 約 123 件」とGoogle先生は仰っています
それで、おじゃまさまは今までにLinuxのどの”機種”を使ったの？
Linuxで何ができる？
Apache, Squid, Tomcat, Xen, MySQL, PostgreSQL, Oracle, … etc
何がしかのLinuxを使ったサーバのセットアップは 当　然　経験済みだよね？
本番環境にXWindow入れてないよね？　SSH使えるよね？
>Cコンパイラの件を見れば、少なくとも商用Linux3種で、コンパイル出来る環境にアクセス出来ると言うのが
分かるだろう。
Cコンパイラの件ってのがわからないが、Cのコンパイルぐらい
yum install gcc(RHEL系), aptitude install gcc(debian系)でインストールして
gcc -o test test.cで終わりだろ

>>541
＞それはオブジェクト視点になっていないからだ
俺は逆の意見。
むしろ責務が把握出来て無い段階でオブジェクトの内部構造を決めてしまうのは
思考停止なんじゃないかな、と思う。
「状態はとりあえずクラスにしておけば大丈夫」程度に思ってるように見える。

図を見る限り、今はレンタル商品名が新旧状態を把握出来てれば良いだけで、
新旧状態が属性だろうとクラスだろうとレンタル商品名オブジェクトの
振る舞いとしては大差は無い。(そらまだ振る舞い(責務？)が割り当てられて無いから当然)

多分、図に描かれて無いけど、経験とかから出てきた十分に根拠がある
責務やクラスの構成がある程度393の頭の中にあって、
そこから描かれたクラスの構成なんじゃないだろうか。
でも頭の中にあるものは俺には見えないので、分析や設計のプロセスが
若干飛躍してるように見えてる気がする。

>>563
＞少なくとも商用Linux3種で、コンパイル出来る環境にアクセス出来る

付け焼き刃程度っていうかぶっちゃけ初歩中の初歩じゃない？
その程度でどうしてそんなに自慢げなのかな？
せめてもう少しハッタリ効かせたほうがいいよ？

＞正当化するつもりはない。

え？言動不一致も甚だしいよね？

＞些細な事だし、

意味合いが大きく変わってるよ？
つか無駄に傷口を広げてるのはお前自身の発言だよ？

＞分かる人には分かっている

明らかに間違っていることはわかったよ？
それでいいのかな？

＞俺の心理を読んでいるみたい

心理を読むってそれなんて妄想？
間違ったのがわかっているなら謝ればって忠告じゃない？
もしかして忠告は全て攻撃と受け取るタイプの人種＝阿呆なの？

linuxとかgccとかmvcとか、どうでもいいだろ

どうでもよくないことはなんだ？

>>568
話の本筋と関係ないことに突っ込むのもなんだが・・・
＞gcc -o test test.cで終わりだろ

test という名前をつけるのはやめれｗ

>そして全体のコントロールの行き場がなくなったか。
いや、それは497で書いてるし、

>とりあえずMVCは忘れた方がいいのではないか？
MVCなんて一言も書いてない

見ていて訳が分からないので、要求仕様を勝手にまとめてみた。

１．レンタルショップにて使用する
　　レンタルシステムを開発してほしい。
２．レンタルシステムは会員制であり、
　　初回に会員登録をしてからの利用となる。
３．レンタルする際には、カードを提示してもらう。
４．レンタル情報を一元管理し、
　　レンタルの延滞などかチェックできるようにしたい。
５．レンタルできる商品は現在「ビデオ」と「ＤＶＤ」である。
　　だが、今後「ブルーレイ」等が出てきても対応できるようにしてほしい。
６．現在、会員は個人登録に限っているが、今後顧客を増加させるために、
　　「家族や企業単位で登録していただくとレンタル料金を安くする」
　　ということをしたい。
７．また、長年当ショップを利用していただいたお客様には、
　　別途レンタル料金を安く出来るようにしたい。
８．レンタル商品には「新作」・「準新作」・「旧作」とあり、
　　作品ごとに以上の属性がつく。
９．料金は、主に「新作」等の属性によって判断されるが、
　　特価日や特殊な作品によっては値段が違う場合があるので、
　　それに対応して欲しい。

とりあえずこんなところかな？
なんか足りないような気もするが・・・
違っているところや足りないところ、余分があったら言ってくれ。
あと、言葉が悪いところが有るかもしれない。そこはつっこんでくれ。

長文失礼

>>564
562だが、おれはおじゃばじゃないぞ。
不名誉な。
オレもオマエモナー(古)。

>端的に言うと、データと関連する処理を1つのクラスにすると言うのが、OOの考え方だ。
>MVCはデータとはちょっと違うがビューと処理を分離しようと言う考え方だ。だからむしろ逆の考え方だ。

M,V,Cそれぞれがクラス(郡)になると思うんだけど(^^;
※ttp://www.shos.info/develop/oo/ooword.html#mvc
　>GUI アプリケーションを Model (ビジネスロジック部分)，View (表示・入出力部分)，Controller (通信・制御）のように三つの部分に分けてなるべく独立した作りとする．
　>各部分間の相互依存性を低減させることで全体の保守性・拡張性を向上させることを目的としている．

>３．レンタルする際には、カードを提示してもらう。
Q)カードがあれば常にOK? 他に条件はないのか？

>４．レンタル情報を一元管理し、
>　　レンタルの延滞などかチェックできるようにしたい。
Q)チェックしてどうする?(どうしたい?)

>９．料金は、主に「新作」等の属性によって判断されるが、
>　　特価日や特殊な作品によっては値段が違う場合があるので、
Q)kwsk

つか、MVCはsmalltalkの基本パターンだったりするわけで
>ttp://www.cue.im.dendai.ac.jp/~masuda/mvc/index.html
OOと逆の考え方なんていったら、じゃそのOOって何よ？
おじゃばはMVCがクラス(モジュール)の作り方だとでも思ってるのか。
ほんとに何も知らないのによくもまあ・・・

>>572
linuxとかスレ違いだろ
アホコテも悲惨だが釣られてあげすぎ

いいからMVCは捨てろ
話がずれる

MVCは拘りと美学だよ

話がずれる、ってあーた、DVDレンタルを作るスレでもないよね本来。

>>579
Smalltalk?ああ、よく知っている。何年か使ったがあれはOOとは方向性が違うと思う。
とか言いそうだぞ、おじゃば。

Smalltalkは実業務では使われていないだろう。
的なおじゃばレスを以前見たような…

>583
課題みたいなもんやし、レンタルシステムでOOを考えるのは悪くない
ただ、提案者がOOを理解してないことと、
協調性が無さ過ぎるため形になってないだけ

>>568
前スレ落ちていたから知らないのか。
Cコンパイラの件というのは、コンパイラの動作に違いを確認すると言う話があった時に、
俺がHEDHAT(EL)、Miracle、Montavistaで検証したら、名無しに商用なので検証出来ないと文句を言われた件だ。
質問に簡単に答えておくとSquid、Xen以外は経験済み。あと、商用では普通yumなどは使わない。
ハンドルがキ○ガイになっている所を見ると、質問に素人臭さが出ているのは、わざとかな？

>>570
3つで初級なら、3つ検証出来なかった多くの人は、初級以下になるのではないか？
心理を読むと言うのは、その前の発言で「図星で悔しい」と予想していた件だよ。

>>574
では「〜処理」でクラスが分かれているのは何故だ？

>>575
要求仕様は出してある。
・ツタヤ店舗、DVDレンタルのみを想定
・会員1種類
・料金体系
「当日、1/2泊、2/3泊、3/4泊、7/8泊、延滞」×「新作、準新作、旧作」
「旧作半額、旧作5本で1000円」などもあり
498の設計は設計者が独自に拡張して設計した物だ。
確か498は「OOとは変更を予測して作成する」物で「設計時に組み込んでおけば低いコストで実現出来る」
と言っていた。だから設計に合わせて要求を変える事なく、本当に低コストかとか、要求にある機能
との整合性は取れるのかなどを考えるべきだと思う。

>>577,579
MVCはあくまでも画面デザインのメンテナンス性を上げる、OOとは別の手段であって、OOではない。
ちなみに、
>各部分間の相互依存性を低減させることで全体の保守性・拡張性を向上させることを目的としている．
これは嘘だろう。ビューとコントロールは密接だ。デザインやレイアウトを変更するのは自由でも、
項目が増えればコントローラーは変更になる。Strutsの経験があれば分かるはずだ。
MVCは全体の保守性、拡張性を落として、ビューのメンテナンス性を向上させた物だ。

OOとは抽象化によって、オブジェクト単位での変更を容易にした物を言う。
つまりDVDがCDになったとして、多くのクラスに変更が必要になる設計はOOとは言えないと言う事になる。

>>587
あれ、それはコンパイラの癖じゃなかったのか？

>>588
StrutsのMVCが問題があるという発想にならないのか？
あれ(俺が知ってる1.1までは)はXMLに汚いところを逃がしただけのもんだぞ。
お前と同様時代遅れかもしらんがなｗ

>>588
ついでに言うと、お前、Modelのことはどーでもいいのか？
項目が増えればうんぬんはModelのことが何もわかってないつことだぞ。
そこが無くて何が抽象化なんだ？

>>587
＞・ツタヤ店舗、DVDレンタルのみを想定
こんな要求があってたまるか。
俺はツタヤでバイトしたこと無いので、
ツタヤがどんなシステムを使ってるかなど知らぬ。

おじゃばが言ってるのは、単なる「業務の説明」で
システムに対する要求仕様どころか要望にすらなってねぇよ。
なんだ？お前の言うOOはコンサルから始まるのか？

「ツタヤみたいなレンタルビデオ屋を作りたいんですがどうすれば良いですか？」

知　る　か

>>587
> 検証出来なかった
アセンブリコードすら読めず
挙げ句すぐに証拠を出せずうだうだうだうだ引き延ばしては
ごまかしてたのは誰なんだい？

おじゃばさまぁ、しつも〜んっ！

>OOとは抽象化によって、オブジェクト単位での変更を容易にした物を言う。
ここで言ってる抽象化ってどういう意味ですか？ 具体的に教えてください。

>つまりDVDがCDになったとして、多くのクラスに変更が必要になる設計はOOとは言えないと言う事になる。
DVDが貸し衣装やレンタル建築機材になったとした場合も同じですか？

>>592
でもそういうのってままあるらしいね

○○（業界最大手）みたいなシステムをうちの会社にも作ってくれ

とかそんなの

>>595
同じものを作れっていうんだから驚くよね。買って来れば？って言いたくなる。

最近はトヨタ方式にしてくれって言ってくるクライアントがいたな
日経に洗脳されてるようだった

>>587
それだけでシステムが開発できるとでも思ってるのか？
そもそも、『要求』が無いじゃないか。

>>578
ありがとう。

>>３．レンタルする際には、カードを提示してもらう。
>Q)カードがあれば常にOK? 他に条件はないのか？
カードがあればOK。他の条件は一切無いものとする。

>>４．レンタル情報を一元管理し、
>>　　レンタルの延滞などかチェックできるようにしたい。
>Q)チェックしてどうする?(どうしたい?)
返却予定日（延滞の発生しない最終日）から１週間が経過したら、
借り主に延滞通知（手紙）を１週間毎に送信する。送信先は、
会員登録時に住所を記入してもらい、そこへ発送する。
それ以外には使用しない。

>>598続き
>>９．料金は、主に「新作」等の属性によって判断されるが、
>>　　特価日や特殊な作品によっては値段が違う場合があるので、
>Q)kwsk
通常料金　　新作：４７０円　１泊２日
　　　　　準新作：３７０円　２泊３日
　　　　　　旧作：３００円　７泊８日
特別料金
・特定の１週間について、旧作を１本１００円とする。
・特定の１ヶ月について、旧作４本をまとめて１０００円とする。
・クーポンを使用して１００円引きすることができる。
　（クーポンには作品名が１作品明記されており、その作品にのみ適用可能）

だいぶ足りなかったな。すまん。
まだあったらよろしく頼む。

長文失礼

取りあえず、貸出状態と色々な料金・期間に対応する為に「会員」「レンタル」「商品」に追加してみる
http://www.dotup.org/uploda/www.dotup.org25258.jpg

次に考えるのは複数割引、今のモデルだとレンタルが1件単位になっているから、レンタルの複数対応を
考えて見るが、その前に>>569に回答しとくと、
http://www.dotup.org/uploda/www.dotup.org25260.jpg
まず、「新旧状態」は要素では無い、要素を区別するものだ、要素は「新作状態」「準新作状態」「旧作状態」になる（図の左）
この要素は、動的に変化するがUMLではこれを＜＜動的＞＞のステレオタイプで表現するのがルールだ（図の真中）
このままでは、既存の言語では表現出来ないのでSTATEパターンを使って表現する（図の右）

>「状態はとりあえずクラスにしておけば大丈夫」程度に思ってるように見える。
ちゃんと要素抽出して、UMLのルールに従っている

>図を見る限り、今はレンタル商品名が新旧状態を把握出来てれば良いだけで、
>新旧状態が属性だろうとクラスだろうとレンタル商品名オブジェクトの
>振る舞いとしては大差は無い。(そらまだ振る舞い(責務？)が割り当てられて無いから当然)
もともと新旧状態と言う要素はない、それに基本的に型（クラス）は要素によって
分けるもので「責務」は関係してこない（もちろん最終的に「責務」の無い型（クラス）は
使いようがないから、作成しないが）

>>599
なるべくモデリングしてみる、俺からの提案は
将来的には、会員登録しなくても借りられるようになる（返す必要がなくなる）
会員制はビジネス客を限定するから、出来れば辞めたいと考えるはず
でも、逆に客を囲いたいからポイント制もあるかもしれない、両方に対応出来るようにする

>では「〜処理」でクラスが分かれている
???

>599 みたく、新旧状態によって「料金やレンタル可能な期間が違う」って話がでてねーよ
ってことだろ？

>>新旧状態が属性だろうとクラスだろうとレンタル商品名オブジェクトの
>>振る舞いとしては大差は無い。(そらまだ振る舞い(責務？)が割り当てられて無いから当然)

なるほど、難しいところはスルーして先送りするのがオブジェクト指向か。
そりゃ開発効率はいいやなｗ

そして設計に時間を費やして肝心のモノはいつまでたっても出てこない
不安にかられた顧客が現場で目にしたものは数枚の落書きだけだった・・・

>>600
>会員登録しなくても借りられるようになる（返す必要がなくなる）
それを世間的には販売と呼ぶんじゃないのかw

>>561
>デザパタはOOの（あまり実用性のない）サンプル集として使えるが、

その台詞はデザパタをマスター（笑）した者だけが吐ける台詞だ。デザパタをマスター（笑）
していないお前に言われても説得力がない。

長々このスレやってるけど、どー考えてもおじゃばはOO否定派にしか思えないんだが。
OOの利点が本人にもよく説明できないコーディングレベルの抽象化(笑)しかない、と主張。
分析にも設計にも役に立たないと主張。ヒアリングも分析も設計も区別ついてないんだけどｗ
いったい何がしたいんだろコイツ。やっぱ学校の先生ごっこかな？

というよりも、クラス図とかみるとコボラー臭感じるの漏れだけ？

>>608
俺もそれは思った。redhat付録の件とか、ひな鳥世代とか言う発言からして年寄り臭い。
〜処理とか結局手続き単位でしか考えられないみたいだし、肝心のOOはコーダレベルで
Strutsについてけないし。背伸びしてるけど取り残されてるか、病気でブランクでもあんじゃね？

>>590,591
ではMVCにする事によって、「全体」の保守性、拡張性が向上するのか？
もし向上するなら何故、GUIや画面関係だけでなく、全体に採用しないのか？

>>592
当初はツタヤを想定していたが、WEB店舗やCDレンタルを含めると複雑になるから外した。
つーか592の発言はひどいな。本気で言っているのか？596もひどい。
はっきり言って、587の情報である程度設計出来ないようでは、設計者としては失格だ。
595,597の言うような場合もあるし、極端な例では「予算余ったから何か作って」と言うのもある。
要求が曖昧なほど、SEの技量の見せ所だろう
>客：「ツタヤみたいなレンタルビデオ屋を作りたいんですがどうすれば良いですか？」
>592：「知　る　か」
>596：「ツタヤで買って来れば？」
こんな会社、やばいんじゃないか？

>>594
>ここで言ってる抽象化ってどういう意味ですか？ 具体的に教えてください。
システムから状態と動作のセットを抜き出すことだ。
今回のシステムで言うと、DVDレンタルから、会員の情報と処理を抜き出してクラスにする事だ。

>DVDが貸し衣装やレンタル建築機材になったとした場合も同じですか？
非常に良い指摘だ。適切に抽象化されていれば、理論的には同様の形態のサービスにも変更が容易になる。
つまり、DVDのように客に期間で商品を貸出すサービスに転用可能と言う事だ。
貸衣裳や建築機器は、DVDと貸しだし期間や商品の扱いがかなり違うようなので変更が多いだろうが、
レンタカーなどは少し変更すれば流用可能になるはずだ。必要性は別にしてだが。

必要性って話ならここ数スレの流れが全て要らないよね
つーかお前の存在が一番要らない・・・・

>>610
>ではMVCにする事によって、「全体」の保守性、拡張性が向上するのか？
>もし向上するなら何故、GUIや画面関係だけでなく、全体に採用しないのか？
だから、Modelはどーしたんだｗ
全体って何？夜間バッチとかも入れてか？そらぁViewが無い部分はMVCにゃならんだろ。
あ、夜間バッチでも帳票出力はあるな。あれもMVC使ってるぞ。
結局おじゃばはMVCが何なのか知らないんだな。毎度のことだけど。

お前ら熱くなりすぎ
おじゃばが賢くなったらこのスレの存在意義が無くなるだろ

よく分からん議論だな

普通MVCと言ったら、MVCアーキテクチャの事だろ、違うのか？
つまり、構造の事だから厳密にはオブジェクト指向には関係ない
MVCパターンは、MVCアーキテクチャを実装する手法の一つで
オブジェクト指向に関係はするが．．．
話が噛み合ってないじゃないか？

OOじゃないMVCパターンでModelクラスが何の仕事するのか教えてください

つぅかOO使わないMVCなんてあんのかよ。MVCとOOが関係無いなんてバカじゃねぇの？
カレー粉とカレーパンが関係無いとでもいうつもりか？　カレー粉を使った新しい調理方
にしか興味ねぇのかよ。

>614
分からないなら口を出すな

また393に、やられているよｗ
お前らの知識じゃ393には敵わなだろう

>>610
>（抽象化とは）システムから状態と動作のセットを抜き出すことだ。

ここおかしいです。システムはこれから作ろう、或いは考えようとしてるもだから、
通常まだ存在していません。存在してないものから何かを抜き出すことはできません。
抜き出すべき場所は問題領域（ドメイン）からです。システム開発における抽象化
とは、問題領域の中での物事の役割とらえ、その特徴をクラスとして或いはクラス同
士の関連として表現することです。結果として対象物が持つべきインタフェースの
抽出を行うことになります。そのインターフェースを実装するために、結果的に状
態を保持する必要があるケースもありますが、状態の保持は必須ではありません。
繰り返しますが、抽象化とは、着目しているオブジェクトが受け持つべき役割を見出
し、外部とのインターフェースを決めてやることです。

それと、レンタカーとDVDレンタルのシステムが、少しの変更で流用可能になるだろ
うというのはあまりにも楽観的すぎます。商品の属性（レンタカーにはグレードや
オプション、保険などがあります）が違います、返却方法（レンタカーは返却場所を
選べたりします）も違います、清算方法（レンタカーは後払いだったり、残油量によっ
て料金も変わったりします）も違います。もちろん商品管理の方法も違います。
DVDレンタルシステムがレンタカーに流用できるのは、あらかじめ、両方に対応できる
ように設計していた場合だけです。そして普通、そういう要件でもない限り、限られた
予算と工数の中でそんなことまで考えて設計しません。

>>615
簡単に言うと、ビューの内容でデータベースの内容を書き換えたりするのだろう？

>>616
カレー粉を使っているから、カレーパンはカレーだと言うと事で、
デザパタ部品を使っているから、OOになると言うと論理か？
でもカレー粉を使っていても、インド料理にはなるとは限らないぞ。

>619
外部とのIFを決めるには、内部で保持すべき情報と、動作を把握しなければならないのではないか？
あと一応、「理論的」には「同様の形態のサービス」にも変更が容易になる、と書いた。
つまり形態が違うので実際にはDVDをレンタカーにするのは難しいが、それを承知でやってみよう。
その前にDVDのは抽象化が低く、DVDと名前が入っていてしまったので、DVDは商品に名前を変えておく。
あと良く見たら、会員に住所や氏名が抜けていたので追加した。
-----------------------------------------------------------------------------------------------
class レンタルシステム{ショップ、会員、倉庫：貸出()、返却()、入荷()、廃棄()};
class ショップ{商品リスト、料金表};
class 商品{シリアル番号、作品番号、入荷日、貸出日：検索()};
class 作品{作品番号、タイトル、ジャンル、年令制限、発売日、レンタル開始日：一括登録()、検索()};
class 料金表{期間、金額：料金算出()、登録()、更新()、削除()};
class 会員{会員番号、住所、氏名、年齢、電話番号、商品リスト：入会()、更新()、脱会()、延滞検索()};
class 倉庫{商品リスト：入庫()、出庫()};
class 貸出履歴{シリアル番号、会員番号、貸出日、返却予定日、返却日、料金、延滞料金：登録()、検索()};
-----------------------------------------------------------------------------------------------

ツタヤでもDVDは別の店に返せるようだが、簡略化のため1店舗の設計にした。
レンタカーも簡略化のため1店舗とする。また燃料は満タンにして返すとする。
-----------------------------------------------------------------------------------------------
class 車種 extends 作品{メーカー、名称、グレード};
class レンタカー料金表 extends 料金表{保険種類};
class レンタカー会員 extends 会員{免許証番号、ゴールド識別};
class レンタカー貸出履歴 extends 貸出履歴{前払い分};
-----------------------------------------------------------------------------------------------
結構簡単に変更出来るのではないかな？

>>620
・・・これっぽっちも抽象化されてないじゃん
あ、抽象化（笑）って「DVD」って入れないことを言うのかｗ
たしかにそれなら「作品」を「車輌」に置換すればレンタカーになるな。
おーすごいぞ抽象化（笑）

>>621
基底クラスに「レンタルシステム」、そっから「DVDレンタル」「レンタカー」としないと抽象化じゃないだろ。
あらゆるレンタル業務はまずTSUTAYAからはじまるのかｗ

>>620-621
ちょ、おじゃば、無理しすぎだろ。無理しすぎてかえって複雑になってる。
レンタカーは会員必須じゃない時点で根本的に無理があるし、車種が継承している
作品には、レンタカーにゃいらん属性がいっぱいあるし、なんで、こんな無理してまで
流用しなきゃなんねんだ？　こんなんじゃ破綻すんの目に見えてっだろ？ 全然説得力ねぇよ。

読解力ねぇな、普通に読めば、
カレー粉を使っているから、カレーパンとカレー粉は関係ある。
OOを使っているから、MVCとOOは関係あると言ってる。曲解すんな。

おじゃばの理論でいけば、ビデオレンタルシステムをサラ金のシステムへも流用できそうだな。

時々居るよね
OO信者のクセしてまともな設計が出来ない馬鹿

>>620
>>外部とのIFを決めるには、内部で保持すべき情報と、動作を把握しなければならないのではないか？

必ずしも内部で情報を保持する必要はない。インターフェースを満たしていさえすればいい。
例えば簡単な例で、6面さいころを抽象化したとしよう。さいころに与えるインターフェースは、

int 振る()

だ。引数はとらず、int型（正確には1〜6の数値だが）の値をランダムに返しさえすれば条件を満たす。
内部的に情報を保持しようがしまいがどうでもいい。実装者次第だ。
さいころをいかさまに使いたい場合は、特定の条件下で特定の目がでるようにするために内部状態を
保持する必要があるかもしれないが、通常は、

int 振る() {
　　return int(random(6) + 1);
}

などといった実装で十分だ。繰り返すがインターフェースの条件さえ満たせば、クラス内部で状態を
保持することは直接的な必須条件ではない。抽象化において状態の保持が必須なら、Javaでもインター
フェースは不要で抽象クラスのみがあればよいということになってしまう。Javaでどうしてインター
フェースという言語機能が提供されているのか少しは考えてみればいい。
おじゃばは頭の思考が硬すぎてこちらの意図を伝えるのに苦労させられる。もうすこし相手の意図を汲む
努力と、想像力を働かして柔軟な思考をするようにして欲しい。

無茶言うなバカ野郎

そうだ、無茶言うな
>おじゃばは頭の思考が硬すぎてこちらの意図を伝えるのに苦労させられる。
だけじゃばくって、おじゃばは自分の言うことはどんなに変でも意図は伝わると考えてるあまえんぼさんなんだぞ。

「あまえんぼさん」なんて、かわいいもんじゃないだろ。

>>620 そりゃ形態が同じなら流用できるし、形態が違えば流用が難しくなるのはあたり前だろ。お前バカか？ いや、あまえんぼさんか？

>>624
＞ レンタカーは会員必須じゃない時点で根本的に無理がある

レンタカーの場合免許が必要なわけで、これは国が唯一の番号だと保障してくれてるわけだから
全ての免許取得者は会員であるが未入力であると言う仮定が成立する。

>おじゃば
自ら要件を壊すなよ
DVDのみ、って自分で要件定義したんだろ
ちょっと話になったぐらいで「レンタカーの考慮を加える」とか言うと話がまた変わるだろ
自分で自分の首を絞めてどうすんだ

>class 作品{作品番号、タイトル、ジャンル、年令制限、発売日、レンタル開始日：一括登録()、検索()};
>class 車種 extends 作品{メーカー、名称、グレード};

ふむ、カローラに年齢制限があるのか。

>結構簡単に変更出来るのではないかな？

利用・保守する側は結構大変そうだがな。

おじゃばはER図からおこしたテーブル項目にgetter,setterをつけたものが
クラスだと思ってるからな。考え方がDOAから抜けきれていない。

>>635
そのDOAもあやしいがｗショップと倉庫はどう違うのよ。貸し出し中かどうかのために
倉庫なんてのをつくったのかいな。

おじゃばは今日も元気に廃棄getしてますか？

おじゃばのモデリングみてたら頭がくらくらしてきた。
車種 is 作品 ?
車の属性に「色」を追加してくれっていわれたら、いったいどのクラスに追加したらいいんだ？
グレードは同じなのに、色が増えるたんびに車種のインスタンスも増やさなきゃならないのか？
カーナビとか、チャイルドシートとか、レンタカーのオプションがどんだけあるか分かってんのか？
汎用化しようとして、本来簡単なことを無駄に複雑にしてる例の典型。しかもその汎用化すら怪しい
ものになってる。
こんな馬鹿馬鹿しい設計を、無理矢理使えるように実装させられる身にもなってみろ、バカ野郎。

オブジェクト指向の極意はサブシステム化にある。
分かるかな。

レンタルならこれが答え
・会員台帳
・貸出台帳
・代金台帳

>>638
おじゃばは、そういう大勢で大きなシステム組んだこと無いヤツだから言うだけ無駄.
半年で何回か納品したとか、仕様を書かずにコーディングから始めた自分が周りより仕事早いぜ、って威張るレベル。
設計したもんをヒトに作らせるなんてとんでもない。なのに知識は五年前のおっさんなんだよなぁ。

こういうのはどうすんの？
・ブラック顧客リストの登録・判定
・深夜２時とかは今日に含めるのか明日なのか（営業日付の概念）
・客がレンタル品を壊した場合
・盗まれた場合の商品の特定と登録抹消処理
・商品の予約をどうするか

>>632
ビデオレンタルの場合は、「レンタルする」の事前条件が、「会員であること」
なわけで、システム的には会員番号をキーにした設計がされている可能性が高い。
一方、レンタカーの場合は、免許証の内容が流動的だという点を考慮する必要が
ある。たんに期限だけをチェックすればいいというものではない。免停や取消に
なっている可能性もあるし、オートバイのレンタルには自動二輪免許が、大型トラッ
クの場合は大型免許が必要だろう。その免許をとった時点で免許証も書き換えられ
ているわけだから、免許証の有効性は、毎回現物を目視して確認する必要がある。
DBに登録しておいたものを照合して終わりというわけにはいかないし、ビデオレン
タルとは手続きがかなり違う。また業種が違うわけだから、管理資料として必要な
出力物の内容も違うだろう。無理して流用できなくもないかもしれないが、よっぽ
どうまく設計されていない限り、流用によるメリットよりデメリットの方が大きい
だろう。

>>634
車はR18指定ってことじゃね？ つぅかこれは年齢制限というより、免許証を提示さ
れた時点で満たしてる事だけどな。会員の属性としては、年齢というより生年月日
を使うべきだろうな。

>>643
性犯罪者はエロビデオレンタルしたらいけないらしいよ。
つまり、

免許停止＝性犯罪の前歴あり

>>642
その件でしたら、今回は予算的に厳しい状況でございますので、
二次開発でということにさせてはいただけないでしょうか？

>>644 性犯罪の前歴ってどうやってチェックすんの？

>>645
ちょっと！ これやってもらわないとお金払えないからね！

>>646
普通に警察のホームページに書いてあるよ。
名前と住所と顔写真入りで。

書いてねぇよアホ。書いてあったとしてもいちいちチェックなんかしてらんねぇよ。

おじゃば、いっちょまえに休みかよ、おじゃばのくせに。

601 ：>584：2008/04/25(金) 00:43:24
>では「〜処理」でクラスが分かれている
???

>>623
実際は623の言う通り、レンタルを基底にするべきだろう。
ただ注意すべき点は、DVDレンタルしかない時点で基底と派生に分割する必要はないと言う事だ。
では分割して見よう。作品をカタログにしてみる。
-----------------------------------------------------------------------------------------------
class レンタルシステム{ショップ、会員、倉庫：貸出()、返却()、入荷()、廃棄()};
class ショップ{商品リスト、料金表};
class 商品{シリアル番号、カタログ番号、入荷日、貸出日：検索()};
class カタログ{カタログ番号、タイトル、ジャンル、年令制限、発売日、レンタル開始日：一括登録()、検索()};
class 料金表{期間、金額：料金算出()、登録()、更新()、削除()};
class 会員{会員番号、住所、氏名、年齢、電話番号、商品リスト：入会()、更新()、脱会()、延滞検索()};
class 倉庫{商品リスト：入庫()、出庫()};
class 貸出履歴{シリアル番号、会員番号、貸出日、返却予定日、返却日、料金、延滞料金：登録()、検索()};
-----------------------------------------------------------------------------------------------
class DVDレンタル extends レンタルシステム;
class 作品 extends カタログ{タイトル、ジャンル、年令制限};
-----------------------------------------------------------------------------------------------
class レンタカー extends レンタルシステム;
class 車種 extends カタログ{メーカー、名称、グレード};
class レンタカー料金表 extends 料金表{保険種類};
class レンタカー会員 extends 会員{免許証番号、ゴールド識別};
class レンタカー貸出履歴 extends 貸出履歴{前払い分};
-----------------------------------------------------------------------------------------------

>>627
インタフェースを考えるだけでは不十分だ。
ちなみにサイコロの例は、627は認識していないかもしれないが、1〜6の値を扱うと言う前提がなければ
サイコロにはならない。例えば「イカサマで振る」が増えたとしよう。627の例ではこうだ。
int 振る();
int イカサマで振る();
これはただの関数だ。俺の例ではこうだ。
class サイコロ{
　　int num;
　　int 振る();
　　int イカサマで振る();
};
実際にnumを管理しているのか、乱数発生器なのかはあまり重要ではない。
しかし、状態がなければメソッド間のつながりが見えない。
ここは構造化とOOの重要な違いだから気をつけるように。

>>653
メソッド間のつながりなんか見えない方が使う側にはいいに決まってるだろ？
何を言ってるんだお前。メンバ全部publicにしろとでも?どこがOOよw

>>638
車種毎に変わるなら車種に入れて、特定の車両毎に変わるなら商品を拡張した物に入れる。簡単だろう。

>>642
>・ブラック顧客リストの登録・判定
会員にフラグ追加。
>・深夜２時とかは今日に含めるのか明日なのか（営業日付の概念）
運用対処。
>・客がレンタル品を壊した場合
破棄は導入済み。
>・盗まれた場合の商品の特定と登録抹消処理
棚卸しの処理を追加する必要がある。
>・商品の予約をどうするか
やり方はいろいろあるが、料金表に予約を追加すれば可能。

>>643
連絡先が必要なのだから、会員登録みたいな物は必要だろう。
会員証の代わりに免許証を使って、有効性は目視で確認すれば良い。

>>651
処理で分類するのは構造化。OOはオブジェクト（物）で分類する。

>>652
データと機能が全部分離してたらOOじゃなくなるぞ…

と、思ったらそうでもなかった>>652
でもクラス多過ぎてワケワカメ。

>>654
意味が通じていないようだな。見えると言うのを「アクセス可能（public）」と理解したのかな
「メソッド間のつながりが見えない。」は「メソッド間のつながりが把握出来ない。」と言う意味だぞ。

>>657
いきなり652を見ると抵抗があるかもしれないが、620、621を見れば、経緯が把握出来ると思う。
そんなに難しくはない。

>>658
>627がいってるように、なぜインタフェースが言語仕様にあるのか考えたか？
おじゃばはどうも想像力がないな。お前、LinuxなりJavaVMがどんな状態を保持してるか
考えてAPI呼ぶか？なんでも自分で作ってる気になってんじゃねーよ、アセンブラも読めないくせに。

それはともかく、イカサマで振るメソッドがあったとしても、そこでnumｇ必要な説明がないんだけど。
読めば意図がわかるってやつか？あいかわらずあまえんぼさんだなｗ

ところで、「メソッド間のつながり」って何のことだ？

>>659
Javaにインタフェースと言う言語仕様があるから、インタフェースの構造はOOだと言いたいのかな？
それ以前にインタフェースがある理由を知らないようだな。Javaでは多重継承が出来ないからインタフェースで
解消しているんだよ。知らなかったか？スレッドに2種類の実装方法がある理由は知らないのかな？
APIはOOとは関係ないぞ。CやperlにだってAPIはあるだろう？

理由は書いてあるだろう。
「1〜6の値を扱うと言う前提がなければサイコロにはならない」と。
num1to6とかにした方が良かったかな？

>>661
へえｗ、なんで多重継承じゃなくてインタフェースにしたんだろ？

>>653
相変わらず無様だな

今時新人でもこう考えるだろ
interface さいころ {
int 振る();
}

class 素人 implements さいころ {
int 振る(){普通に振る実装}
}

class いかさま師 implements さいころ {
int 振る(){いかさまで振る実装}
}

サイコロの例だと分かりにくいようだな。簡単な例を示す。
会員と商品があるとする。
------------------------------------------------------
class 会員{
　　住所; 氏名; 年齢;
　　登録(); 更新(); 削除();
};
class 商品{
　　商品名; 定価;
　　登録(); 更新(); 削除();
};
------------------------------------------------------
627だと次のようになる。
------------------------------------------------------
登録(); 更新(); 削除();
登録(); 更新(); 削除();
------------------------------------------------------
さて、会員が変更になったとする。
どれを変更すればいい？分からないだろう？

>>664
会員の何が変更になったかもわからんのに
どれを変更すればいい？とか意味がわからんわ

>>664
会員のインスタンス.更新()；
じゃないのか？何がわからないんだ？

ああ、結局>635だからおじゃばはそっから出れないんだね。さすが年寄りｗ

>>664
せっかく>>627がインタフェースを教えてくれてるのに。
せめて頭を下げて教えを請えよ。見てて痛々しいよ。
抽象化についてさっぱり噛み合ってないぞ。

ぜんぜんOOじゃないじゃん。なにが物で分類するよｗ
６面体のサイコロも８面体のサイコロも、いかさま師はちゃんと振るんだぜ。

>>661
「Javaでは多重継承が出来ないからインタフェースで解消しているんだよ。知らなかったか？」
この一言だけでおじゃばのレベルの低さが分かるわ(つД｀)

抽象化(笑)
おじゃばは結局OOが嫌いなんじゃないのか。

>664
ぶっちゃけた話、お前、アホだろ。
それで誰をどんなふうに説得したいのか、先が何も見えてこない。
優しい俺様だから大サービスで一応教えてあげるけど、
そんな初歩の初歩で止まってるのは、お前だけ、だよ。

>655
>処理で分類
はぁ...
オブジェクトが備えているべき"役割"で分けるのが一般常識
なんだよ"物"で分類ってw

なんだろ、俺が読解力ないんだろうか、>>661 を読むと、まるで

多重継承みたいなことをしないんだったらインターフェースもいらない

って読めてしまうんだが、...まさかなぁ...そんなわけないし、あぁ、
きっと俺が疲れすぎておじゃばの意図をちゃんと掴みきれてないんだな、
うん、きっとそうだ。いかんいかん、もう寝よ

おじゃばは必死に「物」を主張してるが、そのくせインターフェースの意味を分かってない
OO設計としてのインターフェースの意味はコンポーネント間の接続で、
その接続を受ける側が「インターフェース」と呼んでるだけのこと
多重継承があろうがなかろうが、そんなものは言語仕様でしかなく、インターフェースは変わらない

OOの利点は、OO設計時のインターフェースがOOPでそのまま実装できることなんだよ
多重継承が、とか言いだすのはそもそもコンポーネント間の接続が理解できてない証拠で、
「Javaで作ってるからOO分かってます」、と言ってるようなもんだ
JavaだろうがC++だろうが、さらに言えばCでもbasicでもインターフェースは変わらない
実装方法が違うだけのこと
JavaやC++はその点で実装しやすくなってるだけ

サイコロとか車とかに脱線しまくる前に基本を身に付けろ

>>675
>多重継承が、とか言いだすのはそもそもコンポーネント間の接続が理解できてない証拠で、
>「Javaで作ってるからOO分かってます」、と言ってるようなもんだ
残念なことにおじゃばは大まじめにそう言ってるんだなこれが。
>113,>145
OOは言語だけの話でいいそうだ。うへぇ。

おじゃばがデザパタを理解できない理由がわかった。

>>665,666
会員情報に対する登録／更新を探さないと分からないだろう？
会員クラスになっていれば、強い制約ではないが、会員の情報に対する処理というのは分かるが、
クラスになっていなければ、結局全てのメソッドの中を見て、会員情報を使っているか見る事になる。
たとえコメントで会員情報登録と書いてあったとしても、何の制約もない。

>>668
一般的なインタフェースを言っているのか、Javaのインタフェースを言っているのかと言うと、
>Javaでもインターフェースは不要で抽象クラスのみがあればよいということになってしまう。
>Javaでどうしてインターフェースという言語機能が提供されているのか少しは考えてみればいい。
と言っているのだから、Javaのインタフェースを言っているのだろう？
たから抽象クラスだけではダメな理由を答えたのだが。他にどういう理由がある？

>>669
物と言うのは物体と言う意味ではないぞ。実体を持たない「ルール」みたいな物も含む。
つまり「オブジェクト」の事だ。日本語では良い訳がないから「物」になってしまう。

>>678
日本語で言え。

>>675
>OOの利点は、OO設計時のインターフェースがOOPでそのまま実装できることなんだよ
これだとすると、必ず聞かれる疑問点がある。
「それだとCでモジュール（外部関数）化するのとどう違うの？」
これにはどう答えるのかな？

>>680
その答えが今みんなが教えてくれているインタフェースについての説明にも含まれているんだよ。

>>661 のような誤ったインタフェースの理解をしているおじゃばにはわからんだろうが・・・。

マ業全体がしょぼいから

>>680
おちついて、ゆっくり文章を読み直してみては。
あせらず、最初から順番に理解していけばいい。

>678
正直な話、制約どうのこうの以前に、お前の頭をどうにかしたほうがいいぞ。

＞強い制約ではない
お前の話じゃあ、結局破綻しとるがな。
超シンプルなシステムならともかく、
世の中にはお前のような頭の固いアホが書いたスパゲッティプログラムもあってだな、
結局全部検索せにゃならんことには変わりないっつーオチ。

お前に設計させると、確実に破綻するだろうな。。
基礎の基礎程度の知識で、理想論と妄想だけで構築されば、当然。。

すごいアホが居るな。
どうやったらここまでアホになれるのか不思議でたまらん。

つーかまたOOの利点から始めるのか？
俺の意見では「OOの利点はオブジェクト単位で変更が容易」だが、これはこれでいいのかな？

675の意見では「OOの利点は、OO設計時のインターフェースがOOPでそのまま実装できること」らしいが、
これにはみんな賛成なのか？
ちなみに、「それだとCでモジュール（外部関数）化するのとどう違うの？」の回答はまだないが。

>>686
もうよせ。話が全然噛み合ってねぇ。

>>686
＞これはこれでいいのかな？
よくないから、話題がループしていることにいい加減気づけ。

＞（前略）回答はまだないが。
>>681,683 が回答だ。このスレを理解しながら読みさえすれば答はすでに自明。

>>688
675はOOはCのモジュール化と変わらないと言っているように読み取れる。それでいいと言う事かな？
そうなると、391の処理で分割するクラス構成もOOだと言う事になるが、それでいいのかな？

一から出直しておいで…。

まずは本屋で本買って読むのがオススメ。
非OOPLの勉強もしっかりしておくんだよ。
それで何が不便かをまず学ぶんだ。
次に、OOPを少しずつ学んでいくといい。

まずは、自習しなさい。

on_

おじゃばにまず必要なのは OO(P) の知識じゃないな。読解力だ・・・。

>>690
690はまず俺のレンタルシステム例を見て勉強するのをお勧めする。
「OOの利点は、OO設計時のインターフェースがOOPでそのまま実装できること」なんて言っていると笑われるぞ。

インターフェースってコンセプトを理解できるかどうかってだけの話なのに
なんでいきなりCのモジュールとか出してくるの？

>>693
設計時にインタフェースしか考慮しないなら、Cのモジュールと同じだろうと言う事だよ。

「OOの利点はオブジェクト単位での変更が容易と言う事だ」と言う前提がないと、他の二人の設計を
評価出来ない。「OOの利点は設計時のインタフェースがそのまま実装可能？」設計ミスでもない限り、
普通はそのまま実装可能だろう？わけわからん。

と言う訳で、残の二人の設計が本当に「変更が容易」か検証してみよう。
作者に検証してもらうのがいいのだが、もういないのかな？

>>694
675もう一回読み直せ

まず、「新作／旧作」や「電話番号」がクラスになっているやつ。
あれ、基本機能すらクリアしていないから、出来れば基本機能ぐらいはクリアするようにして欲しい。
今のままだと、デスマ突入で、リリース可能時期未定って感じだ。

次に処理でクラスが分かれているやつ。
------------------------------------------
class DVD登録画面{実行()} class DVD登録{} class DVD削除画面{実行()} class DVD削除{}
class DVD貸出画面{実行()} class DVD貸出{} class DVD返却画面{実行()} class DVD返却{}
class DVD{DVD情報：貸出()、返却()}
class 会員登録画面{実行()} class 会員登録{} class 会員削除画面{実行()} class 会員削除{}
class 会員{会員情報：取得()} class 一覧{取得()}
------------------------------------------
はっきり言って、これだけでは分からない。管理しているデータが分からない。
多分、作者の頭の中にはテーブル設計があるのだろう。以前に俺が設計したテーブルを当てはめてみる。
----------------------------------------------------------------------------------------
会員（会員番号、住所、氏名、生年月日、入会日、退会日）
商品（シリアル番号、DVD番号、入荷日、廃棄日）
DVD情報（DVD番号、タイトル、ジャンル、年令制限、発売日、レンタル開始日）
料金表（料金番号、期間、金額）
料金管理（料金番号、優先順位、開始レンタル開始日、終了レンタル開始日、DVD番号、ジャンル）
貸出管理（貸出番号、シリアル番号、会員番号、貸出日、返却予定日、料金、延滞料金）
----------------------------------------------------------------------------------------

>>695
お前こそ話の流れを読め。
インタフェース設計する時に、内部構造を把握する必要があるかと言う話ではなく、
クラス設計をする時に、インターフェースのみの考慮で十分かという話だぞ。

>>694>>696
お前はアホか。
分析段階のしかも分析途中の図持ち出して、勝手に設計扱いすんなよ。

おじゃぱの書き込みを飛ばして読むと勉強になるな

誰かちゃんと言えよ。つか俺が言う。
おじゃば、あまったれるのもいいかげんにしろ。
誰がお前にそこらの本に嫌ってほど書いてある物を手取り足取り教えなきゃならん。
話が通じるようになってから出直してこいよ。

つぅか糞おじゃば　
つぅかこのスレもいらないんじゃね？
実際糞おじゃばがいなかったGWにはいらなかったし。
つぅか糞おじゃば　いちいちこのスレあげんじゃねぇよ。糞おじゃば!!!!vok

それでいいと言う事かな？

OOの利点はポリモーフだろが
そのためのインタフェースじゃないのか？

>>697
NO


…てか、誰がそんな話し始めたんだ？

>>696
インターフェイスとクラス設計を比べないこと…



あ、
もしかして'うっかりさん'かな？

素人考えで悪いんだけど、インターフェースとか抽象クラスって字面どおりに解釈すれば良いんじゃないの？
例えばUSBにはマウスだろうとディスクドライブだろうとプリンタだろうと、インターフェース規格があってれば接続できる。
抽象クラスの方は、例えば「HDD」、「FDD」に対して「ディスクドライブ」という、抽象的な表現でその本質／共通の性質に着目する。みたいな。
多重継承とインターフェースは別に関係無いっぽい。JAVAでは単純に多重継承禁止。

C++のclassでvirtualを使って作る抽象クラスは上のインターフェースと抽象クラスの二つ目的で使用できるけど、
文法レベルで目的を明確化出きるようにしたのがJAVAなんじゃないかな？

>>627
>必ずしも内部で情報を保持する必要はない。インターフェースを満たしていさえすればいい。
バカすぎるｗ、OOをまったく理解出来てないなorz
内部情報を持たないオブジェクトを作るなんて、それはOOじゃない

>>675
>OO設計としてのインターフェースの意味はコンポーネント間の接続で、
>その接続を受ける側が「インターフェース」と呼んでるだけのこと
こいつもバカか？（コンポーネント間の接続）はっ？　（「インターフェース」と呼んでる『だけ』のこと）「だけ」ってｗｗｗ

┌─────┐
│基地外警報│
└─────┘
`ヽ(´ー`)ﾉ
　 (　へ)
　 く

誰か、もう少しまともなIFの説明したら？

理解する気が無い相手に説明するのは無駄じゃん

いや、理解する・しないは別に、ちゃんとIFを説明しないと
俺も６２７や６７５は違うと思う

じゃ、お前がしろ。おじゃばにわかるようにな。
と言われると想像できないんだろうか？

┌─────┐
│基地外警報│
└─────┘
`ヽ(´ー`)ﾉ
　 (　へ)
　 く

>711
読解力なさすぎ

土曜はおじゃばの自演曜日だからな

よくあるOOの説明としては、
「オブジェクトの振る舞いはオブジェクト自身が知っている」またはもっと強く、
「オブジェクトの振る舞いはオブジェクト自身しか分からない」。
これを実現するために（情報隠蔽を含む）カプセル化がある。

一方インターフェースとは、メッセージパッシングのメッセージの、形式／書式を表現していると解釈した。
メッセージの内容はオブジェクト間の関係というか、投げる側の目的、受ける側の役割で変わってくる。

オブジェクトの「振る舞い」は分からんくても、その「役割／機能」は分かっているから、
目的に合わせて、先に上げたUSB機器のような適切な機器（オブジェクト）をつないでやれば良い。

デザパタのほとんどはインターフェース（若しくは抽象クラス）を前提にしいている。
逆にいうと、中身を定義しないからこそいろいろなケースに適用することができる。
デザパタが考え方や概念を抽象化したものとするなら、抽象化が必ずしも中身ありき
でないことを示す好例だろう。
もともと、抽象化とはなんぞやというところから始まった話だと思うが、どこで>>697
の論旨になったのかわからない。

>>707
＞内部情報を持たないオブジェクトを作るなんて、それはOOじゃない
概念クラスと実装クラスをごっちゃにするな。

最近の携帯電話は、テレビのリモコン代りに使えたりするが、それは、
携帯電話が「チャンネルを送信する」というインターフェースを備えて
いるからだ。逆に言えば、ひげそりだろうが、やかんだろうが、この
インターフェースを備えてさえいれば、テレビのリモコンになりうるわけだ。
何で出来ていようが、実装方法がどうだろうが、関係ない。ボタンを押すタイ
プだろうが、Wiiみたいに振る形式だろうが、音声認識だろうが関係ない。
データはもちろん大事だが、いきなり内部情報がどうだ、扱うデータがどうだ
とデータありきで考えるのは実装レベルでの視点であって、抽象化を意識した
設計者の視点ではない。おじゃばは結局DOAのアプローチから抜けきれていない。

>>718
そうか？
>>627
>int 振る() {
>　　return int(random(6) + 1);
>}
>などといった実装で十分だ。繰り返すがインターフェースの条件さえ満たせば、クラス内部で状態を
>保持することは直接的な必須条件ではない。
って実装レベルで書いてるぞ、>>707の言っている事が正しいと俺も思うよ

>>716,717,719
また、分けのわからん奴らが、うその説明してるなｗ

>>720

int 振る()
が概念

int 振る() {
　　return int(random(6) + 1);
}
が実装

じゃね？　振るという概念に対して実装はいくらでもある。

>>722
違うだろ、よく嫁め
>＞内部情報を持たないオブジェクトを作るなんて、それはOOじゃない
>概念クラスと実装クラスをごっちゃにするな。
と書いているから、、内部情報を待たせないオブジェクトの話だろ
本人じゃないから分からんが、メソッドの概念・実装の話じゃないと思うぞ

俺は本人だが、>722が正しい。

>＞内部情報を持たないオブジェクトを作るなんて、それはOOじゃない
>概念クラスと実装クラスをごっちゃにするな。
普通これ読んで、そう思うかｗｗｗ

>>718,722,724 自作自演乙

>>720,721,>>723,725 こいつおじゃばより頭悪そうだな。

>>725の方がまともだと思うけどね。
インタフェースをメソッドレベルで説明するなんてアホすぎる。
あとデザパタ持ち出してるやつもアホ。

俺の場合は、結論だけ述べて根拠を示さない奴をアホかどうかの判定基準にしているが、
そういう意味では、>>727はアホの中のアホだな。

俺は理解出来ないで書く奴の方が、そうとうバカだと思うぞｗｗｗ、

ということは、>>729も、そうとうバカだなｗｗｗ

流れを読まずに発言するが、
>>706さんの感覚が俺には一番近い。

JavaのinterfaceはOOPLとしての心意気で、
同様に、C++のvirtualはOOPへの及び腰。

まず先にこういう話があっての、
Javaのinterfaceは型の多重継承を可能にした、
の話をすればいいと思う。な、聡明なおまいら。

修正しとく。

な、C++では純粋仮想関数だけのクラスを先に作って嬉しがる聡明なおまいら。

>>730
そんなにカリカリするな、自分が書いたのを批判されて怒るのは分かるが
おじゃばはもっと大人の対応をするぞ。　
それに、おじゃばと一緒で浅い知識で書いたら批判ぐらい覚悟しとかないと