構造化分析とシステム仕様―目指すシステムを明確にするモデル化技法
- 作者: トムデマルコ,Tom Demarco,高梨智弘,黒田順一郎
- 出版社/メーカー: 日経BP出版センター
- 発売日: 1994/09
- メディア: 単行本
- 購入: 13人 クリック: 73回
- この商品を含むブログ (40件) を見る
前々から読みたいと思っていた本、ようやく読めた。
色んなヒント満載。
オススメです。
てか、名著と言われるような本なので、私が勧めるまでもないんですが。
本書の中心にドンと据えられているのがDFD(データフローダイアグラム)。
DFDは「データフロー」「プロセス」「ファイル(DB)」「データの源泉と吸収」で構成される。
データフローは矢印、
プロセスは円、
ファイルは直線、
データの源泉と吸収は四角で表す。
DFDは段階的に詳細化する。
例えばProcess1を詳細化。
Process1の入出力データフローと
矛盾しないように詳細化する。
こんな感じで、必要なだけ下層へと詳細化する。
で、これ以上、下の階層へ降りることに
意味を感じなくなった状態のプロセスを「基本機能」という。
なんで、そのプロセスが基本機能であるか否かで、
それ以上詳細化するか否かが決まる。
じゃぁ、基本機能であるか判断するための目安は？というと、
- 基本機能ごとにミニ仕様書というものを書くが、それが1ページに収まる程度になっていること
- 入力と出力が1:1、又は多:1になっている場合は、十分に分割されていると言える
といったことが挙がる。
また、データフローは、プロセス間のインタフェースを示す。
データフローから重複を排除し整理(正規化)することで、
そのインタフェースをより明確にできる。
この本ではデータディクショナリってのを使って表現している。
でも、まぁ、ERDやクラス図でいいんじゃん、なんて。
基本機能の詳細な仕様は、ミニ仕様書にまとめる。
ミニ仕様書は
をつかって記述する。
こんな感じ。
で、読んで思ったのは、
これまでに触れてきたモデリング手法や設計手法との共通点。
いや、と言うよりは、これが原点なんだろうな。
オブジェクト指向とDFD
例えば、オブジェクト指向。
構造化だと段階的詳細化で構成要素に上下関係がある感じ。
オブジェクト指向だとオブジェクト同士に上下関係はなくフラットに連携してる感じ。
・・・なーんて認識でいたんですが、
DFDを基本機能レベルまで詳細化してぜーんぶ繋げたら、
各基本機能間には上下関係はない。
フラットな関係だ。
オブジェクト指向に何か似てる。
さらに。
データフローが基本機能間のインタフェースになるというじゃないですか。
まぁ、データフローだけだとデータのみになるけど、
基本機能＋データフローで考えると、
これってオブジェクトの責務に似てる？みたいな。
DFDをクラス設計のInputにできるんじゃないかなー。
あと、構造化言語で書かれたミニ仕様書って、
ユースケース記述に似てる。
クラス設計とDFD
クラス設計について。
データフローからドメインモデルを抽出し、
基本機能まで詳細化されたプロセスをアプリケーションロジックとする。
こんな感じでDFDをクラス設計のInputにしてしまう。
例えば、以下のようなDFDがあったとする。
各プロセスをこんな感じに読みかえる。
Process1(domainA, domainB) : domainC
Process2(domainC) : domainD
で、これをそのまんまアプリケーションロジックのinterfaceとして定義する。
それぞれのアプリケーションロジックはStatelessにしておいて、
こやつらを繋げるための「場」を用意する。
んで、その「場」に対してアプリケーションロジックをDIする。
ABDとDFD
で、ABDですよ。
再びこのDFD。
プロセスは入ってるくるデータフローと出ていくデータフローを
関連付けるための「場」のようにも見える。
自分はABDのActivityもEntity同士を関連付けるための「場」だと思ってる。
というわけで、プロセス=Activityなんじゃないかという気がしてくる。
Process1 = Activity1
Process2 = Activity2
で、こんなデータモデルに。
と、まぁ、構造化分析の本を読んでるはずなのに、
色んなことへ繋がって(妄想して)、めっちゃ楽しい本でした。
見逃している「気づきと学び」も、いっぱいあるんだろうなぁ。
また読みかえしたい本です。
