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