This is version 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

★このページは書きかけです。

実際の業務に近い形で考えてみる#

次のような業務シナリオがある場合のモデルを考えてみましょう。
入荷の予定を記入する伝票がある。入荷予定は以下の情報を持つ。

• 伝票番号
• 入荷予定日
• 仕入元会社(取引先)
• 入荷状態(未入荷/一部入荷/入荷済 のいずれか)
• 複数の商品の明細(商品名、個数)

商品が入荷した場合のため、

• 入荷日
• 入荷状態(未入荷/入荷済)

も必要となる。
上記は、商品ごとに分納が可能である前提とする。(商品Aは届いたが、商品Bは未入荷)
その上で、

• 全入荷伝票を検索・一覧表示する画面機能が必要である。
• 入荷伝票を登録するための画面機能が必要である。
• ある日に届いた商品の全明細を表示する画面機能が必要となる。

画面機能を持つ部分はそれぞれ一つのクラスとして省略設計して構わない。

オブジェクト図#

何はともあれ業務分析はオブジェクト図からです。
オブジェクト図を描く時のコツは、複数あり得るオブジェクトは必ず複数描くことです。以下の例で言えば、

• 入荷伝票
• 商品

がそれです。
scenario_obj.png

分析モデル#

続いて、クラス名だけのクラス図を描いてみます。
scenario_analyze.png
青色を付けてあるのが画面機能クラスです。
見落としがちな点は次です。

1. 採番する際に伝票番号一覧が必要となる。
2. 伝票入荷状態と明細入荷状態は異なるクラスである。
3. 入荷明細一覧画面は入荷伝票ではなく入荷明細一覧を扱う。

特に3は大切です。入荷明細一覧画面は入荷伝票が何であるか関係なく入荷明細を一覧表示する必要があります。この時、入荷明細一覧クラスが無いとうまく実装できなくなります。

設計モデル#

分析モデルを洗練し、処理を記述します。