1 / 36

オブジェクト指向モデリング [11]

オブジェクト指向モデリング [11]. 2003 年 12 月 16 日. 10. 状態モデル. 10.2 活動図 （ 6 ）. プロセス図の課題 記法（活動図の拡張） 利益の源泉は何か 回転率を上げる（速い，安い，うまい） ムダを出さない（予測型か調整型か） 予測（見込み生産） 実績（調理と販売） 中間製品で在庫するが，カスタマイズしない 価値の移動 物流と金流 付加価値 接客←従業員教育 素材 店舗の立地. 日別の商品別売上げを得る. カテゴリ別の商品別売上げを得る. 日別の利益額を得る. 店長. 調理係. 窓口係.

xuan
Download Presentation

オブジェクト指向モデリング [11]

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

  5. オブジェクト指向モデリング シラバス • 授業計画 回 月日 内容 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.4 アプリケーション層の実装 12.5 ユーザインタフェース層の実装 12.6 プログラミング

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

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

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

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

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

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

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

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

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

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

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

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

  19. a:Transaction = :Category :Product :LineItem :Transaction :Customer ：Transaction _date=021112 12. 概念モデルから実装まで 12.6 プログラミング（1） • インスタンスの生成と管理 • クラスオブジェクト • インスタンスオブジェクト • 参照の方向 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. constructor 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; } $ｌineItems $transactionList :LineItem :Transaction 1:LineItem 1:Transaction _ｌineItems 2:LineItem 4:LineItem 2:Transaction Transaction LineItem _date _customer _lineItems $transactionList _product _quantity $lineItems * *

  21. $getSoldDate(this) :LineItem :Transaction $getTotalQuantity(バーガー, 11日) sales.getTotal() getTotalQuantity(11日) ui バーガー:ProductSales バーガー:Product :LineItemqtty=3 :Transactiondate=11日 application domain :LineItemqtty=1 :LineItemqtty=1 :Transactiondate=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. 概念モデルの理解 13.1 アナリシスパターン（1） • Fowler, M.,”Analysis Patterns” • 分析に現れるパターン 要求のエスカレーション 変更に強いモデル • 知識レベル • 制約記述 • 実装の考慮 アプリケーションファサード サポートパターン • よいモデル例

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related