＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
ロバストネス分析から実装レベルの相互作用図の依存度は
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-06-18 14:11
こんにちは、凪です。
オブジェクト指向設計を勉強中です。 ロバストネス分析から実装レベルの相互作用図を作成し、クラス間の依存度を検討してみると、コントロールオブジェクトの依存度が高いような気がしませんか？ 例えば、日々の日記を付けるようなWebアプリを開発する場合で、''日記をつける'' という機能があって、日記には写真がついているとします。 ロバストネス図では、 (図1) 日記UI ------ 日記コントロール ------ 日記 ∟----------- 写真 こんな感じになるのではないかと思っているのですが、実際にJ2EEで実装する場合は、依存度が低くなるように、 (図2) 日記UI ------ ファサード -------- 日記DAO ------ 写真DAO (日記DAOと写真DAOは、1 - 0...* の関係です) という具合にされませんか？ ドメイン分析をするとすんなり、図2の関係が出てくるのですが、ロバストネス分析では、エンティティとエンティティの関係はあまりつかわない(あるホームページでは利用しないまで書かれていました)ように推奨されていました。 ロバストネス図を実装レベルで設計しなおすと上記のように関係が変わるのは普通のことなのでしょうか？ ご教授ください。 [ メッセージ編集済み 編集者: 凪 編集日時 2004-06-18 14:13 ] | ||||||||||||
|
投稿日時: 2004-06-18 23:51
ロバストネス分析は、本で読んだだけなので詳しくないのですが。
図１の分析が単純すぎるから違和感を感じるのでは？ たぶん暗黙的にわかるから省いてるのかもしれませんが・・・ １つの日記に複数の写真があるなら、写真リストエンティティが必要だとか、 写真を登録するためのインタフェースが必要だとかいうのを 探しだすのが目的で、実際のモデルとは別と考えていいのでは？ 基本的に画面はもちろん、ボタンやリストボックスなども コントローラとして定義していますよね？＜ロバストネス図 あと、ロバストネス図と実装レベルで設計は別と考えて良いと思います。 ちなみにユースケース入門に以下のように書かれています。
# 個人的な考えです。有識者の方、間違い等ご指摘お願いします。 | ||||||||||||
|
投稿日時: 2004-06-19 11:40
私はロバストネス分析で生成したモデルとベースに実装レベルのモデルを設計するものだとばかり思っていました。(アーキテクチャやパターンを適用させたりして)
確かに[書籍：実践UML―パターンによるオブジェクト指向開発ガイド]では、ロバストネス分析を用いずに、ドメイン分析で設計をしていますね。 両方のモデルを上手に使うにはどうしたらいいのでしょうか？ 素朴にロバストネス分析のモデルとドメイン分析のモデルで出来上がるクラス図は別物になったりするような気がしています。 ロバストネス分析では図１ができそうですし、ドメイン分析では図２ができそうです。
仰るとおり、写真エンティティのライフサイクルを管理するリストを扱うエンティティは必要ですね＞単純化しすぎちゃいました。 ということは、ロバストネス分析では、インタフェースにどのようなものが必要かということを精査する為や顧客にどのようなUIがあるのかを説明したりするためのものであり、そのモデルは実装レベルのモデルを作成するインプットとしては情報が足りないということですね。
すいません、こちらの意味がよくわかりませんでした。 ロバストネス図のコントロールは、ビジネス層のサービスを祖粒度のサービスに まとめるようなFacadeのイメージを持っていたので、ボタンやリストボックス は、バウンダリの一部と考えていました。
この書籍の名前教えてください。一度呼んでみたいと思います。 | ||||||||||||
|
投稿日時: 2004-06-19 13:20
すいません、思いっきりボケてました。
おっしゃる通り、バウンダリが正解です。 書籍は、こちらになります。 ユースケース入門―ユーザマニュアルからプログラムを作る | ||||||||||||
|
投稿日時: 2004-06-20 12:01
objectです。
>凪さん >ドメイン分析をするとすんなり、図2の関係が出てくるのですが、ロバストネス分析では、エンティティとエンティ >ティの関係はあまりつかわない(あるホームページでは利用しないまで書かれていました)ように推奨されていま>した。 ロバストネス分析を使用する手法によっては、 1）アクターはバウンダリとだけ通信できる。 2）バウンダリはアクター、コントローラと通信できる。 3）エンティティはコントローラと通信できる。 4）コントローラはバウンダリ、コントローラ、エンティティと通信できるがアクターとは通信できない。 等の制約を課しているものもあるようです。 でも、これは目的があってそうしている訳で、その手法のその部分でのスタンスを考える必要があると思います。 >ロバストネス図を実装レベルで設計しなおすと上記のように関係が変わるのは普通のことなのでしょうか？ 忘れてならないのは、ロバストネス分析の意味ではないでしょうか？ ロバストネス分析の目的は、本来「システムに頑健な構造を付与する事」だと思います。 #この場合の頑健さとは、主に変更容易性と拡張可能性だと思います。 従って、実装（構築）レベルで問題が発覚し、それがロバストネス分析に影響するという事はありうると思います。 但し、本来ロバストネス分析の方が純粋にシステムの本質を把握できている筈なので、そこは十分考慮する必要があると私は思います。 大切なのは、「機械的・マニュアル的にロバストネス分析を適用しない」という事ではないでしょうか？ [ メッセージ編集済み 編集者: object 編集日時 2004-06-20 12:16 ] | ||||||||||||
|
投稿日時: 2004-06-21 09:35
なるほど、上記の【スタンス】というのはすごく納得いきました。確かにロバストネス分析に制約を持たせてシステムの構造を表現する方が分かり易いですね。 問題領域の関連などは、別の図やアーキテクチャ設計での方針を元に実装レベルのクラスで表現すればよさそうな気もします。 若しくは大規模なシステムは、ロバストネス分析をシステムの構造を表現するモデルで利用し、問題領域の関係は別途、ドメイン分析を行って、分析段階の成果物としてロバストネス分析でシステム構造をドメイン分析で問題領域の関係を成果物として作成するのが良いのでしょうね。 ただ、この2つのモデルをどのように実装レベルの設計に生かすのかが難しそうですが。 | ||||||||||||
|
投稿日時: 2004-06-21 12:59
objectです。
>ただ、この2つのモデルをどのように実装レベルの設計に生かすのかが難しそうですが。 「この2つのモデル」というのは、 ・ロバストネス分析 ・相互作用図 での成果を指すのでしょうか？ 私は、ロバストネス図(分析)は、クラス図、シーケンス図（相互作用図）等に生きていると思っています。 #UMLでは、ロバストネス図(分析)を成果とは考えてないようですが…。 [ メッセージ編集済み 編集者: object 編集日時 2004-06-21 13:14 ] | ||||||||||||
|
投稿日時: 2004-06-21 13:45
すいません。言葉足らずでした。
【この２つのモデル】は ・ロバストネス図(クラス図と相互作用図) ・ドメインモデル ⇒ こちらの方は知識不足なのですが、問題領域のクラス関連をモデル化したもので、簡単にはエンティティの関連と相互作用がモデル化されているものだろうと認識しています。 ロバストネス図は、システムの構造をインタフェースの視点で表現したもので、ドメインモデルは、問題領域に重点を置いて表現したものと考えており、一番最初に投稿させていただいた依存度の低いクラス関係等はドメインモデルで洗い出されるのかと思っているのですが、どうでしょうか？ 具体的には、 (あまり的確な例ではなく、実際にはもっと複雑になると思いますが、) 【ロバストネス図】 日記UI ------ 日記コントロール ------ 日記 ∟----------- 写真 【ドメインモデル】 1 1...* {order} 1 0...* 日記帳 -------- 日記 ---------- 写真(マルチ) ------- 写真 | 1 1 | ∟------- 作成者 1 1 という2つのモデルがそれぞれの分析によって作成され、アーキテクチャ設計を経て実装レベルのクラス図と相互作用図が出来上がるのかなと思っていまして、この設計が難しそうなイメージを持っています。 もしかして大きな間違いをしていますでしょうか？ | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.