工作成果: 軟體架構文件
這個工作成果為系統提供一個綜合性的架構概觀,以許多不同的架構觀點來描述系統的不同層面。
目的

軟體架構文件為軟體系統的架構提供一個綜合性的概觀。在專案已做出的重大架構性決策上,可以做為軟體架構師與其他專案團隊成員之間的溝通媒介。

關係
角色負責: 修改者:
輸入至強制: 選用:
外部:
輸出來源
內容
選用
規劃Yes
圖例
調整
表示法選項UML 表示法:一套相關的架構觀點:使用案例、邏輯、流程、部署、實作、資料。

您應該調整軟體架構文件的大綱來符合軟體的本質:

  • 有些架構觀點可能不適合:
    • 單 CUP 系統不需要「部署觀點」。
    • 如果系統只使用單一控制緒,則不需要「流程觀點」。
    • 除非物件持續性在系統中很重要,持續性機制還需要持續和非持續物件之間的對映,否則不需要「資料觀點」。
  • 軟體的某些特定方面可能需要有自己的區段;例如,有關資料管理或使用性問題等方面。
  • 您可能需要加上其他附錄來解釋特定的層面,例如某些重大選擇的理由加上已排除的解決方案,或定義字首語或縮寫,或描述一般的設計原則。
  • 視系統的關係人及關切重點而定,各區段的順序可能不同。

每一個架構觀點的優缺點如下:

使用案例觀點

這是必要觀點。

邏輯觀點

這是必要觀點。

流程觀點

這是選用觀點。如果系統有多個控制緒,且執行緒交錯或彼此相依,此時才需要採用這個觀點。

部署觀點

這是選用觀點。如果系統橫跨多個節點,此時才需要採用這個觀點。 即使如此,也只有當分佈情形有架構含意時,才需要採用部署觀點。 例如,假設有一部伺服器和多個用戶端,部署觀點只需要以一群節點來描述伺服器和用戶端的責任;如果用戶端節點全部都是相同的功能,則不必顯示每一個用戶端節點。

實作觀點

這是選用觀點。如果實作不受設計的嚴格限制,亦即「設計」和「實作」模型中相對應的套件之間有不同的責任分配,此時才需要採用這個觀點。 如果設計和實作模型的包裝完全相同,則可以省略這個觀點。

資料觀點

這是選用觀點。如果持續性在系統中很重要,且「設計模型」至「資料模型」的轉換不是由持續性機制自動來完成,此時才需要採用這個觀點。



詳細資訊