「RFPからプログラミングまで、シームレスに開発する方法」というのを書くといって、現在以下の図
の①、④、⑤は書いたので、今日は②のDMM（機能構成図＝機能分析表）について
■ドメインを詳細化していくわけだけど・・・
システム開発をするとき、ある程度の規模になると、システムの成果物（帳票、出力画面、DBのデータ）だけでも膨大になるため、適当な範囲を決めて、システムを分けていく。
こうして、システムをサブシステムにわけて、サブシステムをサブサブシステムにわけて、サブサブシステムをサブ３システムにわけて・・・と詳細化していくことを、まずはじめにやる。
この様子を書いたのが、DMM（機能構成図＝機能分析表）っていうことになる。
これは、ドメインの詳細化ともいえるけど、そー厳密な話じゃない。
もちろん基本的には、複数の成果物があれば、その成果物ごとに分けるというのも１つの手だし、ここの例のように、登録・変更・削除・閲覧・・・みたいなかんじに機能で割っていくのもひとつの手。
ただ、どっちにしろ、けっこういい加減であり、視点が定まっていて（業務に着目し詳細化、成果物に着目し詳細化など）漏れがなければ、まあ、いいかなという感じ。
なので、詳細化といっても、ドメイン全体を定義し（おおまかな機能とデータについて認識し）、それを詳細化するほどの厳密さはいらないし、そもそも、それを求めてもできない。
■っていうか、情報を入れるフォルダを作っているかんじ。
ここでの作業はむしろ、フォルダを作っていっているかんじ。
これは、電子的に、パソコンのファイルを入れるフォルダ(ディレクトリ）をイメージしてもらってもいいし、紙文書をいれる、フォルダをイメージしてもらってもいい。
そこのフォルダをつくって、これから、DFDなり、いろんなドキュメントをつっこみますよ、そのフォルダの階層を作りますよ・・・っていうイメージ。
自分のパソコンでフォルダを作るのに、そうそう悩まない？とおもうけど、そんなかんじでも、いい気がする。
問題は、漏れなく情報をフォルダにいれて、必要なときに確実に引き出せること。
なので、どー言う観点でフォルダを作ったか・・・つまり、DMMにおいて、どーいう観点で階層を分けたかは重要だけど、それ以外は。。。
■フォルダってことは・・・パッケージ？
Javaなどの場合、フォルダっていうと、パッケージに相当するわけで、
ってことは、DMMをパッケージ割りというふうに捕らえることも出来る。
そして、適当な大きさになると、そこでDFDなり、業務流れ図がかかれ、そうすると、前に書いたように、そこからクラスが書ける。
それらクラスは、プロセスとか、機能は、そのパッケージに属することになる
（データ部分のエンティティは、この中に入れないほうがいい。共有化されるので）
■ということは・・・
DMMとDFD、業務流れ図には、関連がある。というか、関連を持たせたほうがいい。
DMMで書かれている機能を、DFDや業務流れ図で記入するようなかんじ。
もし、DMMレベルでフォルダを切るなら、DFD、業務流れ図のドキュメントは、対応するDMMのところにおいておいたほうがいいのかもしれない。
■で、今気づいたんだけど・・・
川崎市の事例で、
このページ
トップページ ＞ 導入編「自治体EAの導入方法」 ＞ ２．業務参照モデル（総務省標準第一版）
http://www.soumu.go.jp/denshijiti/system_tebiki/model/content02.html
に載っているDFDと
このページ
トップページ ＞ IV．資料編3：事例集 ＞ 新規事例：川口市 ＞ 業務分析(1) ＞ 基幹：住民基本台帳
http://www.soumu.go.jp/denshijiti/system_tebiki/jirei/kawaguchi/gyomu01/nisshi-KJ01.html
に載っている、DFDの「書き方」が違いすぎるんだけど・・・
（内容が違うのはいいのだが、書き方は同じになるはず・・）
いままでの説明で書いてきたとおり、DMMっていうのは、ドメインを詳細化していくものだから、それとドメインのデータフローを記述するDFDは、関係があるのが普通。
前者に書かれているように、一般にはDMMの各機能が、DFDのプロセスになっているのが美しい。
ところが、後者は、DMMとDFDの関連がまったくわからない。
これでは、開発はできない。
これを、事例としちゃうと、まずいんじゃないか？
アクセス
トータル
ランキング
