---------------------------------------------------------------------

next up previous
Next: 他人のプログラムの理解 Up: pad2ps を使用する利点 Previous: 簡単なアルゴリズムの図示

---------------------------------------------------------------------

プログラムの保守

次に、自分個人、または企業等でプログラムを開発しているケースを考える。 この場合、後々にプログラムを更新する可能性が高いため、ドキュメントを残し ておくのがふつうであろう。 そのドキュメントの一形態として、プログラムの処理手続きを図化しておきたい という要求は強く、できればPAD図を描いて残しておきたいところだろう。 このケースでも本ソフトウェアは有用であるが、その理由は、前節で述べたもの に加えて、以下のようなものが考えられる。

  • 一から作成し直す必要がない
    ドロー系ツールを利用する場合、完成したプログラムとは別途に、一からその アルゴリズムを示すPAD図を描かなければならず、二度手間となる。この手間 のせいでプログラムの図示をあきらめていたというケースがあった。 一方、本ソフトウェアを使うと、もしC言語で開発している場合、そのプログ ラムソース自体を元にして、必要な部分だけを残したり、コメントを加えたり してPADELを作成すれば、二度手間をかける必要がない。 C以外の言語であっても、iffor といったキーワードが違う だけの場合が多く、修正はたやすい。
  • プログラムの更新に柔軟に対応できる
    ソフトウェアは頻繁にバージョンアップを繰り返すものだ。プログラムが少し 変わっただけでも、PAD図の全体の配置が変わったり、枠の大きさが変わった りしてしまうものだが、もしドロー系ツールを用いて画像としてPADを描いて おいた場合、たいていこの修正を反映できず、また作り直しということになる。 一方、本ソフトウェアではテキストファイルとして書いておくため、エディタ で簡単に修正できる。ドロー系ならではの配置の変更も、本ソフトウェアが自 動的に最適にするため、何の問題もない。
  • 共同開発の際に適している
    プログラム開発を複数の人が共同で行う場合も多い。PADELという共通の文法、 しかもC言語に良く似た書式で書いてあれば、他人の作成したPADに対しての修 正が容易に行える。ドロー系ツールの場合、枠の大きさや配置等に個人差が反 映し、意外と妨げとなる。
  • プログラム開発者が慣れたツールでPAD図を作成できる
    これは異論もあると思われるが、プログラム開発はエディタでソースを組んで いくという作業であるため、ほとんどのプログラマーはエディタでの作業に慣 れ親しんでいる。本ソフトウェアはエディタでPADELを描くというシステムな ので、開発者はプログラム開発の作業の中でPADを描くことができる。

---------------------------------------------------------------------

吉田 誠一のホームページ に戻る。
Copyright(C) Seiichi Yoshida (comet@aerith.net). All rights reserved.
Sat Mar 15 01:58:22 JST 1997