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

N.I.T. SoftLab　 1

DATARUN と他の方法論の比較と

　　　　　　　　特徴を生かした使いこなし方

日本工業大学　工学部情報工学科

大木　幹雄http://uhura.nit.ac.jp/~ohki/

N.I.T. SoftLab　 2

簡単な自己紹介簡単な自己紹介

1969 年：　日本電子計算（株）入社1976 年以降：

一貫してソフトウェア開発支援ツール，環境整備に従事．通産省主導特別プロジェクト「保守技術開発計画－ COBOL データフロー解析支援ツール」

（ UNIX ， C)

「形式的仕様技術開発計画－図式分析支援ツール」（ Smalltalk80)

「システムインテグレーション基盤技術開発計画」（ UNIX ， C)

その後，オブジェクト指向開発コンサルティング等を経て1996 年より日本工業大学情報工学科助教授

専門：データベース，ソフトウェア工学，プログラム設計開発･（ C++)

著書： “データベース設計の基礎”，“ソフトウェア設計の基礎”，

“ プログラム設計と開発”　（日本理工出版会）

N.I.T. SoftLab　 3

現在の主な研究テーマ

(１ )　ソフトウェア分析設計モデリング基準の導出とモデリング支援ツール開発

※ DATARUN ，オブジェクト指向分析等のソフトウェア分析設計におけるモデリング

基準の比較評価．（きっかけ：せめて方法論ぐらいは米国の属国にならなくても

いいのでは．まずはいろいろな方法論を比較評価してみたい）

(３ )　不確定な繰返しを含む開発プロセス管理手法の開発と分散プロジェクト管理への適用実験

※ ソフトウェア開発は本質的に不確定性を含むことを前提にして，手戻りが頻繁に

発生するスポット的なソフトウェア開発の管理方法を理論化すること．

(２ )　デザインパターン生成プロセスのダイナミックモデル作成，およびパターン適用支援ツール開発

※ デザインパターンの生成プロセスを場の量子論的な見地からモデル化し，デザイン

パターンの背後にある特性を明らかにしながら，適用判断基準を導出すること．

N.I.T. SoftLab　 4

講演　概要

１．方法論の役割　

２．方法論を比較評価する視点

３． SE 初等教育における判断基準の重要性【事例】４．いろいろな方法論の簡単なレビュー

５．適用分野から見た比較

６．効果的な使い分け方法

７．将来への可能性

N.I.T. SoftLab　 5

１．　方法論の役割１．　方法論の役割

●　最も重要なのは分析設計の視点を与えてくれること．

●　システムに対するユーザの視点から，プログラムの視点まで，視点を変換してゆくプロセスを与えること．　　　

基本的に，詳細な実装上の問題点はその都度考えるべき事項

N.I.T. SoftLab　 6

●　方法論に絶対的なものは存在するか？システムの特徴によって，どの方法論が向いている・いないかの“比較の問題”にすぎないのでは？

２．　方法論を比較評価する視点２．　方法論を比較評価する視点

・一神教　　 VS 多神教・集権化　　 VS 分散化・統合化　　 VS 分社化・統一化　　 VS 個別化　　　　　　　　　：

※ 　類似する“悩ましき比較” の問題

N.I.T. SoftLab　 7

過去の AI 分野において起こった一神教と多神教の争い

「知識と推論を統合しよう」派

「知識と推論は使い分けよう」派

●第 5世代コンピュータ開発機構述語論理（ Prolog ）

＋オブジェクト指向＋並列処理

●フレーム理論＋ルールベース推論

●フレーム理論＋オブジェクト指向＋ルールベース推論

●オブジェクト指向＋述語論理(Prolog)

　　　　　　　　　

●ジェネリックタス( Chandrasekaran が提唱）

いろいろな知識や推論を統一させることが，有用性をもつことだ！いろいろな知識や推論を統一させることが，有用性をもつことだ！

活動領域に特有な６つの知識構造と推論方法をもつ

(1) 状況を要素と可能性から分類学的に分類する．

(2) ある状態変化があったとき，それに対応してシステム内で必要な変化を与える．

(3) データの属性が与えられたとき，概念的に関連する　　　属性を見出す．

(4) なんらかのプランにしたがって，制約条件を満たしながらオブジェクトを合成し，洗練化する．

(5) 仮説と問題の状態が与えられたとき，仮説が状況的　　　にマッチするかを決定する．

(6) 状況と信念に基づいた仮説と仮説を用いて説明できるデータがあったとき，それらを筋道たって説明できるような仮説を作成する．

知識は役割と状況毎に使い分けることが有用性をもつことだ！知識は役割と状況毎に使い分けることが有用性をもつことだ！

N.I.T. SoftLab　 8

●“悩ましき比較問題”の原因になるいくつかのポイント

①　全体効率性から見てどうなのか

単純な構成の方が全体を効率化しやすいか

構成を役割毎に分けた方が全体を効率化しやすいか

②　問題への対応性から見てどうなのか

③　変化に対する柔軟性・リスクから見てどうなのか

　　　　　　　　　　　　　〃

　　　　　　　　　　　　　〃

「集権化 VS 分散化」　「統一化 VS 個別化」等の問題では・・・

N.I.T. SoftLab　 9

“悩ましき比較問題”に対する一般的な対処方法

ωi fiei

（３）　基準にしたがって各特性を評価（３）　基準にしたがって各特性を評価 δij （ ei ，

fj ）

問題毎に総合評価点を出し結論を出す

問題毎に総合評価点を出し結論を出す

gj=Σωi δij

(１ )　評価側面の優先度付けと比較基準の設定

(１ )　評価側面の優先度付けと比較基準の設定

(２ )　問題を構成する特性の洗い出し

(２ )　問題を構成する特性の洗い出し

N.I.T. SoftLab　 10

同様に“方法論の比較”に機械的に適用してみる

(１ )　方法論を評価する側面の優先度付けと比較の基準を設定する

(１ )　方法論を評価する側面の優先度付けと比較の基準を設定する

(２ )　“方法論”を構成する特性を洗い出す

(２ )　“方法論”を構成する特性を洗い出す

（３）　基準にしたがって各特性を評価する（３）　基準にしたがって各特性を評価する

“ 方法論”毎に総合評価点を出し

結論を出す

“ 方法論”毎に総合評価点を出し

結論を出す評価には主観が入るのでどこまで信用できるかわからない！


方法論を比較評価する側面

(a) 　管理的な側面

(b) 　技術的な側面

方法論の特性・構成要素

(a) 　システムの基本的な構成要素

　　　 (b) 　対象システムの分野関連あり

１１

２２

そこで，できるだけ分析的に評価を試みてみる


①　全体の効率性に関して・開発工期が短縮されるか？・理解が容易になるか？・コミュニケーションが円滑になるか？・社内教育が容易になるか？・社外からの情報も入手しやすくなるか？　 etc

②　問題への対応性に関して・困ったとき相談できる相手が多くなるか？・トラブル発生時の責任追及に対して安心感が増すか？

　・運用が容易になるか？　 etc

③　変化に対する柔軟性・変化へのリスクに関して・方法論と運命を共にするリスクが増すか？従来の考え方を大幅に変える必要がないか？･・自分の声が反映される機会が増えるか？ etc

(a) 　管理的な側面

１１

方法論を比較評価する側面


(b) 　技術的な側面

①　理解性誰にでも容易に手順が理解できるか？

②　明瞭性分析の判断基準が明確か？

③　厳密性方法に矛盾する点はないか？

④　形式性記述が容易で，意味が一意的か？

⑤　伝達性容易に伝達できるか？

特に重視

今回は，こちらに重点をおく

どの方法論も通常満たしている


方法論の特性・構成要素

　　　機能　　　機能　　イベント　（きっかけ）

　　イベント　（きっかけ）

　　　　　　　　

　　　データ　　　データ

状態

２２

(a) 　分析設計で考えるシステムの基本的な構成要素


※ 　システムの構成要素と代表的な方法論の関係

　構造化分析設計法　構造化分析設計法

　データ中心分析設計法　データ中心分析設計法

　オブジェクト指向分析設計法　オブジェクト指向分析設計法

DATARUN 分析設計法 DATARUN 分析設計法

方法論名分析の主たる着目点

●機能モジュール構造

●実体属性関連構造ｰｰ

●クラス構造，協調関係状態遷移関係

●実体属性関連構造ｰｰ画面遷移構造


情報システム系【３層モデルのとき】

組込みシステム系

リアルタイム制御システム系

Web システム系

③ データベースサービス

② Ｃ／Ｓアプリケーションサービス

① ユーザインタフェース

(b) “対象システムの分野”とシステムの構成要素との関連

機能データ状態イベント

着目する基本要素システム分野


[ 評価基準 1]

分析の視点が理解しやすいか？[ 評価基準 1]

分析の視点が理解しやすいか？機　能機　能

データデータ

状　態状　態

イベント

イベント

[ 評価基準 2]

分析設計の手順や判断基準が明確か？[ 評価基準 2]

分析設計の手順や判断基準が明確か？

方法論の比較はシステムの構成要素毎に以下の評価基準に対する比較順位の問題になる！

構成要素


（ 1 ）　属性と属性実現値の混同（　最も初歩的誤り。それでも２５％の学生が間違える　）

　ジャンル

アクションコメディSF ファンタジー　　　：

　　ジャンルジャンル番号ジャンル名

【事例】“ データベース設計演習” の概念モデル作成演習

をもとに行った概念モデリングの誤り分析

３．　 SE 初等教育における判断基準の重要性３．　 SE 初等教育における判断基準の重要性


　　レース　レース番号レース名日付

　競走馬　馬番号馬名

　　騎手　騎手番号騎手名

出走 0..*

0..*

1着順

タイム

（ 2）　概念がもつ属性と関連がもつ属性の混同（　ERモデルを多少記述できる者の誤り。１３％が間違える　）


　　明細明細番号数量単価

1 1..*　　　見積見積番号見積日付

（ 3）　関連の多重度や識別子依存性の誤り（　ERモデルを理解しはじめた者の誤り。６７％が間違える　）


①　概念固有の属性以外の混入

　　　売上　日付売上管理番号担当者

　　　売上　日付売上管理番号

　　担当者　従業員番号氏名入社年

0..*1

“売上”に固有の属性でない

　　商品商品番号　商品名値引率

②　属性と概念の混同　

　　値引きランク番号有効期間値引率

　　商品商品番号　商品名

0..* 1

“商品”に固有の属性でなくむしろ“値引き”の属性にすべき

（ 4）　異なるカテゴリの属性の混入（　レベルに関係なく発生。８８％の学生が間違える　）


● 分析設計の具体的な視点と理解しやすい判断基準がない．

《原因分析のまとめ》

● 業務経験や概念モデリングの知識が少ないものにとって業務で用いる“概念 ( 実体型）”を何の指針もなく思い浮かべることは困難である．

重要


構造化分析設計法

４．　いろいろな方法論の簡単なレビュー４．　いろいろな方法論の簡単なレビュー

オブジェクト指向分析設計法

DATARUN 分析設計法 (モデル中心アプローチ）

　　　　実質，データ中心＋オブジェクト指向


構造化システム分析

　データフロー図

　　 ER 図

プロセス仕様書プロセス仕様書

データ辞書

【データ分析】　【性能・信頼性分析】

【システム要求分析】

データ構造図データ構造図

データ名 1

データ名 2入力データ名 1

外部名ｴﾝﾃｨﾃｨ外部名ｴﾝﾃｨﾃｨ名ﾌﾟﾛｾｽ

2

データ名 3

名ﾌﾟﾛｾｽ1

　実体名１基本名ﾃﾞｰﾀ 1

基本名ﾃﾞｰﾀ 2

　実体名 2




関連名 1

1

0..*

どんなプロセス（処理）やデータが必要か

どのようにデータをまとめるか，　　　　　関連があるか

　ストア名



IPO による処理内容の記述例記入日　 XXレベル１．

5最短経路を求めるﾊﾞｰｼﾞｮﾝ 1.0 記入者大木

　入力 (I) 処理 (P) 出力 (O)

I1 ．ノード表

I2 ．各リンクの

両端ノード

I3 ．リンク間距離

I4 ．出発ノードと

到着ノード

1 ．最短経路

2．最短距離

1 ．ノード毎に結ばれている他のノードとそのノードまでの距離を記録する形式でデータを整理する

2．出発ノードから走者（あるいはトークン）を逐次進め進んできた経路を記録する

3．最も短い距離を走ってきた走者の記録が最短経路である


並び換えデータ

並び換え要素 *

並び換えキーレコードポインタ

繰り返し

連絡先

自宅電話番号携帯電話番号

選択


モジュール構造図モジュール構造図モジュール仕様図モジュール仕様図

【ソフトウェア設計】　　

【入出力設計】【データベース設計】

【性能・信頼性設計】

#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出庫不可の出庫依頼を記録

構造化システム設計

どのようなモジュール構造をもつか


経由ルート表 (route) および最短合計時間表 (totalTime) に，初期値 0 と∞をそれぞれ設定する．

P を始点ノードとする

P が終点ノードと一致するまで

P に接続するすべてのノード i について

P からノード i までの時間をtime とする

ノード i までの合計時間 > Pまでの合計時間　 + time

ネットワーク全体から経過時間の最も短いノードを選び出し，次に計算を進めるべきノード P とする．

Y ①ノード i までの合計時間を P までの合計時間 + time にする．②ノード i の経由ノードを P

とする．

経由ルート表 (route) および最短合計時間表に，初期値 0 と∞をそれぞれ設定する．

モジュール仕様図モジュール仕様図

モジュールはどのような機能をもつか

P を始点ノードとする

P が終点ノードと一致するまで

--- ノードに到着したときの経過時間を比較する ---P に接続しているすべてのノード i について

P からノード i までの時間を time とする

--- P を経由したルートの方が合計時間が短いので先に到着すべき ---ノード i までの合計時間を P までの合計時間 + time にするノード i の経由ノードを P とする

--- 次に計算を進めるべきノードの決定 ---ネットワーク全体から経過時間の最も短いノードを選び出し，次に計算を進める

べきノードを P とする．

ノード i までの合計時間 > P までの合計時間 + timeYes No


　空でない　 /* 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


イベントトレース図

ペトリネット


モジュール構造図モジュール構造図データフロー図

　　 ER 図


データ辞書

分析・設計間における視点の変換

　状態遷移図

動作設計

モジュール仕様図モジュール仕様図

《　構造化分析設計まとめ　》

処理とデータの洗い出し具体的な機能構造

対応付けの指針はない


オブジェクト指向分析設計（構造化分析設計との比較）

状態遷移図

ER 図

構造化分析のドキュメント類

データフロー図

（各メソッド内，メソッド間の動作の記述）

（オブジェクト間でやりとりされるメッセージ＝メソッドの種類と順序の記述）

相互作用図

振る舞い図

クラス構造図

オブジェクト指向分析設計のドキュメント類

（クラスの種類と関連の記述）

設計順序


◆ 　オブジェクト指向分析設計の基本的な作業手順

ｵﾌﾞｼﾞｪｸﾄ p

ｒｵﾌﾞｼﾞｪｸﾄｓｵﾌﾞｼﾞｪｸﾄ

ｸﾗｽ B

ｸﾗｽ A

相互作用

ｸﾗｽ C

背後にあるオブジェクトの静的なクラス構造

オブジェクト間の相互作用（メッセージのやり取り等）

スパイラル的に繰返し分析設計可能　 (　視点の変換が不要　）

オブジェクト内部の振る舞い（メッセージ到着等によって起動される独自の内部動作列）

ｑｵﾌﾞｼﾞｪｸﾄ


・クラス図・オブジェクト図

・状態図・アクティビティ図

・シーケンス図・協調図

・コンポーネント図・配置図

・クラス図・オブジェクト図

・状態図・アクティビティ図

・シーケンス図・協調図

・コンポーネント図・配置図

ユーザがシステムと対話するときの一連の処理

クラスとクラス間の関連特定の時点でのインスタンスの集合

特定クラスに属するオブジェクトの状態遷移図内部処理の制御の流れを表すワークフロー

オブジェクト間のイベントトレース図　オブジェクト間のメッセージのやり取り図

コンポーネント間の依存性図コンポーネントやオブジェクトの計算資源の配置

ユーザがシステムと対話するときの一連の処理

クラスとクラス間の関連特定の時点でのインスタンスの集合

特定クラスに属するオブジェクトの状態遷移図内部処理の制御の流れを表すワークフロー

オブジェクト間のイベントトレース図　オブジェクト間のメッセージのやり取り図

コンポーネント間の依存性図コンポーネントやオブジェクトの計算資源の配置

① ユースケース図

② 静的構造図

③ 振る舞い図

④ 相互作用図

⑤ 実装図

① ユースケース図

② 静的構造図

③ 振る舞い図

④ 相互作用図

⑤ 実装図

ドキュメント型

◆ UML における分析ドキュメント類

顧客

店員 A ：受付係クラス１．注文

店員 B ：倉庫係クラス

　　利用状況

２．有効期限（顧客名）

３．利用履歴（顧客名）

４．陳列依頼協調図

ドキュメント種類記　述　内　容


◆ 　オブジェクト指向によるソフトウェア開発の利点　クラスやオブジェクト間の関連（クラス図）ができ上がると，後はそれぞれのオブジェクトのメソッドを詳細化して行くだけでよい．しかし，逆に言えば、

『クラス図の良し悪しが開発システムの出来を決定する』

2: お座り　　：人　　：人

　　：ペット　　：ペット

1: 指示を出す

3: お手

　　ペット愛称お手お座り

　　ペット愛称お手お座り

１

0..*

１

　　家0..2

　　人　

氏名指示を出す

　　人　

氏名指示を出す

メソッドを次々と追加

メソッド内容を段階的に詳細化

《　クラス図　》

《　オブジェクト図　》


◆ 　「クラスをいかに抽出するか」が最も重要な作業になる

Model クラス群

（データ）

Model クラス群

（データ）

View クラス群

（表示）

View クラス群

（表示）Controller クラス群

（イベント制御）

Controller クラス群


ただし，クラスにはいろいろな役割のものがあることに注意する

例えば，標準になっているMVCモデルでは・・・

GUI 外部から与える操作

データ格納庫


クラス抽出の代表的な手法

(a) 　責任駆動アプローチ　

《　機能クラスを中心としたクラス抽出手法　》

(b) 　ユースケースアプローチ　

自分がシステムの中心的な人物（クラス）になったつもりで，他者に対して，どのようなサービスの責任を負うかの観点から，擬人としてのクラスを洗い出す（観察力と洞察力が必要）

システム外部から見たシステムに期待する機能をユースケース（利用方法）を列挙しながら洗い出す．名詞や動詞，副詞に注目してクラスやメソッドを抽出してゆく．《　データ格納クラスを中心としたクラス抽出手

法　》見当たらない！！


クラス名受けもつ責任(Responsibility)

関連するクラス(Collaboration)

CRC(Class,Responsibility,Collaboration)カードカードを利用した発想法（ KJ法）的なクラスの抽出

アクション

表示スクリーンの順序」

トランザクション組立て

トランザクション表示スクリーン

イベント

状態の応答待ち

ハードからユーザインタフェースの分離

表示スクリーンカード読取機現金支払機リモート DB

リモート DB

アカウント

トランザクションの記録

状態の応答

イベントトランザクションアカウント

現金支払機

現金の支払い

成功か空かシグナル

トランザクションイベント

カード読取機

磁気コードの解読

シグナルの挿入


トランザクション

検証と金の移動

カード読取機現金支払機リモート DB

アクションアカウント

オーディットの保持

表示スクリーン

確認の表示アクションへのイベント　　　　の通知


アカウント

収支と記録の保持トランザクション

リモート DB

(a) 　責任駆動アプローチによるクラス抽出

※ どうしても， XX マネージャといったクラスが多くなる


(b) 　ユースケースアプローチ　

アクタ　倉庫係

注文する

レンタル伝票を作成する

仮精算をする

アクタ　顧客

商品を渡す

商品を陳列する

商品の陳列を依頼する

アクタ　受付係受付システム

会員を確認する

ユースケース名：アクタ：システム外部からシステムに働き掛ける動作主体を記述する．目　　的：シナリオの目的を記述する．事前条件：シナリオが起動するための条件を記述する．基本系列：システムとの対話の事象列を記述する．　　　　　　　　　　　　　：事後条件：シナリオによる処理が完了したときに成立しているべき条件を記述する．

①　基本系列を短文に分解し名詞，動詞，副詞を見出す．

②　名詞，動詞，副詞等をオブジェクト，メソッド，属性，イベントに対応つける．

シナリオを起動するきっかけを与える


《代表的なオブジェクト指向クラス抽出手法のまとめ》

（１）クラスが提供すべきサービス ( インタフェース）を中心に経験と“ひらめき”によってクラスを抽出する .

（ただし，“ひらめく”ためのガイドラインは多少ある）．

（３）サービスは往々にして変化するため分析の判断基準を設けることが困難になっている．

（４）データ格納クラスに関する分析は軽視している．

（２）詳細なメソッドは“イベントの発生”に注目して決定する．


DATARUN 分析設計法　（モデル中心アプローチ）

拡張 ER 図（クラス構造図）： ERM

拡張データフロー図： BPM

画面遷移図（ CDM+α ）

データベースを中心とした情報システムに特化した方法論

状態遷移図

ER 図

構造化分析のドキュメント類

データフロー図

DATARUNのドキュメント類

プロセスとデータの洗い出し

データ構造と関連の洗い出し

システム動作の決定

システム起動のきっかけ (PDG ）の洗い出し

分析の中心

分析の中心


特徴

（２）クラスは帳票類から抽出した基本データを整理分類した入れもの（データ中心的な発想）．

（３） PDG を基準にして，基本データを整理分類する（オブジェクト指向の基本概念の利用）．

（４） Model クラスに手順を追加してゆく（オブジェクト指向的な発想）

[ 指針 ] 　初期値の決定時点が同じ属性は，同じクラスに属すべき

（１） BPM で基本データが記載された入力帳票類を見出す（構造化分析の発想）


　　　商　品商品説明販売価格商品仕入番号統一商品コード

(a) 悪い抽出例

　　商　品商品仕入番号

　　商品情報商品説明販売価格統一商品コード

1＊

記録する(b) 良い抽出例

◆ 　分析の判断基準 PDG （＝基本データ発生のきっかけとなるタイミング）

なぜ（ｂ）がよくて（ a ）が悪いのかが判断できる


《 DATARUNのまとめ》

（１）　クラスを抽出する明確な判断基準がある（ PDG ）

Model クラス群

（データ）

Model クラス群

（データ）

View クラス群

（表示）

View クラス群

（表示）Controller クラス群


Controller クラス群


GUI 外部から与える操作

データ格納庫

（３）　 Model クラスの抽出に重点を置いている．

（２）　業務レベルでの発生イベントに着目している．


５ . 　適用分野から見た比較５ . 　適用分野から見た比較

情報システム系【３層モデルのとき】

組込みシステム系

リアルタイム制御システム系

Web システム系

③ データベースサービス

② Ｃ／Ｓアプリケーションサービス

① ユーザインタフェース

機能データ状態イベント着目する基本要素システム分野

視点の理解容易性

明確な判断基準

DATARUN

DATARUN

DATARUN

DATARUN

OOAD

OOAD

OOA


情報システム開発向けの方法論は？

[ 基準 1] 　方法論の着眼点が理解しやすいか？[ 基準 1] 　方法論の着眼点が理解しやすいか？

[ 基準 2] 　判断基準が明確か（イベント）？[ 基準 2] 　判断基準が明確か（イベント）？

※ 　画面操作の詳細な分析設計

DATARUN ＞OOAD

DATARUN ＞OOAD

DATARUN ＜ OOAD


組込みシステム開発向けの方法論は？



DATARUN ＜OOAD

DATARUN ＜OOAD

制御システム開発向けの方法論は？



DATARUN ＜OOAD

DATARUN ＜OOAD


６ . 　効果的な使い分け方法６ . 　効果的な使い分け方法

DATARUN

OOA/OOD

既存の入力帳票の収集が必要

特に前提としない

データ収集の必要性

データ

複雑な機能

操作の中心：データ｜機能

あり

特に前提としない

データベース接続

※ 　留意点：　システムの変化に対応して方法論も進化する．


　企業毎に主に用いる方法論　企業毎に主に用いる方法論

構造化分析設計法構造化分析設計法オブジェクト指向分析設計法

オブジェクト指向分析設計法

データ中心分析設計法データ中心分析設計法

DATARUN分析設計法DATARUN分析設計法

データベースを中心にした従来型システムのとき

GUI をベースにしたデータ入力・表示方法が必要なとき ( 例えば ,web アプリケーション）

バッチ処理的な従来型システムのとき

データベースと GUI表示を併せもつシステムのとき● 基本は使い分けること．

プログラマ： 1つのプログラミング言語しかしらない　＜＝　失格

SE ： 1つの方法論しか知らない　＜＝　失格


７ . 　将来への可能性（研究テーマに関する余談）７ . 　将来への可能性（研究テーマに関する余談）

３つの分類基準

【　分類基準 C1 】初期値決定時点の同時性

初期値が決定される時点ｔ 0 が同一の基本データ di は，同じ概念に属する属性とする．【　分類基準 C2 】実現値の構造性

多値や選択的に実現値が決まる基本データは，単値基本データと混在する形で概念の属性となりえない．別の概念の属性として分離しなければならない．

DATARUN 分析設計法を参考にして，分析の３つの判断基準の延長にあるものを考えると・・・

【　分類基準 C3 】初期値の決定状況単一性

初期値の決定時点が複数の状況に依存する基本データは，状況によって一意的に決まる初期値の決定時点をもった概念の上位概念に属する属性である．


(注 )* … 　繰返し構造をもつ○ … 　実現値が決定するRef … 　他の事象で決められた実現値を参照する

●　３つの分類基準を用いた概念モデル抽出の具体例

導出データ

分離

分析の最初の焦点＝実現値決定のタイミング分析


注文―明細

注文―顧客

1..*

1

1

0..*

注文―商品

　　顧客顧客番号顧客名住所電話番号顧客登録日付営業担当者

　　商品商品番号商品名商品単価商品登録日付仕切り率

　　注文注文日付注文番号

　　明細明細番号注文数

10..*

最終的に抽出された概念モデル

ただし，結合度の決定，自己参照的な関連の決定方法等にいくつかの課題が残っている


　　

元素の周期律表

　　

元素の周期律表

デザインパターン形成プロセスのモデル化に向けて

（ 1 ）　原子の概念と構成する要素原子のもつ電荷量＆電子の離散的なエネルギーレベル

（ 2 ）　相互作用の法則と安定状態の概念固有で安定的なエネルギーレベルとその間での状態遷

移

いろいろな性質をもつ物質が　　なぜ存在するのか

理論的な説明と分類

未知なる物質のもつ性質が予測可能になった！

《　アナロジー》


　　　　　　　　　　　　

モデル化されたデザインパターン形成プロセス

　　　　　　　　　　　　

モデル化されたデザインパターン形成プロセス

（ 1 ）　設計を構成する基本的な構成要素

（ 2）　判断基準と構成要素の安定状態の概念

同様な発想でデザインパターン形成プロセスを　　　　　　　　　　　　　　　　　　モデル化できないか？　

①未知なるパターンの存在や性質が導出できる

②容易にデザインパターンをいろいろな局面に適用できる

いろいろなパターンの存在

理論的な説明

Documents

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

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