【软件建模与UML】

第二章 统一建模语言UML

2.1 软件建模简介

2.1.1 什么是模型

• 模型（model）：模型是用某种媒介对相同媒介或其他媒介里的一些事物的表现形式（对事物的抽象，帮助人们在创建一个事物之前可以有更好的理解）
• 建模：建立模型的过程
• 建模の目的：加入了系统的一个表示，以精确一直的方式描述系统，是的系统的使用更加容易

2.1.2 建模の重要性

• 建模可以帮助理解正在开发的系统*（基本理由）*，帮助开发者缩小问题的范围，每次着重研究一个方面，进而对整个系统产生更加深刻的理解。
• 建模对一个系统主要有以下几点作用：
  （1）捕获和精确表达项目的需求和应用领域的知识，以使全部涉众能够理解并达成一致
  （2）完成系统设计
  （3）分离需求与具体实现细节
  （4）帮助生成有用的工作产品
  （5）方便研究多种解决方案
  （6）全面把握复杂的系统

2.1.3 建模的基本原理

• 选择创建什么模型对如何解决问题和如何形成相应解决的方案意义深远
• 可以在不同的层次级别上表示不同模型
• 最好的模型总是与现实世界联系密切
• 单个模型或视图是不充分的

2.2 UML简述

• UML是一种语言，用于表达和交流
• UML是一种可视化语言
• UML提供了对图形模型的准确的、无歧义的、完整的详细描述
• UML是一种用于构造的语言
• UML是一种用于文档化的语言

2.3 UML的发展历史（略）

2.4 UML的目标与应用范围

2.4.1 UML的目标（意义）

• 为建模者提供可用的、富有表达力的、可视化的建模语言，以开发和交换有意义的模型
• 提供可扩展性和特殊化机制以延伸核心概念
• 支持独立于编程语言和开发过程的规范
• 为理解建模语言提供正式的基础
• 推动面向对象建模工具市场的成长

2.4.2 UML的应用范围

• UML以面向对象的方式来描述系统，最广泛的应用是对软件系统进行建模，但同样适用于许多非软件系统领域的系统。
• 理论上，任何具有静态结构和动态行为的系统都可以使用UML进行相应建模。
• UML应用于大多数软件系统的开发过程是，从需求分析阶段到系统完成后的测试阶段都起到重要作用：
  （1）需求分析阶段：通过用例捕获需求。
  （2）分析和设计阶段：通过类和对象等主要概念及其关系建立静态模型，对类、用例等概念之间的写作进行动态建模。
  （3）开发阶段：将设计的模型转化为编程语言的实际代码，指导并减轻编码工作。
  （4）测试阶段：用UML图作为测试依据。

---

第四章 UML概念模型

4.1 构造块（构造元素）

• 构造块（building blocks）是UML的基本建模元素，用于表达的语言元素，是来自现实世界中的概念的抽象描述方法。
• 构造块包括：事物（thing）、关系（relationship）、图（diagram）
  

4.1.1 事物

• 事物是构成模型图的主要构造块，代表了一些面向对象的基本概念。
• 事物是对模型中关键元素的抽象体现。
• 事物的四种类型：
  • 结构事物：作为UML模型的静态部分，定义了业务或软件系统中的某个概念元素或物理元素，用于描述概念元素或物理元素。
    • 常见结构事物：类、接口、用例、协作、主动类、组件、结点
  • 行为事物：（动作事物）UML模型的动态部分，行为元素是用来描述事物之间的交互或事物的状态变化，用于描述UML模型中的动态元素。
    • 常见行为事物：交互、状态机、活动
  • 分组事物：（组织事物）UML模型的组织部分，是UML对模型中各种组成部分进行事物分组的一种机制，用来组织系统设计。
    • 常见分组事物：包、其他基于包的扩展十五年（子系统、层等）
  • 注释事物：（辅助事物）UML模型的解释部分，用来描述、说明和标注模型的任何元素。

4.1.2 关系

• 关系是模型元素之间具体化的语义连接，负责联系UML的各类事物，构造出结构良好的UML模型。
  
• UML中有四种主要的关系：
  • 关联（association）：
    • 描述不同类元的实例之间的连接。
    • 表示两个类之间存在某种语义上的联系，它是所有关系中最通用、语义最弱的关系
    • 特殊关联关系：
      • 聚集(聚合)：整体与部分间的结构关系(松散)
      • 组成(组合)：部分完全依赖于整体(紧密)
        
  • 依赖（dependency）：
    • 有两个模型元素X、Y，如果元素X(独立元素)发生变化会影响另一个元素Y(依赖元素)的语义，则称元素Y依赖于元素X
    • 依赖关系：导入、包含、扩展
      
  • 泛化（generalization）：
    • 类似面向对象方法中的继承关系，是特殊到一般的一种归纳和分类关系。
    • 事物之间的一种特殊/一般关系，特殊元素(子元素)的对象可替代一般元素(父元素)的对象，即继承
      
  • 实现（realization）：
    • 描述规格说明和其实现的元素之间的连接的一种关系。
    • 描述了一组操作的规约和一组对操作的具体实现之间的语义关系。
    • 使用实现关系的两种情况：
      • 接口和实现接口的类或构件之间
      • 用例和实现用例的协作之间
        
  • 扩展(Extension)：
    • 扩展表示把一个构造型附加到一个元类上，使得元类的定义中包括这个构造型
    • 它是一种UML提供的底层的扩展机制，与用例之间的扩展(Extend)关系是不同的
    • 在UML中，用一个带箭头的实线表示

4.1.3 图

最常用的UML图包括：用例图、类图、顺序图、状态机图、活动图、包图、构件图和部署图。

• 用例图(Use Case Diagram) ：描述系统外部的参与者与系统的用例之间的某种联系，用于需求建模
• 类图(Class Diagram) ：显示系统静态结构，表示不同实体之间的关系
• 对象图(Object Diagram)：表示的是与其对应的类图的一个具体实例，即系统在某一时期或者某一特定时刻可能存在的具体对象实例以及它们相互之间的具体关系
• 顺序图(Sequence Diagram) ：显示了一个具体用例或者用例的一部分的一个详细流程 描述了对象之间动态的交互关系，着重体现对象间消息传递的时间顺序
• 通信图(Communication Diagram)：侧重于描述各个对象之间存在的消息收发关系（交互关系），而不专门突出这些消息发送的时间顺序
• 状态机图(State Diagram) ：表示某个类所处的不同状态及该类在这些状态中的转换过程 强调事件导致的对象行为
• 活动图(Activity Diagram)：用来表示两个或者更多的对象之间在处理某个活动时的过程控制流程
• 构件图(Component Diagram) ：提供系统的物理视图，它是根据系统的代码构件显示了系统代码的整个物理结构
• 部署图(Deployment Diagram)：用于表示该软件系统如何部署到硬件环境中，它是显示在系统中的不同的构件在何处物理地运行，以及如何进行彼此的通信

4.2 规则

• 规则是对软件系统或业务系统中的某些事物的约束或规定。
• 构造元素具有命名、范围、可见性、完整性和执行等属性。
  （1）命名(Name)：为事物、关系和图起名字
  （2）范围(Scope)：指基本元素起作用的范围，相当于程序设计语言中的变量的“作用域”
  （3）可见性(Visibility)：规定外界对该名字识别和使用的范围
  （4）完整性(Integrity)：保证事物正确、一致地相互联系
  

4.3 通用机制（公共机制）

• 公共机制指适用于软件系统或业务系统中每个事物的方法或规则。
• 公共机制包括规格说明、修饰、通用划分、扩展机制。

4.2.1 规格说明

• 规格说明(Specification)：模型元素的属性值

4.2.2 修饰

• 修饰(Adornment) ：基本元素的符号对事物最重要的方面提供可视化表示，要把元素的细节方面表示出来，必须通过对元素进行修饰

4.2.3 通用划分

• 通用划分(General Division) 类和对象的划分：类是一个抽象而对象是这种抽象的一个实例化
• 接口和实现的分离：接口是一种声明，实现则是执行声明

4.2.4 扩展机制

1. 构造型(Stereotype)

• 表示构造型的符号有三种：
  

2. 标记值(Tagged Value)

• 标记值是用来为事物(元素)添加新特征的
• 标记值的表现形式：{标记名=标记值}
• UML预定义标准标记值：documentation、location、 persistence、responsibility、semantics等
  

3. 约束(Constraint)

• 扩展UML模型元素的语义，允许用户增加新的规则和修改现有的规则
• 约束的表现形式：{约束的内容}
  

4.3 “4+1”架构（略）

4.5 小结

---

第五章 用例图

5.1 用例图的基本概念

5.1.1 用例图の概念及作用：

• 用例图（use case diagram）：表示一个系统中用例与参与者关系之间的图。
• 作用：描述了系统中相关的用户和系统对不同用户提供的服务和功能，便于用户和开发人员消除歧义，达成共识

5.1.2 用例图の组成元素：

• 参与者(Actor) ：位于系统外部，使用系统或与系统交互中所扮演的角色
• 用例(Use Case)： 位于系统内部，系统提供给参与者的功能
• 系统边界(Boundary) ：表示正在建模系统的边界，边界内表示系统的组成部分，边界外表示系统外部
• 关系(Relationship) ：
  • 参与者与用例之间：关联关系
  • 参与者与参与者之间 ：泛化关系
  • 用例与用例之间：依赖关系、泛化关系

5.2 参与者

5.2.1 参与者的概念

• 参与者(Actor)：存在于系统外部并直接与系统进行交互的外部实体的抽象。
• 参与者的特点：
  （1）参与者位于系统外部
  （2）参与者是用户相对系统而言所扮演的角色
  （3）参与者包括所有与系统进行交互的外部实体
• 参与者的UML表示方法：
  （1）图标表示法
  （2）标签表示法

5.2.2 确定参与者

• 如何确定参与者：
  • 为系统提供输入的人或事物
  • 接收系统输出的人或事物
  • 需要接入的第三方系统或设备
  • 时间是否会触发某些事件
  • 负责支持或维护系统中信息的人
  • 使用该系统或者与该系统交互的人、系统、设备等外部实体
• 参与者の基本特征：
  • 位于系统边界之外
  • 直接且主动的向系统发出动作并获得反馈

5.2.3 参与者的泛化关系

• 泛化关系(Generalization)：描述了参与者之间特殊与一般的关系
• 泛化关系的UML表示方法：
  

5.3 用例

5.3.1 用例的概念

• **用例(Use Case)**是对一组动作序列的描述，系统执行这些动作序列来为参与者产生一个可观察的结果值。
• 用例的UML表示方法：
  

5.3.2 用例与参与者

• 用例的确定：
  • 考虑以下问题：
    • 参与者希望系统提供什么功能？
    • 参与者是否会读取、创建、修改、删除、存储系统中的某种信息？
    • 参与者是否会将外部的某些事件通知给系统？
    • 系统中发生的事件是否通知给参与者？
    • 是否存在影响系统的外部事件？
• 参与者与用例の关系
  • 关联关系(Association) ：用于为参与者与用例建立连接
  • 关联关系的UML表示方法：
    

5.3.3 用例の特征

特征1：用例必须位于系统边界内部

• 从外部用户角度出发系统所提供的功能和服务
• 定义了系统的行为特征
• 超出当前系统功能范畴之外，以及外部系统或者硬件设备产生的行为，不能识别为用例

特征2：用例是以动宾短语形式出现的

• 用例表达的是一次完整的人机交互序列
  

特征3：用例是相对独立的

• 用例在功能上必须是完备的
• 不能完整实现参与者目的的行为不能称之为用例
  

特征4：用例的执行结果对参与者来说是可观测且有意义的

• 用例描述参与者与系统之间的交互行为，而非内在系统活动
• 用例为业务功能，而非处理过程
  

特征5：用例是由参与者启动的

• 用例不应自动启动，也不应主动启动另一个用例
  

5.3.4 用例的粒度（略）

5.4 用例之间的关系

5.4.1 依赖关系

1.包含关系：

• 包含关系(Include)：一个用例（基础用例）可以简单的包含其他用例（被包含用例）具有的行为。
  • 被包含用例的事件流可插入至基础用例的事件流中。
  • 包含关系的UML表示方法：
    
    
    

2.扩展关系：

• 扩展关系(Extend)：一个用例（扩展用例）扩充了另一个用例（基础用例）的功能。
  • 只有在满足特定条件的情况下才会被执行。
  • 扩展关系的UML表示方法：
    
    

3. 包含关系与扩展关系比较——共同点
4. 包含关系与扩展关系比较——区别

5.4.2 泛化关系

1. 参与者间的泛化关系：

• 泛化关系(Generalization)：描述了参与者之间特殊与一般的关系
• 泛化关系的UML表示方法：
  

2. 用例间的泛化关系

• 泛化关系(Generalization)：描述了特化用例（子用例）与一般化用例（父用例）之间的关系
• 泛化关系的UML表示方法：
  

3. 泛化关系与包含关系比较

• 共同点
  
• 区别
  
  

5.4.3 关联关系

1.概念：

• 关联关系(Association)：表示参与者与用例间的关系，用于为两者建立连接。
• 关联关系的UML表示方法：
  

2. 注意事项：
（1）参与者和用例的消息传递是双向的，关联关系的箭头方向通常只代表了用例被参与者启动：

（2）参与者和用例之间是多对多的关联关系

• 一个用例和一个参与者之间最多只有一个关联关系
• 多个参与者实例参与一个用例实例的发起和执行，则参与者之间存在主次之分
  
  （3）关联关系只存在于参与者和用例之间，用例和用例间不存在关联关系
  

5.5 用例描述与文档（用例规约）

5.5.1 用例描述概述

• 基本数据：
  • 用例编号：用例的唯一标识符，建议以UC(Use Case)作为前缀
  • 用例名称：描述用例的意图或实现的目标，建议与用例图保持一致
  • 用例简述：简要介绍用例的作用和目的
  • 参与者：描述用例的参与者，包括主要参与者和其他参与者

5.5.2 前置条件与后置条件

• 触发条件：标识启动用例的事件，可能是系统外部事件，也可能是系统内部事件，还可能是正常流程的第一个步骤
• 前置条件：描述用例能够正常启动和工作的系统状态条件
• 后置条件：描述用例执行完毕后系统的状态条件
• 注意事项：
  • 描述状态必须是能检测且可观测的
  • 用例规约中的非必需字段
    

5.5.3 事件流

• 基本事件流：
  • 对用例中常规、预期路径的描述
  • 包括参与者发起的动作和系统执行的响应活动
  • 不涉及系统实现细节，不对界面设计提出要求
• 扩展事件流：
  • 对一些异常情况、选择分支的描述
    

5.5.4 补充约束

• 特殊需求：描述用例实现时需要考虑的业务规则、实现约束及非功能性需求等信息
• 扩展点 描述对当前用例的扩展 对于基础用例，给出与之存在关系的其他用例的引用和描述
• 优先级 说明用户对该用例的期望值
• ·数据需求
• 业务规则
• 非功能性需求
• 设计约束

5.6 应用用例图建模

5.6.1 用例图建模技术

• 用例图的一般建模流程： 确定参与者→确定用例→确定用例之间的关系→绘制用例图→描述用例规约
• 使用用例图的两种方式：对系统的语境建模、对系统的需求建模
• 系统的内部和外部：

5.6.2 用例图使用要点

• 构建结构良好的用例
• 应给出一个表达其目的的名称
• 摆放元素时，应避免出现交叉线
• 对于语义上接近的行为和角色，位置上同样接近
• 充分使用注解和颜色等方式，突出图的重要特性
• 尽可能减少图中关系的种类

---

第六章 类图与对象图

6.1 类图的基本概念

6.1.1 类图与对象图的定义

• 类图是用于对系统中的各种概念进行建模，并描绘出它们之间关系的图
• 对象图描述系统在某一个特定时间点上的静态结构，是类图的实例和快照，对象图中包含对象(Object)和链(Link)

6.1.2 类图的作用

• 为系统词汇建模：识别问题域的实体并进行抽象，详细描述抽象及其执行的职责
• 模型化简单的协作：通过类图将类和它们之间的关系进行可视化和表述
• 模型化逻辑数据库模式：为数据库模式建立模型

6.1.3 类图和对象图的异同

• 类图：类图是用于对系统中的各种概念进行建模，并描绘出它们之间关系的图
• 对象图：对象图描述系统在某一个特定时间点上的静态结构，是类图的实例和快照
• 对象—对象与类的区别
  • 对象是一个存在于时间和空间中的具体实体，而类是一个模型，该模型抽象出对象的“本质”
  • 类是静态的，对象是动态的
  • 类是一般化，对象是个性化
  • 类是定义，对象是实例
  • 类是抽象，对象是具体

6.2 类图的组成元素

6.2.1 类

1. 类的定义

• 类是对一组具有相同属性、操作、关系和语义的事物的抽象
• 类拥有不同的构造型

2. 类的名称(Name)

• 每个类都必须有一个区别于其他类的名称，类名部分不可省略
• 名称的表示方法：
  （1）简单名称：只是一个单独的名称，如Student
  （2）路径名称：在类名前面加上包的名称，例如java::awt::Rectangle、Office::Printer
• 类的命名规范要求：由字母、数字、下划线、汉字组成的惟一的字符串
• 类的命名建议：
  （1）在实际应用中，采用CamelCase格式(大写字母开头、混合大小写，每个单词以大写开始)
  （2）不能使用特殊符号，尽可能避免使用缩写形式
  （3）尽可能使用业务领域中的术语，并尽可的明确、简短、无歧义，以便于开发人员与用户之间的相互理解和交流
  （4）一般而言，类的名字是名词 避免使用抽象、无意义的名词
  （5）正体字说明类是可被实例化的，斜体字说明类为抽象类

3. 类的属性(Attribute)

• 描述了在软件系统中所代表的对象具备的静态部分的公共特征抽象
• 类的属性的表示语法： [可见性] 属性名称 [:属性类型] [=初始值] [{属性字符串}]
  （1）可见性：描述该属性是否能被其他类引用
  （2）属性名称：第一个英文单词小写，其余首字母大写
  （3）属性类型 任意类型(简单类型、系统中其他类等)
  （4）初始值：保护系统完整性和为用户提供易用性
  （5）属性字符串：指定关于属性的附加信息，如{readOnly}描述该属性是否能被其他类引用
  （6）类变量：类的作用域属性，能被所属类的所有对象共享
  （7）派生属性：
  （8）多重性：提供了一种精确的方法表达特定的与参与关系中的“事物数目”有关的业务约束

4. 类的操作(Operation)

• 描述了在软件系统中所代表的对象具备的动态部分的公共特征抽象
• 类的操作的表示语法： [可见性] 操作名称 [(参数表)] [:返回类型] [{属性字符串}]
  （1）可见性：描述该操作是否能被其他类引用
  （2）操作名称 第一个英文单词小写，其余首字母大写
  （3）参数表：参数表可选，也可有默认值
  （4）返回类型：任意有效数据类型(简单类型、类、void)
  （5）属性字符串：指定关于操作的附加信息
  （6）类操作：类的作用域操作，能被所属类的所有对象共享
  （7）参数方向：表示操作调用时，参数传递值的方向

5. 类的职责(Responsibility)

• 类的职责指的是对该类的所有对象所具备的相同的属性和操作共同组成的功能或服务的抽象

6. 类的约束(Constraint)

• 类的约束制定了该类要满足的一个或多个规则

7. 类的注释(Note)
8. 类的类型：抽象类、模板类、关联类、分析类
9. 类的构造型：参与者(Actor)、接口(Interface)

• 参与者(Actor)
  • 参与者是指存在于系统外部并直接与系统进行交互的外部实体的抽象。
  • 参与者的UML表示方法：图标表示法、标签表示法

6.2.2 接口(Interface)

• 接口是一个没有具体实现的类，不包含属性和操作实现
• 接口说明了操作的命名集合，是功能性规格说明
• 接口主要定义操作签名，不包含实现，这留给实现接口的类、子系统或构件完成
• 使用接口是为了将规格说明和实现相分离
  
  

6.2.3 类图中的关系

1. 依赖(Dependency)关系

• 依赖表示两个或多个模型元素之间语义上的连接关系
• 提供者的某些变化会要求或指示依赖关系中客户的变化
  
  

（1）绑定(Binding)依赖

• 绑定是将数值分配给模板的参数
• 是具有精确语义的高度结构化的关系，可通过取代模板备份中的参数实现

（2）实现(Realization)依赖

• 说明和对这个说明的具体实现之间的映射关系
• 接口/实现类之间、用例/协作之间

（3）使用(Usage)依赖

• 表示客户使用提供者提供的服务以实现自身的行为

（4）抽象(Abstraction)依赖

• 表示客户与提供者属于不同的抽象事物，将同一个潜在事物的不同形式联系起来

（5）授权(Permission)依赖

• 表示一个事物对另一个事物的进行访问的能力

2. 泛化关系

• 用来描述类的一般和具体之间的关系
• 一般描述的类被称作父类，具体描述的类被称作子类
• 泛化关系描述的是“is a kind of”的关系
• 泛化关系特点：
  （1）特殊事物完全符合一般事物
  （2）能够在一般事物出现的地方替换成特殊事物
  （3）通过从特殊事物泛化或从一般事物特化可以创建泛化层次
• 泛化の用途：
  （1）自底向上的实例替换。可以使得子类的实例用于任何父类被声明使用的地方，实现多态
  （2）自顶向下的属性继承。可以使得子类共享父类的属性和操作，实现继承。
  private、implementation属性不被继承 public、protected属性可被继承
• 泛化の层次:
  • 泛化可能跨越多个层次。一个子类的超类也可以是另一个超类的子类
  • 只有一个类确实是另一个类的特殊类型时才使用泛化，而不是只为了方便使用
• 泛化の多重继承:
  • 一个类可以从多个父类派生而来
• 泛化约束:
  • 泛化约束用于表明泛化有一个与其相关的约束
  • 带有约束条件的泛化也被称为受限泛化
    （1）不完全约束(Incomplete Constraint) 表示类图中没有完全显示出泛化的类
    （2）完全约束(Complete Constraint) 表示类图中显示出全部泛化的类
    （3）解体约束(Disjoint Constraint) 表示紧靠约束下面的泛化类不能子类化为通用的类
    （4）重叠约束(Overlapping Constraint) 表示多个子类可以共享相同的子类

3. 关联(Association)关系

• 关联の定义
  • 关联关系指出了一个事物的对象与另一个事物的对象之间的语义上的连接
  • 关联可以分为单向关联，双向关联
  • 一个类的关联的任何一个连接点被称为关联端
  • 关联的一个实例被称为链
• 关联の特性
  • 名称：可以在关联上标识阅读方向的方向指示符，以消除阅读的歧义
  • 角色：
    • 在关联关系中，一个类通过关联对另外一个类所表现出来的职责
    • 如果在关联上没有标出角色名，则隐含的用类名作为角色名
  • 多重性
    • 在关联关系中，一个类的多个实例与另一个类的一个实例相关
    • 多重性表示形式：minimum…maximum
      
  • 导航性
    • 描述一个对象通过链进行导航访问到另一个对象
    • 根据方向不同分为单向关联和双向关联
  • 关联类：通过关联类可以进一步描述关联的属性、操作，以及其它信息
    

6.2.4 涉及类的其他概念

• 抽象类(Abstract Class)

  • 缺乏实现的操作称为抽象操作，包含抽象操作的类是抽象类
  • 抽象类是不完整的，不能被直接实例化。不能创建一个属于抽象类的对象
    

• 关联类(Association Class)

  • 在应用当中，如果发现两个类之间具有多对多的关系，并且有些属性不属于关联两端任何一个类
  • 实际上关联类既是关联又是类，它不仅象关联那样连接两个类，而且可以定义一组属于关联本身的特性

• 模板类(Parameterized Class)

  • 在编译时把模版参数绑定到不同的数据类型，从而产生不同的类
  • 模板可以根据占位符或者参数来定义类，而不用说明属性、方法返回值和方法参数的实际类型
  • 通过实际值代替占位符即可创建新类

• 主动类(Active Class)

  • 主动类的实例称为主动对象
  • 一个主动对象拥有一个控制线程并且能够控制线程的活动，具有独立的控制权
  • 例如，命令处理程序就是一个主动类的例子，它从外面接受命令对象，然后在自身的控制线程内执行命令

• 嵌套类(nested Class)

  • 在一个类内部定义另一个类
  • 嵌套类存在于外层类的名字空间中，因此只有外层类或外层类的对象才能访问它或它的实例

• 分析类

  • 分析类是一个主要用于开发过程中的概念，用来获取系统中主要的“职责簇”
  • 分析类在从业需求向系统设计的转化过程中起到重要作用，在高层次抽象出系统实现业务需求的原型
  • 分析包括：边界类、实体类、控制类
    

• 边界(Boundary)类：

  • 边界类位于系统与外界的交界处，承担系统与外界的信息交互功能
  • 如窗体、对话框、报表、与外部设备或系统交互的类等
  • 边界类可以通过用例确定，因为参与者必须通过边界类参与用例

• 实体(Entity)类

  • 实体类描述要保存到持久存储体中的信息
  • 类及其属性最终可能映射成数据库中的表以及字段
  • 实体类可以从现实中存在的客观事物，以及需要持久存放的信息两方面来发现

• 控制(Control)类

  • 控制类负责协调其他类工作和控制总体逻辑流程
  • 以委托责任的形式向其他类发出消息

6.4 类图与对象图的建模技术

6.4.1 类图的建模技术

• 对系统词汇建模
• 对简单协作建模
• 对逻辑数据库模式建模

6.4.2 正向工程与逆向工程

• 正向工程の策略：
  • 确定映射到显示语言的规则
  • 根据所选择的语言，限制某些UML的特性
  • 使用标记值来帮助实现目标语言的细节
  • 实用工具生成代码
• 逆向工程の策略：
  • 确定实现语言进行映射的规则
  • 指定要进行逆向工程的代码
  • 使用工具，通过查询模型来创建类图
  • 人工为模型增加在逆向工程中丢失或隐藏的相关信息

6.4.3 对象图的建模技术

• 使用对象图对系统的对象结构建模：
  • 识别建模机制
  • 识别参与的类和接口等元素
  • 识别并选择对象
  • 俺需要显示每个对象的状态
  • 识别并显示出对象之间的链（对象的类目之间关联的实例）

6.4.4 面向对象设计的原则

• 开闭原则
• 里氏替换原则
• 依赖倒置原则
• 接口分离原则
• 单一职责原则

第七章 包图

7.1 包图的基本概念

• 包图(Package Diagram)是一种维护和描述系统总体结构的模型的重要建模工具通过对图中各个包以
• 及包之间关系的描述，展现出系统的模块与模块之间的依赖关系

7.2 包

7.2.1 包的概念

• 包(Package)是UML中将多个元素组织为语义相关的组的通用机制
• 包中可以包含类、接口、构件、用例、结点、活动、状态、包等其他模型元素
• 一个元素只能属于一个包

1. 包的名称

• 包的名称为一个字符串，通常是来自模型词汇中的名词或名词短语
• 名称的表示方法：
  • 简单名称：只是一个单独的名称
  • 路径名称：用该包的外围包的名字作为前缀，加上包本身的名字

2. 包中拥有的元素

• 在一个包中可以创建各种模型元素，如类、接口、构件、结点、用例、图以及其他包等
• 在包图下允许创建的各种模型元素是根据各种视图下所允许创建的内容决定
• 每一个包就意味着一个独立的命名空间

3. 包的可见性

• 内元素的可见性控制了包外部元素访问包内部元素的权限
  
  

7.2.2 包的作用

• 对语义上相关的元素进行分组
• 定义模型中的“语义边界” 提供配置管理单元
• 在设计时，提供并行工作的单元
• 提供封装的命名空间，其中所有名称必须惟一

7.2.3 元素的分包原则

• 元素不能“狡兔三窟”
• 相同包内元素不能重名
• 包内元素要紧密联系
• 包与包尽可能保持独立

7.3 包の关系

7.3.1 包の依赖关系

1. << use >>关系

• < > 关系是一种默认的依赖关系
• 说明客户包中的元素以某种方式使用提供者包的公共元素
• 也就是说客户包依赖于提供者包
  
  

2. << import >>关系

• << import >>关系说明提供者包的命名空间将被添加到客户包的命名空间中
• 客户包中的元素能够访问提供者包的所有公共元素
• << import >>关系使命名空间合并

3.<< access >>关系

• << access >> 关系说明客户包中的元素能访问提供者包中的所有公共元素，但是命名空间不合并，在客户包中必须使用路径名

4. << trace >>关系

• 表示一个包到另一个包的历史发展
  
  

7.3.2 包の泛化关系

• 特殊包继承一般包的特性，使用一般包的地方，可以用特殊包代替

7.3.3 包の拥有（组成）关系

·拥有关系是包嵌套时，包之间的一种组成关系，意味着子包被外围包所拥有

7.4 包图的建模技术

1. 包图建模原则

（1）重用等价原则：把类放入包中时，应考虑把包作为可重用的单元
（2）共同闭包原则：把可能同时修改，同时维护的类放到一个包中，以便于维护，和升级

• 一个类的改变要求另一个类做相应改变
• 删除一个类后，另一个类变成多余
• 两个类间有大量的消息发送

（3）共同重用原则：不会一起使用的类不要放在同一个包中
（4）“最小化系统间的耦合关系”原则：最小化每个包的public、protected元素的个数，最大化每个包中private元素的个数
（5）非循环依赖原则：包之间的依赖关系不要形成循环

2. 类的包图建议

• 一个框架内的类属于一个包
• 一般位于同一继承层次上的类属于同一个包
• 通过聚集或者组成关系相关联的类往往属于同一个包
• 相互之间协作很多的类通常属于同一个包

3. 包图创建步骤

（1）寻找包

• 通过把具有很强语义联系的建模元素分组，找出分析包
• 分析包必须反映元素的真实的语义分组，而不仅是逻辑架构的理想视图
• 良好包结构的关键是包内高内聚，包间低耦合，应尽可能避免嵌套包

（2）确定包之间的依赖关系

• 应该尽量避免包模型中的循环依赖
  

第八章 顺序图

8.1 顺序图的概念

1. 顺序图の定义

• 顺序图(Sequence Diagram)是用于描述一组对象及其协作过程的模型图，也称序列图。
• 顺序图展示了对象之间如何相互协作来完成某一项功能，强调各个对象按照时间顺序进行交互的过程。

2. 顺序图の作用

• 确认和丰富一个使用语境的逻辑表达
• 细化用例的表达
• 有效的描述如何分配各个类的职责以及各类具有相应职责的原因

3. 顺序图の组成

• 对象、生命线、激活、消息

8.2 顺序图的组成元素

8.2.1 对象

• 顺序图中对象可为系统参与者或任何有效的系统对象
• 对象的三种表示形式：对象、匿名对象、省略类名的对象
• 对象置于顶部意味着交互开始时对象就已经存在了
• 对象不置于顶部意味着对象是在交互过程中创建的
• 顺序图中经常使用分析类の对象：
  • 边界类：系统界面，负责输入信息或展示输出。
  • 控制类：
    • 负责对界面输入的数据进行计算。
    • 如果计算结果需要保存，则传递给实体类。
    • 如果计算结果需要输出，则传递给边界类。
  • 实体类：负责存储计算的结果。

8.2.2 生命线

• 用于表示顺序图中的对象在一段时间内的存在
• 对象的存在的时段包括对象在拥有控制线程时或被动对象在控制线程通过时存在
• 对象在拥有控制线程时，对象被激活
• 被动对象在控制线程通过时，即被动对象被外部调用，通常称为活动
• 生命线间的箭头代表对象之间的消息传递
  

8.2.3 激活

• 激活是对象操作的执行，它表示一个对象直接地或通过从属操作完成操作的过程
• 一个被激活的对象要么执行自己的代码，要么等待另一个对象的返回结果
• 对象在完成自己的工作后，被去激活，对象就处于空闲状态
  

8.2.4 消息

• 消息是从一个对象(发送者)向另一个或几个其他对象(接收者)发送信号，或由一个对象(发送者或调用者)调用另一个对象(接收者)的操作
  
• 顺序图中，尽力保持消息的顺序是从左到右排列的
• 一个顺序图的消息流开始于左上方，消息2的位置比消息1低，这意味着消息2的顺序比消息1要迟。因为西方的阅读习惯是从左到右
• 顺序图中消息编号可显示，也可不显示。协作图中必须显示

（1）消息の组成

• 发送者：发出消息的类元角色
• 接收者：接收到消息的类元角色
• 活动：调用、信号、发送者的局部操作或原始活动(创建、销毁)等
• 接收者的调用处理方式：
  • 操作作为方法实现
  • 主动对象，操作调用导致调用事件

（2）消息の种类

• 过程调用/调用消息(Procedure Call)

  • 表示调用某个对象的一个操作(通常格式为“对象名.成员方法”)
  • 可以是对象之间的调用，也可以是对象本身的调用(局部调用)
  • 也称为同步消息，发送者把控制传递给接收者，然后停止活动，等到消息接收者放弃或返回控制
    
    

• 异步消息/简单消息(Asynchronous Message)

  • 异步消息的发送者通过消息把信号传递给接收者，然后继续自己活动，不等待接收者返回消息或控制
    

• 返回消息(Return Message)

  • 返回表示被调用对象向调用者返回一个值
  • 消息上方放置返回值
  • 如果是从过程调用返回，则返回消息是隐含的
  • 对于非过程调用，如果有返回消息，必须画出来
    

• 自调用消息(Message to Self)

  • 某对象自己调用自己的操作
  • UML标记(嵌套的矩形条)和Rose标记
    

• 阻止消息(Balking Message)

  • 阻止消息指消息发送者发出消息给接收者，如果接收者无法立即接收这个消息，则发送者放弃这个消息
    

• 超时消息(Timeout Message)

  • 超时消息指消息发送者发出消息给接收者，并按指定时间等待，如果接收者无法在指定时间内接收这个消息，则发送者放弃这个消息
    

（3）消息の语法格式

• [前缀][守卫条件][序列表达式][返回值:=]消息名([参数列表])
• 前缀(predecessor)
  • 语法：消息序列号,消息序列号, … /
  • 前缀是一个用来同步线程或路径的表达式
  • 含义：在发送当前消息之前指定序列号的消息被处理(必须连续执行)
  • 例如 1.1a, 1.1b/1.2: continue()
• 守卫条件(guard-condition)
  • 语法： [ 条件短语 ]
  • 条件短语通常用伪代码或真正的程序语言来表示，UML并不规定其语法
  • 例如，[x<0] 4: invert(x, color)
• 序列表达式 (sequence-expression)
  • 语法：[integer | name] [recurrence] :
  • integer为指定消息顺序的序列号
  • name表示并发控制线程，例如1.2a和1.2b为同时发送的并发消息
  • recurrence表示一个条件或迭代的执行
  • 有两种选择：
    • [ 循环子句 ]：循环子句(iteration-clause)用来指定一个循环(重复执行)
    • 例如：1.1 *[x = 1…10] : doSomething()
    • [ 条件子句 ] ：一般用来表示分支而不是用作守卫条件

（4）消息の编号

• 形式：顺序编号、嵌套编号

8.3 顺序图の高级概念

1. 创建与销毁对象

• 创建对象
  • 发送者发送一个实例化消息后实例化对象的结果，即通过发送消息的方式创建对象
  • 创建对象通常通过构造函数(方法)来实现
  • 对象创建之后，生命线即开始
• 销毁对象
  • 将对象销毁并回收其拥有的资源
  • 销毁一个对象一般是利用析构函数来实现
  • 销毁对象表示对象生命线的结束
  • 在对象生命线中使用一个“X”来进行标识
    

2. 条件分支

• 分支是指的是从同一点发出多个消息的并指向不同的对象
• 根据条件是否互斥，分支分为两种结构：
  • 条件：根据不同的条件进入不同的处理流程中
  • 并行：当执行到某一点时需要向两个或两个以上对象发送消息，消息是并行的

3. 循环

• 强调需要对多个对象重复发送某个消息
• 顺序图中表示循环执行消息有三种方式
  • 在需要循环重复执行的消息前添加符号“*”，并在其后的中括号中写明具体条件
  • 在时间轴上注释表明消息的重复执行，使用大括号标明说明文字
  • 使用矩形框将需要重复执行的消息框起来，并在中括号内说明重复执行的条件

4. 从属流

• 从属流指从同一点发出多个消息指向同一对象的不同生命线
• Rose和SU不支持从属流， VP支持

5. 消息延迟

• 从一个对象到另一个对象的消息可能存在一定的时间延迟
• 由于邮件服务器是外部对象，用户与邮件服务器的相互通讯需要必要的网络延迟

6. 顺序图片段

• 一个交互片段可以包含多个区域，每个区域拥有一个监护条件和一个复合语句
• 每个交互片段都有一个操作符，操作符决定了交互片段的执行方式
  
  

8.4 顺序图の片段

• 顺序图片段：

  • Alt和Opt

    • 可以表示分支的操作符有两个：支持多条件的alt和支持单条件的opt
      

  • Loop

    • loop操作符说明该片段将可以执行多次，而具体的次数由循环次数和监护条件表达式来说明
    • 迭代标记是由一个附于消息名的“”号来表示，用来表示循环，也可以在“”号后面加上一个方括号，并在里面写出循环次数。监护条件是置于方括号内的条件表达式
    • Loop(1,n):表示for(i=1;i<=n;i++)
    • Loop(10):表示执行10次
      

  • Assert、Consider和Ignore

    • 操作符assert是用来表示行为是执行过程中那个时刻唯一的有效行为
    • 操作符consider包含一个子片段和一个消息类型列表。只有列表中的消息类型可以出现在子片段中
    • 操作符ingore也包含一个子片段和一个消息类型列表。列表中的消息类型可以出现在子片段中，但交互会忽略它们
    • 只接受start或stop消息(consider{start, stop})
    • 而且在start消息之后必须是一个stop消息(assert操作符表示)
      

  • Break

    • 用break定义一个含有监护条件的子片段
    • 若监护条件为“真”则执行子片段，不执行子片段后面的其他交互
    • 若监护条件为“假”就按正常流程执行
      

  • Critical

    • 操作符critical表示子片段是“临界区域”，在临界区域中，生命线上的事件序列不能和其他区域中的任何其他事件交错
    • 它通常用来表示一个原子性的连续操作，例如事务性操作
      

  • Par

    • 操作符par是用来表示“并行”的，即表示两个或多个并发执行的子片段
    • 并行子片段中，单个元素的执行次序可以以任何可能的顺序相互操作(除非采用critical禁止)
      

  • Ref

    • ref用来在一个交互图中，引用其他的交互图。在一个矩形框的左上角标识ref操作符，并在方框中写明被引用的交互图名称
      

8.5 顺序图建模技术

1. 顺序图的建模过程

• 对于包含复杂控制流的用例，顺序图的建模过程：
  （1）分析用例的工作流程，确定基本工作流程和备选工作流程；
  （2）建立包，以便于对复杂控制流的多个顺序图进行组织管理；
  （3）创建顺序图，对于基本工作流程创建主干顺序图，对于每个备选工作流程分别创建分支顺序图；
  （4）绘制顺序图，为每个工作流逐步绘制顺序图。
• 绘制顺序图的基本步骤：
  （1）识别对象：在顺序图上方从左到右依次排列（一般是按参与者、边界对象、控制对象、实体对象的顺序）；
  （2）确定消息：按照消息传递的过程依次在顺序图中绘制消息；
  （3）设置对象的激活期和生存期：在每个对象的生命线上，可以用控制焦点标识激活状态，用符号“×” 标识生存期的结束。

2. 分析工作流（例子）：

• 基本工作流程
  • 教师希望通过系统查询某名学生的学科成绩
  • 教师通过用户界面录入学生的学号以及学科科目请求学生信息
  • 用户界面根据学生的学号向数据库访问层请求学生信息
  • 数据库访问层根据学生的学号加载学生信息
  • 数据库访问层根据学生信息和学科科目获取该名学生的分数信息
  • 数据库访问层将学生信息和分数信息提供给用户界面
  • 用户界面将学生信息和分数信息显示出来
• 备选过程：
  • 备选过程A：该名学生没有学科成绩
    • 数据访问层返回学科成绩为空
    • 系统提示教师没有该学生的成绩
  • 备选过程B：系统没有该学生的信息
    • 数据访问层返回学生信息为空
    • 系统提示教师该学生不存在
• 确定对象
  • 从左到右布置在该工作流程中所有的参与者和对象，同时也包含要添加消息的对象生命线
    - 确定消息和条件
    

第九章 协作图（通信图）

9.1 协作图的概念

1. 协作图的定义

• 协作图(Collaboration Diagram)描述了系统中对象间通过消息进行的交互
• 强调了对象在交互行为中承担的角色
• 协作图和顺序图之间的语义是等价的，可以很容易的完成从顺序图到协作图的转换

2. 协作图的作用

• 通过描述对象之间消息的传递情况来反映具体使用语境的逻辑表达
• 显示对象及其交互关系的空间组织结构
• 表现一个类操作的实现

9.2 协作图的组成元素

9.2.1 对象

1. 概述

• 协作图中对象可为系统参与者或任何有效的系统对象
• 对象的三种表示形式
  

2. 多对象

• 多对象是多个对象组成的集合，往往是同一个类的对象
• 如果消息同时发给多个对象，则用多对象表示
  

3. 主动对象

• 主动对象是一组属性和方法的封装体，其中至少有一个方法不需要接收消息就能主动执行(称为主动方法)
• 主动对象是不需接收消息就可自动启动交互的对象
• 除了含有主动方法外，主动对象和被动对象无区别

9.2.2 链

• 表示对象之间的语义关系，链是关联的一个实例
• 链的构造型(UML 1.0)
  
• 链的可见性：一个对象是否能够对另一个对象可见的机制
  

9.2.3 消息

• 协作图中的消息类型与顺序图中的相同
• 语法格式
  • [前缀][守卫条件][序列表达式][返回值:=]消息名([参数列表])
  • 语法：[integer | name] [recurrence] :
  • 消息编号的形式：无层次编号和嵌套编号
    
    

9.2.4 分支&迭代ppt

9.3 协作图与顺序图

• 顺序图和协作图都属于交互图，用于描述对象之间的动态关系

• 顺序图描述了对象交互的时间顺序，但没有明确的表达对象之间的关系，也没有表明对象在交互中承担的角色

• 协作图描述了对象在交互中承担的角色(关系)，但对象在交互中的时间顺序必须从消息的顺序号获得

• 顺序图强调消息的时间顺序，协作图强调参与交互的对象的组织关系

• 顺序图和协作图在语义上是等价的，两者可以相互转换

• 共同点：

  • 对象和消息

• 区别：

  • 顺序图不同于协作图的特征：
    • 顺序图有对象生命线
    • 顺序图有控制焦点
  • 可以表示出对象的激活状态和去激活状态，也可以显式的表示出对象的创建和销毁的相对时间
    • 协作图不同于顺序图的特征：
    • 协作图必须有消息顺序号
    • 协作图有关联的实例—链

9.4 协作图建模技术

1. 确定工作流程
- 基本工作流程
- 备选过程
2. 确定协作图的元素

3. 确定元素之间的结构关系

4. 细化协作图

---

第十章 状态图

10.1 状态图的基本概念

10.1.1 状态机

1. 状态机

• 一个类的对象所有可能的生命历程的模型
• 包含了一个类的对象在其生命周期内所有状态的序列以及对象接收到事件所产生的反应
• 利用状态机可精确的描述对象的行为

2. 状态机的组成

• 状态：对象在其生命周期中的一种状况
• 转换：两个不同状态之间的一种关系
• 事件：引起状态变化的事情
• 活动：状态机中进行的非原子操作
• 动作：状态机中可以执行的原子操作

10.1.2 状态图

• 状态机图描述对象在整个生命周期的动态行为，表现对象经历的状态序列，引起状态转移的事件，转移伴随的动作
• 状态机图的作用
  • 清晰的描述了状态之间的转换顺序
  • 清晰的事件顺序有利于程序员在开发程序时避免出现事件错序的情况
  • 清晰的描述了状态转换时所必须触发的事件、监护条件和动作等影响转换的因素
  • 通过判定可以更好的描述工作流因为不同条件发生的分支

10.2 状态图的组成

10.2.1 简单状态

1. 状态的基本概念

• 对象在任何时候都会处于某种状态中，所有对象都有状态
• 对象所处的状态决定了它如何响应所检测到的事件或所接收的消息
• 通常，事件使对象从一个状态转向另一个状态（即状态的转换）

2. 状态的表示

• 状态名(name)
  • 给对象所处状态取的名字，用一个字符串表示的唯一标识符
• 入口动作(entry action)
  • 当进入状态时，入口动作执行
  • 通常用来进行状态所需的内部初始化
  • 格式：entry/进入动作
• 出口动作(exit action)
  • 状态退出时执行出口动作
  • 格式：exit/退出动作
• 内部活动(internal action)
  • 处于该状态时执行的需要一定时间且可以中断的工作
  • 格式：do/活动名
• 内部转换(internal transition)
  • 只有源状态，没有目标状态，不会执行entry和exit动作
  • 不导致状态改变的转换
  • 格式：event 事件名(参数)[监护条件]/动作

3. 状态的类型

• 初始状态
  • 初始状态代表状态机图的起始位置
  • 初始状态是一个伪状态
  • 对象不可能保持在初始状态，必须有一个输出的无触发转换
  • 只能作为转换的源，不能作为转换的目标
  • 初始状态在一个状态机图中只允许有一个
  • 嵌套状态中可以使用新的初态
• 终止状态
  • 终止状态代表状态机图的终止点
  • 对象可以保持在终止状态，但不可能有任何形式的触发转换
  • 只能作为转换的目标，不能作为转换的源
  • 终止状态在一个状态机图中可以有0到多个
• 组成状态(Composite State)
  • 组成状态是内部嵌套有子状态的状态
  • 组成状态可以具有初始状态和终止状态
• 历史状态(History State)
  • 记录组成状态退出时所处的子状态，以便再次进入从这个状态开始工作
  • 浅历史：记忆同级别的最后子状态
  • 深历史：记忆所有级别的最后子状态

10.2.2 转换

1. 转换的基本概念

• 转换用于表示一个状态机的两个状态之间的一种关系
• 对象将在第一个状态中执行一定的动作，并在某个特定事件发生且满足特定条件时进入第二个状态
• 在这个状态变化中，转换被称作激发

2. 转换的表示

（1）源状态和目标状态

• 对于一个转换来说，转换前对象所处的状态，就是源状态
• 转换完成后，对象所处的状态就是目标状态
• 源状态和目标状态都是相对某个转换而言的

（2）监护条件

• 监护条件是一个布尔表达式，它是触发转换必须满足的条件
• 如果转换没有监护条件，则默认为真
• 监护条件的值只在事件被处理时计算一次

（3）触发事件

• 事件是外部作用于一个对象，能够触发对象状态改变的一种现象

• 事件可以是系统的内部事件，也可以是外部事件

• 外部事件是在系统和它的参与者之间传送的事件，内部事件是在系统内部的对象之间传送的事件。

• 如果箭头上不带任何事件名，表示是一个自动转换，当与源状态相关的活动完成时就会自动触发。
  

• 信号事件(Signal Event)

  • 一个对象对发送给它的信号的接收事件，可能会在接收对象的状态机内触发转换
  • 信号是一种异步机制
  • 信号是可以泛化的

• 调用事件(Call Event)

  • 一个对象对调用的接收，这个对象利用状态的转换而不是利用固定的处理过程实现操作
  • 调用是一种同步机制

• 改变事件(Change Event)

  • 依赖于特定属性值的布尔表达式所表示的条件满足时，事件发生改变
  • 语法格式：When(表达式)
  • 注意改变事件与监护条件的区别
  • 隐含一个对条件的连续的测试

• 时间事件(Time Event)

  • 表示时间表达式被满足的事件，代表时间的流逝
  • 绝对形式：after(11:00)
  • 相对形式：after(2 seconds)

• 延迟事件(defer Event)

  • 该事件不会触发状态的转换
  • 当对象处于该状态时事件不会丢失，但会被延迟执行
  • 直到对象进入一个不再需要延迟这些事情并需使用其状态时，延迟事件才会发生
  • 语法格式：延迟事件/defer

（4）动作

• 当转换被激活后，如果定义了相应动作，则执行该动作
• 动作一般是一个简短的处理过程
• 动作是原子性的，因此不可中断
  

3. 转换的类型

（1）外部转换

• 对事件做出响应，引起状态变化或自身转换，同时引发一个特定动作
• 语法：[event] 事件(参数)[监护条件]/动作
• 内部转换的激发可能会掩盖使用相同事件的外部转换
  

（2）内部转换

• 对内部事件做出响应，并执行一个特定的活动
• 但不引起状态变化或进入、退出转换
• 语法：event 事件(参数)[监护条件]/动作
• 常用于对不改变状态的插入动作建模
  

（3）进入转换和退出转换

• 进入|退出转换是当进入|离开某一状态时，执行相应的动作
• 语法：
  • entry/动作
  • exit/动作
    

（4）自转换

• 源状态和目标状态为同一状态的转换
• 内部转换与自转换的区别：
  • 内部转换不导致状态改变的转换，不会执行entry和exit动作
  • 自转换会引起entry和exit动作的执行
• 自转换属于外部转换
• 没有明确标明触发器事件的转换，是由状态中活动的完成引起的
• 也可包含监护条件，在状态中的活动完成时被赋值
  

（5）自动转换

• 没有明确标明触发器事件的转换，是由状态中活动的完成引起的
• 也可包含监护条件，在状态中的活动完成时被赋值
  

（6）复合转换

• 由简单转换组成，通过分支和合并将简单转换组合起来
• 可具有多个源状态和多个目标状态
  
  4. 转换实例
  

10.2.3 伪状态

10.3 复合状态

10.4 状态机图の高级概念

1. 分支

• 在外部事件的作用下，根据监护条件的不同值，转向不同的目标状态
• 根据监护条件的真假可以触发不同的分支转换
• 共享同一触发器事件但有着不同监护条件的转换能够在模型中被分在同一组中
  
• 分支和合并仅仅是一种表示上的方便，使用与否不影响转换的语义。
  

2. 同步

• 同步是为了说明并发工作流的分支与汇合
• 并发分支：把一个单独工作流分成两到多个并行进行的分支工作流
• 并发汇合：两到多个并发工作流得到同步
  

3. 组成状态

• 基本概念
  • 子状态：被嵌套在另外一个状态中的状态
  • 组成状态：内部嵌套有子状态的状态
  • 组成状态可以具有初始状态和终止状态
    
• 顺序组成状态
  • 组成状态通过“或”关系分解为互相排斥的顺序子状态
  • 在其包含的多个直接子状态中，当组成状态被激活时，只有一个子状态会被激活
  • 顺序组成状态只包含一个状态机
    
  • 最多可以有一个初始状态
  • 当状态机通过转换进入组成状态时，一个转换可以以组成状态为目标，也可以其子状态为目标
    
    
• 并发组成状态
  • 组成状态通过“与”关系分解为并发子状态
  • 如果一个状态机被分解成多个并发的子状态，则代表其控制流也被分解成与并发子状态数目相同的并发流
  • 并发组成状态包含两个或者多个并发的子状态机
    
• 进入状态后存在分支，子状态机开始并发执行
• 如果所有子状态机都有一个终止状态，在所有子状态机结束之前不能离开超状态，称为合并
• 如果子状态机显式地迁移到外部状态，那么离开超状态时就无须合并
  
• 子状态机通信
  • 子状态机之间通信可以借助于监护条件、状态间的事件来描述
    - 表示法
  • 将子状态机嵌入表示状态的圆角矩形中
  • 在圆角矩形中加入分解指示符
    
• 历史状态(History State)
  • 记录组成状态退出时所处的子状态，以便再次进入从这个状态开始工作
  • 浅历史：记忆同级别的最后子状态
  • 深历史：记忆所有级别的最后子状态
    
  • 当状态机通过转换从某种状态转入组成状态时，被嵌套的子状态机一般要从子状态机的初始状
  • 开始执行，除非转到特定的子状态
  • 使用历史状态，可以存储目前退出组合状态时所处的子状态，则返回组合状态时可以直接回到相应的子状态。
  • CD Player，running状态被打断到power on状态，再转回到running状态时，希望直接进入历史状态

10.4 状态图的建模技术

1. 寻找主要状态

• 对于航班机票预订系统，将机票看成一个整体，考察包含的状态：
  • 无预订
  • 部分预订
  • 预订完
  • 预订关闭
  • 已取消
• 可能有的外部事件：预订()、退订()、关闭()、取消航班()

2. 确定状态间转换

3. 细化状态内的活动与转换

• 添加内部转换、进入和退出转换及相关活动
  

4. 将简单状态机图转换为组成状态机图

5. 状态机图应用说明

• 对对象生命周期建模
  • 主要描述对象能够响应的事件、对这些事件的响应以及过去对当前行为的影响
• 对反应型对象建模
  • 主要描述对象可能处于的状态、从一个状态转换到另一个状态所需的触发事件，以及每个状态改变时发生的动作或活动
• 状态机图在不同阶段的应用
  • 既可以用来表示一个业务领域的知识，也可以用来描述设计阶段对象的状态变迁

第十一章 活动图

11.1 活动图基本概念

1. 活动图的定义

• 活动图描述一系列具体动态过程的执行逻辑，展现活动和活动之间转移的控制流
• 记录单个操作或方法的逻辑、单个用例或商业过程的逻辑流程

2. 活动图的作用

• 描述一个操作执行过程中所完成的工作，说明遵循的规则
• 对业务过程、工作流和用例实现进行建模
• 描述复杂过程的算法

3. 活动图与流程图的区别

• 流程图着重描述处理过程，而活动图着重体现系统的行为
• 活动图是面向对象的，而流程图是面向过程的
• 活动图能够表示并发活动的情形，而流程图不能

4. 活动图与状态图的区别

• 活动图着重表现从一个活动到另一个活动的控制流，是内部处理驱动的流程
• 状态图着重描述从一个状态到另一个状态的流程，主要有外部事件的参与
• 活动图主要目的是描述动作及对象的改变结果，不需要任何触发事件
• 状态图描述对象、子系统、系统在生命周期中的行为
• 活动图的动作可以放在泳道中

11.2 活动图组成元素（看书了解）

11.2.1 动作和活动节点

• 动作状态（动作结点）
  • 动作状态是构造活动图的最小单位，表示原子动作
  • 动作状态是不可中断的
  • 动作状态是瞬时的行为，占用处理时间短
  • 动作状态可以有转入，至少有一个转出
  • 动作状态不能有入口动作、出口动作和内部转换
  • 在一张活动图中，动作状态允许多处出现
• 活动状态（活动结点）
  • 活动状态是非原子性的，可以分解成其他子活动或动作状态
  • 活动状态是可以被中断的
  • 活动状态的内部活动可以用另一个活动图表示
  • 活动状态至少有一个转出
  • 活动状态可以有入口动作、出口动作和内部转换
  • 动作状态是活动状态的一个特例

11.2.2 开始和终止

• 初始状态和终止状态
  • 状态：在对象的生命周期中满足某些条件、执行某些活动或等待某些事件时的一个条件或状况
  • 初始状态：标记活动图的开始，表示事情处理过程的开始
  • 终止状态：标记活动图的结束，表示事情处理流程完成

11.2.3 控制流

11.2.4 判断节点

11.2.5 合并节点

11.2.6 泳道

为了对活动的职责进行组织而在活动图中将活动状态分为不同的组，成为泳道
“泳道”技术用于描述每个活动是由哪个对象负责完成
每个活动只能明确地属于一个泳道
转换、分叉、结合和对象流允许跨越泳道
分支只属于一个泳道

11.3 活动图的高级概念（看书了解）

11.3.1 并发

11.3.2 分叉结点

11.3.3 结合节点

11.3.4 对象流

11.3.5 扩展区域

11.4 活动图建模技术

11.5 活动图的进一步说明

第十二章 组件图

12.1 组件图的基本概念

1. 构件图定义

• 构件图是用来表示系统中构件与构件之间、类或接口与构件之间的关系图

2. 构件图作用

• 使系统人员和开发人员能够从整体上了解系统的所有物理部件
• 从软件架构的角度来描述一个系统的主要功能
• 方便项目组的成员了解系统的结构和功能
• 有利于软件复用

12.2 组件图的组成元素

12.2.1 组件

1. 构件(Component)的定义

• 构件是系统中可替换的物理部分，它封装了实现而且遵从并提供一组接口的实现
• 作为系统中的一个物理实现单元，包括软件代码或相应组成部分、带有身份标识并有物理实体的文件
• 作为系统定义良好接口的物理实现单元，它能够不直接依赖于其他构件而仅仅依赖于构件所支持的接口
• 构件的类型：
  • 《源代码件》:源程序文件块
  • 《执行件》：编译的结果，可投入运行
  • 《文件》：信息的存储体
  • 《库》：可以是类库、动态链接库、数据库等
  • 《表》：表示数据库中的数据表
  • 《文档》：泛指形成的所有文字材料

2. 构件的要素

• 接口声明：构件所提供服务的抽象描述
• 接口实现：实现了供给接口声明的服务
• 受约束的构件标准：在创建构件时，每一个构件必须遵从某种构件标准
• 封装方法：构件遵从的封装标准
• 部署方法：构件运行前需部署，一个构件可以有多种部署方法

3. 构件与类

• 共同点
  • 二者都有名称
  • 都可以实现一组接口
  • 都可以参与依赖、泛化和关联关系
  • 都可以被嵌套
  • 都可以有实例
  • 都可以参与交互
• 区别
  • 类表示逻辑的抽象，而构件表示存在于计算机中的物理抽象
  • 构件是可以部署的，而类不可以
  • 构件表示的是物理模块而非逻辑模块，与类处于不同的抽象级别

4. 构件分类

• 部署构件(Deployment Component) ：组成系统的基础构件，是执行其它构件的基础平台
• 工作产品构件(Work Product Component) ：开发过程的中间产物
• 执行构件(Execution Component)：在运行时创建的构件

12.2.2 构件的表示

1. 构件表示法

• 构件包含两个部分：接口和接口实现部分
• 接口是一组用于描述类或构件的某个服务的操作
• 构件的接口分为两种类型：供给接口和需求接口
• 在构件图中，构件可以通过其它构件的接口来使用其它构件中定义的操作

2. 没有标识接口的构件表示法

• 表示为标有构造型<>的矩形
• 在矩形的右上角放置一个构件图标
• 直接使用构件图标

3. 标识接口的构件表示法

4. 构件的构造型

• 《executable》，可执行构件(编译的结果，可投入运行)，如exe文件。
• 《library》，库构件(类库、动态链接库等)，如dll文件。
• 《database》，表示可执行文件访问的数据库构件，如mdb、mdf文件。
• 主程序(Main Program)：指定系统入口
• 子程序规范(subprogram specification)和子程序体(subprogram body)
• 包规范(package specification)和包体(package body)：将源文件中声明文件与实现文件分离开来
• 任务规范(task specification)和任务体(task body)：表示拥有独立控制线程的构件的规范和实现体
• 数据库(DataBase)
• 虚包(Generic Package)：提供一个包的某些内容的公共视图

12.2.3 组件图中的关系

1. 构件间的依赖关系

• 一个构件如果使用另外一个构件的操作，则可以在该构件和另外一个构件的接口间建立依赖关系
  • 两个构件中的类如果存在泛化关系，则构件间可以加依赖
  • 两个构件中的类如果存在使用（依赖或关联）关系，则构件间可以加依赖
    

2. 组件与接口的关系

12.2.4 组件图の分类

1. 简单构件图

• 将相互协作的类，组织成一个构件
  

2. 嵌套构件图

• 使用嵌套的构件图来表示构件的内部结构
  

12.3 组件图的建模技术

1. 简单构件图的创建

• 确定系统构件
• 将系统中的类和接口等映射到构件中
• 确定构件的依赖关系

2. 嵌套构件图的创建

• 确定子系统对外的接口
  • 首先需要提供用户界面
  • 其次还需要与加盟的酒店系统连接，完成预订工作
• 确定子构件和接口

第十三章 部署图

13.1 部署图的基本概念

• 部署图(Deployment Diagram)是一种用于显示系统中软件和硬件物理架构的图。
• 部署图描述内容：
  • 在实际应用中软件及其运行环境的关系
  • 软件在硬件上的分布情况及部署在硬件上的具体方式
• 一般一个系统仅有一个部署图

13.2 部署图的组成元素

13.2.1 节点

• 结点(Node)又译作为“节点”，代表一个运行时计算机系统中的硬件资源或物理元素
• 一般都拥有内存，而且具有处理能力
• 结点名称的表示方法
  • 简单名称(Simple Name)
  • 受限名称(Qualified Name)
  • 包名+简单名称
    
• 分类
  • 处理器(Processor)：是指具有处理能力的结点
  • 设备(Device)：是本身不具备处理能力的结点，一般通过其接口为外部提供某些服务

13.2.2 构件(Component)

• 构件：系统中可替换的物理部分
• 遵从并提供对一组接口的实现
• 结点包含内容的描述形式：
  • 直接描述：不是由开发团队生成的制品
  • << artifact >>构造型：表示文件、构件等由开发团队生成的制品，制品是存在于实现平台层的系统的物理部分
  • << database >>构造型：表示一个数据库实例
    

13.2.3 连接(Connection)

• 表示两个结点之间的物理连接
• 包括直接连接和非直接连接两种方式
  

13.3 部署图建模技术

• 确定系统中的结点
• 确定结点间的关系
• 部署、映射结点上的构件，分析和确定构件间的关系
• 对建模的结果进行精化和细化
  ​