フローチャート

Next: PAD Up: アルゴリズムの図示 Previous: アルゴリズムの図示

フローチャート

アルゴリズムやプログラムを分かりやすくするための手段として、それを図示するという方法がとられることが多い。
従来より、アルゴリズムの図化には、フローチャートという記述法が用いられることが多かった。多くの学校では、情報系の講義でフローチャートを教えているし、また学生に出す課題でも、プログラムを製作するだけでなく、フローチャートの提出を義務づけているところもある。通産省の情報処理技術者試験でも、フローチャートの知識は必須のものとされている。また、最近はパソコンの一般化により、コンピュータサイエンスを専門職としない人を対象としたプログラミングの解説書なども大量に書店に並んでいるが、軒並フローチャートを用いて説明が為されている。
これほどフローチャートが一般に広まっている理由には、第一に「書きやすい」という特徴を持っていることが挙げられるだろう。本来は、フローチャートにはたくさんの記述単位があり、例えば入出力デバイスや単なる計算、条件判定等はすべて異なる形で記述しなくてはいけないため、正確なフローチャートを書くのは意外と難しい。しかし、実際にはそれらの各処理単位をすべて等しく単なる四角形で済ませてしまうことも多く、その場合、処理単位の四角と、それらの処理順を示すための結線だけでフローチャートが書けてしまう。実際、あるプログラムを開発中の時に、だいたいの流れを考えている時には、その簡易版フローチャートで充分目的を果たせる。この記述の簡易性、また、プログラムの実行と同じように、1つ1つの処理を線に沿って見て行けば良いという原理の分かりやすさによって、フローチャートは一般に受け入れられたのだと考えられる。
しかし、このようなフローチャートも、プログラムの規模が少し大きくなるだけで、途端にうまく機能しなくなる。その理由は次のとおりである。まず第一に、フローチャートを理解するには、始めから順に流れに沿って追っていかないといけない、ということがある。これは、大きなプログラムになった場合、全体を理解する上で障害となる。実際に、世の中のフリーソフトをフローチャートにしてみようとするだけで、線が込み入ってしまい、他人が見たらどこがどうなっているのか分からなくなってしまう。さらに、企業で開発するような大規模アプリケーションの場合を考えてみると、フローチャートでは、とてもではないが他人が見て理解できる代物ではなくなってしまうだろう。
第二に、同じアルゴリズムでも、例えばたった1つのループでも、人によって描き方が大きく異なるということがある(図 1参照)。このフローチャートの性質のため、全体を貫く柱となる線を把握するのが難しいという欠点が生じる。

図 1: 同じアルゴリズムの異なるフローチャート

逆に言えば、2つの図の形が同じように見えても、片方は分岐でもう一方はループになっていたということもある。これでは、アルゴリズムを分かりやすく説明するというより、逆に混乱を引き起こす場合もありえるだろう。
これらの理由は、フローチャートが構造を表すことができないという点に起因する。これについては、構造化プログラミングという概念が誕生した背景を考えれば良く分かるだろう。かつてのプログラミング言語は、処理の流れを制御する命令、いわゆる goto文のある言語が多かった。代表例としては、BASIC が挙げられる。このような言語では、プログラマーも goto文を多用せざるを得なかった。しかし、ハードウェアの進歩とともに、大規模なプログラム作成が可能になるにつれて、複雑に飛び交う goto文がプログラムを理解する妨げとなり、goto文排除が叫ばれ、C言語のような構造化プログラムに移行したのであった。フローチャートは、いわばこの BASIC のようなものであり、両者は根本的な性質が同じものである。即ち、各処理単位が BASIC の命令文に、処理単位をつなぐ線が goto文に該当する。そのためフローチャートは、BASIC のように、初心者に受け入れられやすく、簡単な問題には極めて便利という長所、逆に大規模な問題に不適という短所を持つ。
以上より、フローチャートでは大規模なプログラムの場合には対応できないことが分かる。そもそもプログラムを図示する目的は、その理解を助けるためであった。即ち、大規模なプログラムであればあるほど、図化して理解しやすくする動機が強いはずである。その点、大規模になるほど機能しなくなるというフローチャートの性質は、この本来の目的と矛盾するものである。