＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
オブジェクト指向設計はトップダウン的アプローチ(ドメインモデルからクラス設計),ボトムアップ的アプロー
| 投票結果総投票数：50 | |||
|---|---|---|---|
| トップダウン的アプローチ(ドメインモデルからクラス設計) |  |
29票 | 58.00% |
| ボトムアップ的アプローチ(処理手順からクラス設 | |
21票 | 42.00% |
| |||
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-12-10 15:18
るぱんです。
え〜とですね、 今月転職したばかりなので、 「世の中の人はみんなにたような事を・・・」とおかしく読ませていただきました。 理想は理想で大事です。 プログラミングは思想だと思っていますし。 最終的には、上司部下の関係以上に、 「同じ人間として」いっしょにやりたいかどうかかな・・・。＜最近の見解（笑） 全体を見渡しつつ、バランスを考えることが楽しいクチなので、 いっしょかな？ 熟慮されていると思います。 一度決めたら踏ん切り良くやってみてください。 ある程度はそれだけでかなり成功を収めると思います。 [編集] なまえだけで誤送信したため、本文を追加（汗） [/編集] [ メッセージ編集済み 編集者: るぱん 編集日時 2004-12-10 15:24 ] | ||||||||
|
投稿日時: 2004-12-10 16:35
ソースコード=設計書であることは同意しますが、唯一の設計書ではないでしょう。システムを 見る視点や目的によって複数の設計書があっていいはずです。 システムを構築するステップとして、「何を作るのか(分析)」と「どう作るのか(設計)」の 2段階を経ると思いますが、この2つがシームレスであればあるほど、ユーザのニーズに合った 変更に強いシステムを作ることができると思います。なぜなら、ユーザの要求は「何を作るのか」 に反映されるわけですから、たとえばユーザの要求に変更が合った場合、分析と設計がシームレス であれば、どこをどう修正すればいいか、すぐに見当がつくはずです。 かならずしも厳格に分析/設計のステップを踏む必要はありませんが、このような視点を持って おくことは大事だと思います。 | ||||||||
|
投稿日時: 2004-12-10 21:35
そうですね、ソースコードが唯一の設計書ではないですよね。分析が「何を作るのか」と設計が「どう作るのか」って言われてみるとまさにその通りだって思いました。そう考えると何をすればいいか(その工程がなんのためにあるか)わかりやすいですね。 まぁともかくJack Reevesの「多くの人がプログラマーは大工にあたると思っていたのがプログラマーは建築士にあたるんじゃいか」って考え方はほんと斬新で感動しました。 | ||||||||
|
投稿日時: 2004-12-10 21:46
ありがとうございます！！転職で100%願いが叶うことはないと思うけど、少しでも今よりよくなればと思ってます。そうやって少しずつ良くして行けたらってね！何事もちょっとずつ良くしていくことの積み重ねなんだと思うんです。プログラマーの仕事してて技術力も前やったことを次やるときはもっといい方法でってことを積み重ねていくと自然と向上していくってことを実感しました。 「全体を見渡しつつ、バランスを考える」、う〜ん、僕の場合バランスまで考えれてるかわからないけど、そうっすね〜。全体を見てチーム全体が効率よく仕事が出来るように常に考えてます。そんな権限ないけど〜 [ メッセージ編集済み 編集者: やまろう 編集日時 2004-12-10 21:50 ] | ||||||||
|
投稿日時: 2004-12-15 12:25
実務的なお話として。
仕事の基本はトップダウン＆ボトムアップの両方を同時に活用します。 まず「要求」を受けて要求の定義を確認し、要求内容を理解（調査）し、対応要素を洗い出す等のトップダウン手順を踏みます。 その一方で「成果」をイメージし、成果を出す為の必要条件を洗い出し、必要条件の対処手段を選定する等のボトムアップ手順も同時に考えます。 そしてこの両方向を結び付ける事が出来てやっと自分が何をする必要があるのか判る訳で、この流れを結び付ける行為が全ての仕事の「核」となります。 つまり、トップダウンやボトムアップというのは説明をする際の表現であったり技法の概念であって、実務的には片方向だけの流れは存在しないと考えます。 | ||||||||
|
投稿日時: 2004-12-15 17:30
なるほど、トップダウン的なアプローチをする場合はボトムアップ的なやり方も併用するんでしょうね！ですけど、今いろいろな会社に面接に行っていて、その中で、「要求分析でドメインモデルを書いて、そこからクラスを設計していくようなオブジェクト指向分析をされてますか？」と質問してみると、多くの会社は「していません」ということでした。ベンチャー企業とか大手企業からは逆に「UMLを使った設計をしたことあるか？」といった質問をよくされます。時代はそちらに向かってるんですかね〜 | ||||||||
|
投稿日時: 2004-12-15 21:11
ボトムアップと呼ぶかどうかはともかく、下流工程からのフィードバックは必ずありますよね。
UMLを使っているからといって、ドメインモデルを作っているとは限りません。極端に言えば、 オブジェクト指向で開発しているとも限らないのです。そこは注意が必要ですね。 | ||||||||
|
投稿日時: 2004-12-16 00:40
ukさんの仰る面もありますが、ただ私のはそう言う意図ではありませんので説明不足を補足致します。 例えば分析、設計、テスト等ではその工程から見たボトムを定義出来なければ限がありません。 # 開発工程は事前に使用言語が取り決められる為に、言語仕様が明確なボトムとなります。 具体的に言うと業務分析は 「情報」定義を一項目づつの流れとしてを追う事が出来ますし、 「事象」定義に関しては自分が言葉をどの様に認識しているのかまで意味を砕けます。 無論、そこまでする人は殆ど居ない訳ですが、では一般的にどうように工程の区切りが されているのかと言えば、巷にあふれる「書式定義された資料作成」それ自体が 工程完了となっている現場が非常に多いと感じます。 この結果生まれる資料は、 ・ヒヤリング内容を図式化しただけの、分析という日本語の意味を伺いたくなる様な分析資料 ・主処理＆正常処理しか記述されておらず、思想（構造概念）が全く存在しない整合性が主体となった設計資料 ・特定手順の結果、何かの値が出る事を確認した事が解る、努力のアピールが全面に押しだされた品質資料 等であり多くの方々がこの様な資料を幾度なく見てきていると思います。 結果、各工程で本来解決すべき事が解決されず、またその工程の着地点が次工程の開始地点を 意識されていない為に大きなズレを生み、多様な問題を生み出しているとも考えます。 そして特定の工程（設計）をする際に次工程（開発）の事を考慮する事が出来なければ 隣接する工程間（設計工程と開発工程）の接地面積が最小になる様な考慮も出来ず その結果、各工程の境界線を上手く引く事が出来ずにスコープ定義が崩れ。 良い仕事をする事が出来ないと考えます。 システム開発工程でお話をしましたが、一般的な仕事も理論は一緒だと考えます。 [補足の補足] ・主処理＆正常処理しか記述されておらず、思想（構造概念）が全く存在しない整合性が主体となった設計資料 ここで言う「整合性」はシステムではなく資料の整合性の事 序でに署名が付与されていないので手書．．．（なじぇ？） ----------------------------------------------------------- 日本の中心で、オフを叫ぶ（＠名古屋）。 ご意見募集中！ [ メッセージ編集済み 編集者: はにまる 編集日時 2004-12-16 01:00 ] | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.