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

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

2003 年 12 月 16 日

2

10.2 活動図（ 6 ）

プロセス図の課題記法（活動図の拡張）利益の源泉は何か

回転率を上げる（速い，安い，うまい）ムダを出さない（予測型か調整型か）

予測（見込み生産）実績（調理と販売）

中間製品で在庫するが，カスタマイズしない価値の移動

物流と金流付加価値

接客←従業員教育素材

店舗の立地

10. 状態モデル

3

11.6 揺さぶり（ 1 ）

モデルの洗練変更に強いモデルにする本質的なモデルを追求する

要求のエスカレーション

11. 静的モデル 4

作り置きがあればそこから出庫する

店長

カテゴリ別の商品別売上げを得る

日別の商品別売上げを得る

調理係商品ごとの調理時刻を記録する

窓口係

日別の利益額を得る

作り置きがあればそこから出庫

する

4

11.6 揺さぶり（ 16 ）

汎化も使って概念を整理

11. 静的モデル 4

商品1 明細商品名

単価原価

数量/ 金額

* 取引日時

*

現物ロット番号/ 賞味期限

*

1

*

1

*

/ 売上/ 売上金額/ 製造原価/ 利益

1日

製造

1

廃棄消費税はどうする

1

販売

｛導出｝

カテゴリ名称

客タイプ*

1性別年齢層

導出： the/ 売上 . 製造原価は， the 明細 .the 取引とナビゲートして得られる取引オブジェクトの集合のうち，それぞれのサブタイプが「製造」または「廃棄」で，その日時の日が， the/ 売上 . 日と一致するものについて， the 明細 . 数量を合計したものにこの原価を乗じて得る

5

シラバス

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

回1

2

3

4

5

6

7

8

9

10

11

12

13

内容オリエンテーション：モデルとは何か。モデリング言語： UML の概要静的モデル 1 ：概念とクラス静的モデル 2 ：関連静的モデル 3 ：オブジェクト図静的モデル 3 ：オブジェクト図（続き），モデリング

機能モデル 2 ：要求抽出，協調図，シーケンス図，状態モデル：状態図機能モデル 2 ：活動図，静的モデル 4 ：ユースケースに基づくモデリング静的モデル 4 ：モデルの揺さぶり実装レベル：実装モデルとプログラム，モデリング 1 ：アナリシスパターン

機能モデル 1 ：ユースケース，シナリオ

モデリング 2 ：デザインパターン，モデル図の作成，モデルの評価基準モデリング 3 ：例題によるモデル図の作成

月日9 月 30 日

10 月 7 日10 月 14 日10 月 21 日10 月 28 日11 月 4 日11 月 11 日11 月 18 日12 月 2 日12 月 9 日12 月 16 日

1 月 13 日1 月 20 日

授業計画

6

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


7

12.1 実装作業の概要（ 1 ）

ソフトウエアプロセスフェーズとワークフロー繰り返し

12. 概念モデルから実装まで

方向づけ推敲構築移行

分析設計制作検査

要求

8


ドメインの実装機能の実装アーキテクチャの実装

レイヤー構造役割の分担


アプリケーション（機能）

ドメイン（概念の世界）

永続化

ユーザインタフェース

概念レベル



実装レベル

人工物の作り込み

9


レイヤリングアーキテクチャ関心の分離一方向の参照ドメインを純粋に保つ




永続化

ユーザインタフェース M-V-C

10

12.2 ユースケース（ 1 ）

ユースケース記述と現実の世界情報システムとの対話と現実の活動

現実の世界①窓口で客がメニューに基づいて商品を　注文する②受注担当が注文を聞いて，キッチン担　当（調理係）に渡す③客は注文品ができるまで，窓口で待つ④受注担当は，料金を計算し，請求する⑤客は料金を支払う（窓口係は受け取る）⑥客はできあがった商品を受け取る

ユースケースの例ユースケース名：販売を記録するアクタ：窓口係目的：事前条件：その販売実績は記録されていない。基本系列：　①アクタがこのユースケースを起動する。　②システムは販売した商品，数量，顧客タイプを指示　③アクタはそれらの値を提示する。　④システムはそれらの値と日時，担当者を記録する。代替系列：なし。事後条件：その販売実績が記録されている。備考：　①顧客タイプとは，顧客の分類で，性別 × 年齢層　･･　②担当者情報は，このユースケース起動以前に･･　③一度の取引に複数の商品が関わることがある　④注文が終わると，システムは料金を表示する


11

12.2 ユースケース（ 2 ）

ユースケースによる型モデルの検証シーケンス図，協調図の始点


販売を記録する

店長

カテゴリ別の商品別売上げを得る

日別の商品別売上げを得る

調理係商品ごとの調理時刻を記録する

窓口係

日別の利益額を得る

12

12.3 ドメイン層の実装（ 1 ）

エスカレーションの戻し参照方向の限定


Category_id_name_productList : Vector$categoryList : Vector

Category()$getCategory()add()getName()getProductList()

Product_id_name_price$productList : Vector

Product()getId()getName()getPrice()getTotalQuantity()$getProduct()

**

LineItem_product_quantity$lineItems : Vector

LineItem()getSales()getProduct()getQuantity()$getTotalQuantity()

**

Customer_id_sex_ageRange$customerList

Customer()$getCustomer()getID()getSex()getAgeRange()

Transaction_date_customer_lineItems : Vector$transactionList : Vector

Transaction()addLineItem()setCustomer()getDate()getLineItems()sumSales()$getSoldDate()$getSize()

** **

商品1 明細商品名

単価原価

数量/ 金額

*取引

日時*

現物ロット番号/ 賞味期限

*

1

*

1

*

/ 売上/ 売上金額/ 製造原価/ 利益

1日

製造

1

廃棄

1

販売

｛導出｝

カテゴリ名称

客タイプ*

1性別年齢層

13


多重分類の解決


顧客

一般重要

法人

個人

《多重》

(a) 多重分類

顧客

法人重要個人一般個人重要法人一般

(b) 単一分類

顧客*

1カテゴリ

(c) タイプクラス

インスタンス：　個人／法人　重要／一般

顧客タイプ

14


動的分類の解決


1

貸し出し

返却済み貸出中

《動的》

(a) 動的分類 (b) state クラス

返却済み貸出中

state1

*

貸し出し

15

12.4 アプリケーション層の実装（ 1 ）

ユースケースの本体アプリケーションファサード（ Application Facade ）

ドメインクラスのコピー，ビュー排他制御

アプリケーションロジック


Reciept_transaction

Receipt()addLineItem()setCustomer()getSoldProducts()sumSales()commit()

CustomerFacade_customer

toString()

CategorySales_category_date

CategorySales()getName()getTotal()$getAllCategorySales()

ProductSales_date_product

ProductSales()getTotal()ProductFacade()getName()getDate()$getAllSales()

LineItemFacade_lineItem

LineItemFacade()toString()

Sales

getName()getTotal()

ドメイン

アプリケーション

Transaction*

*

*

LineItem** **

Product

Category

Customer

ProductFacade_product

ProductFacade()toString()

16


シーケンス図による責務の配置メッセージ（インタフェース）の設計

ユースケース「販売を記録する」

［注文あり］［注文終わり


sell:Usecase :Transaction :LineItem : Product : Reciept theActor

起動

商品，数量

会計

new

addLineItem( )

setCustomer( )

commit( )

addLineItem( )

new

setCustomer( )

LineItem( )

$getProduct( )

17


シーケンス図による責務の配置メッセージ（インタフェース）の設計

ユースケース「商品別に売上集計する」

売上： Usecase : Product: /Sales : LineItem : TransactiontheActor

new(prod.,date)

getSales( ) getTotalQuantity(date)

$getTotalQuantity(this, date) $getSoldDate(LineItem)

商品別集計

getProduct( )

getName( )

［ forAll］getPrice( ) ［ LineItem あり］

その prod を参照している LineItemを取り出して

その LineItem の日が date と等しければその LineItem

の数量を累積するその累積数量

に単価を掛ける


18

12.5 ユーザインタフェース層の実装ユーザインタフェース層


Reciept_transaction

Receipt()addLineItem()setCustomer()getSoldProducts()sumSales()commit()

CustomerFacade_customer

toString()

CategorySales_category_date

CategorySales()getName()getTotal()$getAllCategorySales()

ProductSales_date_product

ProductSales()getTotal()ProductFacade()getName()getDate()$getAllSales()

LineItemFacade_lineItem

LineItemFacade()toString()

ProductFacade_product

ProductFacade()toString()

Sales

getName()getTotal()

アプリケーション

Test_date

Sell()showSales()setDate()

ユーザインタフェース

19

12.6 プログラミング（ 1 ）

インスタンスの生成と管理クラスオブジェクトインスタンスオブジェクト参照の方向

：Transaction_date=0211

12a:Transaction=

1:Product

2:Product

1:Category

3:Product


2:Transact

1:LineItem

2:LineItem

3:LineItem

4:LineItem M30:Cust

:Product:Category :Transaction:LineItem :Customer

F20:Cust1:Transact

2:Category

20

12.6 プログラミング（ 2 ）

リンクの実装

1:Transaction

:Transaction

2:Transaction

1:LineItem

2:LineItem

:LineItem

4:LineItem

_ ｌ ineItems

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

Transaction_date_customer_lineItems $transactionList

LineItem_product _quantity$lineItems

**

constructor

21

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; }

public class ProductSales implements Sales { public int getTotal() { return _product.getTotalQuantity(_date) * _product.getPrice(); }

:Transactiondate=12日

:Transactiondate=11日

:Transaction

:LineItemqtty=3

バーガー:Product

:LineItem

getTotalQuantity(11 日 )

:LineItemqtty=1

:LineItemqtty=1

$getTotalQuantity( バーガー , 11 日 )$getSoldDate(this)

バーガー:ProductSales

sales.getTotal()

ui

application domain

22

13. 概念モデルの理解13.1 アナリシスパターン13.2 責任関係13.3 勘定


23

13.1 アナリシスパターン（ 1 ）

Fowler, M.,”Analysis Patterns”分析に現れるパターン

要求のエスカレーション変更に強いモデル

知識レベル制約記述実装の考慮

アプリケーションファサードサポートパターン

よいモデル例

13. 概念モデルの理解

24

13.1 アナリシスパターン（ 1 ）

アナリシスパターン責任関係（ Accountability ）観測と測定企業財務の観測オブジェクトへの参照在庫管理と会計（ Account ）会計モデルの利用計画トレーディングデリバティブトレーディングパッケージ

サポートパターン情報システムの層別化アーキテクチャアプリケーションファサード型モデル設計テンプレートのためのパターン関連パターン


25

13.2 責任関係（ 1 ）

責任関係（ accountability ）パターン明示的なレベルを持った組織

変更に弱い操作（メソッド）の重複，類似の属性オブジェクト（インスタンス）図

事業部地域*

1 営業所部門*

1*

11 1 1売上

コーヒー：事業部

首都圏：地域

神奈川：部門

藤沢：営業所

川崎：営業所

東京：部門


26

13.2 責任関係（ 2 ）

階層関係を持つ組織類似の操作，属性はスーパタイプに持つ

制約の変更が煩わしいマトリックス組織にはどう対応する？

事業部地域部門営業所

組織*

子

*

親 0..1

制約：　親は事業部

制約：　親は持たない

制約：　親は地域

制約：　親は部門

{ 階層 }


27


首都圏：地域

神奈川：部門

藤沢：営業所

川崎：営業所

東京：部門

親親親子子子

28

13.2 責任関係（ 3 ）

2系統の階層

制約変更の煩わしさが２倍に

組織*

*

子営業*

親営業*

*

*

親サービス*

子サービス*

事業部地域部門営業所サービス部門サービス地域サービスチームサービスセンタ

制約：　親営業は部門

制約：　親サービスはサービスセンタ，親営業は営業所

制約 :制約 :制約 :制約 :制約 : 制約 :

{ 階層 }{ 階層 }


29


首都圏：地域

神奈川：部門

藤沢：営業所

川崎：営業所

東京：部門

親営業

子営業

東京：サービス部門

藤沢：サービスセンタ

藤沢：サービスチーム

川崎：サービスチーム

横浜：サービスセンタ

首都圏：サービス地域

神奈川：サービス部門

親サービス

子サービス

30

13.2 責任関係（ 4 ）

関連型の使用

組織構造の制約は，組織構造の変化に敏感

事業部地域部門営業所

インスタンス：　営業組織　サービス組織　

制約：　営業所の親は部門… .　サービスチームの親は営業所およびサービスセンタ… .

期間

組織構造型

組織組織構造

1**

*

1

* *1親*

1* 子*

1型

1 有効期間サービスチーム


31

神奈川：部門

藤沢：営業所

川崎：営業所

営業組織：組織構造型

親

子





：組織構造

：組織構造

：組織構造

：組織構造


親

：組織構造

：組織構造

：組織構造

：組織構造

子サービス組織：組織構造型

：期間2001/10/1 _ 2002/1/22

32

13.2 責任関係（ 5 ）

「組織構造型」と「ルール」

組織構造型ごとのルール組織の変化に弱い

事業部地域部門営業所期間

組織構造型

組織組織構造

1**

*

1

* *1親*

1* 子*

1型

1 有効期間サービスチーム

ルール*1


33

神奈川：部門

藤沢：営業所

川崎：営業所

営業組織：組織構造型

親

子





：組織構造

：組織構造

：組織構造

：組織構造


親

：組織構造

：組織構造

：組織構造

：組織構造

子サービス組織：組織構造型

：期間2001/10/1 _ 2002/1/22

営業組織型：ルール

営業所の親は部門，部門の親は地域， ...

サービスチームの親は営業所およびサービスセンタ，サービスセンタの親は，….

営業組織型：ルール

34

13.2 責任関係（ 6 ）

組織階層を「責任関係」として一般化

依頼者→実行者 Customer-Performer の関係

人組織

責任関係型

期間

パーティ責任関係*

1

*

型

1

**

1**

1** 実行者

依頼者1

1

1

有効期限1


35

13.2 責任関係（ 7 ）

知識レベルと操作レベルパワータイプ（ベキ型）操作レベルの型の制約を記述鏡像関係

inv:　 let collx:set(責任関係 )=self.the責任関係 in　 collX->forALL （ x | x. 型 .依頼者 ->includes(x.依頼者 . 型 ) and x. 型 . 実行者 ->includes(x. 実行者 . 型 ))

知識レベル操作レベル

人組織期間

作業パーティ責任関係

1**

**

** 1

**

1*

パーティ型

*

1

*

責任関係型

*

1

*

型

1..**

1..**

1..**

1..**

実行者

依頼者1

1

1

有効期限

依頼者

実行者

型 1


36

同意：責任関係型

：責任関係

山本太郎：パーティ

型

シナリオ同意：責任関係

　患者 :鈴木一郎は医師 :山本太郎との間で， 2001 年 12 月 18 日に内視鏡検査を受けることについて同意した

医師：パーティ型

鈴木一郎：パーティ

患者：パーティ型

型

型

依頼者

依頼者

実行者

実行者

内視鏡検査：作業

：期間2001/12/18

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

Documents