Cなどの構造化プログラミング言語を教える際、PAD(Problem Analysis Diagram)の使いどころについて悩んでいます。
私自身、PADを用いた教育を受け、これが構造化プログラミングの考え方を強制できるよいツールだと実感してますが、以下の点が気になっています。
・PADに関する情報・文献が少ないこと
・プログラミングになれてくるとまどろっこしい表現に思えてくる（疑似言語の方がいい）
PADを使った教育は一般的なのか？ また、PADよりもよいツール・手法があれば教えてください。
No.1
1782
96
20pt
私も昔はPADを使っていましたが最近では使っていないです。
現在であれば、手続きを記述するのであれば
UMLのアクティビティ図や
http://www.atmarkit.co.jp/im/carc/serial/object08/object08.html
ステートチャートが良いと思われます。
http://bill.doshisha.ac.jp/2002/Study/knowhow/06/UML%E3%81%AE%E5...
まったくプログラムが初めての人に構造化プログラミングを説明するためにはPAD図は良いと思いますが。
最近ではステートチャートからソースを出力してくれるツールもありますし、業界標準のUMLのほうが良いのではないでしょうか。
No.2
3542140
23pt
＞PADを使った教育は一般的なのか？
ＰＡＤ図は、仕事で今も使えるなら一般的かと。
ＰＡＤ図知らない人のほうが多いような気がしますが・・。
＞構造化プログラミングの考え方を強制できる
私も構造化プログラミングを説明するためにはPAD図は良いとは思いますが、
構造化プログラムの考え方でアルゴリズムを落とすために使うには
どうかなと思います。
この手法でやれば構造化プログラムに必ずなるというわけでもないと思うので。
仕事でも使えない？ＰＡＤ図を覚えるのはなんとなく面倒な感じはします。
私の経験では、プログラムを組めない者は構造化プログラミングの考え方ができないんだと考えています。
プログラムを組めるようになるには、既存のプログラムを構造化プログラミングの考え方で説明できるようなってからだと思います。この考え方のできてない者のプログラムの説明は、処理のレベルの違うものが同時にでてくる混沌としたもので、理路整然とされていない。その辺をうまく訂正するには、PADはよいツールで、視覚的にわからせてくれます。
確かにPADはアルゴリズムを落とすために使わないですね。アルゴリズムを説明させるため、理解度を測定するために使えるんだと思いました。
No.3
33225
30pt
> PADを使った教育は一般的なのか？
現在ではフローチャートよりも廃れていると思います。
そもそも、最近の設計手法は構造化プログラミングではなく
オブジェクト指向型のプログラミング設計手法が主流になってきています。
# まだ、オブジェクト指向は一般的とは言えないと思います。
> PADよりもよいツール・手法があれば教えてください。
数学、語学に王道が無いようにプログラミングにおいても王道はありません
ひたすら読んで書くしかないと思われます。習うよりも慣れろです。
PAD図もフローチャートもアルゴリズムを示しているだけです。
私は最も良いツール・手法とは適切なコメントが入っている
ソースコードであると思っています。
ソースコードにはデータ構造とアルゴリズムなど
プログラムに必要な要素が全て入っています。
そして、くだらないスペルミスは殆どコンパイラが指摘してくれます。
個人的にはツールや手法よりもプログラムの考え方の方が重要で
潰しが利き、そして教えるのが難しいと思います。
私は下記の「プログラミング作法」という本で重要な考え方の一部を学びました
教育の参考になれば幸いです。
プログラムにインデントをまともにしてこない、その役割を理解していない者に対して、教えた上で型にはめるという意味ではPADは有益なツールだと考えています。その点、ソースコードだけでは弱いと思いと思うのです（その点、Pythonなら･･･、と思いますが、マイナーすぎます･･･）。
プログラミングはおっしゃるとおり、「習うよりも慣れろ」ですね。ただ、ある程度慣れて来た段階で、処理の構造の組み方について、きっちり習わせる必要があると感じてます。紹介された本を参考に読んでみたいと思います。
# 今ふと思ったのは、インデントがしっかりできてないプログラムをはじいてくれるコンパイラみたいなものってないですかねぇ･･･
No.4
863
30pt
Ｃ＋＋（オブジェクト指向プログラミング）ではなく、Ｃ（構造化プログラミング）ですね。
ＰＡＤは、教育用と言うよりも、設計書の一部として誰が書いても一様になりやすいので重宝なのだと思います。
つまり教育が目的ではないということですね。プログラム製造過程の手法のひとつだということです。
教育が目的であれば、なぜ構造化が必要なのか、そして、なぜそのためにＣ言語を作ったのか、その理由を解き明かしている言語作成者のカーニハン＆リッチーの書いた本が教科書としては良いと思います。
必要性がわからないと、ただ形だけを教えても効果が薄いように思います。
プログラミング言語C ANSI規格準拠 (単行本)
B.W. カーニハン (著), D.M. リッチー (著), 石田 晴久 (翻訳)
http://www.amazon.co.jp/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%...
プログラム書法 (単行本)
Brian W.Kernighan (著), P.J.Plauger (著), 木村 泉
も、良いと思われます。
これらの本で学習した人と、そうでない人の作成したプログラムには、かなり差が出ると思われます。つまり、構造化言語を使う意味を学習していない人は、形式だけは知っているけれども、なぜそうするのかを理解しておらず、欠陥の多いプログラムを書く人が多いということです。
dev_zer0さんに続き、カーニハンの本の紹介、ありがとうございます。
構造化プログラミングを語る上で、カーニハンは避けられないようで、しっかり勉強しておきたいと思います。
No.5
867
25pt
上流レベルの記述で大事なのはデータ構造の処理ではなく
状態遷移の記述なので，ステートチャートやアクティビティ図（フローチャート）を使えということになるのでしょうね．
複雑なデータ構造に対するアルゴリズムの記述のためにはPADは役立つのだと思います．
「アルゴリズムイントロダクション」という教科書がありますが，この本で説明されている
プログラムはほとんどPADとして読むことができる擬似言語で書かれていますし．
個人的には，順序・選択・繰り返しな構造化よりも，
・データ構造
・再帰
の理解の方が大事な気がします．XMLやグラフ構造などはこの理解なしには操作できないと思います．
もっとも最近の開発者の多くは複雑なデータ処理はライブラリやRDBにお任せで，
単純なデータ構造(（連想）配列・オブジェクト）しか扱わないのであまり関心がないのかもしれませんがね．
Beirii
2007/12/27 22:50:07
1
1
1
2
1
2
108
108
garyo
pigment
フローチャート、そして、それから派生したもの思われるアクティビティ図やステートチャートは、処理のレベル（抽象⇔詳細）を分けて記述する能力がないと認識してますので、残念ですが、選択肢として考えていません。