このワークフローの詳細の目的は、1 回の反復のアーキテクチャを完了することです。

トピック


      設計モデル
設計モデル
ソフトウェア アーキテクチャ説明書
ソフトウェア アーキテクチャ説明書
  設計モデル
設計モデル
ソフトウェア アーキテクチャ説明書
ソフトウェア アーキテクチャ説明書
  分析クラス
分析クラス
  分析クラス
分析クラス
  ソフトウェア アーキテクチャ説明書
ソフトウェア アーキテクチャ説明書
設計モデル
設計モデル
 
               
 
ソフトウェア アーキテクト
ソフトウェア アーキテクト
 

 
分散性の記述
分散性の記述

 
実行時アーキテクチャの記述
実行時アーキテクチャの記述

 
設計要素の識別
設計要素の識別

 
設計メカニズムの識別
設計メカニズムの識別

 
既存の設計要素の取り込み
既存の設計要素の取り込み

 
               
      配置モデル
配置モデル
ソフトウェア アーキテクチャ説明書
ソフトウェア アーキテクチャ説明書
  設計モデル
設計モデル
ソフトウェア アーキテクチャ説明書
ソフトウェア アーキテクチャ説明書
  設計サブシステム
設計サブシステム
設計モデル
設計モデル
  設計モデル
設計モデル
ソフトウェア アーキテクチャ説明書
ソフトウェア アーキテクチャ説明書
  設計モデル
設計モデル
ソフトウェア アーキテクチャ説明書
ソフトウェア アーキテクチャ説明書
 
              設計パッケージ
設計パッケージ
シグナル
シグナル
  設計パッケージ
設計パッケージ
設計サブシステム
設計サブシステム
  設計パッケージ
設計パッケージ
設計サブシステム
設計サブシステム
 
              イベント
イベント
設計クラス
設計クラス
  設計クラス
設計クラス
  インターフェイス
インターフェイス
設計クラス
設計クラス
 
              Enterprise Java Beans (EJB)
Enterprise
Java Beans
(EJB)
インターフェイス
インターフェイス
         

      リスク リスト
リスク リスト
ソフトウェア アーキテクチャ説明書
ソフトウェア アーキテクチャ説明書
 
       
 
テクニカル レビュー担当者
テクニカル レビュー担当者
 

 
アーキテクチャのレビュー
アーキテクチャのレビュー

 
       
      レビュー記録
レビュー記録
 


説明 ページの先頭へ

このワークフローの詳細では、次のことを行います。

  • 作業を設計するための自然な分析からの移行作業を提供し、次のものを識別する
    • 分析要素から適切な設計の要素を識別する
    • 関連する分析メカニズムから適切な設計メカニズムを識別する
  • システムの実行時アーキテクチャと配置アーキテクチャの組織を記述する
  • 設計と実装の間の移行をシームレスにするように実装モデルを組織する
  • 次のことが保証されるようにアーキテクチャの一貫性と統合を保持する
    • 現在の反復で識別される新しい設計の要素が、既に存在する設計の要素と統合される
    • 設計のできる限り早い段階に、使用可能なコンポーネントと設計の要素の最大限の再利用を実現する

関連情報 ページの先頭へ

このワークフローの詳細に関連する追加情報へのリンクを提供します。

タイミング ページの先頭へ

推敲フェーズで開始し、作成フェーズと移行フェーズで繰り返します。

オプション度 ページの先頭へ

必須

要員配置方法 ページの先頭へ

この作業の実行に最も適しているのは、異なる部門のメンバーを配置した小さいチームです。 アーキテクチャ上重要な問題の典型は、使いやすさ、性能、スケーリング、プロセスとスレッドの同期、分散などです。このチームには、ドメインの経験を持ち主要な抽象化を識別できるメンバーも含める必要があります。また、このチームはモデルの組織とレイヤリングの経験を持つ必要があります。このチームは、これらの異種のスレッドを、(予備的ではあるが) まとまっていて首尾一貫しているアーキテクチャにできる必要があります。

アーキテクチャの作業の重点が実装の問題に移行しようとしているので、特定の技術の問題に対する注意を高める必要があります。したがって、アーキテクチャ チームは、メンバーを入れ替えるか、(アーキテクチャ上重要な問題の場合は) 分散と導入の専門技術を持つメンバーを入れてチームを拡大しなければなりません。統合しやすさについて実装モデルに構造が与える潜在的な影響を理解するには、ソフトウェアのビルド管理プロセスの専門技術があると役立ちます。

同時に、アーキテクチャ チームを 1 つの大きな拡張されたチームで構成しないようにすることが不可欠です。この傾向に逆らうための戦略は、中心となるチームを比較的小さく保持し、主要な問題に関する「コンサルタント」として招かれた拡張のチーム メンバーでサテライト グループを構成することです。 小規模のプロジェクトで特定の専門技術をほかの組織から借りるか、ほかの組織に外注する場合も、この構造がうまく機能します。特定の問題の対処が必要になったときに、こうした組織を招くことができます。

作業ガイドライン ページの先頭へ

作業の最もよい実行方法は、複数のセッションに分け、数日 (大規模システムの場合は数週間~数か月) かけて実行することです。初期に重点が置かれる作業は、「設計メカニズムの識別」と「設計要素の識別」です。「既存の設計要素の取り込み」の作業は何回も反復され、新しい要素が既存の要素の機能と重複しないことが確認されます。

設計が浮かび上がるにつれて、「実行時アーキテクチャの記述」と「分散性の記述」のそれぞれの作業に、並行性と分散の問題が導入されます。これらの問題の検討が進むにつれて、プロセス、スレッド、ノードの間で振る舞いを分割するように設計の要素に変更を加える必要が出てくることがあります。

個別のモデルを洗練してアーキテクチャの決定を取り込むにつれて、その結果が、ソフトウェア アーキテクチャ説明書のそれぞれのビューのセクションに記録されます (たとえば、設計モデルが洗練されると、ソフトウェア アーキテクチャ説明書の論理ビューも洗練されます)。その結果として作成されたアーキテクチャがレビューされます。



Rational Unified Process   2003.06.15