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

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

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

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

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

どんな設計図？

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

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

項番	提案	略称	名称
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を見直すことでプログラムロジックの誤りを発見することができます。

フローチャートとPADの比較

1977年頃に作成されたTiny BASICの処理系を見てみます。これは、Intel8080マイクロプロセッサー用に作成されたものです。

その中のテープ入力（Tape Input）ルーチンのコードをアセンブラレベルで書いたフローチャートを見てみましょう。

同じプログラムをPADに書き直してみます。

PADは、全体の処理が目の前の図面に浮かび上がってきませんか。これがPADの魅力です。

 

PADの解説書

構造化チャートのひとつであるPAD（Problem Analysis Diagram）は、日立製作所の二村良彦さんが考案したもので1980年代に普及しました。PADは素晴らしいプログラム設計図です。当時は、PADを解説した技術情報誌や書籍がありましたが、最近では入手が困難になってきました。

2018年11月に書いた 拙著「究極のプログラム設計図 PAD解説」でPADを解説しています。興味があったら、一度読んでみてください。

 

 

2019年11月には、amazon売れ筋ランキングのコンピュータサイエンス部門で16位になりました。