デザインパターンによるプログラム評価(2)
システム設計の評価を行う場合には、以下のレベルへ分割すると分かりやすいと思います。
「システム設計評価レベル」
(1)システム発展性評価
システム全体の最適化が図られているかどうかという評価です。
無造作にシステム開発をしていると際限なくプログラムが増加してしまい、
複雑に関連するようになり、管理できなくなってしまいます。それを防止する
ためプログラムを体系化し、同じ機能は共通部品化する必要があります。
[評価方針]
①最適化技術による評価
システムが無駄なく整理された状態で設計されている状態を「最適化」状態と
いいます。そうなっているかどうかは、以下のような方針が適用されているか
で判断します。
〇部品の適正利用
共通部品が設計されているか。無駄に多くの部品がないか。
〇機能分割の最適化
一つのプログラムにやたら機能が詰め込まれていないか。
(2)大規模システム
大規模オープン系基幹システムとして不適切な設計していないかという評価です。
ほとんどのシステム開発は複数のチームに分かれて、割り当てられた機能を
プログラムで実装していく開発スタイルと思います。その際、個々のチームが
バラバラに開発を進めて行くと、協調して動けないプログラムになってしまいます。
各機能の役割分担や、データの授受の方法を取り決めたものが「インタフェース
定義」といいます。その合意を各チームで行う必要があります。
[評価方針]
②システム構想準拠性検証
システムの設計・要件定義を始める前に、どのような機能がどこにあり、それらが
協調してどう動くかの方針を定めた「システム構想」が作成されます。その方針に
沿って設計されているかを判断します。
〇インターフエース仕様書による整合性確認
それぞれの機能モジュールのインタフェースに相互矛盾がないか。
〇入出力関連図による利用関係検証
データ入出力に過不足や、機能モジュール間に機能の重複や抜けがないか。
(3)設計整合性
設計記述上の不整合やミスをしていないかという評価です。
いわゆるプログラミングでバグを作り込んでいないかということです。
バグと一口に言っても以下のようなレベルがあります。
[評価方針]
③記述方針チェック
プロジェクト開始時に開発者に配布されるマニュアル「開発ガイド」に沿って
プログラミングされているかのチェックです。
〇「開発ガイド」の記述方針(記述レベル、効率的記述方法)の遵守を確認。
プログラムの行数が大きすぎないか。異常系の記述がされているか。
④基準準拠性チェック
「開発ガイド」に記述されているコーディング規約に沿って記述されているかの
判断です。
〇設計チームが策定した用語集、ネーミング規約等のルールに、合致している
ことを確認。
関数名(メソッド名)がキャメルスタイル(単語の先頭のみ大文字で直接つなげる)
になっているか。
(例：getContractTrem())
⑤整合性チェック
スペルミスなどのコーディングミスがないかの評価です。
〇各設計書間でインターフエース(名称、データ項目)、機能過不足の整合性を確認
関数名(メソッド名)を間違えてコーディングしていないか。
上記は、論理設計レベル(1)(2)から物理設計レベル(3)まで順に記述しています。
物理設計レベルの設計でミスるとシステムが動作しないので開発者は必死に
修正します。⑤整合性チェックでひっかかると、コンパイルすら通らないので当然
ですよね。
論理設計レベルはシステム動作に関係しないので結構軽視されますが、システム完成以降に重大な問題を発生させるのは、こちらの方だったりします。システムの基本方針に関わるものなので、ある意味当然なのですが。
物理設計レベルの検証は比較的定式化しやすいので、各種ツールが提供されており、
以下のような機能を提供しています。
[再利用性検証]
〇重複コード検出
〇コピー箇所検出
[基準準拠検証]
〇コーディング規約チエック
〇記法・命名規則チェック
[整合性検証]
〇無限ループ検出
〇例外未処理
今回の、デザインパターンによるプログラム評価は(1)(2)の領域を対象としています。
