＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
ロバストネス分析から実装レベルの相互作用図の依存度は
| 投稿者 | 投稿内容 | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-06-21 17:47
objectです。
それでは、凪さんは ・ロバストネス図(クラス図と相互作用図) ・ドメインモデル をどのように実装レベルの設計に生かすのかを重要視しているという事ですね？ >ドメインモデルは、問題領域に重点を置いて表現したもの ドメインモデルは、問題領域そのもの と考えるべきではないでしょうか？ 簡単に言えば、 ドメインモデルとユースケースで表現されるドメインに於ける問題構造が、 ロバストネス分析を経て、 静的・動的構造を表すクラス図・シーケンス図（相互作用図）として構築されていく と私は考えています。 基本的にはドメインモデルが直接的に実装に関わっていくべきでは無いと思います。 だからこそ、分析・設計プロセスが導入されているのではないでしょうか？ | ||||||||||||||||||||
|
投稿日時: 2004-06-21 18:50
あっ、ちょっと横道にそれちゃったんですが、最終的な目的は、 ロバストネス分析で作成された設計(分析)レベルのクラス図や相互作用図は、コントロールがエンティティに依存した関連で洗い出されるので、ビジネス層のクラス間の依存度が高くなる為、依存度を下げるように設計ができればと思っているんです。 ''この依存度を下げる設計''をどこですればよいのかなと思ったので、投稿させて頂きました。 (依存度を下げる設計がドメイン分析だとちょっと思ったので上記のような質問になってしまいましたが、) つまり、一番最初の投稿の
です。やっぱり、実装レベルの設計時に行うのでしょうか？ これは別の問題ですが、今までの経験上、設計(分析)レベル(ロバストネス分析)の設計者と実装レベルの設計者が異なる場合、ロバストネス図でできたクラス関係がそのままアーキテクチャを適用させて、実装レベルのクラス図に落とされてしまい、図２のような関係でソースコードができずに、図１の関係でソースコードが出来てしまいます。 アーキテクチャドキュメントにアーキテクチャの目標として、しっかりとクラス間の依存度を下げる方針を立てた上で、実装レベルの設計者に依頼する方法もあるのですが、なかなかうまくいかず、皆さんはどうされているのかなとご意見をお聞きしようと思った次第です。 | ||||||||||||||||||||
|
投稿日時: 2004-06-22 12:55
objectです。
>ロバストネス分析で作成された設計(分析)レベルのクラス図や相互作用図は、コントロールがエンティティに >依存した関連で洗い出されるので、ビジネス層のクラス間の依存度が高くなる為、依存度を下げるように設計 >ができればと思っているんです。 前に 1）アクターはバウンダリとだけ通信できる。 2）バウンダリはアクター、コントローラと通信できる。 3）エンティティはコントローラと通信できる。 4）コントローラはバウンダリ、コントローラ、エンティティと通信できるがアクターとは通信できない。 と書きましたが、 3）を「コントロールがエンティティに依存した関連で洗い出される」と言っていませんか？ 関連がある＝依存 という形で解釈されているという事はないですよね？ >''この依存度を下げる設計''をどこですればよいのかなと思ったので、投稿させて頂きました。 >(依存度を下げる設計がドメイン分析だとちょっと思ったので上記のような質問になってしまいましたが、) 「依存度を下げる設計がドメイン分析」という表現は、少し変ですよね？ 分析と設計は、基本的に異なるプロセスです。 分析・設計概念が曖昧な為に少し混乱されているのではないでしょうか？ >やっぱり、実装レベルの設計時に行うのでしょうか？ 基本的な部分では、私は最初のレスで答えているつもりなんですけど、 私は、ロバストネス分析（分析プロセス）の中で整理されるべきだと思います。 #当然、分析をどの程度詳細に行うかにもよりますが、ここでの成果はかなりの資産になると私は思います。 >これは別の問題ですが、今までの経験上、設計(分析)レベル(ロバストネス分析)の設計者と実装レベルの設 >計者が異なる場合、ロバストネス図でできたクラス関係がそのままアーキテクチャを適用させて、実装レベル >のクラス図に落とされてしまい、図２のような関係でソースコードができずに、図１の関係でソースコードが出来 >てしまいます。 これは、人の問題では無いと思います。 分析・設計を含む全プロセスが同じスタンスで実施されていれば、基本的には問題無いと思います。 例として考えておられる ----------------------------------------------------------- (図1) 日記UI ------ 日記コントロール ------ 日記 ∟----------- 写真 (図2) 日記UI ------ ファサード -------- 日記DAO ------ 写真DAO ----------------------------------------------------------- に関してですが、 この場合、(図2)と同じレベルで考えるなら、(図1)は、 日記UI ------ 日記コントロール ------ 日記(写真付) 程度で良いのではないでしょうか？ #でも、写真は最初から日記に付随、つまり同時に与えられたものとして存在するのですか？ #問題は、表現の仕方というより、表現される内容そのものの曖昧性ではないでしょうか？ それから、日記をただ単に(図1)の様に表記して、ドメイン分析になるのでしょうか？ 確かに、 日記 だけよりは、ましなのか知れませんが…。 [ メッセージ編集済み 編集者: object 編集日時 2004-06-22 14:39 ] | ||||||||||||||||||||
|
投稿日時: 2004-06-22 14:39
ロバストネス図のコントロールとエンティティの関係は実装レベルで基本的に【依存】【コンポジット】【集約】のいずれかの関係になると思っていました。
ロバストネス分析は、'3）エンティティはコントローラと通信できる。'の制約上、エンティティ同士の関係がモデルに定義できないが、ドメイン分析はエンティティ同士の関係が実装に近い形(カプセル化や委譲を考慮した関係)で出てくるので、そのような勘違いをしてしまいました。 そもそも、「機械的・マニュアル的にロバストネス分析を適用しない」ができていなかったから、まずかったということですね。 (言い訳をするわけではないのですが、書籍:UMLによるエンタープライズJava開発でロバストネス図をベースにEJBアーキテクチャを適用させて、そのまま実装レベルのモデルとしていた為、そのように思い込んでしまっていました)
その通りですね。
ここで例(この例が悪いですね)を挙げさせて頂いたのは、ロバストネス図だと図１のような、コントロールとエンティティの関係が抽出されますが、ドメイン分析の場合、エンティティ同士(少し御幣があるかと思いますが)の関係(依存度や凝縮性などを考慮して)が抽出できますよね。 「ロバストネス分析ではエンティティ同士の関係が洗い出せない」と思い込んでいたので、このような例になってしまいました。>そもそも目的が違うということですよね。
仰るとおり混乱しています。分析、設計、実装で何をすべきか、何を目標とするのかが、曖昧になっていました。各プロセスの成果物をどう次のプロセスに繋げるのかだけを考えていた為、本当に目的とすることが置き去りになっていました。 私なりに纏めると、 ロバストネス分析は、システムの構造を簡潔にモデル化するためやオブジェクトを抽出する為のものであり、実装モデルのオブジェクトの関連には参考程度に留める。 また、問題領域のオブジェクトの関係は、別途分析プロセスで整理するべきである。 実装モデルでのスタンス(拡張性や再利用性、依存度、凝縮性などの方針)は、開発メンバーで共有し、同じスタンスで開発に取り組む。 こんな感じでしょうか、私自身まだまだ理解できていないところがありますので、objectさんにご教授いただいたことを元に整理していきたいと思います。 | ||||||||||||||||||||
|
投稿日時: 2004-06-23 17:56
objectです。
UMLに関連する話題は、あらゆる問題に適用できる等、かなり華やかです。 しかし、それは逆に、それだけ汎用的な「認識論」とその「表現論」になって来ているという事だと思います。 因みに、ロバストネス分析に関しては、私は「I.ヤコブソン」の書籍を薦めます。 凪さん、大変だとは思いますが、今の様に問題意識をしっかり持って頑張って下さい！ [ メッセージ編集済み 編集者: object 編集日時 2004-06-24 00:44 ] | ||||||||||||||||||||
|
投稿日時: 2004-06-23 18:04
そうですね。実際に使い出そうとすると、どう使ったらよいのか悩む一方です。 試行錯誤しながら、実際に使って、もう一度書籍を読み直してという感じで少しずつ自社の中でモデルの利用価値を高めてますが、なかなか、これがベストだとはいきません。
UMLによる統一ソフトウェア開発プロセスがありますので、もう一度読みなおします。 いろいろと、ご教授頂きありがとうございました。 | ||||||||||||||||||||
|
投稿日時: 2004-06-24 16:10
ロバストネス図やオブジェクト指向自体の話ではありませんが、
当スレッドを読んでシステム開発（私は業務系）について感じた事を投稿致します。 モデル（図）は、物事を理解する時／表現する時に重要ですが、システム開発 本来の流れでは無く根底の流れは文字ベース情報であり、そのサポート情報として モデル図が存在していると考えます。 私は実務上で図を多用し、図から図を直接生成する事もありますが、それは頭の中で整理 出来るレベルの場合のみで図が持つ情報が膨大な場合、一旦、箇条書きで文書化し、 それから別の図を生成します。 投稿文書を読む限り、上流工程のモデル図から下流工程のモデル図を直接作成したり、 またはモデル図からのみプログラミングを行う様に捉えらたので疑問に感じました。 図は文書に比べ曖昧に成り易く、またモデル図からモデル図を生成する行為には 具体化、詳細化を欠く危険がある考えます。これは参照元と生成先の両モデル図に対し 粒度を意識してい無い結果と過去を振返り感じます。 後、システム開発時にどこで依存度を排除するか？ですが経験上では全工程です。 例えば分析の場合、今回「日記」を「日記」と捉えていますが、「日記」は、 「想い出を記録する物」、「想い出を閲覧する物」、「想い出を保管する物」と役割定義 すれば、その行為だけでも依存度を軽減する効果を得れます。 「意味不明じゃ！」と思う方もいると思いますが、依存度に注目する本来の目的は、 重複性を無くし、特定視点による意味合いに纏め、直接的な依存関係を断切り、外部との 接続関係を柔軟にする事により「部品化」及び「変更に強い」仕組み作りを行う為と 思います。 つまり、「日記は日記」と見なした時点で、重複性、纏り、接続関係が見えなくなります。 また早い工程タイミングで、依存度を排除する結果、各工程が本来持つ目的の精度自体を 上げ、それに続く下流工程の精度自体までもが向上すると考えます。 ただ、ここで気を付ける点は「各工程が本来持つ目的」を忘れない事。後、多くの システム開発プロセスを説明している技術書の多くは、「各工程が本来持つ目的」への 対処に注意を払っており、「効率的な対応」は二の次で扱われている事が多いと思います。 言わば効率的に作成しても、動かないシステムでは意味が無いからですが、 ただ、現実は「効率的な対応」と「各工程が本来持つ目的」の達成を二兎追わなければ 行けないのが辛い所です．．． | ||||||||||||||||||||
|
投稿日時: 2004-06-25 12:26
objectです。
>はにまるさん >モデル（図）は、物事を理解する時／表現する時に重要ですが、システム開発 >根底の流れは文字ベース情報であり、そのサポート情報として >モデル図が存在していると考えます。 要約： 1.モデル（図）は、物事を理解する時／表現する時に重要 2.根底の流れは文字ベース情報 3.サポート情報としてモデル図が存在 少しお聞きします。 1.->何故、モデル（図）が物事を理解する時／表現する時に重要だとお考えですか？ 2.->何故、根底の流れは文字ベース情報だとお考えですか？ 3.->何故、「サポート情報」としてモデル図が存在するのですか？ 文字ベース情報とモデル（図）は何が違うのですか？ そこを曖昧にしたままで、 「2.根底の流れは文字ベース情報」 と言えるのでしょうか？ >後、システム開発時にどこで依存度を排除するか？ですが経験上では全工程です。 >‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥ 以上の後半に付いては、「はにまるさん」が確信を持っておられる様なので、コメントはしません。 | ||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.