目的

  • 設計の一部 (クラス、ユース・ケースの実現、データベース・エンティティーなど) の実装を生成したり、1 つ以上の障害を修正したりすることが目的です。結果的に、ソース・コードやデータ・ファイル (一般に実装要素という) の新規作成や変更に至ることが多いと言えます。
役割:  実装担当者 
頻度:\ \ 各反復段階で繰り返します (プロトタイプ化が必要なければ、方向づけフェーズの反復段階では行わない場合もあります)。 
ステップ
入力とする成果物:    結果となる成果物:   
ツール・メンター:   
More Information: 

ワークフローの詳細:   

実装の準備 ページの先頭へ

タスク / 問題の理解

実装担当者は、実装作業を開始する前に、作業分担書と反復計画書で指定されている範囲を理解しておく必要があります。実装のタスクでは特定の機能 (ユース・ケース実現の実装や障害の修正など) を実現することに焦点を当てることができ、その機能を実現するための複数の設計要素を実装する作業を行います。また、設計サブシステムや設計クラスなどの特定の設計要素に焦点を当てることもでき、現在の反復で必要とされる範囲でそれらを実装します。

開発環境の構成

この作業では、1 つ以上のファイル (実装要素) を作成するか、更新します。実装担当者は、実装の準備の一環として、正しい要素バージョンを使用するために、開発環境が正しく構成されていることを確認する必要があります。この確認は、更新する要素と、コンパイルや単体テストで必要な要素の両方で必要です。実装担当者は、プロジェクトの構成と変更管理の手順を理解し、それに従う必要があります。そのような手順では、変更の制御やバージョン管理の方法、統合のために変更を配信する方法などを定めています。

既存の実装の分析

クラスを実装する前に、再利用や調整が可能な既存のコードがないかどうかを調べます。実装担当者は、システムのほかの部分のアーキテクチャーや設計に実装が適合するかどうかを確認することによって、そのような再利用の可能性を探ることができます。さらに、実装をシステムのほかの部分に確実に適合させることもできます。

段階的な実装

実装は段階的に行うことをお勧めします。コンパイル、リンク、1 日に 1、2 回の回帰テストを実行します。パブリック操作、属性、関連のすべてを設計中に定義するわけではないことに注意してください。

障害を処理するときには、症状をなくすのではなく、問題を修正するようにします。目指すべきことは、コード内の根本的な問題を修正することです。エラーの修正自体がエラーを引き起こしやすい作業なので、変更は 1 つずつ行っていきます。新しいエラーの発生源を突き止めやすくするため、修正を 1 つずつ段階的に実装することが大切です。

実装担当者は、特定のプログラミング言語用のプログラミング・ガイドラインを含め、プロジェクト固有の実装ガイドラインを理解し、それに従う必要があります。

設計から実装への変換 ページの先頭へ

設計を実装に変換するには、さまざまな技法があります。以下に例を示します。

  • プラットフォーム固有のビジュアル・モデルを使用して、初期のコード・フレームワークを生成できます。このコード・フレームワークをさらに練り上げていくために、設計で指定されていないコードを追加することもできます。
  • モデルを詳細化して、実行可能なプロトタイプを生成できます。構造 (クラスやパッケージの図) と振る舞い図 (状態や作業の図など) を両方を使用して、実行可能コードを生成できます。これらのプロトタイプを必要に応じてさらに微調整できます。
  • モデルが完全に実装を表すようになるまで、モデルの詳細化を進めることもできます。この場合は、抽象的な設計をコード実装に変換するのではなく、設計を取り出して、実装の詳細をモデルの中に直接追加します。
  • 程度の差はありますが、プラットフォームに依存しない設計もあります。プラットフォーム固有の設計モデルやコードを生成するには、高水準の抽象概念をプラットフォーム固有の要素に割り当てる方法を定めたさまざまな規則によって変換を行います。これに焦点を当てているのが、オブジェクト・マネジメント・グループ (OMG) のモデル駆動型アーキテクチャー(MDA) (http://www.omg.org) イニシアチブです。
  • 関連する設計や実装から設計要素やコード要素を生成するために、標準パターンを適用することもできます。たとえば、標準変換パターンをデータ・テーブルに適用して、データ・テーブルにアクセスする Java クラスを作成できます。また、Eclipse モデリング・フレームワーク (http://www.eclipse.org/emf/) モデルを使用して、そのモデルと一致するデータを格納するコードを生成し、データを取り込むためのユーザー・インターフェース実装を生成することも可能です。

しかし、手作業で行うにしても、自動変換を適用するにしても、一部の設計の抽象概念を詳細化して実装に変換することはどんな場合でも同じです。

実装の完了 ページの先頭へ

前のステップで説明した方法で設計を実装に変換すると、程度の差はあっても実装は完了します。 これだけで、そのまま受け入れられる完全な実装になる場合もあります。 しかし通常は、実装を完了するためにかなりの労力が必要です。 たとえば、以下のような作業が考えられます。

  • 変換の結果を調整する作業 (パフォーマンスの改善やユーザー・インターフェースの改良など)。
  • 欠落している詳細を追加する作業。
    • 設計で記述されている操作の完了
    • サポートするクラス、操作、データ構造の追加

実装の評価 ページの先頭へ

この作業では、実装が目的に合っているかどうかを確認します。 テストに加えて、以下のような検査も有効です (テストについては、他の作業の箇所で説明しています)。

  • コードを読み通します。実装で生じた一般的なエラーのチェックリストを保持するのも一案です。
  • ツールを使用してコードのエラーをチェックします。たとえば、静的なコード・ルールのチェッカー・プログラムや、詳細な警告レベルを設定したコンパイラーなどを使います。
  • コードを視覚化できるツールを使用します。コードを視覚化すると、実装担当者は、過剰な結合や循環依存関係などのパターンを識別しやすくなります。

設計へのフィードバックの提供 ページの先頭へ

設計を実装してテストを行うと、設計に影響するエラーがどうしても見つかってしまいます。今後の保守作業あるいは契約や情報交換などのために設計の抽象概念を保持しておくのであれば、設計の更新が必要になります。

これをどのような方法で行うかは、プロジェクトの構成と変更管理のプロセスによって異なります。一般的に、必要な変更が少なく、クラスの設計と実装を同じ人が担当している場合、正式な変更依頼は必要ありません。その人が設計を変更できます。

パブリック操作への変更など、必要な変更が広範な影響を及ぼすのであれば、正式な変更依頼を提出しなければならない場合があります。



Rational Unified Process   2003.06.15