2019年 | ある計算機屋さんの手帳

フローから構造化チャート

プログラム設計図を書いてますか？

さて、あなたはプログラムを作成するときに設計図を書いているでしょうか。いきなりパソコンに向かってタイプしてコーディングしていないでしょうか。

私も、小さくて簡単なプログラムなら、いきなりコーディングしてしまうことが多いです。しかし、ちょっと複雑だと感じたとき最初にプログラム設計図を書きます。

あなたが日曜大工で本棚を作るとします。木材をカットする前に、大ざっぱなスケッチでもかまいませんが設計図面を書くでしょう。そして、その設計図面に従って木材をカットして組み立てるでしょう。日曜大工と同じでプログラムを作成するとき、プログラム設計図を書いたほうが良いと考えます。

設計しながらコーディングするのではなく、プログラム設計図を書いて論理的な正しさを確認してからコーディングしたほうが、近道ではないでしょうか。

どんな設計図？

では、どんな設計図を書いたら良いでしょうか。オブジェクト指向設計や複合設計などなど、いろんな設計手法があります。
モジュールに分割した後の詳細設計においては、構造化チャートをお勧めします。間違っても、フローチャートを書いてはいけません。フローチャートにはいろいろ問題があり、複雑なプログラムロジックを作ってしまう可能性が多いです。

使えないフローチャート

構造化チャートにもいろいろあります。

項番	提案	略称	名称
1	–	PF	Program Flowchart
2	–	NS	Nassi-Shneiderman diagram
3	–	PSD	Program Structure Diagrams
4	日本電気	SPD	Structured Programming Diagrams
5	電電公社	HCP	Hierarchical and ComPact description chart
6	日立製作所	PAD	Problem Analysis Diagrams
7	富士通	YAC	Yet Another Control chart

同じ問題をフローチャート、SPDチャート、HCPチャート、NSチャート、PADで書いてみました。

構造化チャートの比較

このなかで、PADがコンパクトにまとまっていて、わかりやすいと思いませんか。

PADに慣れてくると、図面からプログラムのロジックが浮かび上がり、プログラム構造を見渡すことができるようになります。誤ったプログラムロジックの場合は、なぜか違和感を抱きます。なぜならば、美しい構造になっていない場合が多いからです。美しい構造とは、対称的であり個々の処理があるべき位置に配置されているものです。違和感を抱くPADには、バグが潜んでいる可能性があります。PADを見直すことでプログラムロジックの誤りを発見することができます。