面向物件的分析與設計

    面向物件方法是一種非常實用的軟體開發方法，它一出現就受到軟體技術人員的青睞，現已成為電腦科學研究的一個重要領域，並逐漸成為軟體開發的一種主要方法。面向物件方法以客觀世界中的物件為中心，其分析和設計思想符合人們的思維方式，分析和設計的結構與客觀世界的實際比較接近，容易被人們接受。在面向物件方法中，分析和設計的介面並不明顯，它們採用相同的符號表示，能夠方便地從分析階段平滑地過渡到設計階段。此外，在現實生活中，使用者的需求經常會發生變化，但客觀世界的物件及物件間的關係比較穩定，因此用面向物件方法分析和設計的結構也相對比較穩定。

1 面向物件的基本概念

    1．物件和類

    物件是系統中用來描述客觀事物的一個實體，它由物件標識（名稱）、屬性（狀態、資料、成員變數）和服務（操作、行為、方法）三個要素組成，它們被封裝為一個整體，以介面的形式對外提供服務。

    在現實世界中，每個實體都是物件，如學生、書籍、收音機等；每個物件都有它的操作，例如書籍的頁數，收音機的頻道、按鈕等屬性，以及收音機的切換頻道等操作。

    而類則是對具有相同屬性和服務的一個或一組物件的抽象。類與物件是抽象描述和具體例項的關係，一個具體的物件被稱為類的一個例項。在系統設計過程中，類可以分為三種類型，分別是實體類、邊界類和控制類。

    （1）實體類：實體類對映需求中的每個實體，實體類儲存需要儲存在永久儲存體中的資訊，例如，線上教育平臺系統可以提取出學員類和課程類，它們都屬於實體類。實體類通常都是永久性的，它們所具有的屬性和關係是長期需要的，有時甚至在系統的整個生存期都需要。

   實體類是對使用者來說最有意義的類，通常採用業務領域術語命名，一般來說是一個名詞，在用例模型向領域模型的轉化中，一個參與者一般對應於實體類。通常可以從 SRS 中的那些與資料庫表（需要持久儲存）對應的名詞著手來找尋實體類。通常情況下，實體類一定有屬性，但不一定有操作。

    （2）控制類：控制類是用於控制用例工作的類，一般是由動賓結構的短語（“動詞+名詞”或“名詞+動詞”）轉化來的名詞，例如，用例“身份驗證”可以對應於一個控制類“身份驗證器”，它提供了與身份驗證相關的所有操作。控制類用於對一個或幾個用例所特有的控制行為進行建模，控制物件（控制類的例項）通常控制其他物件，因此，它們的行為具有協調性。

    控制類將用例的特有行為進行封裝，控制物件的行為與特定用例的實現密切相關，當系統執行用例的時候，就產生了一個控制物件，控制物件經常在其對應的用例執行完畢後消亡。通常情況下，控制類沒有屬性，但一定有方法。

    （3）邊界類：邊界類用於封裝在用例內、外流動的資訊或資料流。邊界類位於系統與外界的交接處，包括所有窗體、報表、印表機和掃描器等硬體的介面，以及與其他系統的介面。要尋找和定義邊界類，可以檢查用例模型，每個參與者和用例互動至少要有一個邊界類，邊界類使參與者能與系統互動。邊界類是一種用於對系統外部環境與其內部運作之間的互動進行建模的類。常見的邊界類有視窗、通訊協議、印表機介面、感測器和終端等。實際上，在系統設計時，產生的報表都可以作為邊界類來處理。

    邊界類用於系統介面與系統外部進行互動，邊界物件將系統與其外部環境的變更（例如，與其他系統的介面的變更、使用者需求的變更等）分隔開，使這些變更不會對系統的其他部分造成影響。通常情況下，邊界類可以既有屬性也有方法。

    2．繼承與泛化

    繼承是面向物件方法中重要的概念，用來說明特殊類（子類）與一般類（父類）的關係，而通常用泛化來說明一般類與特殊類的關係，也就是說它們是一對多關係。

   如圖 8-11 所示，“交通工具”是“自行車”和“小轎車”的泛化；“自行車”和“小轎車”從“交通工具”中繼承。

    3．多型與過載

    多型（即多種形式）性是指一般類中定義的屬性或服務被特殊類繼承後，可以具有不同的資料型別或表現出不同的行為，通常是使用過載和改寫兩項技術來實現的。一般有4種不同形式的多型，如表 8-4 所示。

               注 1：過載也稱為過載、重置；

               注 2：引數多型和包含多型稱為通用多型，過載多型和強制多型稱為特定多型。 

    雖然過載和改寫都是在多種潛在的函式體中，選擇和呼叫某一個函式或方法並對其進行執行，但它們的本質區別在於：過載是編譯時執行的（靜態繫結），而改寫則是執行時選擇的（動態繫結）。

    4．模板類

    也稱為類屬類，它用來實現引數多型機制。一個類屬類是關於一組類的一個特性抽象，它強調的是這些類的成員特徵中與具體型別無關的那些部分，而用變元來表示與具體型別有關的那些部分。

    5．訊息和訊息通訊

    訊息就是向物件發出的服務請求，它通常包括提供服務的物件標識、訊息名、輸入資訊和回答資訊。訊息通訊則是面向物件方法學中的一個重要原則，它與物件的封裝原則密不可分，為物件間提供了唯一合法的動態聯絡的途徑。

2 面向物件分析

    面向物件分析的目標是開發一系列模型，這些模型描述計算機軟體，當它工作時以滿足一組客戶定義的需求。物件技術的流行，演化出了數十種不同的 OOA 方法，每個方法都引入了一個產品或系統分析的過程、一組過程演化的模型及使軟體工程師能夠以一致的方式建立每個模型的符號體系。其中比較流行的方法包括 OMT、OOA、OOSE、Booch 方法等，而 OMT、OOSE、Booch 最後則統一成為 UML。 

    1．OOA/OOD 方法

    這是由 Peter Coad 和 Edward Yourdon 提出的，OOA 模型中包括主題、物件類、結構、屬性和服務 5 個層次，需經過標識物件類、標識結構與關聯（包括繼承、聚合、組合、例項化等）、劃分主題、定義屬性、定義服務 5 個步驟來完成整個分析工作。

OOD 中將繼續貫穿 OOA 中的 5 個層次和 5 個活動，它由人機互動部件、問題域部件、任務管理部件、資料管理部件 4 個部分組成，其主要的活動就是這 4 個部件的設計工作。

• 設計問題域部分：OOA 的結果恰好是 OOD 的問題域部件，分析的結果在 OOD 中可以被改動或增補，但基於問題域的總體組織框架是長時間穩定的；

• 設計人機互動部件：人機互動部件在上述結果中加入人機互動的設計和互動的細節，包括視窗和輸出報告的設計。可以用原型來幫助實際互動機制進行開發和選擇；

• 設計任務管理部分：這部分主要是識別事件驅動任務，識別時鐘驅動任務，識別優先任務和關鍵任務，識別協調者，審查每個任務並定義每個任務。

• 設計資料管理部分：資料管理部分提供了在資料管理系統中儲存和檢索物件的基本結構，其目的是隔離資料管理方法對其他部分的影響。

    2．Booch 方法

    Booch 認為軟體開發是一個螺旋上升的過程，每個週期中包括標識類和物件、確定類和物件的含義、標識關係、說明每個類的介面和實現 4 個步驟。它的模型中主要包括如表 8-5 所示的幾種圖形。

    Booch 方法的開發過程是一個迭代的、漸進式的系統開發過程，它可以分為巨集過程和微過程兩類。巨集過程用於控制微過程，是覆蓋幾個月或幾周所進行的活動，它包括負責建立核心需求的概念化，為所期望的行為建立模型的分析，建立架構的設計，形成實現的進化，以及管理軟體交付使用的維護等 5 個主要活動。

    而微過程則基本上代表了開發人員的日常活動，它由 4 個重要、沒有順序關係的步驟組成：在給定的抽象層次上識別出類和物件，識別出這些類和物件的語義，識別出類間和物件間的關係，實現類和物件。

    3．OMT 方法

    OMT 是物件建模技術的縮寫，它是由 Jam Rambaugh 及其同事合作開發的，它主要用於分析、系統設計和物件設計。包括物件模型（靜態的、結構化的系統的“資料”性質，通常採用類圖）、動態模型（瞬時的、行為化的系統“控制”性質，通常使用狀態圖）和功能模型（表示變化的系統的“功能”性質，通常使用資料流圖）。OMT 方法的三大模型如表 8-6 所示。

    4.OOSE 方法

    OOSE 是面向物件軟體工程的縮寫，它是由 Ivar Jacobson 提出的。它在 OMT 的基礎上，對功能模型進行了補充，提出了“用例”的概念，最終取代資料流圖進行需求分析和建立功能模型。

3 統一建模語言

    統一建模語言（Unified Modeling Language，UML）是用於系統的視覺化建模語言，它將OMT、OOSE 和 Booch 方法中的建模語言和方法有機地融合在一起，是國際統一的軟體建模標準。雖然它源於 OO 軟體系統建模領域，但由於其內建了大量擴充套件機制，也可以應用於更多的領域中，例如工作流程、業務領域等。

     1．UML 是什麼

• UML 是一種語言：UML 在軟體領域中的地位與價值就像“1、2、3、+、、…”等符號在數學領域中的地位一樣。它為軟體開發人員之間提供了一種用於交流的詞彙表和一種用於軟體藍圖的標準語言。

• UML 是一種視覺化語言：UML 只是一組圖形符號，它的每個符號都有明確語義，是一種直觀、視覺化的語言。

• UML 是一種可用於詳細描述的語言：UML 所建的模型是精確的、無歧義和完整的，因此適合於對所有重要的分析、設計和實現決策進行詳細描述。

• UML 是一種構造語言：UML 雖然不是一種視覺化的程式語言，但其與各種程式語言直接相連，而且有較好的對映關係，這種對映允許進行正向工程、逆向工程。

• UML 是一種文件化語言：它適合於建立系統架構及其所有的細節文件。

    2．UML 的結構

    UML 由構造塊、公共機制和規則三個部分組成。

    （1）構造塊。構造塊也就是基本的 UML 建模元素（事物）、關係和圖。

• 建模元素：包括結構事物（類、介面、協作、用例、活動類、元件、節點等）、行為事物（互動、狀態機）、分組事物（包）、註釋事物。

• 關係：包括關聯關係、依賴關係、泛化關係、實現關係。

• 圖：UML 2.0 包括 14 種不同的圖，分為表示系統靜態結構的靜態模型（包括類圖、物件圖、包圖、構件圖、部署圖、製品圖），以及表示系統動態結構的動態模型（包括物件圖、用例圖、順序圖、通訊圖、定時圖、狀態圖、活動圖、互動概覽圖）。

    （2）公共機制。公共機制是指達到特定目標的公共 UML 方法，主要包括規格說明、修飾、公共分類和擴充套件機制 4 種。

• 規格說明：規格說明是元素語義的文字描述，它是模型的重要組成部分。

• 修飾：UML  為每一個模型元素設定了一個簡單的記號，還可以通過修飾來表達更多的資訊。

• 公共分類：包括類元與實體（類元表示概念，而實體表示具體的實體）、介面和實現（介面用來定義契約，而實現就是具體的內容）兩組公共分類。

• 擴充套件機制：包括約束（新增新規則來擴充套件元素的語義）、構造型（用於定義新的 UML

• 建模元素）、標記值（新增新的特殊資訊來擴充套件模型元素的規格說明）。

    （3）規則。規則是構造塊如何放在一起的規定，包括為構造塊命名；給一個名字以特定含義的語境，即範圍怎樣使用或看見名字，即可見性事物如何正確、一致地相互聯絡，即完整性；執行或模擬動態模型的含義是什麼，即執行。

        UML 對系統架構的定義是：系統的組織結構，包括系統分解的組成部分、它們的關聯性、互動、機制和指導原則，這些提供系統設計的資訊。而具體來說，就是指 5 個系統檢視。

• 邏輯檢視：以問題域的語彙組成的類和物件集合。

• 程序檢視：可執行執行緒和程序作為活動類的建模，它是邏輯檢視的一次執行例項。

• 實現檢視：對組成基於系統的物理程式碼的檔案和元件進行建模。

• 部署檢視：把元件物理地部署到一組物理的、可計算的節點上。

• 用例檢視：最基本的需求分析模型。

    3．用例圖基礎 

    用例是什麼呢？Ivar Jacobson 是這樣描述的：“用例例項是在系統中執行的一系列動作，這些動作將生成特定參與者可見的價值結果。一個用例定義一組用例例項。”首先，從定義中得知用例是由一組用例例項組成的，用例例項也就是常說的“使用場景”，就是使用者使用系統的一個實際的、特定的場景。其次，可以知道，用例應該給參與者帶來可見的價值，這點很關鍵。最後，用例是在系統中的。

    而用例模型描述的是外部參與者所理解的系統功能。用例模型用於需求分析階段，它的建立是系統開發者和使用者反覆討論的結果，表明了開發者和使用者對需求規格達成的共識。圖 8-12 就是一個用例圖的例子。

    （1）參與者。參與者代表與系統介面的任何事物或人，它是指代表某一種特定功能的角色，因此，參與者都是虛擬的概念。在 UML 中，用一個小人表示參與者。

   圖8-12 中的“圖書管理員”就是參與者。對於該系統來說，可能可以充當圖書管理員角色的有多個人，由於他們對系統均起著相同的作用，扮演相同的角色，因此只用一個參與者來表示。切忌不要為每一個可能與系統互動的真人畫出一個參與者。

    （2）用例。用例是對系統行為的動態描述，它可以促進設計人員、開發人員與使用者的溝通，理解正確的需求，還可以劃分系統與外部實體的界限，是系統設計的起點。在識別出參與者之後，可以使用下列問題幫助識別用例。

• 每個參與者的任務是什麼？

• 有參與者將要建立、儲存、修改、刪除或讀取系統中的資訊嗎？

• 什麼用例會建立、儲存、修改、刪除或讀取這個資訊？

• 參與者需要通知系統外部的突然變化嗎？

• 需要通知參與者系統中正在發生的事情嗎？

• 什麼用例將支援和維護系統？

• 所有的功能需求都對應到用例中了嗎？

• 系統需要何種輸入/輸出？輸入從何處來？輸出到何處？

• 當前執行系統的主要問題是什麼？

    （3）包含和擴充套件。兩個用例之間的關係可以主要概括為兩種情況。一種是用於重用的包含關係，用構造型<<include>>或者<<use>>表示；另一種是用於分離出不同的行為，用構造型<<extend>>表示。

• 包含關係：當可以從兩個或兩個以上的原始用例中提取公共行為，或者發現能夠使用一個元件來實現某一個用例的部分功能是很重要的事時，應該使用包含關係來表示。所提取出來的公共行為稱為抽象用例。包含關係的例子如圖 8-13 所示。

• 擴充套件關係：如果一個用例明顯地混合了兩種或兩種以上的不同場景，即根據情況可能發生多種事情。可以將這個用例分為一個主用例和一個或多個輔用例，描述可能更加清晰。擴充套件關係的例子如圖 8-14 所示。

    此處介紹的包含和擴充套件關係屬於用例之間所特有的關係，因為用例也是UML 的一種結構事物，因此，事物之間的 4 種基本關係對用例也是適用的。

    4．類圖和物件圖基礎

    在面向物件建模技術中，將客觀世界的實體對映為物件，並歸納成一個個類。類、物件和它們之間的關聯是面向物件技術中最基本的元素。對於一個想要描述的系統，其類模型和物件模型揭示了系統的結構。在 UML 中，類和物件模型分別由類圖和物件圖表示。類圖技術是 OO 方法的核心。圖 8-15 是一個類圖的例項。

    （1）類和物件。物件與人們對客觀世界的理解相關。人們通常用物件描述客觀世界中某個具體的實體。所謂類是對一類具有相同特徵的物件的描述。而物件是類的例項。在 UML 中，類的視覺化表示為一個劃分成三個格子的長方形（下面兩個格子可省略）。圖 8-15 中，“書籍”、“借閱記錄”等都是一個類。

• 類的獲取和命名：最頂部的格子包含類的名字。類的命名應儘量用應用領域中的術語，應明確、無歧義，以利於開發人員與使用者之間的相互理解和交流。

• 類的屬性：中間的格子包含類的屬性，用以描述該類物件的共同特點。該項可省略。圖 8-15 中“書籍”類有“書名”、“書號”等屬性。UML 規定類的屬性的語法為： “可見性 屬性名：型別 =  預設值 {約束特性}”。

    可見性包括 Public、Private 和 Protected，分別用+、-、#號表示。

    型別表示該屬性的種類：它可以是基本資料型別，例如整數、實數、布林型等，也可以是使用者自定義的型別。一般它由所涉及的程式設計語言確定。約束特性則是使用者對該屬性性質的一個約束說明。例如“{只讀}”說明該屬性是隻讀屬性。

• 類的操作（Operation）：該項可省略。操作用於修改、檢索類的屬性或執行某些動作。操作通常也被稱為功能，但是它們被約束在類的內部，只能作用到該類的物件上。操作名、返回型別和引數表組成操作介面。UML 規定操作的語法為：“可見性：操作名（引數表）：返回型別 {約束特性}”。

     類圖描述了類和類之間的靜態關係。定義了類之後，就可以定義類之間的各種關係了。

     （2）類之間的關係。在建立抽象模型時，會發現很少有類會單獨存在，大多數都將會以某種方式互相協作，因此還需要描述這些類之間的關係。關係是事物間的連線，在面向物件建模中，有 4 個很重要的關係。

    ① 依賴關係。有兩個元素 X、Y，如果修改元素 X 的定義可能會引起對另一個元素 Y 的定義的修改，則稱元素 Y 依賴於元素 X。在 UML 中，使用帶箭頭的虛線表示依賴關係。

    在類中，依賴由多種原因引起，如：一個類向另一個類發訊息；一個類是另一個類的資料成員；一個類是另一個類的某個操作引數。如果一個類的介面改變，它發出的任何訊息可能不再合法。

     ② 泛化關係。泛化關係描述了一般事物與該事物中的特殊種類之間的關係，也就是父類與子類之間的關係。繼承關係是泛化關係的反關係，也就是說子類是從父類中繼承的，而父類則是子類的泛化。在 UML 中，使用帶空心箭頭的實線表示，箭頭指向父類。

    在 UML 中，對泛化關係有 3 個要求：

• 子類應與父類完全一致，父類所具有的關聯、屬性和操作，子類都應具有。

• 子類中除了與父類一致的資訊外，還包括額外的資訊。

• 可以使用子父類例項的地方，也可以使用子類例項。

    ③ 關聯關係。關聯表示兩個類之間存在某種語義上的聯絡。例如，一個人為一家公司工作，一家公司有許多辦公室。就認為人和公司、公司和辦公室之間存在某種語義上的聯絡。

    關聯關係提供了通訊的路徑，它是所有關係中最通用的、語義最弱的。在 UML 中，用一條實線來表示關聯關係。

• 聚合關係：聚合是一種特殊形式的關聯。聚合表示類之間的關係是整體與部分的關係。例如一輛轎車包含四個車輪、一個方向盤、一個發動機和一個底盤，就是聚合的一個例子。在 UML 中，用一個帶空心菱形的實線表示，空心菱形指向的是代表“整體”的類。

• 組合關係：如果聚合關係中的表示“部分”的類的存在，與表示“整體”的類有著緊密的關係，例如“公司”與“部門”之間的關係，那麼就應該使用“組合”關係來表示。在 UML 中，用帶有實心菱形的實線表示，菱形指向的是代表“整體”的類。

    聚合關係是指部分與整體的生命週期可以不相同，而組合關係則是指部分與整體的生命週期是相同的。

    ④ 實現關係。實現關係是用來規定介面和實現介面的類或元件之間的關係的。介面是操作的集合，這些操作用於規定類或元件的服務。在 UML 中，用一個帶空心箭頭的虛線表示。

    （3）多重性問題。重複度又稱多重性，多重性表示為一個整數範圍 n…m，整數 n 定義所連線的最少物件的數目，而 m 則為最多物件數（當不知道確切的最大數時，最大數用*號表示）。最常見的多重性有：0…1；0…*；1…1；1…*；*。

    多重性是用來說明關聯的兩個類之間的數量關係的，例如：

• 書與借書記錄之間的關係，就應該是 1 對 0…1 的關係，也就是一本書可以有 0 個或 1 個借書記錄。

• 經理與員工之間的關係，則應為 1 對 0…*的關係，也就是一個經理可以領導 0 個或多個員工。

• 學生與選修課程之間的關係，就可以表示為 0…*對 1…*的關係，也就是一個學生可以選擇 1 門或多門課程，而一門課程可以有 0 個或多個學生選修。

    （4）類圖。對於軟體系統，其類模型和物件模型類圖描述類和類之間的靜態關係。與資料模型不同，它不僅顯示了資訊的結構，同時還描述了系統的行為。類圖是定義其他圖的基礎。

    （5）物件圖。UML 中物件圖與類圖具有相同的表示形式。物件圖可以看作是類圖的一個例項。物件是類的例項；物件之間的鏈（Link）是類之間的關聯的例項。物件與類的圖形表示相似，均為劃分成兩個格子的長方形（下面的格子可省略）。上面的格子是物件名，物件名下有下畫線；下面的格子記錄屬性值。鏈的圖形表示與關聯相似。物件圖常用於表示複雜類圖的一個例項。

    5．互動圖基礎

    互動圖是表示各組物件如何依某種行為進行協作的模型。通常可以使用一個互動圖來表示和說明一個用例的行為。在 UML 中，包括 3 種不同形式的互動圖，強調物件互動行為順序的順序圖，強調物件協作的通訊圖（UML1.X 版本中稱為“協作圖”），強調訊息的具體時間的定時圖，它們之間沒有什麼本質不同，只是排版不盡相同而已。

    （1）順序圖。順序圖用來描述物件之間動態的互動關係，著重體現物件間訊息傳遞的時間順序。順序圖允許直觀地表示出物件的生存期，在生存期內，物件可以對輸入訊息做出響應，並且可以傳送資訊。圖 8-16 是一個順序圖的示例。

    如圖 8-16 所示，順序圖存在兩個軸，水平軸表示不同的物件，即圖中的 Client、Factory、Product 等；而垂直軸表示時間，表示物件及類的生命週期。

    物件間的通訊通過在物件的生命線間畫訊息來表示。訊息的箭頭指明訊息的型別。順序圖中的訊息可以是訊號、操作呼叫或類似於 C++中的 RPC（Remote Procedure Calls）和 Java 中的RMI（Remote Method Invocation）。當收到訊息時，接收物件立即開始執行活動，即物件被激活了。通過在物件生命線上顯示一個細長矩形框來表示啟用。

    訊息可以用訊息名及引數來標識，訊息也可帶有順序號。訊息還可帶有條件表示式，表示分支或決定是否傳送訊息。如果用於表示分支，則每個分支是相互排斥的，即在某一時刻僅可傳送分支中的一個訊息。

    （2）通訊圖。通訊圖用於描述相互合作的物件間的互動關係和連結關係。雖然順序圖和通訊圖都用來描述物件間的互動關係，但側重點不一樣。順序圖著重體現互動的時間順序，通訊圖則著重體現互動物件間的靜態連結關係。圖 8-17 就是與圖 8-16 相對應的通訊圖，可以從圖 8-17 中很明顯地發現它與順序圖之間的異同點。

    （3）定時圖。如果要表示的互動具有很強的時間特性（例如，現實生活中的電子工程、實時控制等系統中），在 UML 1.X 中是無法有效地表示出來的。而在 UML 2.0 中引入了一種新的互動圖來解決這類問題，這就是著重表示定時約束的定時圖。

   根據 UML 的定義，定時圖實際上是一種特殊形式的順序圖（即一種變化），它與順序圖的區別主要體現在以下幾個方面。

• 座標軸交換了位置，改為從左到右來表示時間的推移。

• 用生命線的“凹下凸起”來表示狀態的變化，每個水平位置代表一種不同的狀態，狀態的順序可以有意義、也可以沒有意義。

• 生命線可以跟在一根線後面，在這根線上顯示一些不同的狀態值。

• 可以顯示一個度量時間值的標尺，用刻度來表示時間間隔。

    圖 8-18 是一個定時圖的實際例子，其中小黑點加曲線表示的是註釋。它用來表示一個電子門禁系統的控制邏輯，該門禁系統包括門（物理的門）、智慧讀卡器（讀取使用者的智慧卡資訊）、處理器（用來處理是否開門的判斷）。

    在這個例子中，它所表示的意思是一開始讀卡器是啟用的（等使用者來刷卡）、處理器是空閒的（沒有驗證的請求）、門是關的；接著，當用戶刷卡時，讀卡器就進入了“等待校驗” 的狀態，併發一個訊息給處理器，處理器就進入了校驗狀態。如果校驗通過，就傳送一個“禁用”訊息給讀卡器（因為門開的時候，讀卡器就可以不工作），使讀卡器進入禁用狀態；並且自己轉入啟用狀態，這時門的狀態變成了“開”。而門“開”了 30 秒鐘（根據時間刻度得知）之後，處理器將會把它再次“關”上，並且傳送一個“啟用”訊息給讀卡器（門關了，讀卡器開始重新工作），這時讀卡器再次進入啟用狀態，而處理器已經又回到了空閒狀態。

    從上面的例子中，不難看出定時圖所包含的圖元並不多，主要包括生命線、狀態、狀態變遷、訊息、時間刻度，可以根據自身的需要來使用它。

    6．狀態圖基礎狀態圖

    用來描述一個特定物件的所有可能狀態及其引起狀態轉移的事件。大多數面向物件技術都用狀態圖表示單個物件在其生命週期中的行為。一個狀態圖包括一系列的狀態及狀態之間的轉移。圖8-19 是一個數碼沖印店的訂單狀態圖例項。

    狀態圖包括以下部分。

• 狀態：又稱為中間狀態，用圓角矩形框表示；

• 初始狀態：又稱為初態，用一個黑色的實心圓圈表示，在一張狀態圖中只能夠有一個初始狀態；

• 結束狀態：又稱為終態，在黑色的實心圓圈外面套上一個空心圓，在一張狀態圖中可能有多個結束狀態；

• 狀態轉移：用箭頭說明狀態的轉移情況，並用文字說明引發這個狀態變化的相應事件是什麼。

    一個狀態也可能被細分為多個子狀態，那麼如果將這些子狀態都描繪出來的話，那這個狀態就是複合狀態。

    狀態圖適合用於表述在不同用例之間的物件行為，但並不適合用於表述包括若干用例協作的物件行為。通常不會需要對系統中的每一個類繪製相應的狀態圖，而通常會在業務流程、控制物件、使用者介面的設計方面使用狀態圖。

    7．活動圖基礎

    活動圖的應用非常廣泛，它既可用來描述操作（類的方法）的行為，也可以描述用例和物件內部的工作過程。活動圖是由狀態圖變化而來的，它們各自用於不同的目的。活動圖依據物件狀態的變化來捕獲動作（將要執行的工作或活動）與動作的結果。活動圖中一個活動結束後將立即進入下一個活動（在狀態圖中狀態的變遷可能需要事件的觸發）。

    （1）基本活動圖。圖 8-20 給出了一個基本活動圖的例子。

    如圖 8-20 所示，活動圖與狀態圖類似，包括了初始狀態、終止狀態，以及中間的活動狀態，每個活動之間，也就是一種狀態的變遷。在活動圖中，還引入了以下幾個概念。

• 判定：說明基於某些表示式的選擇性路徑，在 UML中使用菱形表示。

• 分支與組合：由於活動圖建模時，經常會遇到併發流，因此在 UML 中引入瞭如上圖 8-20 所示的粗線來表示分支和組合。

     （2）帶泳道的活動圖。在前面說明的基本活動圖中，雖然能夠描述系統發生了什麼，但沒有說明該項活動由誰來完成。而針對 OOP 而言，這就意味著活動圖沒有描述出各個活動由哪個類來完成。要想解決這個問題，可以通過泳道來解決這一問題。它將活動圖的邏輯描述與順序圖、協作圖的責任描述結合起來。圖 8-21 是一個使用了泳道的例子。

    （3）物件流。在活動圖中可以出現物件。物件可以作為活動的輸入或輸出，物件與活動間的輸入/輸出關係由虛線箭頭來表示。如果僅表示物件受到某一活動的影響，則可用不帶箭頭的虛線來連線物件與活動。

    （4）訊號。在活動圖中可以表示訊號的傳送與接收，分別用傳送和接收標識來表示。傳送和接收標識也可與物件相連，用於表示訊息的傳送者和接收者。

    8．構件圖基礎

    構件圖是面向物件系統的物理方面進行建模要用的兩種圖之一。它可以有效地顯示一組構件，以及它們之間的關係。構件圖中通常包括構件、介面及各種關係。圖 8-22 就是一個構件圖的例子。

    通常構件指的是原始碼檔案、二進位制程式碼檔案和可執行檔案等。而構件圖就是用來顯示編譯、連結或執行時構件之間的依賴關係的。例如，在圖 8-22 中，就是說明 QueryClient.exe 將通過呼叫 QueryServer.exe來完成相應的功能，而 QueryServer.exe 則需要 Find.exe 的支援，Find.exe 在實現時呼叫了 Query.dll。

    通常來說，可以使用構件圖完成以下工作。

• 對原始碼進行建模：這樣可以清晰地表示出各個不同源程式檔案之間的關係。

• 對可執行體的釋出建模：如圖 8-22 所示，將清晰地表示出各個可執行檔案、DLL 檔案之間的關係。

• 對物理資料庫建模：用來表示各種型別的資料庫、表之間的關係。

• 對可調整的系統建模：例如對應用了負載均衡、故障恢復等系統的建模。

    在繪製構件圖時，應該注意側重於描述系統的靜態實現檢視的一個方面，圖形不要過於簡化，應該為構件圖取一個直觀的名稱，在繪製時避免產生線的交叉。 

    9．部署圖基礎

    部署圖，也稱為實施圖，它和構件圖一樣，是面向物件系統的物理方面建模的兩種圖之一。構件圖是說明構件之間的邏輯關係，而部署圖則是在此基礎上更進一步地描述系統硬體的物理拓撲結構及在此結構上執行的軟體。部署圖可以顯示計算結點的拓撲結構和通訊路徑、結點上執行的軟體構件，常用於幫助理解分散式系統。

   圖 8-23 就是與圖 8-22 對應的部署圖，這樣的圖示可以使系統的安裝、部署更為簡單。在部署圖中，通常包括以下一些關鍵的組成部分。

    （1）節點和連線。節點代表一個物理裝置及其上執行的軟體系統，如一臺 UNIX 主機、一個PC 終端、一臺印表機、一個感測器等。

    如圖 8-23 所示，“客戶端：個人 PC”和“伺服器”就是兩個節點。在 UML 中，使用一個立方體表示一個節點，節點名放在左上角。節點之間的連線表示系統之間進行互動的通訊路徑，在UML 中被稱為連線。通訊型別則放在連線旁邊的“《》”之間，表示所用的通訊協議或網路型別。

    （2）構件和介面。在部署圖中，構件代表可執行的物理程式碼模組，如一個可執行程式。邏輯上它可以與類圖中的包或類對應。例如，在圖 8-23  中，“伺服器”結點中包含“QueryServer.exe”、“Find.exe”和“Query.dll”3 個構件。

    在面向物件方法中，類和構件等元素並不是所有的屬性和操作都對外可見。它們對外提供了可見操作和屬性，稱之為類和構件的介面。介面可以表示為一頭是小圓圈的直線。在圖 8-23 中，“Query.dll”構件提供了一個“查詢”介面。