準則: 分析類別
分析類別有三個模板:界限、控制和實體。這個準則說明意義和用法。
關係
主要說明

分析類別模板

分析類別的模板可以是下列其中一項:

  • 界限類別
  • 控制類別
  • 實體類別

除了在尋找類別時提供較明確的流程指引之外,模板也會產生健全的物件模型,因為模型的變更傾向於只影響特定區域。例如,使用者介面的變更只會影響界限類別。控制流程的變更只會影響控制類別。長期資訊的變更只會影響實體類別。無論如何,當您在分析和先期設計中確定類別時,這些模板特別有用。到了設計後期,您可能應該考慮使用一組稍微不同的模板,以便更妥當地關聯於實作環境、應用程式類型等。

界限類別 界限類別圖示

界限類別是用來建立系統週遭項目和系統內部運作間之互動模型的類別。這些互動包括在系統的呈現(如介面)中,轉換事件和記錄變更。

界限類別用來為系統中相依於週遭項目的部分建立模型。實體類別和控制類別用來為與系統週遭項目無關的部分建立模型。因此,變更 GUI 或通訊協定應該只意謂著變更界限類別,實體和控制類別維持不變。

另外,界限類別也使系統成為更容易瞭解,因為它們釐清了系統的界限。它們有助於設計工作,因為它們提供了用來識別相關服務的好的起點。比方說,如果您在先期設計中識別印表機介面,您很快就會發現,您也必須建立輸出報表格式的模型。

一般界限類別包括視窗、通訊協定、印表機介面、感應器和終端機。您不需要在模型中,將常規介面組件(如按鈕)建立成個別的界限類別。一般而言,整個視窗便是粒度最好的界限物件。界限類別也可用來擷取可能是非物件導向 API(如舊式程式碼)的介面。

您應該根據界限類別所代表的界限來建立界限類別的模型。與另一個系統通訊和與人類參與者通訊(利用使用者介面),有非常不同的目標。如果是與人類參與者通訊,最重要的問題是介面如何呈現給使用者。如果是與另一個系統通訊,最重要的問題是通訊協定。

界限物件(界限類別的實例)的存在可以超出使用案例實例,比方說,如果在執行兩個使用案例的間隔中,它必須出現在畫面,這時便是如此。不過,一般而言,界限物件的存在期間只能與使用案例實例一樣。

尋找界限類別

界限類別是一個用來連繫系統外界事物的中間介面。界限物件會將系統和週遭項目的變更(與其他系統的介面變更、使用者需求的變更等)隔開,防止這些變更影響到系統的其餘部分。

系統可能有的界限類別類型如下:

  • 使用者介面類別 - 用來與系統的人類使用者通訊
  • 系統介面類別 - 用來與其他系統通訊的類別
  • 裝置介面類別 - 偵測外部事件之裝置(如感應器)的介面類別
尋找使用者介面類別

請針對每個使用案例參與者配對來定義一個界限類別。您可以將這個類別視為負責協調與參與者的互動。您也可以定義其他界限類別來代表接受主要界限類別委派部分責任的次要類別。對於以視窗為基礎的 GUI 應用程式而言,尤其如此,您可能會每個視窗各建立一個界限物件模型,或每份表單各建立一個界限物件模型。請只建立系統主要摘要的模型;不要 GUI 中的每個按鈕、每個小組件、每份清單都分別建模。分析目標的用途是畫一幅好圖來表現系統的組成方式,而不在於設計每個最後的細節。換句話說,請只針對系統中的現象,或分析使用案例實現化之事件流程所提及的事物,來識別界限類別。

請利用草稿或使用者介面原型所傾出的使用畫面來說明界限類別的行為或外觀。

尋找系統介面類別

與外部系統通訊的界限類別負責管理與外部系統的對話;它針對所建置之系統來提供連繫這個系統的介面。

範例

在自動櫃員機中,提款必須透過 ATM 網路來接受驗證,ATM 網路本身也是一個參與者,它又會利用銀行帳戶系統來驗證提款。在識別稱為 ATM 網路介面的物件之後,便可以與 ATM 網路通訊。

現有系統的介面有可能早已定義好;若是如此,就應該直接從介面定義衍生責任。如果正式的介面定義存在,便可以進行反向工程,我們不需要在這裡正式定義它;請簡單記住這個事實:在設計期間,將重複使用現有的介面。

尋找裝置介面類別

系統可能會包含一些如同是外部元素的元素(未受系統中任何物件的影響,也會自動改變值),例如感應器設備。雖然這類外部裝置可以用參與者來代表,但系統使用者有可能覺得這會「造成混淆」,因為裝置和人類參與者是傾向於放在相同「層次」上。不過,收集好需求之後,我們必須考慮所有外部事件的來源,並確定系統有偵測這些事件的方法。

如果在使用案例模型中以參與者來代表裝置,便很容易證明利用界限類別進行裝置和系統之間的通訊是合理的。如果使用案例模型不包括這些「裝置參與者」,這時便適合加入它們來適當更新使用案例的增補說明。

對於每個「裝置參與者」,請各建立一個界限類別來承擔裝置或感應器的責任。如果裝置已有定義好的介面,請記下它,以便在後續設計中進行參照。

控制類別 控制類別圖示

控制類別是用來建立單一或少數使用案例專屬行為模型的類別。控制物件(控制類別的實例)通常會控制其他物件,所以它們有屬於協調類型的行為。控制類別會將使用案例專屬行為封裝起來。

控制物件的行為與特定使用案例的實現化密切相關。在許多情境中,您甚至會說,控制物件在「執行」分析使用案例的實現化。不過,如果各項使用案例作業密切相關,有些控制物件可以參與多項分析使用案例實現化。另外,不同控制類別的多個控制物件也可以參與單一使用案例。並非所有使用案例都需要控制物件。比方說,如果使用案例中的事件流程與某個實體物件相關,界限物件可能會協同實體物件來實現使用案例。您可以先找出每項分析使用案例的實現化各一個控制類別,等確定了更多的分析使用案例實現化,發現了共通性之後,再加以調整。

控制類別有助於瞭解系統,因為它們代表系統的動態,會處理主要作業和控制流程。

當系統執行使用案例時,會建立一個控制物件。控制物件通常是在對應的使用案例執行之後死去。

請注意,控制類別並不會處理使用案例中所需要的所有東西。相反地,它會協調其他物件的作業來實作功能。控制類別會將工作委派給被指派負責這個功能的物件。

尋找控制類別

控制類別提供系統中的協調行為。系統並不需要控制物件,就可以執行某些使用案例(只用實體和界限物件),尤其是只涉及簡單操作所儲存之資訊的使用案例。

比較複雜的使用案例通常會需要一或多個控制類別來控制系統中其他物件的行為。控制物件的範例包括交易管理程式、資源協調程式和錯誤處理常式之類的程式。

控制類別可以將界限和實體物件有效分開,使系統更能容受系統界限的變更。另外,它們也會將特定使用案例專用行為與實體物件分開,使它們更能跨越不同的使用案例和系統來重複使用。

控制類別提供如下行為:

  • 與週遭項目無關(當週遭項目變更時,不會跟著改變),
  • 定義使用案例內的控制邏輯(事件之間的次序)和交易。
  • 當實體類別的內部結構或行為有了改變時,不太會跟著改變,
  • 使用或設定多個實體類別的內容,因而必須協調這些實體類別的行為。
  • 每次啟動的執行方式各不相同(事件流程有多種狀態)。
判斷是否需要控制類別

使用案例的事件流程定義不同作業的執行次序。如果已識別的界限和實體類別能夠處理這個流程,請先進行探索。對於主要是輸入、擷取和顯示資訊或修改資訊的簡單事件流程而言,通常不會證明個別控制類別為合理;界限類別負責協調使用案例。

事件流程非常複雜,由動態行為組成,且這些行為的變更與系統的介面(界限類別)或資訊儲存庫(實體類別)無關,它便應該封裝在個別控制類別中。將事件流程封裝起來之後,同一個控制類別便有可能供介面各不相同、資訊儲存庫(至少是基礎資料結構)也各不相同的多種系統重複使用。

範例:管理作業佇列

您可以從倉庫系統的「執行作業」使用案例中找出一個控制類別。這個控制類別會處理作業佇列,確保各項作業會依正確次序來執行。在配置了適當的運輸設備之後,它會立即執行佇列中的下一項作業。因此,系統可以同時執行許多作業。

如果您將對應的控制物件分成「作業執行常式」和「佇列處理常式」兩個控制類別,對應控制物件所定義的行為會比較容易說明。「佇列處理常式」物件只會處理佇列次序以及運輸設備的配置。整個佇列需要一個「佇列處理常式」物件。只要系統一執行作業,就會建立一個新的「作業執行常式」物件,這個物件將會執行這項作業。因此,系統所執行的每項「作業」都需要一個「作業執行常式」物件。

「太複雜」的類別應該分成幾個類別,這些類別含有一致而相關的責任

複雜類別應該沿著類似責任的軌跡來分割。

這項分割的主要好處是處理佇列的責任(許多使用案例通用)會與管理作業的特定作業(這個使用案例專用)分開。這會使類別更容易理解,也更容易隨著設計的成熟而進行調整。另外,它還有平衡系統負荷量的好處,因為這時可以依照需要建立許多作業參數來處理工作量。

將主要事件流程和替代/例外事件流程封裝在個別控制類別中

為了簡化變更,請將主要事件流程和替代事件流程封裝在不同的控制類別中。如果替代和例外流程互不相關,它們也要分開。這會使系統日後比較容易擴充和維護。

當兩個參與者共用相同控制類別時,區分控制類別

當多個參與者使用相同控制類別時,也可能需要區分各個控制類別。在執行這個動作之後,會將單一參與者的需求變更和系統其餘部分隔開。如果變更成本很高,或結果很糟,您應該找出所有關聯於多個參與者的控制類別,將它們分開。在理想情況中,每個控制類別都應該與單一參與者互動(透過某個界限物件),或完全不與任何參與者互動。

範例:電話管理

請設想區域電話使用案例。開始時,我們可以識別一個控制類別來管理電話本身。

使用案例所涉及的不同參與者通常會需要個別的控制類別

處理電話系統區域電話的控制類別,會很快分成 A 行為B 行為這兩個控制類別,所涉及的每個參與者各有一個控制類別。

在區域電話中,有 A 訂閱者B 訂閱者這兩個參與者,A 訂閱者發話,B 訂閱者收話。A 訂閱者拿起聽筒,聽到撥號音,再撥號,系統會儲存和分析這個號碼。當系統收到整個號碼之後,它會向 A 訂閱者送出鈴音,向 B 訂閱者送出鈴聲信號。當 B 訂閱者接話時,鈴音和信號便會停止,兩個訂閱者便可以開始交談。當這兩個訂閱者掛斷電話時,這次電話便告完成。

A 訂閱者端和 B 訂閱者端所發生的兩個行為都必須受到控制。因此,原始控制物件便分成 A 行為B 行為這兩個控制物件。

在下列情況下,您不需要區分控制類別:

  • 您可以合理確定控制類別物件之相關參與者的行為永遠不會變更,或只會有少許改變。
  • 控制類別物件針對某參與者的行為,比針對其他參與者的行為不重要得多,單一物件便足以保存所有行為。依照這個方式來組合行為,不太會影響可變性。

實體類別 實體類別圖示

實體類別用來建立資訊及必須儲存之相關行為的模型。實體物件(實體類別的實例)用來保留和更新某些現象(如事件、人員或某些實現世界的物件)的相關資訊。它們通常會持續存在,有長期需要的屬性和關係,有時會貫穿系統的整個生命週期。

實體物件通常不是專用於單一分析使用案例實現化;有時候,實體物件甚至不是給系統本身專用。它的屬性和關係值通常是由參與者來提供。通常也必須有實體物件,才能夠協助執行內部系統作業。實體物件可以有複雜度如同其他物件模板的行為。不過,和其他物件不同,這個行為與實體物件所代表的現象有很緊密的關係。實體物件與環境(參與者)無關。

實體物件代表開發中之系統的主要概念。帳戶客戶便是銀行業系統中典型的實體類別範例。節點鏈結是網路處理系統中的範例。

如果沒有任何其他類別使用您想要建立模型的現象,您可以在模型中,將它建立成某個實體類別的屬性,甚至可以將它建立成實體類別之間的關係。從另一方面來說,如果設計模型中有任何其他類別使用這個現象,您就必須在模型中,將它建立成一個類別。

實體類別提供另一個瞭解系統的觀點,因為它們會顯示邏輯資料結構,可協助您瞭解系統會向使用者提供什麼。

尋找實體類別

實體類別代表系統中的資訊儲存庫;它們通常用來代表系統所管理的主要概念。實體物件經常是被動的,且具有持續性。它們的主要責任是在系統中儲存和管理資訊。

實體類別的靈感來源經常是名詞解釋(需求期間所開發)和商業領域模型(如果已建立商業模型,便是在商業模型建立期間所開發)。

關聯模板使用限制

界限類別的限制

容許項目如下:

  • 兩個界限類別之間的通訊關聯,例如,用來說明特定視窗如何關聯於其他界限物件。
  • 界限類別到實體類別的通訊或訂閱關聯,因為界限物件可能需要在界限物件的動作之間追蹤特定實體物件,或收到實體物件狀態變更的通知。
  • 從界限類別到控制類別的通訊關聯,使界限物件能夠觸發特定行為。

控制類別的限制

容許項目如下:

  • 控制類別和實體類別之間的通訊或訂閱關聯,因為控制物件可能需要在控制物件的動作之間追蹤特定實體物件,或收到實體物件狀態變更的通知。
  • 控制和界限類別之間的通訊關聯,可讓所呼叫之行為的結果傳給環境。
  • 控制類別之間的通訊關聯,可供建構更複雜的行為型樣。

實體類別的限制

實體類別只應該是通往其他實體類別之關聯(通訊或訂閱)的來源。實體類別物件的存在時間往往比較長;控制和界限類別的存在時間往往比較短。從架構的角度來看,限制實體物件對於週遭項目的可見度是合理的,在這個方式之下,系統會更好管理。

限制摘要

來往
(可導覽性)

界限

實體

控制

界限

通訊

通訊

訂閱

通訊

實體

通訊

訂閱

 

控制

通訊

通訊

訂閱

通訊

有效的關聯模板組合

強制一致性

  • 當識別新的行為時,請檢查是否有現存類別具備類似的責任,請儘可能重複使用類別。您只應該在沒有現存物件可供執行這個行為時,才建立新的類別。
  • 當識別類別時,請檢查它們,以確定它們有一致的責任。類別責任分開之後,請將物件分成兩個或更多類別。請據此來更新互動圖。
  • 如果因發現責任混亂而分割類別,請檢查類別在其中扮演角色的協同作業,以瞭解是否需要更新協同作業。必要的話,請更新協同作業。
  • 只含有單一責任的類別本身並不是問題,但它應該提出為什麼需要它的問題。請準備挑戰所有類別的存在,並證明它們的存在合理。