問題解決からビジネスモデリングへ

オブジェクト指向モデリング
[11]
2003年12月16日
10. 状態モデル
10.2 活動図（6）
 プロセス図の課題
 記法（活動図の拡張）
 利益の源泉は何か
 回転率を上げる（速い，安い，うまい）
 ムダを出さない（予測型か調整型か）
 予測（見込み生産）
 実績（調理と販売）
 中間製品で在庫するが，カスタマイズしない
 価値の移動
 物流と金流
 付加価値
 接客←従業員教育
 素材
 店舗の立地
2
11. 静的モデル4
11.6 揺さぶり（1）
 モデルの洗練
 変更に強いモデルにする
 本質的なモデルを追求する
 要求のエスカレーション
日別の商品別売上げを得る
カテゴリ別の商品別売上げを得る
作り置きがあれば
そこから出庫する
店長
日別の利益額を得る
作り置きがあればそこから出庫する
窓口係
調理係
商品ごとの調理時刻を記録する
3
11. 静的モデル4
11.6 揺さぶり（16）
 汎化も使って概念を整理
導出：
the/売上.製造原価は，the明細.the取引と
ナビゲートして得られる取引オブジェクトの
集合のうち，それぞれのサブタイプが「製
造」または「廃棄」で，その日時の日が，
the/売上.日と一致するものについて，the
明細.数量を合計したものにこの原価を乗
じて得る
カテゴリ
名称
1
*
商品
/売上
/売上金額
/製造原価
/利益
1
1
商品名
日単価
原価
｛導出｝
*
現物
ロット番号
/賞味期限
明細
数量
/金額
取引
1
*
日時
1
1
消費税はどうす
る
*
*
廃棄
製造
販売
*
客タイプ
性別
年齢層
1
4
オブジェクト指向モデリング
シラバス
 授業計画
回
1
2
3
4
5
6
7
8
9
10
11
12
13
月日
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日
内容
オリエンテーション：モデルとは何か。
モデリング言語：UMLの概要
静的モデル1：概念とクラス
静的モデル2：関連
静的モデル3：オブジェクト図
静的モデル3：オブジェクト図（続き），モデリング
機能モデル1：ユースケース，シナリオ
機能モデル2：要求抽出，協調図，シーケンス図，状態モデル：状態図
機能モデル2：活動図，静的モデル4：ユースケースに基づくモデリング
静的モデル4：モデルの揺さぶり
実装レベル：実装モデルとプログラム，モデリング1：アナリシスパターン
モデリング2：デザインパターン，モデル図の作成，モデルの評価基準
モデリング3：例題によるモデル図の作成
5
オブジェクト指向モデリング
12. 概念モデルから実装まで
12.1 実装作業の概要
12.2 ユースケース
12.3 ドメイン層の実装
12.4 アプリケーション層の実装
12.5 ユーザインタフェース層の実装
12.6 プログラミング
6
12. 概念モデルから実装まで
12.1 実装作業の概要（1）
 ソフトウエアプロセス
 フェーズとワークフロー
 繰り返し
方向づけ
推敲
構築
移行
要求
分析
設計
制作
検査
7
12. 概念モデルから実装まで
12.1 実装作業の概要（2）
 ドメインの実装
 機能の実装
 アーキテクチャの実装
 レイヤー構造
 役割の分担
人工物の作り込み
ユーザインタフェース
アプリケーション（機能）
アプリケーション（機能）
ドメイン（概念の世界）
ドメイン（概念の世界）
永続化
概念レベル
実装レベル
8
12. 概念モデルから実装まで
12.1 実装作業の概要（3）
 レイヤリングアーキテクチャ
 関心の分離
 一方向の参照
 ドメインを純粋に保つ
 M-V-C
ユーザインタフェース
アプリケーション（機能）
ドメイン（概念の世界）
永続化
9
12. 概念モデルから実装まで
12.2 ユースケース（1）
 ユースケース記述と現実の世界
 情報システムとの対話と現実の活動
ユースケースの例
ユースケース名：販売を記録する
アクタ：窓口係
目的：
事前条件：その販売実績は記録されていない。
基本系列：
①アクタがこのユースケースを起動する。
②システムは販売した商品，数量，顧客タイプを指示
③アクタはそれらの値を提示する。
④システムはそれらの値と日時，担当者を記録する。
代替系列：なし。
事後条件：その販売実績が記録されている。
備考：
①顧客タイプとは，顧客の分類で，性別×年齢層･･
②担当者情報は，このユースケース起動以前に･･
③一度の取引に複数の商品が関わることがある
④注文が終わると，システムは料金を表示する
現実の世界
①窓口で客がメニューに基づいて商品を
注文する
②受注担当が注文を聞いて，キッチン担
当（調理係）に渡す
③客は注文品ができるまで，窓口で待つ
④受注担当は，料金を計算し，請求する
⑤客は料金を支払う（窓口係は受け取る）
⑥客はできあがった商品を受け取る
10
12. 概念モデルから実装まで
12.2 ユースケース（2）
 ユースケースによる型モデルの検証
 シーケンス図，協調図の始点
販売を記録する
窓口係
日別の商品別売上げを得る
カテゴリ別の商品別売上げを得る
店長
日別の利益額を得る
商品ごとの調理時刻を記録する
調理係
11
12. 概念モデルから実装まで
12.3 ドメイン層の実装（1）
 エスカレーションの戻し
 参照方向の限定
カテゴリ
名称
1
*
商品
/売上
/売上金額
/製造原価
/利益
Category
_id
_name
_productList : Vector
$categoryList : Vector
1
明細
数量
/金額
取引
1
*
日時
1
1
*
*
廃棄
現物
ロット番号
/賞味期限
製造
Transaction
_date
_customer
_lineItems : Vector
$transactionList : Vector
LineItem
_product
_quantity
$lineItems : Vector
LineItem()
* getSales()
getProduct()
getQuantity()
$getTotalQuantity()
*
Transaction()
addLineItem()
setCustomer()
getDate()
getLineItems()
sumSales()
$getSoldDate()
$getSize()
販売
*
客タイプ
性別
年齢層
*
Product
Product()
getId()
getName()
getPrice()
getTotalQuantity()
$getProduct()
*
｛導出｝
原価
Category()
$getCategory()
add()
getName()
getProductList()
_id
_name
_price
$productList : Vector
1
商品名
日単価
1
Customer
_id
_sex
_ageRange
$customerList
*
Customer()
$getCustomer()
getID()
getSex()
getAgeRange()
12
12. 概念モデルから実装まで
12.3 ドメイン層の実装（2）
 多重分類の解決
顧客
個人重要
個人
個人一般
法人重要
法人一般
(b) 単一分類
顧客
法人
顧客タイプ
《多重》
インスタンス：
個人／法人
重要／一般
カテゴリ 1
重要
一般
*
顧客
(a) 多重分類
(c) タイプクラス
13
12. 概念モデルから実装まで
12.3 ドメイン層の実装（3）
 動的分類の解決
貸し出し
貸し出し
1
state
*
1
《動的》
貸出中
返却済み
(a) 動的分類
貸出中
返却済み
(b) stateクラス
14
12. 概念モデルから実装まで
12.4 アプリケーション層の実装（1）
 ユースケースの本体
 アプリケーションファサード（Application Facade）
 ドメインクラスのコピー，ビュー
 排他制御
 アプリケーションロジック
アプリケーション
Sales
getName()
getTotal()
ProductSales
CategorySales
_date
_product
_category
_date
ProductSales()
getTotal()
ProductFacade()
getName()
getDate()
$getAllSales()
CategorySales()
getName()
getTotal()
$getAllCategorySales()
Reciept
LineItemFacade
ProductFacade
_product
_lineItem
ProductFacade()
toString()
LineItemFacade()
toString()
CustomerFacade
_transaction
_customer
Receipt()
addLineItem()
setCustomer()
getSoldProducts()
sumSales()
commit()
toString()
ドメイン
Category
*
LineItem
Product
*
Transaction
*
Customer
*
15
12. 概念モデルから実装まで
12.4 アプリケーション層の実装（2）
 シーケンス図による責務の配置
 メッセージ（インタフェース）の設計
 ユースケース「販売を記録する」
theActor
sell:Usecase
起動
: Reciept
new
:Transaction
:LineItem
: Product
new
商品，数量
addLineItem( )
$getProduct( )
LineItem( )
addLineItem( )
［注文あり］
会計
［注文終わり
setCustomer( )
setCustomer( )
commit( )
16
12. 概念モデルから実装まで
12.4 アプリケーション層の実装（3）
 シーケンス図による責務の配置
 メッセージ（インタフェース）の設計
 ユースケース「商品別に売上集計する」
theActor
売上：Usecase
: /Sales
: Product
: LineItem
: Transaction
商品別集計
new(prod.,date)
getProduct( )
そのprodを参照し
ているLineItemを
取り出して
getName( )
getSales( )
getTotalQuantity(date)
$getTotalQuantity(this, date)
$getSoldDate(LineItem)
getPrice( )
［LineItemあり］
［forAll］
その累積数量に
単価を掛ける
そのLineItemの
数量を累積する
そのLineItemの日
がdateと等しけれ
ば
17
12. 概念モデルから実装まで
12.5 ユーザインタフェース層の実装
 ユーザインタフェース層
ユーザインタフェース
Test
_date
Sell()
showSales()
setDate()
アプリケーション
Sales
getName()
getTotal()
ProductSales
CategorySales
_date
_product
_category
_date
ProductSales()
getTotal()
ProductFacade()
getName()
getDate()
$getAllSales()
CategorySales()
getName()
getTotal()
$getAllCategorySales()
ProductFacade
LineItemFacade
_product
_lineItem
ProductFacade()
toString()
LineItemFacade()
toString()
Reciept
CustomerFacade
_transaction
_customer
Receipt()
addLineItem()
setCustomer()
getSoldProducts()
sumSales()
commit()
toString()
18
12. 概念モデルから実装まで
12.6 プログラミング（1）
 インスタンスの生成と管理
：Transaction
_date=021112
 クラスオブジェクト
 インスタンスオブジェクト
 参照の方向
=
a:Transaction
:Category
:Product
:LineItem
:Transaction
:Customer
1:Category
1:Product
1:LineItem
1:Transact
F20:Cust
2:Product
2:LineItem
3:Product
3:LineItem
2:Transact
M30:Cust
2:Category
4:LineItem
19
12. 概念モデルから実装まで
12.6 プログラミング（2）
 リンクの実装
public class Transaction{
constructor
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);
}
$ｌineItems
:LineItem
:Transaction
1:LineItem
1:Transaction
_ｌineItems
2:LineItem
public void addLineItem( LineItem lineItem ){
if(lineItem != null){
_lineItems.add( lineItem );
}
}
public void setCustomer( Customer customer ){
_customer = customer;
}
$transactionList
4:LineItem
2:Transaction
Transaction
LineItem
_product
_quantity
$lineItems
*
_date
_customer
_lineItems
$transactionList
20
$getTotalQuantity(バーガー, 11日)
$getSoldDate(this)
:LineItem
:Transaction
:LineItem
qtty=3
:Transaction
date=11日
sales.getTotal()
getTotalQuantity(11日)
ui
バーガー
:ProductSales
バーガー
:Product
application domain
public class ProductSales implements Sales {
:LineItem
qtty=1
:LineItem
qtty=1
:Transaction
date=12日
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;
}
21
オブジェクト指向モデリング
13. 概念モデルの理解
13.1 アナリシスパターン
13.2 責任関係
13.3 勘定
22
13. 概念モデルの理解
13.1 アナリシスパターン（1）
 Fowler, M.,”Analysis Patterns”
 分析に現れるパターン
要求のエスカレーション
変更に強いモデル
 知識レベル
 制約記述
 実装の考慮
アプリケーションファサード
サポートパターン
 よいモデル例
23
13. 概念モデルの理解
13.1 アナリシスパターン（1）
 アナリシスパターン
責任関係（Accountability）
観測と測定
企業財務の観測
オブジェクトへの参照
在庫管理と会計（Account）
会計モデルの利用
計画
トレーディング
デリバティブ
トレーディングパッケージ
 サポートパターン
情報システムの層別化アーキテクチャ
アプリケーションファサード
型モデル設計テンプレートのためのパターン
関連パターン
24
13. 概念モデルの理解
13.2 責任関係（1）
 責任関係（accountability）パターン
 明示的なレベルを持った組織
事業部
1
*
地域
1
*
部門
1
営業所
* 売上
変更に弱い
操作（メソッド）の重複，類似の属性
オブジェクト（インスタンス）図
コーヒー：事
業部
首都圏：
地域
神奈川：
部門
藤沢：営
業所
東京：部
門
川崎：営
業所
25
13. 概念モデルの理解
13.2 責任関係（2）
 階層関係を持つ組織
 類似の操作，属性はスーパタイプに持つ
{階層}
親
組織
制約：
親は持たない
事業部
0..1
子
制約：
親は部門
*
地域
制約：
親は事業部
部門
営業所
制約：
親は地域
 制約の変更が煩わしい
 マトリックス組織にはどう対応する？
26
コーヒー：事親
業部
子首都圏：
地域
親
子神奈川：
部門
東京：部
門
親
子藤沢：営
業所
川崎：営
業所
27
13. 概念モデルの理解
13.2 責任関係（3）
 2系統の階層
{階層}
{階層}
*
子営業
*
組織
親営業
*
*
事業部
制約:
地域
制約:
親サービス
子サービス
部門
制約:
営業所サービス地域サービス部門サービスセンタサービスチーム
制約:
制約：
親営業は部門
制約:
制約:
制約：
親サービスは
サービスセンタ，
親営業は営業所
 制約変更の煩わしさが２倍に
28
コーヒー：事
業部
首都圏：
地域
東京：部
門
首都圏：サ
ービス地域
神奈川：
部門
川崎：営
業所
藤沢：営
業所
神奈川：サ
ービス部門
横浜：サー
ビスセンタ
親営業
子営業
東京：サー
ビス部門
藤沢：サー
ビスセンタ
親サービス
子サービス
川崎：サー
ビスチーム
藤沢：サー
ビスチーム
29
13. 概念モデルの理解
13.2 責任関係（4）
 関連型の使用
インスタンス：
営業組織
サービス組織
組織構造型
制約：
営業所の親は部
門….
サービスチームの
親は営業所および
サービスセンタ….
型1
*
組織構造
*
親
1
*
組織
子
1
*
1 有効期間
期間
事業部
地域
部門
営業所
サービス
チーム
 組織構造の制約は，組織構造の変化に敏感
30
神奈川：
部門
神奈川：サ
ービス部門
親
営業組織：
組織構造型
：組織構
造
：組織構
造
：組織構
造
：組織構
造
子
川崎：営
業所
藤沢：営
業所
横浜：サー
ビスセンタ
藤沢：サー
ビスセンタ
：組織構
造
：組織構
造
：組織構
造
サービス組織
：組織構造型
親
：組織構
造
：期間
2001/10/1 _
2002/1/22
子
川崎：サー
ビスチーム
藤沢：サー
ビスチーム
31
13. 概念モデルの理解
13.2 責任関係（5）
 「組織構造型」と「ルール」
組織構造型 *
1
ルール
型1
*
組織構造
*
親
1
*
組織
子
1
*
1 有効期間
期間
事業部
地域
部門
営業所
サービス
チーム
 組織構造型ごとのルール
 組織の変化に弱い
32
営業所の親は部門，
部門の親は地域，...
神奈川：
部門
営業組織型
：ルール
神奈川：サ
ービス部門
サービスチームの親
は営業所およびサー
ビスセンタ，サービス
センタの親は，….
営業組織型
：ルール
親
営業組織：
組織構造型
：組織構
造
：組織構
造
：組織構
造
：組織構
造
子
川崎：営
業所
藤沢：営
業所
横浜：サー
ビスセンタ
藤沢：サー
ビスセンタ
：組織構
造
：組織構
造
：組織構
造
サービス組織
：組織構造型
親
：組織構
造
：期間
2001/10/1 _
2002/1/22
子
川崎：サー
ビスチーム
藤沢：サー
ビスチーム
33
13. 概念モデルの理解
13.2 責任関係（6）
 組織階層を「責任関係」として一般化
責任関係型
型 1
*
*
責任関係
依頼者
1
*
実行者
*
パーティ
1
1 有効期限
期間
人
組織
 依頼者→実行者
 Customer-Performerの関係
34
13. 概念モデルの理解
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 有効期限
期間
人
組織
35
 シナリオ
 同意：責任関係
患者:鈴木一郎は医師:山本太郎との間で，2001年12月18日に内視鏡検
査を受けることについて同意した
同意：責任
関係型
型
依頼者患者
：パーティ型
医師
実行者：パーティ型
型
型
内視鏡検
査：作業
：責任関
係
：期間
2001/12/18
依頼者鈴木一郎
：パーティ
実行者山本太郎
：パーティ
36

Download Report