Transcript ppt形式

オブジェクト指向モデリング
[13]
2004年1月20日
13. 概念モデルの理解
13.3 勘定（1）
 移動の記録
 勘定（account）
 勘定科目
 口座
実施日
04/1/12
借方
貸方
勘定科目
金額
勘定科目
金額
04/1/12 売上げ
30,000円 売掛金
30,000円
消費税
1,500円 預かり消費税 1,500円
計上日
摘要
商品販売
 多肢トランザクション
勘定科目
/残高 : 量
仕訳記入
1
*
数量 : 量
会計取引
2..*
実施日:時点
1 計上日:時点
《business rule》
inv:
self.the仕訳記入.数量->sum = 0
2
14. 実装モデルの理解
14.2 Composite（1）
子
子
 構造に関するパターン
子
B
 木構造の一般形
C
{階層}
子
子
G
E
子
子
Leafの集合
Component
{abstract}
children
*
Component
operation()
add(Component)
remove(Component)
getChild()
Composite
children.operation()
D
A
F
*
Compositeの集合
operation()
add(Component)
remove(Component)
getChild()
Leaf
operation()
3
14. 実装モデルの理解
14.3 State（1）
 振る舞いに関するパターン
 内部状態が変化したときに，その振る舞いを変える
 動的分類の実装方法の一つ
 状態に依存した振る舞いを局所化
 状態ごとの振る舞いを用意
 ConcreteStateはsingleton
state.Handle()
Context
Request()
state
{abstract}
*
State
state Handle()
ConcreteStateA ConcreteStateB
Handle()
Handle()
4
14. 実装モデルの理解
14.4 Observer（1）
 振る舞いに関するパターン
 ある観測対象に複数の観測者
 観測対象の変化をできるだけ早く知るには
 ポーリングではコンピュータリソースを消費しすぎる
 変化があったことだけを通知（notify）する（callback）
 通知を受けた観測者が変化情報を取りに行く
observer.
update()
{abstract}
{abstract}
Subject
*
Notify()
Attach(Observer)
Detach(observer)
ConcreteSubject
return subjectState
SetState()
GetState()
subjectState
Observer
update()
フレームワーク側
observer
subject
ConcreteObserver
update()
observerState=
subject.GetState()
observerState
5
オブジェクト指向モデリング
シラバス
 授業計画
回
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：モデルの揺さぶり
実装レベル：実装モデルとプログラム，概念モデルの理解：アナリシスパターン
概念モデルの理解：アナリシスパターン，実装モデルの理解：デザインパターン
モデリング：例題によるモデル図の作成
6
オブジェクト指向モデリング
15.モデリング
15.1 モデルの良さの基準
15.2 自動改札システム
15.3 酒屋の在庫問題
7
15. モデリング
15.1 モデルの良さの基準
 ユースケース
 妥当なユースケース
目的充足性（効果的）
 型モデル（概念レベル）
 世界（UoD）が記述できている
適度な抽象性
一般性
単純性（良い概念，良い構造）
耐変更性
再利用性
 ユースケースが実現できている
 理解の共有
8
15. モデリング
15.2 自動改札システム（1）
 演習12
自動改札システムの型モデル（概念レベル）を書いてください。
①概念の整理
②初期モデル
③基本的なユースケースによる検証
④初期モデルの改訂
9
15. モデリング
15.2 自動改札システム（2）
 モデリングプロセス
 基本定義→基本課題→解決策
 ユースケースを考える→ユースケース記述
 仮説（初期モデル）→検討→モデルの改訂
 さらに揺さぶり→より本質的なモデル
 最小セットで実装
10
15. モデリング
15.2 自動改札システム（3）
 自動改札システムのユースケースを考えて
 ユースケース図
 ユースケース記述
 システム境界
アクタは誰？
切符を購入する
自動改札システム
入場する
利用者
社内検札する
車掌
出場する
切符を回収する
料金を設定する
駅員
（事業者の代理）
11
15. モデリング
15.2 自動改札システム（4）
 ユースケース記述
ユースケース名：入場する。
アクター：利用者（乗客）
目的：乗客は入場して電車に乗りたい。事業者は妥当な乗客のみを入場させたい。
事前条件：その乗客は入場していない。
基本系列：
①アクターは，自分が妥当な乗客である証明をシステムに提示する。
②システムはその証明を確認し，妥当であればアクターだけ入場を許す。
③アクターは入場する。
④システムは，アクターが入場したことを記録する。
事後条件：その乗客が入場している。
代替系列：基本系列②で，証明が妥当でなければ警告する。
備考：・システムは乗客を停滞させないこと。
・入場管理にはゲートを使う。
・入場したかどうかを切符などの証明に記録する。
・証明には，切符，プリペイドカード，回数券，定期券などのタイプがある。
12
15. モデリング
15.2 自動改札システム（5）
 ユースケース記述
ユースケース名：出場する。
アクター：利用者（乗客）
目的：乗客は目的地で出場したい。事業者は料金不足の乗客の出場を阻止したい。
事前条件：その乗客は出場していない。
基本系列：
①アクターは，自分が入場を記録した証明をシステムに提示する。
②システムはその証明を確認し，料金が足りていれば出場を許す。
③アクターは出場する。
④システムは，証明を回収する。
事後条件：その乗客が出場している。
代替系列：基本系列②で，料金が不足であれば警告して出場を阻止する。
備考：・システムは乗客を停滞させないこと。
・出場管理にはゲートを使う。
・証明がプリペイドカードの場合は，回収する代わりに，代金を決済する。
13
15. モデリング
15.2 自動改札システム（6）
 初期モデル
運賃
営業キロ数
運賃
get運賃()
1
駅
名称
基準距離
入場駅
出場駅
定期券
営業キロ数
*
*
証明
入場日時
出場日時
/営業キロ数
/運賃
切符
購入料金
営業キロ数は入場
駅と出場駅の基準
距離の差
プリペイドカード
回数券
残高
14
15. モデリング
15.2 自動改札システム（7）
アクタ
 シーケンス図による検討
 アクタ
乗客か自動改札機か
現物とオブジェクトは別
自動改札機
切符
U/I
：切符
：駅
：利用者
入場する（東京駅）
find駅（東京駅）
：切符
：駅
：利用者
出場する（渋谷駅）
：運賃
東京駅：
駅
ドメイン
渋谷駅
：駅
find駅（渋谷駅）
get運賃（東京駅，渋谷駅）
get基準距離（）
get基準距離（）
運賃と購入金額を
比較する
15
15. モデリング
15.2 自動改札システム（8）
 オブジェクト図による検討
：運賃
：運賃
運賃=
運賃=190
東京：駅
名称＝東京
基準距離＝0
渋谷：駅
東京：駅
入場駅
名称＝東京
基準距離＝0
：切符
入場日時=02.15.01...
出場日時=
購入金額=190
/営業キロ数=
/運賃=
名称＝渋谷
基準距離＝14
東京駅で，190円の切符を買って入場する
渋谷：駅
入場駅
出場駅
：切符
入場日時=02.15.01...
出場日時=02.15.01…
購入金額=190
/営業キロ数=14
/運賃=190
名称＝渋谷
基準距離＝14
渋谷駅で出場する
16
15. モデリング
15.2 自動改札システム（9）
 モデルの改訂
「指定席」，「特急」の扱いを検討
から
/運賃
*
営業キロ数
輸送料金
get運賃()
まで
1
駅
路線
{ordered}
*
名称
基準キロ数
get基準キロ数()
区間
から
有効期限
*
*
入場
*
出場
*
*
《多重》
証明
入場日時
出場日時
料金
/運賃
入場する()
出場する()
グリーン
区間
まで
普通
*
定期券
*
指定席
切符
購入料金
急行
特急
プリペイドカード
/残高
*
1
乗客
回数券
有効期限は
ない
17
15. モデリング
15.2 自動改札システム（10）
 モデルの改訂
「証明」の意味を検討
状態遷移するオブジェクト
キャンセル
行使前
入場
行使中
出場
行使済
18
15. モデリング
15.2 自動改札システム（11）
/時刻表
 モデルの改訂
乗車便の日付は
有効期間中である
こと
日付
*
便
1
1
指定席
*
* 乗車便
*
着席権*
グリーン
1
0..1
《多重》
有効期限
普通
*
*
駅
事業者
*
路線
名称
{ordered} 基準キロ数
*
急行
特急
*
入場
*
出場
*
から
*
/運賃
まで
*
営業キロ数
輸送料金
get基準キロ数()
*
0..1
乗車権
入場日時
出場日時
料金
/運賃
子供
割引
*
学割
入場する()
出場する()
《多重》
get運賃()
区間
から
0..1
《動的》
区間
まで
行使前
「証明」や「切符」は「乗車権」のビュー
行使中
行使済
* 定期券
*
*
1
乗客
切符
購入料金
回数券
プリペイドカード
/残高
有効期限は
ない
19
15. モデリング
15.3 酒屋の在庫問題（1）
 演習13
別紙の課題（酒屋の在庫問題）を読んで，型モデル（概念レ
ベル）を作ってください。
①基本課題を想定する
②基本的なユースケースを記述する（1件以上）
③概念の整理
④初期モデル
⑤基本的なユースケースによる検証
⑥初期モデルの改訂
⑦要求のエスカレーション
⑧モデルの改訂
20
15. モデリング
15.3 酒屋の在庫問題
（2）
当日，翌日納入の場
 課題
合は欠品する可能性
がある
仕入注文
0日
受注
入庫
+1日
+2日
出荷
酒類卸売り業のA社の倉庫には，仕入注文に応じて，メーカから毎
日数個のコンテナが搬入されてくる。その内容はビン詰めの酒で，１
つのコンテナには10銘柄まで混載できる。扱い銘柄は約200種類ある。
倉庫係は，商品（酒）をコンテナから取り出して倉庫に保管し，それ
を記録した入庫表を受付係へ手渡す。また受付係からの出荷指示に
よって倉庫から商品を出荷することになっている。
さて，受付係は毎日，納入希望日の前日までに，電話で小売店から
の注文を受ける。受付係は，その都度注文票に記入し，そのコピーを
出荷指示として倉庫係に渡す。注文の納入希望日の当日朝時点で当
該商品の在庫数量が不足する場合には，不足分について在庫不足リ
ストに記入し，当日の夕方に，入庫希望日別，商品別に集計して，
メーカに仕入注文を出す。翌日入庫希望分は，翌日の夕方に入庫さ
れる。
A社の，仕入，受注，出荷をサポートする情報システムの概念モデ
ルを作成せよ。
21
15. モデリング
15.3 酒屋の在庫問題（3）
 業務の流れ
卸売商
小売店
酒メーカ
A社
仕入注文
B社
［顧客］注文

仕入発注書
C社

受注票
在庫不足
リスト
受注係
受領書
納品書
コンテナ
倉庫係
納品書
輸送係
出荷指示書
倉庫
22
15. モデリング
15.3 酒屋の在庫問題（4）
 基本定義
「商品の仕入と販売を的確に行うことを支援するシステム」
 CATWOE分析
Customer：小売店
Actor：受付係，倉庫係
Transformation：商品を仕入れて販売する
Weltanschauung：的確に…？
Owner：A社
Environment：酒類市場
 的確さを決める世界観
課題記述には直接
現れない概念
 在庫負担を最小にする（保有量を最小に，かつ滞留期間を最短に）
or
 受注から出荷までの日数（リードタイム）を最短に
メーカ依存
or
 機会損失を最小にする（欠品しない；安全在庫は保有する）
23
15. モデリング
15.3 酒屋の在庫問題（5）
 基本定義の再設定
「安全在庫を確保しつつ，販売状況に合わせて商品を仕入れ
ることを支援するシステム」
 CATWOE分析
Customer：小売店
Actor：受付係，倉庫係
Transformation：商品を仕入れて販売する
Weltanschauung：在庫負担を最小化するが，欠品は避ける
Owner：A社
Environment：酒類市場
 安全在庫
 飛び込み注文対応分
 翌日夕方入庫までのつなぎ
在
庫
量
安全在庫
 注文のキャンセルや変更もある
期首
現在
実績
予定
時間
24
15. モデリング
15.3 酒屋の在庫問題（6）
 ワークフローの整理
は，ユースケースに対応する活動
 新業務フロー
出荷
受付係
倉庫係
出荷を指示する
出荷する
受注
注文
受付係
商品在庫から数
量を差し引く
注文
注文
［出荷済み］
注文を受ける
《view》
商品
当日分だけを
選択
出荷指示書
《view》
納品書
《view》
受領書
仕入発注
受付係
商品
入庫
日締め後の
バッチ処理
在庫不足状態を
見る
倉庫係
《view》
（仕入）納品書
仕入発注する
《view》
翌々日入庫
予定分だけ
受付係
商品を倉庫に
保管する
納品書と突き合
わせる
商品在庫に
数量を加える
入庫を記録する
商品
発注書
《view》
（仕入）納品書
［突き合せ済み］
25
15. モデリング
15.3 酒屋の在庫問題（7）
 演習14
別紙の課題（酒屋の在庫問題）を読んで，型モデル（概念レ
ベル）を作ってください。
①基本課題を想定する
②基本的なユースケースを記述する（1件以上）
③概念の整理
④初期モデル
⑤基本的なユースケースによる検証
⑥初期モデルの改訂
⑦要求のエスカレーション
⑧モデルの改訂
解答例
26
15. モデリング
15.3 酒屋の在庫問題（22）
 仕様モデル，実装モデル
 機能実現の具体的な方法
設計判断
実装判断
 アーキテクチャの設計
階層分け
フレームワークの当てはめ
 ユーザインタフェース設計
 オブジェクト永続化の方法
オブジェクト指向データベース
リレーショナルデータベースへは複雑なマッピングが必要
インピーダンスのミスマッチ
 関連の実装
27
オブジェクト指向モデリング
16. まとめ
16.1 情報システム
16.2 基本定義と基本課題
16.3 モデリングの過程
16.4 よい情報システムの構築
28
16. まとめ
16.1 情報システム
 情報システム工学
 人間活動システム
システム論
システム要素間の相互作用→創発
階層と通信
ソフトな問題
構造化できない問題
自分自身がシステムの一部分
正解がない
対策がまた新たな問題の原因に
 効果的な情報システム
目的（ビジョン，ミッション，ゴール，目標値）の達成
アプローチ（戦略，戦術，作戦）の選択と合意形成
フィードバックと目的・アプローチの修正の繰り返し
目標値と現状との乖離＝動的テンション
敏感でいること
Embrace Change !
29
16. まとめ
16.2 基本定義と基本課題
 変化し続ける人間活動システム
 現実世界（real world）と認識世界
 ソフトな問題構造の合意
 システムの基本定義
合意（Accommodation）
CATWOE分析
Customer：
Actor：
Transformation：
Weltanschauung：
Owner：
Environment：
基本定義のrefine
 基本課題
 解決策の発明
30
16. まとめ
16.3 モデリングの過程
 モデリングとは
 理解と合意のプロセス
 ドメインと操作の分離
ドメインの定義
Ownerによる世界の認識
Universe of Discourse（UoD）
発明
概念レベル
 要求記述としてのユースケース
 操作の実現
 良いモデルの基準
ユーザインタフェース
アプリケーション（機能）
ドメイン（概念の世界）
永続化
適度な抽象性
一般性，単純性，耐変更性，再利用性
31
16. まとめ
16.4 よい情報システムの構築
 情報システム工学とオブジェクト指向
 概念モデルとの素直な対応
概念の実装としてのクラス－インスタンス
概念階層
ソフトウェア工学からの「良い概念」の基準
結合度
凝集度
オブジェクトメタファー
変更に強いモデル
通信と相互作用
 変更吸収の仕組み
拡張のメカニズム
継承
フレームワークの発想
リファクタリングのプラクティス
32
オブジェクト指向モデリング
この講義の主題と目標
 思考を支えるモデリング
ビジネス要求の本質を理解し，当事者間で共有する活動
システム思考（対象をシステムとして見る）
情報システムは成長（変化）するものだという考え方
学ぶこと
 良いモデル
ビジネス構造やビジネスルールを的確に記述
変更に耐えられる問題領域の概念構造を追求する
 モデルの書き方
要求記述，対象領域の概念構造の記述，業務フローの記述，オブジェク
トどうしの対話の記述
33