47070 オブジェクト指向モデリング [12] 2002年1月15日

オブジェクト指向モデリング 前回　モデリング1 11.1 自動改札システム 11.2 CS4 11.3 モデルの良さの基準 テキスト　第6章

CS4管理システム 基本定義 基本課題 ユースケースの作成 概念モデルの作成 どのアクティビティを取り出すか システム境界を決める モデリング１ CS4管理システム 基本定義 基本課題 ユースケースの作成 どのアクティビティを取り出すか コースハンドブックを作成する CS4学生リストを生成する 履修申請する システム境界を決める 機能の発明 概念モデルの作成 アクティビティの取り出し システム境界を決める 機能の発明 概念モデリング

オブジェクト指向モデリング 第12回　モデリング2 教科書外 12.1 酒在庫問題 12.2 まとめ

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

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

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

12.1 酒在庫問題 ワークフローの整理 受注 入庫 出荷 仕入注文 モデリング２ 倉庫係 受付係 商品を倉庫に保管する 注文を受ける 受付係 在庫を確認する 在庫不足リストに記入する ［在庫数量不足］ 受注 商品を倉庫に保管する 倉庫係 入庫票に記入する 入庫 出荷 仕入注文を出す 仕入注文 出荷指示をする 在庫不足リストを日別商品別に分類 出荷を記録する 出荷する 当日分だけを選択

12.1 酒在庫問題 ユースケース モデリング２ 仕入販売支援システム 受注する 入庫を記録する 在庫を引き当てる 受付係 倉庫係 出荷指示する 入庫を記録する 倉庫係 出荷を記録する 仕入注文をする

12.1 酒在庫問題 ユースケース記述 モデリング２ ユースケース名：受注する。 アクタ：受付係 目的：小売店からの注文を記録して，出荷指示の準備をする。 事前条件：注文が記録されていない。 基本系列： 　①アクタは，システムに注文を記録する旨を示す。 　②システムはアクタに注文の入力を促す。 　③アクタは注文内容（送り先名，｛商品名，数量，納入希望日｝，受注日）を入 　　力する。 　④システムは，注文内容が妥当であることを確認し，注文番号を発行して， 　　それらを記録する。 事後条件：注文が記録されている。 代替系列：A 基本系列④で注文内容が妥当でなかった場合,... 備考：注文内容が妥当であるとは，... 　　　　注文番号は一連番号とし，ユニーク性を保証すること。

12.1 酒在庫問題 ユースケース記述 モデリング２ 商品名 1/15 12 1/16 1/17 1/18 1/19 1/14 2 -8 計画ホライゾン ユースケース記述 商品名 1/15 マッカラン 12 1/16 1/17 1/18 1/19 1/14 2 -8 ユースケース名：在庫を引き当てる。 アクタ：受付係 目的：注文に対する在庫不足分を明らかにする。 事前条件：未処理の注文がある。 基本系列： 　①アクタは，システムに在庫の確認処理を要請する。 　②システムは，商品別，納入希望日順に在庫量から注文分を減じる。当日お 　　よび翌日の在庫がマイナスになった場合はアクタに警告する。 　③システムは，処理した注文に対して「処理済み」をマークする。 事後条件：未処理の注文がない。 代替系列：なし 備考：在庫引き当ては，商品別，日別の予定在庫を減じることで表現する。 　　　　「仕入注文をする」ユースケースでは，安全在庫を加味して仕入数量を 　　　決める）。 注文： 　マッカラン　10本　1/15 　マッカラン　10本　1/16

モデリング２ 12.1 酒在庫問題 概念モデリング 最初のモデル ちょっと待って。 在庫って何？

12.1 酒在庫問題 在庫とは ユースケースは不変？ 実在庫 ある時点での予定在庫 入庫，出荷は実績 仕入，注文は 入庫予定，出荷予定 モデリング２ 12.1 酒在庫問題 在庫とは 実在庫 期首在庫＋Σ入庫－Σ出荷 ある時点での予定在庫 実在庫＋Σ仕入－Σ注文 入庫，出荷は実績 仕入，注文は 　　　入庫予定，出荷予定 ユースケースは不変？ 時間 累積量 注文 仕入 期首 在庫 滞留時間 実績 予定 現在 flow 出荷 入庫 時間 在庫量 期首 実績 予定 現在 安全在庫 stock ②システムは，商品別，納入希望日順に在庫量から注文分を減じる。当日および翌日の在庫がマイナスになった場合はアクタに警告する。 内部を書きすぎだった

12.1 酒在庫問題 代替案 ものの動きに注目 最初の案はビジネスプロセスに注目していた モデリング２ エントリ トランザクション 実績 * 0..1 実績 予定 入庫 出庫 <<多重>> 銘柄 /在庫 在庫導出 ルール 1 時点 取引先 勘定 メーカ 小売店 受け 払い inv: self.oclTypeOf(入庫） implies self.受け.勘定.取引先.oclTypeOｆ（メーカ） inv: self.oclTypeOf(入庫） implies self.払い.勘定.取引先=null inv: self.oclTypeOf(出庫） implies self.払い.勘定.取引先.oclTypeOｆ（小売店） inv: self.oclTypeOf(出庫） implies self.受け.勘定.取引先=null

12.1 酒在庫問題 さらに代替案 ビジネスプロセスとものの動きの両方をとらえる モデリング２ 一方を導出型とする e.g. 「仕入」のインスタンスを書くと同時に「入庫・予定のトランザクション」，「エントリ」を書く 取引 仕入 入庫 0..1 注文 出荷 小売店 メーカ 実績 受け 払い 予定 取引先 * 勘定 銘柄 /在庫 1 時点 /エントリ /トランザクション <<多重>> 出庫 取引タイプごとの取引先の制約

12.1 酒在庫問題 責任の配置 ユースケース：受注する モデリング２ 受付係 : アクタ : 注文 : 小売店 : 銘柄 create isValid

12.1 酒在庫問題 責任の配置 ユースケース：在庫を引き当てる 注文からトランザクションを生成 モデリング２ 受付係 : アクタ : 注文 : /トランザクシ ョン : 勘定 : 払い : 受け process create getUnprocessed getAccount

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

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

12.2 まとめ 情報システム工学 変化し続ける人間活動システム システムの基本定義 基本課題の合意 ソフトな課題構造の合意 モデリング２ 12.2 まとめ 情報システム工学 変化し続ける人間活動システム 現実世界（real world）と認識世界 システムの基本定義 CATWOE分析 Customer： Agent： Transformation： Weltanschauung： Owner： Environment： 基本定義のrefine 基本課題の合意 ソフトな課題構造の合意

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

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