準則: 分析 & 設計中的重要決策
這個準則說明調整流程的「分析與設計」方面時的重要事項。
關係
主要說明

決定如何使用工作成果

決定要使用什麼工作成果及如何使用。除了指出要使用什麼工作成果之外,也必須調整要使用的每一個工作成果,以符合專案的需求。 

下表指出建議哪些「分析與設計」工作成果及哪些可視為選用(亦即,只在特定的情況下使用)。 至於其他調整注意事項,請參閱工作成果說明頁的調整章節。

工作成果 目的

調整(選用、建議)

分析模型分析類別 分析模型可協助您在進行設計決策之前,更充分瞭解需求。對於複雜系統,您可以維護分析模型來提供系統的概念性概觀。

選用

許多專案都利用起始設計模型來取代分析模型。

如果是會建立分析模型的專案,分析模型通常都是一個將發展成設計模型的暫時構件。

導覽圖使用者介面原型

使用者介面大而複雜的專案應該考量使用者介面設計。

選用

在較小型的開發工作上,較不正式的使用者介面設計可能已經足夠。

設計模型

大部分系統都應該先設計,再實作,以免因設計錯誤而虛耗重做成本。即使系統較小,也是如此。視覺化模型使設計上的溝通變成非常容易。正推和反向工程的工具可以確保與實作模型一致,且可以節省工作。

建議大部分專案採用。

如果專案較小,自動化工具的使用並不很重要,但它們仍有長程的生產力優勢。

設計類別設計套件

類別和套件是物件導向設計的基本部分。物件導向設計是大部分專案都採用的標準設計。

建議大部分專案採用。

主要調整問題是決定要用哪些模板(這可以擷取放在「設計準則」中)。

使用案例實現化

提供從使用案例到設計的橋樑。

建議大部分專案採用。

介面

介面通常用來定義與實現行為的大粒度元件無關的行為。

建議大部分專案採用。

以元件為基礎的設計正逐漸成為標準設計方式。

設計子系統

設計子系統用來將行為封裝在提供介面的元件內。它用來封裝類別和/或其他子系統的互動。

建議大部分專案採用。

子系統通常用來提高設計的抽象層次。它們使系統成為比較容易理解。

事件

對於回應許多外部事件的系統而言,可能很有幫助。 建議即時系統採用。

通訊協定

即時系統需要。 建議即時系統採用。

信號

對於需要並行功能且由事件驅動的系統而言,可能很有幫助。

即時系統需要。

對於需要並行功能且由事件驅動的系統而言,可能很有幫助。

建議即時系統採用。

封裝體

適用於即時系統,但對於任何高並行度的系統而言,在建模和設計時,都可能很有幫助。

建議即時系統採用。

資料模型 用來說明持續性資訊的邏輯結構,實體結構可能也包括在內。

建議使用資料庫的專案採用。

部署模型 顯示執行時期處理節點的配置、它們之間的通訊鏈結,以及其中的元件實例和物件。

選用。

許多系統都有多個處理節點,因而需要處理部署模型。不過,它可以擷取成軟體架構文件的一個章節,不需要成為單獨識別的構件。

架構概念實證 用來判斷是否有解決方案可以滿足含架構重要性的需求。 建議大部分專案採用。

許多專案都利用架構概念證明來判斷需求的可行性。它有許多形式,例如:

  • 解決方案可能適用的已知技術清單
  • 解決方案概念模型的草稿
  • 解決方案的模擬
  • 可執行的原型。
參照架構 參照架構會重複使用已證明的解決方案,以降低風險,加快開發速度。

建議大部分專案採用。

如果有適當的參照架構資料,它可以大幅降低風險,加快開發速度。

軟體架構文件 (SAD) 軟體架構文件用來提供系統的綜合性架構概觀。這個概觀有助於瞭解系統,擷取主要架構決策。

建議大部分專案採用。

除了最小的系統,高階軟體架構概觀對所有系統都很有幫助。相較於小專案,複雜系統通常都需要較詳細的層次,也需要較多視圖。

使用者介面原型 在開始真正的開發之前,用來顯現和測試功能和可用性。這是先驗證設計以免後來浪費太多時間的有效方法。

建議大部分專案採用。



決定使用哪些報告

使用哪些報告的決策,取決於專案所能使用的報告工具。如果能夠得到產生報告的工具,我們建議您針對模型導向的工作成果來產生報告,如「設計類別」和「使用案例實現化」。您可以從工作成果說明頁面中取得 RUP 配置現有的報告,或在目錄樹瀏覽器中,將它們分組在相關工作成果之下。

決定如何檢視

決定在每一個要使用的工作成果上採取的審查層次。尤其是決定如何審查和核准「分析和設計」結果,以及結果應該審查到什麼程度。  

在「分析與設計」期間進行審查的優點包括:

  • 偵測出在測試時不可能或很難發覺的問題。例如,樣式和配置的問題。 
  • 貫徹共同的建模樣式,讓每個人有機會互相學習。 
  • 提早偵測到專案在以後測試時才會發現的缺失。

在「分析與設計」期間進行審查的缺點如下:

  • 耗用時間和資源。 
  • 一旦管理不善,容易濫用。

「分析與設計」可能改變的因數包括技術、資源及範圍。以下是您可以決定用來處理專案的動作範例:

  • 決定只由一位同層級伙伴來檢視子系統的本端變更,這位伙伴進行檢驗,再將結果寫在紙上。
  • 決定完全不檢視設計的哪些部分;例如,只檢視專案每個成員的某些類別,希望這可以確保樣式的品質類似於結果的其餘部分。
  • 決定在個別會議期間,由客戶來檢視軟體架構文件。
  • 決定利用正式檢視會議來處理重要介面(也就是會影響多個專案成員之工作的介面)的變更。

如需審查層次的相關資訊,請參閱準則:審查層次。 

決定是否產生程式碼

您的設計方式會隨著是否從設計模型中產生程式碼而有所不同。如果您產生程式碼,設計就必須非常詳細。從另一方面來說,如果您並不從設計產生程式碼,設計就不需要非常詳細。相反地,這時您必須用手動方式來同步處理設計的細節和程式碼。