モジュールの実装

分担

モジュール化が一段落したら，分担を決めましょう

一つのモジュールを2〜3人で担当できればベストです．

確認

モジュール毎に，担当者は，

やるべき事とインタフェースを確認し，
プログラム化を参考に，まずは関数プロトタイプ（名称，機能，何を引数で受け取って何を返すか）を作成してみましょう
- モジュール（オブジェクト）に持たせる「メソッドとしての」関数を考えます
- どのモジュールからも利用できそうな汎用性の高い機能は，共通の関数として格上げしましょう

モジュール内部説明

担当者は，モジュールの実現（実装）方法について考えましょう

インタフェースを作る側から見直しましょう
インタフェース関数の実現を考えましょう
インタフェースに書かれていない内部変数や関数が必要か検討しましょう

それらを，モジュール内部説明書（仕様書）としてまとめましょう．

モジュール内部説明書（仕様書）の作成

まずはモジュールが提供するインタフェースを確認し，モジュール内での決まりを書きます．

内部インタフェースの定義と説明

続いて，モジュールが提供するインタフェースの実装方法を書きます．

関数が呼び出される前の状態
関数が呼び出された後の状態
関数内部の操作を，モジュールが提供する概念（の詳細）と機能（の詳細）を用いて記述します

実装方法に記述した内容を，実装言語で翻訳し直したものがそのままソースプログラムになると理想的です．

仕様書を作る意味

実装まで考えずに作成し（てみ）た提供インタフェースが，本当に妥当であるか確認する目的
データ構造が妥当であるかを確認する目的
ある関数が実行されるために必要な状態の確認
ある関数が実行されたあとの状態の確認

部品作り

モジュールの簡単なプロトタイプを作ってみましょう．

インタフェース仕様を満たしているもので，
まずは関数の入口と出口を作ります．
徐々に中身を入れていってもいいし，作りなおしてもいいです．

あるいは，

モジュールを実装するための，
ごくごく小さな部品を，
動作確認しながら作っていきましょう．

部品作りの進め方（の例）

プロトタイプ（雛形）を作ります
曳光弾（えいこうだん）アプローチを利用する
- 手探りでプロジェクトを進めるのではなく，まず検証したい焦点を絞った簡易なプログラムを作って，実際に効果があるかを確かめるやり方です．
- もし効果がなければ，効果があるのはどの形態かが判るまで繰り返します．

アプローチ

作ろうとするものを，より基本的で独立な機能や部品に分けて，その中で次のような「もの」や「機能」を作ります．

本質的だけれども，
作り方がはっきりしていない

この際，使い捨ての立場でやるならプロトタイピングアプローチが適していますし，修正・詳細化など改良を加えていく立場なら曳光弾アプローチが適しています．

得られる成果（または目的）

実装のための基本的な考え方や技術が身につきます
自分（達）でできる，という自信が得られます
作ろうとしているものを実感できます
作ろうとしているものとプログラムを対応付けられるようになってきます

関数の実装

上記の「部品作り」の経験を元に，実装していきましょう。

単体テスト

ある程度モジュールが出来上がってきたら，モジュールが提供する機能をテストすることが重要です．主な目的は，バグを検出して修正することであり，関数の機能や，モジュールの機能だけをテストするメインプログラムを作ることが有効です．

このテストは，モジュールを作成した本人が担当すべきであり，技法としてはホワイトボックス法などが使われます．

担当者ごとに，ひとつひとつの関数やモジュールの機能をテストしましょう．

テストの意義

（書籍『経験ゼロでもできるプログラミング現場の単体テスト』より）

中規模以上のシステム開発では，設計に時間がかかってテストに時間をかけられないこともある．
よって，致命的な障害が発生する可能性がある．
とはいえ，すべてのケースを想定してテストを実施するなどということは現実的ではないので，テストケースを絞る必要がある．
各テストフェーズの礎となる 単体テストが重要 となる

後でまとめてテスト，はダメ

とにかく時間がかかる
問題箇所を切り分けることが難しくなる
モチベーションが下がる
リスクの先送りになりかねない

プロジェクト終盤で行うテストは，再現→原因調査→修正→再テストと，余計に時間がかかるので，プロジェクト序盤から単体テストを実施するべき．

テストの実際

準備するもの

テスト用メインプログラム

提供する機能を使う
うまく機能するかを，プログラム，または人が判断する

テストすべきモジュール

下位モジュール

テスト済みの下位モジュール
あるいはその代わりとなる代替インタフェースモジュール

テストできること

提供機能の不具合
インタフェースの自然さ

（参考）ホワイトボックス法とブラックボックス法

動作チェックのために必要な値を含めたデータのことを「テストデータ」と呼びます．このテストデータを，実際にプログラムをコーディングする「エンジニア側の視点」から作ることを「ホワイトボックス法」，モジュールやシステムを使う「ユーザ側の視点」から作ることを「ブラックボックス法」と呼びます．

ホワイトボックス法

プログラムの処理手順や処理内容といった内部構造を意識して，バグが発見できるようにテストデータを作り込みます．ソースプログラム中の文，分岐，条件などを網羅的に実行してバグを見つけます．

テスト	内容
ステートメントカバレッジ（命令網羅）	ソースコードの全命令・文のうち，１回でも実行されたステートメントの割合
ブランチカバレッジ（分岐網羅）	ソースコードの全分岐のうち，１回でも実行された分岐の割合
コンディションカバレッジ（条件網羅）	ソースコードの分岐に設定されている１つ１つの条件が成立・不成立の両方が実行された割合

ブラックボックス法

プログラムの内部構造をあまり意識せず，「このデータを処理したら，結果としてAという値が返ってこなければならない」といった要件をクリアできるかどうか，を検証するようなテストデータを作るやり方をいいます．モジュールを統合した以降のテストに使われる技法です．

テスト	内容
同値分割法	プログラムが期待する「有効同値」及び「無効同値」を入力として結果を確認
境界値分割法	プログラムの「有効同値」と「無効同値」の境界となる値を入力して結果を確認