1.3　プログラミングの流れ

プログラムの設計からテストまでの一連の流れをプログラミングという。
プログラミングは、以下の流れで行う。

【STEP1】問題を分析し、仕様を定義する

まず始めに、コンピュータに処理させる情報の内容を分析し、整理する。複雑な処理の場合には、処理しやすい単位に分割する。

ここでは、問題を解決するために与えられる情報は何か、どの情報が重要か、といった「入力」と、問題を解決するために生成されるべき情報は何かといった「出力」を考える必要がある。この「入力」と「出力」が問題の仕様を構成するときの主要な部分になる。

たとえば、次の例の場合、入力と出力はそれぞれ以下のようになる。

例：400円と600円の菓子セットがある。合わせて100セット売れた。合計売上は52,000円であった、それぞれいくつずつ売れたか。

• 入力：菓子セットの単価、販売数量、合計売上
• 出力：400円の菓子セットと600円の菓子セットそれぞれの販売個数

【STEP2】処理手順（アルゴリズム）を明確にする

問題の仕様が明確になったら、次は処理手順を決める。いくつかの処理方法や計算方法がある場合は、どの方法を使うかを決め、どのような手順で処理を行うかを決める。

この処理手順を「アルゴリズム」という。

次の例の計算方法には、以下の2点が考えられる。

例：400円と600円の菓子セットがある。合わせて100セット売れた。合計売上は52,000円であった、それぞれいくつずつ売れたか。

＜方法１＞

400円の菓子セットをx、600円の菓子セットをyとする。

x＋y＝100
400x＋600y＝52,000　　これを解くと、x＝40、y＝60となる。


＜方法２＞

以下のように仮定を設けて計算を行い、売上の合計が52,000円になったところを解とする。

400円が0、600円が100　→　400×0＋600×100＝60,000
400円が1、600円が99 　→　400×1＋600×99 ＝59,800
400円が2、600円が98 　→　400×2＋600×98 ＝59,600
　　　　　　　：
400円が40、600円が60　→　400×40＋600×60＝52,000

処理手順はフローチャート（流れ図）で表すとわかりやすくなる。

プログラムのコーディングを正しく行えるかどうかは、STEP1、STEP2の内容がキーとなる。
STEP1、STEP2をいい加減に行うと、その後のプログラム開発が非常に難しくなるため、STEP3のコーディングを行う前にSTEP1、STEP2の内容に不足がないかどうかを十分に検討する必要がある。

【STEP3】プログラムをコーディングする

Fortran90の文法規則に従ってプログラムを記述する。プログラムはエディタを使ってキーボードから入力し、適切な名前を付けたファイルとして外部記憶装置に記憶しておく。各プログラムはファイル名で識別される。

複数のファイルに分けて作成されたプログラムは、最終的にすべてのファイルを結合する必要がある。このように、複数のシステムをあとでつなげて1つにするという方式を「モジュール化」という。

エディタに入力したプログラムは人間が理解できるように作られているが、コンピュータで実行することはできない。そこで、コンピュータが理解できる機械語にプログラムを変換する必要がある。これを「コンパイル」といい、コンパイルを行うためのツールを「コンパイラ」という。

プログラムに何のエラーもない場合は、スムーズにコンパイルが終了するが、入力や実行の過程で誤りがある場合はプログラムのコンパイルには至らず、エラーが検出される。

プログラムの構文エラーが原因で起こるエラーを構文エラーまたは翻訳時エラーといい、構文エラーが発生するとコンパイルは中止される。プログラムが実行されて初めて検出されるエラーは、実行時エラーという。構文エラーも実行時エラーも、エラーメッセージが表示されることによって、プログラム構文に間違いがあることがわかるため、比較的、修正や検出が容易である。

エラーの中で特定するのが難しいものは、プログラムの構文は正しいが、アルゴリズム上では間違った公式になっている場合である。このようなエラーを論理エラーという。
論理エラーを見つけるためには、STEP4で行うテストが重要である。

【STEP4】プログラムを実行し、テストする

コーディングが終了したら、アルゴリズムとプログラムが正しいことを確認する。

プログラムが正しいかどうかの確認は、正しい出力値がすでにわかっている複数の入力値セットを使い、プログラムを実行して行う。

あらかじめ予想した結果と出力された値が異なる場合は、どこにエラーがあるのかを推定し、修正する。この作業をデバッグという。

複数のセットを使って何度もテストを行うことで、そのプログラムの信頼性が高まり、よりエラーの少ないプログラムとなる。

【STEP5】プログラムの保守

プログラムは、作成したらそれで完成というわけではない。

多くの場合、プログラムは何年にも渡って使用され続け、使用される過程でなんらかの修正が必要になる可能性が高い。特に、複雑な大規模プロジェクトでは、テスト段階で発見されなかったエラーが、ソフトウェアの稼動が開始されてから発見されるということがよく起こる。

プログラム修正が必要になる主な要因には、以下のような場合が考えられる。

• 稼動が開始してから発生したエラーを是正する
• パフォーマンスの向上や新機能の追加
• コンピュータのハードウェアまたはソフトウェアの変更に伴う対応
• 関連する法律などの変更

いずれの場合も、プログラム構造がよく考えられたものであれば、変更も容易に行うことができる。保守を行なうことを前提に考えたプログラムの設計が重要である。