作業: 類別設計
這項作業定義如何設計子系統或元件的類別結構。
規範: 分析 設計
目的
  • 確保類別確實提供實現使用案例所需要的行為
  • 確保提供足夠的資訊來清楚地實作類別
  • 處理與類別相關的非功能方面的需求
  • 涵蓋類別使用的設計機制
關係
主要說明

類別是設計工作的馬力,系統中的實際工作都是由類別在執行。諸如子系統、套件及共同作業等的其他設計元素,則是用來說明類別如何分組,或類別之間如何交互作用。

封裝體也是模板化的類別,旨在用來代表在即時系統中執行的並行執行緒。在這種情況下,其他設計類別都是屬於被動性的類別,供在主動式的封裝體提供的執行環境定義中使用。若軟體架構師及設計師選擇的設計方法沒有採用封裝體時,還是可以使用主動式的類別來建構平行行為的模型。

主動類別是設計類別中,用來協調及驅動被動類別之行為的類別,主動類別則是其實例為主動物件的類別,這些主動物件擁有其各自的控制緒。

步驟
使用設計型樣與機制

使用適合要設計的類別或功能,並且符合專案設計準則的設計型樣與機制。

涵蓋型樣及/或機制就是有效率地執行本作業內的許多後續步驟 (新增類別、作業、屬性及關係),但同時也符合型樣或機制定義的規則。

請注意,型樣與機制通常是在設計的演變過程中加入使用,而不僅只是作為本作業的第一個步驟而已。並且型樣與機制也經常會套用一組類別中,而不僅只是套用到某一個類別。

建立起始設計類別

針對給定的分析類別建立一或多個起始設計類別,作為本作業的輸入,並指派追蹤相依關係。在這個步驟建立的設計類別,會在後續的步驟中指派諸如作業、方法以及狀態機等各種設計特性,來說明分析類別的設計方式時,加以修正、調整、分割或合併。

視所設計的分析類別類型(界限、實體或控制項),各有特定的策略可以用來建立起始設計類別。

設計界限類別

界限類別代表與使用者或其他系統之間的介面。

通常代表與其他系統的介面之界限類別,會建立成子系統模型,這是因為界限類別通常具有複雜的內部行為。如果介面行為極為簡單(也許只是作為與現有的 API 到外部系統之間的通道而已),您就可以選擇以一或多個設計類別來代表介面。如果您選擇採用這個路徑,則請針對每一個通訊協定、介面或 API 使用一個設計類別,並且請注意在類別的特殊需求中使用的標準有關的特殊需求。

代表與使用者的介面之界限類別,通常會遵循在使用者介面中的一個視窗一個界限類別,或是一個表單一個界限類別的規則。因此,界限類別的責任可能會變得極為高階,並且需要在這個步驟中加以修正和詳述。使用者介面的其他模型或原型,可以是本步驟可以考慮作為輸入的來源。

界限類別的設計方式,是視專案可以使用的使用者介面 (UI) 開發工具而定。在使用目前的技術時,使用者介面通常是在開發工具中,以視覺可見的方式直接建立。這個方式會自動建立必須和控制項及實體類別設計相關聯的使用者介面類別。如果使用者介面開發環境會自動建立實作使用者介面所需要的支援類別,在設計時,就不需要考慮建立支援類別。您只需要設計開發環境不會自動建立的項目。

設計實體類別

分析期間,實體類別是代表受操控的資訊。這些資訊通常是被動且持續的,並且可能會被指出並和持續的分析機制相關聯。作業:資料庫設計會詳細說明設計 以資料庫為基礎的持續性機制。效能考量會導致強制重新建構持續性類別,因而必須變更 角色:資料庫設計師 以及角色:設計師們已經共同討論過的「設計模型」。

在稍後的標題識別持續性類別中,會對持續性類別的設計問題做更廣泛的討論。

設計控制類別

控制物件負責管理使用案例的流程,因此它會協調它的大部分動作;控制物件中會涵蓋和使用者介面問題(界限物件)或資料工程問題(實體物件)無直接關聯的邏輯。這個邏輯有時亦稱為應用程式邏輯商業邏輯

設計控制類別時,請考慮下列事項:

  • 複雜度 - 您可以使用界限類別或實體類別來處理較不複雜的控制或協調行為。不過,當應用程式變得較複雜時,這種方式的缺點就會開始浮現,例如:
  • 使用案例協調行為變成內嵌在使用者介面中,因此很難更改系統
  • 相同的使用者介面若要在不同的實現使用案例中使用時,困難重重
  • 使用者介面因為承接附加功能,而導致效能降級
  • 實體物件可能會因為承受了使用案例特定的行為,而降低其通用程度

為了避免這些問題,就要引進控制類別,來提供與協調事件流程相關的行為。

  • 變更彈性 - 如果需要變更事件流程的可能性很低,或是成本微不足道時,就不值得接受額外的控制類別所帶來的額外費用和複雜性。
  • 分送與效能 - 由於需要在不同的節點,或是不同的處理空間執行應用程式的一部分,而導致需要使用特殊的設計模型元素。這項特殊化通常是依靠從界限類別及實體類別增加控制物件及分送行為到控制類別來達成。使用這種做法時,界限類別會移轉為只提供使用者介面服務,實體類別會改為只提供資料服務,而控制類別則提供其餘服務。
  • 交易管理 - 管理交易是典型的協調活動。若沒有架構可以處理交易管理,一或多個交易管理程式類別就必須進行互動,來確保維持交易的完整性。

在後兩個狀況中,如果控制類別代表的是個別控制緒,則使用主動類別來建立控制緒模型會更適當。在即時系統中,使用 工作成果:封裝體會是理想的建模方法。

識別持續性類別

需要將狀態儲存在永久媒體上的類別,稱為持續性類別。需要儲存狀態的原因包括要永久記錄類別資訊、作為系統失效時使用的備份,或是要交換資訊。持續性類別可能會有持續性以及暫時性的實例;將類別標示為持續性,只是表示該類別的某些實例可能必須是持續性的實例。

依據分析期間找出的持續性機制,來涵蓋相對應的設計機制。例如,視類別的需要,持續性的分析機制可以由下列其中一種設計機制實現:

  • 內建記憶體儲存裝置
  • 快閃卡
  • 二進位檔
  • 資料庫管理系統 (DBMS)

持續性物件並不一定只是從實體類別衍生;持續性物件也可能需要用來處理一般的非功能需求。這種範例包括需要維護和程序控制相關資訊的持續性物件,或維護交易之間的狀態資訊之持續性物件。

指出持續性類別來通知角色:資料庫設計師,該類別需要特別注意實體儲存體特性。如此也會通知角色:軟體架構師,該類別必須是持續性類別,並通知負責持續性機制的角色:設計師,該類別的實例必須是持續性實例。

由於需要有一個經過協調的持續性策略,角色:資料庫設計師 要負責使用持續性架構,將持續性類別對映至資料庫。如果專案要開發持續性架構,則架構開發人員也會負責瞭解設計類別的持續性需求。為了向這些人員提供他們需要的資訊,這個階段只需要指出類別持續性類別,或者更明確地指出類別的實例是持續性實例即可。

定義類別可見度

針對每個類別,決定類別在其所在的套件中之可見度。公用類別可以在包含類別的套件之外參照。專用類別(或可見度為實作的類別)只能被位於相同套件內的類別參照。

定義作業

識別作業

若要識別設計類別的作業:

  • 瞭解每個相對應的分析類別之職責,並針對每一種職責建立一項作業。使用職責的說明作為作業的起始說明。
  • 瞭解類別 participates 中的實現使用案例,查看實現使用案例如何使用作業。一次展開一個實現使用案例的作業,並修正作業以及作業的說明、傳回類型與參數。每一個實現使用案例對類別的需求,都會在實現使用案例的「事件流程」中以文字說明。
  • 瞭解使用案例的「特殊需求」,以確保未遺漏其中可能會指出的作業隱含需求。

作業必須能支援序列圖中出現的訊息,因為 Script(尚未指派給作業的臨時訊息規格) 會說明類別預期要執行的行為。圖 1 提供序列圖的範例。

圖解說明詳見隨附的文字。

圖 1:組成識別作業基礎的訊息

實現使用案例無法提供足夠的資訊來識別所有作業。若要找出其餘作業,請考慮下列項目:

  • 是否有方法可以起始設定類別的新實例,包括將類別連接至與類別相關聯的其他類別之實例?
  • 是否需要進行測試,查看類別的兩個實例是否相等?
  • 是否需要建立類別實例的複本?
  • 類別使用的機制對類別是否有任何作業要求?例如,記憶體回收 機製可能會要求物件要捨棄對所有其他物件的參照,才能釋放出任何未使用的資源。

請勿定義只用來取得及設定公用屬性值的作業(請參閱定義屬性 以及定義關聯)。通常這種作業會由產生程式機制自動產生,因此不需要明確地定義。

命名及說明作業

在命名作業、傳回類型及參數與參數類型時,請使用實作語言的命名慣例。這些作業的說明位於 專案特定準則

您應該針對每項作業定義下列項目:

  • 作業名稱 - 名稱維持愈短愈好,並敘述作業會達到的結果。
    • 作業名稱應該遵循實作語言的語法。例如 C++ 和 Visual Basic 可接受 find_location,但是 Smalltalk 就不接受(因為它不使用底線);findLocation 就可以被所有語言接受。
    • 避免使用名稱暗指作業的執行方式。例如,Employee.wages() 要比 Employee.calculateWages() 理想,因為後者暗指會執行計算。作業可能只是傳回資料庫中的值而已。
    • 作業的名稱應該要清楚顯示其用途。避免使用不特定的名稱,如 getData,這個名稱並沒有敘述它會傳回的結果。請使用會表示其預期會執行的動作名稱,例如 getAddress。更好的做法是,作業名稱就使用所傳回或設定的內容名稱。如果作業具有參數,作業就會設定其內容。如果作業沒有參數,作業就會取得其內容。範例:作業 address 傳回客戶的地址,而 address(aString) 則設定或變更客戶的地址。作業的 get 以及 set 本質,是由作業的簽章暗示。
    • 觀念相同的作業,但是是由不同的類別定義,或是以完全不同的方式實作,或如果具有不同的數目的參數時,應該要使用相同的名稱。如果作業會建立物件,則應該在所有類別中都使用相同的名稱。
    • 如果多個作業在數個類別中具有相同的簽章,則作業必須傳回適合接收端物件的相同結果類型。這是多型性概念範例,這個概念指出不同的物件應該以類似的方式回應相同的訊息。範例:作業 name 應該傳回物件的名稱,不論名稱是如何儲存或衍生。依照這個原則時,會使模型較容易瞭解。
  • 傳回類型 - 傳回類型應該是由作業傳回的物件類別。
  • 簡要說明 - 要盡量言簡意賅,作業名稱通常只是在要瞭解作業的執行動作時,才會有一點用處。用幾個句子提供作業的簡要說明,並且要從作業使用者的角度來寫。
  • 參數 - 針對每一個參數建立一個簡要的描述性名稱,決定其類別,並提供摘要的說明。在指定參數時,請記得參數愈少,表示愈容易重複使用。少數幾個參數會使作業更容易瞭解,因此,會比較容易找到類似的作業。您可以將具有許多參數的作業,分割成數個作業。作業必須能讓需要使用作業的使用者瞭解。摘要說明應該包括:
    • 參數的意義,如果無法從名稱明顯看出的話
    • 參數是由參照傳遞
    • 必須提供值的參數
    • 如果沒有提供參數值,則參數可以是選用的,並具有預設值
    • 適用的有效參數範圍
    • 作業會執行什麼
    • 作業會變更什麼參照參數

定義好作業後,請在序列圖中填入每一則訊息會起動的作業相關資訊。

如需詳細資訊,請參閱章節標題工作成果準則:設計類別

定義作業可見度

針對每一項作業,從以下選擇指出作業的匯出可見度:

  • 公用 - 類別本身以外的模型元素都可以見到作業。
  • 實作 - 只有在類別本身內才能夠看到作業。
  • 受保護 - 只有類別本身及其子類別,或類別的伙伴(這會隨著語言而不同),能夠看到作業。
  • 專用 - 只有類別本身及類別的伙伴能夠看到作業。

請選擇限制最嚴格,但是仍然可以達成作業目標的可見度。若要執行此動作,請查看序列圖,並針對每一則訊息判斷該訊息是來自接收端套件以外的類別 (需要公用可見度)、來自套件內(需要實作可見度)、來自子類別 (需要受保護可見度),或是來自類別本身或伙伴(需要專用可見度)。

定義類別作業

在大部分的情況,作業都是屬於實例作業,也就是說,作業是在類別的實例中執行。不過在某些情況下,作業會適用類別的所有實例,因此是屬於類別範圍作業。類別作業接收端實際上是 Meta 類別的一個實例,這種類別只是類別本身的說明而已,並不是類別的任何特定實例。類別作業的範例包括會建立(實例化)新實例的訊息,這種訊息會傳回類別的 所有實例

作業字串會畫底線,以表示是類別範圍作業。

定義方法

方法指定作業的實作方式。在許多情況下,作業需要的行為,會由作業名稱、說明及參數確切地定義,方法會在程式設計語言中直接實作。實作作業時,需要使用特定的演算法,或需要比作業說明中呈現的資訊以外的更多資訊時,就需要有個別的方法說明。方法會說明作業的執行方式,而不僅只是作業會做什麼而已。

方法應該要討論下列動作的執行方式:

  • 要實作的作業
  • 要實作並用來實作作業的屬性
  • 要實作並用來實作作業的關係

需求會視每個案例而有不同,不過類別的方法規格一定要指出:

  • 依據需求會執行什麼動作
  • 將會使用哪些其他物件以及物件的作業

更詳細的需求也會考慮:

  • 參數的實作方式
  • 是否會使用以及會使用哪些特殊的演算法

序列圖是此資訊的重要來源。從序列圖中可以清楚看出當執行作業時,會在其他物件中使用哪些作業。作業的完整實作方式需要指出會在其他物件中使用哪些作業。因此若要建立完整的方法規格,您就必須指出物件所涵蓋的作業,並視察相對應的序列圖。

定義狀態

對某些作業而言,作業的行為是視接收端物件所處的狀態而定。狀態機是一種工具,用來說明物件可以假設的狀態,以及會使物件從某個狀態轉移為另一個狀態的事件 (請參閱技術:狀態圖)。狀態機最適於用來陳述主動類別。定義 工作成果:封裝體的行為時,尤其應該使用狀態機。

圖 2 顯示一個簡單的狀態機範例。

圖解說明詳見隨附的文字。

圖 2:分配汽油的簡單狀態圖

每一個狀態轉移事件都可以和一項作業建立關聯。視物件的狀態,作業可能會有不同的行為,轉換事件就是在說明這種狀況的發生原因。

相關聯作業的方法說明應該要用與狀態相關的資訊更新,以指出在每一種相關聯的狀態中,作業應該採取什麼動作。狀態經常是用屬性呈現;狀態圖可作為屬性識別步驟的輸入。

如需詳細資訊,請參閱技術:狀態圖

定義屬性

在定義方法以及識別狀態時,就會指出類別執行作業所需要的屬性。屬性可以為類別實例提供資訊儲存體,並且常用來代表類別實例的狀態。由類別本身維護的任何資訊,都是透過類別的屬性處理。請針對每一個屬性定義:

  • 名稱,名稱應該遵循實作語言以及專案的命名慣例
  • 類型,這是實作語言可支援的基本資料類型
  • 預設值或起始值,當建立新的類別實例時,就會起始設定為這些值
  • 可見度,其值為下列其中一項:
    • 公用:在包含類別的套件內外,都能看到這個屬性
    • 受保護:只有類別本身及其子類別,或類別的伙伴(這會隨著語言而不同),能夠看到這個屬性
    • 專用:只有類別本身及類別的伙伴能夠看到這個屬性
    • 實作:只有類別本身可以看到這個屬性
  • 持續性類別,不論屬性是持續性(預設值)或暫時性的。雖然類別本身可能是持續性的,但是類別的所有屬性並不一定都必須是持續性的屬性。

檢查以確定是否所有屬性都是必要的。屬性應該進行確認,屬性很可能在程序初期時加入,並且因為視而不見的關係,在不再需要之後許久,還存留在系統中。額外的屬性並乘以無數的實例時,不但會影響系統效能,並且也需要額外的儲存體。

如需有關屬性的詳細資訊,請參閱工作成果準則:設計類別中的標題屬性

定義相依關係

針對物件之間需要進行通訊的情況,詢問下列問題:

  • 與接收端的參照是用參數傳遞給作業嗎?如果是,請在包含兩個類別的類別圖中,建立傳送端與接收端類別之間的相依關係。另外,如果在交互作用使用通訊圖格式,則指定鏈結可見度,並將其設定為參數
  • 接收端是廣域的嗎?如果是,請在包含兩個類別的類別圖中,建立傳送端與接收端類別之間的相依關係。另外,如果在交互作用使用通訊圖格式,則指定鏈結可見度,並將其設定為廣域
  • 接收端是暫時建立的物件並會在作業期間自行摧毀嗎?如果是,請在包含兩個類別的類別圖中,建立傳送端與接收端類別之間的相依關係。另外,如果在交互作用使用通訊圖格式,則指定鏈結可見度,並將其設定為本端

請注意用這種方式建立的鏈結模型是屬於暫時性的鏈結,它只會在協同作業的特定環境定義中存在一段有限的期間,因此,它們是相關聯的角色在協同作業中的實例。不過,類別模型中的關係(亦即和環境定義無關)應該如先前所說的,具有相依關係。如 [RUM98] 在暫時性鏈結定義中的說明:「雖然可以將所有這類鏈結塑造為相關聯的鏈結,不過關聯的條件必須指定為廣泛的條件,如此卻會在限制物件的合併時,喪失精準度」。在此情況下,建立相依關係模型的重要性,不如建立協同作業的關係模型那麼重要,這是因為相依關係並不會完整說明關係;只是指出有關係存在而已。

定義關聯

關聯提供一種機制,讓物件之間可以互相通訊。它為物件提供一個通道,供訊息延著通道傳遞。關聯同時也會記錄類別之間的相依關係,標示出在某個類別中的變更,會影響到許多其他類別。

請檢查每項作業的方法說明,瞭解類別的實例如何互相通訊,以及和其他物件分工合作。物件若要傳送訊息給其他物件,它必須具有訊息接收端的參照。通訊圖(序列圖的替代表示法)會以鏈結方式,顯示出物件通訊,如圖 3 所示。

圖解說明詳見隨附的文字。

圖 3:通訊圖範例

定義關聯與聚集

其餘訊息會使用關聯聚集,來指定相互通訊的兩個類別之實例之間的關係。如需有關選擇適當的表示法資訊,請參閱技術:關聯 and 技術:聚集。對於這些關聯,請在通訊圖中,將鏈結可見度設定為欄位。其他作業包括:

  • 建立關聯及聚集的可導覽性。您可以考慮鏈結實例化的需求,在互動圖中執行此動作。由於可導覽性的預設值是 true,因此您只需要在關聯的類別中,找出所有物件的所有相反鏈結角色不需要可導覽性的關聯(及聚集)。在那些情況下,類別的角色會將可導覽性設定為 false
  • 如果關聯本身有屬性存在(由關聯類別代表),則建立一個設計類別來代表關聯類別,並且要包含適當的屬性。將這個類別放置在其他兩個類別之間,並在關聯類別以及其他兩個類別之間,建立具有適當對應關係的關聯。
  • 指定關聯端點是否要排序;當與關聯另一端的物件相關聯的物件必須維持順序時,就必須做此指定。
  • 如果相關聯(或聚集)的類別只被現行類別參照時,請考慮該類別是否需要做成巢狀。巢狀類別的優點包括傳訊快,以及設計模型較簡單。缺點則包括不論是否有巢狀類別實例存在,都需要靜態配置巢狀類別的空間、物件身分無法和包含類別分隔開來,或是無法從包含類別的外部參照巢狀類別實例。

關聯及聚集最好是在指出相關聯類別的類別圖中定義。類別圖應該要由包含相關聯類別的套件擁有。圖 4 說明類別圖的範例,指出關聯與聚集。

圖解說明詳見隨附的文字。

圖 4:類別圖範例,顯示類別之間的關聯、聚集以及一般化

處理分析類別之間的訂閱關聯

分析類別之間的訂閱關聯,是用來指出類別之間的事件相依關係。在「設計模型」中,您必須明確地處理這些事件相依關係,這可以使用可用的事件處理常式架構,或是設計及建構您自己的事件處理常式架構。在如 Visual Basic 之類的程式設計語言中,這個動作很直接了當;您只需要宣告、提出及處理相對應的事件即可。但在其他語言中,就可能需要使用額外的可重複使用功能庫,來處理訂閱及事件。如果買不到功能,就需要自己設計和建構。另請參閱技術:訂閱關聯

定義內部結構

有些類別可以代表複雜的抽象化,且有複雜的結構。當建立類別的模型,設計者可以呈現它的內部參與元素及其關係,以確保實作者會據此實作這個類別內所發生的協同作業。

在 UML 2.0 中,類別定義為結構化類別,它可以具有內部的結構和連接埠。之後,類別可以拆解成相連組件的集合,這些組件又可以進一步拆解。強制來自類別外的通訊遵循宣告的介面來通過埠,便可以將類別封裝起來。

若找到具有複雜結構的複雜類別時,可以為該類別建立一個組合結構圖。針對會執行該類別行為的角色部分,建立模型。使用連接器,建立各個角色部分之間如何「連結」。如果您要讓該類別的不同用戶存取該類別提供的行為之特定部分時,請使用有宣告介面的連接埠。同時也請使用連接埠,將該類別的內部部分和其環境完整隔離。

如需這個主題的詳細資訊以及組合結構圖的範例,請參閱概念:結構化類別

定義一般化

類別可能會組織為一般化的階層,來反映共同的行為和結構。可以定義共同的超類別子類別可以繼承這個超類別的行為和結構。一般化是一種便利的表現方式,它可以讓您在某個位置定義共同的結構和行為,並在遇到具有重複行為和結構處重複使用。如需有關一般化關係的詳細資訊,請參閱技術:一般化

在發現一般化時,可以建立一個共用的超類別,來包含共同的屬性、關聯、聚集以及作業等。從會成為共同的超類別之子類別中,移除共同的行為。定義子類別到超類別之間的一般化關係

解決使用案例衝突

這個步驟的目的是要防止兩個以上的使用案例以不一致的方式,同時存取設計類別的實例,所可能造成的並行衝突。

先前的設計程序中之按使用案例所造成的困難,是會有兩個以上的使用案例會採用可能相衝突的方式,同時試圖針對設計物件啟動作業。在這種情況下,就必須找出並行衝突並明確地解決。

如果有使用同步傳訊,當執行作業時,將會封鎖對物件的後續呼叫,直到作業完成時才解除封鎖。同步傳訊暗指依據訊息的處理次序,先來先做。這種方式可以解決並行衝突,特別是當所有訊息都具有相同的優先順序,或是每則訊息都是在相同的執行緒中執行時。如果物件可能會被不同的執行緒(由主動類別代表)存取時,就必須使用明確的機制,來防止或解決並行衝突。

在執行緒是由 工作成果:封裝體代表的即時系統中,還是需要解決這個被動物件的多重並行存取問題,其中的封裝體會自行提供佇列作業機制,並強制「執行至完成」語意處理並行存取。建議的解決方案是將被動物件封裝在封裝體中,透過封裝體本身的語意,來避免並行存取問題。

在相同物件中的不同作業可能可以由不同的執行緒同步呼叫,但卻不會發生並行衝突問題;客戶的名稱和地址可以並行修改,不會發生衝突。只有在兩個不同的執行緒試圖要修改物件的相同內容時,才會發生衝突。

針對可能會被不同的執行緒並行存取的每個物件,找出必須避免同時存取的程式碼區段。在「詳述」階段的初期,可能無法找出特定的程式區段;但需要保護的作業將會浮現。接下來選擇或設計適當的存取控制機制,來防止相衝突的同時存取。這些機制的範例包括使用訊息佇列作業將存取序列化、使用信號或記號一次只容許一個執行緒存取,或是其它不同的鎖定機制。可以選擇的機制常和實作方式相關,並且通常會因程式設計語言和作業環境而有不同。如需有關選擇並行機制的指引,請參閱 專案特定準則

處理一般的非功能需求

需要修正「設計類別」來處理一般性的非功能需求。這個步驟的重要輸入包括分析類別的非功能需求,這可能已經在其特殊的需求與職責中指出。這種需求通常會以需要什麼樣的架構(分析) 機制才能實現類別的方式指定;在這個步驟中,會將類別修正為涵蓋與這些分析機制相對應的設計機制。

可用的設計機制會由軟體架構師指定及說明特性。對於所需要的每一種設計機制,盡可能限定多一點特性,提供適當的範圍。如需有關設計機制的詳細資訊,請參閱作業:識別設計機制概念:分析機制以及概念:設計與實作機制

設計類別時,可能需要考慮許多種一般設計準則與機制,例如如何:

  • 使用現有的產品和元件
  • 適應程式設計語言
  • 分散物件
  • 達到可接受的效能
  • 達到特定的安全層次
  • 處理錯誤
評估成果

請在這個階段檢查設計模型,確定您的工作是朝正確的方向進行。 這時並不需要詳細審查模型,不過您應該考慮下列核對清單:



詳細資訊