赤坂さん、今晩は
藤倉です
> Rational(ROOM)のアプローチでは最初に並行性を考えて分析するわけですね。
> その上で、設計でのActiveオブジェクトから実際のタスク(あるいはスレッド)へ
> のマッピングに自由度を持たせているわけですね。これも良いですね(^^;;
と言うか、基本はダグラスさんが言うようにすべての外部オブジェクトは並列と考えます。
> 確かに、並行性実現方法が変わりやすい場合、Rose-RTを使って開発する方が、
> 保守開発が楽になりそうですね。
> でも、Rationalのアプローチの場合、Activeオブジェクト(並行性)ドリブンな分
> 析のためエンティティクラスの抽出が甘くなってしまわないか少し心配ですね。
ベースは並列なので、むしろエンティティクラスから出てくる順序制約の抽出に注意します。その意味で静的構造の分析・設計が重要になります。
> 結局、OOを使うメリットとして、従来のタスクありき(並行性ドリブン?)で開発
> するため、扱うデータなどの複雑さに対応できなくなってきている現状に対して、
> 静的構造をきちんとまとめるということがあるかと思います。
まったくその通りです。RoseRTの場合はタスク分割やタスク合成を、静的構造から出てくる順序制約に注意する以外は、デッドラインやパフォーマンスチューニング、メモリ制約から決定します。
> これを上手く出来れば、並行性については最初に検討しても、設計時に検討して
> もそれなりにメリットがありそうですよね。
と言うか、必要に応じて何時でも検討・変更できることが重要です。検討時期を指定することには特にメリットは無いでしょう。
> 並行性を最初に検討しないからといって、RealTimeUMLでコンテキスト図が不要
> (というか重要でない)と結論付けるのはどうかな、という気もします。
> # 確かにRationalのアプローチでは必須なのでしょうが…。
設計時に出てくる順序制約や並列性要求がアプリケーションについて本質的なものか、設計の都合で出てきた偽者か識別するには要求定義時に明確にする必要があると言うことではないでしょうか。
//T.Fujikura