貨物輸送システムの紹介 (P163-P166) †
要約 †
貨物船会社のための新しいソフトウェアを開発している。初期の要件は3つの基本機能。
- 顧客の積荷をトラッキングする
- あらかじめ積荷を記録する？
- いくつかのポイントに積荷が到着した際、自動的に顧客に送り状を送付する
実プロジェクトでは、このモデルを明快にするのにある程度の時間とイテレーションが必要。その辺の過程はパート�靴播按貪�にやるが、ここでは雛型として必要な概念を持っているモデルから始め、デザインしやすくするために詳細の微調整に焦点をあててみる。
図7.1 出荷ドメインのモデルを表すクラス図
このモデルから以下のようなことが言える: (P.164-1)
- 「複数のCustomersがそれぞれ異なる役割でCargoに関わる。」
- 「Cargoの配送目標は明確である。」
- 「Delivery Specificationを満たす一連のCarrier Movementsが配送目標を実現させるだろう。」
モデルの各オブジェクトの意味 †
- Handling Event (P.164-2)
- Cargoと共に取られた個別の行動で、船への荷積み、荷下ろし、税関を通す、受領者による請求？などのこと。
- Delivery Specification (P.165-1)
- 配送目標を定義し、最小限、目的地と到着日付を含むが、より複雑な場合もある。SPECIFICATIONパターンに従う。
この責務はCargoでも良かったが、この抽象化には少なくとも3つの利点がある。
- これがないと、配送詳細を指定する場合にCargoオブジェクトがそれらのすべての属性とつながりの詳細に責任をとらねばらなず、取り散らかり、理解したり変更するのがより困難になる。
- この抽象化で、モデルをまとめて説明するときに詳細を端折るのが楽になる。
例えば、Delivery Specificationに他の判定基準が隠蔽されているかもしれないが、詳細な図でそれを公開する必要はないだろう。
図は配送のSPECIFICATIONがあると言っており、その詳細は思考する上で重要ではない。（実際、後で簡単に変えることができたし）
- このモデルはより表現が豊かで、正確な配送手段をCargoでは決定せず、Delivery Specificationでそれを達成することが明確になる。
- role (P.165-3)
- Customerの役割。荷主、受領者、支払者など。関連はmany-to-manyではなくmany-to-one。
単に文字列として実装されるかもしれないが、他の振る舞いが必要ならクラスかもしれない。
- Carrier Movement (P.165-4)
- あるLocationから別のLocationまでのトラックや船などによるCargoの移動を表す。
- Delivery History (P.165-5)
- Cargoに起こった事象の履歴。最後の荷積みや荷下ろしからCargoの現在のLocationに対するCarrier Movementの目的地を求められる。うまく配送されれば、Delivey Specificationの目標を満たしたもので終わる。
- 永続化のための手段も仮定して、要件を満たすのに必要な全ての概念がこのモデルに存在する。実装上の問題はモデルでは対処されないが、デザインにはそれがあるに違いない。(P166-1)
- よりしっかりした実装にするために、更なる明確化と引き締めが必要。(P166-2)
- 通常、モデルの洗練、デザイン、実装の繰り返しにより、なせるものであることを忘れないこと。本章では説明のために比較的熟したモデルから始めているし、変更はパターンを使った実際の実装に則したものとなっている。(P166-3)
- また、モデルがデザインをよりよく維持するために洗練するとき、ドメインに関する新しい洞察を反映するために洗練されるべきだが、以下同文。(P166-4)
担当者のつぶやき †
- すみません、ここが出来てないと後が書きづらいですよね。。何とか土日前に片付けたので、あとの人頑張って下さいm(_ _)m
- 送り状はモデルには現れないんですね。送付することは重要だけど、その内容や送った記録みたいのは重要ではない、ということなんでしょう。
みんなの突っ込み †
