UML 表示法:模型,以 <<analysis model>> 為模板。
分析模型可能有下列內容:
-
簡介:模型的簡介文字。
-
分析套件:模型中代表階層的套件。
-
類別:模型中由套件擁有的類別。
-
關係:模型中由套件擁有的關係。
-
使用案例實現化:模型中由套件擁有的使用案例實現化。
-
圖型:模型中由套件擁有的圖型。
「分析類別」通常會直接發展成「設計模型」中的元素:有些會變成設計類別,有些會變成設計子系統。 「分析」的目標是指出從必要行為至系統中建模元素之間的初步對映關係。 「設計」的目標是將此初步的(稍微理想化)對映轉換成一組可實作的模型元素。
因此,從「分析」進入「設計」時,細節和精準度都會提升。 因此,在「設計」活動中趨於穩定之前,「分析類別」通常相當不穩定、易變且變化巨大。
在決定是否需要個別的「分析模型」時,考量的重點如下:
-
當必須針對多個目標環境以個別的設計架構來設計系統時,個別的「分析模型」很有用。 「分析模型」是「設計模型」的抽象或一般化概念。 省略許多設計細節,呈現系統功能的概觀。
-
設計錯綜複雜,因此,需要以簡化、摘要的「設計」向新的團隊成員介紹設計。 同樣地,明確的架構也有相同的效果。
-
確保「分析與設計」模型維持一致所需的額外付出,與一個系統觀點只表達系統如何運作的最重要細節,必須權衡兩者的利弊。 在「分析模型」和「設計模型」之間維持高度的精確性,也許要付出不少代價。
以設計中最重要的領域類別和關鍵抽象概念來維護「分析模型」,應該是較為溫和的作法。 維護成本會隨著「分析模型」的複雜性提高而增加。
-
不再維護「分析模型」時,其價值將極速下降。等到不維護時,即完全無用,因為已不再準確反映系統的最新設計。 決定不再維護「分析模型」也許適當(因為已達成目的),但決策必須明確。
在某些公司中,系統已存在數十年或有各種不同的系統,個別的分析模型確實很有用。
|