プログラム設計書の良い部分と悪い部分

設計書の定義は、おおよそ開発標準や慣例で決まっています。逆に言うと、設計書名やその中身を書くと社名がバレるかもしれません。だからみんな書きたがらないのでは。中でもプログラム設計書はベンダによる違いが大きく、結果的に技術力の差となることが多いです。

前回のエントリでは、プログラム設計書のすべてが不要と言っているわけではありません。

プログラム設計書には、良い部分もあります。内部設計では表現できない設計思想が書いてあるので、変更容易性が向上します。例えば、クラス図からは具体的にどんなデータを扱って処理しているのか読み取れます。そもそもの話ですがインタフェースが決まらないと分業ができませんので、他所と共有するメソッドは設計書に落ちている必要があります。小規模だと細かいメソッド名まで決めない場合もあるし、逆にprivateメソッドまで決めてから実装する場合もあります。

ただ、言語レベルの記述方法まで規定するのは良くありません。

悪いプログラム設計書は、一言で言えば「プログラミング言語を日本語で書いたもの」です。変数の代入からif文の遷移まですべて日本語で書いてあります。こんなものを書くぐらいならプログラムに落とした方が早いし、間違いも減ります。

具体例

例えば、銀行の手数料割引を考えてみましょう。

はてな銀行では、平日9〜17時は1,000円の手数料が必要です。平日のそれ以外は5,000円となります。休日だと10円になります。ただし、アルファブロガーの方は無料です。

これはビジネスルールと呼ばれるもので、外部設計に含まれます。

手数料計算機能

1. アルファブロガー認証サービス（外部設計書p.200）に問い合わて、アルファブロガーの場合は0円を返す。
2. ビジネスルール（外部設計書p.100）で定義した条件で手数料を計算し、手数料の値を返す。

手数料計算機能は、共通機能とする。

これは機能定義と呼ばれるもので、内部設計に含まれます。

• クラスAccountChargeのメソッドcalcで実装する。引数は会員オブジェクト。詳しくはクラス図を参照。
• アルファブロガー認証サービスはRESTベースのWebサービスのため、本プログラムではRESTクライアントのライブラリを使用する。

ここまでは必要です。

手数料計算メソッド(引数：会員)：戻り値はint型

1. client変数にAlphaBloggerAuthServiceClientの新しいインスタンスを代入する。
2. client変数のqueryメソッドを実行する。第1引数に会員オブジェクトを渡す。戻り値をresult変数に代入する。
3. result変数がtrueと等しいとき、戻り値として0を返す。メソッドを終了する。
4. date変数に現在日時のDateオブジェクトを代入する。
5. date変数のisHolidayメソッドを実行した結果がtrueの場合は、戻り値として10を返す。メソッドを終了する。
6. date変数のgetHourメソッドを実行した結果をhour変数に代入する。引数はなし。
7. hour変数が9以上16以下の場合は、戻り値として1000を返す。メソッドを終了する。
8. 戻り値として5000を返す。メソッドを終了する。

ここまで必要ですか？

もっと面白くて良い例があれば教えて下さい＾＾