DATARUN と他の方法論の比較と特徴を生かした使いこなし方

DATARUNと他の方法論の比較と 特徴を生かした使いこなし方日本工業大学　工学部情報工学科大木　幹雄 http://uhura.nit.ac.jp/~ohki/ N.I.T. SoftLab　

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

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

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

１．　方法論の役割 ●　最も重要なのは分析設計の視点を与えてくれること． ●　システムに対するユーザの視点から，プログラムの視点まで，視点を変換してゆくプロセスを与えること．　　　基本的に，詳細な実装上の問題点はその都度考えるべき事項 N.I.T. SoftLab　

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

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

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

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

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

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

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

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

２方法論の特性・構成要素 (a)　分析設計で考えるシステムの基本的な構成要素状態データイベント　（きっかけ）機能 N.I.T. SoftLab　

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

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

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

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

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

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

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

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

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

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

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

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

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

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　

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DATARUN と他の方法論の比較と特徴を生かした使いこなし方