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 用生命线间带有实心箭头的实线表示消息，每条消息从发送对象指向接收对象

消息的命名

• 每一个消息都必须命名

• 在表达消息的箭头上，我们放置表示消息名称的标签，其语法如下：属性 = 信号或消息名(参数: 参数类型) : 返回值

简单消息、同步消息和异步消息

• 简单消息(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（扩展机制）。

正确答案: 对

动态图的比较

• 交互图（顺序图、协作图）：适合描述单个用例中多个对象之间的协作行为

• 状态图：适合描述跨越多个用例的单个对象的行为，不适合描述多个对象之间的协作行为

• 活动图：适合描述多个对象跨越多个用例时的总面貌

• 不应对系统中的每个类都画状态图，而只应对某些关键类建立状态图;而且应将状态图与其它技术组合使用

• 如果你更关注消息调用的顺序，那么就使用顺序图

• 如果更关注交互参与者间的链接，就使用通信图