08/03/25 09:44:03
トップダウン男は提示した内容で問題ないか、みんなに聞いているのだから答えただけだ。
大きな点では問題ないと思うが、細かい点でいつくか問題があったので指摘した。
オマエラも、愚痴る暇があったら、少しは協力したらどうだ？
951:仕様書無しさん
08/03/25 10:22:24
>>950
少なくともてめーにだけは協力しねー。てか何によ？
952:おじゃばさま ◆GxjxF3yEw6
08/03/25 19:05:56
>>951
協力しないと言いつつ、「何によ」と言うのは協力したいのが伺える。
また「何によ」と言っているが、少し考えれば分かる内容なので、951にも分かっていると思われる。
まあ俺からは、「出来る事をやれ」とだけ言っておこう。
953:仕様書無しさん
08/03/25 20:04:04
お前は何も「できない」わけか。なるほど。
954:仕様書無しさん
08/03/25 20:17:53
前、言っただろリピータ大事にしろと。
大体お前と話している奇特な奴なんてもういないぜ。
955:仕様書無しさん
08/03/25 20:30:00
おじゃばが「OOAとOODが分からないから、まずはOOAから教えてください」って言ってるだけだろ。
出だしの在庫管理辺りからそう。
個人的にはそんなことはどうでも良くて、393が>>867で書いた開発プロセス。
そういうのがホントに確立されてるなら、なんつー名前なのか知りたいんだけど、
名前がないなら紹介されてるウェブページとかでもいい。
誰か知らない？393でなくても良いし。
要件定義で(ウォーターフォールなりRUPなりで言う)要件を定義しないで、
システム分析は設計工程に含まれの「概念」と「実装」に分かれるらしい。
そして>>871や>>891
分析、だそうだが、何を分析したいのかさっぱり分からない。
インプットは目的(これすら良く分からんけど)で、
アウトプットは業務要件と要素？
抽出した要素も、何に注目して抽出されたのか分からない。
抽出した要素の使い道も分からない。
誰か教えてくれないか？
それで、この後どうなるんだ？
956:仕様書無しさん
08/03/25 20:57:21
>>955
どうもならねぇよ、糞が。いいかげんにしろ。
957:仕様書無しさん
08/03/26 00:25:28
393は、最近来ないな>>897のオレオレルールとオレオレ要件定義書に
参ってたからな(>>915)w
しかし、897のオレオレ分析とオレオレ設計も見てみたいなｗ
958:仕様書無しさん
08/03/26 00:32:17
まぁ、このスレ的には、OOは結局使いもんにならんことがわかって順調ってことじゃね？
959:仕様書無しさん
08/03/26 06:26:11
ちゃんとわかってる人が作った図なら子一時間レビューすれば
仕様をある程度知ってるはずの顧客にはわかりやすく通じるがな
おじゃばみたいにぐだぐだ書かれると通じない
960:仕様書無しさん
08/03/26 10:11:19
おじゃばの性格からして、このスレは(オレの）オブジェクト指向は普及しないのか？だからな。
そもそも、処理中心の考えで組まなくちゃ逝けないプログラムって言うものがあるわけで、
でもC++でクラス使って一応オブジェクト指向の場合おじゃばは納得できるのだろうか？
961:仕様書無しさん
08/03/26 10:34:38
>>960
クラス使ってりゃそれでいいんじゃねーの、おじゃばは。
自分から教える(笑)もんでなきゃどんなんにも納得なんかしねーよ。クズだし。
962:仕様書無しさん
08/03/26 22:30:25
>>897の要件定義書もう見れないのか？誰かアップしてくれ
しかし、よく自社の要件定義書をさらしたよな、何処の会社か分かる奴いないの？
963:おじゃばさま ◆GxjxF3yEw6
08/03/26 23:04:02
>>955
確立された手法ではないと思う。
また詳細は記述内容から読み取れと言う事で、955の読み取った内容でいいと思う。
>>959
俺が普段設計する時は、要求仕様が決まったら、コーディングを開始する。
コーディングが終わったら機能仕様書に落とす。それでも他の人が機能仕様書だけを書くより早い。
>>961
クズと言うのは議論にも参加せずに、他人の非難ばかりする奴だろう？
964:仕様書無しさん
08/03/27 01:27:33
OO支持の方、OO設計はどうやって勉強すればいいですか？
参考になる本、サイトを教えてください
よろしくお願いします
965:おじゃばさま ◆GxjxF3yEw6
08/03/27 12:41:41
>>964
OO設計に確立された方法はない。
いや正確に言うと、いっぱいあるが、どれも何にでも使える適切な方法ではないと言う所だ。
試しに下記HPを読んでみるといい。
URLﾘﾝｸ(www.asahi-net.or.jp)
俺俺天国が実感出来るだろう。
つまりこれは未知の分野と言う事だ。
未知の分野での学習のこつは、「実験」→「分析」の繰り返しになる。
966:仕様書無しさん
08/03/27 16:56:59
>>932
>業務システムだと、そういう「お絵描き」よりもER図をしっかり書いてほしい。
結局今の業務システムの作り方ってDOAのままだよね
DBに保存する、DBからもってきて表示する、しかやってない
だから面倒なモデリングなんかするんなら人集めて作っちゃえ、ってなるわけで
OOで設計する方が時間がかかるのは例のOMT本にも書いてあるしね
メリットがないんだろうなあ
967:おじゃばさま ◆GxjxF3yEw6
08/03/27 20:45:55
トップダウン男も撃沈か。
仕方ないので、俺がやってみる事にする。
結局、ユースケース→クラス図→クラス（コード）に出来ればいい訳だ。
ただユースケースからクラス図への変換の方法が分からないし、どこにも書いてない。
まあやってみるか。
とりあえずユースケース図をもう一度考えてみよう。
誰かがアクターは店員のみだと言っていたが、ビデオを借りて店員まで持って行くのは会員だし、
新しいビデオ持って来り、古いビデオを回収したりするのは業者だから、それもアクターにしようと思う。
ただシステムに直接触らずに、店員に対して動作を実行している。アクターに対して別のアクターが
ユースケースを出していいのだろうか？まずい気がするので、アクターとアクターの間にシステムを
噛ませようと思う。
例えば、会員はカウンターを通して店員にビデオ渡す。ビデオ返すのは返却ボックスとしよう。
業者は仕入れ棚と廃棄棚を通して作業することにしよう。
そして、カウンター、返却ボックス、仕入れ棚、廃棄棚をシステムの一部とする。
そうすれば、アクターとシステムの関係は保たれるだろう。
968:仕様書無しさん
08/03/27 21:56:23
客に店舗でシステムを使わせんのかよ。また変な要件を出してきたな。
なんか、おじゃばはユースケース自体を理解してないっぽいな。またオレ流解釈か。
ユースケースの枠はシステム境界。アクターはシステムとやり取りをする人や物（別のシステム）。
つまり、システムと係わりのないものをアクターとすることは間違ってるし設定的にも意味がない。
だから、客や業者もアクターにするというなら、システムを使って何をやらせるつもりなのか、
まず要件を決めないと。
それと、ユースケースからクラス図が難しいと思うんだったらロバストネス図を書くのがおすすめ。
969:393
08/03/27 23:08:19
>>897からのレスないな
それより、なんか話が噛み合わないと思う、考えたが
俺は、オブジェクト指向の勉強の為に設計まで行なうから、ニュアンスが伝わればいいぐらに考えているが
「おじゃばさま」を始め何人かは、実際の業務で意識して、実装出来るレベルまで行なうと考えているのか？
それなら、アーキテクチャーやツールなども考えないと
970:仕様書無しさん
08/03/27 23:11:24
なんやろ
ひととおり恥をかかせてやるのがいんやろか？