針對給定的分析類別建立一或多個起始設計類別,作為本作業的輸入,並指派追蹤相依關係。在這個步驟建立的設計類別,會在後續的步驟中指派諸如作業、方法以及狀態機等各種設計特性,來說明分析類別的設計方式時,加以修正、調整、分割或合併。
視所設計的分析類別類型(界限、實體或控制項),各有特定的策略可以用來建立起始設計類別。
界限類別代表與使用者或其他系統之間的介面。
通常代表與其他系統的介面之界限類別,會建立成子系統模型,這是因為界限類別通常具有複雜的內部行為。如果介面行為極為簡單(也許只是作為與現有的 API
到外部系統之間的通道而已),您就可以選擇以一或多個設計類別來代表介面。如果您選擇採用這個路徑,則請針對每一個通訊協定、介面或 API 使用一個設計類別,並且請注意在類別的特殊需求中使用的標準有關的特殊需求。
代表與使用者的介面之界限類別,通常會遵循在使用者介面中的一個視窗一個界限類別,或是一個表單一個界限類別的規則。因此,界限類別的責任可能會變得極為高階,並且需要在這個步驟中加以修正和詳述。使用者介面的其他模型或原型,可以是本步驟可以考慮作為輸入的來源。
界限類別的設計方式,是視專案可以使用的使用者介面 (UI)
開發工具而定。在使用目前的技術時,使用者介面通常是在開發工具中,以視覺可見的方式直接建立。這個方式會自動建立必須和控制項及實體類別設計相關聯的使用者介面類別。如果使用者介面開發環境會自動建立實作使用者介面所需要的支援類別,在設計時,就不需要考慮建立支援類別。您只需要設計開發環境不會自動建立的項目。
分析期間,實體類別是代表受操控的資訊。這些資訊通常是被動且持續的,並且可能會被指出並和持續的分析機制相關聯。作業:資料庫設計會詳細說明設計
以資料庫為基礎的持續性機制。效能考量會導致強制重新建構持續性類別,因而必須變更 角色:資料庫設計師 以及角色:設計師們已經共同討論過的「設計模型」。
在稍後的標題識別持續性類別中,會對持續性類別的設計問題做更廣泛的討論。
控制物件負責管理使用案例的流程,因此它會協調它的大部分動作;控制物件中會涵蓋和使用者介面問題(界限物件)或資料工程問題(實體物件)無直接關聯的邏輯。這個邏輯有時亦稱為應用程式邏輯或商業邏輯。
設計控制類別時,請考慮下列事項:
-
複雜度 - 您可以使用界限類別或實體類別來處理較不複雜的控制或協調行為。不過,當應用程式變得較複雜時,這種方式的缺點就會開始浮現,例如:
-
使用案例協調行為變成內嵌在使用者介面中,因此很難更改系統
-
相同的使用者介面若要在不同的實現使用案例中使用時,困難重重
-
使用者介面因為承接附加功能,而導致效能降級
-
實體物件可能會因為承受了使用案例特定的行為,而降低其通用程度
為了避免這些問題,就要引進控制類別,來提供與協調事件流程相關的行為。
-
變更彈性 - 如果需要變更事件流程的可能性很低,或是成本微不足道時,就不值得接受額外的控制類別所帶來的額外費用和複雜性。
-
分送與效能 -
由於需要在不同的節點,或是不同的處理空間執行應用程式的一部分,而導致需要使用特殊的設計模型元素。這項特殊化通常是依靠從界限類別及實體類別增加控制物件及分送行為到控制類別來達成。使用這種做法時,界限類別會移轉為只提供使用者介面服務,實體類別會改為只提供資料服務,而控制類別則提供其餘服務。
-
交易管理 - 管理交易是典型的協調活動。若沒有架構可以處理交易管理,一或多個交易管理程式類別就必須進行互動,來確保維持交易的完整性。
在後兩個狀況中,如果控制類別代表的是個別控制緒,則使用主動類別來建立控制緒模型會更適當。在即時系統中,使用工作成果:封裝體會是理想的建模方法。
|