重用，粒度，模式和穩健性的常見錯誤以及如何糾正它們

重複使用，粒度，模式和穩健性的常見錯誤以及如何糾正它們

常見錯誤	糾正錯誤	舉例
只考慮“有”重用而不是“重用”	制定策略以開發可重用的類以供將來使用; 確保人們理解“for”重用需要額外的貢獻，並且管理層準備承認對未來利益的貢獻。	請參見圖15.1，其中顯示了重用的兩個方面。
建立隨機大小的類	檢查專案的粒度需求，並確保解決方案空間中的類的平衡大小。	重新閱讀圖15.3及其周圍的討論，以瞭解實踐中的粒度。
不將設計重用與執行時重用分開	設計重用側重於使用繼承的類的結構; 執行時重用基於對已經例項化的服務的“呼叫”。	有關不同型別重用的示例，請參見圖15.1; 然後考慮設計和執行時重用之間的區別。
將設計模式視為實施模式	設計模式正是抽象的思維過程。 它們需要轉換為針對特定現實情況的實現。	參見圖15.4和15.5作為實現設計模式的實際示例。
在穩健性方面走向“極端”	並非每個實際設計都遵循穩健性 - 主要是因為這種穩健性會在執行時增加大量開銷。	重新訪問圖15.9，瞭解在實踐中如何應用健壯性。
忽略建立系統架構和設計的過程和步驟	遵循系統架構和設計的過程有助於重用和質量。	例如，通過利用在前一次迭代/專案中開發的“重用”類來“重用”設計類。
不分離架構的功能和技術方面	系統架構的功能和技術層相互交叉。 功能層表示系統的行為，而技術層表示資料庫，規則和介面。	重新閱讀圖15.10，以進一步瞭解系統的功能層和技術層之間的差異。 使用該資訊建立基本系統體系結構。

魯棒是Robust的音譯，也就是健壯和強壯的意思。 它是在異常和危險情況下系統生存的關鍵。 比如說，計算機軟體在輸入錯誤、磁碟故障、網路過載或有意攻擊情況下，能否不宕機、不崩潰，就是該軟體的魯棒性。 所謂“魯棒性”，是指控制系統在一定（結構，大小）的引數攝動下，維持其它某些效能的特性。

學習目標

◾瞭解軟體可重用性的各種級別，型別和方法

◾瞭解類設計粒度對系統的可重用性和可維護性的影響

◾應用設計模式以提高類圖的質量

◾在面向物件設計中應用魯棒性概念，以提高系統的可維護性

◾瞭解基本系統架構（特定於軟體）並將其與封裝圖相關聯簡介

本章討論軟體工程中的一些高階概念，這些概念在解決方案和架構建模空間（MOSS，MOAS）中具有特殊價值。這些高階概念基於早期對類和序列圖的討論。

本討論的重點是建立一個健壯，可重用且高質量的軟體設計。這種高質量的設計對於當前專案之外的組織具有價值。本章的討論包括可重用性，理解“with”和“for”重用，面向物件設計中的粒度以及應用設計模式。還提到了支援質量設計的開發過程的相關方面。

軟體工程中的可重用性

可重用性被認為是面向物件（OO）對軟體工程領域的主要貢獻。這是因為OO為軟體開發人員提供了第一次在新類中再次使用現有類而無需修改的機會。

重複使用可提高生產率和提高輸出質量。

重用級別 瞭解軟體開發中的各種重用級別是提高可重用性的良好起點。

圖15.1顯示了軟體工程中普遍存在的三種不同重用級別：

◾程式碼級重用 - 當新類基於現有的完全編碼類時發生。

◾設計級重用 - 當所有新設計的基礎都基於現有設計和可用設計模式時，就會發生。

◾分析級別重用 - 可以跨多個專案在組織級別進行。在一個專案中確定的要求可以在另一個專案中重複使用（通過適當的修改）。這種分析級別的重用需要組織範圍的重用文化。

1.程式碼級重用

當類重用另一個類時，會發生程式碼級重用。這意味著繼承的類使用基類的任何函式（或屬性）。程式碼級重用還包括在實現語言和開發環境中重用類。

圖15.1a顯示了左側的這種基本重用。程式碼示例顯示瞭如何建立繼承Person類的新Patient類。患者可以使用Person的所有屬性和關係，而無需在Person類中再次顯式宣告。程式碼級重用取決於程式設計師對開發環境的瞭解以及現有類的可用性。

2.設計級重用

設計級別的重用基於類設計，元件，框架，包和服務。在這個級別重用很重要，因為它發生在比程式碼級重用更高的級別，因此對專案有更大的影響。例如，與重用類相比，重用整個可執行庫或呼叫複雜的分析服務對開發的影響要大得多。這是在設計或“模式級別”的重用，為軟體專案提供了主要的好處。這是專案中的重用，也可以跨多個專案提供價值。

圖15.1b顯示了第二種重用形式，其中可以基於現有設計或模式對類及其關係進行建模。圖15.1顯示了基於Gamma（Gamma等人1995）觀察者模式的設計（本章後面將討論）。主體和患者之間的繼承不是基於類背後的語義含義，而是基於它們的實現特徵。來自相應的Subject和Observer類的Patient和Doctor類的繼承有助於實現Observer模式，而系統設計者只需要很少的努力。圖15.1b顯示瞭如何根據實現中的設計特性重用整個類集。

3.分析級重用

第三種重用形式位於分析級別，如圖15.1c右側所示。在此級別，需求被記錄並從UML提供的用例中重用。用例 - 用例 - 關係有助於這種重用。兩個用例之間的<< include >>關係可以在分析級別重用需求。例如，其中一個用例MaintainsCalendar需要檢查日曆詳細資訊。與此同時，“預約”和“重新安排諮詢”等其他模組也需要檢視日曆。在這種情況下，開發了一個新的用例ChecksCalendar。稍後，需要使用此用例的其他用例可以包含它用於實現。這種重用如圖15.1所示，其中MaintainsCalendar用例包括ChecksCalendar用例。

軟體專案中的重用策略

重用策略在軟體專案中提供比程式碼級重用更大的價值。需要仔細考慮這些重用策略，並得到所有利益相關方的同意，並將其納入軟體開發過程。戰略性重用可為專案和組織帶來生產力和質量收益。

重用可提高工作效率，因為重用的類和元件不是從頭開始設計的。還不需要再次測試重用的類和元件（除了具有繼承類的新介面）。因此，基於現有類的類減少了編碼以及測試工作量，從而提高了質量並提高了生產率。然而，這種重用需要一種超越一個專案並進入組織內所有專案的戰略方法。

封裝有助於重用除了繼承之外，封裝還有助於OO的可重用性，從而提高生產力和質量。正如第1章中的OO基礎知識所討論的，封裝通過其函式或方法“包裝”類屬性。由於資料和函式在一個類中被“封裝”在一起，因此可以很容易地將邏輯和執行中的潛在錯誤精確定位到特定類。 OO中的錯誤的縮小在程式設計中不容易發生，因為錯誤可能發生並且流經系統的任​​何部分而不被本地化。

對於面向物件的設計，如果物件在檢索某些屬性的值時“丟擲”錯誤，則該錯誤相對容易地追溯到該特定物件及其相應類的程式碼。此外，由於封裝，錯誤仍然存​​在於類中，並且不會滲透到系統的其餘部分。

前面的討論表明，一旦一個類被設計，開發，測試並放置在一個模組（或一個元件或服務）中，那麼該模組就可以被廣泛地分發和重用。這種模組的重複使用需要最少的努力，僅限於為新設計的類測試新介面。

重用的類具有比新編寫的類更高的質量特性，特別是如果它之前已經被重用。這是因為隨著類的重用，它們也會在現實生活中通過重用進行測試。因此，一個類被重用的越多，其質量就越高。

為了使封裝成功，它必須是專案中設計標準的一部分，因此是專案文化的一部分（如下所述）。應注意確保封裝不會退化為資料隱藏的練習。簡單地將資料或屬性隱藏在函式後面並不能提供與封裝相同的質量優勢。

舉一個簡單的例子，考慮HMS中的Patient類和該類中的MedicareNumber屬性。如果使用getMedNo（）方法訪問MedicareNumber，那麼實現的是資料隱藏 - 通過函式隱藏資料。如果提供了一個具有業務邏輯的函式（例如getCoverDetails（），而不是getMedNo（），其中包含Medicare編號以及其他欄位，則整個業務功能將封裝在類中。

作為文化重用專案中的重用文化需要專案管理的戰略方法。在組織層面理解重用的一個有用概念如圖15.2所示。該圖顯示了重用的兩個“型別”：

1。優化類或元件以供將來重用，從而使專案成為可重用元素的“生產者”;

2.將可重用的類和元件合併到下一個專案中，或“消耗”它們。

前者需要類的泛化，可以稱為“for”重用，而後者稱為“with”重用。圖15.2顯示了跨多個專案的這兩種型別重用的戰略方面。專案1顯示為生成可重用元件，專案2正在消耗或“重用”它們。

*或類別，將這種重用分組與圖15.1中關於重用級別的早期討論分開。

重用中的泛化與專業化在專案1上工作的建模者和開發人員正在為生成可重用元件做出額外貢獻（對他們的正常工作）。這是“為了”未來的重用。這樣的重用工作使得從事專案2工作的建模人員和開發人員受益。專案2人員正在“重用”他們的建模工作，因此他們依賴於專案1工作人員所做的工作。

“for”重用的一個例子是Animal類到Living類的泛化。這樣的設計具有足夠的功能，不僅滿足當前專案的需求，而且滿足未來專案的需求。第一個“生產者”專案需要額外的努力，特別是在質量保證，質量控制或測試方面。這是因為必須對類進行指定，記錄和測試，不僅要為其現在的應用程式，還要為未知的未來使用。

當“重複”發生時，質量區域所需的相對較少的努力抵消了這種額外的努力，因為期望元件的所有基本特徵的質量得到保證，並且需要針對由於它們的使用而發生的變化進行重新測試。例如，以Animal為模型的新類Cat是專業化的示例（“有”重用）。在這裡，Cat享有動物和生活類開發人員所有設計和測試工作的優勢。

面向物件設計中的粒度隨著開發的進行以滿足當前專案的要求，“for”和“with”重用注意事項明確地影響未來或併發專案的需求。平均等級的大小與專案團隊成功建立這種“前饋”機制的能力有關。類的大小是本節中討論粒度的基礎。

粒度意味著，對於給定的功能，可以使用幾個大類（粗粒度設計）或大量較小的類（細粒度設計）來建立設計。

圖15.2“With”和“for”重用 - 重用策略的一部分。

粒度的概念進一步說明了物件的平均大小

“永恆的建築方式”（1977）4仍然是模式概念的基本閱讀，它已被髮展為設計模式，作為Gamma等人的可重用面向物件軟體的元素。 （1995年）。根據亞歷山大的說法，

“每種模式都描述了一個在我們的環境中反覆出現的問題，然後描述了該問題解決方案的核心，以這種方式使解決方案可以使用一百萬次，而不用做它以同樣的方式兩次。

“儘管亞歷山大在談論建築和城鎮中的模式，但這一概念在面向物件的設計模式中同樣如此。

Coplien（1991）5進一步將模式定義為對正在構建的事物的描述和構建事物的過程，在上下文中解決問題的解決方案以及解決給定設計決策中的力量的問題。此定義有助於發現模式並將其應用於軟體工程專案。建立的模型和建立這些模型的過程通過上述定義找到了指導。

模式的結構形式上，模式可以通過

模式的四個基本要素   來描述（Gamma等，1995）：

◾1.模式名稱: 用一兩個詞來描述設計問題，解決方案和後果。

◾2.問題: 描述何時應用模式。

◾3.解決方案 描述了構成設計的元素，它們之間的關係，責任和協作。

◾4.後果 是應用模式的結果和權衡。

在解決方案和架構建模空間中使用模式

模式在概念層面形式化可重用性（圖15.1b）。經驗豐富的設計人員可以識別重複的類層次結構，關聯類或訪問序列，並將它們組合在一起，使它們可以應用於各種實際設計問題。

正如Gamma等人。 （1995）說：“這些模式解決了特定的設計問題，使面向物件的設計更加靈活，優雅，最終可重複使用。”因為它們不僅捕獲系統部分，還捕獲它們之間的豐富關係（Coplien，1991）5，模式描述了比任何物件或類層次結構更廣泛的系統體系結構。

一旦在目錄中進行描述和記錄，設計模式就成為熟練的源泉，只有經驗才能提供 - 通過高效靈活的設計促進重用。模式還解決了物件大小和數量問題 - 幫助決定應該是什麼物件。

例如，Gamma等。描述Facade模式，它表示完整的子系統作為物件，以及Flyweight模式，它描述瞭如何以最精細的粒度支援大量的物件。

因此，可以看出，通過捕獲和記錄專家明顯的重複行為，模式為面向物件的軟體工程提供了可重用性和質量。

特別地，設計模式主要在解空間（MOSS）中提供上述值。然而，與分析和架構模式一起，在架構空間（MOAS）中最大化重用和質量的價值。這是因為基於約束和引數在架構空間中做出的組織級決策。

粒度的概念進一步指出，面向物件系統中物件/類的平均大小是成功重用設計中的重要考慮因素。

在圖15.3中演示了這種粒度概念，其中示出了能夠由4個粗粒度類或16個細粒度類實現的相同功能（大致由用例圖表示）。

細粒度類需要更多的努力來生成，但它們更可重用。這是因為大量較小的類比新的（粗）類更適合新的場景/需求。這種情況的另一面是更精細的粒度設計需要額外注意質量，因為有更多的類用於給定的功能。此外，不僅是本身，還有需要測試的關係。無論情況如何（精細或粗略），系統架構師和系統設計人員必須牢記建立面向物件設計時的這一重要概念。

軟體設計工程中的設計模式什麼是模式？

模式是在抽象中捕獲的反覆出現的“思維過程”。這些“更高級別”的抽象可以在較新的設計中重複使用，而設計師不必經歷與從頭開始的相同嚴格。

設計模式提供了重用軟體和設計的最流行方法之一，尤其是在面向物件的環境中。由於設計模式的普及，軟體工程領域也出現了其他價值模式。這些是：

◾分析模式，描述和模擬問題空間1中的重複現象

◾如前所述，設計模式是解空間中的重複現象（Gamma等，1995）

◾架構模式，是作為正在開發的系統的組織約束而出現的反覆出現的現象

◾遊戲模式，是軟體專案中反覆發生的社會心理現象（Unhelkar，2003,2005）2,3更大的粒度設計=粗粒度設計粗粒度系統設計細粒度系統設計更小的粒度=細粒度設計粒度概念有助於表達具有不同“大小”設計的“相同”功能'A10-Account Executive''A20-Client'AddClientsDetails << business >> ChangesClientsDetails << business >>圖15.3面向物件設計中粒度的概念。

圖15.4演示了在軟體架構和設計中使用模式。觀察者模式已由Gamma等人詳細描述。他們在設計模式方面的熱門工作。在該模式中，它們捕獲了一個類（Observer）依賴於另一個類（Subject）的情況的本質。主體狀態的任何變化都會影響觀察者。

表示Observer和Subject的抽象類專門用於concreteObserver和concreteSubject。

從設計角度考慮，需要以某種圖形方式（如圖形或餅圖）表示Excel資料。在這種情況下，Excel工作表中的實際資料是主題，圖形是觀察者。就類而言，這可以解釋如下。考慮物件B的狀態取決於物件A的狀態。每當物件A的狀態改變時，物件B必須重新計算其狀態以保持一致。

在HMS域中，此模式可以解釋為如圖15.4所示。在該圖中，concreteObserver由Doctor替換，而concreteSubject由Patient類替換。此設計表明，只要患者的任何細節發生變化，醫生就會受到影響。患者狀態的變化（例如，InTreatment患者）會影響醫院治療患者的方式。

如圖15.4所示，這種設計優於從頭開發的設計，因為基於觀察者模式的設計，Gamma等人的知識和經驗。正在被重用。毋庸置疑，這種設計經過進一步修改和擴充套件，以滿足醫院領域的完整實施需求，但它肯定比從頭開始考慮患者 - 醫生協會更好的開始 - 從而提高質量。

attach（Observer）detach（Observer）notify（） - doctorState update（）update（） - patientState getPatientState（）* observers subject將Patient的狀態返回給任何呼叫物件，例如Doctor doctorState = policy-> getPatientState（）for all o在觀察者中{o-> update（）}患者醫生主題觀察者圖15.4在HMS中使用設計模式（基於Gamma等人的觀察者模式工作）。

通常，在系統中只需要建立一個物件例項，然後由整個系統訪問。在這種情況下，需要控制這種單個物件的例項化和訪問。這些物件的示例包括通訊，資料庫訪問，視窗管理器和列印緩衝器。系統中全域性需要這些物件。擁有此類的多個例項會導致系統不一致。

Singleton模式有助於設計建立，其中基於該模式的類只能被例項化一次。因此，Singleton模式導致封裝的全域性物件，並且可以檢查是否只存在一個物件。

圖15.5顯示瞭如何在HMS中使用Singleton模式的示例。此示例顯示了HMS中的一個類，該類只需要一個例項。在HMS中，Hospital物件是唯一的，因為在執行系統時只需要它的一個例項。這是通過基於Singleton模式實現的。如果沒有這樣的模式，醫院例項化的系統部分必須由設計人員和開發人員“手動編碼”以確保單一例項化。

設計中的穩健性設計中的穩健性設計中的穩健性是一種探索類之間依賴關係的概念。類之間的這種依賴性或耦合程度是軟體工程的傳統挑戰之一。

如果一個類嚴重依賴於另一個類，那麼一個類中的更改自然會影響依賴於該類的所有其他類。因此，一個類中的更改可以影響其他類，使得幾乎不可能在不影響許多其他部分的情況下更改系統的一部分。

簡單地說，系統中類之間的依賴性越高，系統的魯棒性就越低。相反，如果類較少依賴於彼此，那麼一個類中的更改對系統中的其他類的影響較小。結果，該系統被認為是健壯的。因此，魯棒性是一種設計方法，可確保解決方案的一部分能夠在不影響系統其他部分的情況下進行更改。

識別缺乏穩健性考慮圖15.6。

請注意，兩個<< entity >>類，Patient和Schedule緊密耦合。即使這些類與<< boundary >>類Patient _ Form相關聯，整個設計也是緊密耦合的。一個類（以及執行時的相應物件）的更改會直接影響其他類。

Hospital uniqueInstance ... instance（）... return uniqueInstance圖15.5 Singleton模式（HMS中的另一個例子，基於Gamma等人的工作）。

◾具有UML魯棒性規則的軟體工程魯棒性是一種特定的設計構造，其中控制器（或管理器）類插入實體，邊界和資料庫類之間。例如，Patient類可能不直接與Doctor類關聯，或者更具體地，Patient類可能不會呼叫或建立Doctor類，反之亦然。相反，在上述兩個類之間引入了一個物件管理器（或具有任何其他名稱的類，即<< manager >>或<< controller >>構造型）。此物件管理器負責建立和管理活動物件列表。

這裡討論的魯棒性概念源於早期的，眾所周知的稱為MVC *的SmallTalk模式，或模型檢視控制器模式。在MVC中，模型（或基於UML的設計中的<< entity >>構造型）和檢視（或<< boundary >>構造型）由控制器（或<< controller >>構造型）分隔。

在應用穩健性時，設計中包含以下規則（如圖15.7所示）：

◾邊界（介面）類不能相互通訊（關聯）

◾實體類不能互相交談（關聯）

◾邊界和實體類可以與控制類通訊

◾控制類可以互相交談（關聯）注意在實踐中，這些健壯性規則也可以擴充套件到<< table >>和<< entity >>關係;這意味著<< entity >>類，

當需要在相應的<< table >>中儲存細節時，不能直接這樣做。相反，<< entity >>類經過另一個<< control >>，通常是DatabaseManager類，用於在<< table >>中儲存細節。

在設計中加入魯棒性圖15.8顯示瞭如何在前面圖15.6所示的設計中插入<< control >>類。

該圖中的類圖顯示了ConsultationManager控制元件類將Patient_Form與Patient類分開。 Patient類也與其他實體類Schedule分開。

* MVC模式。

<< entity >> Patient 0 ... 1 1 0 ... 1 << boundary >> Patient_Form << entity >> Schedule與邊界類相關聯的實體類直接暗示設計中缺乏魯棒性圖15.6識別缺乏魯棒性。

圖15.8左側顯示的類圖，

在類的標記上標有刻板印象，在圖的右側用圖示重複。圖示的使用使圖表更具可讀性，從而更容易發現穩健性（或缺乏穩健性）。實際上，魯棒性僅限於建立實體和邊界物件;一旦建立了物件，它們可能最終會相互發送和接收訊息 - 儘管包含了一個控制元件類。

圖15.9顯示了現在通過序列圖顯示在實踐中如何實現穩健性的另一個示例。一旦PatientRegistrationForm收到訊息A10-Patient（來自用例檢視）邊界控制control2實體

圖15.7健壯性規則。

Patient_Form Patient ConsultationManager

Schedule Schedule << entity >> Patient << entity >>

ConsultationManager << control >> Patient_Form << boundary >>

圖15.8在設計中加入魯棒性。

要更新（）Patient的詳細資訊，它會執行內部validatePatientDtls（）。然後它將訊息savePatient（）傳送到TransactionManager，它是<< control >>類（在這種情況下是物件，因為它是一個例項級序列圖）。然後，該控制物件將訊息傳遞給另一個名為DatabaseManager的控制物件，該物件又呼叫Patient物件以獲取需要儲存在資料庫中的Patient的詳細資訊。收到患者詳細資訊後，DatabaseManager將它們傳送到PatientTable進行儲存。

實際上，通過此序列圖中的兩個控制物件實現的這種穩健性可能會對系統性能產生負面影響。這是因為訊息需要通過其他控制器物件。這裡的平衡行為是犧牲一小部分效能來獲得設計靈活性和穩健性。

系統架構和設計過程到目前為止討論的高階設計概念在架構空間模型（MOAS）的構建中具有重要價值。以下是關於構建這樣的系統架構模型的討論。

像系統設計人員，系統架構師和專案經理之類的專案角色需要整合在一起並進行戰略性工作，以實現重用的粒度和穩健性。建立原型（可執行檔案）和改進需求等技術支援早期關於重用和質量的討論。操作考慮因素（系統執行時的要求）也在開發MOAS時發揮作用。以下是與開發良好系統架構相關的活動和任務。

ActorStaff PatientRegistrationForm TransactionManager Patient DatabaseManager PatientTable update（）validatePatientDtls（）savePatient（）控制元件類確保設計的穩健性savePatientDtls（）getPatientDtls（）savePatientRecord（）

圖15.9健壯性對儲存患者註冊詳細資訊的過程的影響。

調查系統（以及組織內的其他系統）的現有架構和設計：

◾瞭解系統的當前系統架構和設計需求

◾將當前系統體系結構與組織的現有企業體系結構（EA）相關聯

◾瞭解建立問題空間模型（MOPS）中指定的當前操作要求

 融合模式

◾認識到當前設計中的“模式”情況

◾確定可在當前設計中使用的合適設計模式

◾嘗試使用可用的模式，以檢視哪些模式最適合使用

◾在您的設計中加入合適的圖案

◾使用選定的模式進行設計演練

系統架構建立

◾為系統建立資訊體系結構

◾建立資料庫體系結構以啟用系統的永續性功能

◾執行架構原型（這和下一個任務與原型製作流程元件相關），以便了解架構需求

◾根據架構原型檢查當前系統架構

 操作要求確認

◾確保效能要求由系統體系結構處理

◾確保系統體系結構處理卷要求

◾確保體系結構具有可擴充套件性，這將使系統隨著系統使用者需求的增長而增長

◾確保將系統的安全要求合併到體系結構中。

特別是在Web應用程式中，必須在效能和安全性要求之間取得平衡。圖15.10顯示了HMS的基本系統體系結構。基於對系統基礎結構的理解，該體系結構分為三個部分：使用者介面，業務規則和資料庫。這三層散佈著四個功能層：患者，員工，諮詢和賬戶。

在實踐中，可能有更多的功能劃分。系統的功能層和基礎架構層之間的交叉是建立包的基礎。因此，這樣的架構圖也是在專案的早期繪製的（再次參考第3章中關於建立包的討論）。

該體系結構的每個橫截面都可以是一個包，如圖15.10所示。或者，GUI和資料庫可以各自放在一個包中，並且功能部分可以放在它們自己的包中。這種劃分的基本思想是建立由包表示的可管理子系統。

圖15.10顯示了HMS的基本系統體系結構。基於對系統基礎結構的理解，該體系結構分為三個部分：使用者介面，業務規則和資料庫。這三層散佈著四個功能層：患者，員工，諮詢和賬戶。

在實踐中，可能有更多的功能劃分。系統的功能層和基礎架構層之間的交叉是建立包的基礎。因此，這樣的架構圖也是在專案的早期繪製的（再次參考第3章中關於建立包的討論）。

該體系結構的每個橫截面都可以是一個包，如圖15.10所示。或者，GUI和資料庫可以各自放在一個包中，並且功能部分可以放在它們自己的包中。這種劃分的基本思想是建立由包表示的可管理子系統。

重複使用，粒度，模式和穩健性的常見錯誤以及如何糾正它們