このワークフローの詳細の目的は、ソフトウェア アーキテクチャの初期スケッチを作成することです。


トピック

      ユース ケース
ユース ケース
 
       
 
設計者
設計者
 

 
ユース ケース分析
ユース ケース分析

 
       
      分析クラス
分析クラス
ユース・ケースの実現
ユース・ケースの実現
 
      分析モデル
分析モデル
 

      リスク リスト
リスク リスト
 
      用語集
用語集
開発構想
開発構想
 
       
 
ソフトウェア アーキテクト
ソフトウェア アーキテクト
 

 
アーキテクチャ分析
アーキテクチャ分析

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


説明 ページの先頭へ

このワークフローの詳細の目標は次のとおりです。

  • システムのアーキテクチャの初期スケッチを作成する
    • 分析の基礎として使用されるアーキテクチャ上重要な要素の初期セットを定義する
    • 分析メカニズムの初期セットを定義する
    • システムの初期のレイヤリングと組織を定義する
    • 現在の反復で対処されるユース ケースの実現を定義する
  • アーキテクチャ上重要なユース ケースから分析クラスを識別する
  • 分析クラスの相互作用を使用してユース ケースの実現を更新する

関連情報 ページの先頭へ

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

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

推敲フェーズの初期の部分

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

必須

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

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

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

作業の最もよい実行方法は、複数のセッションに分け、数日 (大規模システムの場合は数週間~数か月) かけて実行し、「アーキテクチャ分析」と「ユース ケース分析」の間で反復する方法です。「アーキテクチャ分析」でアーキテクチャの初期段階を実行してから、アーキテクチャ上重要なユース ケースを選択し、ユース ケースごとに「ユース ケース分析」を実行します。ユース ケースの分析を 1 つ終える (または進める) たびに、必要に応じてアーキテクチャを更新し、システムの新しい振る舞いに対応するために必要な適応の反映、アーキテクチャに発生する可能性があると識別された問題の対処を行います。

(以前のプロジェクトまたは反復で作成された) アーキテクチャが既に存在する場合は、システムがサポートしなければならない新しい振る舞いを説明できるようにアーキテクチャを変更する変更依頼の作成が必要になることがあります。この変更は、変更の範囲に応じたプロセス内の成果物に加えられます。



Rational Unified Process   2003.06.15