オブジェクト指向モデリング [13] 2004年1月20日.

Presentation on theme: "オブジェクト指向モデリング [13] 2004年1月20日."— Presentation transcript:

1 オブジェクト指向モデリング [13] 2004年1月20日

2 13.3 勘定（1） 移動の記録 勘定（account） 多肢トランザクション 勘定科目 口座 勘定科目 仕訳記入 会計取引 1 *
13. 概念モデルの理解 13.3 勘定（1） 移動の記録 勘定（account） 勘定科目 口座 多肢トランザクション 実施日 04/1/12 計上日 勘定科目 売掛金 金額 30,000円 売上げ 商品販売 預かり消費税 1,500円 消費税 借方 貸方 摘要 勘定科目 仕訳記入 会計取引 /残高 : 量 数量 : 量 実施日:時点 計上日:時点 1 * 2..* 1 　　　　　《business rule》 inv: 　self.the仕訳記入.数量->sum = 0

3 14.2 Composite（1） 構造に関するパターン 木構造の一般形 Component * Composite Leaf C B D
14. 実装モデルの理解 14.2 Composite（1） Compositeの集合 子 子 構造に関するパターン 木構造の一般形 子 C B D A E 子 F {階層} G 子 * 子 子 Component Leafの集合 {abstract} Component children operation() add(Component) remove(Component) getChild() * Composite Leaf operation() add(Component) remove(Component) getChild() children.operation() operation()

4 14.3 State（1） 振る舞いに関するパターン 内部状態が変化したときに，その振る舞いを変える 状態に依存した振る舞いを局所化
14. 実装モデルの理解 14.3 State（1） 振る舞いに関するパターン 内部状態が変化したときに，その振る舞いを変える 動的分類の実装方法の一つ 状態に依存した振る舞いを局所化 状態ごとの振る舞いを用意 ConcreteStateはsingleton Context {abstract} State state.Handle() * Request() state Handle() state ConcreteStateB Handle() ConcreteStateA

5 14.4 Observer（1） 振る舞いに関するパターン ある観測対象に複数の観測者 観測対象の変化をできるだけ早く知るには
14. 実装モデルの理解 14.4 Observer（1） 振る舞いに関するパターン ある観測対象に複数の観測者 観測対象の変化をできるだけ早く知るには ポーリングではコンピュータリソースを消費しすぎる 変化があったことだけを通知（notify）する（callback） 通知を受けた観測者が変化情報を取りに行く {abstract} Subject Notify() Attach(Observer) Detach(observer) Observer update() * observer subject ConcreteObserver observerState ConcreteSubject SetState() GetState() subjectState observerState= subject.GetState() observer. update() return subjectState フレームワーク側

6 シラバス 授業計画 回 月日 内容 1 9月 30日 オリエンテーション：モデルとは何か。 2 10月 7日 モデリング言語：UMLの概要
オブジェクト指向モデリング シラバス 授業計画 回 月日 内容 1 9月 30日 オリエンテーション：モデルとは何か。 2 10月 7日 モデリング言語：UMLの概要 3 10月14日 静的モデル1：概念とクラス 4 10月21日 静的モデル2：関連 5 10月28日 静的モデル3：オブジェクト図 6 11月 4日 静的モデル3：オブジェクト図（続き），モデリング 7 11月11日 機能モデル1：ユースケース，シナリオ 8 11月18日 機能モデル2：要求抽出，協調図，シーケンス図，状態モデル：状態図 9 12月 2日 機能モデル2：活動図，静的モデル4：ユースケースに基づくモデリング 10 12月 9日 静的モデル4：モデルの揺さぶり 11 12月16日 実装レベル：実装モデルとプログラム，概念モデルの理解：アナリシスパターン 12 1月13日 概念モデルの理解：アナリシスパターン，実装モデルの理解：デザインパターン 13 1月20日 モデリング：例題によるモデル図の作成

7 オブジェクト指向モデリング 15.モデリング 15.1 モデルの良さの基準 15.2 自動改札システム 15.3 酒屋の在庫問題

8 15.1 モデルの良さの基準 ユースケース 型モデル（概念レベル） 妥当なユースケース 世界（UoD）が記述できている
15. モデリング 15.1 モデルの良さの基準 ユースケース 妥当なユースケース 目的充足性（効果的） 型モデル（概念レベル） 世界（UoD）が記述できている 適度な抽象性 一般性 単純性（良い概念，良い構造） 耐変更性 再利用性 ユースケースが実現できている 理解の共有

9 15.2 自動改札システム（1） 演習12 自動改札システムの型モデル（概念レベル）を書いてください。 ①概念の整理 ②初期モデル
15. モデリング 15.2 自動改札システム（1） 演習12 自動改札システムの型モデル（概念レベル）を書いてください。 ①概念の整理 ②初期モデル ③基本的なユースケースによる検証 ④初期モデルの改訂

10 15.2 自動改札システム（2） モデリングプロセス 基本定義→基本課題→解決策 ユースケースを考える→ユースケース記述
15. モデリング 15.2 自動改札システム（2） モデリングプロセス 基本定義→基本課題→解決策 ユースケースを考える→ユースケース記述 仮説（初期モデル）→検討→モデルの改訂 さらに揺さぶり→より本質的なモデル 最小セットで実装

11 15.2 自動改札システム（3） 自動改札システムのユースケースを考えて ユースケース図 ユースケース記述 システム境界 アクタは誰？
15. モデリング 15.2 自動改札システム（3） 自動改札システムのユースケースを考えて ユースケース図 ユースケース記述 システム境界 アクタは誰？ 駅員 （事業者の代理） 切符を回収する 利用者 入場する 出場する 切符を購入する 自動改札システム 料金を設定する 車掌 社内検札する

12 15.2 自動改札システム（4） ユースケース記述 ユースケース名：入場する。 アクター：利用者（乗客）
15. モデリング 15.2 自動改札システム（4） ユースケース記述 ユースケース名：入場する。 アクター：利用者（乗客） 目的：乗客は入場して電車に乗りたい。事業者は妥当な乗客のみを入場させたい。 事前条件：その乗客は入場していない。 基本系列： 　①アクターは，自分が妥当な乗客である証明をシステムに提示する。 　②システムはその証明を確認し，妥当であればアクターだけ入場を許す。 　③アクターは入場する。 　④システムは，アクターが入場したことを記録する。 事後条件：その乗客が入場している。 代替系列：基本系列②で，証明が妥当でなければ警告する。 備考：・システムは乗客を停滞させないこと。 　　　　・入場管理にはゲートを使う。 　　　　・入場したかどうかを切符などの証明に記録する。 　　　　・証明には，切符，プリペイドカード，回数券，定期券などのタイプがある。

13 15.2 自動改札システム（5） ユースケース記述 ユースケース名：出場する。 アクター：利用者（乗客）
15. モデリング 15.2 自動改札システム（5） ユースケース記述 ユースケース名：出場する。 アクター：利用者（乗客） 目的：乗客は目的地で出場したい。事業者は料金不足の乗客の出場を阻止したい。 事前条件：その乗客は出場していない。 基本系列： 　①アクターは，自分が入場を記録した証明をシステムに提示する。 　②システムはその証明を確認し，料金が足りていれば出場を許す。 　③アクターは出場する。 　④システムは，証明を回収する。 事後条件：その乗客が出場している。 代替系列：基本系列②で，料金が不足であれば警告して出場を阻止する。 備考：・システムは乗客を停滞させないこと。 　　　　・出場管理にはゲートを使う。 　　　　・証明がプリペイドカードの場合は，回収する代わりに，代金を決済する。

14 15.2 自動改札システム（6） 初期モデル * 1 駅 15. モデリング 証明 切符 プリペイドカード 定期券 回数券 運賃
入場駅 出場駅 1 * 証明 入場日時 出場日時 /営業キロ数 /運賃 切符 プリペイドカード 定期券 回数券 運賃 営業キロ数 駅 名称 基準距離 get運賃() 営業キロ数は入場駅と出場駅の基準距離の差 購入料金 残高

15 15.2 自動改札システム（7） シーケンス図による検討 アクタ 乗客か自動改札機か 現物とオブジェクトは別 自動改札機 切符
15. モデリング 15.2 自動改札システム（7） ドメイン U/I アクタ シーケンス図による検討 アクタ 乗客か自動改札機か 現物とオブジェクトは別 自動改札機 切符 ：切符 ：駅 ：利用者 入場する（東京駅） find駅（東京駅） ：切符 ：駅 ：運賃 東京駅：駅 渋谷駅 ：駅 ：利用者 出場する（渋谷駅） find駅（渋谷駅） get運賃（東京駅，渋谷駅） get基準距離（） get基準距離（） 運賃と購入金額を比較する

16 15.2 自動改札システム（8） オブジェクト図による検討 15. モデリング 東京駅で，190円の切符を買って入場する 渋谷駅で出場する
：運賃 ：運賃 運賃= 運賃=190 東京：駅 東京：駅 名称＝東京 基準距離＝0 名称＝東京 基準距離＝0 入場駅 ：切符 入場駅 ：切符 入場日時= 出場日時= 購入金額=190 /営業キロ数= /運賃= 入場日時= 出場日時= … 購入金額=190 /営業キロ数=14 /運賃=190 渋谷：駅 渋谷：駅 出場駅 名称＝渋谷 基準距離＝14 名称＝渋谷 基準距離＝14 東京駅で，190円の切符を買って入場する 渋谷駅で出場する

17 15.2 自動改札システム（9） モデルの改訂 「指定席」，「特急」の扱いを検討 15. モデリング 駅 証明 有効期限 * /運賃 * *
営業キロ数 輸送料金 * get運賃() から まで * 《多重》 指定席 1 駅 * 証明 路線 {ordered} 名称 基準キロ数 入場日時 出場日時 料金 /運賃 入場 * グリーン * 出場 * get基準キロ数() 入場する() 出場する() 区間 から 区間 まで 普通 急行 特急 * 定期券 切符 プリペイドカード * 購入料金 /残高 * 1 乗客 回数券 有効期限はない

18 15.2 自動改札システム（10） モデルの改訂 「証明」の意味を検討 状態遷移するオブジェクト 行使前 行使中 行使済 15. モデリング
入場 出場 行使前 行使中 行使済 キャンセル

19 15.2 自動改札システム（11） モデルの改訂 「証明」や「切符」は「乗車権」のビュー 15. モデリング 乗車権 駅 プリペイドカード
/残高 《多重》 行使前 行使中 行使済 入場 出場 * 便 0..1 乗車権 入場日時 出場日時 料金 /運賃 入場する() 出場する() 《動的》 1 子供 学割 回数券 割引 着席権 駅 名称 基準キロ数 get基準キロ数() 定期券 切符 購入料金 特急 急行 普通 グリーン 指定席 営業キロ数 輸送料金 get運賃() /時刻表 日付 乗車便の日付は有効期間中であること 区間 から 区間 まで 有効期限 有効期限はない 乗客 {ordered} から まで 路線 乗車便 事業者 モデルの改訂 「証明」や「切符」は「乗車権」のビュー

20 15.3 酒屋の在庫問題（1） 演習13 別紙の課題（酒屋の在庫問題）を読んで，型モデル（概念レベル）を作ってください。
15. モデリング 15.3 酒屋の在庫問題（1） 演習13 別紙の課題（酒屋の在庫問題）を読んで，型モデル（概念レベル）を作ってください。 ①基本課題を想定する ②基本的なユースケースを記述する（1件以上） ③概念の整理 ④初期モデル ⑤基本的なユースケースによる検証 ⑥初期モデルの改訂 ⑦要求のエスカレーション ⑧モデルの改訂

21 当日，翌日納入の場合は欠品する可能性がある
15. モデリング 15.3 酒屋の在庫問題（2） 0日 +1日 +2日 受注 入庫 出荷 仕入注文 当日，翌日納入の場合は欠品する可能性がある 課題 　　 　酒類卸売り業のA社の倉庫には，仕入注文に応じて，メーカから毎日数個のコンテナが搬入されてくる。その内容はビン詰めの酒で，１つのコンテナには10銘柄まで混載できる。扱い銘柄は約200種類ある。 　　　　倉庫係は，商品（酒）をコンテナから取り出して倉庫に保管し，それを記録した入庫表を受付係へ手渡す。また受付係からの出荷指示によって倉庫から商品を出荷することになっている。 　　　　さて，受付係は毎日，納入希望日の前日までに，電話で小売店からの注文を受ける。受付係は，その都度注文票に記入し，そのコピーを出荷指示として倉庫係に渡す。注文の納入希望日の当日朝時点で当該商品の在庫数量が不足する場合には，不足分について在庫不足リストに記入し，当日の夕方に，入庫希望日別，商品別に集計して，メーカに仕入注文を出す。翌日入庫希望分は，翌日の夕方に入庫される。 　　　A社の，仕入，受注，出荷をサポートする情報システムの概念モデ ルを作成せよ。

22 15.3 酒屋の在庫問題（3） 業務の流れ 卸売商 酒メーカ 小売店 A社 C社 B社 倉庫 15. モデリング コンテナ 受注票 受注係
仕入発注書 受注票 出荷指示書 在庫不足 リスト 卸売商 B社 酒メーカ A社 C社 小売店 受注係 倉庫係 倉庫 ［顧客］注文 仕入注文 納品書 輸送係 受領書

23 15.3 酒屋の在庫問題（4） 基本定義 「商品の仕入と販売を的確に行うことを支援するシステム」 CATWOE分析 的確さを決める世界観
15. モデリング 15.3 酒屋の在庫問題（4） 基本定義 「商品の仕入と販売を的確に行うことを支援するシステム」 CATWOE分析 Customer：小売店 Actor：受付係，倉庫係 Transformation：商品を仕入れて販売する Weltanschauung：的確に…？ Owner：A社 Environment：酒類市場 的確さを決める世界観 在庫負担を最小にする（保有量を最小に，かつ滞留期間を最短に） 　　or 受注から出荷までの日数（リードタイム）を最短に 機会損失を最小にする（欠品しない；安全在庫は保有する） 課題記述には直接現れない概念 メーカ依存

24 15.3 酒屋の在庫問題（5） 基本定義の再設定 「安全在庫を確保しつつ，販売状況に合わせて商品を仕入れることを支援するシステム」
15. モデリング 15.3 酒屋の在庫問題（5） 基本定義の再設定 「安全在庫を確保しつつ，販売状況に合わせて商品を仕入れることを支援するシステム」 CATWOE分析 Customer：小売店 Actor：受付係，倉庫係 Transformation：商品を仕入れて販売する Weltanschauung：在庫負担を最小化するが，欠品は避ける Owner：A社 Environment：酒類市場 安全在庫 飛び込み注文対応分 翌日夕方入庫までのつなぎ 注文のキャンセルや変更もある 時間 在庫量 期首 実績 予定 現在 安全在庫

25 15.3 酒屋の在庫問題（6） ワークフローの整理 新業務フロー 出荷 受注 仕入発注 入庫 15. モデリング
は，ユースケースに対応する活動 受付係 受注 商品を倉庫に保管する 倉庫係 入庫 出荷 仕入発注する 仕入発注 出荷する 当日分だけを選択 注文 《view》 （仕入）納品書 発注書 出荷指示書 出荷を指示する 翌々日入庫予定分だけ 商品在庫から数量を差し引く 在庫不足状態を見る 商品 注文を受ける 納品書 受領書 入庫を記録する 納品書と突き合わせる ［突き合せ済み］ 商品在庫に 数量を加える ［出荷済み］ 日締め後のバッチ処理

26 15.3 酒屋の在庫問題（7） 演習14 別紙の課題（酒屋の在庫問題）を読んで，型モデル（概念レベル）を作ってください。
15. モデリング 15.3 酒屋の在庫問題（7） 演習14 別紙の課題（酒屋の在庫問題）を読んで，型モデル（概念レベル）を作ってください。 ①基本課題を想定する ②基本的なユースケースを記述する（1件以上） ③概念の整理 ④初期モデル ⑤基本的なユースケースによる検証 ⑥初期モデルの改訂 ⑦要求のエスカレーション ⑧モデルの改訂 解答例

27 15.3 酒屋の在庫問題（22） 仕様モデル，実装モデル 機能実現の具体的な方法 アーキテクチャの設計 ユーザインタフェース設計
15. モデリング 15.3 酒屋の在庫問題（22） 仕様モデル，実装モデル 機能実現の具体的な方法 設計判断 実装判断 アーキテクチャの設計 階層分け フレームワークの当てはめ ユーザインタフェース設計 オブジェクト永続化の方法 オブジェクト指向データベース リレーショナルデータベースへは複雑なマッピングが必要 インピーダンスのミスマッチ 関連の実装

28 16. まとめ 16.1 情報システム 16.2 基本定義と基本課題 16.3 モデリングの過程 16.4 よい情報システムの構築
オブジェクト指向モデリング 16. まとめ 16.1 情報システム 16.2 基本定義と基本課題 16.3 モデリングの過程 16.4 よい情報システムの構築

29 16.1 情報システム 情報システム工学 人間活動システム 効果的な情報システム システム論 ソフトな問題
16. まとめ 16.1 情報システム 情報システム工学 人間活動システム システム論 システム要素間の相互作用→創発 階層と通信 ソフトな問題 構造化できない問題 自分自身がシステムの一部分 効果的な情報システム 目的（ビジョン，ミッション，ゴール，目標値）の達成 アプローチ（戦略，戦術，作戦）の選択と合意形成 フィードバックと目的・アプローチの修正の繰り返し 目標値と現状との乖離＝動的テンション 敏感でいること 正解がない 対策がまた新たな問題の原因に Embrace Change !

30 16.2 基本定義と基本課題 変化し続ける人間活動システム 現実世界（real world）と認識世界 ソフトな問題構造の合意
16. まとめ 16.2 基本定義と基本課題 変化し続ける人間活動システム 現実世界（real world）と認識世界 ソフトな問題構造の合意 システムの基本定義 合意（Accommodation） CATWOE分析 Customer： Actor： Transformation： Weltanschauung： Owner： Environment： 基本定義のrefine 基本課題 解決策の発明

31 16.3 モデリングの過程 モデリングとは 理解と合意のプロセス ドメインと操作の分離 要求記述としてのユースケース 操作の実現
16. まとめ 16.3 モデリングの過程 モデリングとは 理解と合意のプロセス ドメインと操作の分離 ドメインの定義 Ownerによる世界の認識 Universe of Discourse（UoD） 発明 概念レベル 要求記述としてのユースケース 操作の実現 良いモデルの基準 適度な抽象性 一般性，単純性，耐変更性，再利用性 アプリケーション（機能） ドメイン（概念の世界） 永続化 ユーザインタフェース

32 16.4 よい情報システムの構築 情報システム工学とオブジェクト指向 概念モデルとの素直な対応 変更吸収の仕組み
16. まとめ 16.4 よい情報システムの構築 情報システム工学とオブジェクト指向 概念モデルとの素直な対応 概念の実装としてのクラス－インスタンス 概念階層 ソフトウェア工学からの「良い概念」の基準 結合度 凝集度 オブジェクトメタファー 通信と相互作用 変更吸収の仕組み 拡張のメカニズム 継承 フレームワークの発想 リファクタリングのプラクティス 変更に強いモデル

33 この講義の主題と目標 思考を支えるモデリング 良いモデル モデルの書き方 ビジネス要求の本質を理解し，当事者間で共有する活動
オブジェクト指向モデリング この講義の主題と目標 思考を支えるモデリング ビジネス要求の本質を理解し，当事者間で共有する活動 システム思考（対象をシステムとして見る） 情報システムは成長（変化）するものだという考え方 学ぶこと 良いモデル ビジネス構造やビジネスルールを的確に記述 変更に耐えられる問題領域の概念構造を追求する モデルの書き方 要求記述，対象領域の概念構造の記述，業務フローの記述，オブジェクトどうしの対話の記述