PAD図ってご存じですかね？
順次、選択、反復といった制御フローをブロック単位で表現し、それらを直列または入れ子状に配置する事でプログラムの構造を図示するものと言えばよいでしょうか。
私の場合、制御構造を図示するときにはPAD図一択です。何故か？フローチャートやアクティビティ図だと、注意して書かないと表現がブレるからです。PAD図は誰が書いても同じ表現になります。ちょっと言いすぎかもですが、表記に縛りがあるので、同じ表現に落ち着きます。
なので、強くお勧めしたいです
また、PAD図で書いた制御構造は、Scratchと相性が良いです。ほぼそのまま写像できる感じです。(Scratchを使うならPAD図を書く意味がないので、身もふたもないですが・・・)
詳しい話は、次を参照してもらうとして、フローチャートとPAD図を比較してみて、その良さを感じてみてください。
(UMLのアクティビティ図もフローチャートと同じように下記のような良くないところがあります)
FizzBuzzをフローチャートとPAD図で書いてみる
FizzBuzz問題を次のように定義したとします。
1から100までの数字を順番に表示してください。
ただし、3の倍数のときは「Fizz」、
5の倍数のときは「Buzz」、
3と5の公倍数のときは「FizzBuzz」と表示してください。
これを、フローチャートとPAD図で書いてみて比較してみます。
FizzBuzzをフローチャートで表現-その１
条件分岐のYesを下に、Noは右に。ループの戻りは左側。というように注意して書いたフローチャートです。
FizzBuzzをフローチャートで表現-その２
条件分岐のYesを右に、Noは下に。ループの戻りは右側。というように注意して書いたフローチャートです。
FizzBuzzをフローチャートで表現-その３
条件分岐表現のルールなし、ループ表現ルールなし。わけがわからないフローチャートです。
PAD図-その１
ループの制御構造は入れ子で表現。条件分岐は上がYes、Noが下。という縛りがあります。
PAD図-その２
case文の表現ができます。
Scratchで表現
考察
- フローチャートは、注意して書かないと訳が分からなくなる(その３)。
- フローチャートは、表現の縛りを入れれば見やすくなるが、Yes下派かYes右派か、ループ左派か右派かで見え方が変わるので、同じ制御構造に見えない(その１とその２)
- PAD図は表現に縛りがあるので、表現にブレがない。
- Scratchの制御構造とPAD図で書いた制御構造は同じ(と言ってよい)。
実は、投稿後に気づいたのですが、上記のフロチャート、PAD図、Scratchのいずれかにはバグがあります。
ちゃんと動作するのはどれでしょうか？
解答
ちゃんと動くのはScratchです。
ここからちょっとした気づきがあったのですが、どんなに良い表記であっても実際に動かしてテストできないものはダメなんだなぁと。
これまで、PAD図をどんな時に書いていたか振り返ると、他人の書いたコードを理解するために書いていました。
つまり、先にソースコードがあって、その後で作図していました。
昔々のその昔、ソースコードの入力がパンチカードくらいの昔。よく制御構造を考えずに、いきなりパンチカードにコーディングして、うまく動かなかった時のコストがばかにならなかったので、机上でフローチャートを書いて、頭の中でデバッグして、いよいようまくいくと納得してからパンチしていたそうです。
つまり当時は先に図を書いてからコードを書いていたと。
コンピュータが安価になり、手軽にソースコードが書けるようになったので、PAD図などで図示する局面はそうとう稀になりましたが、「理解」を助けるツールとしては有用ですので、これからも使っていくでしょう。
参考
PAD図の書き方などは、次のURLが参考になります。