- - PR -
分析モデルと設計モデル、どこまで作成?
1
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-09-23 15:13
お世話になります。
分析モデルと設計モデル(クラス図)について、皆様は実際のプロジェクトでどこまで作成されていますでしょうか。 ここで分析モデル = ユースケースを元にアーキテクチャや実装を意識せず、必要なクラスや関係を表すクラス図、だと考えています。 また、設計モデルは分析モデルを元に、アーキテクチャや実装をよく踏まえて作成したクラス図を意味するものとします。 そこで、「設計モデル = 分析モデルを詳細にしたもの」ではないと思うのですが、それぞれを作成するのにはかなりの時間や労力がかかり、2つのモデルを同期させるのも大変なことが多いです(横着してどちらか一方だけ修正して、整合性が取れなくなるなど)。 実際のプロジェクトでどのようにされているか、またどのように考えるべきか、詳しい方がおられましたら教えて頂けないでしょうか。 | ||||||||
|
投稿日時: 2008-09-23 17:13
なにを作るのかが決まっているのならば、分析モデルは要らないでしょう。分析モデルはなにを作ればよいのか分からないから必要なものです。そういう考えで行けば、設計モデルだけ作って、そこからソースコードを実装すれば良いです。 ただ上記の「なにを作るのかが決まっている」という状態についてですが、たとえば、ワープロのソフトウェアを作る場合、「フォントスタイルを可変できる。文字色を設定できる。アンドゥができる。」などという要求仕様があっても、それでは到底、モノは作れません。 フォント属性は文字単位の開始位置と終了位置で持つ、アンドゥはデザインパターンのコマンドパターンを使う、などは分析しておく必要があります。もっとも、詳細度の考え方にもよりますが、こういうのは分析ではなく設計だ、という考えだったら、分析モデルは要らないでしょう。 | ||||||||
|
投稿日時: 2008-09-25 12:54
unibon様、早速アドバイス頂きありがとうございます。
分析モデル、設計モデルを作る目的を踏まえて、どうすべきか考えてみたいと思います。 | ||||||||
|
投稿日時: 2008-09-28 12:11
分析モデルで問題を把握し、設計モデルでその問題対処を考える場合、分析モデルと設計モデルで対応する箇所はありますが、同義ではありませんしどちらかと言えば別ものです。 これは現実社会を考えて、問題と解決策が別ものである事を思い出されればよろしいかと思います。 例えば、おなかが減る人体の現象と、パン食べるという行為は別ものであり、それを結びつけるものは”食べればお腹は満たせる”という過去の経験知識でしかありません。 また私達（日本人の大人）が”おなか減った”と言葉に表した場合”とりあえず何でもいいから食べさせて欲しい”というモノでは無いように、本来、要求とは端的な言葉として表現し難いものです。 その表現し難い要求を分析モデルで理解を深め認識を他者と共有するのであって、それを解決するか否か、どう解決するのか、はたまた解決できるかどうかは全く別の話になります。
分析モデル、設計モデルをどこまで作成するかは、分析モデル、設計モデルが使いこなせて考える事になります。道具の使い方と効用がわかって、道具を利用する状況に対応でるように成るのと一緒です。 決まり切った作業の道具であれば利用状況も方法も定まりますが、ソフトウェア開発では作業自体が千差万別なため、道具の利用方法とは別に利用場面の理解と状況に応じた適用能力が要求されます。 | ||||||||
|
投稿日時: 2008-09-28 21:37
私もその様に思います。 昔は分析モデル、クラス図など書かずとも、それなりにシステムは作れてましたから 通信等は状態遷移図等の方が重要になりますし。。。。 オブジェクト指向が入ってからはちょっと変わってきましたが。。。。 ちなみに、私はクラス図はまったく作りません。インスタンス図もどきを作成します インスタンス図の方が直感的理解度が上がりますし、かつ クラス図はリファクタリングを阻害すると考えてます。 （特にSEとPGが分離された場合、そう作らなければならないと思われる） 参考になればと思います。 | ||||||||
|
投稿日時: 2008-09-28 22:03
かつひとさんこんにちは。
そう思います。 分析モデルは対象とするドメインの持つ本質を把握し、設計はユースケースの実現方法を定義することなので、設計モデルが変わっても分析モデルは影響受けないはずです。 分析モデルにまで変更が入るということは、分析に誤りがあった場合のみです。 それに対して実現方法は正解が何通りもありますから、誤りがあったときはもちろん、方針が変われば修正が必要になります。 クラス図は頭の中を整理すると同時にコミュニケーションツールですから、それに必要なときにやればいいと思います。プロジェクト途中は省略し、完了時に自動生成するとかでも良いと思います。 ただし、簡単なものでも開発メンバ間で意思が伝わらないようなら、ホワイトボードを活用でもいいからモデリング（クラス図以外も）して情報や考え方を共有するべきだと思います。 | ||||||||
|
投稿日時: 2008-09-29 00:57
どもです。
ご自身でお話の通り、やはりモデルを作る目的を明確にするべきです。 短納期で実現しなければならない難解なものであれば、分析モデルに絞り急所をおさえる。 時間に余裕があれば、モデルを理解する必要のある人にとって意味のあるものにする。 何にしてもモデルは一人で時間をかけて作るというより、有識メンバーで叩いて 意味のあるものに仕上げていくという考え方が重要であると思います。 ちなみに設計モデルは、システムアーキテクチャ(フレームワーク全体像、セキュリティ、性能要件担保方法など)の考慮までで個人的にはやめておきます。管理が煩雑になるので。 細かい実装(デザインパターン適用など)は、都度コミュニケーションすれば事足ります。 | ||||||||
1
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。