DATARUNと他の方法論の比較と 特徴を生かした使いこなし方 日本工業大学 工学部情報工学科 大木 幹雄 http://uhura.nit.ac.jp/~ohki/ N.I.T. SoftLab 1 簡単な自己紹介 1969年： 日本電子計算（株）入社 1976年以降： 一貫してソフトウェア開発支援ツール，環境整備に従事． 通産省主導特別プロジェクト 「保守技術開発計画－COBOLデータフロー解析支援ツール 」（UNIX ，C) 「形式的仕様技術開発計画 －図式分析支援ツール」（Smalltalk80) 「システムインテグレーション基盤技術開発計画」（UNIX ， C) その後，オブジェクト指向開発コンサルティング等を経て 1996年より日本工業大学情報工学科助教授 専門： データベース，ソフトウェア工学，プログラム設計･開発（C++) 著書： “データベース設計の基礎”，“ソフトウェア設計の基礎”， “プログラム設計と開発” （日本理工出版会） N.I.T. SoftLab 2 現在の主な研究テーマ (１) ソフトウェア分析設計モデリング基準の導出とモデリング支援ツール開発 ※ DATARUN，オブジェクト指向分析等のソフトウェア分析設計におけるモデリング 基準の比較評価．（きっかけ：せめて方法論ぐらいは米国の属国にならなくても いいのでは．まずはいろいろな方法論を比較評価してみたい） (２) デザインパターン生成プロセスのダイナミックモデル作成， およびパターン適用支援ツール開発 ※ デザインパターンの生成プロセスを場の量子論的な見地からモデル化し，デザイン パターンの背後にある特性を明らかにしながら，適用判断基準を導出すること． (３) 不確定な繰返しを含む開発プロセス管理手法の開発と 分散プロジェクト管理への適用実験 ※ ソフトウェア開発は本質的に不確定性を含むことを前提にして，手戻りが頻繁に 発生するスポット的なソフトウェア開発の管理方法を理論化すること． N.I.T. SoftLab 3 講演 概要 １．方法論の役割 ２．方法論を比較評価する視点 ３．SE初等教育における判断基準の重要性【事例】 ４．いろいろな方法論の簡単なレビュー ５．適用分野から見た比較 ６．効果的な使い分け方法 ７．将来への可能性 N.I.T. SoftLab 4 １． 方法論の役割 ● 最も重要なのは分析設計の視点を与えてくれること． ● システムに対するユーザの視点から，プログラムの 視点まで，視点を変換してゆくプロセスを与えること． 基本的に，詳細な実装上の問題点はその都度考えるべき事項 N.I.T. SoftLab 5 ２． 方法論を比較評価する視点 ● 方法論に絶対的なものは存在するか？ システムの特徴によって，どの方法論が向いて いる・いないかの“比較の問題”にすぎないのでは？ ※ 類似する“悩ましき比較” の問題 ・一神教 ・集権化 ・統合化 ・統一化 VS VS VS VS ： 多神教 分散化 分社化 個別化 N.I.T. SoftLab 6 過去のAI分野において起こった一神教と多神教の争い 「知識と推論を統合しよう」派 「知識と推論は使い分けよう」派 ● ジェネリックタス ● 第5世代コンピュータ開発機構 ( Chandrasekaran が提唱） 活動領域に特有な６つの知識構造と推論方法をもつ 述語論理（Prolog） ＋ オブジェクト指向 ＋ 並列処理 (1) 状況を要素と可能性から分類学的に分類する． (2) ある状態変化があったとき，それに対応してシステム 内で必要な変化を与える． ● フレーム理論 ＋ ルールベース推論 (3) データの属性が与えられたとき，概念的に関連する 属性を見出す． ● フレーム理論 ＋ オブジェクト指向 ＋ ルールベース推論 (4) なんらかのプランにしたがって，制約条件を満たしな がらオブジェクトを合成し，洗練化する． ● オブジェクト指向 ＋ 述語論理(Prolog) (6) 状況と信念に基づいた仮説と仮説を用いて説明でき るデータがあったとき，それらを筋道たって説明できる ような仮説を作成する． (5) 仮説と問題の状態が与えられたとき，仮説が状況的 にマッチするかを決定する． いろいろな知識や推論を統一させることが， 有用性をもつことだ！ 知識は役割と状況毎に使い分けることが 有用性をもつことだ！ N.I.T. SoftLab 7 ●“悩ましき比較問題”の原因になるいくつかのポイント 「集権化 VS 分散化」 「統一化 VS 個別化」等の問題では・・・ ① 全体効率性から見てどうなのか 単純な構成の方が全体を効率化しやすいか 構成を役割毎に分けた方が全体を効率化しやすいか ② 問題への対応性から見てどうなのか 〃 ③ 変化に対する柔軟性・リスクから見てどうなのか 〃 N.I.T. SoftLab 8 “悩ましき比較問題”に対する一般的な対処方法 (１) 評価側面の優先度付け と比較基準の設定 ωi (２) 問題を構成する特性の 洗い出し ei fi （３） 基準にしたがって各特性を評価 問題毎に総合評価点を出し 結論を出す N.I.T. SoftLab δij（ ei ，fj） gj=Σωi δij 9 同様に“方法論の比較”に機械的に適用してみる (１) 方法論を評価する側面 の優先度付けと比較の 基準を設定する (２) “方法論”を構成する 特性を洗い出す （３） 基準にしたがって各特性を評価する “方法論”毎に総合評価点を出し 結論を出す 評価には主観が入るのでどこまで信用できるかわからな い！ N.I.T. SoftLab 10 そこで，できるだけ分析的に評価を試みてみる １ 方法論を比較評価する側面 (a) 管理的な側面 (b) 技術的な側面 ２ 方法論の特性・構成要素 (a) システムの基本的な構成要素 (b) 対象システムの分野 N.I.T. SoftLab 関連あり 11 １ 方法論を比較評価する側面 (a) 管理的な側面 ① 全体の効率性に関して ・開発工期が短縮されるか？ ・理解が容易になるか？ ・コミュニケーションが円滑になるか？ ・社内教育が容易になるか？ ・社外からの情報も入手しやすくなるか？ etc ② 問題への対応性に関して ・困ったとき相談できる相手が多くなるか？ ・トラブル発生時の責任追及に対して安心感が増すか？ ・運用が容易になるか？ etc ③ 変化に対する柔軟性・変化へのリスクに関して ・方法論と運命を共にするリスクが増すか？ ･従来の考え方を大幅に変える必要がないか？ ・自分の声が反映される機会が増えるか？ etc N.I.T. SoftLab 12 (b) 技術的な側面 今回は，こちらに重点をおく ① 理解性 誰にでも容易に手順が理解できるか？ ② 明瞭性 分析の判断基準が明確か？ ③ 厳密性 方法に矛盾する点はないか？ ④ 形式性 記述が容易で，意味が一意的か？ ⑤ 伝達性 容易に伝達できるか？ N.I.T. SoftLab 特に重視 どの方法論も 通常満たしている 13 ２ 方法論の特性・構成要素 (a) 分析設計で考えるシステムの基本的な構成要素 状態 データ イベント （きっかけ） 機能 N.I.T. SoftLab 14 ※ システムの構成要素と代表的な方法論の関係 分析の主たる着目点 方法論名 ●機能モジュール構造 構造化分析設計法 ●実体ｰ属性ｰ関連構造 データ中心分析設計法 ●クラス構造，協調関係 状態遷移関係 オブジェクト指向分析設計法 ●実体ｰ属性ｰ関連構造 画面遷移構造 DATARUN分析設計法 N.I.T. SoftLab 15 (b) “対象システムの分野”とシステムの構成要素との関連 システム分野 着目する基本要素 機能 データ 状態 イベント 情報システム系【 ３層モデルのとき 】 ① ユーザインタフェース ② Ｃ／Ｓアプリケーションサービス ③ データベースサービス 組込みシステム系 リアルタイム制御システム系 Webシステム系 N.I.T. SoftLab 16 方法論の比較はシステムの構成要素毎に 以下の評価基準に対する比較順位の問題になる！ 構成要素 機 能 [評価基準1] 分析の視点が理解しやすいか？ データ [評価基準2] 分析設計の手順や判断基準が明確か？ 状 態 イベント N.I.T. SoftLab 17 ３． SE初等教育における判断基準の重要性 【事例】 “データベース設計演習” の概念モデル作成演習 をもとに行った概念モデリングの誤り分析 （1） 属性と属性実現値の混同 （ 最も初歩的誤り。それでも２５％の学生が間違える ） ジャンル アクション コメディ ジャンル ジャンル番号 SFファンタ ジー ： ジャンル名 N.I.T. SoftLab 18 （2） 概念がもつ属性と関連がもつ属性の混同 （ ERモデルを多少記述できる者の誤り。１３％が間違える ） レース レース番号 レース名 日付 1 出走 着順 タイム 0..* 競走馬 馬番号 馬名 0..* 騎手 騎手番号 騎手名 N.I.T. SoftLab 19 （3） 関連の多重度や識別子依存性の誤り （ ERモデルを理解しはじめた者の誤り。６７％が間違える ） 見積 見積番号 見積日付 1 1..* 明細 明細番号 数量 単価 N.I.T. SoftLab 20 （4） 異なるカテゴリの属性の混入 （ レベルに関係なく発生。８８％の学生が間違える ） ① 概念固有の属性以外の混入 売上 売上 1 日付 日付 売上管理番号 担当者 担当者 0..* 従業員番号 売上管理番号 氏名 入社年 “売上”に固有の属性でない ② 属性と概念の混同 商品 商品番号 商品名 商品 0..* 1 値引き 商品番号 ランク番号 商品名 有効期間 値引率 値引率 “商品”に固有の属性でなく むしろ“値引き”の属性にすべき N.I.T. SoftLab 21 《 原因分析のまとめ》 ● 業務経験や概念モデリングの知識が少ないものにとって 業務で用いる“概念(実体型）”を何の指針もなく思い浮か べることは困難である． ● 分析設計の具体的な視点と理解しやすい判断基準がない． 重要 N.I.T. SoftLab 22 ４． いろいろな方法論の簡単なレビュー 構造化分析設計法 オブジェクト指向分析設計法 DATARUN分析設計法(モデル中心アプローチ） 実質，データ中心＋オブジェクト指向 N.I.T. SoftLab 23 構造化システム分析 【 性能・信頼性分析 】 【 データ分析 】 【 システム要求分析 】 データ辞書 データ構造図 データフロー図 ER図 プロセス仕様書 どんなプロセス（処理）やデータが必要か データ名1 外部ｴﾝﾃｨﾃｨ名 入力データ名1 ﾌﾟﾛｾｽ名2 データ名3 どのようにデータをまとめるか， 関連があるか 関連名1 1 データ名2 ﾌﾟﾛｾｽ名1 ストア名 N.I.T. SoftLab 0..* 実体名2 基本ﾃﾞｰﾀ名1 基本ﾃﾞｰﾀ名2 基本ﾃﾞｰﾀ名3 実体名１ 基本ﾃﾞｰﾀ名1 基本ﾃﾞｰﾀ名2 24 プロセス仕様書 データ構造図 IPOによる処理内容の記述例 レベル１．5 最短経路を求める 入力(I) I1． ノード表 I2． 各リンクの 両端ノード I3． リンク間距離 I4． 出発ノードと 到着ノード ﾊﾞｰｼﾞｮﾝ 1.0 処理(P) 記入者 大木 記入日 XX 出力(O) 並び換えデータ 1． ノード毎に結ばれている他のノードとそ のノードまでの距離を記録する形式で データを整理する 並び換え要素 2． 出発ノードから走者（あるいはトークン） を逐次進め進んできた経路を記録する 3． 最も短い距離を走ってきた走者の記録 が最短経路である 並び換えキー 繰り返し * レコードポインタ 1． 最短経路 2． 最短距離 自宅電話番号 N.I.T. SoftLab 選択 連絡先 携帯電話番号 25 構造化システム設計 【 性能・信頼性設計 】 【 入出力設計 】 【 データベース設計 】 【 ソフトウェア設計 】 モジュール構造図 モジュール仕様図 #1.0 出庫依頼の受付 どのようなモジュール構造をもつか ﾁｪｯｸ後の出庫依頼書 入荷通知 出力処理 入力処理 #1.1 出庫可能 かﾁｪｯｸ 出庫依頼書 #1.1.1 出庫依頼 書を入力 #1.2 出庫不可の出庫 依頼を記録 #1.3 不足品目の出 庫を指示 出庫指示 在庫不足品 #1.1.2 在庫ﾌｧｲ ﾙを読む #1.2.1 在庫不足品ﾘｽ ﾄへ書込む 在庫不足品 #1.3.1 在庫ﾌｧｲﾙ を読む #1.4 出庫を指示 #1.3.2 在庫不足品ﾘ ｽﾄを読む N.I.T. SoftLab #1.5 積荷票を受取る 積荷票 #1.4.1 出庫指示書を 出力 #1.5.1 積荷票 を入力 #1.5.2 在庫ﾌｧｲﾙ へ書込む 不足品出庫指示 #1.3.3 在庫ﾌｧｲﾙへ 書込む #1.3.4 不足品出庫指示 書を出力 26 経由ルート表(route)および最短合計時間表に，初期値0と∞をそれぞれ設定する． Pを始点ノードとする モジュール仕様図 Pが終点ノードと一致するまで --- ノードに到着したときの経過時間を比較する --Pに接続しているすべてのノードiについて モジュールはどのような機能 をもつか Pからノードiまでの時間をtimeとする ノードiまでの合計時間 > Pまでの合計時間 + time Yes --- Pを経由したルートの方が合計時間が短いので先に到着すべき --ノードiまでの合計時間を Pまでの合計時間 + timeにする ノードiの経由ノードをPとする No --- 次に計算を進めるべきノードの決定 --ネットワーク全体から経過時間の最も短いノードを選び出し，次に計算を進めるべき ノードをPとする． 経由ルート表(route)および最短合計時間表(totalTime)に，初期値0と∞をそれぞれ設定 する． Pを始点ノードとする Pが終点ノードと 一致するまで Pに接続するすべてのノー ドiについて Pからノードiまでの時間を timeとする ノードiまでの合計時間 > Pまで の合計時間 + time ネットワーク全体から経過時間の最も短い ノードを選び出し，次に計算を進めるべきノ ードPとする． N.I.T. SoftLab Y ①ノードiまでの合計時間を Pまで の合計時間+ timeにする． ②ノードiの経由ノードをPとする． 27 ◆ システム動作設計 push(X)／size’++; top’=X push(X)／size’++1; top’=X 空 /* Size = 0 */ 空でない /* Size > 0 */ top pop[size =1]／pop’=top; size’=0 pop[size =1]／pop’=top; size’-- 顧 客 南北方向 東西方向 赤 赤 レンタルショップ受付係 レンタル商品DB 売上DB レンタル注文 会員証提示要求 ④ ① 会員証提示 ③ 黄 黄 商品番号, 合計数記録 ② 記録完了 仮払売上金額の記録 記録完了 青 青 精算OK N.I.T. SoftLab 28 《 構造化分析設計まとめ 》 対応付けの指針はない 処理とデータの洗い出し データフロー図 データ辞書 具体的な機能構造 プロセス仕様書 モジュール構造図 データ構造図 モジュール仕様図 ER図 分析・設計間における視点の変換 動作設計 状態遷移図 ペトリネット イベントトレース図 N.I.T. SoftLab 29 オブジェクト指向分析設計（構造化分析設計との比較） オブジェクト指向分析設計の ドキュメント類 設計 順序 構造化分析のドキュメント類 クラス構造図 データフロー図 （クラスの種類と関連の記述） ER図 相互作用図 （オブジェクト間でやりとりされるメッセージ ＝メソッドの種類と順序の記述） 状態遷移図 振る舞い図 （各メソッド内，メソッド間の動作の記 述） N.I.T. SoftLab 30 ◆ オブジェクト指向分析設計の基本的な作業手順 スパイラル的に繰返し分析設計可能 ( 視点の変換が不要 ） オブジェクト間の相互作用 （メッセージのやり取り等） オブジェクト内部の振る舞い （ メッセージ到着等によって 起動される独自の内部動作列 ） ｵﾌﾞｼﾞｪｸﾄp 相互作用 ｵﾌﾞｼﾞｪｸﾄｓ ｵﾌﾞｼﾞｪｸﾄｑ ｵﾌﾞｼﾞｪｸﾄｒ ｸﾗｽA ｸﾗｽB N.I.T. SoftLab ｸﾗｽC 背後にあるオブジェクト の静的なクラス構造 31 ◆ UMLにおける分析ドキュメント類 ドキュメント型 ドキュメント種類 ① ユースケース図 記 述 内 容 ユーザがシステムと対話するときの一連の処理 ② 静的構造図 ・クラス図 ・オブジェクト図 クラスとクラス間の関連 特定の時点でのインスタンスの集合 ③ 振る舞い図 ・状態図 ・アクティビティ図 特定クラスに属するオブジェクトの状態遷移図 内部処理の制御の流れを表すワークフロー ④ 相互作用図 ・シーケンス図 ・協調図 オブジェクト間のイベントトレース図 オブジェクト間のメッセージのやり取り図 ⑤ 実装図 ・コンポーネント図 ・配置図 コンポーネント間の依存性図 コンポーネントやオブジェクトの計算資源の配置 顧客 １．注文 店員A：受付係クラス ２．有効期限（顧客名） ３．利用履歴（顧客名） 協調図 ４．陳列依頼 利用状況 店員B：倉庫係クラス N.I.T. SoftLab 32 ◆ オブジェクト指向によるソフトウェア開発の利点 クラスやオブジェクト間の関連（クラス図）ができ上がると，後はそれぞれの オブジェクトのメソッドを詳細化して行くだけでよい． しかし，逆に言えば、 『クラス図の良し悪しが開発システムの出来を決定する』 《 クラス図 》 《 オブジェクト図 》 ペット 0..* １ 愛称 1: 指示を出す お手 人 氏名 指示を出す ：人 お座り １ メソッド内容を段階的に 詳細化 2: お座り メソッドを次々と 追加 3: お手 ：ペット 0..2 家 N.I.T. SoftLab 33 ◆ 「クラスをいかに抽出するか」が最も重要な作業になる ただし，クラスにはいろいろな役割のものがあることに注意する 例えば，標準になっているMVCモデルでは・・・ データ格納庫 Modelクラス群 （データ） Viewクラス群 Controllerクラス群 （表示） （イベント制御） 外部から与える操作 GUI N.I.T. SoftLab 34 クラス抽出の代表的な手法 《 機能クラスを中心としたクラス抽出手法 》 (a) 責任駆動アプローチ 自分がシステムの中心的な人物（クラス）になったつもりで，他者に 対して，どのようなサービスの責任を負うかの観点から，擬人とし てのクラスを洗い出す（観察力と洞察力が必要） (b) ユースケースアプローチ システム外部から見たシステムに期待する機能をユースケース （利用方法）を列挙しながら洗い出す．名詞や動詞，副詞に注目 してクラスやメソッドを抽出してゆく． 《 データ格納クラスを中心としたクラス抽出手法 》 見当たらない！！ N.I.T. SoftLab 35 (a) 責任駆動アプローチによるクラス抽出 CRC(Class,Responsibility,Collaboration)カード カードを利用した発想法 （KJ法）的なクラスの抽出 クラス名 受けもつ責任 (Responsibility) 関連するクラス (Collaboration) ※ どうしても，XXマネージャと いったクラスが多くなる アクション イベント 表示スクリーン 状態の応答待ち カード読取機 ハードからユーザインタ 現金支払機 リモートDB フェースの分離 イベント リモートDB アカウント トランザクション トランザクションの記録 アカウント 状態の応答 トランザクション 検証と金の移動 オーディットの保持 カード読取機 現金支払機 リモートDB アクション アカウント アカウント 収支と記録の保持 トランザクション 表示スクリーンの順序」 表示スクリーン 現金支払機 トランザクション トランザクション組立て 現金の支払い イベント 成功か空かシグナル カード読取機 磁気コードの解読 トランザクション イベント シグナルの挿入 表示スクリーン 確認の表示 アクションへのイベント の通知 トランザクション イベント トランザクション N.I.T. SoftLabリモートDB 36 (b) ユースケースアプローチ 受付システム アクタ 顧客 アクタ 受付係 注文する 会員を確認する レンタル伝票を作成する シナリオを起動する きっかけを与える 仮精算をする 商品を渡す 商品の陳列を依頼する アクタ 倉庫係 商品を陳列する ユースケース名 ： アクタ ： システム外部からシステムに働き掛ける動作主体を記述する． 目 的 ： シナリオの目的を記述する． 事前条件 ： シナリオが起動するための条件を記述する． 基本系列 ： システムとの対話の事象列を記述する． ： 事後条件 ： シナリオによる処理が完了したときに成立しているべき条件を記述する． ① 基本系列を短文に分解し名詞，動詞，副詞を見出す． ② 名詞，動詞，副詞等をオブジェクト，メソッド，属性，イベントに対応つける． N.I.T. SoftLab 37 《 代表的なオブジェクト指向クラス抽出手法のまとめ 》 （１） クラスが提供すべきサービス(インタフェース）を中心に 経験と“ひらめき”によってクラスを抽出する. （ただし，“ひらめく”ためのガイドラインは多少ある）． （２） 詳細なメソッドは“イベントの発生”に注目して決定する． （３） サービスは往々にして変化するため分析の判断基準を 設けることが困難になっている． （４） データ格納クラスに関する分析は軽視している． N.I.T. SoftLab 38 DATARUN分析設計法 （モデル中心アプローチ） データベースを中心とした情報システムに特化した方法論 構造化分析のドキュメント類 DATARUNのドキュメント類 拡張データフロー図：BPM データフロー図 分析の中心 システム起動のきっかけ(PDG） の洗い出し プロセスとデータの洗い出し 拡張ER図（クラス構造図）：ERM ER図 分析の中心 データ構造と関連の洗い出し 画面遷移図（CDM+α） 状態遷移図 システム動作の決定 N.I.T. SoftLab 39 特徴 （１） BPMで基本データが記載された入力帳票類を見出す （構造化分析の発想） （２） クラスは帳票類から抽出した基本データを整理分類した 入れもの（データ中心的な発想）． （３） PDGを基準にして，基本データを整理分類する （オブジェクト指向の基本概念の利用）． [指針] 初期値の決定時点が同じ属性は，同じクラスに属すべき （４） Modelクラスに手順を追加してゆく（オブジェクト指向的 な発想） N.I.T. SoftLab 40 ◆ 分析の判断基準PDG （＝基本データ発生のきっかけとなるタイミング） (a) 悪い抽出例 商 品 商品説明 販売価格 商品仕入番号 統一商品コード (b) 良い抽出例 商品情報 商品説明 販売価格 統一商品コード なぜ（ｂ）がよくて（a）が悪い のかが判断できる 記録する 1 ＊ 商 品 商品仕入番号 N.I.T. SoftLab 41 《 DATARUNのまとめ 》 （１） クラスを抽出する明確な判断基準がある（PDG） （２） 業務レベルでの発生イベントに着目している． （３） Modelクラスの抽出に重点を置いている． Modelクラス群 データ格納庫 （データ） Viewクラス群 Controllerクラス群 （表示） （イベント制御） 外部から与える操作 GUI N.I.T. SoftLab 42 ５. 適用分野から見た比較 システム分野 着目する基本要素 機能 データ 状態 イベント 視点の理 解容易性 明確な判 断基準 情報システム系【 ３層モデルのとき 】 OOA ① ユーザインタフェース ② Ｃ／Ｓアプリケーションサービス DATARUN DATARUN ③ データベースサービス DATARUN DATARUN 組込みシステム系 OOAD リアルタイム制御システム系 OOAD Webシステム系 N.I.T. SoftLab 43 情報システム開発向けの方法論は？ [基準1] 方法論の着眼点が理解しやすいか？ DATARUN ＞ OOAD [基準2] 判断基準が明確か（イベント） ？ DATARUN ＞ OOAD ※ 画面操作の詳細な分析設計 DATARUN ＜ OOAD N.I.T. SoftLab 44 組込みシステム開発向けの方法論は？ [基準1] 方法論の着眼点が理解しやすいか？ DATARUN ＜ OOAD [基準2] 判断基準が明確か（イベント）？ DATARUN ＜ OOAD 制御システム開発向けの方法論は？ [基準1] 方法論の着眼点が理解しやすいか？ DATARUN ＜ OOAD [基準2] 判断基準が明確か（イベント）？ DATARUN ＜ N.I.T. SoftLab OOAD 45 ６. 効果的な使い分け方法 データ収集の必要性 操作の中心：データ｜機能 データベース接続 OOA/OOD 特に前提としない DATARUN 既存の入力帳票の 収集が必要 複雑な機能 特に前提としない データ あり ※ 留意点： システムの変化に対応して方法論も進化する． N.I.T. SoftLab 46 企業毎に主に用いる方法論 構造化分析設計法 バッチ処理的な従来型 システムのとき データ中心分析設計法 データベースを中心にした 従来型システムのとき オブジェクト指向 分析 設計法 GUIをベースにしたデータ 入力・表示方法が必要な とき(例えば,webアプリ ケーション） DATARUN分析設計法 データベースとGUI表示を 併せもつシステムのとき ● 基本は使い分けること． プログラマ ： 1つのプログラミング言語しかしらない ＜＝ 失格 SE ： 1つの方法論しか知らない ＜＝ 失格 N.I.T. SoftLab 47 ７. 将来への可能性（研究テーマに関する余談） DATARUN分析設計法を参考にして，分析の３つの判断基準 の延長にあるものを考えると・・・ ３つの分類基準 【 分類基準C1 】 初期値決定時点の同時性 初期値が決定される時点ｔ0が同一の基本データdiは，同じ概念に属する 属性とする． 【 分類基準C2 】 実現値の構造性 多値や選択的に実現値が決まる基本データは，単値基本データと混在 する形で概念の属性となりえない．別の概念の属性として分離しなけれ ばならない． 【 分類基準C3 】 初期値の決定状況単一性 初期値の決定時点が複数の状況に依存する基本データは，状況によっ て一意的に決まる初期値の決定時点をもった概念の上位概念に属する 属性である． N.I.T. SoftLab 48 ● ３つの分類基準を用いた概念モデル抽出の具体例 (注) * ○ Ref … 繰返し構造をもつ … 実現値が決定する … 他の事象で決められた実現値を参照する 分析の最初の焦点＝ 実現値決定のタイミング分析 分離 導出データ N.I.T. SoftLab 49 最終的に抽出された概念モデル 注文 注文日付 注文番号 0..* 注文―顧客 1 1 注文―明細 1..* 明細 明細番号 注文数 0..* 1 注文―商品 顧客 顧客番号 顧客名 住所 電話番号 顧客登録日付 営業担当者 商品 商品番号 商品名 商品単価 商品登録日付 仕切り率 ただし，結合度の決定，自己参照的な関連の決定方法等に いくつかの課題が残っている N.I.T. SoftLab 50 デザインパターン形成プロセスのモデル化に向けて 《 アナロジー 》 いろいろな性質をもつ物質が なぜ存在するのか 元素の周期律表 未知なる物質の もつ性質が予測 可能になった！ 理論的な説明と分類 （1） 原子の概念と構成する要素 原子のもつ電荷量＆電子の離散的なエネルギーレベル （2） 相互作用の法則と安定状態の概念 固有で安定的なエネルギーレベルとその間での状態遷移 N.I.T. SoftLab 51 同様な発想でデザインパターン形成プロセスを モデル化できないか？ いろいろなパターンの存在 モデル化された デザインパターン形成プロセス ①未知なるパターンの存在 や性質が導出できる ②容易にデザインパターン をいろいろな局面に適用 できる 理論的な説明 （1） 設計を構成する基本的な構成要素 （2） 判断基準と構成要素の安定状態の概念 N.I.T. SoftLab 52
© Copyright 2024 ExpyDoc
