【プログラミング教育におけるPADの有用性】


Cなどの構造化プログラミング言語を教える際、PAD(Problem Analysis Diagram)の使いどころについて悩んでいます。

私自身、PADを用いた教育を受け、これが構造化プログラミングの考え方を強制できるよいツールだと実感してますが、以下の点が気になっています。

・PADに関する情報・文献が少ないこと
・プログラミングになれてくるとまどろっこしい表現に思えてくる(疑似言語の方がいい)

PADを使った教育は一般的なのか? また、PADよりもよいツール・手法があれば教えてください。

回答の条件
  • 1人3回まで
  • 登録:2007/12/27 19:25:35
  • 終了:2007/12/30 22:03:15

回答(5件)

id:garyo No.1

garyo回答回数1782ベストアンサー獲得回数962007/12/27 20:12:45

ポイント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のほうが良いのではないでしょうか。

id:witt

フローチャート、そして、それから派生したもの思われるアクティビティ図やステートチャートは、処理のレベル(抽象⇔詳細)を分けて記述する能力がないと認識してますので、残念ですが、選択肢として考えていません。

2007/12/28 15:26:35
id:KUROX No.2

KUROX回答回数3542ベストアンサー獲得回数1402007/12/27 21:31:07

ポイント23pt

>PADを使った教育は一般的なのか?

PAD図は、仕事で今も使えるなら一般的かと。

PAD図知らない人のほうが多いような気がしますが・・。

>構造化プログラミングの考え方を強制できる

私も構造化プログラミングを説明するためにはPAD図は良いとは思いますが、

構造化プログラムの考え方でアルゴリズムを落とすために使うには

どうかなと思います。

この手法でやれば構造化プログラムに必ずなるというわけでもないと思うので。

仕事でも使えない?PAD図を覚えるのはなんとなく面倒な感じはします。

id:witt

私の経験では、プログラムを組めない者は構造化プログラミングの考え方ができないんだと考えています。

プログラムを組めるようになるには、既存のプログラムを構造化プログラミングの考え方で説明できるようなってからだと思います。この考え方のできてない者のプログラムの説明は、処理のレベルの違うものが同時にでてくる混沌としたもので、理路整然とされていない。その辺をうまく訂正するには、PADはよいツールで、視覚的にわからせてくれます。

確かにPADはアルゴリズムを落とすために使わないですね。アルゴリズムを説明させるため、理解度を測定するために使えるんだと思いました。

2007/12/29 01:26:22
id:dev_zer0 No.3

dev_zer0回答回数332ベストアンサー獲得回数252007/12/27 23:25:11

ポイント30pt

> PADを使った教育は一般的なのか?

現在ではフローチャートよりも廃れていると思います。

そもそも、最近の設計手法は構造化プログラミングではなく

オブジェクト指向型のプログラミング設計手法が主流になってきています。

# まだ、オブジェクト指向は一般的とは言えないと思います。


> PADよりもよいツール・手法があれば教えてください。

数学、語学に王道が無いようにプログラミングにおいても王道はありません

ひたすら読んで書くしかないと思われます。習うよりも慣れろです。


PAD図もフローチャートもアルゴリズムを示しているだけです。

私は最も良いツール・手法とは適切なコメントが入っている

ソースコードであると思っています。

ソースコードにはデータ構造とアルゴリズムなど

プログラムに必要な要素が全て入っています。

そして、くだらないスペルミスは殆どコンパイラが指摘してくれます。


個人的にはツールや手法よりもプログラムの考え方の方が重要で

潰しが利き、そして教えるのが難しいと思います。


私は下記の「プログラミング作法」という本で重要な考え方の一部を学びました

ISBN:4756136494

教育の参考になれば幸いです。

id:witt

プログラムにインデントをまともにしてこない、その役割を理解していない者に対して、教えた上で型にはめるという意味ではPADは有益なツールだと考えています。その点、ソースコードだけでは弱いと思いと思うのです(その点、Pythonなら・・・、と思いますが、マイナーすぎます・・・)。

プログラミングはおっしゃるとおり、「習うよりも慣れろ」ですね。ただ、ある程度慣れて来た段階で、処理の構造の組み方について、きっちり習わせる必要があると感じてます。紹介された本を参考に読んでみたいと思います。

# 今ふと思ったのは、インデントがしっかりできてないプログラムをはじいてくれるコンパイラみたいなものってないですかねぇ・・・

2007/12/29 01:01:38
id:yokayo No.4

yokayo回答回数86ベストアンサー獲得回数32007/12/28 01:48:34

ポイント30pt

C++(オブジェクト指向プログラミング)ではなく、C(構造化プログラミング)ですね。

PADは、教育用と言うよりも、設計書の一部として誰が書いても一様になりやすいので重宝なのだと思います。

つまり教育が目的ではないということですね。プログラム製造過程の手法のひとつだということです。

教育が目的であれば、なぜ構造化が必要なのか、そして、なぜそのためにC言語を作ったのか、その理由を解き明かしている言語作成者のカーニハン&リッチーの書いた本が教科書としては良いと思います。

必要性がわからないと、ただ形だけを教えても効果が薄いように思います。

プログラミング言語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 (著), 木村 泉

も、良いと思われます。

 これらの本で学習した人と、そうでない人の作成したプログラムには、かなり差が出ると思われます。つまり、構造化言語を使う意味を学習していない人は、形式だけは知っているけれども、なぜそうするのかを理解しておらず、欠陥の多いプログラムを書く人が多いということです。

id:witt

dev_zer0さんに続き、カーニハンの本の紹介、ありがとうございます。

構造化プログラミングを語る上で、カーニハンは避けられないようで、しっかり勉強しておきたいと思います。

2007/12/29 01:05:29
id:wasisan No.5

wasisan回答回数86ベストアンサー獲得回数72007/12/29 09:24:56

ポイント25pt

上流レベルの記述で大事なのはデータ構造の処理ではなく

状態遷移の記述なので,ステートチャートやアクティビティ図(フローチャート)を使えということになるのでしょうね.

複雑なデータ構造に対するアルゴリズムの記述のためにはPADは役立つのだと思います.

「アルゴリズムイントロダクション」という教科書がありますが,この本で説明されている

プログラムはほとんどPADとして読むことができる擬似言語で書かれていますし.

個人的には,順序・選択・繰り返しな構造化よりも,

・データ構造

・再帰

の理解の方が大事な気がします.XMLやグラフ構造などはこの理解なしには操作できないと思います.

もっとも最近の開発者の多くは複雑なデータ処理はライブラリやRDBにお任せで,

単純なデータ構造((連想)配列・オブジェクト)しか扱わないのであまり関心がないのかもしれませんがね.

  • id:Beirii
    PADは特にC言語を使用した構造化設計手法による開発には向いていると思います。
    PADはその性質上、構造化プログラミングとなるように作られていますし、詳細に書かれたPADはそのままソースコードになる程にシームレスです。
    従って、主に下流の設計を担当するようなエントリーレベルのエンジニアにはPADは向いているんじゃないかと私は思います。

    しかしそれ故に、PADは下流設計で使用するのには向いているものの、上流設計で使用するのには必ずしも向いているとは思いません。
    witt様が『プログラミングになれてくるとまどろっこしい表現に思えて』きたのは、下流設計に慣れてきたために詳細なPAD図を書く必要性を感じなくなったためではないでしょうか。(書かなくても直接コーディング可能になった)

    構造化設計手法の上流設計であればやっぱりUMLに準拠したアクティビティ図かステートチャートあたりがいいのかなと思います。
    外部にも提示しやすいですし、何より現在の業界標準ですから。
    でも下流設計ではC言語を使用した構造化設計手法による開発であれば無理にUMLのダイアグラムを使用しなくてもいいと思います。
  • id:garyo
    最近は構造化プログラミング用の制御文(if~else,while)が普通なので、(あえてgotoでも使わなければ)何もしなくても構造化プログラミングになる(そうしか書けない)と思いますよ。
  • id:pigment
    Beiriiさんに賛成
    追加する部分もないほどに完璧な回答であると思います。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません