- - PR -
クラス設計などのあり方
1
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-04-12 16:51
Java クラスを設計する際のケースについて確認させてください。
以下のようなケースでどこまでのクラス設計、またはクラス設計自体の見直しが可能でしょうか。 そもそも不可能です、というようなご回答でも構いません。また、それぞれの理由などもあれば、 書いていただけると参考になります。そもそもそれがないと非効率的である、あって然るべき、など。 以下に該当するケースの経験があり、こういったことで苦労した、プロジェクトが頓挫した、 プログラマーは死にます、などもあれば、よろしくです。 ★ ケース １． 要件定義書しかない。 プログラマーはその業界外の人で業務自体の知識は全くない。 ２． a.要件定義書と b.機能設計書がある。 業務アプリケーションを構築する上での業務フローは a,b に記述してある。 プログラマーは各ミドルウェアのクラスライブラリーは使い慣れている。 ３． a.要件定義書と b.機能設計書、c.過去の業務アプリケーション があり、d.詳細設計書が 全くないが、機能追加の要件、JDKバージョンが上がることによる改修作業などが発生する 可能性がある。 また、 a,b が更新されていない状態で「実際のアプリケーションの動作」と矛盾する説明がある。 その a,b に基づいて、設計者はそれに気がつかず（というより Java が分からない）、 機能拡張要件の影響分析をし、それを Javaプログラマーに渡そうとしている。 | ||||||||||||
|
投稿日時: 2007-04-12 17:05
規模にもよりますがデスマーチのフラグが立ってますね。
> 以下のようなケースでどこまでのクラス設計、またはクラス設計自体の見直しが可能でしょうか。 クラス設計が不可能という事はないけど苦労します。 ソースからクラス図を起こせるツール(ツール クラス図などを使って探して)を 使って現状のソースからクラス図を作成してから考えると良いかもしれませんね。 業務知識など不明点が多いようなのできちんと設計者とお客さんまでのは橋渡しが出来る人がいないとまずデスマーチ確定♪ | ||||||||||||
|
投稿日時: 2007-04-12 17:14
1.論外。クラス設計以前の問題
2.それぞれの書類からUMLなりなんなりで図を起こして行けば、クラス設計はなんとかできる気がする。全体を俯瞰して調整できる人物がいれば、なお良し。 3.過去の業務アプリケーションの現状分析を行い、その段階で見つかった問題点と 改修コストと新規機能との絡み具合を見た上で、クラス設計を行う形がよいかと。 | ||||||||||||
|
投稿日時: 2007-04-12 18:11
＃過去の3つのご質問は拝見しましたので、そのつもりで書きます。
１．, ２．, ３． のどれも「要件定義」があるから大丈夫です。 -- unibon {B73D0144-CD2A-11DA-8E06-0050DA15BC86} | ||||||||||||
|
投稿日時: 2007-04-12 18:15
私は非オブジェクト指向時代の「詳細設計書」ではクラスを作ることはできないと考えています。
そもそもそれぞれの書類の役割というか位置づけというか定義が 会社もしくは現場ごとに違うので、議論したければそこを明確にする必要があると思いますよ。 「関数」に対してI/Oを決めるような視点ではクラスは作れません。 もっと広い視野が必要とされるますね。 クラスを作る際にはもちろん「機能」としての要件を満たさなければなりませんが、 「関数」を寄せ集めても使える「クラス」にはならないのです。 「クラス」というまとまりをどういう思想で作るのか−。 「要件」と「機能」が挙げられたところから、どういう「クラス」にするのか を考えるにはオブジェクト指向に対する深い知識と、業務要件に対する深い知識が 求められますから、SEの仕事、PGの仕事というわけ方が難しいですね。 クラスの外観が出来てしまえば個々のメソッドは書面で機能を提示して 実装をPGに委譲するということはできると思います。 | ||||||||||||
|
投稿日時: 2007-04-12 20:59
全部クラスを作ること出来ます。
ただ、１＞２＞３の順で自由度は減っていきますね。 １の場合はもう好きなように作成できます。 ただ、要件定義書の内容が抽象的だと 何を作っていいのかわからず 上流工程をこなすことになりますが。 | ||||||||||||
|
投稿日時: 2007-04-12 21:51
ユースケースレベルからクラスを設計するのは、
実務レベルではちょっと微妙かも。 使うフレームワークやミドルウェアによって 全然作り方が変わってくるので。 | ||||||||||||
|
投稿日時: 2007-04-12 22:20
どの状態でも業務要件定義書があれば、クラス設計そのものは、まこと簡単です。 class 業務 { public: 業務A(); 業務B(); ... } でいいわけですから。見直しだってやろうと思えば可能です。 要するに見直し項目がどれか、相手に決めさせて、それだけやればいいからです。 ・保守性->よく修正するクラスだけ「見直し」 ・性能->遅いとこだけ「見直し」 ・見栄え->悪く「見える」とこだけ「見直し」 実際は、こんなもんだと思いますけど。違うのかしら。 オブジェクト指向設計のフレームワーク上でUML設計をして デザインパターンを駆使して実装するのもいいのでしょうけど。。。 #一回やってみたいのだが。。。 。。。んなもんは保守できません。 もちろん新しく入った人が。 で、当然保守費が下がらず、要員が忙しいまま。。 でも、「正しい」クラス設計をしたとしても、保守費が下がるんですかね。 #といいわけしつつ放置(苦笑) | ||||||||||||
1
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。