我が家の植物たち(1)
デザインパターンによるプログラム評価(2)
システム設計の評価を行う場合には、以下のレベルへ分割すると分かりやすいと思います。
「システム設計評価レベル」
(1)システム発展性評価
システム全体の最適化が図られているかどうかという評価です。
無造作にシステム開発をしていると際限なくプログラムが増加してしまい、
複雑に関連するようになり、管理できなくなってしまいます。それを防止する
ためプログラムを体系化し、同じ機能は共通部品化する必要があります。
[評価方針]
①最適化技術による評価
システムが無駄なく整理された状態で設計されている状態を「最適化」状態と
いいます。そうなっているかどうかは、以下のような方針が適用されているか
で判断します。
〇部品の適正利用
共通部品が設計されているか。無駄に多くの部品がないか。
〇機能分割の最適化
一つのプログラムにやたら機能が詰め込まれていないか。
(2)大規模システム
大規模オープン系基幹システムとして不適切な設計していないかという評価です。
ほとんどのシステム開発は複数のチームに分かれて、割り当てられた機能を
プログラムで実装していく開発スタイルと思います。その際、個々のチームが
バラバラに開発を進めて行くと、協調して動けないプログラムになってしまいます。
各機能の役割分担や、データの授受の方法を取り決めたものが「インタフェース
定義」といいます。その合意を各チームで行う必要があります。
[評価方針]
②システム構想準拠性検証
システムの設計・要件定義を始める前に、どのような機能がどこにあり、それらが
協調してどう動くかの方針を定めた「システム構想」が作成されます。その方針に
沿って設計されているかを判断します。
〇インターフエース仕様書による整合性確認
それぞれの機能モジュールのインタフェースに相互矛盾がないか。
〇入出力関連図による利用関係検証
データ入出力に過不足や、機能モジュール間に機能の重複や抜けがないか。
(3)設計整合性
設計記述上の不整合やミスをしていないかという評価です。
いわゆるプログラミングでバグを作り込んでいないかということです。
バグと一口に言っても以下のようなレベルがあります。
[評価方針]
③記述方針チェック
プロジェクト開始時に開発者に配布されるマニュアル「開発ガイド」に沿って
プログラミングされているかのチェックです。
〇「開発ガイド」の記述方針(記述レベル、効率的記述方法)の遵守を確認。
プログラムの行数が大きすぎないか。異常系の記述がされているか。
④基準準拠性チェック
「開発ガイド」に記述されているコーディング規約に沿って記述されているかの
判断です。
〇設計チームが策定した用語集、ネーミング規約等のルールに、合致している
ことを確認。
関数名(メソッド名)がキャメルスタイル(単語の先頭のみ大文字で直接つなげる)
になっているか。
(例：getContractTrem())
⑤整合性チェック
スペルミスなどのコーディングミスがないかの評価です。
〇各設計書間でインターフエース(名称、データ項目)、機能過不足の整合性を確認
関数名(メソッド名)を間違えてコーディングしていないか。
上記は、論理設計レベル(1)(2)から物理設計レベル(3)まで順に記述しています。
物理設計レベルの設計でミスるとシステムが動作しないので開発者は必死に
修正します。⑤整合性チェックでひっかかると、コンパイルすら通らないので当然
ですよね。
論理設計レベルはシステム動作に関係しないので結構軽視されますが、システム完成以降に重大な問題を発生させるのは、こちらの方だったりします。システムの基本方針に関わるものなので、ある意味当然なのですが。
物理設計レベルの検証は比較的定式化しやすいので、各種ツールが提供されており、
以下のような機能を提供しています。
[再利用性検証]
〇重複コード検出
〇コピー箇所検出
[基準準拠検証]
〇コーディング規約チエック
〇記法・命名規則チェック
[整合性検証]
〇無限ループ検出
〇例外未処理
今回の、デザインパターンによるプログラム評価は(1)(2)の領域を対象としています。
デザインパターンによるプログラム評価(1)
システム開発に対するコンサルティングを実施していると、プログラム品質の検証を相談されることがあります。
コーディング規約等のルールは比較的整備されている企業が多く、違反を抽出するツールも製版されていたりして整備されているのですが、「良いプログラミング」が出来ているか、ということはなかなか評価が難しいところです。
プログラムが構造化、共通部品化されていて効率的に開発でき、追加・改修等の保守がやり易く、構造が分かりやすくなっているかという評価を実施する必要があります。
その際、私たちは「デザインパターン」を評価軸としました。
「デザインパターン」は、オブジェクト指向プログラミングにおいて良く利用される処理概念を集めたものです。
特に、GoF(Gang of Four:Erich Gamma,Richard Helm,Ralph Johnson,John Vlissides)の著作("Design Patterns" Addison-Wesley 1995)に挙げられた23パターンが有名です。
FactoryパターンやIteratorパターン等のオブジェクト指向プログラミングの基礎となる概念が含まれています。
ちなみに日本語訳がSBクリエイティブ社から出ています。
「オブジェクト指向における再利用のためのデザインパターン(改訂版）」(1999)
以下、GoFの23のデザインパターンを記載します。
説明には筆者の解釈が含まれています。
「デザインパターン」
A.生成に関するパターン
(1)Abstract Factory
関連する一連のインスタンスを状況に応じて適切に生成する方法を提供する。
(2)Builder
複合化されたインスタンスの生成過程を隠蔽する。
(3)Factory Method
実際に生成されるインスタンスに依存しない、インスタンスの生成方法を提供する。
(4)Prototype
同様のインスタンスを生成するために、原型のインスタンスを複製する。
(5)Singleton
あるクラスについて、インスタンスが単一であることを保証する。
B.構造に関するパターン
(6)Adapter
元々関連性のない2つのクラスを接続するクラスを作る。
(7)Bridge
クラスなどの実装と、呼出し側の間の橋渡しをするクラスを用意し、実装を隠蔽する。
(8)Composite
再帰的な構造を表現する。
(9)Decoraior
あるインスタンスに対し、動的に付加機能を追加する。Filterとも呼ばれる。
(10)Facade
複数のサブシステムの窓日となる共通のインタフエースを提供する。
(11)Flyweight
多数のインスタンスを共有し、インスタンスの構築のための負荷を減らす。
(12)Proxy
共通のインタフェースをもつインスタンスを内包し、利用者からのアクセスを代理する。
C.振る舞いに関するパターン
(13)Chain of Responsibility
イベントの送受信を行う複数のオブジェクトを鎖状につなぎ、それらの間をイベントが渡されてゆくようにする。
(14)Command
複数の異なる操作について、それぞれに対応するオブジェクトを用意し、オブジェクトを切り替えることで操作の切替えを実現する。
(15)lnlerpreter
構文解析のために、文法規則を反映するクラス構造を作る。
(16)Iterator
複数の要素を内包するオブジェクトのすべての要素に順にアクセスする方法を提供する。反復子。
(17)Mediator
オブジェクト間の相互作用を仲介するオブジェクトを定義し、オブジェクト間の結合度を低くする。
(18)Memento
データ構造に対する一連の操作のそれぞれを記録しておき、以前の状態の復帰または操作の再現が行えるようにする。
(19)0bserver
インスタンスの変化を他のインスタンスから監視できるようにする。Listenerとも呼ばれる。
(20)State
オブジェクトの状態を変化させることで、処理内容を変えられるようにする。
(21)Stralegy
データ構造に対して適用する一連のアルゴリズムをカプセル化し、アルゴリズムの切替えを容易にする。
(22)Template Method
あるアルゴリズムの途中経過で必要な処理を抽象メソッドに委ね、その実装を変えることで処理が変えられるようにする。
(23)Visitor
データ構造を保持するクラスと、それに対して処理を行うクラスを分離する。
次回、上記デザインパターンをどのようにプログラム評価に利用したかを記述したいと思います。
【初めまして】ブログを始めてみます
ブログを開始します。
かなり以前に開設してみたのですが、長続きしなかったので再度チャレンジです。
「目的」
1. ITニッチネタの記載
今までITコンサルティングをして来て得た知見があるのですが、結構ニッチで
再利用が難しいものが結構あります。このまま風化させるのももったいないので、
なるべく公開したいと思います。
2. 日常の記載
日頃気づいたこと、面白いことの記録をして行きたいと思います。
何かの話題になればと思います。
それでは、よろしくお願いします。
