プログラムとは、何か目的を達成するために開発するものであり、設計、実装、テストの順で行われる。
設計とは、実際にプログラムを作るために設計すること。実装とは、設計に従ってプログラミングやコーディングを行うこと。テストは、試験を行う事である。
当レポートでは、実装の工程について解説する。
実装とは
実装とは機能や技術を開発したり組み込んだりすることを言う。
既に述べたように、実装は基本的に設計にしたがって行うが、設計の段階で実装するべきすべての事が決まっているわけではない。実装には、完全に設計に従う部分と、設計からよりかみ砕く必要のある部分が存在する。
設計に完全に従う部分
インプット/アウトプット
そもそも、プログラムとは何かの目的を達成するために開発する。
その目的にあたるのがアウトプット。アウトプットを生み出すための元ネタにあたるのがインプットである。
（例）クエリの場合
常に同じデータを表示したいわけではなく、その時に指定した条件に沿ったデータを表示させたい。そのためには、選択画面で欲しいデータの条件を指定し、実行画面に表示するデータを動的に変える。
この選択画面で条件を指定することがインプット、その条件に沿ったデータを実行画面に表示させることがアウトプットである。
このように、システム内部では、どのようなアウトプットを生み出せばよいのか判断できない。そのため、システム内部にデータが存在しない時にインプットが必要なのだ。
基本的に、プログラムの目的であるアウトプット、その元ネタであるインプットは設計に従う。
プロセス
アウトプットを生み出すための処理。（業務的な観点）
プロセスは設計に従って実装を行う。とはいえ、設計の段階ではアウトプットを生み出すための処理を粗い粒度で定めているため、実装の段階ではそれらをかみ砕きプログラムに落とし込む必要がある。
画面
画面とは文字通り、表示される画面。
設計の段階で定めていないボタンなどを、実装の段階で画面に追加することはない。
イベント
イベントとは、処理を行わせる引き金。（ダブルクリックなど）
イベントは、設計の段階で定めた通りに実装を行う。
処理
アウトプットを生み出すための処理（システム的な観点）
処理と、プロセスは似ているが違う。処理は、システム的な観点での処理を指し、プロセスは業務的な観点での処理を指す。
（プロセスと処理）
プロセスは、業務上達成したい目的を達成するためには、どのような処理が必要か、という粗い粒度の処理を定義しているのに対し、処理は、プロセスで定めた粗い粒度の処理をシステム的ににかみ砕いたものである。
大体の処理は、設計の段階で定めた通りに実装を行う。
型
型とは、データの種類。（データの形式や、桁長など）
型は、設計の段階で定めた通りに実装を行う。
実装ならではの部分
順次/選択/繰返
プログラムはこの3つのどれかに必ず分類される。
順次とは、上から書いてある順番通りに処理を実行する事。選択とは、条件によって異なった処理を実行する事。繰返とは、処理を繰り返し実行する事である。
プログラムの一行一行を設計の段階で書いているわけではないので、これらは実装の段階で定める。
カプセル化/モジュール化
ロジックを小分けにする概念。
カプセル化とは、関連するロジックを纏め、カプセルで包み込む事。ロジックをカプセル化することにより、外部からカプセル内のロジックを守ることや、ロジックを変更した際の影響範囲をカプセル内にとどめるというメリットがある。
モジュール化とは、ロジックを部品のように扱う事。ロジックを部品化することにより、「プログラミングが効率的に行える」、「プログラムの修正が楽になる」、「プログラムが見やすくなる」というメリットがある。
設計の段階では、プログラムの一行一行まで落とし込んでいないため、どのロジックをカプセル化・モジュール化すべきなのかは実装の段階で定める。
ローカル/グローバル
ロジックを、プログラム全体で共有するか否かの概念。
グローバルはプログラム全体にロジックが有効であるもの。一方ローカルとは、その範囲内でしかロジックが有効でないものである。
プログラミングの際には、必要最低限だけグローバル、それ以外を全てローカルにし、有効範囲を狭めることにより、不具合をなくすことができる。
この概念は実装の段階で定める。
例外処理
何らかの理由で、処理に失敗した後の処理。
業務レベルの例外処理に関しては、設計の段階である程度洗い出すことが可能であるが、システムレベルの例外処理までは、想定しきれない。
そのため、実装の段階でシステム的なエラーに対しての例外処理を定める。
コメント
どのような意図があって、そのソースコードを書いたかを補足する情報。
ソースコードを見ただけでは、なぜそのソースコードを書いたのか意図が伝わりにくい部分がある場合、削除しても問題ないのか、あるいは削除したらエラーが発生してしまうのか、変更者には判断できない。そのため、ソースコードにプラスして、どのような理由でソースコードを書いたのか、補足するコメントが必要である。
そもそも、ソースコードは実装の段階で書かれるため、その補足説明であり、コメントはソースコードを書いた後、つまり実装の段階で書く。
変数
値を書き換えることが可能な箱。
変数（値を入れる箱）を定義することにより、毎回違う値を変数に入れることが可能である。
そもそも、プログラムは複雑で高度な処理を行うためのものであるため、値を書き換えることが可能な変数を定義し、効率的に処理を行わせる事が必要不可欠である。
設計の段階では、プログラムの一行一行まで細かい粒度で定められていないため、実装の段階で変数を定めることになる。
定数
定数とは、値を書き換えることができない変数の事で、消費税や、円周率など固定的な値に使用する。
定数を定義することによって、プログラムの修正を楽に行うことができる。逆に、定数を定義せずに値をプログラムに直接埋め込んでしまった場合、プログラムの修正を行う際に、そのすべての箇所を修正する必要がある。
設計の段階では、プログラムの一行一行まで細かい粒度で定められていないため、実装の段階で定数を定めることになる。
命令
プログラミング言語に備わっている、コンピュータに対する指示。命令はプログラム言語によって、どのようなものがあるのかは異なる。
設計の段階では、プログラムの一行一行まで細かい粒度で定められていないため、実装の段階で命令を書くことになる。
関数
インプットに対して、アウトプットを生み出すためのもの。
命令と関数は似ているが、両者の異なる点は、命令はプログラム標準であるのに対し、関数は必ずしもプログラム標準でなく、新たに開発することが可能な点である。
関数を開発することにより、様々な場面で使いまわす事が可能である。
設計の段階では、プログラムの一行一行まで細かい粒度で定められていないため、実装の段階で、どの関数を使用するかを定めることになる。
コンパイル/有効化
コンパイルとは、書いたソースコードをコンピュータが理解できる形に翻訳する事。有効化とは構文のエラーをチェックして、アクティブ化する事。
プログラムのソースコードは人間が理解しやすい言語であるが、コンピュータはそのソースコードを理解できるわけではない。そのため、ソースコードを機械が理解できる形に翻訳する必要があり、それをコンパイルと呼ぶ。
ソースコードを書いた後に行う作業のため、実装の段階で行う。
コーディングルール
プログラムのルールである。
例えば、x,yには何の値を埋め込むかなど、プログラムを綺麗に書くため、あるいは誤解を生まないようにするためのルールである。
コーディングルールは、ソースコードを書く際のルールであるため、実装より前の段階で定める。
実装手順
実装には、絶対的に守らなくてはいけない手順は存在しない。
とはいえ、大体はインプット・アウトプット・画面といった目に見える部分から作り、その後に、プロセスや処理といった、システム的な部分を作る。
実装の一部であり、プログラミングと同時に行われるのが、動作確認である。
動作確認とは正常に動作するかをざっくり確かめるものであり、テストとは別に行われる。
テストは、実装及び動作確認を終えた後に行う。
まとめ
プログラムは、漫然と書けばいいわけではなく、過不足なく整理した状態であるべきである。そのためには当レポートで解説した概念が必要不可欠である。整理され、過不足ないプログラムは不具合を起こさないだけではなく、修正もより簡単になるのである。
実装工程では、何の目的を達成するためにそのプログラムを開発するか、目的達成のためにはどんな要素が必要なのかをきちんと理解して、エンドユーザ目線に立ち気を利かせて行う必要があると考えた。なぜなら、プログラムを開発する目的は、作る事自体にあるのではなく、そのプログラムを使い、業務を助け、お客さんを満足させることだからだ。
コメント