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

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
モデリング１
12.0 概念モデリングの手順
 要求を認識することから始まる
 ドメイン知識とモデリング技術が必要
 とにかく書く
 書いてから考える
《プロセス》
補助図
初期モデル
を書く
初期モデル
《プロセス》
《プロセス》
活動図を書く
ユースケースを書く
モデルを補強
修正する
要求
知識
シーケンス図，協調図，
ステートチャート図を書い
てモデルをチェックする
改訂モデル
《プロセス》
要求
本質に迫る
本質モデル
8
モデリング１
12.1 自動改札システム
 自動改札システムに関わる活動図
 システム境界
 ユースケースの候補
利用者
切符を買う
プリペイドカードを買う
回数券を買う
入場する
電車に乗って移動する
［到着］
［未到着］
出場する
定期券を買う
9
モデリング１
12.1 自動改札システム
 自動改札システムのユースケースを考えて
 ユースケース図
 ユースケース記述
 システム境界
アクタは誰？
切符を購入する
自動改札システム
入場する
利用者
社内検札する
車掌
出場する
切符を回収する
料金を設定する
駅員
（事業者の代理）
10
モデリング１
12.1 自動改札システム
 ユースケース記述
ユースケース名：入場する。
アクター：利用者（乗客）
目的：乗客は入場して電車に乗りたい。事業者は妥当な乗客のみを入場させ
たい。
事前条件：その乗客は入場していない。
基本系列：
①アクターは，自分が妥当な乗客である証明をシステムに提示する。
②システムはその証明を確認し，妥当であればアクターだけ入場を許す。
③アクターは入場する。
④システムは，アクターが入場したことを記録する。
事後条件：その乗客が入場している。
代替系列：基本系列②で，証明が妥当でなければ警告する。
備考：・システムは乗客を停滞させないこと。
・入場管理にはゲートを使う。
・入場したかどうかを切符などの証明に記録する。
・証明には，切符，プリペイドカード，回数券，定期券などのタイプがある。
11
モデリング１
12.1 自動改札システム
 ユースケース記述
ユースケース名：出場する。
アクター：利用者（乗客）
目的：乗客は目的地で出場したい。事業者は料金不足の乗客の出場を阻止し
たい。
事前条件：その乗客は出場していない。
基本系列：
①アクターは，自分が入場を記録した証明をシステムに提示する。
②システムはその証明を確認し，料金が足りていれば出場を許す。
③アクターは出場する。
④システムは，証明を回収する。
事後条件：その乗客が出場している。
代替系列：基本系列②で，料金が不足であれば警告して出場を阻止する。
備考：・システムは乗客を停滞させないこと。
・出場管理にはゲートを使う。
・証明がプリペイドカードの場合は，回収する代わりに，代金を決済する。
12
モデリング１
12.1 自動改札システム
 ユースケース記述
ユースケース名：証明を回収する。
アクター：駅員
目的：事業者は代金の回収状況を把握したい。証明が再使用できないように
したい。
事前条件：その時点で回収されていない証明がある。
基本系列：
①アクターは，システムにある時点で証明の回収を指示する。
②システムはその時点での代金の回収状況を報告する。
事後条件：その時点で回収されていない証明はない。
代替系列：なし。
備考：・証明のタイプごとに報告する。
・切符は物理的に駅員が回収処理して，本部に送付する。
13
モデリング１
12.1 自動改札システム
 初期のモデル
運賃
営業キロ数
運賃
get運賃()
1
駅
名称
基準距離
入場駅
出場駅
定期券
営業キロ数
*
*
証明
入場日時
出場日時
/営業キロ数
/運賃
切符
購入料金
プリペイドカード
回数券
残高
14
モデリング１
12.1 自動改札システム
自動改札機
切符
 入場する／出場する
 アクタ
ユースケース「入場する」
：切符
 乗客か自動改札機か
 現物とオブジェクトは別
：切符
：利用者
出場する（渋谷駅）
：駅
：駅
：利用者
入場する（東京駅）
find駅（東京駅）
：運賃
東京駅：駅
渋谷駅
：駅
find駅（渋谷駅）
get運賃（東京駅，渋谷駅）
get基準距離（）
get基準距離（）
運賃と購入金額を
比較する
ユースケース「出場する」
15
モデリング１
12.1 自動改札システム
 シナリオベースの検討
 切符
：運賃
：運賃
運賃=
運賃=190
東京：駅
名称＝東京
基準距離＝0
渋谷：駅
名称＝渋谷
基準距離＝14
東京：駅
入場駅
名称＝東京
基準距離＝0
：切符
入場日時=02.12.01...
出場日時=
購入金額=190
/営業キロ数=
/運賃=
東京駅で，190円の切符を買って入場する
渋谷：駅
入場駅
出場駅
名称＝渋谷
基準距離＝14
：切符
入場日時=02.12.01...
出場日時=02.12.01…
購入金額=190
/営業キロ数=14
/運賃=190
渋谷駅で出場する
16
モデリング１
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
モデリング１
12.1 自動改札システム
 モデルの改訂
*
*
から
まで
有効期限
/運賃
営業キロ数
輸送料金
get運賃()
1
*
駅
路線
{ordered}
*
名称
基準キロ数
get基準キロ数()
区間
から
入場
*
出場
*
*
<<多重>>
証明
入場日時
出場日時
料金
/運賃
グリーン
入場する()
出場する()
区間
まで
普通
*
定期券
*
指定席
切符
購入料金
急行
特急
プリペイドカード
/残高
*
1
乗客
回数券
有効期限は
ない
18
モデリング１
12.1 自動改札システム
 モデルの検討
 証明とは何か
 権利の状態
キャンセル
行使前
入場
行使中
出場
行使済
19
モデリング１
12.1 自動改札システム
便の日付は有効
期間中であること
日付
 改訂後
時間割
*
便
*
座席
*
* 指定席
グリーン
<<多重>>
有効期限
事業者
普通
*
*
路線
駅
名称
{ordered} 基準キロ数
*
急行
着席権
特急
*
*
入場
*
出場
*
入場日時
出場日時
料金
/運賃
*
入場する()
出場する()
から
get基準キロ数()
まで
*
/運賃
営業キロ数
* 輸送料金
子供
乗車権
割引
*
学割
get運賃()
区間
から
<<動的>> <<多重>>
区間
まで
行使前
行使中
行使済
* 定期券
*
1
乗客
切符
購入料金
回数券
プリペイドカード
/残高
有効期限は
ない
20
モデリング１
166～172ページ
12.2 CS4管理システム
 CS4の優等コースの管理を支援するシステム
 RFP（Request for Proposal）
 要求仕様書
 複数のProposal
 目的
 スコープ（機能）
 体制
 見積もり（工数，工期，スケジュール）
 入札，業者選定
 契約
 実行
 納入
打診
Customer
契約
Performer
Customer
報告
Performer
実行
21
モデリング１
12.2 CS4管理システム
 CS4コースの管理の現状説明
166ページ
打診
契約
 優等コース
 CS学科のシラバス策定委員会
Customer
Performer
 来年度の授業科目（module）を決定する
 学科主任
 授業科目の講義担当者（講師；lecturer）の割当
報告
実行
 講師
 コースハンドブックの紹介文の更新
 CS4とりまとめ担当者




コースハンドブックの中核部分（紹介文以外）の更新
講師が書いたコースハンドブックの紹介文のチェック
ハンドブック（LATEX）をHTMLに変換
進級以外のCS4受講者（聴講生）をUTOに通知
 CS3とりまとめ担当者
 進級する学生の一覧をCS4のとりまとめ担当者とUTOに通知
22
モデリング１
12.2 CS4管理システム
 CS4コースの管理の現状
166ページ
 学習指導担当者（DoS）
 Dosは１年生の時に一人ひとり決められて，以来，卒業まで固定
 学生にアドバイスする
 履修授業科目選択の相談
これは単なる
意味の説明
 学生
 授業科目への仮登録；履修申請書を教務課に提出
 教務課（UTO）




ハンドブックの印刷
CS4学生原本を保守
履修者むけメーリングリスト（cs4class）の保守
履修申請をチェック
 CS4の学生であること
 授業科目の組み合わせの妥当性
 学生との話し合い
 履修者一覧を作成し，講師に渡す
これが本音？
 開講から3週以内に渡してほしい
23
モデリング１
12.2 CS4管理システム
 RFPを受けての質問
167ページ
 認識の確認
 不明の点
 記述されない状況の明示化
 不合理点の指摘
 提案の方向性の確認
168ページ
 調査と分析
 こんな機能が欲しい？
 全職員（特にCS4とりまとめ担当者）の業務負荷を減らしたい
 学生が直接，オンラインで授業科目を登録するようにしたい
 最新の正確な情報を容易に得たい
 情報ソースの追跡を可能にしたい
 情報作成を自動化して，講師に対する情報提供を迅速にしたい
24
モデリング１
12.2 CS4管理システム
 われわれの方法
 基本定義
 コースハンドブックの作成から履修登録までを，より迅速かつ正確に行うこ
とを支援するシステム
Customer：講師，UTO，学生，CS4とりまとめ担当
Agent：講師，UTO，学生，CS4とりまとめ担当，CS3とりまとめ担当，学科
主任，DoS
Transformation：コースハンドブックを作成し，履修登録を行う
Weltanschauung：講師の手間を省いて，授業に集中させたい
Owner：大学
Environment：CS4学科
 基本課題
すなわち，基本的な現状モデル
（as-is）が新モデル（to-be）
 迅速かつ正確な情報の収集と提供
→ワークフロー自動化（コミュニケーション）
→進度管理
25
モデリング１
12.2 CS4管理システム
 ワークフローの確認
 コースハンドブックの作成
シラバス策定委員会
学科主任
授業科目の設定
担当講師を決める
CS4とりまとめ担当者
講師
コースハンドブックの
中核部分を作成する
コースハンドブック
紹介文を更新する
UTO
コースハンドブック
をチェックする
［問題あり］
コースハンドブック
をHTMLに変換
コースハンドブック
を印刷する
26
モデリング１
12.2 CS4管理システム
 ワークフローの確認
 CS4学生一覧表の作成
CS3とりまとめ担当者 CS4とりまとめ担当者
UTO
進級学生一覧を
とりまとめる
CS4への聴講生一覧
をとりまとめる
CS4学生一覧表原
本の保守
メーリングリストの
更新
27
モデリング１
12.2 CS4管理システム
 ワークフローの確認
 履修者一覧表の作成
学生
UTO
DoS
履修申請書を
作成する
履修申請書を
チェックする
［不明点あり］
or
UTOと話し合う
［不明点なし］
問い合わせを受ける
授業科目ごとの
履修者一覧の作成
一覧表の配付
28
モデリング１
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
モデリング１
12.2 CS4管理システム
打診
契約
 ユースケースの作成
Actor
System
ユースケース名：コースハンドブックの授業科目
紹介文を書く。
実行
報告
アクタ：講師
目的：学生が授業科目を正しく選択できるように情報を提供する。
事前条件：当該年度の紹介文は登録されていない。
基本系列：
①アクタは，対象の授業科目を指定して紹介文の入力を要請する。
②システムは授業科目のインデックス情報（と，過去の紹介文があればそ
れ）
を表示して，紹介文の入力を促す。
③アクタは紹介文を入力する。
④システムは，当該年度の紹介文が入力されたことを登録する。
事後条件：当該年度の紹介文が登録されている。
代替系列：...
備考：紹介文は400文字程度であること。
30
モデリング１
12.2 CS4管理システム
担当する
講師
 概念モデリング
*
6
履修する
 主要な概念から着手
 学生，講師，授業科目
DoS
*
授業科目
6..*
学生 1..*
 時間の観念
1..*
聴講生
一般学生
優等コース
*
講師
担当する
授業科目
*
科目紹介
*
6..*
*
170ページ
*
DoS
1..*
*
学生
履修登録
6
1..*
聴講生
一般学生
優等コース
*
*
コースハンドブック
年度
*
31
モデリング１
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
モデリング１
12.2 CS4管理システム
 ユースケース「履修申請を行う」
 シーケンス図の例
アクタ
: Registory
: 学生
: 優等コース
: 履修登録
getStudent( )
getModule( )
chooseModule( )
isAcceptable( )
new
setEnroll( )
registerEnroll( )
33
モデリング１
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
モデリング１
12.4 モデルの良さの基準
 ユースケース
 妥当なユースケース
 目的充足性（効果的）
 型モデル（概念レベル）
 世界（UoD）が記述できている
 適度な抽象性
 一般性
 単純性（良い概念，良い構造）
 耐変更性
 再利用性
 ユースケースが実現できている
 理解の共有
37
モデリング１
宿題
 別紙の課題（酒在庫問題）を読んで，
①基本定義を想定する
②基本的なユースケースを記述する
③型モデル（概念レベル）を作ってください。
必要に応じてアクティビティ図などを作ってもかまいません。
提出してください。成績評価の一部にします。
38

Download Report