作業: 納入現有的設計元素
這項作業說明如何發展和修正設計模型。
目的
  • 對分析類別的互動進行分析來尋找介面、設計類別和設計子系統
  • 修正架構,儘可能納入重複使用。
  • 識別常見設計問題的一般解決方案
  • 在軟體架構文件的「邏輯視圖」區段中,併入含架構重要性的設計模型元素。
關係
角色主要: 其他的: 協助:
輸入強制: 選用:
外部:
輸出
步驟
識別重複使用的機會
目的 識別哪裡可以根據現有子系統和/或元件的介面來重複使用子系統和/或元件。 

尋找提供類似介面的現有子系統或元件。 請比較每個所識別的介面和現有子系統或元件所提供的介面。它們通常不會完全相符,但可以找到大致相符的情況。請先尋找類似的行為和回覆值,再考慮各個參數。

修改新識別的介面來增進適合度。您可能會有機會對候選介面進行次要變更,使它更符合現有的介面。簡單變更包括重新安排參數,或將參數加入候選介面中,之後,再將介面分解成多個介面,其中一或多個介面符合現有元件的介面,且含有在個別介面中的「新」行為。

當完全相符時,利用現有的介面來取代候選的介面。 在簡化和分解之後,如果有完全符合現有介面的候選介面,請刪除候選介面,只用現有的介面。

將候選子系統對映到現有元件。 請查看現有的元件和候選子系統集。請分解子系統,以便儘可能利用現有元件來滿足所需要的系統行為。當現有元件實現候選子系統時,請建立設計子系統和實作模型元件之間的可追蹤性。

將子系統對映到可重複使用的元件時,請考慮子系統的相關設計機制;效能或安全需求可能會使元件不具重複使用的資格,即使作業簽章完美相符,也是如此。

元件和資料庫反向工程
目的 納入其他專案中有可能重複使用的模型元素,也許是來自外部來源,也可能是先前的反覆。 

您可以「清除」現有的程式碼和資料庫定義,以便在現行專案/反覆所能使用的先前的專案或反覆上工作。您可以利用潛在可重複使用的機會作為過濾器,只將反向工程的焦點放在現行反覆所能重複使用的元件上。

元件反向工程

在建置類似系統的組織中,通常會有一組共用元件,用來提供新系統所需要的許多架構機制。業界也可能會有元件可以提供架構機制。您應該檢查現有的元件來判斷它們在軟體架構內的適用性和相容性。

現有元件,不論是先前的反覆期間所開發而尚未併入設計模型的元件,或是購買的元件,都必須在反向工程之後,納入設計模型。在設計模型中,通常會將這些元件表現為含有一或多個介面的子系統。

資料庫反向工程

資料庫及其中的資料代表可重複使用的資產最重要的來源。如果要重複使用內含在現有資料庫中的隱含類別定義,請確定現有資料庫中已有應用程式所用的哪些資訊。請反向工程一組類別來代表保留這項資訊的資料庫結構。這時也要建構應用程式類別表示法和資料庫所用的結構之間的對映。 如需資料庫反向工程的相關資訊,請參閱工作成果準則:關聯式資料庫反向工程。如果要進一步瞭解類別和關聯式資料庫表格之間的對映,請參閱工作成果準則:資料模型

更新設計模型的組織
目的 說明設計模型組織中的新模型元素。
在必要之時,重新平衡設計模型的結構。 

在新元素加入設計模型之後,通常需要重新套裝設計模型的元素。重新套裝可以實現許多目標:它會在設計模型中,降低套件之間的耦合性,增進套件的內聚力。最終目標是可以區分個人或小組,使不同套件(和子系統)的設計和開發可以彼此獨立進行。完全獨立大概不可能,但使套件之間的耦合性鬆散,往往會使大型或複雜系統的開發更容易。

「平面」模型結構(所有套件和子系統都在系統的相同概念層次)適合小系統;較大的系統需要稱為「分層」的其他結構工具(請參閱工作成果準則:分層)。分層規則會定義特定套件類型之間的可用關係限制。這些規則會辨認出不應存在的特定相依性:應用程式功能不應直接相依於特定作業系統或視窗系統服務,應該有一個中間層包含邏輯作業系統以及從低階實作服務的變更說明應用程式功能的視窗服務。分層提供一種方式來降低變更的影響:強制採用某些規則來限制套件和子系統之間的相依性,降低套件和子系統之間的耦合性程度,系統會變得更強韌。它能容忍變更。

當系統中加入新的模型元素時,現有套件可能會長得太大,以致於單一小組無法管理它:這時必須將套件分成幾個套件,它們的套件內聚性強,但套件之間的耦合性鬆散。這可能很困難,有些元素可能很難放在特定套件內,因為兩個套件的元素都會用到它們。可能的解決方案有兩個:將元素分割成多個物件,每個套件中各一個(當元素有多重「特質」或多組離散責任時,適合這個方式),或將元素移到較低層的套件中,讓所有較高層的元素平等依賴它。

當系統越來越複雜時,會需要更多層次,才能夠保持可維護、可理解的結構。不過,即使在最大的系統中,超出 7-10 層也很不尋常,因為越多層,會越複雜,越難理解。

以下顯示分層的範例,其中包括中介軟體和系統軟體層:

Java/Web 應用程式的佈置圖

Java/Web 型應用程式的套件分層範例。附註:對於 TCP/IP 套件的相依性通常不會明確建模,因為 TCP/IP 服務的使用封裝在 Java VM、java.rmi 和 Web 瀏覽器內。這裡描述它們只是為了說明。

請將子系統和層次的責任指派給個人或小組。每個套件或子系統都應該由一個人(小範圍)或小組(大範圍)來負責。

更新邏輯視圖

當從架構的角度來看,設計類別、套件和子系統(模型元素)很重要時,它們應該併入工作成果:軟體架構文件的「邏輯觀點」一節中。這可以確保其他專案小組成員能夠得知含架構重要性的新模型元素。

另外,軟體架構師角色會與流程工程師角色協同作業,為設計者和實作者提供如何使用新納入的設計元素之詳細指引。



內容
多次出現的項目
事件驅動
持續進行中
選用
規劃
可重複的
詳細資訊