メモ3

サブシステムの責務の振り分け

インタフェースの各操作に対し1つ以上の相互作用図を作成すべし。分岐がある場合はその数も含めて相互作用図を作成する。

サブシステムとカプセル化

完全なカプセル化を必要とするならば1サブシステムは1パッケージで作成する。完璧を求めないのであれば他のパッケージや他のサブシステムに依存させることも可。

バウンダリクラスの設計

ユーザーインタフェースを表す場合は1画面につきひとつのクラスとして作成。外部システムのインタフェースを表す場合はサブシステムとして作成。

エンティティクラスの設計

多くの場合分析段階で抽出したエンティティは設計段階でもつかえる。パフォーマンスを考慮してひとつのクラスのデータをアクセス頻度の高いものとそうでないものに分けることがある。

コントロールクラスの設計

責務を明確にして必要ならば分割する。また他のユースケースと機能が重複する場合などは汎化をもちいて整理する場合もある。

クラス名称

日本語・英語対応表はかならずつくること。

状態の定義

ステートチャート図を使った状態定義は複雑なものだけクラスに対してクラス単位で行う。

派生属性

他の属性の値に基づいて算出できる属性のことであり、スラッシュをつけて表記する。これは実装者に対して、キャッシュにとるか要求されるたびに算出するか検討の余地があることを示す。

属性

関係で結びつけれれている場合はこれを属性とは言わない。

関連クラス

多対多の関係を解決するために導入されるクラス。

多重継承

多重継承が問題になるときは継承と委譲を使用する。このときクラス間強度、メッセージ頻度を考えてどちらを継承にしどちらを委譲にするかを決める。

ロバストネス図

責務を明確にするために分析段階で使用する。設計段階では使用しない。設計時には分析時に導き出したクラス図と異なる場合がある。

相互作用図に現れるスーパータイプ

相互作用図が扱うのはオブジェクトであるが、あるオブジェクトがどのオブジェクトを見るかというときにどうそのオブジェクトが見えるかということが大事なので特定のサブタイプではなくスーパータイプを使う。

インタフェースとプロキシ

インタフェースはメッセージを受信するが送信は行わない。インタフェースの代わりにプロキシがメッセージ送信をする。