概念: コンポーネント ソリューションの開発

トピック
ライフサイクルで行う作業
  1. 概論
  2. 方向づけフェーズの作業
  3. 推敲フェーズの作業
  4. 作成フェーズの作業
  5. 移行フェーズの作業
追加トピック

概論 ページの先頭へ

コンポーネントに基づく開発は、一般的なアプリケーション開発の一種で、次のような特徴があります。

  • アプリーションは、異なるチームによって相互に独立して開発または導入された、個別の実行可能なコンポーネントから組み立てられます
  • アプリケーションを構成するコンポーネントの一部だけをアップグレードして、アプリケーションを小規模な追加単位でアップグレードします。
  • コンポーネントはアプリケーション間で共有できます。再利用が可能となりますが、プロジェクト間の依存関係が作成される場合もあります。
  • コンポーネントに基づく開発に限られたことではありませんが、コンポーネントに基づくアプリケーションは分散される傾向があります。

「コンポーネント」という用語は、ここでは独立して開発されたコンポーネントや、個別に導入可能なコンポーネントを表すために使用しています。RUP のその他の状況では、「概念: コンポーネント」で説明されているような、より一般的な意味で使用し、必要に応じて意味を限定しています。

ここでは、コンポーネントに基づく開発を扱うための RUP (Rational Unified Process) の適応について議論します。

方向づけフェーズの作業 ページの先頭へ

方向づけフェーズの基本ワークフローは、次のように拡張または変更して適用します。

プロジェクト管理

  • ../process/workflow/manageme/wfs_eval.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんワークフローの詳細: プロジェクトの開発範囲とリスクの評価
  • コンポーネントの手法を採用すると、特定のリスクの性質が変化したり、新しいリスクが生じます。次のような場合が考えられます。

    • 外部で作成されたコンポーネントを使用すると、リスクが増大します。これらのコンポーネントから、プロジェクト チームが直接管理していない重大な要素が導入されます。
    • 外部で作成されたコンポーネントを使用すると、開発時間が削減され、リソースのリスクが減少します。
    • 外部で作成されたコンポーネントがアーキテクチャに対して強い制約を持つ場合、システムのアーキテクチャにひずみが生じる場合があります。
  • ../process/workflow/manageme/wfs_sdp.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんワークフローの詳細: プロジェクトの計画
  • 作業: フェーズと反復の計画では、作成フェーズの計画に基づき、プロジェクトが並行する 2 つのプロジェクトに分割される可能性があります。1 つは、アプリケーション固有のコンポーネントとドメイン固有のコンポーネント (アーキテクチャの上位レイヤに編成されます。「概念: レイヤリング」を参照) を開発するプロジェクトで、もう 1 つは、下位レイヤに編成される非アプリケーションおよび非ドメイン固有のコンポーネントを開発するプロジェクトです。また、再利用可能なコンポーネントを、独立した開発チームが開発する場合もあります。並行作業を行うかどうかは、主に要員配置とリソースの問題で決まります。これらは、再利用可能なコンポーネントを、導入するアプリケーションと独立した資産として管理するという要求から行われます。

要求

テスト

環境

  • ../process/workflow/environm/wfs_env1.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんワークフローの詳細: プロジェクトのための環境準備
  • プロジェクトのガイドラインを収集または準備するときに、特定のコンポーネント フレームワークとその制約を考慮します。フレームワークを使用した設計とコード化の方法が記載されたガイドラインを準備します。これらのガイドラインでは、コンポーネント フレームワーク自身と、コンポーネント間で定義されたインターフェイスの両方に対する適合性を検証する方法のガイダンスも提供されます。

推敲フェーズの作業 ページの先頭へ

推敲フェーズの基本ワークフローは、次のように拡張または変更して適用します。

要求

分析と設計

  • ワークフローの詳細: コンポーネントの設計
  • 作業: サブシステム設計では、コンポーネントの設計をさらに洗練し、コンポーネント内のクラスを識別します。このクラスによって、コンポーネントの実際の振る舞いが決定されます。推敲フェーズの初期の段階では、ほとんどの場合、単一のクラスしかありません。これは、スタブとして機能して、アーキテクチャのプロトタイプ用にコンポーネントの振る舞いをシミュレートする「サブシステム / コンポーネント プロキシ」などです。プロジェクトが進むにつれ、このクラスの振る舞いはサブシステム内のクラスのコラボレーションとして分散されます。これらのクラスは、作業: クラス設計で洗練します。

  • ワークフローの詳細: データベースの設計
  • 推敲フェーズで重視するのは、永続的な計画がスケーラブルであること、データベース設計や永続的なメカニズムがシステムのスループットに関する要求をサポートすることです。永続的クラスが識別され、永続性メカニズムに割り当てられます。データ集約的なユース ケースが分析され、メカニズムがスケーラブルであることが確認されます。テストのワークフローの詳細と共に、永続性メカニズムとデータベース設計が評価され、検証されます。

実装

  • ワークフローの詳細: コンポーネントの実装

    作業: 設計要素の実装では、コンポーネント フレームワークによる制約に適合する必要があります。推敲フェーズでは、ほとんどのコンポーネントに大量のスタブ コードが含まれます。ここでの実装では、製品品質のコードを生成することよりも、アーキテクチャの検証が重視されます。

テスト

  • ワークフローの詳細: ../process/workflow/test/wfs_dfnevlmsn.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません評価目標の決定../process/workflow/test/wfs_tstandevl.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんテストと評価../process/workflow/test/wfs_achmsnacp.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません受け入れ目標の達成

    推敲フェーズのテスト作業では、アーキテクチャを検証することに重点を置きます。コンポーネントに基づくシステムでは、次の作業を行います。

    • コンポーネント間のインターフェイスをテストして、コンポーネントの境界が適切であることを確認します。
    • 性能テストを重視します。特に、性能のスケーラビリティに関するテストを重視して、予測されるトランザクション量に対応できることを確認します。

    コンポーネント フレームワークに内在する仮定を評価する必要もあります。一般的に、永続性メカニズムやトランザクション管理メカニズムのスケーラビリティやスループットが含まれます。メカニズム設計者による暗黙的な仮定がアプリケーション アーキテクチャによって理解されなければ、アプリケーション アーキテクチャが深刻な影響を受ける場合があります。

プロジェクト管理

  • ../process/workflow/manageme/wfs_plan.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんワークフローの詳細: 次の反復計画

    実装サブシステムを「責務の論理単位」として使用すると、作成作業を複数の並行した作業に分割できます。アプリケーション固有の機能に焦点を当てた作業と、再利用可能な汎用のコンポーネントに焦点を当てた作業になります。このような作業分割は、並行開発作業に十分な要員を確保できるかどうかに依存します。開発チームを分割し、並行作業を行うことができるかどうかは、アーキテクチャの安定性に完全に依存します。特に、コンポーネント間のインターフェイスの品質と安定性に大きく依存します。推敲フェーズにおける十分な作業により、作業の分割が可能になります。

作成フェーズの作業 ページの先頭へ

作成フェーズの基本ワークフローは、次のように拡張または変更して適用します。

プロジェクト管理

  • ../process/workflow/manageme/wfs_plan.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんワークフローの詳細: 次の反復計画

    既に説明したように、作成フェーズの最初の反復計画は推敲フェーズの終わりに行います。2 回目の反復計画と、開発チームを分割して並行に作業できるかどうかは、引き続きアーキテクチャの安定性と、コンポーネント間のインターフェイスの品質と安定性に依存します。

分析と設計

実装

テスト

    性能テストは引き続き重要ですが、機能テストの重要性も大きくなります。ここでは、機能の完全性、既存の機能の回帰テスト、期待される性能の実現に注目する必要があります。

移行フェーズの作業 ページの先頭へ

  • 現在、Web 環境での製品リリースが増加傾向にあり、従来のメディアによる配布は減少しつつあります。リリース計画は、このような傾向に応じて調整する必要があります。
  • このフェーズでは、製品サポートを特に重視します。
  • データ変換作業を実行します。

Rational Unified Process   2003.06.15