Transcript ppt形式
47070 オブジェクト指向モデリング [12] 2002年1月15日 オブジェクト指向モデリング 前回 モデリング1 11.1 自動改札システム 11.2 CS4 11.3 モデルの良さの基準 テキスト 第6章 2 モデリング１ CS4管理システム 基本定義 基本課題 ユースケースの作成 どのアクティビティを取り出すか コースハンドブックを作成する CS4学生リストを生成する 履修申請する システム境界を決める 機能の発明 概念モデルの作成 アクティビティの取り出し システム境界を決める 概念モデリング 機能の発明 3 オブジェクト指向モデリング 第12回 モデリング2 12.1 酒在庫問題 12.2 まとめ 教科書外 4 モデリング２ 12.1 酒在庫問題 課題 当日，翌日納入の場 合は欠品する可能性 がある 仕入注文 0日 受注 入庫 +1日 +2日 出荷 酒類卸売り業のA社の倉庫には，仕入注文に応じて，メーカから毎日 数個のコンテナが搬入されてくる。その内容はビン詰めの酒で，１つの コンテナには10銘柄まで混載できる。扱い銘柄は約200種類ある。倉 庫係は，商品（酒）をコンテナから取り出して倉庫に保管し，それを記 録した入庫表を受付係へ手渡す。また受付係からの出荷指示によって 倉庫から商品を出荷することになっている。 さて，受付係は毎日，納入希望日の前日までに，電話で小売店からの 注文を受ける。受付係は，その都度注文票に記入し，そのコピーを出 荷指示として倉庫係に渡す。注文の納入希望日の当日朝時点で当該 商品の在庫数量が不足する場合には，不足分について在庫不足リス トに記入し，当日の夕方に，入庫希望日別，商品別に集計して，メーカ に仕入注文を出す。翌日入庫希望分は，翌日の夕方に入庫される。 A社の，仕入，受注，出荷をサポートする情報システムの概念モデル を作成せよ。 5 モデリング２ 12.1 酒在庫問題 基本定義 「商品の仕入と販売を的確に行うことを支援するシステム」 CATWOE分析 Customer：小売店 Agent：受付係，倉庫係 Transformation：商品を仕入れて販売する Weltanschauung：的確に…？ Owner：A社 Environment：酒類市場 的確さを決める世界観 課題記述には直接 現れない概念 在庫負担を最小にする（保有量を最小に，かつ滞留期間を最短に） or 受注から出荷までの日数（リードタイム）を最短に メーカ依存 or 機会損失を最小にする（欠品しない；安全在庫は保有する） 6 モデリング２ 12.1 酒在庫問題 基本定義の再設定 「安全在庫を確保しつつ，販売状況に合わせて商品を仕入れ ることを支援するシステム」 CATWOE分析 Customer：小売店 Agent：受付係，倉庫係 Transformation：商品を仕入れて販売する Weltanschauung：在庫負担を最小化するが，欠品は避ける Owner：A社 Environment：酒類市場 安全在庫 飛び込み注文対応分 在 庫 量 安全在庫 翌日夕方入庫までのつなぎ 注文のキャンセルや変更もある 期首 現在 実績 予定 時間 7 モデリング２ 12.1 酒在庫問題 ワークフローの整理 入庫 仕入注文 倉庫係 受付係 受付係 商品を倉庫に 保管する 在庫不足リストを 日別商品別に分類 注文を受ける 入庫票に記入 する 仕入注文を出す 受注 在庫を確認する 出荷 ［在庫数量不足］ 在庫不足リスト に記入する 受付係 倉庫係 出荷指示をする 出荷する 出荷を記録する 当日分だけを 選択 8 モデリング２ 12.1 酒在庫問題 ユースケース 仕入販売支援システム 受注する 入庫を記録する 在庫を引き当てる 受付係 倉庫係 出荷指示する 出荷を記録する 仕入注文をする 9 モデリング２ 12.1 酒在庫問題 ユースケース記述 ユースケース名：受注する。 アクタ：受付係 目的：小売店からの注文を記録して，出荷指示の準備をする。 事前条件：注文が記録されていない。 基本系列： ①アクタは，システムに注文を記録する旨を示す。 ②システムはアクタに注文の入力を促す。 ③アクタは注文内容（送り先名，｛商品名，数量，納入希望日｝，受注日）を入 力する。 ④システムは，注文内容が妥当であることを確認し，注文番号を発行して， それらを記録する。 事後条件：注文が記録されている。 代替系列：A 基本系列④で注文内容が妥当でなかった場合,... 備考：注文内容が妥当であるとは，... 注文番号は一連番号とし，ユニーク性を保証すること。 10 モデリング２ 12.1 酒在庫問題 ユースケース記述 計画ホライゾン 商品名 1/14 1/15 1/16 1/17 1/18 1/19 マッカラン 12 12 2 12 -8 2 12 -8 2 12 -8 2 12 -8 2 ユースケース名：在庫を引き当てる。 アクタ：受付係 注文： マッカラン 10本 1/15 目的：注文に対する在庫不足分を明らかにする。 マッカラン 10本 1/16 事前条件：未処理の注文がある。 基本系列： ①アクタは，システムに在庫の確認処理を要請する。 ②システムは，商品別，納入希望日順に在庫量から注文分を減じる。当日お よび翌日の在庫がマイナスになった場合はアクタに警告する。 ③システムは，処理した注文に対して「処理済み」をマークする。 事後条件：未処理の注文がない。 代替系列：なし 備考：在庫引き当ては，商品別，日別の予定在庫を減じることで表現する。 「仕入注文をする」ユースケースでは，安全在庫を加味して仕入数量を 決める）。 11 モデリング２ 12.1 酒在庫問題 概念モデリング 最初のモデル ちょっと待って。 在庫って何？ 期首在庫 在庫 時点 * * 注文 * 銘柄 * 仕入 * * 小売店 メーカ 0..1 * 出荷 * 0..1 商品 * 入庫 * * 12 モデリング２ 12.1 酒在庫問題 在庫とは 累 積 量 入庫 実在庫 仕入 滞留時間 期首在庫＋Σ入庫－Σ出荷 注文 ある時点での予定在庫 実在庫＋Σ仕入－Σ注文 入庫，出荷は実績 仕入，注文は 入庫予定，出荷予定 ユースケースは不変？ ②システムは，商品別，納入希望日順に 在庫量から注文分を減じる。当日および 翌日の在庫がマイナスになった場合はア クタに警告する。 在庫 出荷 期首 現在 実績 予定 在 庫 量 安全在庫 期首 現在 実績 予定 flow 時間 stock 時間 内部を書きすぎだった 13 モデリング２ 12.1 酒在庫問題 代替案 ものの動きに注目 最初の案はビジネスプロセスに注目していた 在庫導出 ルール 銘柄 入庫 * /在庫 1 時点 勘定 * エントリ トランザクション 出庫 * * <<多重>> 取引先 受け 払い 実績 予定 0..1 小売店 メーカ inv: inv: inv: inv: self.oclTypeOf(入庫） self.oclTypeOf(入庫） self.oclTypeOf(出庫） self.oclTypeOf(出庫） implies implies implies implies self.受け.勘定.取引先.oclTypeOｆ（メーカ） self.払い.勘定.取引先=null self.払い.勘定.取引先.oclTypeOｆ（小売店） self.受け.勘定.取引先=null 14 モデリング２ 12.1 酒在庫問題 さらに代替案 ビジネスプロセスとものの動きの両方をとらえる 一方を導出型とする e.g. 「仕入」のインスタンスを書くと同時に「入庫・予定のトランザクション」， 「エントリ」を書く /在庫 小売店 メーカ 予定 実績 1 時点 取引先 * 勘定 * /エントリ * * 取引タイプごとの 取引先の制約 仕入 * 取引 入庫 0..1 * 銘柄 注文 /トランザクション <<多重>> 受け 払い 入庫 出庫 出荷 0..1 15 モデリング２ 12.1 酒在庫問題 責任の配置 ユースケース：受注する 受付係 : アクタ create : 注文 : 小売店 : 銘柄 isValid isValid 16 モデリング２ 12.1 酒在庫問題 責任の配置 ユースケース：在庫を引き当てる 注文からトランザクションを生成 受付係 : アクタ process : 注文 : /トランザクシ ョン : 勘定 : 払い : 勘定 : 受け getUnprocessed create getAccount create getAccount create 17 モデリング２ 12.1 酒在庫問題 仕様モデル，実装モデル 機能実現の具体的な方法 設計判断 実装判断 アーキテクチャの設計 レイヤリング フレームワークの当てはめ ユーザインタフェース設計 オブジェクト永続化の方法 オブジェクト指向データベース リレーショナルデータベースへは複雑なマッピングが必要 インピーダンスのミスマッチ 関連の実装 18 モデリング２ 12.2 まとめ 情報システム工学 人間活動システム システム論 システム要素間の相互作用→創発 階層と通信 ソフトな問題 構造化できない問題 自分自身がシステムの一部分 正解がない 対策がまた新たな問題の原因に 効果的な情報システム 目的（ビジョン，ミッション，ゴール，目標値）の達成 アプローチ（戦略，戦術，作戦）の選択と合意形成 フィードバックと目的・アプローチの修正の繰り返し 目標値と現状との乖離＝動的テンション 敏感でいること Embrace Change ! 19 モデリング２ 12.2 まとめ 情報システム工学 変化し続ける人間活動システム 現実世界（real world）と認識世界 システムの基本定義 CATWOE分析 Customer： Agent： Transformation： Weltanschauung： Owner： Environment： 基本定義のrefine 基本課題の合意 ソフトな課題構造の合意 20 モデリング２ 12.2 まとめ モデリング 理解と合意のプロセス ドメインと操作の分離 ドメインの定義 Ownerによる世界の認識 Universe of Discourse（UoD） 発明 概念レベル 要求記述としてのユースケース 操作の実現 良いモデルの基準 ユーザインタフェース アプリケーション（機能） ドメイン（概念の世界） 永続化 適度な抽象性 一般性，単純性，耐変更性，再利用性 21 モデリング２ 12.2 まとめ 情報システム工学とオブジェクト指向 概念モデルとの素直な対応 概念の実装としてのクラス－インスタンス 概念階層 ソフトウェア工学からの「良い概念」の基準 結合度 凝集度 オブジェクトメタファー 通信と相互作用 変更吸収の仕組み 拡張のメカニズム 継承 フレームワークの発想 リファクタリングのプラクティス 22