5分で習得!PADで構造化プログラミング

title31

著者は長い間フローチャートやUMLのアクティビティ図でプログラム仕様書を書いていたのですが、PADというものに出会ってこれは使える!と思ったのでご紹介します。

フローチャートのイライラを解消してサクサク開発をすすめましょう!

PADの使いかた

細かい説明をするよりPADで書いたフローを見た方がわかりやすいと思います。以下の例ではサイコロを6回ふって合計によってメッセージを変えるプログラムをPADで記述しています。

pad1

緑色の線は説明のために描いたものでPADの仕様ではありません。右側には実行、繰り返し、サブルーチン、分岐の判例を記載しておきました。

使うパーツは「実行」「繰り返し」「分岐」「サブルーチン」と「開始/終了」のみ

本当にこれだけです。これしかないので説明しようがありません…。

分岐はキザギザの山を2つにしてYes/Noにしたり逆に数を増やして10択にすることもできます。

実行順序は単純。分岐だけは注意が必要。

プログラムの実行は上から下まで一筆書きで進みます。途中で切れることはありません。

分岐は択一なので、分岐先の中から一つを選んだら他の処理には入りません。

PADの良いところ

一見、フローチャートと少し表記方法が違うだけの様に見えるのですが、実際に描いてみるとフローチャートにはないメリットに気づきます。

メリット1 : スピード。素早く描けてコードに落としやすい。

フローチャートで4分岐を描くには菱型の分岐マークを3階層にする必要がありました。PADでは4分岐でも10分岐でもスラスラ描けます。実行順序も上から下へスムーズに流れるので他の人に依頼する際に説明が楽です。

分岐は2分岐(True or False)以外に多分岐(case)に対応している他、繰り返しが前処理(for,while)以外に後処理(Do until)にも対応しているため、フローチャートに比べてプログラムのコードと1対1の対応が取りやすくなっています。

メリット2 : 品質。強制的に構造化され、分業しやすい。

pad2

各要素の入り口と出口が1つしか無く、途中で消えることがないので自然に構造化プログラムになります。

フローチャートのループや分岐の出入り口の部分(上図の赤丸部分)に注目してください。前の処理からループに入って右側の処理を実行したあと必ず元に戻ってきてから次の処理に向かいます。

このルールのおかげでExitでいきなり終了したり、GoToで突然ループの外に飛んだりするようなフローになることはありません。

また、処理の出入り口が決まっているので関数にして簡単に切り出すことができます。これはモジュール開発の分業や、コーディングとテスト(スタブ/ドライバ作成)の並行作業を容易にします。

メリット3 :コストが見えやすい。要素数から開発工数が予想できる。

私がPADですばらしいと思ったのはこれです。実行数+分岐の枝数+繰り返し×3でおよその開発工数とテスト工数が算出できます。

1要素がほぼ1関数に対応できることと、やり直しが発生しにくい上に修正もしやすいため、フローチャートよりも正確に見積りができます。

また、前述のとおり分業や並行作業を意識した工程の見積も正確に行うことができます。

どんな場面で使えるか

手続き型言語なら全般的にOK。

構成が単純で柔軟性があることから手続き型言語に向いていると思います。C、やシェルスクリプト、Perlスクリプトのコードをいくつかピックアップしてみたところスラスラ記述することができました。

アセンブラでも推奨

アセンブラはJUMPを多用する言語なのでPADには合わないかな?と思ったのですが意外にマッチするようです。

分岐の戻りポイントが明確になることで、苦しまみれのJUMPをしてレジスタ/スタックの中身が想定外の値になるケースをコーディング前に検出できるようになりました。

オブジェクト指向ではクラス図・アクティビティ図との併用を。

オブジェクト指向ではクラス図やアクティビティ図と併用することでより品質の高いコードを書くことができます。

プログラムの全体の流れはアクティビティ図、クラスの構成はクラス図に任せてメンバの中の記述はフローチャートからPADに置き換えるとコーディング効率の向上が期待できます。


PAD(Problem Analysis Diagram)
1979年に日立製作所の二村良彦氏が開発したプログラム技法。ISO8631として標準化されている。


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です