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

オブジェクト指向モデリング
[7]
2003年11月11日
6.高度な関連
6.6 型図の演習（2）
 手順
基本定義から基本課題を発明
する
基本課題からユー
スケースを発明する
ワークフローを書い
て，隠れたユース
ケースを洗い出す
初期の概念モデルを書く
モデルを揺さぶる
疑問点を考える
本質的な概念モデルを導く
2
6.高度な関連
6.6 型図の演習（3）
 初期の概念モデルを書く
 手順
対象領域における概念を取り出す
重要な概念を他の概念との関係で記述する
ロールを識別する
包含する概念（スーパータイプ）か，包含される概念（サブタイプ）か
知識レベルの概念か
属性か
「もの－こと－もの」で書いてみる
多重度を考える
次に重要そうな概念を取り上げて，繰り返す
 名詞抽出法
3
6.高度な関連
6.6 型図の演習（4）
 初期の概念モデル
まとめ
販売日
/合計金額
 最初の対象世界の理解
｛導出｝
*
文脈が与えられないと，いろんなモデルができてしまう
 疑問点
商品
商品名
単価
現物管理が要るか
客をどこまで管理するか
売上げはどうするか
従業員の給与は歩合？
：
：
客
年齢層
性別
1
1
従業員
*
数量
/金額
客
商品
1
商品名
単価
型 1
*
販売
*
現品
商品
販売日
数量
/合計金額
/金額
inv：
self.合計金額=
self.the明細,/金額->sum
*
1
inv：
self.金額=
the商品.単価×self.数量
氏名
*
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：動的モデル1：協調図，シーケンス図
動的モデル2：状態図，活動図
実装モデル：実装モデルとプログラム
モデリング1：モデル図の理解：アナリシスパターン，事例
モデリング2：モデル図の作成，モデルの評価基準
モデリング3：例題によるモデル図の作成
5
オブジェクト指向モデリング
7.機能モデル1
7.1 ユースケース
7.2 アクタ
7.3 システム境界
7.4 シナリオ
7.5 ユースケース記述
7.6 ユースケースに潜む問題
6
7. 機能モデル1
7.1 ユースケース
 「ソフトウエアに割り当てられた要求」
 アクタとシステムの関わり
システム内部は書かない
アクタ
 ユースケース（記述）
機能要求の記述
ユーザが読んで分かる
相互作用図を書く起点
型図の検証
ユースケース
在庫を確認する
受注係
注文を受ける
 ユースケース図
 列挙する
システムの機能の網
羅性をみる
アクタ
ユースケース名
開発のスコープ（要求セット）
7
7. 機能モデル1
7.2 アクタ
 アクタ
ロール
受益者
primary actor（主アクタ）
secondary actor（支援アクタ）
在庫を確認する
受注係
注文を受ける
アクタとなりうるもの
主体的にシステムと関わるもの
ownerではない（ownerの代理人はありうる）
人間に限らない
《actor》
受注係
システムと相互作用するもの
パーティ
 なぜユースケースにアクタが必要か
 なぜアクタは一つだけなのか
8
7. 機能モデル1
7.3 システム境界
 システムの範囲
システムの内と外を分ける
図書館システム
本を貸し出す
書名（書誌情報）を
登録する
文献を検索する
本の返却を受ける
図書館の
職員
新しい蔵書を登録する
会員を登録する
本の棚卸を行う
雑誌を製本する
図書館の
職員
未返却者に督促状を送る
蔵書を検索する
貸出予約を受ける
利用者
9
7. 機能モデル1
7.4 シナリオ（1）
 具体的なシステムとの関わり
物語として書く
キャスト
誰が
シーン
いつ
どこで
なぜ
アクション
何を
どんなふうに
どれだけ
 ユースケースのインスタンス
 シナリオを抽象化したものがユースケース
10
7. 機能モデル1
7.4 シナリオ（2）
 演習9
ビデオレンタル店に関するシナリオを書いてください。
インスタンスをでっち上げて
解答例
11
7. 機能モデル1
7.4 シナリオ（3）
 演習10
次の型図を基に，貸出のシナリオに対応するオブジェクト図
を書いてください。
ジャンル
制約：
「未成年会員」に「成
人向き」を貸し出せない
インスタンス：
未成年会員
成年会員
会員型
*
ジャンル名
インスタンス：
アニメ，邦画，
洋画，成人向き
型
貸出条件
*
単価
*
ビデオタイトル
作品名
主演
型
{不完全}
新作
型
*
*
氏名
住所
*
貸出
会員
*
*
ビデオ
ビデオNo.
《動的》
貸出中
貸出日
/返却予定日
/代金
返却済
返却日
/追加代金
解答例
12
7. 機能モデル1
7.5 ユースケース記述（1）
 ユースケース記述の形式
「（アクタが）○○したい」と書く
と，目的らしくなる
ユースケース名･････「○○する」
アクタ
目的････････アクタまたはシステムのownerにとっての目的。
事前条件････UC実行前の主要なオブジェクトの状態
基本系列････アクタとシステムのやりとり
代替系列････例外のやりとり
事後条件････UC実行後の主要なオブジェクトの状態
備考･･･････ UC理解のためなら何でも書く。非機能要求もここで
シナリオを付加することもある
そのままテストケースになる
 アクタとシステムとのやりとり
実装を書かない（設計者の仕事）
実装を示唆するなら備考で
13
7. 機能モデル1
7.5 ユースケース記述（2）
 記述例
アクタとシステム
のやりとり
ユースケース名：本を貸し出す
アクタ：図書館の職員
目
的：どの本を誰に貸し出したを記録したい。
実装を書かない
事前条件：貸し出した事実が記録されていない。
基本系列：①アクタがこのユースケースを起動する。
②システムは利用者と貸し出そうとする本の識別を要求する。
③アクタはそれらの識別を提示する。
④システムはその利用者が貸し出しの上限を越えていないことを確認して，
その本が貸し出されたことを記録する。
代替系列：基本系列④で利用者が貸し出しの上限を超えている場合は貸し出しを拒否
する。
事後条件：貸し出した事実が記録されている。
備
考：①利用者の識別は利用者カードで行う。
実装を示唆する
②本の識別は本に埋め込んだICタグで行う。
③貸し出しの記録は，貸し出しの日時だけとする。
④利用者が本人であることは，利用者カードの写真によってアクタが行う。
おまけ
14
7. 機能モデル1
7.5 ユースケース記述（3）
 裏腹な要求
「注文を受ける」と「注文する」
「本を返却する」と「本の返却を受ける」
アクタと目的は異なるが，基本系列は同じ
機能は同じだが，目的が異なる
 アクタの要求を満足しないユースケース
「チェックインする」
「本を返却する」
アクタがチェックイン／返却したいわけではない。
システムのOwner側の都合による間接的要求
この場合の目的は難しい
「妥当な顧客であることを確認したい」
「他の利用者が借りられるようにしたい」
15
7. 機能モデル1
7.5 ユースケース記述（4）
 演習11
ファーストフード店の窓口システムを考えて，ユースケースを
1つ書いてください。
窓口で客がメニューに基づいて商品を注文する
受注担当者は注文を聞く
受注担当者はその注文を調理担当に渡す
客は注文品ができるまで，窓口で待つ
調理担当は注文品を作る
受注担当者は料金を計算し，請求する
客は代金を支払う
受注担当者は客から代金を受け取る
客はできあがった商品を受け取る
受注担当者は客に商品を渡す
16
7. 機能モデル1
7.6 ユースケースに潜む問題
 制御オブジェクトを作る
オブジェクトに任せないで，自分で処理してしまう
型構造，責務の割付が不全→悪構造
非オブジェクト指向のプログラム（処理とデータの二元論）
 詳細な手続き記述にとらわれる
本質的な要求から逸れる
目的を満足しているかどうかわからない
ユーザインタフェースの設計に走る
実装を書いてしまう（ボタンを押す）
内部処理を書いてしまう（○○ファイルに書く）
17

Download Report