プログラム開発工程

In document ( ( 5 10 pdf (Page 81-84)

5

一般に、プログラムを作る作業は次のように進みます。

6

(A) プログラム化すべき問題が与えられる。

7

(B) 問題を分析し、処理内容の大きな流れ、基本構造を決める。

8

(C) プログラミングと直接関係しない、比較的抽象度の高いレベルで処理内容を詰める。

9

(D) 特定のプログラミング言語、プロセッサ向きにプログラムを作るための前準備/設計を行う。

10

(E) 実際にプログラムを書き下す。

11

(F) プログラムの間違いを修正する。

12

たとえば平方根を求めるという問題が与えられたとしましょう。これが上の(A)の段階です。

13

通常、いきなりプログラムを作成することはありません。まず、どのような方法で問題を解決す

14

るのか、基本となる数式やアイディアを出し、それをまとめていきます。前節では平方根の解法と

15

して3種類を紹介しました。そのいずれを利用するか、あるいは別の方法を用いるか、各解法の特

16

徴を考慮して決定します。これが(B)の段階です。

17

そして、アイディアに致命的な欠陥はないか等を注意深く調べながら、さらに条件判定式やプロ

18

グラムの分岐構造、ループ構造を少しずつ詳細に固めていきます。これが(C)の段階です。この段

19

階ではまだ特定のコンピュータを想定している訳ではなく、前章で述べたプログラムの三大原理:

20

プログラム中の文は上から順番に逐一実行されていく。

21

プログラム中では、条件判定を行い、その判定結果の真偽に従い、次に実行する文を取捨選

22

択できる。

23

プログラム中に繰り返し実行部を作ることで、多数回の類似の処理を簡素に表現できる。

24

81

アルゴリズム

(algorithm)と呼びます。問題が簡単な場合には、プログラ

2

マは無意識にアルゴリズムを作り上げるかもしれません。少し複雑な場合には、簡単なメモを取る

3

かもしれません。しかし、より複雑な場合には図式を用いたり1、データの変化などを表にまとめ

4

たりしながら、計算手順を精密な形にまとめていくのが一般的です。

5

アルゴリズムが定まったならば、それを特定のプログラミング言語やプロセッサ上に実装(実

6

現)するために、その言語やプロセッサに固有の設計を行います。たとえば6.1節では、プログラ

7

ミングの前に変数名、変数の使い方を決めました。これが(D)に相当します。

8

そして最後にプログラミングを行います。これが(E)です。プログラムを書き下しても、それで終

9

わりではありません。ほとんどの場合、最初に書いたプログラムには間違い—これを

バグ

10

(bug)2と呼びます—が含まれています。そこで、プログラマはプログラムを実際に実行し、実

11

行結果を確認しながら、バグをひとつひとつ取り除いていかねばなりません。これが(F)です。

12

(A)から(F)へ向かう途中で不都合を発見したら、逆戻りして設計し直すことも必要です。その

13

ような作業を繰り返して、プログラムは形になっていきます。

14

通常、(A)に近い段階をプログラム開発の

上流工程

(upstream process)、逆に

15

(F) に近い段階を

下流工程

(downstream process)と呼びます。一般に、開発す

16

るプログラムの規模が大きくなればなるほど、上流工程での問題分析・設計は重要度が増し、難易

17

度が上がり、それを担当するソフトウェア技術者には高いスキルが要求されます。それに対して下

18

流工程は上流での設計に基づくプログラミングが中心の作業ですから、設計さえ正しく終えていれ

19

ば個々のプログラミングはそれほど難しいものではありません。この意味から、下流工程よりも上

20

流工程がより重要度が高い訳ですが、しかし上流工程のスキルは一朝一夕に身につくものではあり

21

ませんし、上流工程の仕事には下流工程の管理も含まれますから、上流工程の技術者は下流工程に

22

ついても知悉している必要があります。結果として、ソフトウェア技術者は当初はプログラマとし

23

て下流工程で開発経験を積みながら、上流工程のスキルを磨いていく場合がほとんどです。

24

本学科のカリキュラムでは、ソフトウェア技術者に必要な上流工程、下流工程の知識と技術をと

25

もに深く学ぶことができるように科目を配置しています。1年後期からはプログラミング(すなわ

26

ち下流工程の技術)を学び、2年生後期からは

ソフトウェア工学

(こ

27

れが上流工程の技術)の講義も始まります。

28

1この講義では省略していますが、プログラムを図式化する方法としてフローチャート(flow chart)などがよく知られ ています。

2英単語bugとは虫のことです。特にゴキブリやシラミなどのありがたたくない虫を指します。プログラムのバグとは、

プログラムに潜む、虫酸の走るような間違いのことなのです。

科に在籍する4年間(あるいは6年間、9年間)でこの単語を何度となく使うことになるはずです。

4

アルゴリズム(=処理手順)を可能な限り厳密に定義するならば以下の4条件になります。

5

1. 手順通りに実行すれば、正しい答えを求めることができる。

6

2. 手順にあいまいさがない。また個々人の経験や感性に応じて手順の解釈が異なるということ

7

がない。

8

3. 手順の実行は、必ず有限回の操作で終了/停止する。無限に実行し続けることはない。

9

4. 手順は、特定のコンピュータ、プロセッサ、プログラミング言語を想定して作られていない。

10

1.は当然成り立つべき事項です。

11

2.では、たとえば「どちらの手順を実行してもよい」というあいまいさは許されません。また

12

「スマートと思う手順を実行しなさい」「おもしろい方の手順を実行しなさい」というのも許されま

13

せん。何がスマートか、何がおもしろいかは個人の趣味・趣向に依るからです。次に実行すべき事

14

項は必ず客観的に明確に定まっていなければなりません。

15

3.の条件は重要です3。計算が永遠に終わらないかもしれないということは非常に不都合です。

16

アルゴリズムを作るときには、必ず有限停止することを保証すべきです。

17

4.の条件は、アルゴリズムとプログラムを区別する重要な条件です。プログラムはコンピュータ

18

上で実際に実行可能な手順であり、その意味で重要です。これに対してアルゴリズムは上記(B)、

19

(C) の段階で作られる中間生産物に過ぎません。しかし実は、中間生産物であるアルゴリズムがプ

20

ログラムの本質を表しており、多くの場合、アルゴリズムはプログラムよりも重要 です。6.1節を

21

振り返ってみましょう。「平方根を計算せよ」という問題が与えられた場合、どの手法(二分法、

22

モンテカルト法、ニュートン・ラフソン法のいずれ)を用いるかが、プログラムの性質、性能を決

23

める要因となります。もしモンテカルロ法を選んだならば、どんなにプログラムを工夫したとして

24

も実行時間の割に計算精度はほとんど向上しません。しかしニュートン・ラフソン法では、特別に

25

プログラムの作り方を工夫しなくとも短時間で高精度の計算が可能です。この計算手法がアルゴリ

26

ズムに他なりません。そしてプログラムは、そのアルゴリズムを特定の記述法を用いて実体化し、

27

コンピュータで実行可能にしたものになります。

28

31.〜4.の中で3.のみ成り立たない手順を「セミ・アルゴリズム」と呼ぶことがあります。たとえば、論理学のある種の

命題をコンピュータで自動的に証明する場合に、正しい命題は有限回の手順で自動的に証明できるが、間違った命題は永遠 に証明を終えることができない場合があります。世の中には3.が成り立たない手順が多数存在することが分かっています。

NJȓǜȒǢȈ ǿȕǘȑȈ

ǿȕǘȑȈ

ǿȕǘȑȈ

図7.1: 問題、アルゴリズム、プログラムの関係

In document ( ( 5 10 pdf (Page 81-84)