オブジェクト指向モデリング [11] 2003年12月16日.

Presentation on theme: "オブジェクト指向モデリング [11] 2003年12月16日."— Presentation transcript:

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

2 10.2 活動図（6） プロセス図の課題 記法（活動図の拡張） 利益の源泉は何か 回転率を上げる（速い，安い，うまい）
10. 状態モデル 10.2 活動図（6） プロセス図の課題 記法（活動図の拡張） 利益の源泉は何か 回転率を上げる（速い，安い，うまい） ムダを出さない（予測型か調整型か） 予測（見込み生産） 実績（調理と販売） 中間製品で在庫するが，カスタマイズしない 価値の移動 物流と金流 付加価値 接客←従業員教育 素材 店舗の立地

3 11.6 揺さぶり（1） モデルの洗練 要求のエスカレーション 変更に強いモデルにする 本質的なモデルを追求する 11. 静的モデル4
店長 カテゴリ別の商品別売上げを得る 日別の商品別売上げを得る 調理係 商品ごとの調理時刻を記録する 窓口係 日別の利益額を得る 作り置きがあればそこから出庫する 作り置きがあればそこから出庫する

4 11.6 揺さぶり（16） 汎化も使って概念を整理 商品 明細 取引 現物 /売上 製造 廃棄 販売 カテゴリ 客タイプ
11. 静的モデル4 11.6 揺さぶり（16） 汎化も使って概念を整理 導出： the/売上.製造原価は，the明細.the取引とナビゲートして得られる取引オブジェクトの集合のうち，それぞれのサブタイプが「製造」または「廃棄」で，その日時の日が，the/売上.日と一致するものについて，the明細.数量を合計したものにこの原価を乗じて得る 商品 1 明細 商品名 単価 原価 数量 /金額 * 取引 日時 現物 ロット番号 /賞味期限 /売上 /売上金額 /製造原価 /利益 日 製造 廃棄 消費税はどうする 販売 ｛導出｝ カテゴリ 名称 客タイプ 性別 年齢層

5 シラバス 授業計画 回 月日 内容 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日 実装レベル：実装モデルとプログラム，モデリング1：アナリシスパターン 12 1月13日 モデリング2：デザインパターン，モデル図の作成，モデルの評価基準 13 1月20日 モデリング3：例題によるモデル図の作成

6 12. 概念モデルから実装まで 12.1 実装作業の概要 12.2 ユースケース 12.3 ドメイン層の実装
オブジェクト指向モデリング 12. 概念モデルから実装まで 12.1 実装作業の概要 12.2 ユースケース 12.3 ドメイン層の実装 12.4 アプリケーション層の実装 12.5 ユーザインタフェース層の実装 12.6 プログラミング

7 12.1 実装作業の概要（1） ソフトウエアプロセス フェーズとワークフロー 繰り返し 方向づけ 推敲 構築 移行 要求 分析 設計 制作
12. 概念モデルから実装まで 12.1 実装作業の概要（1） ソフトウエアプロセス フェーズとワークフロー 繰り返し 方向づけ 推敲 構築 移行 要求 分析 設計 制作 検査

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

9 12.1 実装作業の概要（3） レイヤリングアーキテクチャ 関心の分離 一方向の参照 ドメインを純粋に保つ ユーザインタフェース M-V-C
12. 概念モデルから実装まで 12.1 実装作業の概要（3） レイヤリングアーキテクチャ 関心の分離 一方向の参照 ドメインを純粋に保つ ユーザインタフェース M-V-C アプリケーション（機能） ドメイン（概念の世界） 永続化

10 12.2 ユースケース（1） ユースケース記述と現実の世界 情報システムとの対話と現実の活動 ユースケースの例 現実の世界
12. 概念モデルから実装まで 12.2 ユースケース（1） ユースケース記述と現実の世界 情報システムとの対話と現実の活動 ユースケースの例 ユースケース名：販売を記録する アクタ：窓口係 目的： 事前条件：その販売実績は記録されていない。 基本系列： 　①アクタがこのユースケースを起動する。 　②システムは販売した商品，数量，顧客タイプを指示 　③アクタはそれらの値を提示する。 　④システムはそれらの値と日時，担当者を記録する。 代替系列：なし。 事後条件：その販売実績が記録されている。 備考： 　①顧客タイプとは，顧客の分類で，性別×年齢層･･　 　②担当者情報は，このユースケース起動以前に･･ 　③一度の取引に複数の商品が関わることがある 　④注文が終わると，システムは料金を表示する 現実の世界 ①窓口で客がメニューに基づいて商品を 　注文する ②受注担当が注文を聞いて，キッチン担 　当（調理係）に渡す ③客は注文品ができるまで，窓口で待つ ④受注担当は，料金を計算し，請求する ⑤客は料金を支払う（窓口係は受け取る） ⑥客はできあがった商品を受け取る

11 12.2 ユースケース（2） ユースケースによる型モデルの検証 シーケンス図，協調図の始点 12. 概念モデルから実装まで 販売を記録する
窓口係 販売を記録する 日別の商品別売上げを得る 店長 カテゴリ別の商品別売上げを得る 日別の利益額を得る 調理係 商品ごとの調理時刻を記録する

12 12.3 ドメイン層の実装（1） エスカレーションの戻し 参照方向の限定 12. 概念モデルから実装まで 商品 明細 取引 現物 /売上
商品名 単価 原価 数量 /金額 * 取引 日時 現物 ロット番号 /賞味期限 /売上 /売上金額 /製造原価 /利益 日 製造 廃棄 販売 ｛導出｝ カテゴリ 名称 客タイプ 性別 年齢層

13 12.3 ドメイン層の実装（2） 多重分類の解決 12. 概念モデルから実装まで 顧客 一般 重要 法人 個人 《多重》 (b) 単一分類
個人重要 個人一般 法人重要 法人一般 顧客 一般 重要 法人 個人 《多重》 (b) 単一分類 インスタンス： 　個人／法人 　重要／一般 顧客タイプ カテゴリ 1 * 顧客 (a) 多重分類 (c) タイプクラス

14 12.3 ドメイン層の実装（3） 動的分類の解決 12. 概念モデルから実装まで 貸し出し 貸し出し state 1 * 1 《動的》
貸出中 返却済み 貸出中 返却済み (a) 動的分類 (b) stateクラス

15 12.4 アプリケーション層の実装（1） ユースケースの本体 アプリケーションファサード（Application Facade）
12. 概念モデルから実装まで 12.4 アプリケーション層の実装（1） ユースケースの本体 アプリケーションファサード（Application Facade） ドメインクラスのコピー，ビュー 排他制御 アプリケーションロジック Reciept _transaction Receipt() addLineItem() setCustomer() getSoldProducts() sumSales() commit() CustomerFacade _customer toString() CategorySales _category _date CategorySales() getName() getTotal() $getAllCategorySales() ProductSales _product ProductSales() ProductFacade() getDate() $getAllSales() LineItemFacade _lineItem LineItemFacade() Sales ドメイン アプリケーション Transaction * LineItem Product Category Customer ProductFacade

16 12.4 アプリケーション層の実装（2） シーケンス図による責務の配置 メッセージ（インタフェース）の設計 ユースケース「販売を記録する」
12. 概念モデルから実装まで 12.4 アプリケーション層の実装（2） シーケンス図による責務の配置 メッセージ（インタフェース）の設計 ユースケース「販売を記録する」 theActor sell:Usecase : Reciept :Transaction :LineItem : Product 起動 new new 商品，数量 addLineItem( ) $getProduct( ) LineItem( ) addLineItem( ) ［注文あり］ ［注文終わり 会計 setCustomer( ) setCustomer( ) commit( )

17 12.4 アプリケーション層の実装（3） シーケンス図による責務の配置 メッセージ（インタフェース）の設計
12. 概念モデルから実装まで 12.4 アプリケーション層の実装（3） シーケンス図による責務の配置 メッセージ（インタフェース）の設計 ユースケース「商品別に売上集計する」 売上：Usecase : Product : /Sales : LineItem : Transaction theActor new(prod.,date) getSales( ) getTotalQuantity(date) $getTotalQuantity(this, date) $getSoldDate(LineItem) 商品別集計 getProduct( ) getName( ) ［forAll］ getPrice( ) ［LineItemあり］ そのprodを参照しているLineItemを取り出して そのLineItemの日がdateと等しければ そのLineItemの数量を累積する その累積数量に単価を掛ける

18 12.5 ユーザインタフェース層の実装 ユーザインタフェース層 12. 概念モデルから実装まで ユーザインタフェース アプリケーション
Test _date Sell() showSales() setDate() アプリケーション Sales getName() getTotal() ProductSales CategorySales Reciept _date ProductFacade LineItemFacade CustomerFacade _product _category _date _transaction _product _lineItem _customer ProductSales() CategorySales() Receipt() getTotal() getName() ProductFacade() LineItemFacade() addLineItem() toString() ProductFacade() toString() getTotal() toString() setCustomer() getName() $getAllCategorySales() getSoldProducts() getDate() sumSales() $getAllSales() commit()

19 12.6 プログラミング（1） インスタンスの生成と管理 クラスオブジェクト インスタンスオブジェクト 参照の方向 =
12. 概念モデルから実装まで 12.6 プログラミング（1） インスタンスの生成と管理 クラスオブジェクト インスタンスオブジェクト 参照の方向 ：Transaction _date=021112 a:Transaction = :Product :Category :Transaction :LineItem :Customer 1:Category 1:Product 1:LineItem 1:Transact F20:Cust 2:Product 2:LineItem 2:Category 3:Product 3:LineItem 4:LineItem 2:Transact M30:Cust

20 12.6 プログラミング（2） リンクの実装 constructor LineItem Transaction * *
12. 概念モデルから実装まで 12.6 プログラミング（2） リンクの実装 public class Transaction{ private Date _date; private Customer _customer; private Vector _lineItems; private static Vector $transactionList = new Vector(); 　 public Transaction( Date date ){ _date = date; _lineItems = new Vector(); $transactionList.add(this); } 　　public void addLineItem( LineItem lineItem ){ if(lineItem != null){ _lineItems.add( lineItem ); public void setCustomer( Customer customer ){ _customer = customer; constructor $ｌineItems $transactionList :LineItem :Transaction 1:LineItem 1:Transaction _ｌineItems 2:LineItem 4:LineItem 2:Transaction LineItem Transaction _date _customer _lineItems $transactionList _product _quantity $lineItems * *

21 ui application domain :LineItem :Transaction バーガー :ProductSales
$getSoldDate(this) :LineItem :Transaction $getTotalQuantity(バーガー, 11日) sales.getTotal() getTotalQuantity(11日) ui バーガー :ProductSales バーガー :Product :LineItem qtty=3 :Transaction date=11日 application domain :LineItem qtty=1 :LineItem qtty=1 :Transaction date=12日 public class ProductSales implements Sales { public int getTotal() { return _product.getTotalQuantity(_date) * _product.getPrice(); } public class Product{ public int getTotalQuantity(Date date){ return LineItem.$getTotalQuantity(this, date); } public class LineItem{ public static int $getTotalQuantity(Product product, Date date){ int _totalQuantity = 0; Iterator iter = $lineItems.iterator(); while(iter.hasNext()){ LineItem _lineItem = (LineItem)iter.next(); if( _lineItem._product == product ){ if( Transaction.$getSoldDate(_lineItem).equals(date) ){ _totalQuantity += _lineItem._quantity; }　return _totalQuantity;

22 オブジェクト指向モデリング 13. 概念モデルの理解 13.1 アナリシスパターン 13.2 責任関係 13.3 勘定

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

24 13.1 アナリシスパターン（1） アナリシスパターン サポートパターン 責任関係（Accountability） 観測と測定
13. 概念モデルの理解 13.1 アナリシスパターン（1） アナリシスパターン 責任関係（Accountability） 観測と測定 企業財務の観測 オブジェクトへの参照 在庫管理と会計（Account） 会計モデルの利用 計画 トレーディング デリバティブ トレーディングパッケージ サポートパターン 情報システムの層別化アーキテクチャ アプリケーションファサード 型モデル設計テンプレートのためのパターン 関連パターン

25 13.2 責任関係（1） 責任関係（accountability）パターン 明示的なレベルを持った組織 変更に弱い
13. 概念モデルの理解 13.2 責任関係（1） 責任関係（accountability）パターン 明示的なレベルを持った組織 変更に弱い 操作（メソッド）の重複，類似の属性 オブジェクト（インスタンス）図 事業部 地域 * 1 営業所 部門 売上 コーヒー：事業部 首都圏：地域 神奈川：部門 藤沢：営業所 川崎：営業所 東京：部門

26 13.2 責任関係（2） 階層関係を持つ組織 類似の操作，属性はスーパタイプに持つ 制約の変更が煩わしい マトリックス組織にはどう対応する？
13. 概念モデルの理解 13.2 責任関係（2） 階層関係を持つ組織 類似の操作，属性はスーパタイプに持つ 制約の変更が煩わしい マトリックス組織にはどう対応する？ {階層} 親 0..1 子 制約： 組織 制約： 　親は持たない * * 　親は部門 事業部 地域 部門 営業所 制約： 制約： 　親は事業部 　親は地域

27 コーヒー：事業部 首都圏：地域 神奈川：部門 藤沢：営業所 川崎：営業所 東京：部門 親 子

28 13.2 責任関係（3） 2系統の階層 制約変更の煩わしさが２倍に 組織 子営業 親営業 親サービス 子サービス 事業部 地域 部門 営業所
13. 概念モデルの理解 13.2 責任関係（3） 2系統の階層 制約変更の煩わしさが２倍に 組織 * 子営業 親営業 親サービス 子サービス 事業部 地域 部門 営業所 サービス部門 サービス地域 サービスチーム サービスセンタ 制約： 　親営業は部門 　親サービスはサービスセンタ，親営業は営業所 制約: {階層}

29 コーヒー：事業部 首都圏：地域 神奈川：部門 藤沢：営業所 川崎：営業所 東京：部門 親営業 子営業 東京：サービス部門 藤沢：サービスセンタ 藤沢：サービスチーム 川崎：サービスチーム 横浜：サービスセンタ 首都圏：サービス地域 神奈川：サービス部門 親サービス 子サービス

30 13.2 責任関係（4） 関連型の使用 組織構造の制約は，組織構造の変化に敏感 事業部 地域 部門 営業所 営業組織 サービス組織
13. 概念モデルの理解 13.2 責任関係（4） 関連型の使用 組織構造の制約は，組織構造の変化に敏感 事業部 地域 部門 営業所 インスタンス： 　営業組織 　サービス組織 制約： 　営業所の親は部門…. 　サービスチームの親は営業所およびサービスセンタ…. 期間 組織構造型 組織 組織構造 1 * 親 子 型 有効期間 サービスチーム

31 神奈川：部門 藤沢：営業所 川崎：営業所 営業組織：組織構造型 親 子 藤沢：サービスセンタ 藤沢：サービスチーム 川崎：サービスチーム
横浜：サービスセンタ ：組織構造 神奈川：サービス部門 サービス組織：組織構造型 ：期間 2001/10/1 _ 2002/1/22

32 13.2 責任関係（5） 「組織構造型」と「ルール」 組織構造型ごとのルール 組織の変化に弱い 事業部 地域 部門 営業所 期間 組織構造型
13. 概念モデルの理解 13.2 責任関係（5） 「組織構造型」と「ルール」 組織構造型ごとのルール 組織の変化に弱い 事業部 地域 部門 営業所 期間 組織構造型 組織 組織構造 1 * 親 子 型 有効期間 サービスチーム ルール

33 神奈川：部門 藤沢：営業所 川崎：営業所 営業組織：組織構造型 親 子 藤沢：サービスセンタ 藤沢：サービスチーム 川崎：サービスチーム
横浜：サービスセンタ ：組織構造 神奈川：サービス部門 サービス組織：組織構造型 ：期間 2001/10/1 _ 2002/1/22 営業組織型：ルール 営業所の親は部門，部門の親は地域，... サービスチームの親は営業所およびサービスセンタ，サービスセンタの親は，….

34 13.2 責任関係（6） 組織階層を「責任関係」として一般化 依頼者→実行者 Customer-Performerの関係 責任関係型
13. 概念モデルの理解 13.2 責任関係（6） 組織階層を「責任関係」として一般化 依頼者→実行者 Customer-Performerの関係 人 組織 責任関係型 期間 パーティ 責任関係 * 1 型 実行者 依頼者 有効期限

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

36 シナリオ 同意：責任関係 患者:鈴木一郎は医師:山本太郎との間で，2001年12月18日に内視鏡検査を受けることについて同意した 依頼者
　患者:鈴木一郎は医師:山本太郎との間で，2001年12月18日に内視鏡検査を受けることについて同意した 依頼者 患者 ：パーティ型 同意：責任関係型 型 医師 ：パーティ型 実行者 型 型 内視鏡検査：作業 ：責任関係 依頼者 鈴木一郎 ：パーティ ：期間 実行者 山本太郎 ：パーティ 2001/12/18