【UML】統一建模語言及工具「通關指南」

共 4 個 Chapter
參考資料：
UML軟件建模技術-基於IBM RSA工具（清華大學出版社）
UML2.0基礎與RSA建模實例教程（人民郵電）
面向對象葵花寶典（李運華）（電子工業出版社）
火球——UML大戰需求分析（第二版）（張傳波 ）
吉林大學統一建模語言及工具 ppt

Why we modeling and What is UML

Why We Modeling

What is a model?

• A model is a simplification of reality.

What is Modeling?

• 建模就是認識現實世界

What is Software Models?

• 軟件模型的概念

  • 軟件模型：通過一定的形式和方法用來描述軟件的模型。
  • 軟件建模：建立軟件模型的過程被稱為軟件建模。

• 軟件模型的內容

  • 需求模型：描述軟件向用戶所能夠提供的外在特性，包括軟件的目標、
    功能、性能等。
  • 分析模型：立足於系統的抽象邏輯建模.
  • 設計模型：軟件設計方案的規范化描述。包括軟件的架構、詳細設計、界面設計、數據庫設計等模型。
  • 測試模型：測試軟件的方案描述.

Software Modeling

Software modeling elements：

Object oriented software modeling：
在軟件開發中，采用與人的思維方式相一致的，直接面向客觀事物，面向所要解決的需求問題，並用一套對象、類、繼承、消息等機制開發軟件的系統化軟件建模方法。

特點：

• 對象是軟件建模的重心
• 包括需求、設計、實現等多種模型

Software modeling process：

• 是指根據軟件開發的需要,進行業務建模、需求建模、分析建模、設計建模和測試建模的過程。
  

Software modeling tools：

• Rational Rose2003
• Enterprise Architect
• Microsoft Visio
• IBM Rational Software Architect
• starUML

Introducing the UML

What is UML?：
Unified Modeling Language

• Unified: UML has become a world standard
• Modeling: Describing a software system at a high level of abstraction
• Language: More comprehensible, ready-to-use, expressive, and visualing.

The UML Is a Language for Visualizing, Specifying, Constructing and Documenting

• Visualizing

  • Communicating conceptual models to others is prone to error unless everyone involved speaks the same language.
  • There are things about a software system you can’t understand unless you build models.
  • An explicit model facilitates communication.

• Specifying

  • To build models that are precise, unambiguous, and complete. In particular, the UML addresses the specification of all the important analysis, design, and implementation decisions that must be made to develop and deploy software-intensive systems.

• Constructing

  • UML models can be directly connected to a variety of programming languages.

• Documenting

  • The UML addresses documentation of system architecture, requirements, tests, project planning, and release management.

History of UML

Skip !!!😆

The essence of UML

• UML 軟件過程規定軟件開發的階段、步驟和工作。和程序設計語言的關系
  • Java、C++ 等程序設計語言用來編碼實現一個軟件系統。
  • UML用於對一個軟件系統建立模型。
• UML 和軟件過程的關系
  • 軟件過程規定軟件開發的階段、步驟和工作。
  • UML 是語言，用來描述軟件模型。

A Practice of Visual Modeling with UML

UML結構

物件 Things

類 Class

類的定義：

類是具有相同屬性、操作、關系和語義的對象集合的總稱。通常在 UML 中類被畫成矩形

表示形式：

• 類名 The class name

  • 每個類都必須有一個名字，用來區分其它的類。
  • 名詞或名詞短語(動詞或動詞短語表示控制類)。如：人，桌子，圖形，匯總
  • 盡可能明確、簡短，業務領域中事物的名稱，避免使用抽象、無意義的名詞。如：帳戶，訂單
  • 用英文，第1個字母大寫。如：Shape, Person,CheckingAccdount

• 屬性 Attribute

  • 描述類所表示事物的靜態性質
  • 格式：[可見性]屬性名[:類型][‘[ ’多重性[次序]‘]’][=初始值][{特性}]
    • 可見性：該屬性對外部實體的顯現程度。
      • 公有 public: + 所有可見
      • 受限 protected: # 子類及本身可見
      • 私有 private: - 本身可見
      • 包 package: ~ 包內可見
    • 屬性名：第 1 個英文單詞首字母小寫,其它單詞首字母大寫。如：contactName
    • 類型：
      • 字符串: String
      • 日期: Date
      • 布爾: Boolean
      • 整型: int
      • 其他
    • 多重性：表示屬性取值的多寡,以及有序性
      • name:String[0..1]，表示屬性”name”可能無值,也可能僅有一個值
      • points:Point[2..* ordered]：表示有兩個或多個值，有序
    • 初始值：表示屬性初始所取的值
      • #visibility:Boolean=false：表示屬性 visibility 初始取 false
    • 特性：表示屬性約束說明
      • #visibility:Boolean=false{R/W}：表示屬性 visibility 可讀,寫

• 操作

  • 描述類所表示事物的動態性質
  • 格式：[可見性]操作名[(參數列表):返回類型]
    • 可見性：同屬性的可見性格式
    • 操作名：第 1 個英文單詞首字母小寫，其它單詞首字母大寫。如：close()
    • 該操作的形式參數,可以為空。如 #create()， -attachXWindow(xwin: Xwindow)
    • 返回類型：該操作的返回值的類型。如: +display():Boolean

類的類型：
按照其作用，類分為實體類，界面類和控制類三種類型。

• 實體類 Entity Class

  • 實體類用來表示客觀實體，像“圖書”、“學生”，“訂單”等都屬於實體類。
  • 實體類一般對應着在業務領域中的客觀事物，或者是具有較穩定信息內容的系統元素。
  • 實體類的名字用名詞或名詞短語。
  • 

• 界面類 Boundary Class

  • 界面類用來描述系統與外界之間交互的系統要素，也稱為邊界類。
  • 界面類是對外界與系統之間交互的抽象表示，並不表示交互的具體內容，以及交互界面的具體形式。
  • 界面類的名字用名詞或名詞短語。
  • 

• 控制類 Control Class

  • 控制類表示系統用來進行調度、協調、處理，以及業務處理的系統要素。
  • 控制類的名字用動詞或動詞短語表示。
  • 

接口 Interface

類的定義：

• 接口是未給出實現的對象行為的描述，一個或多個類可以實現接口，每個類實現接口的操作。
  

組件 Component

組件的定義：

• 組件代表了一個接口定義良好的軟件模塊。

• 一個組件可能是源代碼、可執行程序或動態庫。如:一個DLL，一個JavaBeans

結點 Node

結點的定義：

• 節點代表系統運行時的物理單元，主要用於系統物理方面的建模。
  

包 Package

包的定義：

• 包是一個用來將模型單元分組的通用機制。

• 包可以含有類、接口、組件、用例等物件或其它的包。

包的作用：任何大系統都必須划分為較小的單元，以便人們在某一時刻可以和有限的信息工作，使團隊的工作不相互影響。

注釋

注釋的定義：

• 注釋用於解釋設計的思路，便於理解。
• 一個好的模型應該有詳盡的注釋。

關系 Relationships

關聯 Association

關聯的定義：

• Has a

• 關聯關系描述表示兩個類之間存在某種語義上的聯系。

• 關聯到類的連接點稱為關聯端點，很多信息被附在關聯端點上，它擁有角色名、重數（多少個類的實例可以關聯於另一個類的實例）等。

關聯的表示形式：

關聯之間的幾種表現形式：

連接：

• 最弱的關聯，只是表示兩個類對象之間有導航關系
• 雙向連接代碼表示形式
  
• 單向連接代碼表示形式
  

聚合 Aggregation：

• 具有 has a 語義，對象 A 是對象 B 的一個組成部分
  
• 代碼表示形式
  

組合 Composition：

• 強語義的聚合，整體對象消失，部分對象也消失
  
• 代碼表示形式
  

依賴 Dependency

• Use a

• 如果一個模型元素的變化會影響另一個模型元素，那么二者之間存在依賴關系。
  

泛化 Generalization

• Is a or is a kind of

• 泛化是一般化和具體化之間的一種關系。

• 繼承就是一種泛化關系，更一般化的描述稱為雙親，雙親的雙親稱為祖先，更具體化的描述稱為孩子。
  

實現 Realizations

• Like a

• 多數情況下，實現關系被用來規定接口和實現接口的類或組件之間的關系

公共機制 Common Divisions

規格說明 Specifications

• 模型元素的特征和語義的文本描述—模型的“肉”
• 形成了承載模型的語義背板（semantic backplane），賦予模型意義，各種圖僅僅是該背板的視圖或者可視化投影
• death by diagram —— 由於圖形而死亡

修飾 Adornments

• 圖中建模元素上暴露的信息項以表現某個要點

• 任何 UML 圖僅是模型的視圖，因此，只有在修飾增強了圖的整體清晰性和可讀性或者突出模型的某些重要特征時，你才應該表示那些修飾

公共分類 Common divisions

• 公共分類描述認識世界的特殊方法

  • 類元（Classifier）和實例

    • 類元：一類事物的抽象概念；如 bank account
    • 實例：一類事物的特定實例；如 my bank account

  • 接口（interface）和實現

    • 接口：說明事物行為的契約（做什么）
    • 實現：事物是如何工作的特殊細節（如何做）

拓展機制 Extensibility mechanisms

三部分組成：約束、構造型、標記值

約束（Constraints）：允許對模型元素添加新的規則

• 約束是用文字表達式表示的語義限制
• 約束用大括弧內的字符串表達式表示
  

構造型（stereotypes）：基於已有的建模元素引入新的建模元素；類中三種構造型：界面類、實體類、控制類

• UML 中元素具有通用的語義，用構造型可以對它們進行專有化和擴展

標記值（Tagged values）：允許為模型元素添加新的特性，是帶有相關值的關鍵字

• 標記值是一組字符串，存儲着有關元素的一些信息。

架構 Architecture

概述

構架是一個系統的組織結構，包括系統分解成的各個部分、它們的連接性、交互機制和通知系統設計的向導規則

4+1 視圖

用例視圖 Use Case View

• End-user: Functionality

• 這些視圖由用例視圖所統一，它描述項目干系人（stakeholder）的需求；所有其他視圖都是從用例視圖派生而來，該視圖把系統的基本需求捕獲為用例，並提供構造其他視圖的基礎

邏輯視圖 Logic View

• Analysts/Designers: Structure

• 系統功能和詞匯；描述問題域的詞匯，構造類和對象的集合。重點是展示對象和類是如何組成系統、實現所需系統行為的

進程視圖 Process View

• System integrators: Performance, Scalability, Throughput

• 系統性能、可伸縮性和吞吐量；將系統中的可執行線程和進程作為活動類來建模。其實，它是邏輯視圖面向進程的變體，包含與邏輯視圖相同的制品

實現視圖 Implementation View

• Programmers: Software Management

• 系統組裝和配置管理；對組成基於系統的物理代碼的文件和組件進行建模。它同樣展示出組件之間的依賴，展示一組組件的配置管理以定義系統的版本

部署視圖 Deployment View

• System engineering: System Topology, Delivery, Installation, Communication

• 系統的拓撲結構、分布、移交和安裝；建模把組件物理地部署到一組物理的、可計算節點上，如計算機和外設上。它允許建模橫跨分布式系統節點上的組件分布

用例圖 Use Case Diagrams

用例圖概念

• 用來顯示在系統（或其它實體）內的用例與系統參與者之間的關系。

• UML的用例圖由參與者、用例及它們之間的關系組成。

• 用例圖 = 參與者 + 用例 + 關系

• Use cases is a technique for capturing the functional requirements of a system.

• Use cases work by describing the typical interactions between the users of a system and the system itself, providing a narrative of how a system is used.

• 三個基本要素

  • Scenario（場景）：是用來描述用戶和系統之間交互的順序的步驟
    

  • Use case（用例）：是為了達到某一用戶目標而組合在一起的一組場景
    

  • Actor(參與者) ：參與者是用戶相對於系統所扮演的角色。

    • Actors carry out use cases.
    • A single actor may perform many use cases; conversely, a use case may have several actors performing it.

用例圖元語

借閱管理用例圖

類圖 Class Diagrams

類圖的概述

• 類圖是軟件的藍圖，詳細描述了系統內各個對象的類型，以及這些類之間的靜態關系

• 類圖是由類 (Classes)、類之間的關系 (Relationships) 和約束 (Constraints) 構成的。

• 類圖 = 類 + 關系 + 約束

類圖元語

類圖示例-POST系統

類圖的閱讀方法

1️⃣ 找出類
2️⃣ 找出方法
3️⃣ 理解多重性（多重性：用來說明關聯的兩個類之間的數量關系）
4️⃣ 理解方法

類圖的抽象層次

類圖的抽象層次共分為三種：概念層、邏輯層、實現層

• 概念層：類圖一般以抽象的方式描述從業務領域中抽取的業務對象之間的關系。

  • 抽象反映業務對象之間的關系
  • 不展開類中的內容
  • 對類用縮略表示或簡化表示
    

• 邏輯層：需要展開類圖中類的內容，但對類的內容不需要過於詳細，僅列出屬性名和操作名就可以。

  • 邏輯層是對概念層的深化
  • 展開類中的內容，但可以不包括細節
  • 對類用一般表示形式
    

• 實現層：需要展開類的所有內容，包括屬性名，類型，可見性，初始值等。實現層中的類應該能夠立即用於編程實現。

  • 實現層是對邏輯層的深化
  • 展開類中的內容，包括細節
  • 對類用一般表示形式
    

類圖的構建步驟

1️⃣ 研究分析問題領域，確定系統需求
2️⃣ 抽取類，明確類的含義和職責，確定類的屬性和操作
3️⃣ 確定類之間的關系。關聯，泛化，聚合，組合，依賴
4️⃣ 調整和細化類及其關系，解決重復和沖突
5️⃣ 繪制類圖，並增加相應說明

實戰

🌈 提取旅游賓館預訂的類圖

• 張博在大學期間為了鍛煉職業能力，和幾個要好的同學注冊了一個提供旅游服務預訂業務的公司，該公司負責為在校學生的暑假旅游提供服務

• 各旅游勝地的賓館向他們提供在暑假期間可以預訂的客房信息，包括客房的大小、設施、價格等。希望旅游的在校學生則通過這個公司提供的房間信息，進行客房預訂

• 學生在預訂客房時，需要提供自己的學號、姓名、性別、年齡、身份證號、所在學校等基本信息，並提供希望預訂的客房和時間，學生需要交納一定的預訂手續費和預訂押金

• 預訂之后，發生特殊情況，學生可以撤除預訂或更改預訂

1️⃣ 提取本問題的類

2️⃣ 確定各類的屬性

3️⃣ 確定類之間的關系

• “旅游地”和“賓館”的關系
  

• “客房”分析

• 客房應該有不同的類型
  

• 客房應該有不同的狀態
  

• 賓館記錄包含的客房
  

• 客房預訂分析

  • 通過 “訂單”描述客房的預訂信息，“訂單”應該有狀態，提取“訂單狀態”
    

  • 客房預訂涉及到“學生”，“訂單”，“賓館”和“客房”幾個類

  • 假設一個訂單可以預訂到多個客房。
    

4️⃣ 畫出完整類圖

對象圖 Object Diagrams

對象圖的概念

• 表示在某一時刻類的對象靜態結構和行為。

• 描述類圖在某一時刻，各個類中的對象相互之間的關系，相當於對類圖在某時刻的一個快照。

• 對象圖由對象和對象間的鏈組成

• 對象圖 = 對象 + 鏈

對象

• 對象（Object）是真實世界中的一個物理上或概念上具有自己狀態和行為的實體

• UML表示對象的方式

  • 在矩形框中放置對象的名字
  • 名字下加上下划線來表示這是一個對象

• 語法為：對象名: 類名

• 這種表達方法的每個部分都是可選的

Object name
object name: Class Name
:Class Name

鏈

• 有的時候僅表示對象本身並不重要，更多時候，我們需要表達對象之間在系統的某一個特定的運行時刻是如何在一起工作的，這就需要展示對象之間的關系

• 對象圖用鏈將這些對象捆綁在一切，UML將其稱為Links，即鏈

• UML 用實線表示鏈

對象圖和類圖的對比

對應着同一幅類圖，在不同時間繪制出來的對象圖是不一樣的

包圖 Package Diagrams

包圖的概念

• 包(Package): 是UML用來組織模型元素的模型元素。

• 包在UML中被視為文件夾。可以把包比作一個存放模型元素的箱子或容器，在它里面可以存放多個模型元素。

• 包中存放的模型元素可以是：類、接口、構件、用例、節點、活動、狀態、包和圖等。

包的表示

• 名稱：每個包都必須有一個與其它包相區別的名稱

順序圖 Sequence Diagrams

順序圖的概念

• 順序圖用於捕獲系統運行中對象之間有順序的交互，強調的是消息交互的時間順序

• 順序圖描述了對象實現全部或部分系統功能的行為模型

• 順序圖由參與者、生命線、活動條和消息組成

• 順序圖 = 交互的參與者 + 生命線 + 活動條 + 消息

生命線 Lifelines

• 每個參與者及系統運行中的對象都用一條垂直的生命線(Lifelines)表示

• 生命線展示了一個對象在交互過程中的生命期限，表示一個對象在系統表現一個功能時的存在時間長度

• UML 用矩形框和虛線表示生命線，矩形框中添加生命線的名稱，虛線展示了參與交互的對象的生命長度

• 生命線的描述標簽可以使用下面的語法：對象名: 類名

活動條 Activation Bar

• 活動條(Activation Bar)也稱為執行發生(Execution Occurrence)，它用來表示對象的某個行為所處的執行狀態

• 活動條用小矩形條表示

消息 Message

什么是消息

• 在面向對象的分析和設計中，對象的行為也稱為消息(Message)

• 通常，當一個對象調用另一個對象中的行為時，即完成了一次消息傳遞

• UML 用生命線間帶有實心箭頭的實線表示消息，每條消息從發送對象指向接收對象

消息的命名

• 每一個消息都必須命名

• 在表達消息的箭頭上，我們放置表示消息名稱的標簽，其語法如下：屬性 = 信號或消息名(參數: 參數類型) : 返回值

消息的例子	說明
get()	消息的名字是 get，其他信息未知
set(item)	消息的名字是 set，有一個參數為 item
d = get (id)	消息的名字是 get，有一個參數為 id，返回值存儲在屬性 d 中
d = get (id1:ItemID,id2:ItemID) ：Item	消息的名字是get，它有兩個參數，id1 和 id2，這兩個參數都是 ItemID 類型的，消息返回類 Item 的對象，該對象被存儲在消息調用方的屬性 d 中

簡單消息、同步消息和異步消息

• 簡單消息(Simple Message)：只表示控制如何從一個對象發給另一個對象，並不包含控制的細節

• 同步消息(Synchronous Message)：意味着阻塞和等待，如果對象 A 向對象 B 發送一個消息，對象 A 發出消息后必須等待消息返回，只有當對象 B 處理消息的操作執行完畢后, 對象 A 才可繼續執行自己的操作，這樣的消息稱為同步消息

• 異步消息(Asynchronous Message)：意味着非阻塞，如果對象 A 向對象B發送一個消息，對象 A 不必等待對象 B 執行完這個消息，就可以繼續執行自己的下一個行為，這樣的消息稱為異步消息

• UML 用實體箭頭表示同步消息，用開放式箭頭表示異步消息

對象創建消息

• 創建對象的消息被稱為對象創建消息(Object Creation Message)，表示對象在交互過程中被創建，通過構造型 <<create>> 來表示

對象銷毀消息

• 一個對象可以通過對象銷毀消息(Object Destruction Messages)銷毀另一個對象，它也可以銷毀它本身

• UML 將構造型 <<destroy>> 作為消息的標簽來表達對象銷毀消息，同時在對象生命線的結束部分畫一個 “×” 來表示該對象被銷毀

無觸發對象和無接受對象消息

• 無觸發對象消息稱為 found message， 用活動條開始端點上的實心球加箭頭來表示，它表示消息的發送者沒有被詳細指明，或者是一個未知的發送者，或者該消息來自於一個隨機的消息源

• 無接收對象消息稱為 lost message，用箭頭加實心球來表示，它描述消息的接收者沒有被詳細指明，或者是一個未知的接收者，或者該消息在某一時刻未被收到

自我調用消息

• 自我調用消息表示消息從一個對象發送到它本身，可以通過活動條的嵌套來表示自我調用消息(Call Self Message)
  

控制信息

• 有兩種情況可以應用控制信息(Control Information)表達：
  • 條件(Condition)：僅當條件為真的時候消息才被發送
    語法為：[表達式]消息標簽
  • 迭代(Iteration)：為了接收多次對象消息被發送多次
    語法為：*[表達式]消息標簽

消息的返回值

• 消息的返回值(Return Value)可以表示為：返回變量 = 消息(參數)

• 或者在活動條的結尾應用一個返回消息線

交互框

• 交互框(Interaction Frames)指圖中的一塊區域(Regions)或片斷(Fragments)

1️⃣ alt（選擇片段，在警戒中表達互斥的條件邏輯，與if else相似）

2️⃣ Loop（循環片段，條件為真的時候循環）

3️⃣ opt（可選片段，當警戒值為真時執行）

4️⃣ par（並行片段，表達並行執行）

實戰

還書用例

• 用例：還書
• 參與者：管理員,借閱者
• 操作流：
  ①管理員進入圖書借閱界面，用例開始。
  ②系統要求輸入所還圖書的條碼。
  ③系統顯示所還圖書的圖書、讀者、借閱等信息。
  ④確認還書。
  ⑤系統回到上一界面，等待處理下一業務。

通信圖 Communication Diagram

通信圖的概念

• 通信圖(Communication Diagram) 它與順序圖一樣，都是用來描述對象之間的相互作用的建模工具

• 通信圖強調的是對象之間在交互作用時的關聯

• 通信圖的消息發生順序用圖中的消息編號的方法來表示

• 在 UML1.x 中，通信圖被稱為協作圖(Collaboration Diagrams)

• 用例的每個事件流都可以用通信圖來描述。通信圖中可以有對象、參與者、它們之間鏈接和交互的消息

• 通信圖描述參與一個交互的對象的鏈接，它強調發送和接收消息的對象之間的鏈接

通信圖的表達方式

通信圖 = 交互的參與者 + 通信鏈 + 消息

交互的參與者

• 交互的參與者(Participants)用一個對象符號表示，在矩形框中放置交互的參與者，顯示交互的參與者的名稱和它所屬的類

• 在通信圖中表示對象的方法與在對象圖中表示對象的方法一致，其語法均為：參與者名：類名

鏈接

• 鏈接(Link)是兩個對象間的連接路徑，它表示兩個對象間的導航(Navigation)和可視性(Visibility)

• UML 用直線來表示鏈接

消息

自我委派消息

• 消息可能從一個對象發送到它自身，這樣的消息被稱為自我委派(self Delegation)消息
  

控制消息

• 控制消息(Control Message)表示當控制條件為真的時候消息才會被發送
  

嵌套消息和子消息

• 當一個消息導致了另一個消息被發送的時候，第二個消息被稱為嵌套在第一消息里，這樣的消息稱為嵌套消息(Nested Message)

• 通信圖用多級消息號的形式表示這種消息的嵌套

循環

• 在通信圖中，循環用 “*” 號來表示，循環子句被放在順序號的后面，表示循環將按照給定的循環子句重復

並發消息

• 有的時候，幾個消息需要同時被發送，這樣的消息稱為並發消息(Concurrent Message)
  

狀態圖 State Diagrams

狀態圖的概念

• 對象既有行為又有狀態，對象的行為由其狀態決定，對象根據其狀態的不同而產生不同的行為

• 狀態圖由狀態(State)和遷移(Transitions) 組成

• 表達方式為：狀態圖 = 狀態 + 遷移

狀態圖的表示方法

狀態

• 狀態是對象在它的生命周期中的某一時刻的，對象不僅在這一時刻具有某些特殊條件下產生的狀況值，而且具有該狀態決定的相應的動作或活動

• UML 用圓角矩形來表示狀態，其中包含可選的名稱

• 在定義狀態時，我們只關注與狀態值相關的對象屬性，基於狀態建模的目標是將該屬性所有可能發生的狀態和狀態之間轉換的鏈接組合在一起，以便展現對象在該屬性不同狀態下的行為全貌

狀態的種類

1️⃣ 簡單狀態(Simple State)

• 各種狀態中最簡單的狀態
• 其特點是它沒有子狀態，只帶有一組轉換和可能的入口和出口動作

2️⃣ 復合狀態(Composite State)

• 一個狀態是由一組或多組子狀態圖組成時，這個狀態稱為復合狀態
• 如果一個狀態有一組子狀態圖，則在該狀態圖內包含另一個狀態圖
• 如果一組狀態有多個子狀態圖，則用虛線將該狀態圖分開，在分開區域分別包含子狀態圖

3️⃣ 初始狀態(Initial State)

• 特殊狀態，表明狀態圖狀態的起點

4️⃣ 終止狀態(Final State)

• 特殊狀態，進入此狀態表明完成了狀態圖中狀態裝換歷程的所有活動

5️⃣ 結合狀態(Junction State)

• 將兩個轉換連接成一次就可以完成的轉換

6️⃣ 歷史狀態(History State)

• 保存組成狀態中先前被激活的狀態

如果沒有歷史狀態，邏輯處理會變復雜

狀態內部的活動

• 狀態的內部活動(Internal Activity)表示在特定狀態下對象可執行的功能

• 一個狀態可以有若干相關活動，這些活動可以是由狀態內部的事件觸發的內部活動，也可能是由遷移的開始或結束自動觸發的活動

• 無論是內部還是外部活動，只有當狀態處於激活時活動才被觸發

• 這些活動可以是操作、屬性或者任何觸發事件的參數，它可能是產生諸如發送信號或調用某個操作，包括給另一個對象發送消息、創建和銷毀對象等

• 應用標簽來表示狀態的內部活動，一個活動可以采用下面的形式描述，並放置在表示狀態的圓角矩形中：標簽/活動表達式

• UML提供了三種標簽來表示活動

  • entry：當進入一個狀態的時候被自動觸發，該活動在狀態中其他任何活動之前被自動觸發；
  • do：當狀態處於激活時執行 do 活動，do 活動在進入活動之后執行，並且一直運行到它本身完成
  • exit：當離開一個狀態的時候被自動觸發，該活動在該狀態結束之前，所有的其他活動都完成后被觸發。

遷移

• 遷移指從一個狀態到另一個狀態的瞬間變化過程

• 從源狀態到目標狀態一發生變化，就稱發生了遷移

• UML用從源狀態到目標狀態的帶開放式箭頭的實線表示遷移，箭頭指向目標狀態

引發遷移的事件

• 遷移的發生可能被來自對象內部或外部各種事件所引發

• 如果某一事件的發生引起了對象狀態的變化，即稱對象的狀態發生了遷移

• 這些可能引發遷移的事件可以進一步划分為：

  • 信號事件

    • 信號事件(Signal Event)指在實時(Real-time)系統運行中，對象接收到一個系統外界的信號，從而使對象的狀態發生遷移的事件

    • 例如，當我們打開燈的開關時，我們把系統外界壓力信號通過開關轉入系統，同時系統狀態發生由熄燈到亮燈的狀態遷移

  • 變化事件

    • 變化事件(Change Event)指對象的內部或外部條件發生變化而引起的對象狀態發生變化的事件

    • 例如，對象在實行某個行為時，當某個條件是 true 時，則必須改變其自身或所關聯對象的狀態，這個布爾條件就是變化條件

  • 調用事件

    • 調用事件(Call Event)是指系統之外的其它系統通過接口和某種協議，直接執行該系統內部的對象行為，從而引發對象狀態的遷移

    • 例如，我們可以用辦公室電腦遠程遙控家里的各種電器，使電器發生狀態遷移

  • 時間事件

    • 時間事件(Time Event)指對象的狀態在絕對時間上或某個時間段內自動發生遷移

    • 時間事件經常由系統外界設定的時間時刻或系統內部設定的時間段產生，其時間表的運行可能來源於操作系統，或者是系統應用中的自身運算

    • 例如，一個在校學生在校的有效學生身份狀態可能由於學校管理系統的日期變化而自動變成非學生狀態

遷移的文字標簽

• 為了使遷移線有明確的意義，UML提供了由三部分組成的文字標簽來解釋該遷移的發生事件

  • 觸發：trigger 表示觸發，指明何種條件可以導致遷移發生

  • 警戒條件：guard 表示警戒條件，指為了讓警戒發生而必須為真的布爾表達式

  • 行為：behavior 指為響應事件而執行的行為，遷移行為指當遷移發生時所執行一個不可中斷的活動(Activity)

• 文字標簽的語法可以表示為：觸發[警戒條件]/行為

🐍 分析動作執行順序

當前狀態是 Gathering input ，分析該狀態的動作執行序列。

submit input -> displayInput -> checkSpelling -> showGoodbye -> connectDB

案例分析

🌈 手機狀態圖

🌈 電梯狀態圖

🌈 復合狀態圖（順序子狀態）

🌈 復合狀態圖（並發子狀態）

總結

• 狀態圖更適用於描述一個橫跨多個用例的對象的行為，而不適於描述包括多個對象間協作的行為。

• 不要試圖為系統中的每個對象繪制狀態圖，只為一些具有復雜狀態的對象建立狀態圖就足夠了。

活動圖 Activity Diagrams

活動圖的概念

• UML 活動圖 (Activity Diagram) 是為基於活動的系統行為建模的有效工具。

• 活動圖是一種描述過程邏輯、業務流程和工作流程的技術。它本質上是一個流程圖，顯示從一個活動或動作到另一個活動或動作的控制流。

• UML 活動圖經常被用於描述復雜的企業流程、用例場景或為具體業務的邏輯建模

• 用例模型中的活動圖可以用來捕獲用例中執行的活動和動作。

• UML活動圖是由四種元素組成：

  • 活動
  • 動作
  • 活動邊
  • 活動節點

• 活動圖的表達方式為：活動圖 = 活動 + 動作 + 活動邊 + 活動節點

活動的表示方法

活動和動作

• 活動(Activity)是由一個或多個動作(Action)組成的行為

• 動作是活動中的一個基本執行單位，若干個動作按照一定的流程聯系起來就構成一個活動。活動可以分解為多個動作，但動作一般不再分解。

活動邊

• 在活動圖中，僅有動作是沒有意義的，因為活動圖是需要表現動作與動作之間、動作與數據之間、數據與動作之間的關聯和方向

• UML2.0 稱這些出現在活動中的信息之間的關聯為活動邊 (Activity Edges)

• UML2.0的活動邊為一條帶有開放式箭頭的實線，其箭頭指向下一個動作或下一個節點

• 活動邊所連的點(動作或節點)的不同，所形成的信息流也不同，在活動圖中，由活動邊關聯起來的信息流程可分為兩大類：

  • 控制流

    • 當活動邊連接的是兩個動作時，這種活動邊稱為控制流(Control Flow)

    • 控制流一般發生在於兩種情況：

      • 在活動邊控制下，活動由一個動作直接轉變為另一個動作時
      • 由一個動作經過一個邏輯判斷條件轉變為另一個動作時

    • 表示控制流的活動邊的箭頭指明下一個動作
      

  • 對象流

    • 當活動邊連接動作與數值或活動與數值時，UML2.0稱這類活動邊為對象流(Object Flow)
      對象流用於描述活動中的數據輸出輸入

    • 在對象流中，一般用對象的形式表示動作的輸入和輸出值，一個動作的輸出表示為一個對象作為一個另一個動作的輸入
      

活動節點

• 在活動圖中，流動中的信息不僅僅只有動作，還有許多其它的流動信息，UML2.0把除了動作外的其它活動信息稱為活動節點

• 活動節點主要分為三大類

  • 參數節點

    • UML2.0 用參數節點(Parameter Nodes)來表示一個參數進入一個活動或者一個參數從一個活動中輸出
    • 參數節點是出現在活動框上的長方形
    • 活動框上可以有一個或多個參數節點，它的一個邊通常與活動框內的某個動作相連以表示它是這個動作的輸入或輸出數據
    • 參數的輸入來源於活動之外，參數的輸出表示參數將輸出到活動之外
      

  • 對象節點

    • 當UML活動圖表達一個復雜的數據試圖通過一個活動時，這個穿越活動的數據包被稱為對象節點(Object Nodes)
    • 對象節點用於表示活動中移動的數據
    • 對象節點用矩形框表示，對象節點名可以加在矩形框內或外部，框內標明數據的名稱
      

  • 控制節點

    • 控制節點 (Control Nodes) 是用於表示活動中的控制判斷、同步運算、路徑分叉、路徑合並等特殊節點

    • 控制節點主要包括：

      • 起始節點(Initial Nodes)：表示活動的開始節點
        

      • 判斷（分支）節點(Decision Nodes/Branch Nodes)：判斷節點是通過布爾值的選擇給出不同的輸出流的控制節點
        一個分支有一個入轉換和兩個或多個帶監護條件的出轉換，出轉換的監護條件應當是互斥的，這樣可以保證只有一條出轉換能夠被觸發。

      

      • 合並節點(Merge Nodes)：與判斷節點相反，匯合節點具有多個輸入邊和一個輸出邊，它的兩個輸入邊並不需要並行到達匯合節點，也就是說無論哪個邊先到達匯合節點，都要進入唯一的輸出邊
        

      • 分叉節點(Fork Nodes)：分叉節點是一個動作在該點同時並行產生多個並發活動邊
        

      • 匯合節點(Join Nodes)：結合節點是指多個並發活動邊在該點應產生各自的返回值，當所有返回值均正確產生后，傳遞給該節點的唯一輸出邊
        

      • 終點節點(Final Nodes)

        • 用於終止活動圖的一個路徑而不是整個活動的流終點節點，用圓形加 X 表示；
        • 用於結束整個活動的活動終點節點，用加圈的實心圓表示
          

活動划分或泳道

• 為了表明活動圖中各種元素的歸屬，UML用垂直線將不同歸屬的元素分開，將它稱為活動划分(Activity Partitions)，由於這種划分的外觀很像泳道，所以也稱為活動圖中的泳道(Swimming Lines)。

• 活動划分將一個活動圖中的活動元素分組，每一組的上方表明該組元素所屬對象，這樣很容易通過划分看到活動的參與者

案例分析

🌈 新增讀者

"新增讀者"用例屬於讀者信息管理中的一個功能，主要用於在系統中增加新的讀者信息，其具體的辦理流程是：
1️⃣ "讀者"填寫申請表，並交給"圖書管理員"；
2️⃣ "圖書管理員"將申請表中的信息通過錄入界面，輸入到圖書管理系統；
3️⃣ 系統中的"業務邏輯"組件將判斷輸入的信息是否合法；
4️⃣ 如果不合法則轉入步驟（5），否則轉入步驟（6）;
5️⃣ 顯示"添加錯誤信息"，轉到（8）；
6️⃣ 在“數據庫”添加相信的用戶信息；
7️⃣ 顯示"添加成功信息"；
8️⃣ 結束。

組件圖 Component Diagrams

組件和組件圖

組件

• 在 UML2.0 中，組件被認為是在一個系統或子系統中的獨立的封裝單位，組件通過一系列的接口對外界提供功能。（系統>組件>類）

組件圖

• 組件圖(Component Diagram)為系統中的組件建模，它展示了組件間相互依賴的網絡結構

組件圖的表達方式

• 組件圖由組件、接口、關系、端口和連接器組成，它的表達方式為：組件圖 = 組件 + 接口 + 關系 + 端口+ 連接器

組件圖的表示方法

組件

供接口和需接口

• 組件中有非常多的功能，假如有一個類使要用組件中的某個類的具體的某個方法，但當組件中這個具體的方法發生變化時(比如方法名字的變化或方法內容的變化)，那么該類就不能應用組件中的相應內容了

• 應用接口，可以隱藏具體的實現細節，這樣，組件中的內容可以任意變化，而接口卻是相對固定的

• 組件向外部展現兩種接口：

  • 供接口：供接口用棒棒糖式的圖形表示，由一個封閉的圓形與一條直線組成

  • 需接口：需接口用插座式的圖形表示，由一個半圓與一條直線組成
    

組件間的關系

• 如果一個組件有一個需接口，則表示它需要另一個組件或者類來為它提供服務

• 為了表達組件與其他組件間的關系，供接口與需接口之間用一個表示依賴的箭頭(即虛線加一個開箭頭)連接起來，該箭頭從需接口引出，指向服務供應者提供的供接口
  

• 用一個裝配連接器(Assembly Connectors)來表示組件之間的關系
  

• 更簡單的，你可以忽略組件間的供接口和需接口，而直接在組件間畫上依賴關系
  

實現組件的類

• 組件需要包含和使用一些類來實施它的功能，這些類實現了這個組件

• 可以在組件中畫出這些類和類間的關系
  

顯示組件的內部結構

• 一個組件的內部可能包括多個其他的組件，這樣的組件稱為復合組件(Compound Component)，復合組件中的組件稱為子組件(Subcomponent)
  

部署圖 Deployment Diagrams

部署圖的概念

• 當軟件處於物理部署階段時，我們關注的是軟件程序在計算機硬件系統中的物理分布、通信方式和部署方法

• UML 的部署圖(Deployment Diagram)用來解決這類建模問題

• 一個 UML 部署圖描述了系統的軟件如何映射到將要執行它們的硬件上，用來顯示系統中軟件和硬件的物理架構，是一個運行時的硬件節點以及在這些節點上運行的軟件的靜態結構模型

• 這些軟件(可能是一些構件或類等)通常被稱為制品(Artifacts)，被部署到的硬件或者軟件環境被稱為節點(Nodes)，節點間的通信被建模為通信路徑(Communication Paths)

• 部署圖的表達方式為：部署圖 = 制品 + 節點 + 通信路徑

部署圖的表示方法

制品

• 制品可以是一個模型、描述或軟件,它通常以文件的形式存在，可以是可執行的，比如 .exe 文件、二進制文件、DDLs 或者 JAR 文件等，或者是一個數據文件、一個配置文件、一個用戶手冊或者一個HTML文檔

• 在 UML 中，制品用右上角帶一個狗耳朵標記的矩形框表示
  

• 可以在矩形框中標明制品的名字
  

節點

• 節點(Nodes)是一個能夠執行制品的實體，可以是硬件，但有時也可以是為其他軟件的執行提供執行環境的軟件

• 有兩種類型的節點

  • 執行環境(Execution Environments)節點
  • 設備(Device)節點

• UML2.0用一個3D風格的盒子表示節點，在節點的內部注明節點名
  

• 在部署圖內部用構造型 <<ExecutionEnvironment>> 和所選用的執行環境名稱來表示執行環境節點，執行環境通常是中間件或操作系統
  

• 設備節點用於表示具體的計算設備，一般是一個單獨的硬件設備
  

部署

• 部署圖最重要的部分就是將制品部署在將執行它的節點上

• UML2.0 提供了三種方法來表示把制品部署到節點中

1️⃣ 通過將制品繪制在節點中實現對制品的部署

2️⃣ 可以用帶構造型 <<deploy>> 標簽的虛線箭頭表示將制品部署在節點中，注意，箭頭指向節點

3️⃣ 更簡單的，可以將制品直接記錄在節點中表示部署關系

通信路徑

• 通信路徑表示節點間的通信，用實心線表示
  

• 通信路徑支持一個或多個通信協議，比如JDBC，ODBC，RMI等，通信協議可以用加在通信路徑上的構造型表示

Use-Case Modeling

前言

局限性

• 用UML畫圖很容易，但知道要畫什么是困難的！
• UML僅僅是一種表達形式

畫圖的三個步驟

• 認識問題：以用戶的身份站在用戶的角度認識問題
• 分析問題：以開發者的身份站在用戶的角度分析問題
• 解決問題：以開發者的身份站在開發團隊的角度分析問題

需求

• 需求：系統必須滿足的條件或具備的能力

• 理解需求的目的：建造”正確”的系統

Robert Grady軟件質量准則“FURPS”

• 功能性（Functionality）
• 使用性（Usability）
• 可靠性（Reliability）
• 性能（Performance）
• 可支持性（Supportability）

需求收集包括五個關鍵步驟

• 找到可以幫助你理解這個系統的人
• 傾聽這些相關人員的描述，並從他們的角度來理解系統
• 利用一個容易理解的模型來描述用戶希望如何使用這個系統以及為他們提供的什么價值
• 詳細地描述系統和客戶以及系統和外部系統之間的交互
• 重構（refactor）這個詳細描述以保證它是可讀且易懂的

基於用例的需求分析過程

獲取原始需求

開發一個可以理解的需求

識別參與者

• 參與者，Actor

  • 關鍵詞：邊界
  • 參與者：在系統之外，透過系統邊界與系統進行有意義交互的任何事物

• 系統外

  • 參與者代表在系統邊界之外的真實事物，並不是系統的成分

• 系統邊界

  • 參與者透過系統邊界直接與系統交互，參與者的確定代表系統邊界的確定

• 有意義的交互

• 任何事物

  • 人、外系統、外部因素、時間

• 實現參與者的思路

  • 誰使用系統的主要功能
  • 誰改變系統的數據
  • 誰從系統獲取信息
  • 誰需要系統的支持以完成日常工作任務
  • 誰負責日常維護、管理並保證系統正常運行
  • 系統需要應付（處理）那些硬設備
  • 系統需要和那些外部系統交互
  • 誰（或什么）對系統運行產生的結果（值）感興趣
  • 時間、氣溫等內部外部條件

• 參與者的命名

  • 不好的：用職務名稱和個人姓名來命名
    • 例如，張三、老李、校長、科長…
    • 若使用系統的人（職務名稱）變化的話，就不是參與者了
  • 好的參與者命名的例子：用能知道其角色的名稱來命名
    • 例如，學生、訂單管理員、維護部門…
    • 即使使用系統的人改變，從系統來看，使用者的角色（作用）是相同的。

• 參與者的泛化：責任重疊
  • Generalization – A generalization from an actor A to an actor B indicates that an instance of A can communicate with the same kinds of use-case instances as an instance of B
  • 如系統中經理可以參加雇員的所有用例
    

識別用例

• 用例的定義
  • 用例實例是系統執行的一系列動作，這些動作將生成特定參與者可觀測的結果值
  • 一個用例定義一組用例實例
  • 參與者使用系統達到目標

• 要點

  • 用例止於系統邊界
    
  • 有意義的目標
    
  • 結果值由系統生成
    
  • 業務語言而非技術語言：如：發票，商品，洗衣機，而不是：記錄，字段，COM，C++等
  • 用戶觀點而非系統觀點
    

• 用例的命名

  • 執行者視角：（狀語）動詞+（定語+ ）賓語
    

• 用戶粒度不宜過細

  • 常見錯誤：
  • 把步驟當用例
    
  • 把系統活動當用例
    
  • CRUD掩蓋業務，銳變成關系數據庫的建模
    
  • 如果確實是CRUD？ 如果CRUD不涉及復雜的交互，一個用例“管理××”即可
    

• 識別電梯系統的用例
  

構建用例圖

• 用例圖構建過程示例

  • 識別參與者
  • 候選參與者
  • 識別用例

• 用例圖構建過程示例：POST系統

  • 識別參與者
    
    

  • 候選參與者
    

  • 獲取用例
    

  • 識別用例
    

詳細、完整地描述需求

進行用例闡述

用例圖是骨架，而用例規約則是其內在的肉

用例規約的組成

• 用例名稱

• 用例標識

• 涉及的參與者

• 描述

• 用例的規格說明

  • 前置條件 PreConditions：前置條件約束在用例開始前系統的狀態
    • 把它們看做是看門人，它阻止參與者觸發該用例直到滿足所有條件
    • 說明在用例觸發之前什么必須為真
      
  • 后置條件 PostConditions：后置條件約束用例執行后系統的狀態
    • 用例執行后什么必須為真
    • 對於有多個事件流的用例，則應該有多個后置條件
  • 正常事件流 Flow of events
    • 用例的主路徑、愉快路徑（Happy Path）
    • 通常用來描述一個理想世界，即沒有任何錯誤發生的情況
    • 復雜的基本流可以分解成多個子流
  • 備選事件流 Alternate flow
    • 基本事件流中的分支或異常情況
    • 注意如何與基本流銜接

• 其它

  • 非功能需求、設計約束、尚存在的問題

• 事件流描述要點

  • 使用業務語言：使用用戶平時所使用的語言進行描述
  • 重點描述參與者與系統交互的信息
  • 不使用“例如”、“等”不清晰的表達
  • 不要過多的考慮界面細節
  • 不要描述系統內部處理細節，要描述從系統外部所看到的活動
  • 要明確描述用例的開始和結束
  • 不僅需要描述基本事件流，還需要考慮備選事件流

重構用力模型

識別用例間的關系

• Include(包含)

  • 基用例中復用被包含用例的行為
  • 提取公共步驟，便於復用
  • 包含：表示某個用例中包含了其他用例的行為
    從兩個或多個用例行為中提取公共部分的能力，主要用於支持用例行為的復用
    

• Extend(擴展)

  • 通過擴展用例對基用例增加附加的行為
  • 擴展：某個用例在特定情況下，包含其他用例(擴展用例)的行為，表示功能被擴展
    為了將基用例的一些特殊情況分離出來，在保持基用例本身相對完整的情況下處理這些特殊行為
    即不改變基用例，對基用例的行為進行擴展
    

• Generalization(泛化)

  • 派生用例繼承泛化用例的行為並添加新行為
  • 泛化：表示子用例繼承了父用例
    用例間的泛化關系表明子用例繼承父用例中定義的所有屬性、行為序列和擴展點，並且參與父用例中所有的關系
    

對用例進行組織和分包

• 用例和開發周期

  • 開發周期是圍繞用例的需求來組織的
  • 一個開發周期要被指派一個到多個用例，如果完全版本的用例在一個開發周期中處理起來太復雜的話，那就采用簡化版本的用例
    

• 用例分類原則

  • 用例分類的一個基本原則
    • 高級別的用例是那些對系統核心體系結構影響最大的用例
  • 提高用例級別的特性：
    • a. 對體系結構設計有重要影響的用例，如在領域層中增加多個類的用例或者需要持久化的用例
    • b. 不需要花費很多努力就可以從中獲得重要信息和線索的那些用例
    • c. 含有開發風險、時間緊迫或功能復雜的用例
    • d. 涉及到重要技術研究或者新技術和高風險的用例
    • e. 代表主要的在線業務流程的用例
    • f. 能產生直接經濟效益或者降低成本的用例

• 對用例進行分包

  • 讓用例圖能夠更為清晰地表現出系統的業務邏輯關系和層次
  • 對系統進行模塊的分割，這將影響到今后的開發和系統的最終表現形式

• 常見的分包方式

  • 按參與者分包
  • 按主題分包
  • 按開發團隊分包
  • 按發布情況分包

• 適用用例建模的情況

  • 系統由功能需求所主導
  • 系統具有很多類型的用戶，系統對他們提供不同的功能
  • 系統具有很多接口

• 不適用用例建模的情況

  • 系統有非功能需求所主導（如：google）
  • 系統具有很少的用戶
  • 系統具有很少的接口（非內部功能）

用例分析示例

圖書館的圖書借閱

用例分析：
1️⃣ 確定圖書管理的參與者；
2️⃣ 確定參與者所看到的圖書管理功能；
3️⃣ 把這些功能分解為用例；
4️⃣ 確定用例之間的關系；
5️⃣ 畫用例圖；
6️⃣ 描述事件流。

• 找出系統外部參與者，確定系統邊界和范圍。
  

• 確定各參與者所期望的系統行為。

管理員：
1️⃣ 借書證管理: 辦證，補證，注銷，證件查詢
2️⃣ 圖書管理: 查詢，添加，修改，刪除
3️⃣ 借閱管理:書目查詢，借書，還書，過期催還，丟失處理
借閱者：
1️⃣ 書目查詢

• 把這些系統行為命名為用例
  

• 確定各用例之間的關系(泛化，包含，擴展)
  

• 繪制用例圖
  

• 編制用例敘述
  

用例分析（Use Case Analysis）

理解分析

• 分析
  • 為了滿足需求模型中所描述的功能，系統內部應該有什么樣的業務核心機制(做什么？)
• 分析的目標開發一系列模型，以描述軟件核心成分，從而滿足客戶定義的需求：分析模型
  • 包括兩個層次：架構分析和用例分析
  • 包括兩類模型：靜態結構(包圖、類圖)和動態交互(順序圖)
  • 各類視圖按照用例實現(協作)來組織

從用例開始分析

用例實現(UML2協作，Collaboration)是設計(分析)模型中系統用例的表達式

• 使用構造型 <<use-case realization>>，EA中直接使用協作（Collaboration）來表示
• 描述了對象間的協作以完成用例目標
• 將用例模型中的用例和設計(分析)模型中的類和關系連接在一起
• 說明了每個用例必須用哪些類來實現
  用例實現提供了從分析和設計到需求的可跟蹤性

用例實現是設計模型中的元素，說明了一個用例是如何實現其行為的。
在用例實現中包含：

• 靜態類圖：刻畫參與一個用例的一組對象所屬的類及類間的關系。
• 動態交互圖：刻畫參與一個用例的一組對象之間的動態交互關系，具體可以是順序圖、協作圖。
  用例實現對應於設計模型下的元素，是對用例的實現，二者之間是實現關系，建立了設計模型到用例模型之間的追溯關系。

架構模式

架構模式表示了軟件系統的一個基礎結構組織形式。它提供了一套預定義子系統，詳細說明它們的職責，並且包括組織它們之間的規則和指南

• 層
• 模型-視圖-控制器(M-V-C)
• 管道和過濾器
• 黑板

以構造型 <<layer>> 表示系統不同層次
以 B-C-E 三層划分系統三類處理邏輯

• 邊界層(Boundary)負責系統與參與者之間的交互
  • 邊界類表示系統與參與者之間的邊界
    • 代表系統與環境的交互
    • 是接口和外部事物的中間體
    • 構造型 <<boundary>>
  • 兩類邊界類
    • 用戶界面類
    • 系統和設備接口類
  • 每對參與者/用例定義一個邊界類

• 控制層(Control)處理系統的控制邏輯

• 實體層(Entity)管理系統使用的信息
  層之間建立依賴關系

構造用例實現

構造用例實現是分析最核心的工作

• 獲得實現用例行為所必須的分析類
• 利用這些分析類來描述其實現邏輯

針對每一個用例：

• 完善用例文檔
• 識別分析類
  • 邊界類、控制類和實體類
• 分析交互
  • 將用例行為分配給類
• 完成參與類類圖
  • 參與用例實現的類的類圖

1. 完善用例文檔

• 需求階段的用例文檔是從用戶角度看待用戶問題，側重描述交互的1、4步
• 分析階段則需要從系統角度看待用戶問題，重點關注交互的2、3步：即系統如何響應用戶請求；此時可以對需求階段用例文檔中系統的處理流程進一步細化

2. 從用例行為中識別分析類

• 在對象技術中，一個用例的全部行為都是由相應的類來完成的

• 這些行為必須被分配到類中

  • 分析階段就是對這個過程的第一次嘗試
  • 這是一個從“無”到“有”的跨越

• 分析類代表了“系統中必須具備職責和行為的事物”的早期概念模型

• 分析類處理主要的功能需求

• 根據備選架構定義三類分析類

  • 邊界類：系統及其參與者的邊界
  • 控制類：系統的控制邏輯
  • 實體類：系統使用的信息

3. 將用例行為分配給類

• 面向對象系統是通過對象間的協作實現需求的

  • 需求階段通過自然語言描述
  • 分析設計階段采用圖形化方式描述協作過程
  • 利用交互圖將用例行為分配給分析類

• 以B-C-E的方式繪制順序圖，並以Control類將控制邏輯隱藏起來

• 可以將對象之間的信息傳遞以“//”的方式標記，表明初步進行類的職責分配，該項信息尚未制定完全

• 可以利用白話的方式將信息進行的說明，在信息長度不夠時，可以加上UML的注釋來做說明

• 分析階段順序圖中所找出的對象可以放置到分析階段的類圖上，反之，也可以由分析階段的類圖上找出順序圖中所需的對象

• 以分析類的構造型作為分配標准

  • 邊界類：承擔與參與者進行通信的職責
  • 控制類：承擔協調用例參與者與數據操作之間交互的職責
  • 實體類：承擔對被封裝的內部數據進行操作的職責

4. VOPC圖

• 對於每個“用例實現”都存在若干張交互圖進行描述，而這些交互圖中會使用到各種分析類的對象
• 對於每一個“用例實現”，需要繪制與之相關的類圖，即VOPC圖
  • 參與類類圖(VOPC, View Of Participating Classes Class Diagram)
  • 類圖中的元素來自於交互圖中的對象
  • 類圖中的關系來自於交互圖中的消息(和業務對象模型)，分析階段主要使用關聯關系，也可根據業務模型引入泛化、聚合等關系

定義分析類

從單個分析類入手，完成如下工作：

1. 定義職責
2. 定義屬性
3. 定義關系
   3.1 關聯關系
   3.2 聚合關系
   3.3 泛化關系
4. 限定分析機制
5. 統一分析類

作業題

類圖對象圖

一.單選題（共5題,38.0分）

1. UML類圖中,若類A僅在其方法Method1中定義並使用了類B的一個對象,類A其他部分的代碼都不涉及類B,那么類A和類B的關系應為()關系。
   A、 依賴
   B、 關聯
   C、 聚合
   D、 組合

正確答案：A

2. UML類圖中,若類A中包含了其他類的實例,且當類A的實例消失時,其包含的其它類的實例也消失,則類A和它所包含的類之間存在()關系。
   A、 依賴
   B、 關聯
   C、 聚合
   D、 組合

正確答案：D

3. UML類圖中, 類A中包含了其他類的實例, 若類A的實例消失時,其它類的實例仍然存在並繼續工作,那么類A和它所包含的類之間存在( )關系。
   A、依賴
   B、關聯
   C、聚合
   D、組合

正確答案：C

4. 采用UML進行軟件建模過程中,類圖是系統的一種靜態視圖,用()可明確表示兩類事物之間存在的整體/部分形式的關聯關系。
   A、 依賴關系
   B、 聚合關系
   C、 泛化關系
   D、 實現關系

正確答案：B

5. 下列對對象圖描述錯誤的是。
   A、對象圖中兩個對象之間的連線是類圖中兩個類的關聯實例。
   B、對象圖中創建對象時，不允許缺少類名。
   C、如果類A與類B之間存在一對多的關聯關系，那么在對象圖中，一個A對象x可能與五個B對象連接，在另外的場景中，一個A對象y則可能只與一個B對象連接。
   D、the instances of things contained in class diagrams. an object diagram is often called an instance diagram

正確答案：B

1(單選題) 采用UML進行軟件建模過程中,類圖是系統的一種靜態視圖,用()可明確表示兩類事物之間存在的整體/部分形式的關聯關系。

A. 依賴關系

B. 聚合關系

C. 泛化關系

D. 實現關系

正確答案: B

5(單選題) UML中關聯的多重性是指( )。

A. 一個類有多個方法被另一個類調用

B. 一個類的實例能夠與另一個類的多個實例相關聯

C. 一個類的某個方法被另一個類調用的次數

D. 兩個類所具有的相同的方法和屬性

正確答案: B

6(單選題) A class . . . ?

A. Is an encapsulation of an object.

B. Represents the hierarchy of an object.

C. Is an instance of an object.

D. Is an abstract definition of an object.

正確答案: D

7(單選題) A subclass inherits its parent’s ...?

A. attributes

B. operations

C. relationships

D. All of above

正確答案: D

8(單選題) 在類A的定義中出現形如：void setColor(Color temp){...}的操作定義。易見Color是一個類，那么它與類A一定存在()關系。

A. 沒關系

B. 泛化關系

C. 依賴關系

D. 關聯關系

正確答案: C

9(單選題) 下圖中，xyz分別表示關系

A. Dependencies, Generalizations, Associations

B. Dependencies, Associations, Generalizations

C. Associations, Dependencies,Generalizations

D. Associations,Generalizations, Dependencies

正確答案: A

10(單選題) Uml的類元素中，可視化符號" # "表示

A. public

B. protected

C. private

D. package

正確答案: B

二.判斷題（共5題,38.0分）

1. 對象圖展示了所建模的系統在某個特定時間點的一個完整的或部分的結構視圖,這個快照關注類的實例、實例的屬性以及實例間的鏈接。

正確答案： √

2. 對象圖中對象之間連接個數取決於類圖中類的關聯關系的定義。

正確答案： √

3. 在一個對象圖中，一個類至多只能顯示一個對象。

正確答案： ×

4. An object diagram is a snapshot of the objects in a system at a point in time

正確答案： √

10. An object diagram is a structural diagram that shows a set of objects and their relationships.

正確答案： √

三.簡答題（共3題,24.0分）

1. 簡述類之間存在幾種關系？給出uml符號表示，並簡要解釋它們的含義。

正確答案：關聯關系，泛化關系，依賴關系。

類圖之間：關聯關系，泛化關系，依賴關系，實現關系

2. 簡述類圖中 Aggregation 和 Composition 的區別。

正確答案：Aggregation 的整體類和部分類無相同生命周期；Composition 的整體類和部分類有相同生命周期。畫圖方式不同。

3. 閱讀下列說明和圖，回答問題1至問題4，將解答填入答題紙的對應欄內。

   ​ 【說明】
   已知某唱片播放器不僅可以播放唱片，而且可以連接電腦並把電腦中的歌曲刻錄到唱片上（同步歌曲）。連接電腦的過程中還可自動完成充電。
   關於唱片，還有以下描述信息：

   1. 每首歌曲的描述信息包括：歌曲的名字、譜寫這首歌曲的藝術家以及演奏這首歌曲的藝術家。只有兩首歌曲的這三部分信息完全相同時，才認為它們是同一首歌曲。藝術家可能是一名歌手或一支由2名或2名以上的歌手所組成的樂隊。一名歌手可以不屬於任何樂隊，也可以屬於一個或多個樂隊。

   2. 每張唱片由多條音軌構成；一條音軌中只包含一首歌曲或為空，一首歌曲可分布在多條音軌上；同一首歌曲在一張唱片中最多只能出現一次。

   3. 每條音軌都有一個開始位置和持續時間。一張唱片上音軌的次序是非常重要的，因此對於任意一條音軌，播放器需要准確地知道，它的下一條音軌和上一條音軌是什么（如果存在的話）。
      根據上述描述，采用面向對象方法對其進行分析與設計，得到了如表1-1所示的類列表、如圖1-1所示的初始類圖

【問題1】
根據說明中的描述，使用表1-1給出的類的名稱，給出圖1-1中的A~F所對應的類。

【問題2】
根據說明中的描述，給出圖1-1中（1）~（6）處的多重度。

【問題1】
根據說明中的描述，使用表1-1給出的類的名稱，給出圖1-1中的A~F所對應的類。
A: Artist
B: Song
C: Band
D: Musician
E: Track
F: Album

【問題2】
根據說明中的描述，給出圖1-1中（1）~（6）處的多重度。
(1) 0..*
(2) 2..*
(3) 0..1
(4) 1..*
(5) 1..*
(6) 1

用例圖

正確作業：

A1: Customer A2: Bank U1: Session U2: Invalid PIN Process U3: Transaction (1): 《extend》

正確答案：

A1 User， A2 Author， A3 Reviewer， A4 PCChair

U1 list accepted / rejected papers

U2 browse submitted papers

U3 assign paper to reviewer

U2和U3的答案可以互換

（1）<<extend>>：將常規動作放在一個基本Use Case中，將非常規動作放在其擴展Use Case中（不一定發生）。

（2）<<include>>：兩個Use Case，如果其中一個在其事件流中包含了另一個，那么它們間就有包含關系（一個發生，被包含事件一定發生）。

1(判斷題) 用例（use case）是一種有效捕獲系統功能性需求的方法，它從參與者（Actor）角度刻畫了參與者期望系統為其提供的功能或服務。

正確答案: 對

2(判斷題) 場景（scenario）描述了用戶與系統的一次特定的交互過程，相當於用例的實例，即用例是對同一功能的各種可能場景的抽象和概括。

正確答案: 對

3(判斷題) 用例定義了參與者與系統之間的一組動作序列，通過執行這組動作序列，系統能夠向參與者返回能夠觀察到的有價值的結果。

正確答案: 對

4(判斷題) 用例規格說明中的事件流包括主要事件流（Main flow），即用例正常執行的動作步驟，也可以包括備選事件流（alternative flows），即在用例執行過程中可能出現的一些其他情況，比如執行出錯、取消執行、在多種選項中選擇等。

正確答案: 對

1.[單選題]下面不是用例之間主要關系的是()
A. 擴展
B. 包含
C. 關聯
D. 泛化

正確答案：C

2.[單選題]下面關於參與者(Actor)的描述中，錯誤的是()
A. 是系統范圍之外的，與系統進行交互的元素
B. 參與者對應的是一種角色，而不是具體的對象;同一對象可以在系統中作為不同的參與者存在入
C. 參與者可以是人、系統、軟硬件設備，甚至是時間等能啟動系統功能或是系統與之交互的任何元素
D. 我們在需求階段從參與者角度認識系統需求，然后在后續過程中也要將參與者作為系統的一部分加以實現。

正確答案：D

3.[判斷題]用例定義了參與者與系統之間的一組動作序列，通過執行這組動作序列，系統能夠向參與者返回能夠觀察到的有價值的結架。

1. 對
2. 錯

正確答案：對

4.[多選題]用例的規格說明(specification）是對用例的詳細說明，其中包含的內容包括(
A. 用例的主要參與者、次要參與者（如果有的話)
B. 前置條件，即用例開始啟動時系統需要滿足的條件
C. 事件流，這是用例規格說明中最重要的部分，其中包含了用例執行過程中參與者和系統之間交互的動作步驟
D. 后置條件，即用例執行完成系統必須滿足的條件

正確答案：ABCD

5.[單選題]用例和參與者之間的關系是（()
A. 泛化
B. 包含
C. 擴展
D. 關聯

正確答案：D

6.[單選題]用例A代表驗證用戶簽到功能，用例B代表用人臉識別進行簽到的功能，則二者之間存在()關系
A. 泛化
B. 包含
C. 擴展
D. 關聯

正確答案：A

7.[單選題]用例A瀏覽圖書信息、B修改圖書信息和C刪除圖書信息中都有查找圖書的相關步驟，可以把這些共同的步驟抽取出來作為一個新用例D查找圖書，則A、B、C和D之間存在()關系。
A. 泛化
B. 包含
C. 擴展
D. 關聯

正確答案：B

8.[單選題]圖書館系統中歸還圖書用例可以用來表示讀者還書的功能，如果在還書時發現該讀者延期歸還，則需要執行繳納罰金相關操作，那么在用例還書和繳納罰金之間存在()關系。
A. 泛化
B. 包含
C. 擴展
D. 關聯

正確答案：C

9.[多選題]以下關於用例包含和擴展關系的描述中正確的是（
A. 如果用例A包含用例B，則表示用例A本身是不完整的，每次用例A的執行都必須執行用例B中的動作序列，即用例A主動包含用例B，A知道B。
B. 如果用例B擴展用例A，則表示用例A本身是完整的，可以在不執行用例B中動作序列的情況下完成自身功能，只有當特定條件滿足時，用例B中的動作序列才會執行。即用例A不知道B的存在，用例B主動去擴展A。
C. 包含關系常用於在多個用例中都包含一些相同的動作步驟，而這些動作步驟又可以看作是一個相對獨立的用例，這時可以將這些共同的動作步驟定義為一個新的用例，被其他用例所包含。
D. 擴展關系常用於先定義一個基本功能用例，然后在需要對其增加擴展處理能力時定義新的擴展用例，去擴展原來的基本功能用例。

正確答案：ABCD

活動圖

正確答案：
(1)
enter title and abstract
(2)
select subject group
(3)
select paper location
(4)
upload paper

交互圖

1. (單選題, 20分)UML中有多種類型的圖,( )與通信圖類似,但強調的是順序而不是連接。
   A. 用例圖
   B. 順序圖
   C. 類圖
   D. 活動圖

正確答案: B

2. (判斷題, 10分)用UML的順序圖表達對象的交互時,只可以表示同步消息,但不可以表示異步消息;可以表示消息發送的先后次序,但不可以表示消息的循環發送。
   A. 對
   B. 錯

正確答案: 錯

3. (判斷題, 10分)組合片段(Combine Fragment)可以代表一組對象交互行為,它是順序圖中的一個嵌套區域,它可以用來定義交互中的條件結構和循環結構。
   A. 對
   B. 錯

正確答案: 對

4. (判斷題, 10分)順序圖和協作圖(UML2.0中的通信圖)在語義上是等價的,順序圖用鏈接(link)刻畫對象間的拓撲關系,通信圖則可以描述執行的發生(execution occurrence)或控制焦點(focus of control)。
   A. 對
   B. 錯

正確答案: 錯

5. (判斷題, 10分)通信圖(UML1.x中的協作圖)主要描述對象間的交互與連接,它既能表示消息的順序關系,也能表示消息的嵌套消息。
   A. 對
   B. 錯

正確答案: 對

2(單選題) The interactions can be found in the context of ()

A. the system or subsystem

B. an operation

C. a class

D. 上述所有

正確答案: D

3(單選題) 交互圖中的對象可能代表的是一個

A. 子系統

B. 構件

C. 類的對象

D. 以上全部

正確答案: D

4(單選題) 下圖是一個順序圖，其中(1)是指包含anOrder：Order對象的矩形框和虛線，它表示這個對象的()

A. 消息

B. 生命線

C. 活動條

D. 交互框

正確答案: B

5(單選題) 下圖是一個順序圖，其中(2)是指包含getTotalPayment的有向邊，叫做( )

A. 消息

B. 生命線

C. 活動條

D. 交互框

正確答案: A

6(單選題) 下圖是一個順序圖， 對getPrice描述正確的是( )

A. getPrice是Order類中的一個操作，它支持Product類對象訪問

B. getPrice是anOrder對象向prodcut對象傳遞的參數

C. getPrice是Product類中的一個操作，它支持Order類對象訪問

D. 以上均不正確

正確答案: C

7(單選題) 下圖是一個順序圖，其中(3)是指虛線上的細長矩形條，叫做( )

A. 消息

B. 生命線

C. 活動條

D. 交互框

正確答案: C

8(單選題) 如果對象A向對象B發送一個消息，對象A不必等待對象B執行完這個消息，就可以繼續執行自己的下一個行為，這樣的消息稱為( )

A. 同步消息

B. 異步消息

C. 自我調用消息

D. 上述均不正確

正確答案: B

9(單選題) 對象創建消息和對象銷毀消息是兩類特殊的消息，它們通過( )來標識。

A. 消息的箭頭

B. 注解

C. 構造型

D. 上述均不正確

正確答案: C

10(單選題) 下列哪個消息表示消息從一個對象發送到它本身

A. 同步消息

B. 異步消息

C. 自我調用消息

D. 簡單消息

正確答案: C

正確答案：
6: readPIN()
7: PIN
8: create(atm, this, card, pin)
9: performTransaction()

UML 結構

1 (單選題) A model . . .?

A. Is not necessary when team members understand their job.

B. Has to be structural AND behavioral.

C. Is a simplification of reality.

D. Is an excuse for building an elaborate plan.

正確答案: C

2(單選題) Why do we model?

A. Helps to visualize a system

B. Gives us a template for constructing a system

C. Documents our decisions

D. All of the above

正確答案: D

3(單選題) UML的擴展機制使得UML具有廣泛的應用范圍，其中（）可以用來為UML增加新的詞匯，即增加新的元素。

A. 構造型

B. 標記值

C. 約束

正確答案: A

4(單選題) The best models are connected to . . .?

A. Java-script code

B. Reality

C. C ++

D. Issues that tie it to an object-oriented developer

正確答案: B

5(單選題) UML的擴展機制使得UML具有廣泛的應用范圍，其中（）可以用來為UML元素增加新的屬性，即增加新的特性。

A. 構造型

B. 標記值

C. 約束

正確答案: B

6(單選題) UML的擴展機制使得UML具有廣泛的應用范圍，其中（）可以用來為UML增加新的規則，即增加新的語義。

A. 構造型

B. 標記值

C. 約束

正確答案: C

1(判斷題) UML結構包括構造塊、公共機制和圖三個部分。

正確答案: 錯

2(判斷題) 用UML描述的模型可以借助工具轉換成相應的程序代碼，所以UML可以看作是一種可視化程序設計語言。

正確答案: 錯

3(判斷題) UML是一種靈活的、可定制可擴展的語言，所以其不僅可以應用在面向對象軟件開發中，而且可以用在任何類型的分析設計項目中，甚至是軟件領域之外的其他項目也可以使用UML進行可視化建模。

正確答案: 對

4(判斷題) 公共機制指人們在使用UML時共同遵守的四種機制，使得使用UML變得比較簡單。這四種公共機制是Specification(規格說明)、Adornment（修飾）、Common Divisions(公共划分)和Extensibility Mechanisms（擴展機制）。

正確答案: 對

動態圖的比較

• 交互圖（順序圖、協作圖）：適合描述單個用例中多個對象之間的協作行為

• 狀態圖：適合描述跨越多個用例的單個對象的行為，不適合描述多個對象之間的協作行為

• 活動圖：適合描述多個對象跨越多個用例時的總面貌

• 不應對系統中的每個類都畫狀態圖，而只應對某些關鍵類建立狀態圖;而且應將狀態圖與其它技術組合使用

• 如果你更關注消息調用的順序，那么就使用順序圖

• 如果更關注交互參與者間的鏈接，就使用通信圖