開発フェーズ編
第２４章 アプリケーション設計・実装
アプリケーション設計・実装フェーズでは、システム共通設計によって分割された個々のアプリケーションについての設計・実装を行う。
アプリケーション設計・実装で作成するドキュメントの一覧を示す。
| ドキュメント名 | 解説 | 様式番号 |
アプリケーション
設計書
|
アプリケーションレイアに位置づけられるクラスの内部構造を示す設計書である。
|
3-01 |
|
テスト項目表
|
システムをテストする項目の一覧
|
3-02 |
アプリケーション設計・実装フェーズでは、システム共通設計フェーズにより分割されたアプリケーションの機能の範囲や詳細しついて、さらに詳しく仕様化がなされ、ODG、ADGチームによって先行開発中のフレームワークやコンポーネントを使ってアプリケーションの実装がなされる。
ここで使われる代表的なプロトタイプとしては、コンポーネントインタフェースプロトタイプがある。このプロトタイプは、開発途中のフレームワークやコンポーネントのインタフェースとスタブをアプリケーション開発者に提供することで、アプリケーション本体の開発に遅れを来すことがないようにするという目的で使用される。
本フェーズで、フレームワークやコンポーネントに仕様上または実装上の不都合が発見された場合、システム共通ワークショップを通じて、問題に対する打開策を検討され、その結果がシステム共通設計やコンポーネント設計にフィートバックされる。
従って、アプリケーション設計フェーズはシステム共通設計フェーズが先行させながらも、ほとんど同時に進めらることも多い。
図24-1 再利用コンポーネントの問題改善
アプリケーション設計・実装によって開発されるクラスは、基本的に再利用の観点を持たないAppレイアに属するものが対象となる。このようなクラスは、個人的に再利用するようなコンポーネントとして設計されていても、再利用コンポーネントとしての管理対象とはならず、再利用のためのドキュメントであるコンポーネント仕様書やパッケージ仕様書を書く必要もない。
ここで開発されるクラスは、完全にアプリケーション固有のものであり、コードに対する再利用のコストを省き、アプリケーションの機能実現に集中しなければならない。しかし、再利用しないからといって、コードの可読性を高める努力を怠ってはならない。Appレイアに属するクラスも、保守面では見通しのよい設計・実装がなされなければならないからである。
アプリケーションで利用されるソフトウェアは、原則としてコンポーネントや、フレームワークという形態で提供されるパッケージということになる。
システム開発では、多くの市販ソフトウェア製品を使われることになるだろう。これらはシステム共通設計によって具体的な使用方法が検討される。オブジェクト指向的ではないソフトウェア製品については、ODGによってオブジェクトにラップされ、再利用可能なコンポーネントとしてパッケージ化されることになる。
このようにして提供されたコンポーネントを使いこなすためには、習得期間必要とされることは事実であるが、それを身につければコスト削減につながるというメリットがある。コンポーネントの習得期間を短くするには、再利用クラス開発サイクルで作成される以下の２つのドキュメントを有効に利用するのがよい。しかしながら、コンポーネント開発がアプリケーション開発と同時並行的に進む場合、下記のドキュメントの完成を待つよりもコンポーネントの完成を最優先する方が得策であることも事実である。よってそのようなケースでは、下記のドキュメントをODGに無理に要求するよりも、ODGがDROを使って作成するオブジェクトレイアウトカードや実際にコンポーネントを使ったサンプルコードを要求したりして、コンポーネントの理解を深めなければならない。
-
パッケージ利用解説書
コンポーネントまたはフレームワークの提供単位であるパッケージについての解説書。
-
コンポーネントリファレンス
再利用可能なコンポーネントの使い方を解説したもの。パッケージ仕様書に添付される。
アプリケーション開発では、上記ドキュメントとODGの支援により、提供されるコンポーネントの仕様を短期間で理解しなければならない。そのためには、仕様書に記載されているコンポーネントの利用例を基に、アプリケーションの個々の機能を実現する小さなプロトタイプを数多く作成しながら習得する期間を、アプリケーション設計・実装フェーズの前段階に設けるとよい。これによって提供されるフレームワーク・コンポーネントの使い方のコツや癖を学びとることができる。
コンポーネントの使い方がある程度理解できた時点で、アプリケーションの機能を実現するためのオブジェクト同士の動的な振る舞いを動的構造モデルを作りながらトレースし、問題があればクラス図に反映する。
この作業はすべての機能に対して行うものではなく、以下の手順を繰り返すことで効率のよい設計を行う。
-
重要な機能を優先させる。
-
アプリケーション設計の中で類似する構造やロジックを優先させる。
-
単純なメッセージ交換で実現されるものは対象外とする。
-
類似したメッセージ交換で実現する機能はグループ化してトレースする。
-
エラー処理やアプリケーション機能の繰り返し時に発生する後始末処理について、シナリオから動的モデルを作ってトレースする。新たに見つかった重要部分についてはモデルに組み込む。
ラフスケッチを基にチームで繰り返しデイスカッションすることにより、チームの間で実装における意志の疎通が図れるようになる。その際、ある程度の記法を守りながらホワイトボードにモデルを書き、何度もトレースして書き直しながら、最終的に最善のモデルを見つける。そして、それが正しいかどうかは、簡単な実装プロトタイプによって早急に検証され、最終的な実装がなされる。
チームとしてソースを管理する段階は、個々のクラス単位で基本的なバグを取り去り、アプリケーション開発用の共有デイレクトリに登録した時からである。この時点より、バグや変更履歴がリソース管理責任者（通常システム管理者）によって管理されなければならない。よって、この作業の効率化を図るために、中途半端なソースコードをチームのソース管理に含めないようにしなければならない。
そのためには、クラスソースの単体テスト、テストドライバやテストスタブを使った連動テストの徹底を実装者に促すことが重要となる。あまりにも基本的なバグなどが頻繁に発生する場合は、一旦、実装者にソースを返却することも検討すべきである。
システム設計者は実装者全員のソースを注意深く目を通すべきである。
特に、クラスのインターフェースを定義したファイル（C++ではヘッダファイル）が、設計どおりに正しく実装されているかを、実装時の早い段階から調べるとよい。これにより、初期段階のミスを防ぎ、効率のよい実装が可能となる。
また、システム設計者は、重要なクラスについて実装を兼務することが多く、同時に他のシステム実装者の成果物にも責任を持つ。そのために、以下のようなチェックポイントを設けるとよい。
-
クラスのインターフェース部分を定義し終えた時。
- クラス名は正しいか。
- 属性名や属性型値が正しく定義されているか。
- メソッド名やメソッドのパラメータ、戻り値が正しいか。
- ソースコードが汚くないか。クラス設計時に作成したプロトタイプをそのまま整理もせずに流用した場合などは、ソースがとても汚くなることがある。
- コーディングルールを守っているか。
-
クラスの実装を完了した時。
- 再利用コンポーネントの基本的な使い方が正しいか。
- インスタンスの生成と消滅のタイミングに無駄がなく、かつ、安全であるか。
- インスタンスの生成時と消滅ロジックに一貫性があるか。
- コラボレーション図で仕様化されたとおりにメッセージの流れを実装されているか。
- 基本的なロジックに間違いがないか。
- 安易なエラー処理を行っていないか。
-
担当するクラスのテストが完了した時。
- 再利用コンポーネントの事前条件や使用条件を満たした利用をしているか。
- 試行錯誤の結果、多くの不必要なコメント行をそのまま残していないか。
- 不必要なメソッドが含まれていないか。
- 不必要な属性が含まれていないか。
- 不必要なロジックが含まれていないか。
- 同じようなロジックを数多く含んでいないか。
- 潜在バグがないか。
1.のチェックポイントにより、クラスインターフェースの誤りを早期に発見することができる。2.のチェックポイントは、実装部分の誤りを発見することができる。システム設計者は、初めてチームを組むメンバであっても、ここまでで、ある程度実装者の技量を判断することができなければならない。実装者のソースについて、いくつかレベルを変えて質問をしてみるとよいだろう。質問の中で、クラス図やコラボレーション図を書かせながら答えてもらうこともよいだろう。何度かの質問のやり取りとソースコードの質によって実装者のレベルを見抜いた後は、実装者のレベルに合った指導を行う。このころから、システム開発者は毎朝、１、２人のソースコードをメールで受け取り、ソースを眺めるようにするとよい。それは、朝のコーヒーブレイクの時間内で片づけられるようなことである。そして、問題点や技術面において、実装者に適切な指示を出せるようにする。
このような習慣によって、システム全体の品質を高めることができる。
3.のチェックポイントを完了すると、先に述べたように、プログラムコードは個人のものではなくなり、プロジェクトの中でリソース管理者の責任で一括して管理されることになる。この段階からプログラムの重要部分や問題部分について、システム設計者を交え、複数人でコードインスペクションを行うことになる。コードインスペクションに参加したプログラマは、インスペクションの中で発見されたミスについて十分注意することとなるだろう。
アプリケーション設計・実装計フェーズの作業過程や完了時に、作業内容の評価を行う材料として以下のチェックリストを示す。
チームで管理するソースの管理を適切におこなっているか？-
アプリケーションの動作をテストする段階になると、ソースをチームで共有する必要がでてくる。このときには、個人レベルのバックアップを取るだけでなく、共有ソースのバックアップを責任持って行う役割を誰にするか決めなければならない。
- 使えそうもない機能をそのままにしていないか？
-
アプリケーションを設計においてシステム共通設計できめた仕様を実際にアプリケーションレベルに具体化する際、システム共通設計では有効に思えた機能がアプリケーション設計では使えない仕様となっていることもある。このような場合に、システム共通で決めた仕様だからということで何も言わずに設計・実装してしまうと問題が起こる。よってシステム設計者（アプリケーション設計者）はシステム共通設計で決定されたシステムとしての機能を、もう１度アプリケーション利用の観点で疑ってみるべきだ。そし問題がある場合は、システム共通設計に観点を変えてもう一度システム機能を設計しなければならない。
再利用の観点を持たないクラス開発