工作成果
|
目的
|
調整(選用、建議)
|
分析模型(分析類別)
|
分析模型可協助您在進行設計決策之前,更充分瞭解需求。對於複雜系統,您可以維護分析模型來提供系統的概念性概觀。
|
選用
許多專案都利用起始設計模型來取代分析模型。
如果是會建立分析模型的專案,分析模型通常都是一個將發展成設計模型的暫時構件。
|
導覽圖、使用者介面原型
|
使用者介面大而複雜的專案應該考量使用者介面設計。
|
選用
在較小型的開發工作上,較不正式的使用者介面設計可能已經足夠。
|
設計模型
|
大部分系統都應該先設計,再實作,以免因設計錯誤而虛耗重做成本。即使系統較小,也是如此。視覺化模型使設計上的溝通變成非常容易。正推和反向工程的工具可以確保與實作模型一致,且可以節省工作。
|
建議大部分專案採用。
如果專案較小,自動化工具的使用並不很重要,但它們仍有長程的生產力優勢。
|
設計類別;設計套件
|
類別和套件是物件導向設計的基本部分。物件導向設計是大部分專案都採用的標準設計。
|
建議大部分專案採用。
主要調整問題是決定要用哪些模板(這可以擷取放在「設計準則」中)。
|
使用案例實現化
|
提供從使用案例到設計的橋樑。
|
建議大部分專案採用。
|
介面
|
介面通常用來定義與實現行為的大粒度元件無關的行為。
|
建議大部分專案採用。
以元件為基礎的設計正逐漸成為標準設計方式。
|
設計子系統
|
設計子系統用來將行為封裝在提供介面的元件內。它用來封裝類別和/或其他子系統的互動。
|
建議大部分專案採用。
子系統通常用來提高設計的抽象層次。它們使系統成為比較容易理解。
|
事件
|
對於回應許多外部事件的系統而言,可能很有幫助。
|
建議即時系統採用。
|
通訊協定
|
即時系統需要。
|
建議即時系統採用。
|
信號
|
對於需要並行功能且由事件驅動的系統而言,可能很有幫助。
即時系統需要。
|
對於需要並行功能且由事件驅動的系統而言,可能很有幫助。
建議即時系統採用。
|
封裝體
|
適用於即時系統,但對於任何高並行度的系統而言,在建模和設計時,都可能很有幫助。
|
建議即時系統採用。
|
資料模型
|
用來說明持續性資訊的邏輯結構,實體結構可能也包括在內。
|
建議使用資料庫的專案採用。
|
部署模型
|
顯示執行時期處理節點的配置、它們之間的通訊鏈結,以及其中的元件實例和物件。
|
選用。
許多系統都有多個處理節點,因而需要處理部署模型。不過,它可以擷取成軟體架構文件的一個章節,不需要成為單獨識別的構件。
|
架構概念實證
|
用來判斷是否有解決方案可以滿足含架構重要性的需求。
|
建議大部分專案採用。
許多專案都利用架構概念證明來判斷需求的可行性。它有許多形式,例如:
-
解決方案可能適用的已知技術清單
-
解決方案概念模型的草稿
-
解決方案的模擬
-
可執行的原型。
|
參照架構
|
參照架構會重複使用已證明的解決方案,以降低風險,加快開發速度。
|
建議大部分專案採用。
如果有適當的參照架構資料,它可以大幅降低風險,加快開發速度。
|
軟體架構文件 (SAD)
|
軟體架構文件用來提供系統的綜合性架構概觀。這個概觀有助於瞭解系統,擷取主要架構決策。
|
建議大部分專案採用。
除了最小的系統,高階軟體架構概觀對所有系統都很有幫助。相較於小專案,複雜系統通常都需要較詳細的層次,也需要較多視圖。
|
使用者介面原型
|
在開始真正的開發之前,用來顯現和測試功能和可用性。這是先驗證設計以免後來浪費太多時間的有效方法。
|
建議大部分專案採用。
|