概念:
|
ライフサイクルで行う作業 |
追加トピック
|
コンポーネントに基づく開発は、一般的なアプリケーション開発の一種で、次のような特徴があります。
- アプリーションは、異なるチームによって相互に独立して開発または導入された、個別の実行可能なコンポーネントから組み立てられます。
- アプリケーションを構成するコンポーネントの一部だけをアップグレードして、アプリケーションを小規模な追加単位でアップグレードします。
- コンポーネントはアプリケーション間で共有できます。再利用が可能となりますが、プロジェクト間の依存関係が作成される場合もあります。
- コンポーネントに基づく開発に限られたことではありませんが、コンポーネントに基づくアプリケーションは分散される傾向があります。
「コンポーネント」という用語は、ここでは独立して開発されたコンポーネントや、個別に導入可能なコンポーネントを表すために使用しています。RUP のその他の状況では、「概念: コンポーネント」で説明されているような、より一般的な意味で使用し、必要に応じて意味を限定しています。
ここでは、コンポーネントに基づく開発を扱うための RUP (Rational Unified Process) の適応について議論します。
方向づけフェーズの基本ワークフローは、次のように拡張または変更して適用します。
作業: 開発企画書の作成の焦点を、コンポーネントの使用による開発のコスト構造の変化を考慮して調整します。特に、コンポーネントの開発コストを削減すると、コンポーネントの識別や、選択したコンポーネントが要件を満たしているかどうかの検証に必要な作業が増加します。
コンポーネントの手法を採用すると、特定のリスクの性質が変化したり、新しいリスクが生じます。次のような場合が考えられます。
作業: フェーズと反復の計画では、作成フェーズの計画に基づき、プロジェクトが並行する 2 つのプロジェクトに分割される可能性があります。1 つは、アプリケーション固有のコンポーネントとドメイン固有のコンポーネント (アーキテクチャの上位レイヤに編成されます。「概念: レイヤリング」を参照) を開発するプロジェクトで、もう 1 つは、下位レイヤに編成される非アプリケーションおよび非ドメイン固有のコンポーネントを開発するプロジェクトです。また、再利用可能なコンポーネントを、独立した開発チームが開発する場合もあります。並行作業を行うかどうかは、主に要員配置とリソースの問題で決まります。これらは、再利用可能なコンポーネントを、導入するアプリケーションと独立した資産として管理するという要求から行われます。
システムの要求を洗練する際に、選択したコンポーネント フレームワークによる制約を把握する必要があります。コンポーネント フレームワークは、ソフトウェア アーキテクトや設計者の自由度を制限することで、開発の生産性を一部向上させます。作業: ソフトウェア要求の詳細の作成では、これらの制約の文書化に焦点を当てる必要があります。
プロジェクトに対するテスト全体を表すテスト計画を作成し、「マスター テスト計画」と呼びます。
プロジェクトのガイドラインを収集または準備するときに、特定のコンポーネント フレームワークとその制約を考慮します。フレームワークを使用した設計とコード化の方法が記載されたガイドラインを準備します。これらのガイドラインでは、コンポーネント フレームワーク自身と、コンポーネント間で定義されたインターフェイスの両方に対する適合性を検証する方法のガイダンスも提供されます。
推敲フェーズの基本ワークフローは、次のように拡張または変更して適用します。
作業: ソフトウェア要求の詳細の作成では、技術的な要求と機能外要求、および作成または購入するコンポーネントによる制約に焦点を当てます。考慮が必要な機能外要求には、サイズ、性能、メモリまたはディスクのフットプリント、実行時のライセンスに関する問題、コンポーネントの選択または構築に影響を与えるその他の制約があります。
作業: アーキテクチャ分析では、コンポーネント フレームワークと技術的要求および機能外要求を使用して、第 1 次アーキテクチャを定義します。これには、第 1 次のレイヤリング スキーム、コンポーネントとサービスのデフォルト セットが含まれます (分析と設計のメカニズムとして表されます)。作業: ユース ケース分析では、アーキテクチャ上重要なユースケースから、アーキテクチャ上重要なコンポーネントを識別することに焦点を当てます。
作業: 実装モデルの構成では、コンポーネント フレームワーク構造と互換性のある実装モデル、開発チームの構成と責務を確立します。
作業: 設計メカニズムの識別では、特定のフレームワーク サービスとコンポーネントを考慮して、初期の設計メカニズムを洗練します。
作業: 設計要素の識別では、アーキテクチャ上重要なシステムの主要コンポーネントを識別します。再利用可能な責務は、再利用性を向上させるためにグループ化します。アプリケーション固有の機能は、領域に固有な機能や、アプリケーションと領域に依存しない機能から分離します。設計の目的では、コンポーネントは成果物: 設計サブシステムとして表すことができます。成果物: インターフェイスは、これらのコンポーネントとサブシステムに対して指定されます。
作業: 既存の設計要素の取り込みでは、識別されたコンポーネントに一貫性があり、以前の反復、フレームワーク自体、外部ソースで識別された既存のコンポーネントと互換性があることを確認します。
作業: 実行時アーキテクチャの記述では、コンポーネント フレームワークの基本プロセスとスレッド アーキテクチャを説明します。作業: 分散性の記述では、コンポーネント アプリケーションを実行する分散コンピューティング環境について説明します。
作業: サブシステム設計では、コンポーネントの設計をさらに洗練し、コンポーネント内のクラスを識別します。このクラスによって、コンポーネントの実際の振る舞いが決定されます。推敲フェーズの初期の段階では、ほとんどの場合、単一のクラスしかありません。これは、スタブとして機能して、アーキテクチャのプロトタイプ用にコンポーネントの振る舞いをシミュレートする「サブシステム / コンポーネント プロキシ」などです。プロジェクトが進むにつれ、このクラスの振る舞いはサブシステム内のクラスのコラボレーションとして分散されます。これらのクラスは、作業: クラス設計で洗練します。
推敲フェーズで重視するのは、永続的な計画がスケーラブルであること、データベース設計や永続的なメカニズムがシステムのスループットに関する要求をサポートすることです。永続的クラスが識別され、永続性メカニズムに割り当てられます。データ集約的なユース ケースが分析され、メカニズムがスケーラブルであることが確認されます。テストのワークフローの詳細と共に、永続性メカニズムとデータベース設計が評価され、検証されます。
作業: 設計要素の実装では、コンポーネント フレームワークによる制約に適合する必要があります。推敲フェーズでは、ほとんどのコンポーネントに大量のスタブ コードが含まれます。ここでの実装では、製品品質のコードを生成することよりも、アーキテクチャの検証が重視されます。
推敲フェーズのテスト作業では、アーキテクチャを検証することに重点を置きます。コンポーネントに基づくシステムでは、次の作業を行います。
コンポーネント フレームワークに内在する仮定を評価する必要もあります。一般的に、永続性メカニズムやトランザクション管理メカニズムのスケーラビリティやスループットが含まれます。メカニズム設計者による暗黙的な仮定がアプリケーション アーキテクチャによって理解されなければ、アプリケーション アーキテクチャが深刻な影響を受ける場合があります。
実装サブシステムを「責務の論理単位」として使用すると、作成作業を複数の並行した作業に分割できます。アプリケーション固有の機能に焦点を当てた作業と、再利用可能な汎用のコンポーネントに焦点を当てた作業になります。このような作業分割は、並行開発作業に十分な要員を確保できるかどうかに依存します。開発チームを分割し、並行作業を行うことができるかどうかは、アーキテクチャの安定性に完全に依存します。特に、コンポーネント間のインターフェイスの品質と安定性に大きく依存します。推敲フェーズにおける十分な作業により、作業の分割が可能になります。
作成フェーズの基本ワークフローは、次のように拡張または変更して適用します。
既に説明したように、作成フェーズの最初の反復計画は推敲フェーズの終わりに行います。2 回目の反復計画と、開発チームを分割して並行に作業できるかどうかは、引き続きアーキテクチャの安定性と、コンポーネント間のインターフェイスの品質と安定性に依存します。
作成フェーズでは、残りのユース ケースを分析し、ユース ケースの実現に適切なコンポーネントとコンポーネント コラボレーションを識別することに集中します。既存のアーキテクチャを拡張して完成させ、コンポーネントの内部的な振る舞いを完全に設計して実装します。
作成フェーズでは、データベース設計を完成させ、すべての永続的クラスがデータベースと永続性メカニズムの両方でサポートされることを確認します。この作業は、ワークフローの詳細: アーキテクチャの洗練とワークフローの詳細: コンポーネントの設計で行う作業と並行して、反復的に行います。理想的な組織では、統合されたコンポーネント チームが編成され、永続性に関する問題に対してチーム間で調整を行い、最適なデータベース設計が実現されます。
ここでの作業は推敲フェーズの作業と類似していますが、フェーズが進むにつれて、残りの詳細部分が完成します。
フェーズの進行と共に、システムが段階的に構築されます。
性能テストは引き続き重要ですが、機能テストの重要性も大きくなります。ここでは、機能の完全性、既存の機能の回帰テスト、期待される性能の実現に注目する必要があります。
Rational Unified Process
|