構造化プログラミングについての整理

構造化プログラミングについてです。

構造化プログラミングとはプログラミング実作業やプログラム設計、システム設計において重要な技法、考え方です。今現在では構造化プログラミングの後に出てきたオブジェクト指向がより主流になっていると思いますが、そのベースになっている部分もありますので構造化プログラミングもまだまだ重要だと思います。これについて整理してみたいと思います。

構造化定理と構造化プログラミング

これを書こうと思ってまずはと思ってWikipediaを調べてみたら以下の項目に分かれていました。

構造化定理
構造化プログラミング

これらの記事をざっと読んで見たところ一般的に構造化プログラミングと認識されているのは、構造化定理の方だということです。そういうことであればここではまずそれに従ってこの「構造化定理を使ったプログラミング」について整理します。

この「構造化定理を使ったプログラミング」では3つの手段でプログラムの制御が記述できるとされています。 そのままWikipediaの構造化定理のページから引用させて頂きます。

3つだけの手段(制御構造)は、以下のものである。
1.ある一つの手続きを実行し、それからもう一つの手続きを実行する(順次)
2.ブール演算式の値に従って2つの手続きのどれか1つを実行する(選択)
3.ブール演算式が真である限り、手続きを繰り返し実行する(反復)

確かに開発の現場ではこの内容を「構造化プログラミング」とよく言っています。つまり、「正しいプログラムの書き方」として新人研修から覚えた記憶があります。プログラムの入り口(開始)と出口(終了)を原則一つにして流れが追えなくなるような書き方をしないと覚えました。これにより誰が書いたプログラムでも同じような書き方になり、品質も保てるということです。

またプログラミング言語にはそれぞれ特徴があるにしても、これに従えばある程度同じような構造、書き方になるということです。

それでは、Wikipediaでの「構造化プログラミング」とはどういった内容でしょうか。構造化プログラミングのページにはやはりというか難しい言葉が書いてあります。

キーワードとしては以下が挙げられると思いました。
段階的
抽象化
詳細化
階層化

これらから簡単に考えると大きな処理は段階的に階層化して小さい処理に分割していく、その場合上位から下位について考える時は詳細化であり、下位から上位について考える場合は抽象化ということでしょうか。

これも、実際の開発現場では「構造化設計」とか「構造化技法」という言い方で使っていて実践していると思います。以下のような図(PAD図)で表現することが多いと思います。

開発現場ではどのように考えられているか

それでは実際の開発現場では「構造化プログラミング」をどのように捉えているかと考えるとWikipediaの「構造化定理」と「構造化プログラミング」を両方まとめて「構造化プログラミング」と考えているような気がします。

例えば以下ページで書いてある内容です。
(※最初に広告のページが出てくる場合があります。また全部を読むには有料になるようです。)
最初に学ぶべき構造化プログラミング、大きな問題を分割して解決
ここの説明では「順次」「反復」「分岐」という言葉も出てきて、「大きな問題」を「小さな問題」に分割するという表現も出てきます。私のような現場の立場としては非常に分かりやすい説明です。

あとは、以下のページでは、簡潔に書かれています。引用させて頂きます。
素晴らしいPAD図 | ある計算機屋さんの手帳

構造化プログラミングのポイントは下記の三つです。
三つの基本制御構造(連接処理、選択処理、反復処理)に限定する
基本制御構造を組み合わせて階層化する
トップダウン設計により段階的に詳細化する

これはまさにWikipediaの「構造化定理」と「構造化プログラミング」を両方まとめた考え方ではないでしょうか。

現場では以上のような考え方が分かりやすくて使いやすいということでこうなってきたと思います。

整理してみると

もし、論文やレポートなどで書く場合はWikipediaの内容を考慮する必要がある。また試験の対策としては試験対策用の書籍などで正解になるように理解しておくということが重要かと思います。現場では、上記の現場で幅広く浸透している内容を把握して実践すればいいように思います。

このサイトでは現場の感覚で実践的なことを書いていきたいと思います。

次回はより具体的な内容としてフローチャートと構造化チャートについて書きます。