第2回 DATARUNソリューションセミナー

Presentation on theme: "第2回 DATARUNソリューションセミナー"— Presentation transcript:

1 第2回 DATARUNソリューションセミナー
平成13年11月28日 DATARUNと他の方法論の比較と 　　　　　　　　特徴を生かした使いこなし方 日本工業大学　工学部情報工学科 大木　幹雄 N.I.T. SoftLab　 株式会社PFU

2 簡単な自己紹介 1969年： 日本電子計算（株）入社 1976年以降： 一貫してソフトウェア開発支援ツール，環境整備に従事．
1969年：　日本電子計算（株）入社 1976年以降： 一貫してソフトウェア開発支援ツール，環境整備に従事． 通産省主導特別プロジェクト 「保守技術開発計画－COBOLデータフロー解析支援ツール 」（UNIX ，C) 「形式的仕様技術開発計画 －図式分析支援ツール」（Smalltalk80) 「システムインテグレーション基盤技術開発計画」（UNIX ， C) その後，オブジェクト指向開発コンサルティング等を経て 1996年より日本工業大学情報工学科助教授 専門： データベース，ソフトウェア工学，プログラム設計･開発（C++) 　　　　 著書： “データベース設計の基礎”，“ソフトウェア設計の基礎”， “プログラム設計と開発”　（日本理工出版会） N.I.T. SoftLab　

3 現在の主な研究テーマ ※ DATARUN，オブジェクト指向分析等のソフトウェア分析設計におけるモデリング
(１)　ソフトウェア分析設計モデリング基準の導出と モデリング支援ツール開発 ※ DATARUN，オブジェクト指向分析等のソフトウェア分析設計におけるモデリング 基準の比較評価．（きっかけ：せめて方法論ぐらいは米国の属国にならなくても いいのでは．まずはいろいろな方法論を比較評価してみたい） (２)　デザインパターン生成プロセスのダイナミックモデル作成， およびパターン適用支援ツール開発 ※ デザインパターンの生成プロセスを場の量子論的な見地からモデル化し，デザイン パターンの背後にある特性を明らかにしながら，適用判断基準を導出すること． (３)　不確定な繰返しを含む開発プロセス管理手法の開発と 分散プロジェクト管理への適用実験 ※ ソフトウェア開発は本質的に不確定性を含むことを前提にして，手戻りが頻繁に 発生するスポット的なソフトウェア開発の管理方法を理論化すること． N.I.T. SoftLab　

4 ３．SE初等教育における判断基準の重要性【事例】
講演　概要 １．方法論の役割　 ２．方法論を比較評価する視点 ３．SE初等教育における判断基準の重要性【事例】 ４．いろいろな方法論の簡単なレビュー ５．適用分野から見た比較 ６．効果的な使い分け方法 ７．将来への可能性 N.I.T. SoftLab　

5 第2回 DATARUNソリューションセミナー
平成13年11月28日 １．　方法論の役割 ●　最も重要なのは分析設計の視点を与えてくれること． ●　システムに対するユーザの視点から，プログラムの視点まで，視点を変換してゆくプロセスを与えること．　　　 基本的に，詳細な実装上の問題点はその都度考えるべき事項 N.I.T. SoftLab　 株式会社PFU

6 ● 方法論に絶対的なものは存在するか？ ２． 方法論を比較評価する視点 システムの特徴によって，どの方法論が向いて
２．　方法論を比較評価する視点 ●　方法論に絶対的なものは存在するか？ システムの特徴によって，どの方法論が向いて いる・いないかの“比較の問題”にすぎないのでは？ ・一神教　　VS　 多神教 ・集権化　　VS 分散化 ・統合化　　VS 分社化 ・統一化　　VS 個別化　 　　　　　　　　： ※　類似する“悩ましき比較” の問題 N.I.T. SoftLab　

7 過去のAI分野において起こった一神教と多神教の争い
「知識と推論を統合しよう」派 「知識と推論は使い分けよう」派 ● ジェネリックタス ( Chandrasekaran が提唱） ● 第5世代コンピュータ開発機構 述語論理（Prolog） ＋ オブジェクト指向 ＋ 並列処理 ● フレーム理論 ＋ ルールベース推論 ● フレーム理論 ＋ オブジェクト指向 ＋ ルールベース推論 ● オブジェクト指向 ＋ 述語論理(Prolog) 活動領域に特有な６つの知識構造と推論方法をもつ (1) 状況を要素と可能性から分類学的に分類する． (2) ある状態変化があったとき，それに対応してシステム内で必要な変化を与える． (3) データの属性が与えられたとき，概念的に関連する　　　属性を見出す． (4) なんらかのプランにしたがって，制約条件を満たしながらオブジェクトを合成し，洗練化する． (5) 仮説と問題の状態が与えられたとき，仮説が状況的　　　にマッチするかを決定する． (6) 状況と信念に基づいた仮説と仮説を用いて説明できるデータがあったとき，それらを筋道たって説明できるような仮説を作成する． いろいろな知識や推論を統一させることが，有用性をもつことだ！ 知識は役割と状況毎に使い分けることが有用性をもつことだ！ N.I.T. SoftLab　

8 ●“悩ましき比較問題”の原因になるいくつかのポイント
「集権化 VS 分散化」　「統一化 VS 個別化」等の問題では・・・ ①　全体効率性から見てどうなのか 単純な構成の方が全体を効率化しやすいか 構成を役割毎に分けた方が全体を効率化しやすいか ②　問題への対応性から見てどうなのか 　　　　　　　　　　　　　〃 ③　変化に対する柔軟性・リスクから見てどうなのか 　　　　　　　　　　　　　〃 N.I.T. SoftLab　

9 “悩ましき比較問題”に対する一般的な対処方法
(１)　評価側面の優先度付けと比較基準の設定 (２)　問題を構成する特性の洗い出し ωi ei （３）　基準にしたがって各特性を評価 δij（ ei　，fj） fi 問題毎に総合評価点を出し 結論を出す gj=Σωi δij N.I.T. SoftLab　

10 同様に“方法論の比較”に機械的に適用してみる
(１)　方法論を評価する側面の優先度付けと比較の基準を設定する (２)　“方法論”を構成する特性を洗い出す （３）　基準にしたがって各特性を評価する “方法論”毎に総合評価点を出し 結論を出す 評価には主観が入るのでどこまで信用できるかわからない！ N.I.T. SoftLab　

11 そこで，できるだけ分析的に評価を試みてみる
１ 方法論を比較評価する側面 (a)　管理的な側面 (b)　技術的な側面 ２ 方法論の特性・構成要素 (a)　システムの基本的な構成要素 　　　(b)　対象システムの分野 関連あり N.I.T. SoftLab　

12 ・困ったとき相談できる相手が多くなるか？
１ 方法論を比較評価する側面 (a)　管理的な側面 ①　全体の効率性に関して ・開発工期が短縮されるか？ ・理解が容易になるか？ ・コミュニケーションが円滑になるか？ ・社内教育が容易になるか？ ・社外からの情報も入手しやすくなるか？　etc ②　問題への対応性に関して ・困ったとき相談できる相手が多くなるか？ ・トラブル発生時の責任追及に対して安心感が増すか？　 ・運用が容易になるか？　etc ③　変化に対する柔軟性・変化へのリスクに関して ・方法論と運命を共にするリスクが増すか？ ･従来の考え方を大幅に変える必要がないか？ ・自分の声が反映される機会が増えるか？　etc N.I.T. SoftLab　

13 (b) 技術的な側面 今回は，こちらに重点をおく ① 理解性 誰にでも容易に手順が理解できるか？ ② 明瞭性 分析の判断基準が明確か？
①　理解性 誰にでも容易に手順が理解できるか？ ②　明瞭性 分析の判断基準が明確か？ ③　厳密性 方法に矛盾する点はないか？ ④　形式性 記述が容易で，意味が一意的か？ ⑤　伝達性 容易に伝達できるか？ 特に重視 どの方法論も 通常満たしている N.I.T. SoftLab　

14 第2回 DATARUNソリューションセミナー
平成13年11月28日 ２ 方法論の特性・構成要素 (a)　分析設計で考えるシステムの基本的な構成要素 状 態 　 　　データ 　　イベント 　（きっかけ） 　 　　機 能 N.I.T. SoftLab　 株式会社PFU

15 ※ システムの構成要素と代表的な方法論の関係
※　システムの構成要素と代表的な方法論の関係 分析の主たる着目点 方法論名 ●機能モジュール構造 　構造化分析設計法 ●実体ｰ属性ｰ関連構造 　データ中心分析設計法 ●クラス構造，協調関係状態遷移関係 　オブジェクト指向分析設計法 ●実体ｰ属性ｰ関連構造画面遷移構造 　DATARUN分析設計法 N.I.T. SoftLab　

16 (b) “対象システムの分野”とシステムの構成要素との関連
着目する基本要素 機能 データ 状態 イベント システム分野 情報システム系【 ３層モデルのとき 】 ① ユーザインタフェース ② Ｃ／Ｓアプリケーションサービス ③ データベースサービス 組込みシステム系 リアルタイム制御システム系 Webシステム系 N.I.T. SoftLab　

17 以下の評価基準に対する比較順位の問題になる！
方法論の比較はシステムの構成要素毎に 以下の評価基準に対する比較順位の問題になる！ 構成要素 機　能 [評価基準1] 分析の視点が理解しやすいか？ データ [評価基準2] 分析設計の手順や判断基準が明確か？ 状　態 イベント N.I.T. SoftLab　

18 ３． SE初等教育における判断基準の重要性 【事例】 “データベース設計演習” の概念モデル作成演習 （1） 属性と属性実現値の混同
をもとに行った概念モデリングの誤り分析 （1）　属性と属性実現値の混同 （　最も初歩的誤り。それでも２５％の学生が間違える　） 　ジャンル アクション コメディ SFファンタジー 　　　： 　　ジャンル ジャンル番号 ジャンル名 N.I.T. SoftLab　

19 （2） 概念がもつ属性と関連がもつ属性の混同 （ ERモデルを多少記述できる者の誤り。１３％が間違える ）
（2）　概念がもつ属性と関連がもつ属性の混同 （　ERモデルを多少記述できる者の誤り。１３％が間違える　） 　　レース　 レース番号 レース名 日付 　競走馬　 馬番号 馬名 　　騎手　 騎手番号 騎手名 出走 0..* 1 着順 タイム N.I.T. SoftLab　

20 （ ERモデルを理解しはじめた者の誤り。６７％が間違える ）
（3）　関連の多重度や識別子依存性の誤り （　ERモデルを理解しはじめた者の誤り。６７％が間違える　） 　　明細 明細番号 数量 単価 　　　見積 見積番号 見積日付 1 1..* N.I.T. SoftLab　

21 （ レベルに関係なく発生。８８％の学生が間違える ）
（4）　異なるカテゴリの属性の混入 （　レベルに関係なく発生。８８％の学生が間違える　） ①　概念固有の属性以外の混入 　　　売上　 日付 売上管理番号 　　担当者　 従業員番号 氏名 入社年 0..* 1 　　　売上　 日付 売上管理番号 担当者 “売上”に固有の属性でない ②　属性と概念の混同　 　　値引き ランク番号 有効期間 値引率 　　商品 商品番号　 商品名 0..* 1 　　商品 商品番号　 商品名 値引率 “商品”に固有の属性でなく むしろ“値引き”の属性にすべき N.I.T. SoftLab　

22 《 原因分析のまとめ》 ● 業務経験や概念モデリングの知識が少ないものにとって業務で用いる“概念(実体型）”を何の指針もなく思い浮かべることは困難である． ● 分析設計の具体的な視点と理解しやすい判断基準がない． 重要 N.I.T. SoftLab　

23 ４． いろいろな方法論の簡単なレビュー 構造化分析設計法 オブジェクト指向分析設計法 DATARUN分析設計法(モデル中心アプローチ）
４．　いろいろな方法論の簡単なレビュー 構造化分析設計法 オブジェクト指向分析設計法 DATARUN分析設計法(モデル中心アプローチ） 　　　　実質，データ中心＋オブジェクト指向 N.I.T. SoftLab　

24 構造化システム分析 データフロー図 【 性能・信頼性分析 】 【 データ分析 】 【 システム要求分析 】 データ辞書 データ構造図 ER図
【 データ分析 】　 【 システム要求分析 】 データ辞書 データ構造図 　データフロー図 　　ER図 プロセス仕様書 どのようにデータをまとめるか， 　　　　　関連があるか どんなプロセス（処理）やデータが必要か 0..* 　実体名2 基本ﾃﾞｰﾀ名1 基本ﾃﾞｰﾀ名2 基本ﾃﾞｰﾀ名3 関連名1 外部ｴﾝﾃｨﾃｨ名 データ名1 データ名3 ﾌﾟﾛｾｽ名2 1 入力データ名1 データ名2 ﾌﾟﾛｾｽ名1 　実体名１ 基本ﾃﾞｰﾀ名1 基本ﾃﾞｰﾀ名2 　ストア名 N.I.T. SoftLab　

25 プロセス仕様書 データ構造図 IPOによる処理内容の記述例 繰り返し 選択 * N.I.T. SoftLab 記入日 XX レベル１．5
最短経路を求める ﾊﾞｰｼﾞｮﾝ 1.0 記入者 大木 　 入力(I)　　　　　　　　 処理(P)　　　　　　　 出力(O) I1． ノード表 I2． 各リンクの 両端ノード I3． リンク間距離 I4． 出発ノードと 到着ノード 1． 最短経路 2． 最短距離 1． ノード毎に結ばれている他のノードとそのノードまでの距離を記録する形式でデータを整理する 2． 出発ノードから走者（あるいはトークン） を逐次進め進んできた経路を記録する 3． 最も短い距離を走ってきた走者の記録が最短経路である 並び換えデータ 並び換え要素 * 並び換えキー レコードポインタ 繰り返し 連絡先 自宅電話番号 携帯電話番号 選択 N.I.T. SoftLab　

26 構造化システム設計 【 性能・信頼性設計 】 【 入出力設計 】 【 データベース設計 】 【 ソフトウェア設計 】 モジュール構造図
モジュール仕様図 #1.0 出庫依頼の受付 #1.1.1 出庫依頼書を入力 #1.1.2 在庫ﾌｧｲﾙを読む #1.1 出庫可能かﾁｪｯｸ #1.4 出庫を指示 #1.5 積荷票を受取る #1.5.1 積荷票を入力 #1.5.2 在庫ﾌｧｲﾙへ書込む #1.3.1 #1.3.2 在庫不足品ﾘｽﾄを読む #1.3.4 不足品出庫指示書を出力 #1.4.1 出庫指示書を出力 出庫依頼書 出庫指示 積荷票 在庫不足品 入荷通知 不足品出庫指示 ﾁｪｯｸ後の出庫依頼書 入力処理 出力処理 #1.2.1 在庫不足品ﾘｽﾄへ書込む #1.3.3 #1.3 不足品目の出庫を指示 #1.2 出庫不可の出庫依頼を記録 どのようなモジュール構造をもつか N.I.T. SoftLab　

27 ノードiまでの合計時間 > Pまでの合計時間 + time
経由ルート表(route)および最短合計時間表に，初期値0と∞をそれぞれ設定する． Pを始点ノードとする モジュール仕様図 Pが終点ノードと一致するまで --- ノードに到着したときの経過時間を比較する --- Pに接続しているすべてのノードiについて モジュールはどのような機能をもつか Pからノードiまでの時間をtimeとする ノードiまでの合計時間 >　Pまでの合計時間 + time Yes No --- Pを経由したルートの方が合計時間が短いので先に到着すべき --- ノードiまでの合計時間を Pまでの合計時間 + timeにする ノードiの経由ノードをPとする --- 次に計算を進めるべきノードの決定 --- ネットワーク全体から経過時間の最も短いノードを選び出し，次に計算を進めるべき ノードをPとする． 経由ルート表(route)および最短合計時間表(totalTime)に，初期値0と∞をそれぞれ設定する． Pを始点ノードとする Pが終点ノードと 一致するまで Pに接続するすべてのノードiについて Pからノードiまでの時間を timeとする ノードiまでの合計時間 >　Pまでの合計時間 　 + time ネットワーク全体から経過時間の最も短いノードを選び出し，次に計算を進めるべきノードPとする． Y ①ノードiまでの合計時間を Pまでの合計時間+ timeにする． ②ノードiの経由ノードをPとする． N.I.T. SoftLab　

28 ◆ システム動作設計 N.I.T. SoftLab 東西方向 南北方向 赤 ④ ① ② ③ 黄 青 空でない
◆　システム動作設計 　 空でない 　/*　Size > 0 */ 　　 空 /* Size = 0 */ top push(X)／size’++1; top’=X pop[size =1]／pop’=top; size’=0 pop[size =1]／pop’=top; size’-- push(X)／size’++; top’=X 顧 客 レンタルショップ受付係 レンタル注文 会員証提示要求 会員証提示 レンタル商品DB 売上DB 商品番号, 合計数記録 仮払売上金額の記録 記録完了 精算OK 青 黄 赤 東西方向 南北方向 ④ ① ② ③ N.I.T. SoftLab　

29 《 構造化分析設計まとめ 》 分析・設計間における視点の変換 対応付けの指針はない 処理とデータの洗い出し 具体的な機能構造 プロセス仕様書
《　構造化分析設計まとめ　》 対応付けの指針はない 処理とデータの洗い出し 具体的な機能構造 プロセス仕様書 モジュール構造図 データフロー図 データ構造図 モジュール仕様図 データ辞書 　　ER図 分析・設計間における視点の変換 動作設計 　状態遷移図 ペトリネット イベントトレース図 N.I.T. SoftLab　

30 オブジェクト指向分析設計（構造化分析設計との比較）
オブジェクト指向分析設計の ドキュメント類 構造化分析のドキュメント類 クラス構造図 設計 順序 データフロー図 （クラスの種類と関連の記述） ER図 相互作用図 （オブジェクト間でやりとりされるメッセージ＝メソッドの種類と順序の記述） 状態遷移図 振る舞い図 （各メソッド内，メソッド間の動作の記述） N.I.T. SoftLab　

31 ◆ オブジェクト指向分析設計の基本的な作業手順
◆　オブジェクト指向分析設計の基本的な作業手順 スパイラル的に繰返し分析設計可能　(　視点の変換が不要　） オブジェクト間の相互作用 （メッセージのやり取り等） オブジェクト内部の振る舞い （ メッセージ到着等によって 起動される独自の内部動作列 ） ｵﾌﾞｼﾞｪｸﾄp 相互作用 ｵﾌﾞｼﾞｪｸﾄｑ ｵﾌﾞｼﾞｪｸﾄｓ ｵﾌﾞｼﾞｪｸﾄｒ ｸﾗｽA 背後にあるオブジェクト の静的なクラス構造 ｸﾗｽB ｸﾗｽC N.I.T. SoftLab　

32 ◆ UMLにおける分析ドキュメント類 協調図 ドキュメント型 ドキュメント種類 記 述 内 容 ① ユースケース図 ② 静的構造図
記　述　内　容 ① ユースケース図 ② 静的構造図 ③ 振る舞い図 ④ 相互作用図 ⑤ 実装図 ・クラス図 ・オブジェクト図 ・状態図 ・アクティビティ図 ・シーケンス図 ・協調図 ・コンポーネント図 ・配置図 ユーザがシステムと対話するときの一連の処理 クラスとクラス間の関連 特定の時点でのインスタンスの集合 特定クラスに属するオブジェクトの状態遷移図 内部処理の制御の流れを表すワークフロー オブジェクト間のイベントトレース図　 オブジェクト間のメッセージのやり取り図 コンポーネント間の依存性図 コンポーネントやオブジェクトの計算資源の配置 顧客 店員A：受付係クラス １．注文 店員B：倉庫係クラス 　　利用状況 ２．有効期限（顧客名） ３．利用履歴（顧客名） ４．陳列依頼 協調図 N.I.T. SoftLab　

33 ◆ オブジェクト指向によるソフトウェア開発の利点
◆　オブジェクト指向によるソフトウェア開発の利点　 クラスやオブジェクト間の関連（クラス図）ができ上がると，後はそれぞれのオブジェクトのメソッドを詳細化して行くだけでよい． しかし，逆に言えば、 『クラス図の良し悪しが開発システムの出来を決定する』 2: お座り 　　：人 　　：ペット 1: 指示を出す 3: お手 　　ペット 愛称 お手 お座り １ 0..* 　　家 0..2 　　人 　 氏名 指示を出す メソッドを次々と追加 メソッド内容を段階的に詳細化 《　クラス図　》 《　オブジェクト図　》 N.I.T. SoftLab　

34 ◆ 「クラスをいかに抽出するか」が最も重要な作業になる
◆　「クラスをいかに抽出するか」が最も重要な作業になる ただし，クラスにはいろいろな役割のものがあることに注意する 例えば，標準になっているMVCモデルでは・・・ Modelクラス群 （データ） データ格納庫 Viewクラス群 （表示） Controllerクラス群 （イベント制御） 外部から与える操作 GUI N.I.T. SoftLab　

35 クラス抽出の代表的な手法 《 機能クラスを中心としたクラス抽出手法 》 (a) 責任駆動アプローチ (b) ユースケースアプローチ
《　機能クラスを中心としたクラス抽出手法　》 (a)　責任駆動アプローチ　 自分がシステムの中心的な人物（クラス）になったつもりで，他者に 対して，どのようなサービスの責任を負うかの観点から，擬人とし てのクラスを洗い出す（観察力と洞察力が必要） (b)　ユースケースアプローチ　 システム外部から見たシステムに期待する機能をユースケース （利用方法）を列挙しながら洗い出す．名詞や動詞，副詞に注目 してクラスやメソッドを抽出してゆく． 《　データ格納クラスを中心としたクラス抽出手法　》 見当たらない！！ N.I.T. SoftLab　

36 (a) 責任駆動アプローチによるクラス抽出
CRC(Class,Responsibility,Collaboration)カード カードを利用した発想法（KJ法）的なクラスの抽出 クラス名 関連するクラス (Collaboration) 受けもつ責任 (Responsibility) ※ どうしても，XXマネージャといったクラスが多くなる アクション 表示スクリーンの順序」 トランザクション組立て トランザクション 表示スクリーン イベント 状態の応答待ち ハードからユーザインタフェースの分離 表示スクリーン カード読取機 現金支払機 リモートDB 現金支払機 現金の支払い 成功か空かシグナル トランザクション イベント リモートDB アカウント トランザクションの記録 状態の応答 イベント トランザクション カード読取機 磁気コードの解読 シグナルの挿入 トランザクション イベント トランザクション 検証と金の移動 カード読取機 現金支払機 リモートDB アクション アカウント オーディットの保持 表示スクリーン 確認の表示 アクションへのイベント 　　　　の通知 トランザクション イベント アカウント 収支と記録の保持 トランザクション リモートDB N.I.T. SoftLab　

37 (b) ユースケースアプローチ ① 基本系列を短文に分解し名詞，動詞，副詞を見出す．
アクタ　倉庫係 注文する レンタル伝票を作成する 仮精算をする アクタ　顧客 商品を渡す 商品を陳列する 商品の陳列を依頼する アクタ　受付係 受付システム 会員を確認する シナリオを起動するきっかけを与える ユースケース名 ： ア ク タ ： システム外部からシステムに働き掛ける動作主体を記述する． 目　　的 ： シナリオの目的を記述する． 事前条件 ： シナリオが起動するための条件を記述する． 基本系列 ： システムとの対話の事象列を記述する． 　　　　　　　　　　　　　： 事後条件 ： シナリオによる処理が完了したときに成立しているべき条件を記述する． ①　基本系列を短文に分解し名詞，動詞，副詞を見出す． ②　名詞，動詞，副詞等をオブジェクト，メソッド，属性，イベントに対応つける． N.I.T. SoftLab　

38 《 代表的なオブジェクト指向クラス抽出手法のまとめ 》
（１） クラスが提供すべきサービス(インタフェース）を中心に経験と“ひらめき”によってクラスを抽出する. （ただし，“ひらめく”ためのガイドラインは多少ある）． （２） 詳細なメソッドは“イベントの発生”に注目して決定する． （３） サービスは往々にして変化するため分析の判断基準を設けることが困難になっている． （４） データ格納クラスに関する分析は軽視している． N.I.T. SoftLab　

39 DATARUN分析設計法 （モデル中心アプローチ）
データベースを中心とした情報システムに特化した方法論 構造化分析のドキュメント類 DATARUNのドキュメント類 データフロー図 拡張データフロー図：BPM 分析の中心 システム起動のきっかけ(PDG） の洗い出し プロセスとデータの洗い出し 拡張ER図（クラス構造図）：ERM ER図 分析の中心 データ構造と関連の洗い出し 画面遷移図（CDM+α） 状態遷移図 システム動作の決定 N.I.T. SoftLab　

40 特徴 （１） BPMで基本データが記載された入力帳票類を見出す（構造化分析の発想）
（２） クラスは帳票類から抽出した基本データを整理分類した入れもの（データ中心的な発想）． （３） PDGを基準にして，基本データを整理分類する （オブジェクト指向の基本概念の利用）． [指針]　初期値の決定時点が同じ属性は，同じクラスに属すべき （４） Modelクラスに手順を追加してゆく（オブジェクト指向的な発想） N.I.T. SoftLab　

41 ◆ 分析の判断基準PDG （＝基本データ発生のきっかけとなるタイミング） なぜ（ｂ）がよくて（a）が悪いのかが判断できる (a) 悪い抽出例
　　　　　　　　　　（＝基本データ発生のきっかけとなるタイミング） 　　　商　品 商品説明 販売価格 商品仕入番号 統一商品コード (a) 悪い抽出例 なぜ（ｂ）がよくて（a）が悪いのかが判断できる 　　商　品 商品仕入番号 　　 商品情報 商品説明 販売価格 統一商品コード 1 ＊ 記録する (b) 良い抽出例 N.I.T. SoftLab　

42 《 DATARUNのまとめ 》 （１） クラスを抽出する明確な判断基準がある（PDG） （２） 業務レベルでの発生イベントに着目している．
（２）　業務レベルでの発生イベントに着目している． （３）　Modelクラスの抽出に重点を置いている． Modelクラス群 （データ） データ格納庫 Viewクラス群 （表示） Controllerクラス群 （イベント制御） GUI 外部から与える操作 N.I.T. SoftLab　

43 ５. 適用分野から見た比較 機能 データ 状態 イベント 情報システム系【 ３層モデルのとき 】 組込みシステム系
５.　適用分野から見た比較 視点の理解容易性 明確な判断基準 着目する基本要素 機能 データ 状態 イベント システム分野 情報システム系【 ３層モデルのとき 】 ① ユーザインタフェース OOA ② Ｃ／Ｓアプリケーションサービス DATARUN DATARUN ③ データベースサービス DATARUN DATARUN 組込みシステム系 OOAD OOAD リアルタイム制御システム系 Webシステム系 N.I.T. SoftLab　

44 情報システム開発向けの方法論は？ [基準1] 方法論の着眼点が理解しやすいか？ DATARUN ＞ OOAD
[基準1] 　方法論の着眼点が理解しやすいか？ DATARUN　　＞　　OOAD [基準2] 　判断基準が明確か（イベント） ？ DATARUN　　＞　　OOAD ※　画面操作の詳細な分析設計 DATARUN　　＜　OOAD N.I.T. SoftLab　

45 組込みシステム開発向けの方法論は？ 制御システム開発向けの方法論は？ [基準1] 方法論の着眼点が理解しやすいか？
[基準1] 　方法論の着眼点が理解しやすいか？ DATARUN　　＜　　OOAD [基準2] 　判断基準が明確か（イベント）？ DATARUN　　＜　　OOAD 制御システム開発向けの方法論は？ [基準1] 　方法論の着眼点が理解しやすいか？ DATARUN　　＜　　OOAD [基準2] 　判断基準が明確か（イベント）？ DATARUN　　＜　　OOAD N.I.T. SoftLab　

46 ６. 効果的な使い分け方法 OOA/OOD DATARUN ※ 留意点： システムの変化に対応して方法論も進化する． データ収集の必要性
６.　効果的な使い分け方法 データ収集の必要性 操作の中心：データ｜機能 データベース接続 OOA/OOD 特に前提としない 複雑な機能 特に前提としない DATARUN 既存の入力帳票の収集が必要 データ あり ※　留意点：　システムの変化に対応して方法論も進化する． N.I.T. SoftLab　

47 企業毎に主に用いる方法論 DATARUN分析設計法 構造化分析設計法 データ中心分析設計法 オブジェクト指向 分析 設計法
　企業毎に主に用いる方法論 構造化分析設計法 データ中心分析設計法 オブジェクト指向 分析 設計法 バッチ処理的な従来型 システムのとき データベースを中心にした従来型システムのとき GUIをベースにしたデータ入力・表示方法が必要なとき(例えば,webアプリケーション） DATARUN分析設計法 データベースとGUI表示を併せもつシステムのとき ● 基本は使い分けること． プログラマ ： 1つのプログラミング言語しかしらない　＜＝　失格 SE ： 1つの方法論しか知らない　＜＝　失格 N.I.T. SoftLab　

48 ７. 将来への可能性（研究テーマに関する余談）
７.　将来への可能性（研究テーマに関する余談） DATARUN分析設計法を参考にして，分析の３つの判断基準の延長にあるものを考えると・・・ ３つの分類基準 【　分類基準C1　】　初期値決定時点の同時性 初期値が決定される時点ｔ0が同一の基本データdiは，同じ概念に属する属性とする． 【　分類基準C2　】　実現値の構造性 多値や選択的に実現値が決まる基本データは，単値基本データと混在する形で概念の属性となりえない．別の概念の属性として分離しなければならない． 【　分類基準C3　】　初期値の決定状況単一性 初期値の決定時点が複数の状況に依存する基本データは，状況によって一意的に決まる初期値の決定時点をもった概念の上位概念に属する属性である． N.I.T. SoftLab　

49 ● ３つの分類基準を用いた概念モデル抽出の具体例
●　３つの分類基準を用いた概念モデル抽出の具体例 (注) * …　繰返し構造をもつ ○ …　実現値が決定する Ref …　他の事象で決められた実現値を参照する 分析の最初の焦点＝ 実現値決定のタイミング分析 分離 導出データ N.I.T. SoftLab　

50 ただし，結合度の決定，自己参照的な関連の決定方法等にいくつかの課題が残っている
最終的に抽出された概念モデル 注文―明細 注文―顧客 1..* 1 0..* 注文―商品 　　顧 客 顧客番号 顧客名 住所 電話番号 顧客登録日付 営業担当者 　　商 品 商品番号 商品名 商品単価 商品登録日付 仕切り率 　　注 文 注文日付 注文番号 　　明 細 明細番号 注文数 ただし，結合度の決定，自己参照的な関連の決定方法等にいくつかの課題が残っている N.I.T. SoftLab　

51 デザインパターン形成プロセスのモデル化に向けて
《　アナロジー 》 いろいろな性質をもつ物質が 　　なぜ存在するのか 未知なる物質の もつ性質が予測 可能になった！ 元素の周期律表 理論的な説明と分類 （1）　原子の概念と構成する要素 原子のもつ電荷量＆電子の離散的なエネルギーレベル （2）　相互作用の法則と安定状態の概念 固有で安定的なエネルギーレベルとその間での状態遷移 N.I.T. SoftLab　

52 同様な発想でデザインパターン形成プロセスを モデル化できないか？
　　　　　　　　　　　　　　　　　　モデル化できないか？　 いろいろなパターンの存在 ①未知なるパターンの存在や性質が導出できる ②容易にデザインパターンをいろいろな局面に適用できる モデル化された デザインパターン形成プロセス 理論的な説明 （1）　設計を構成する基本的な構成要素 （2）　判断基準と構成要素の安定状態の概念 N.I.T. SoftLab