オブジェクト指向モデリング [12] 2004年1月13日

12.1 実装作業の概要（2） ドメインの実装 機能の実装 アーキテクチャの実装 レイヤー構造 ユーザインタフェース 12. 概念モデルから実装まで 12.1 実装作業の概要（2） ドメインの実装 機能の実装 アーキテクチャの実装 レイヤー構造 役割の分担 人工物の作り込み ユーザインタフェース アプリケーション（機能） アプリケーション（機能） ドメイン（概念の世界） ドメイン（概念の世界） 永続化 概念レベル 実装レベル

13.1 アナリシスパターン（1） パターンランゲージ ソフトウェアにおけるパターン Christopher Alexander 13. 概念モデルの理解 13.1 アナリシスパターン（1） パターンランゲージ Christopher Alexander パターンの記述 パターン名 背景，問題意識 解決策 フォース（有効である状況，他のパターンとの関係） 体系づけられたパターンの順序 ソフトウェアにおけるパターン デザインパターン（GoF） アナリシスパターン（Fowler） アーキテクチャパターン（POSA） よい建築がもつ性質 無名の質（Quality Without A Name） 生き生きと生きること（alive） パターンの重層 得も言われる心地よさをもつシステムってどんなもの？

13.1 アナリシスパターン（1） Fowler, M., ”Analysis Patterns” よいモデル例 分析に現れるパターン 13. 概念モデルの理解 13.1 アナリシスパターン（1） Fowler, M., ”Analysis Patterns” 分析に現れるパターン 要求のエスカレーション 変更に強いモデル 知識レベル 制約記述 実装の考慮 アプリケーションファサード サポートパターン よいモデル例

13.2 責任関係（7） 知識レベルと操作レベル 操作レベルの型の制約を記述 鏡像関係 人 組織 期間 作業 パーティ 責任関係 パーティ型 13. 概念モデルの理解 13.2 責任関係（7） 知識レベルと操作レベル 操作レベルの型の制約を記述 鏡像関係 inv: 　let collx:set(責任関係)=self.the責任関係 in 　collX->forALL（ x | x.型.依頼者->includes(x.依頼者.型) and x.型.実行者->includes(x.実行者.型)) 知識レベル 操作レベル 人 組織 期間 作業 パーティ 責任関係 1 * パーティ型 責任関係型 型 1..* 実行者 依頼者 有効期限

シラバス 授業計画 回 月日 内容 1 9月 30日 オリエンテーション：モデルとは何か。 2 10月 7日 モデリング言語：UMLの概要 オブジェクト指向モデリング シラバス 授業計画 回 月日 内容 1 9月 30日 オリエンテーション：モデルとは何か。 2 10月 7日 モデリング言語：UMLの概要 3 10月14日 静的モデル1：概念とクラス 4 10月21日 静的モデル2：関連 5 10月28日 静的モデル3：オブジェクト図 6 11月 4日 静的モデル3：オブジェクト図（続き），モデリング 7 11月11日 機能モデル1：ユースケース，シナリオ 8 11月18日 機能モデル2：要求抽出，協調図，シーケンス図，状態モデル：状態図 9 12月 2日 機能モデル2：活動図，静的モデル4：ユースケースに基づくモデリング 10 12月 9日 静的モデル4：モデルの揺さぶり 11 12月16日 実装レベル：実装モデルとプログラム，概念モデルの理解：アナリシスパターン 12 1月13日 概念モデルの理解：アナリシスパターン，実装モデルの理解：デザインパターン 13 1月20日 モデリング：例題によるモデル図の作成

13.3 勘定（1） 移動の記録 勘定（account） 多肢トランザクション 勘定科目 口座 勘定科目 仕訳記入 会計取引 1 * 13. 概念モデルの理解 13.3 勘定（1） 移動の記録 勘定（account） 勘定科目 口座 多肢トランザクション 実施日 04/1/12 計上日 勘定科目 売掛金 金額 31,500円 売上げ 30,000円 商品販売 預かり消費税 1,500円 消費税 借方 貸方 摘要 勘定科目 仕訳記入 会計取引 /残高 : 量 数量 : 量 実施日:時点 計上日:時点 1 * 2..* 1 　　　　　《business rule》 inv: 　self.仕訳記入.数量->sum = 0

シナリオ 航空券の購入：多肢トランザクション 　2001年5月1日，航空券を買うためにA航空に45,000円をクレジットカードで払った。2001年5月31日，当座預金からクレジット勘定へ，それを埋合わせる会計取引データを作成した ：仕訳記入 ：会計取引 2001年5月1日 クレジット：勘定 －45000円 ：仕訳記入 ＋45000円 A航空：勘定 ：仕訳記入 －45000円 ：会計取引 2001年5月31日 当座預金：勘定 ：仕訳記入 ＋45000円

13.3 勘定（2） 移動の記録 二肢トランザクション /残高＝self.~繰入.移動量->sum - 13. 概念モデルの理解 13.3 勘定（2） 移動の記録 二肢トランザクション 実施日 04/1/12 計上日 勘定科目 売掛金 金額 31,500円 売上げ 30,000円 商品販売 預かり消費税 1,500円 消費税 借方 貸方 摘要 実施日 04/1/12 計上日 貸方勘定科目 売掛金 借方勘定科目 売上げ 金額 30,000円 摘要 商品販売 預かり消費税 消費税 1,500円 導出： 　/残高＝self.~繰入.移動量->sum - self.~払出.移動量->sum 1 1 勘定 会計取引 繰入 * * /残高：量 1 移動量：量 実施日：時点 * * 「もの－こと－もの」のパターン；どこからどこへの移動を表す 払出

シナリオ 航空券の購入：二肢トランザクション 　2004年1月5日，航空券を買うためにA航空に45,000円をクレジットカードで払った。2004年1月31日，当座預金からクレジット勘定へ，それを埋合わせる会計取引データを作成した 払出 クレジット：勘定 A航空：勘定 当座預金：勘定 /残高= 0円 /残高=50000円 ：会計取引 移動量=45000円 実施日=2004年1月5日 /残高=－45000円 /残高= 0円 繰入 繰入 /残高=45000円 ：会計取引 移動量=45000円 実施日=2004年1月31日 払出 /残高= 5000円

13.3 勘定（3） 要約 ロールアップ 13. 概念モデルの理解 勘定 仕訳記入 会計取引 要約勘定 明細勘定 * * 0..1 1 * ｛抽象｝ 勘定 構成要素 * / 残高 : 量 ｛階層} /対象仕訳記入 * 0..1 仕訳記入 会計取引 要約勘定 明細勘定 対象仕訳記入 数量 : 量 実施日：時点 計上日：時点 1 * 2..* 1 inv: /対象仕訳記入＝self.対象仕訳記入 inv: /対象仕訳記入＝self.構成要素./対象仕訳記入

旅費交通費：要約勘定 航空旅費：要約勘定 A航空：明細勘定 B航空：明細勘定 クレジット：明細勘定 ：仕訳記入 ：仕訳記入 ：仕訳記入 構成要素 航空旅費：要約勘定 構成要素 A航空：明細勘定 B航空：明細勘定 クレジット：明細勘定 /対象仕訳記入 /対象仕訳記入 対象仕訳記入 ：仕訳記入 ：仕訳記入 ：仕訳記入 ：仕訳記入 ＋45000円 ＋66000円 ＋128000円 －45000円 ：会計取引 2001年5月1日 ：会計取引 2001年1月31日 ：会計取引 2001年11月21日

14. 実装モデルの理解 14.1 デザインパターン 14.2 Composite 14.3 State 14.4 Observer オブジェクト指向モデリング 14. 実装モデルの理解 14.1 デザインパターン 14.2 Composite 14.3 State 14.4 Observer 14.5 ObserverとMVC

14.1 デザインパターン（1） Design Patterns （1995） ソフトウエアパターンが世に知られる契機に 14. 実装モデルの理解 14.1 デザインパターン（1） Design Patterns （1995） GoF（Gang of Four） Gamma, Helm, Johnson, and Vlissides ET++に出てくるプログラムのパターン（Gamma） よいクラス設計のためのレシピ集 Johnsonにパターン化を勧められる ソフトウエアパターンが世に知られる契機に パターンランゲージではない

14.1 デザインパターン（2） 生成に関するパターン 構造に関するパターン 振る舞いに関するパターン 14. 実装モデルの理解 14.1 デザインパターン（2） 生成に関するパターン Abstract Factory Builder Factory Method Prototype Singleton 構造に関するパターン Adapter Bridge Composite Decorator Façade Flyweight Proxy 振る舞いに関するパターン Cain of Responsibility Command Interpreter Iterator mediator Memento Observer State Strategy Template Method Visitor

14.2 Composite（1） 構造に関するパターン 木構造の一般形 Component * Composite Leaf C B D 14. 実装モデルの理解 14.2 Composite（1） Compositeの集合 子 子 構造に関するパターン 木構造の一般形 子 C B D A E 子 F {階層} G 子 * 子 子 Component Leafの集合 {abstract} Component children operation() add(Component) remove(Component) getChild() * Composite Leaf operation() add(Component) remove(Component) getChild() children.operation() operation()

14.2 Composite（2） 要約勘定の例 14. 実装モデルの理解 Account * DetailAccount {abstract} Account balance() * DetailAccount SummaryAccount children Entry amount Transaction postedDate 2..* entries getAmount() {完全} public abstract class Account { public abstract int balance(); ： public class DetailAccount extends Account { private Vector entries = new Vector(); public int balance() { int total = 0; Iterator iter = entries.iterator(); while(iter.hasNext()){ Entry entry = (Entry)iter.next(); total += entry.getAmount(); } return total; 　　　　　　　　　　　　　　　　　　　： public class SummaryAccount extends Account { private Vector children = new Vector(); public int balance() { int total = 0; Iterator iter = children.iterator(); while(iter.hasNext()){ Account account = (Account)iter.next(); total += account. balance(); } return total; ：

14.3 State（1） 振る舞いに関するパターン 内部状態が変化したときに，その振る舞いを変える 状態に依存した振る舞いを局所化 14. 実装モデルの理解 14.3 State（1） 振る舞いに関するパターン 内部状態が変化したときに，その振る舞いを変える 動的分類の実装方法の一つ 状態に依存した振る舞いを局所化 状態ごとの振る舞いを用意 ConcreteStateはsingleton Context {abstract} State state.Handle() * Request() state Handle() state ConcreteStateB Handle() ConcreteStateA

14.3 State（2） 条件分岐を外部クラスに Stateパターンを使わない場合との比較 従業員 * 14. 実装モデルの理解 従業員型 Request() state {abstract} 従業員型 給与計算() * 技術職型 営業職型 条件分岐を外部クラスに Stateパターンを使わない場合との比較 public class 従業員 ｛ private 従業員型 _state; private Money _salary; public void setState(従業員型 s) { _state = s; } public void Request( ) { _salary = _state.給与計算( ); public class 従業員型 ｛．．．｝ public class 営業職型 extends 従業員型 { public Money 給与計算( ) { return 基本給 + 成績給( ); private Money 成績給( ) {...} public class 従業員 ｛ private Money _salary; private char _state; public void setState(char s) { _state = s; } public void Request( ) { if(_state == ‘1’) 　 _salary = 基本給 + 成績給( ); else if(_state == ‘2’) 　　　　　　_salary = 基本給 + 資格給( ); else ...; private Money 成績給( ) {...} private Money 資格給( ) {...}

14.4 Observer（1） 振る舞いに関するパターン ある観測対象に複数の観測者 観測対象の変化をできるだけ早く知るには 14. 実装モデルの理解 14.4 Observer（1） 振る舞いに関するパターン ある観測対象に複数の観測者 観測対象の変化をできるだけ早く知るには ポーリングではコンピュータリソースを消費しすぎる 変化があったことだけを通知（notify）する（callback） 通知を受けた観測者が変化情報を取りに行く {abstract} Subject Notify() Attach(Observer) Detach(observer) Observer update() * observer subject ConcreteObserver observerState ConcreteSubject SetState() GetState() subjectState observerState= subject.GetState() observer. update() return subjectState フレームワーク側

14.4 Observer（2） 拡張部分が一方向の参照になるように Observerの登録 事象の通知 状態へのアクセス 14. 実装モデルの理解 14.4 Observer（2） 拡張部分が一方向の参照になるように Observerの登録 事象の通知 状態へのアクセス :ConcreteSubject a:ConcreteObserver attach(this) :ConcreteSubject a:ConcreteObserver b:ConcreteObserver setState() 1:notify() 2つめのConcreteObserver オブジェクトに対する変更事象発生の通知 1.1:update() 1.1.1:getState() 1.2:update() 1.2.1:getState()

14.5 ObserverとMVC（1） POSAのMVCパターン ConcreteSubjectを分離せず 14. 実装モデルの理解 14.5 ObserverとMVC（1） POSAのMVCパターン ConcreteSubjectを分離せず ConcreteObserverを2つのサブクラスに 異なる責務を配置 {abstract} Subject Notify() Attach(Observer) Detach(observer) Observer update() * observer subject ConcreteObserver observerState ConcreteSubject SetState() GetState() subjectState {abstract} Observer update() * View display() makeController() Model notify() attach(Observer) detach(observer) setState() getState() state 生成する 表示を 　指示する Controller

14.5 ObserverとMVC（2） GUIのパターン 層別化の基本的アーキテクチャ 2種のObserverに通知 U/I 14. 実装モデルの理解 14.5 ObserverとMVC（2） {abstract} Observer update() * View display() makeController() Model notify() attach(Observer) detach(observer) setState() getState() state 生成する 表示を 　指示する Controller GUIのパターン 2種のObserverに通知 層別化の基本的アーキテクチャ U/I アプリケーション ドメイン seｔState() 1:notify() 1.1:update() :Model :Controller :View 1.2:update() 1.1.1.1:getState() 1.2.1:getState() 1.1.1:display()

15. モデリング 15.3 酒屋の在庫問題 予習 課題 　　 酒類卸売り業のA社の倉庫には，仕入注文に応じて，メーカから毎日数個のコンテナが搬入されてくる。その内容はビン詰めの酒で，１つのコンテナには10銘柄まで混載できる。扱い銘柄は約200種類ある。倉庫係は，商品（酒）をコンテナから取り出して倉庫に保管し，それを記録した入庫表を受付係へ手渡す。また受付係からの出荷指示によって倉庫から商品を出荷することになっている。 　　　さて，受付係は毎日，納入希望日の前日までに，電話で小売店からの注文を受ける。受付係は，その都度注文票に記入し，そのコピーを出荷指示として倉庫係に渡す。注文の納入希望日の当日朝時点で当該商品の在庫数量が不足する場合には，不足分について在庫不足リストに記入し，当日の夕方に，入庫希望日別，商品別に集計して，メーカに仕入注文を出す。翌日入庫希望分は，翌日の夕方に入庫される。 　　A社の，仕入，受注，出荷をサポートする情報システムの概念モデル を作成せよ。