オブジェクト指向設計はトップダウン的アプローチ(ドメインモデルからクラス設計),ボトムアップ的アプロー

投票結果総投票数：50
トップダウン的アプローチ(ドメインモデルからクラス設計)	29票	58.00%
ボトムアップ的アプローチ(処理手順からクラス設	21票	42.00%
投票は恣意的に行われます。統計的な調査と異なり、投票データの正確性や標本の代表性は保証されません。投票結果の正当性や公平性について、＠ITは一切保証も関与もいたしません。

投稿者

投稿内容

やまろう: 常連さん; 会議室デビュー日: 2003/10/13; 投稿数: 35; お住まい・勤務地: 埼玉・東京

投稿日時: 2004-12-09 14:39

オブジェクト指向の技術力トップクラスの有名ベンチャー企業の面接に行ってきました。さすが！と言うほど技術力を感じました。OOPの話から開発プロセス、実装の話まで技術的な話が出来ました。

開発プロセスの話でXPとRUPの話になってその中でドメインをモデリング出来るか？ってことを聞かれたんですよ。業務を分析していく過程でドメインをモデリング(実装レベルより上のクラス図のようなもの)して、それをさらに実装レベルのクラス設計に落としていくみたいなんですけど、おおざっぱな分け方をするとRUP側のやり方でクラス設計をトップダウン的アプローチってことですよね。対してXPではストーリーカード、つまりは処理の手順を元にクラスを設計して行きますよね、つまりボトムアップ的アプローチといいますかね。

自分としてはプログラムってものを本質的に考えていくとOOPだろうが手続き型であろうが最終的にはマシン語になって処理の手順となるのだから、処理の手順を元にしてクラスを設計していくようなやり方の方が良い気がしています。現実世界をそのままクラスに当てはめてもうまくいかないと思うし、OOPというものをシンプルにポリモーフィズムで処理の流れ(呼び出す側のコード)を共通化するっていう観点で使っていけばいいと思うんですが、皆さんはどう思いますか？

この面接だとこのトップ企業はトップダウン的アプローチをしてるみたいですが、XPのケント・ベックも「UMLなんてほとんど使わない」と言ってたり、XP対RUP、オブジェクト指向の設計プロセスや上流で顧客に説明する、またはプログラマーとしての実装の観点等からご意見をお聞かせ下さい。

uk: ぬし; 会議室デビュー日: 2003/05/20; 投稿数: 1155; お住まい・勤務地: 東京都

投稿日時: 2004-12-09 18:07

XPでもRUPでも、ドキュメントを作るかどうか、とかプラクティスの違いはいろいろありますが、
問題にされている部分では、基本的な思想はそう変わらないと思いますよ。まずはユーザから
見た機能ありきで、その機能を表現する手段がユースケースだったりユーザストーリーだったり
するだけだと思います。

それから、XPを表面的に捉えすぎているように思います。XPの推進者であるファウラーの
「アナリシスパターン」やケント・ベックの「実践CRCカード」を読んでみてください。現実
世界のモデルからプログラムコードまでを一貫した視点で捉えていることがわかると思います。

やまろう: 常連さん; 会議室デビュー日: 2003/10/13; 投稿数: 35; お住まい・勤務地: 埼玉・東京

投稿日時: 2004-12-09 18:55

なるほどー、XPでもRUPでもクラス設計へのプロセスはそんなに変わらないということですかぁ。RUPの方が成果物としてのドキュメントが多い分モデリングをしてるというイメージが強かったのかもしれません。頭の中や一時的なメモでやるかきれいなドキュメントになるかの差なんですかねぇ。もう少し開発プロセスを学んでみたいと思います。「アナリシスパターン」と「実践CRCカード」、ぜひ読んでみたいと思います。ということは現実世界のモデルからプログラムコードを設計していくというのが主流ということですね。

uk: ぬし; 会議室デビュー日: 2003/05/20; 投稿数: 1155; お住まい・勤務地: 東京都

投稿日時: 2004-12-09 19:17

引用:
やまろうさんの書き込み (2004-12-09 18:55) より: ということは現実世界のモデルからプログラムコードを設計していくというのが主流ということですね。

実際には、RUPやXPそのものには、このような設計アプローチを取る、ということは明示されて
ないと思います。製品としてのRUPがどうなっているのかは知りませんが、「UMLによる統一
開発プロセス」に記されている分析クラスはドメインクラスではなく、ロバストネス分析の
クラスですし、ドメインモデルを作るかどうかは「スコープ外」ではないかと。

ドメインモデルをプロセスとして作る、と明示しているものにはFDDがありますね。

skulker: ベテラン; 会議室デビュー日: 2004/06/08; 投稿数: 67

投稿日時: 2004-12-09 19:42

ドメインモデルから見る = トップダウン
処理手順から見る = ボトムアップ

という考え方にそもそも違和感を覚えます。(処理手順とはユースケースのようなものを想定しているのでしょうが、それとドメインモデルと抽象度にどのくらい差がありますか?)

トップダウンというのは、いわゆる構造化プログラミングのように、まず大きな抽象機械を考え、サブシステム分割、モジュール分割のようにブレイクダウンしていくという事をいうのだと思いますが。
ボトムアップは逆に細かな粒度のモジュールから始めて、それらを組み合わせてシステムを設計していくというものでしょう。

一般にオブジェクト指向分析・設計におけるオブジェクト(クラス)の発見は、トップダウンでもボトムアップでもないと思っています。同時多発的にオブジェクトを認識する感覚なのでは。

やまろう: 常連さん; 会議室デビュー日: 2003/10/13; 投稿数: 35; お住まい・勤務地: 埼玉・東京

投稿日時: 2004-12-09 21:22

引用:
skulkerさんの書き込み (2004-12-09 19:42) より: ドメインモデルから見る = トップダウン処理手順から見る = ボトムアップという考え方にそもそも違和感を覚えます。(処理手順とはユースケースのようなものを想定しているのでしょうが、それとドメインモデルと抽象度にどのくらい差がありますか?)

なるほど、確かにトップダウンとボトムアップっていう言葉の一般的な意味はそうでしょうね。私は感覚的に分析の中でドメインモデルという実装レベルよりも抽象的なモデルが出来てそれをさらに実装レベルへと落とし込んでいくっていうイメージから「トップダウン的」と表現しました。処理手順っていってるのは「詳細なユースケース」というか完成されるプログラム１行１行レベルの仕様くらいの詳細な手順というイメージで言っています。どんな分析設計方法をしても最終的には一連の処理の流れ(マシン語の羅列)がなるので、分析・設計のゴールはプログラム１行１行レベルの仕様なんだと思います。一連の処理の流れをどうクラスにわけて実装するかっていうやり方をボトムアップ的と表現してみました。

「分析・設計のゴールはプログラム１行１行レベルの仕様」という考えはマーチン・ファウラーの「新しいソフトウエア開発手法」って論文でJack Reevesは、「実はソースコードが設計書で、(建築でいう)モノ作りに相当するのは、コンパイラーとリンカーを動かしてる時間だけじゃないだろうか」っていう話と合ってるなぁと思います。コードを書くって作業が設計だってことで、これには私は大変感銘を受けました。これについてはどう思いますか？
http://www007.upp.so-net.ne.jp/kengai/fowler/newMethodology_j.html

それでドメインモデルを分析していくやり方も「プログラム１行１行レベルの仕様」を割り出してくためにまずドメインモデルを作って、結局最終的なクラスの設計は「プログラム１行１行レベルの仕様」から重複のないコードになるようなクラスの構造を作っていくのかもしれないなぁとか考えてみました。

それとも、ドメインモデルから分析していくとなんとなく自然と実装レベルのクラスの設計になっていくのかなぁ？結局、処理手順ってものが出来上がって、それを重複がないようにクラスに分割するんじゃないかなぁと思うんですけど…。その結果が現実世界のオブジェクトと近いものになるってことじゃないかなぁと。僕自身はともかく処理手順から設計してます。とはいえ、ukさんお薦めの「アナリシスパターン」と「実践CRCカード」を読んでみると何か変わるかもしれないなぁと。

[ メッセージ編集済み編集者: やまろう編集日時 2004-12-09 21:30 ]

るぱん: ぬし; 会議室デビュー日: 2003/08/01; 投稿数: 1370

投稿日時: 2004-12-09 22:13

るぱんです。

個人的にはグロスでボトムアップ→トップダウン→ボトムアップのスパイラルと考えてます。

ソースコード＝設計書のお話は、理想的なお話で、感銘を受けたことは僕も同じです。
しかし、全員が全員それを出来るわけではなく、
それでいながらなおかつ目指すべきことだという認識です。

理想は自分が突き進むもので、他人に対して強要しないのが原則ではないでしょうか？
理想状態にあれば設計屋さん＝実装者であるわけです。

理想は現実問題との乖離が起きてますよね。激しく。
具体的にどうすれば良いか・・・になりますが、
個人的には、できない人は単価が安くて、それでも、アサインがつく様な
環境があれば良いと思います。

ただ、現実はそれを許してはくれないわけですし。
矛盾してきますね。

階級を作る・・・ではなく、作業の割り振りになってくるんじゃないかと。
お互い話し合って納得できる環境があればそれでいいんではないでしょうか？

偉そうな事言って責任逃ればかりする人が上についたら悲惨ですけどね。

やまろう: 常連さん; 会議室デビュー日: 2003/10/13; 投稿数: 35; お住まい・勤務地: 埼玉・東京

投稿日時: 2004-12-10 14:37

引用:

るぱんさんの書き込み (2004-12-09 22:13) より:
ソースコード＝設計書のお話は、理想的なお話で、感銘を受けたことは僕も同じです。
しかし、全員が全員それを出来るわけではなく、
それでいながらなおかつ目指すべきことだという認識です。

理想は自分が突き進むもので、他人に対して強要しないのが原則ではないでしょうか？
理想状態にあれば設計屋さん＝実装者であるわけです。

なるほどー、確かに僕も理想を他人に強要してはいけないと思います。だけども、実際の仕事の場では理想(理念)が無い人があまりに多すぎる気がします。ただ仕事が片づけばいい、自分の責任にならなければいい。そんな環境から脱するために転職を考えています。いろいろ会社を廻っていてチャレンジ精神のあるよい会社があることがわかりました。そして、技術力トップと言われてる企業がどんなスキルを求めているのかということが少し分かってきました。

僕は自分の技術力にはとても自信を持っていたのですが、企業から指摘されて、それは実装技術(プログラミング技術)の部分だけだということが分かりました。ここで、もう一歩上の技術者を目指すには分析・設計の技術、要求から具体的設計へと落とし込んでいく技術を学ぶべきだと感じました。

こう思えたのも、面接で会った素晴らしい技術者の方々やこの会議室での皆さんの発言があったからだと思います。実際の仕事の場では理想(理念)が無い人が多くても、こうして理念を持ってる人たちがいるんだなぁと思って、やっぱ「自分は理想を突き進めていけばいいんだな」と思いましたv(^o^)

「僕らが何と戦えばいいのか分かった気がするんだ」キラ・ヤマト

1|2|3|4|5|6 次のページへ»

オブジェクト指向設計はトップダウン的アプローチ(ドメインモデルからクラス設計),ボトムアップ的アプロー

スキルアップ／キャリアアップ（JOB@IT）