工作成果: 分析模型
這個工作成果定義一個物件模型來描述使用案例的實現,同時也是「設計模型」的抽象模型。
目的

分析模型包含分析類別及任何相關的工作成果。分析模型可能只是短暫的工作成果、從現狀逐步發展成為設計模型,或持續存在專案的一部分或整個期間,甚至更久,成為系統的概念性概觀。

關係
角色負責: 修改者:
輸入至強制:
選用: 外部:
輸出來源
主要說明
「分析模型」定義一個物件模型來描述使用案例的實現,同時也是工作成果:設計模型 . 「分析模型」包含使用案例分析的結果、工作成果:分析類別.
內容
選用
規劃Yes
調整
表示法選項

UML 表示法:模型,以 <<analysis model>> 為模板。 

分析模型可能有下列內容

  • 簡介:模型的簡介文字。 
  • 分析套件:模型中代表階層的套件。 
  • 類別:模型中由套件擁有的類別。  
  • 關係:模型中由套件擁有的關係。 
  • 使用案例實現化:模型中由套件擁有的使用案例實現化。
  • 圖型:模型中由套件擁有的圖型。 

「分析類別」通常會直接發展成「設計模型」中的元素:有些會變成設計類別,有些會變成設計子系統。 「分析」的目標是指出從必要行為至系統中建模元素之間的初步對映關係。 「設計」的目標是將此初步的(稍微理想化)對映轉換成一組可實作的模型元素。 因此,從「分析」進入「設計」時,細節和精準度都會提升。 因此,在「設計」活動中趨於穩定之前,「分析類別」通常相當不穩定、易變且變化巨大。

在決定是否需要個別的「分析模型」時,考量的重點如下:

  • 當必須針對多個目標環境以個別的設計架構來設計系統時,個別的「分析模型」很有用。 「分析模型」是「設計模型」的抽象或一般化概念。 省略許多設計細節,呈現系統功能的概觀。
  • 設計錯綜複雜,因此,需要以簡化、摘要的「設計」向新的團隊成員介紹設計。 同樣地,明確的架構也有相同的效果。
  • 確保「分析與設計」模型維持一致所需的額外付出,與一個系統觀點只表達系統如何運作的最重要細節,必須權衡兩者的利弊。 在「分析模型」和「設計模型」之間維持高度的精確性,也許要付出不少代價。 以設計中最重要的領域類別和關鍵抽象概念來維護「分析模型」,應該是較為溫和的作法。 維護成本會隨著「分析模型」的複雜性提高而增加。
  • 不再維護「分析模型」時,其價值將極速下降。等到不維護時,即完全無用,因為已不再準確反映系統的最新設計。 決定不再維護「分析模型」也許適當(因為已達成目的),但決策必須明確。

在某些公司中,系統已存在數十年或有各種不同的系統,個別的分析模型確實很有用。



詳細資訊
概念