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

47070
オブジェクト指向モデリング
[11]
2003年 1月 7日
オブジェクト指向モデリング
第10回静的モデル3
10.1 制約
10.2 関連型
10.3 型についての補足
10.4 依存性
10.5 パッケージ
10.6 知識レベル
2
静的モデル3
10.1 制約
79～81ページ
 型（クラス）図も制約がなければただの線図
 曖昧さの排除
 制約に従ったクラス群がモデル
 形式的なルールの記述
 ｛制約｝
 ノート
貸出
0..*
0..*
 制約記述言語
1
｛xor｝
1
雑誌
1
本
 UML組み込み
 OCL
 多重度も制約の一種
路線
｛ordered｝
*
駅
貸出
0..*
制約：
雑誌は教員の会
員だけが借りられる
本
雑誌
3
静的モデル3
82ページ
10.2 関連型
 関連に属性，操作を持たせる
 「もの－こと－もの」パターン
 2種類の記述方法
 導出関連
学生
履修している
1..*
6..*
氏名
授業科目
科目名
成績
/履修している
1..*
6..*
学生
氏名
履修
6..*
1..1
成績
授業科目
1..*
1..1 科目名
制約：
再履修は不可
4
オブジェクト指向モデリング
第11回ソフトウェアパターン
11.1 パターンランゲージ
すべて
教科書外
11.2 パターンの意味
11.3 パターンの形式
11.4 ソフトウェアパターンの歴史
11.5 PLoPの活動
11.6 刊行されたパターンたち
11.7 アナリシスパターン
11.8 デザインパターン
5
11.1 パターンランゲージ
 Christopher Alexander(1936～）
 パターン3部作（5部作）
“The Oregon Experiment,” Oxford Univ. Press, 1975, 宮本雅明（訳），「オレ
ゴン大学の実験」，鹿島出版会，1977
“A Pattern Language,” Oxford Univ. Press, 1977, 平田翰那（訳），「パタン・ラ
ンゲージ」，鹿島出版会，1984
“The Timeless Way of Building," Oxford Univ. Press, 1979, 平田翰那（訳），
「時を超えた建設の道」，鹿島出版会，1993
 よい建築がもつ性質
 無名の質（Quality Without A Name）
 生き生きと生きること（alive）
 パターンの重層
6
11.1 パターンランゲージ
 たゆまざる方法(timeless way)
The Oregon Experiment
 有機的秩序の原理
全体を徐々に生み出して行く
 参加の原理（grassroots housing process）
 漸進的成長（piecemeal growth）
建築物は，修正，復元，拡張，改善によって成長すべき
小規模開発を繰り返す
 パターンの原理
漸進的プロセスにあって，設計を指導して行く概念
コミュニティにおける共通の合意事項
長期にわたって基本設計を
採択のプロセス
書くことはできない。パターン
学習過程
ランゲージを基本設計書の
代わりにする
7
11.1 パターンランゲージ
 「パタン・ランゲージ」
 建築のための253のパターン
 パタンで建てられた建築は［長い時間の中で］無名の質を織りなす
 シーケンス（工事手順の手引き）
大きいパタン（町）から小さいパタン（建物，施工）へ
骨組みのパタンから肉づけのパタンへ
 パタン間の脈絡は「詩」を構成する
81 小さな広場
68 つながった遊び場
125 座れる階段
126 ほぼ中央の焦点
 パターンどうしは圧縮して適用される
 印刷されたパタン・ランゲージに依存してはならない
 自分自身のパタン･ランゲージを自覚し，改良していく
 「パタン・ランゲージ」の使い方
 プロジェクトごとに，元になるパタンランゲージから有効なものを
（順序を崩さないように）抜き出して，プロジェクト用のパタンラン
ゲージを作る。
8
11.2 パターンの意味
 パターンは有効なのか
 建築の世界がソフトウェアに当てはまるのか
 無名の質，piecemeal growth,...
 パターンは必ずしも成功していない？
 Modesto，Mexicali
 Oregon
59 静かな奥
105 南向きの屋外
111 見え隠れの庭
112 入口での転換
161 日のあたる場所
171 木のある場所
9
11.2 パターンの意味
 パターンの定義
 おおかたの定義
 ノウハウの記述，経験則
 文脈を超えて有効な解決策
 繰り返し起こる問題と解決策
一般化
抽象化
3のルール
 われわれの捉え方
 漸進的成長のための設計原理
 10年後のシステムを設計できないとすれば...
 設計原理を継承して行くプロセス
 合意，公式化，共有，使用
 追加，修正，削除／発展・改良
10
11.3 パターンの形式
 Alexander
名前
<写真>
・・・概要（目的，他のパタンとの関係）
問題，背景
「したがって，…すること。」
［説明図，写真］
「（他のパタンとの関係）すること ‥‥」
154 十代の離れ（Teenage Cottage）
<写真>
．．．十代の子供がいる家では，必ず子供部屋に特
別の注意を払う必要がある。できれば，この部屋は
壁続きであっても独立性があり，後で述べる貸せる
部屋（153）に転用できるように作るべきである。
★
家庭内の十代の子供のための場所は，独立への
要求を反映しないと，子供は家族との対立で身動き
がとれなくなる。
大抵の家庭では，こともの部屋と青年の部屋は本
質的に同じものである。だが，子供が青年になる
と，．．．
したがって，
子供が十代になったことを明示するために，子供
の場所は，自立の始まりを物理的に表現する一種
の離れに変えること。離れはおも屋と壁続きにする
が，一目で見分けられるように突き出し，．．．
★
離れにはくるま座（185）とベッド・アルコーブ（188）
を備えても，専用の浴室や台所は設けないこと。．．．
11
11.3 パターンの形式
COMPOSITE
 GoF
名前と分類
目的
別名
動機
適用可能性
構造（クラス図）
構成要素
協調関係
結果
実装
サンプルコード
使用例
関連するパターン
オブジェクト，構造
◎目的
部分－全体階層を表現するために，オブジェクトを木構造に組
み立てる。．．．
◎動機
．．．ユーザは構成要素を組み合わせて大きな構成要素を作り
出すことができ，．．．
<例のクラス図>
Component *
Client
◎適用可能性
children
次のような場合に，Compositeパターンを使用する。
◎構造
<クラス図>
◎構成要素
・Componentクラス
Leaf
Composite
：
◎協調関係
・クライアントは，Componentクラスのインタフェースを使っ
て，．．．
◎結果
Compositeパターンを用いると，次のような結果が得られる。
◎実装
Compositeパターンを実装する際には，以下に挙げる点を考慮
しなければならない。
：
12
11.3 パターンの形式
 POSA（Pattern-Oriented Software Architecture）
名前［別名］
概要
例
前提
課題
解決策
静的側面
動的側面
実装
バリエーション
適用例
結論
参考
謝辞
Model-View-Controller
MVCアーキテクチャパターンは，対話型アプリケーションを3つ
のコンポーネントに分割する。モデルコンポーネントは，．．．
例得票率で決まる政治選挙についての簡単な情報システムを
考えてみる。このシステムは，データ入力のためのスプレッド．．．
<図>
前提人とコンピュータのインタフェースに柔軟性を持たせた対
話型アプリケーションの機能を拡張しようとすると．．．
課題ユーザインタフェースは要求変更の影響を被ることが多い，
例えば，アプリケーションの機能を拡張しようとすると．．．
解決策 MVCパターンが最初に導入されたのは，smalltalk-80プ
ログラミング環境である。このパターンは，．．．
静的側面モデルコンポーネントは，アプリケーションの機能中核
となる部分を含んでいる。．．．更新伝播メカニズムは，．．．
<CRC図>
<クラス図>
動的側面以下のシナリオは，MVCの動的な振る舞いを描いた
ものである。．．．
<シーケンス図>
実装
13
11.3 パターンの形式
 “Analysis Patterns” （Fowler）
その章の概要
テーマ
型図
例
［モデリングの原則］
 “Refactoring” （Fowler）
名前
問題－解決
動機
手順
例（コード）
14
11.3 パターンの形式
 記述形式になぜこだわるか
 形式化しにくい知識を伝えたい
 盲目的に従うルールではない
 プランではなく，レシピ
 隠された構造の取り出し
 分析ではなく合成
 Forceを感じること
 トレードオフの調停
 判断の助け
 形式を持っていればパターン
c.f. 絵本の読み聞かせのパターンランゲージ
（http://www.hyuki.com/writing/ehonpat.html）
子供におかたづけを促すパターンランゲージ
（児玉，矢崎：オブジェクト指向シンポジウム2000論文集）
15
11.4 ソフトウエアパターンの歴史
 ソフトウエアパターンの歴史
 OOPSLA’87
 Beck & Cunningham
Using Pattern Languages for Object-Oriented Programs
Window Per Task, Few Panes, Standard Pane, Nouns and Verbs, Short Menus
（BeckはOregon Univ.卒）
 ECOOP/OOPSLA’90
 Gamma and Helm
 BOF（Birds-of-a-Feather; 同じ羽の鳥は集まる）session
 ECOOP’91
 GoFのパターンの原形
 OOPSLA’91～93
 Patternに関するワークショップ
16
11.4 ソフトウエアパターンの歴史
 PLoPの活動
 OOPSLA’91,’92のワークショップの参加者
 Hillside Group
 1993年8月：Beck, Booch, Cunningham, Johnson, Coplien,…
 1994年4月：+Gabriel
 PLoP：パターンライティングの奨励
 1994年8月：1st PLoP Conference @Allerton Park, Illinois Univ.
：
：




EuroPLoP(1996～)
ChilliPLoP(1998～）
KoalaPLoP（2000～）
MensolePLoP（2001～）
17
11.5 PLoPの活動
 PLoPの方法
 Writer’s Workshop
 パターンの投稿
 shepherding
 コンファレンス
 ゲーム
 パターンの推敲
詩の吟味
 Writing Workshop
 パターンライティング
 PLoPD
 完成したパターンの刊行
18
11.5 PLoPの活動
 パターンの吟味
a. 著者がパターンの「肝」を朗読．以降，口を差し挟めない
b. 推敲者がそれぞれの視点でそのパターンを要約する
c. 「良いところ」を述べる
d. 「直すべきところ」を述べる
e. 著者による上記に関する質問と補足
f. 拍手して終了
 吟味のパターンランゲージ
19
ソフトウェアパターン
11.6 刊行されたパターンたち
 Design Patterns （1995）
 GoF（Gang of Four）
Gamma, Helm, Johnson, and Vlissides
 よいクラス設計のためのレシピ集
 Pattern-Oriented Software Architecture（1996）
 Siemens Group
Buschmann, Meunier, Rohnert, Sommerlad, and Stal
 アーキテクチャ設計のためのレシピ集
 Analysis Patterns（1997）
 Martin Fowler
 よい分析のためのレシピ集
 サポートパターン（分析から設計への橋渡し）
 PLoPD（Pattern Language of Programming and Design）
 Anti Patterns
20
ソフトウェアパターン
11.7 アナリシスパターン
 アナリシスパターン
責任関係（Accountability）
観測と測定
企業財務の観測
オブジェクトへの参照
在庫管理と会計（Account）
会計モデルの利用
計画
トレーディング
デリバティブ
トレーディングパッケージ
 サポートパターン
情報システムの層別化アーキテクチャ
アプリケーションファサード
型モデル設計テンプレートのためのパターン
関連パターン
21
ソフトウェアパターン
11.7 アナリシスパターン
 責任関係（Accountability）
 明示的なレベルを持った組織
事業部
1
*
地域
1
部門
*
1
営業所
* 売上
 変更に弱い
 操作（メソッド）の重複，類似の属性
 オブジェクト（インスタンス）図
コーヒー：事
業部
首都圏：
地域
神奈川：
部門
藤沢：営
業所
東京：部
門
川崎：営
業所
22
ソフトウェアパターン
11.7 アナリシスパターン
このオブジェクト
図はどうなる？
 責任関係（Accountability）
 階層関係を持つ組織
 類似の操作，属性はスーパタイプに持つ
｛階層｝
親
組織
制約：
親は持たない
事業部
0..1
子
制約：
親は部門
*
地域
制約：
親は事業部
部門
営業所
制約：
親は地域
 制約の変更が煩わしい
 マトリックス組織にはどう対応する？
23
コーヒー：事親
業部
子首都圏：
地域
親
子神奈川：
部門
東京：部
門
親
子藤沢：営
業所
川崎：営
業所
24
ソフトウェアパターン
11.7 アナリシスパターン
このオブジェクト
図はどうなる？
 責任関係（Accountability）
 2系統の階層
｛階層｝
｛階層｝
*
子営業
*
組織
親営業
*
*
事業部
制約:
地域
制約:
親サービス
子サービス
部門
制約:
営業所サービス地域サービス部門サービスセンタサービスチーム
制約:
制約：
親営業は部門
制約:
制約:
制約：
親サービスは
サービスセンタ，
親営業は営業所
 制約変更の煩わしさが2倍に
25
コーヒー：事
業部
首都圏：地
域
東京：部門
首都圏：サー
ビス地域
神奈川：部
門
川崎：営業
所
藤沢：営業
所
神奈川：サー
ビス部門
横浜：サービ
スセンタ
親営業
東京：サービ
ス部門
藤沢：サービ
スセンタ
親サービス
子サービス
子営業
川崎：サービ
スチーム
藤沢：サービ
スチーム
26
ソフトウェアパターン
11.7 アナリシスパターン
このオブジェクト
図はどうなる？
 責任関係（Accountability）
 関連型の使用
インスタンス：
営業組織
サービス組織
組織構造型
制約：
営業所の親は部
門….
サービスチームの
親は営業所および
サービスセンタ….
型1
*
組織構造
*
親
1
*
組織
子
1
*
1 有効期間
期間
事業部
地域
部門
営業所
サービス
チーム
 「組織構造」の制約は，組織構造の変化に敏感
27
神奈川：
部門
神奈川：サ
ービス部門
親
営業組織：
組織構造型
：組織構
造
：組織構
造
：組織構
造
：組織構
造
子
川崎：営
業所
藤沢：営
業所
横浜：サー
ビスセンタ
藤沢：サー
ビスセンタ
：組織構
造
：組織構
造
：組織構
造
サービス組織
：組織構造型
親
：組織構
造
：期間
2001/10/1 _
2002/1/22
子
川崎：サー
ビスチーム
藤沢：サー
ビスチーム
28
ソフトウェアパターン
11.7 アナリシスパターン
このオブジェクト
図はどうなる？
 責任関係（Accountability）
 「組織構造型」と「ルール」
組織構造型 *
1
ルール
型1
*
組織構造
*
親
1
*
組織
子
1
*
1 有効期間
期間
事業部
地域
部門
営業所
サービス
チーム
 組織構造型ごとのルール
 組織の変化に弱い
29
サービスチームの親は営
業所およびサービスセンタ
，サービスセンタの親は，
….
営業所の親は部門，部門
の親は地域，...
神奈川：部
門
営業組織型：
ルール
神奈川：サー
ビス部門
営業組織型：
ルール
親
：組織構造
：組織構造
：組織構造
藤沢：営業
所
横浜：サービ
スセンタ
藤沢：サービ
スセンタ
：組織構造
：組織構造
：組織構造
：組織構造
子
営業組織：組
織構造型
川崎：営業
所
サービス組織：
組織構造型
親
：組織構造
子
：期間
2001/10/1 _
2002/1/22
川崎：サービ
スチーム
藤沢：サービ
スチーム
30
ソフトウェアパターン
11.7 アナリシスパターン
打診
 責任関係（Accountability）
契約
 組織階層を「責任関係」として一般化
Customer
Performer
Customer
責任関係型
Performer
実行
報告
型 1
*
*
責任関係
依頼者
1
*
*
実行者
パーティ
1
1 有効期限
期間
人
組織
 依頼者→実行者
 Customer-Performerの関係
31
ソフトウェアパターン
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 有効期限
期間
人
組織
32
 シナリオ
 同意：責任関係
患者:鈴木一郎は医師:山本太郎との間で，2001年12月18日に内視鏡検
査を受けることについて同意した
同意：責任
関係型
型
依頼者患者
：パーティ型
医師
実行者：パーティ型
型
型
内視鏡検
査：作業
：責任関
係
：期間
2001/12/18
依頼者鈴木一郎
：パーティ
実行者山本太郎
：パーティ
33
ソフトウェアパターン
11.7 アナリシスパターン
このオブジェクト
図はどうなる？
 勘定（Account）
 移動の記録
 勘定
 多肢トランザクション
勘定
/残高 : 量
エントリ
1
*
数量 : 量
2..*
1
トランザクション
実施日:日
<<business rule>>
inv:
self.theエントリ.数量->sum = 0
34
 シナリオ
航空券の購入：多肢トランザクション
2001年5月1日，航空券を買うためにA航空に45,000円をクレジットカー
ドで払った。2001年5月31日，当座預金からクレジット勘定へ，それを埋
合わせるトランザクションを作成した
：エントリ
クレジット：勘定
－45000円
：エントリ
：トランザクション
2001年5月1日
＋45000円
A航空：勘定
：エントリ
－45000円
当座預金：勘定
：エントリ
：トランザクション
2001年5月31日
＋45000円
35
ソフトウェアパターン
11.7 アナリシスパターン
このオブジェクト
図はどうなる？
 勘定（Account）
 要約（Summary）
 ロールアップ
｛抽象｝
構成要素
勘定
* /残高 : 量
｛階層}
/対象エントリ
*
0..1
要約勘定
対象エントリ
明細勘定
1
*
エントリ
数量 : 量
トランザクション
2..*
1
inv:
/対象エントリ＝self.対象エントリ
inv:
/対象エントリ＝self.構成要素./対象エントリ
36
旅費交通費：要約勘定
構成要素
航空旅費：要約勘定
構成要素
A航空：明細勘定
/対象エントリ
B航空：明細勘定
クレジット：明細勘定
/対象エントリ
対象エントリ
：エントリ
：エントリ
：エントリ
＋45000円
＋66000円
＋128000円
：トランザクション
2001年5月1日
：トランザクション
2001年1月31日
：トランザクション
2001年11月21日
：エントリ
－45000円
37
ソフトウェアパターン
11.8 デザインパターン
 生成に関するパターン
Abstract Factory Builder
Factory Method Prototype
Singleton
 構造に関するパターン
Adapter
Composite
Façade
Proxy
Bridge
Decorator
Flyweight
 振る舞いに関するパターン
Cain of Responsibility
Command
Interpreter
Iterator
mediator
Memento
Observer
State
Strategy
Template Method
Visitor
38
ソフトウェアパターン
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()
39
ソフトウェアパターン
11.8 デザインパターン
 Observer
 Observerの登録（Attach()）
 値が変化したことの通知（Notify()->update()）
 Observerはそれぞれ値を取りに行く
 SubjectはModelで，ObserverはViewに相当
:ConcreteSubject
a:ConcreteObserver
b:ConcreteObserver
1:SetState()
1.1:Notify()
1.1.1:update()
1.1.1.1:GetState()
1.1.2:update()
1.1.2.1:GetState()
40
ソフトウェアパターン
11.8 デザインパターン
 State
 内部状態が変化したときに，その振る舞いを変える
 状態に依存した振る舞いを局所化
 状態ごとの振る舞いを用意
 ConcreteStateはsingleton
state.Handle()
Context
Request()
state
{abstract}
*
State
state Handle()
ConcreteStateA ConcreteStateB
Handle()
Handle()
41
ソフトウェアパターン
11.8 デザインパターン
従業員
Request()
{abstract}
従業員型
*
state 給与計算()
state
 State
 Stateパターンを使わない場合との比較
public class 従業員｛
private 従業員型 _state;
private Money _salary;
public void setState(従業員型 s) {
_state = s;
}
給与計算()
給与計算()
public class 従業員｛
private Money _salary;
private char _state;
public void setState(char s) {
_state = s;
}
public void Request( ) {
_salary = _state.給与計算( );
}
public void Request( ) {
if(_state == ‘1’)
_salary = 基本給 + 成績給( );
else if(_state == ‘2’)
_salary = 基本給 + 資格給( );
else ...;
}
}
public class 従業員型｛．．．｝
public class 営業職型 extends 従業員型 {
public Money 給与計算( ) {
return 基本給 + 成績給( );
}
private Money 成績給( ) {...}
private Money 資格給( ) {...}
private Money 成績給( ) {...}
}
技術職型
営業職型
}
42
質問カードから
 設計の際にデザインパターンをどう考慮するか
 使えるときには使う
 使えるかどうかの判断はForce
43

Download Report