ソフトウェア工学 其の八 20171214
構造化分析(続き)
前回出てきた図は「業務をモデリング」していることをもう一回書いておく。このように、モデリングを図にして表したものをDFD(Data Flow Diagram)と呼ぶ。構造化分析以外のことをするにしても、このDFDをキチっと理解していないとダメらしい。何かを理解するときに、この図を頭の中にイメージできるといいエンジニアになるとも。ちゃんと理解しよう。
DFDはフローチャートと似ているが、異なるものだということを頭に置いておかなければならない。フローチャートは「プロセスの実行順番・制御」について記述したもの。DFDは「データの流れ」を記述したもの。*1
DFDの書き方
具体的なDFDの書き方を以下に書いていく。
レベル0DFDを書く
そのシステムがどのようなものなのかだけを書いておく(どんな入力を受けて何をするのか)。なので、プロセスの数は1個。仕様書の文脈だけを図にしているとも表現できるので、レベル0DFDのことをcontext diagramと呼んだりもする。
DFDを再帰的に詳述する(水平・垂直分割する)
分割していくたびにDFDのレベルが上がっていく。
分割する際の注意点は、ちょっとだけ分割するということ。分割していくほど、各プロセスの仕様書を書くことができる。この仕様書のことをPSPECと呼ぶ。PSPECを構文解析、詳細分割していくことで、下位のPSPECが手に入る。この処理を繰り返し繰り返し、分割不可能なところ(具体的なアルゴリズムが想像できる)まで行っていく。このことを段階的詳細化と呼ぶ。
一般的にはレベル7DFDまで書くのだが、1回で5個に分割できるとすると、レベル7DFDは7万8千くらいのプロセス。とんでもない量になる。仕様書が膨大になるわけだ。
データディクショナリー
設計段階で出てくる用語をまとめたもの。誰でも理解できるように書く必要がある。
上に示したDFDという考え方など、ソフトウェア工学に出てくる概念はとても簡単なものが多い。その理由は、大規模で複雑なシステムを良く作るための学問だから。現実社会でも、問題にぶち当たったとき、どのように簡単にシンプルに問題を変換して解決するのかが重要になってくる。そういうところにも使える基礎的な知識だ。
さて、ここまでやってきたのが構造化分析。DFDでシステムの業務をモデリングすることはできたが、ここからどのようにプログラムに落とし込むのか。これが残りの内容で、構造化設計という。
構造化設計
STS分割
全てのDFDに共通する特徴は、
- 前半でデータの整理
- 真ん中ででデータの処理
- 後半でデータの整理
ということ。つまり、DFDは上の特徴に従って3つに分割して考えることができるということだ。この分割方法をSTS分割と呼ぶ。
モジュール構造図
STS分割されたDFDはいったい何を表しているのだろうか。それは、関数の呼び出し関係だ。例として、プロセスがSTS分割によって、という部分(モジュール)に分割されたとする。これは、という関数を順番に呼び出しなさいという表現に読み替えられる。さらに、各関数の中身(モジュール)はDFDに具体的にきっちり書かれている(そうなるようにDFDは記述されているはずだ)。これを図にしたものをモジュール構造図と呼ぶ。
気が付いたら、コーディングすべきことが分かっている。DFDをモジュール構造図に落とし込むことこそが、構造化設計。
モジュール構造図の形について
構造化設計では、分割するほど末広がりな形になるのだろうか。
答えはNoだ。下の方ので共通するモジュール(例えば、画面に文字列を表示するとか)が出てくるので、そんなに広がらない。一番理想的な形は、ひし形。モジュールを増やすので途中までは広がるが、ある時点で共通モジュールの関係でしぼんでいく。
良い設計とは
良い設計の特徴をいかに箇条書きにする。
- 縦に分割→各サブツリーの機能が分かる
- 横に分割→上の方はドメイン(機能・分野)の言葉、下の方は実行環境の言葉で書かれている
- ファンアウト・ファンイン・幅・深さのバランスがいい
こんな感じ。
小々節「モジュール構造図の形について」で、出てきた「ある時点」とは、ドメインの言葉と実行環境の言葉が入れ替わるあたり。
ファンアウト・ファンイン
新しい言葉が出てきたのでここで補足。
ファンアウトとは、一つのモジュールから伸びている線の数。ファンインとは、一つのモジュールへ伸びている線の数。この二つの値が近い方が、モジュール構造図の理想形に近い構造になっている。
*1:http://www.dab.hi-ho.ne.jp/sasa/hyoryuki/dfd/に、フローチャートとDFDの違いについて書いてあるので参考に。