オブジェクト指向による 分析と設計

47070
オブジェクト指向モデリング
[12]
2003年 1月14日
オブジェクト指向モデリング
前回 ソフトウェアパターン
11.1 パターンランゲージ
11.2 パターンの意味
11.3 パターンの形式
11.4 ソフトウェアパターンの歴史
11.5 PLoPの活動
11.6 刊行されたパターンたち
11.7 アナリシスパターン
11.8 デザインパターン
2
ソフトウェアパターン
11.7 アナリシスパターン
このオブジェクト
図はどうなる?
 責任関係(Accountability)
 知識レベルと操作レベル
 パワータイプ(ベキ型)
 操作レベルの型の制約を記述
 鏡像関係
責任関係型
inv:
collx:set(責任関係)=self.the責任関係
collX->forALL( x |
x.型.依頼者->includes(x.依頼者.型)
and
x.型.実行者->includes(x.実行者.型))
作業
*
依頼者
*
実行者
1..*
型 1
*
*
*
*
依頼者
1
*
*
型 1
知識レベル
責任関係
*
パーティ型
1..*
操作レベル
パーティ
実行者
1
1 有効期限
期間
人
組織
3
ソフトウェアパターン
11.7 アナリシスパターン
このオブジェクト
図はどうなる?
 勘定(Account)
 要約(Summary)
 ロールアップ
{抽象}
構成要素
勘定
* /残高 : 量
{階層}
/対象エントリ
*
0..1
要約勘定
対象エントリ
明細勘定
1
*
エントリ
数量 : 量
トランザクション
2..*
1
inv:
/対象エントリ=self.対象エントリ
inv:
/対象エントリ=self.構成要素./対象エントリ
4
ソフトウェアパターン
11.8 デザインパターン
 Observer
 1つの主題(Subject)に対して複数の表示(Observers)
 ObserverからSubjectへの1方向の可視性を保証
 結合度を下げる
 update()は逆方向だが,変更時には問題にならない
observer
->update()
{abstract}
{abstract}
Subject
*
Notify()
Attach(Observer)
Detach(observer)
ConcreteSubject
return subjectState
SetState()
GetState()
subjectState
Observer
update()
observer
subject
ConcreteObserver
update()
observerState
observerState=
subject.GetState()
5
ソフトウェアパターン
11.8 デザインパターン
 State
 内部状態が変化したときに,その振る舞いを変える
 状態に依存した振る舞いを局所化
 状態ごとの振る舞いを用意
 ConcreteStateはsingleton
state.Handle()
Context
Request()
state
{abstract}
*
State
state Handle()
ConcreteStateA ConcreteStateB
Handle()
Handle()
6
オブジェクト指向モデリング
第12回 モデリング1
12.0 概念モデリングの手順
12.1 自動改札システム
12.2 CS4
12.3 実際のモデル
12.4 モデルの良さの基準
テキスト 第15章
7
モデリング1
12.0 概念モデリングの手順
 要求を認識することから始まる
 ドメイン知識とモデリング技術が必要
 とにかく書く
 書いてから考える
《プロセス》
補助図
初期モデル
を書く
初期モデル
《プロセス》
《プロセス》
活動図を書く
ユースケースを書く
モデルを補強
修正する
要求
知識
シーケンス図,協調図,
ステートチャート図を書い
てモデルをチェックする
改訂モデル
《プロセス》
要求
本質に迫る
本質モデル
8
モデリング1
12.1 自動改札システム
 自動改札システムに関わる活動図
 システム境界
 ユースケースの候補
利用者
切符を買う
プリペイドカードを買う
回数券を買う
入場する
電車に乗って移動する
[到着]
[未到着]
出場する
定期券を買う
9
モデリング1
12.1 自動改札システム
 自動改札システムのユースケースを考えて
 ユースケース図
 ユースケース記述
 システム境界
アクタは誰?
切符を購入する
自動改札システム
入場する
利用者
社内検札する
車掌
出場する
切符を回収する
料金を設定する
駅員
(事業者の代理)
10
モデリング1
12.1 自動改札システム
 ユースケース記述
ユースケース名:入場する。
アクター:利用者(乗客)
目的:乗客は入場して電車に乗りたい。事業者は妥当な乗客のみを入場させ
たい。
事前条件:その乗客は入場していない。
基本系列:
①アクターは,自分が妥当な乗客である証明をシステムに提示する。
②システムはその証明を確認し,妥当であればアクターだけ入場を許す。
③アクターは入場する。
④システムは,アクターが入場したことを記録する。
事後条件:その乗客が入場している。
代替系列:基本系列②で,証明が妥当でなければ警告する。
備考:・システムは乗客を停滞させないこと。
・入場管理にはゲートを使う。
・入場したかどうかを切符などの証明に記録する。
・証明には,切符,プリペイドカード,回数券,定期券などのタイプがある。
11
モデリング1
12.1 自動改札システム
 ユースケース記述
ユースケース名:出場する。
アクター:利用者(乗客)
目的:乗客は目的地で出場したい。事業者は料金不足の乗客の出場を阻止し
たい。
事前条件:その乗客は出場していない。
基本系列:
①アクターは,自分が入場を記録した証明をシステムに提示する。
②システムはその証明を確認し,料金が足りていれば出場を許す。
③アクターは出場する。
④システムは,証明を回収する。
事後条件:その乗客が出場している。
代替系列:基本系列②で,料金が不足であれば警告して出場を阻止する。
備考:・システムは乗客を停滞させないこと。
・出場管理にはゲートを使う。
・証明がプリペイドカードの場合は,回収する代わりに,代金を決済する。
12
モデリング1
12.1 自動改札システム
 ユースケース記述
ユースケース名:証明を回収する。
アクター:駅員
目的:事業者は代金の回収状況を把握したい。証明が再使用できないように
したい。
事前条件:その時点で回収されていない証明がある。
基本系列:
①アクターは,システムにある時点で証明の回収を指示する。
②システムはその時点での代金の回収状況を報告する。
事後条件:その時点で回収されていない証明はない。
代替系列:なし。
備考:・証明のタイプごとに報告する。
・切符は物理的に駅員が回収処理して,本部に送付する。
13
モデリング1
12.1 自動改札システム
 初期のモデル
運賃
営業キロ数
運賃
get運賃()
1
駅
名称
基準距離
入場駅
出場駅
定期券
営業キロ数
*
*
証明
入場日時
出場日時
/営業キロ数
/運賃
切符
購入料金
プリペイドカード
回数券
残高
14
モデリング1
12.1 自動改札システム
自動改札機
切符
 入場する/出場する
 アクタ
ユースケース「入場する」
:切符
 乗客か自動改札機か
 現物とオブジェクトは別
:切符
:利用者
出場する(渋谷駅)
:駅
:駅
:利用者
入場する(東京駅)
find駅(東京駅)
:運賃
東京駅:駅
渋谷駅
:駅
find駅(渋谷駅)
get運賃(東京駅,渋谷駅)
get基準距離()
get基準距離()
運賃と購入金額を
比較する
ユースケース「出場する」
15
モデリング1
12.1 自動改札システム
 シナリオベースの検討
 切符
:運賃
:運賃
運賃=
運賃=190
東京:駅
名称=東京
基準距離=0
渋谷:駅
名称=渋谷
基準距離=14
東京:駅
入場駅
名称=東京
基準距離=0
:切符
入場日時=02.12.01...
出場日時=
購入金額=190
/営業キロ数=
/運賃=
東京駅で,190円の切符を買って入場する
渋谷:駅
入場駅
出場駅
名称=渋谷
基準距離=14
:切符
入場日時=02.12.01...
出場日時=02.12.01…
購入金額=190
/営業キロ数=14
/運賃=190
渋谷駅で出場する
16
モデリング1
12.1 自動改札システム
 シナリオベースの検討
 定期券
東京:駅
名称=東京
基準距離=0
渋谷:駅
名称=渋谷
基準距離=14
東京:駅
から
入場駅
まで
名称=東京
基準距離=0
a:定期券
入場日時=02.12.01...
出場日時=
購入金額=XXXXX
所有者=児玉公信
有効期限=02.10.01
~ 03.03.31
渋谷:駅
名称=渋谷
基準距離=14
から
入場駅
まで
出場駅
a:定期券
入場日時=02.12.01...
出場日時=02.12.01...
購入金額=XXXXX
/所有者=児玉公信
有効期限=02.10.01
~ 03.03.31
17
モデリング1
12.1 自動改札システム
 モデルの改訂
*
*
から
まで
有効期限
/運賃
営業キロ数
輸送料金
get運賃()
1
*
駅
路線
{ordered}
*
名称
基準キロ数
get基準キロ数()
区間
から
入場
*
出場
*
*
<<多重>>
証明
入場日時
出場日時
料金
/運賃
グリーン
入場する()
出場する()
区間
まで
普通
*
定期券
*
指定席
切符
購入料金
急行
特急
プリペイドカード
/残高
*
1
乗客
回数券
有効期限は
ない
18
モデリング1
12.1 自動改札システム
 モデルの検討
 証明とは何か
 権利の状態
キャンセル
行使前
入場
行使中
出場
行使済
19
モデリング1
12.1 自動改札システム
便の日付は有効
期間中であること
日付
 改訂後
時間割
*
便
*
座席
*
* 指定席
グリーン
<<多重>>
有効期限
事業者
普通
*
*
路線
駅
名称
{ordered} 基準キロ数
*
急行
着席権
特急
*
*
入場
*
出場
*
入場日時
出場日時
料金
/運賃
*
入場する()
出場する()
から
get基準キロ数()
まで
*
/運賃
営業キロ数
* 輸送料金
子供
乗車権
割引
*
学割
get運賃()
区間
から
<<動的>> <<多重>>
区間
まで
行使前
行使中
行使済
* 定期券
*
1
乗客
切符
購入料金
回数券
プリペイドカード
/残高
有効期限は
ない
20
モデリング1
166~172ページ
12.2 CS4管理システム
 CS4の優等コースの管理を支援するシステム
 RFP(Request for Proposal)
 要求仕様書
 複数のProposal
 目的
 スコープ(機能)
 体制
 見積もり(工数,工期,スケジュール)
 入札,業者選定
 契約
 実行
 納入
打診
Customer
契約
Performer
Customer
報告
Performer
実行
21
モデリング1
12.2 CS4管理システム
 CS4コースの管理の現状説明
166ページ
打診
契約
 優等コース
 CS学科のシラバス策定委員会
Customer
Performer
 来年度の授業科目(module)を決定する
 学科主任
 授業科目の講義担当者(講師;lecturer)の割当
報告
実行
 講師
 コースハンドブックの紹介文の更新
 CS4とりまとめ担当者




コースハンドブックの中核部分(紹介文以外)の更新
講師が書いたコースハンドブックの紹介文のチェック
ハンドブック(LATEX)をHTMLに変換
進級以外のCS4受講者(聴講生)をUTOに通知
 CS3とりまとめ担当者
 進級する学生の一覧をCS4のとりまとめ担当者とUTOに通知
22
モデリング1
12.2 CS4管理システム
 CS4コースの管理の現状
166ページ
 学習指導担当者(DoS)
 Dosは1年生の時に一人ひとり決められて,以来,卒業まで固定
 学生にアドバイスする
 履修授業科目選択の相談
これは単なる
意味の説明
 学生
 授業科目への仮登録;履修申請書を教務課に提出
 教務課(UTO)




ハンドブックの印刷
CS4学生原本を保守
履修者むけメーリングリスト(cs4class)の保守
履修申請をチェック
 CS4の学生であること
 授業科目の組み合わせの妥当性
 学生との話し合い
 履修者一覧を作成し,講師に渡す
これが本音?
 開講から3週以内に渡してほしい
23
モデリング1
12.2 CS4管理システム
 RFPを受けての質問
167ページ
 認識の確認
 不明の点
 記述されない状況の明示化
 不合理点の指摘
 提案の方向性の確認
168ページ
 調査と分析
 こんな機能が欲しい?
 全職員(特にCS4とりまとめ担当者)の業務負荷を減らしたい
 学生が直接,オンラインで授業科目を登録するようにしたい
 最新の正確な情報を容易に得たい
 情報ソースの追跡を可能にしたい
 情報作成を自動化して,講師に対する情報提供を迅速にしたい
24
モデリング1
12.2 CS4管理システム
 われわれの方法
 基本定義
 コースハンドブックの作成から履修登録までを,より迅速かつ正確に行うこ
とを支援するシステム
Customer:講師,UTO,学生,CS4とりまとめ担当
Agent:講師,UTO,学生,CS4とりまとめ担当,CS3とりまとめ担当,学科
主任,DoS
Transformation:コースハンドブックを作成し,履修登録を行う
Weltanschauung:講師の手間を省いて,授業に集中させたい
Owner:大学
Environment:CS4学科
 基本課題
すなわち,基本的な現状モデル
(as-is)が新モデル(to-be)
 迅速かつ正確な情報の収集と提供
→ワークフロー自動化(コミュニケーション)
→進度管理
25
モデリング1
12.2 CS4管理システム
 ワークフローの確認
 コースハンドブックの作成
シラバス策定委員会
学科主任
授業科目の設定
担当講師を決める
CS4とりまとめ担当者
講師
コースハンドブックの
中核部分を作成する
コースハンドブック
紹介文を更新する
UTO
コースハンドブック
をチェックする
[問題あり]
コースハンドブック
をHTMLに変換
コースハンドブック
を印刷する
26
モデリング1
12.2 CS4管理システム
 ワークフローの確認
 CS4学生一覧表の作成
CS3とりまとめ担当者 CS4とりまとめ担当者
UTO
進級学生一覧を
とりまとめる
CS4への聴講生一覧
をとりまとめる
CS4学生一覧表原
本の保守
メーリングリストの
更新
27
モデリング1
12.2 CS4管理システム
 ワークフローの確認
 履修者一覧表の作成
学生
UTO
DoS
履修申請書を
作成する
履修申請書を
チェックする
[不明点あり]
or
UTOと話し合う
[不明点なし]
問い合わせを受ける
授業科目ごとの
履修者一覧の作成
一覧表の配付
28
モデリング1
12.2 CS4管理システム
 ユースケースの作成
 どのアクティビティを取り出すか
 コースハンドブックを作成する
 CS4学生リストを生成する
 履修申請する
 システム境界を決める
 機能の発明
 概念モデルを作る
アクティビティの取り出し
システム境界を決める
概念モデリング
機能の発明
教科書(p.168)のユースケー
スの粒度は大きすぎる
ユースケースの候
補
1. コースハンドブックの授業科目紹介文を書く。
2. コースハンドブックの中核部分を書く。
3. コースハンドブックを編集する。
4. コースハンドブックをHTMLに変換する。
5. コースハンドブックを印刷する。
6. CS3→CS4進級者を登録する。
7. CS4聴講生を登録する。
8. CS4登録学生を保守する。
9. CS4メーリングリストを保守する。
10. 履修申請を行う。
12. 履修申請を照会する。
12. 履修申請を確定する。
13. 履修予定者リストを作成する。
29
モデリング1
12.2 CS4管理システム
打診
契約
 ユースケースの作成
Actor
System
ユースケース名:コースハンドブックの授業科目
紹介文を書く。
実行
報告
アクタ:講師
目的:学生が授業科目を正しく選択できるように情報を提供する。
事前条件:当該年度の紹介文は登録されていない。
基本系列:
①アクタは,対象の授業科目を指定して紹介文の入力を要請する。
②システムは授業科目のインデックス情報(と,過去の紹介文があればそ
れ)
を表示して,紹介文の入力を促す。
③アクタは紹介文を入力する。
④システムは,当該年度の紹介文が入力されたことを登録する。
事後条件:当該年度の紹介文が登録されている。
代替系列:...
備考:紹介文は400文字程度であること。
30
モデリング1
12.2 CS4管理システム
担当する
講師
 概念モデリング
*
6
履修する
 主要な概念から着手
 学生,講師,授業科目
DoS
*
授業科目
6..*
学生 1..*
 時間の観念
1..*
聴講生
一般学生
優等コース
*
講師
担当する
授業科目
*
科目紹介
*
6..*
*
170ページ
*
DoS
1..*
*
学生
履修登録
6
1..*
聴講生
一般学生
優等コース
*
*
コースハンドブック
年度
*
31
モデリング1
12.2 CS4管理システム
 実装モデリング
<<UserInterface>>
Login
 責任の配置
 操作上の人工物
 冗長な参照の削除
授業科目
講師
科目名
紹介文
担当する
氏名
*
teachModule()
setLecturer()
checkOutDescription()
checkInDescription()
isUpToDate()
makeStudentList()
6..*
DoS
履修登録
成績
学生
氏名
registerEnroll()
6 deregisterEnroll()
chooseModule()
chooseStudent()
<<Facade>>
Registry
getStudent()
getLecturer()
getDos()
getModule()
getCourse()
getEnroll()
1..*
*
setup()
adminstratorLogin()
addStudent()
addLecturer()
addModule()
changeLecturer()
studentLogin()
lecturerLogin()
1..*
優等コース
聴講生
一般学生
validateChoices()
名称
一般説明文
*
isHandbookReady()
isAcceptable()
32
モデリング1
12.2 CS4管理システム
 ユースケース「履修申請を行う」
 シーケンス図の例
アクタ
: Registory
: 学生
: 優等コース
: 履修登録
getStudent( )
getModule( )
chooseModule( )
isAcceptable( )
new
setEnroll( )
registerEnroll( )
33
モデリング1
12.2 CS4管理システム
 ユースケース「授業科目紹介文を書く」
 シーケンス図の例
アクタ
: 授業科目
getModule
addDescription
34
モデル図の理解
12.3 実際のモデル
顧客注文
顧客オーダ番号
顧客名称
*
数量
希望納期
受注日時
 生産管理システム
品目群
品目群名
1..1
1
0..*
座席予約
1..*
生産計画
1..* 製造番号
出来数量
/製造納期
/実績原価
pegging
<<導出>>
対象
*
/品目
/製造リードタイム
最終製品
*
用途使用条件種
0..*
/構成部品
(from 技術データ管理)
1
1
用途使用条件種
1
1
*
用途使用条件値
(from 技術データ管理)
未定
*
* /変更可能用途使用条件
用途使用条件種
1..*
製造方法
/ 着手日
/ 完了日
/ 加工原価
ロットサイズ
/加工機能
加工機能名
加工時間
工順 * 着手日
完了日
{ordered}
加工データ
*
1
1
群加工機能
加工資源
投入資源
投入数量
生産品目
* 生産数量
*
1
assembly
投入品目
* 投入数量
*
1
component
*
1
*
部品調達計画
制約:
最終製品の完
成時に未定であっ
てはならない
部品期首在庫
部品実在庫量
* 期首 : 日付
1
指定日
1
/在庫
/
部品有効在庫量
0..1
1
<<動的>>
加工終了
加工中
未着手
内作品
/製造原価
調達品
調達原価
加工資源
単位原価
加工データ
35
モデル図の理解
12.3 実際のモデル
 素材発注システム
アクタ
: 在庫調整
create
移動元_ :
エントリ
create
移動元 :
在庫単位
移動先_ :
エントリ
移動先 :
在庫単位
findAccount
if not found
createAccount
create
findAccount
場所
if not found
createAccount
製品メーカ
*
素材メーカ
発注
*
素材
*
/在庫単位
*
*
*
*
*
*
進捗
SKU
/エントリ
/トランザクション
2..*
*
/在庫
出庫
入庫
移動
在庫調整
<<動的>>
染色
裁断
完成
36
モデリング1
12.4 モデルの良さの基準
 ユースケース
 妥当なユースケース
 目的充足性(効果的)
 型モデル(概念レベル)
 世界(UoD)が記述できている
 適度な抽象性
 一般性
 単純性(良い概念,良い構造)
 耐変更性
 再利用性
 ユースケースが実現できている
 理解の共有
37
モデリング1
宿題
 別紙の課題(酒在庫問題)を読んで,
①基本定義を想定する
②基本的なユースケースを記述する
③型モデル(概念レベル)を作ってください。
必要に応じてアクティビティ図などを作ってもかまいません。
提出してください。成績評価の一部にします。
38