# 软件工程与面向对象方法

# 软件工程

软件的定义：软件是我们使用硬件设备的桥梁。我们可以把软件理解为，由程序、数据和文档构成的集合体

程序是能够完成预定功能和性能的一组计算机指令
数据是程序在执行过程需要输入、处理和输出的内容和结构
文档是描述程序设计和使用的部分

软件工程的定义：软件工程（software engineering）是指应用计算机科学技术、数字和管理学的原理，运用工程学的理论、方法和技术，研究和知道软件开发和演化的一门交叉学科。

软件工程的三个主要方面：

软件工程目标
软件工程过程
软件工程的四条原则

软件工程的四条原则：

开发模型
开发方法
工程支持
工程管理

# 软件工程的历史

20 世纪 60 年代以前，软件 “个体生产方式”
20 世纪 60 至 70 年代，软件奇数取得了很大的进展。软件应用的需求变多，规模变大，复杂程度变高。
软件的生产方式满足不了社会对软件的需求，最终导致 “软件危机” 的开始。
1968 年，在北大西洋公约组织举行的一次学术会议上，首次提出了 “软件工程” 的概念。

# 软件危机

定义：在计算机软件开发和维护中所遇到的一系列严重问题。

造成软件危机的主要原因：

用户需求不明确
软件本身的复杂性
软件维护和开发方法不正确

造成软件危机的主要表现：

软件开发周期大大超过规定日期
软件开发成本严重超标
软件价格昂贵
软件可维护性差
软件质量难于保证

# 软件建模

定义：建模时构建模型的过程。是一项经过检验并被广为接受的工程技术

目的：建模可以更好的理解正在开发分系统

建模原理

选择合适的模型
可以在不同的精度级别上表示每一种模型
最好的模型与显示相联系的
LOREM IPSUM

普遍的建模方法

从算法的角度建模
从面向对象的角度建模

# 面向对象

# 面向对象方法简介

定义：面向对象是基于对象概念，以对象为中心，以类和继承为构造机制，来认识、理解、刻画客观世界和设计、构建相应的软件系统。

面向对象技术：是一种以对象为基础，以事件或消息来驱动对象执行处理的程序设计技术。

软件开发过程各阶段所应用的面向对象技术

面向对象的方法
面向对象的分析
面向对象的设计
面向对象的编程

# 面向对象发展历史

20 世纪 50 年代后期，ALGOL 语言首次提供封装（保护）的尝试。
1967 年，Simula 语言提出了对象的概念，并使用类，也支持类继承。第一门面向对象的编程语言。
20 世纪 70 年代，Smalltalk 语言诞生，它取 Simula 的类为核心概念。
1980 年，Xerox 公司推出商品化的 Smalltalk80，它在系统设计中强调对象概念的统一，引入对象、对象类、方法、示例等概念和术语，采用动态联编和单继承机制。
20 世纪 80 年代至 90 年代 Objective C、C++、Eiffel 和 CLOS 等语言大量涌现。C++ 语言的广泛应用，使得面向对象技术真正的从实验室阶段走到了商业化阶段。面向对象的软件工程迅速发展。
1986 年在美国举行了首届 “面向对象编程、系统、语言和应用（OOPSLA'86）” 国际会议，使面向对象受到世人瞩目。

# 面向对象方法的概念

# 对象

定义：客观世界中的事物都是对象（object），是一个属性（数据）集及其操作（行为）的封装体。

三大分类：

客观对象：现实中的实体
问题对象：抽象客观对象某些属性和方法来研究某个问题或场景中的性质
计算机对象：问题对象通过封装等过程称为计算机中的一个包含有数据和操作的集合体

四个特性：

自治性
封闭性
通信性
被动性

# 类

定义：类是对象的模板。即类是对一组有相同数据和相同操作的对象的定义，一个类所包含的方法和数据描述一组对象的共同属性和行为。

对类四个角度的理解

类是面向对象程序中的构造单位
类是面向对象程序设计语言的基本成分
类是抽象数据类型的具体表现
类刻画了一组相似对象的共同特性

# 抽象

揭示一个事物区别于其他事物的本质特征，是从去除某一个角度看来不重要的细节行为。

# 封装

是一种信息隐蔽技术，对用户隐藏对象的属性和实现细节，仅对外公开接口，并控制在程序中属性的读和修改的访问级别。

# 独立

指对象是一个不可分割的整体，它继承了事物全部的属性和操作，并且它的存在不依赖于外部事物。

# 封装

定义：指与外部的事物通信时，对象要尽量地隐藏其内部的实现细节，它的内部信息对外界来说是隐蔽的，外界不能直接访问对象的内部信息，而只能通过有限的接口与对象发生联系。

功能

将对象的属性和行为结合成一个独立的单位。
隐蔽对象的内部细节，防止数据遭到破坏。

# 泛化

定义：是类元的一般描述和具体描述之间的关系。

实现泛化关系的机制为继承。
继承性实现了软件模块的可重用性、独立性，缩短了开发周期，提高了软件开发的效率，同时使软件易于维护和修改。

多态

定义：指相同的操作可作用于多种类型的对象上并获得不同的结果。

多态的前提是继承。
实现多态的二种方式：覆盖，重载。指相同的操作可作用于多种类型的对象上并获得不同的结果。

# 面向对象技术的优点

更符合人类的思维习惯。
提高软件稳定性。
提高代码的复用率。

# UML

# UML 的简介

定义：统一建模语言，是对软件密集型系统中的制品进行可视化、详述、构造和文档化的语言。

UML 是一种可视化的语言
UML 是一种用于构造的语言

# UML 的历史

“方法大战”：

Booch: 在项目的设计和构造阶段的表达力极强。
OMT: 对分析和数据密集型信息系统最为有用。
OOSE: 对以用例驱动需求获取、分析和高层设计的开发过程提供了极好的支持。

早期方法统一的尝试：Fushion 方法，结合了 OMT、Booch、CRC

UML 的发展阶段：

1996 年 6 月，三位创始人发布 UML 0.9。
1997 年 11 月，OMG 正式采纳 UML 1.1 作为建模语言规范。
2005 年 7 月，最终的 UML 2.0 规范发布。
2012 年，UML 2.4.1 被 ISO 正式确定为国际标准

UML发展阶段

UML2 的重大改变

大部分的类元都可以嵌套
行为建模进行了改进
改善了结构模型和行为模型之间的关系

# UML 的目标与应用范围

# UML 的目标

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

# UML 的应用范围

UML 以面向对象的方式来描述系统
在需求分析阶段，可以通过用例捕获需求

# 初识 UML

# UML 构造块

构造块（building block):UML 基本建模元素。

构造块的类型：

事物（things): the abstractions of first-class citizens in a model．
关系（relationships):tying the things together
图（diagrams): grouping interesting collections of things

# 事物

事物：是对模型中关键元素的抽象。描述的是关键部件。
事物分为：结构事物、行为事物、分组事物、注释事物。

# 结构事物

概念：描述模型的静态结构
结构事物的分类：

# 类

图形为多层矩形
包括：

类名
属性
方法

# 接口

图形为多层矩形
包括：

接口名
方法

# 协作

表示多个元素间的交互动作
图形为虚线椭圆
包括：协作名称

# 用例

图形为实线椭圆
包括：动作名称

# 组件

封装好的模块化部件，仅将外部接口暴露出来
图形为矩形框＋两个小矩形
包括：组件名称

# 结点

物理元素名称，如计算机资源
图形为立方体
包括：结点名称

# 行为事物

概念：描述模型中的动态元素，又称为动作事物。

行为事物分类：

交互（Interaction)：对象间消息交换的行为，或为完成指定目标而设置的相关规则。包含消息、状态和连接。
状态机（state machine)：对象在生命周期内的状态序列及转移规则。包含状态、转移、条件（事物）和活动。
活动（activity)：一个计算过程包含的动作（action）序列。

# 交互

图形为实箭头，从发出者到接收者
包括：操作名称

# 状态机

图形为圆角矩形
包括：状态名称

# 活动

表示操作的过程信息
图形为圆角矩形
包括：活动名称

# 分组事物

描述模型中的组织结构，用于组织设计本身，而非组织构建（constructs)。
分组事物包括：包（packages)、子系统 (subsystems)、层（layers)。

# 包

图形为小矩形＋大矩形
包括：

名称
包含的元素

# 注释事物（annotation things)

模型中的注解元素，用于描述、说明和标注任何模型元素。
注解（notes)：是最主要的注释事物实例，是对单个或一组元素进行约束或解释的文本。

# 关系

关系是模型元素之间具体化的语义连接。

# 关联关系

描述一个事物的对象与另一个事物的对象的联系，表示一种结构关系。关联关系包括聚合和组合。

# 聚合（aggregations)

概念：整体与局部的包含、从属关系。在 UML 中使用带空心菱形的实心线表示，菱形指向整体。

# 组合（composition)

概念：强依赖的特殊聚合关系。在 UML 中带使用实心菱形的实线表示，菱形指向整体。

# 依赖关系

一个元素（independent element）的变化影响另一元素的语义。

依赖关系代表：

带箭头的虚线，箭头指向被使用者。
表示一种使用的关系。

# 泛化关系

描述特殊到一般的归纳和分类关系。

泛化关系代表：

带三角箭头的实线，箭头指向父类。
继承关系（inherit)：指定了子类如何特化父类的所有特征和行为。

# 实现关系（realization):

一个元素定义规格说明，另一元素按照规格具体实现。

实现关系代表：

带三角箭头的虚线，箭头指向接口。
接口与实现接口功能的类或组件。
用例与实现该用例的协作

# 图（diagram)

一组模型元素的图形化表示，一般由事物与各种关系构成。

图的类型：

结构图：捕获事物与事物之间的静态关系，用来描述系统的静态结构模型。

行为图：捕获事物的交互过程如何产生系统的行为，用来描述系统的动态行为模型。

UML1.4	UML2	对比说明
	包图	用于展示由模型本身分解而成的组织单元以及他们的依赖关系，展示了软件系统的分层结构。
状态图	状态机图	只是名称不同，技术上完全相同。
活动图	活动图	UML2 的活动图独立于状态机存在。
	组合结构图	显示结构化类元或协作的内部结构，和普通类图之间没有严格界限。
	外廊图	展示构造型、元类等扩展机制的结构。
协作图	通信图	UML2 中多用更加精确的通信图来代替协作图的大部分功能。
	交互概览图	活动图的变体，合并了序列图片段和控制流构造。
	时间图	是一种特殊的序列图形式，显式地表示了生命线上的状态变化和标度时间。

# 通用机制

作用：用于对建模元素进行补充，从而完善 UML 的语义表达。

建模可以遵循不同的模式 —— 建筑具有不同的风格。
模型的 “风格” 与 “模式” 必须进行补充语义说明。

UML 提供四种通用机制：规格说明、修饰、通用划分、扩展机制

# 规格说明 (Specifications):

概念：文本维度的模型描述。

规格说明使可视化视图和文字视图的分离。
规格说明通常不在图中直接显示，而是通过工具来获得。

# 修饰 (Adornments)

描述建模元素的细节信息。

修饰是对规格说明的文字的或图形的表示。

# 通用划分 (1CommonDivisions):

建模时对事物的划分方法。是一种保证不同抽象层次建模的机制。

通用划分的类型：

类型与实例、接口与实现、用例与协作、类型与角色。

# 类型－实例 (type-instance)

通用描述与某个特定元素的对应。

类型：通用元素。
实例：特定元素。
例：类／对象、用例／场景、组件／组件实例、节点／节点实例

# 接口－实现 (interf aces-imp I e mentati on)

强制规范与实现的对应。

接口：声明了服务的约定，行为的契约。
实例：负责执行接口的全部语义井实现该项服务。
例：接口／类、用例／协作、操作／方法

# 扩展机制 (Extensibility Mechanisms)

类型：

构造型 (stereotype) : 基千已有的建模元素引入新的建模元素。
标记值 (tagged value) : 扩展 UML 构造型的特性，可以用来创建构造型的详述信息。
约束 (constraint) : 扩展 UML 构造块的语义，可以用来增加新的规则或修改现有的规则。

# 构造型

将一个已有的元素模型进行修改或精化，创造出一种新的模型元素。
构造型的信息内容和形式与已存在的基本模型元素相同，但拥有不同的含义与用法。
表示方法：一个双尖括号内附构造型名称，一般放在已有的基本模型元素符号上方。

# 标记值

关于模型元素本身的一个属性的定义，即一个元属性的定义。是用来为事物添加新特性、新信息。

标记定义被构造型所拥有。标记可以用来存储元素的任意信息，它是一个名称－值组合，表现为形如 “property = value" 的字符串形式。

# 约束

使用某种文本语言中的陈述句表达的语义条件或者限制。是施加在元素上的限制。

约束包括一个约束体与一种解释语言。
约束使用大括号｛｝中的文本串表示。
若要精确地详述约束，可以使用 UML 的对象约束语言 (ObjectConstraint Language , OCL) 来表达。

# "4+'1" 架构

# "4+'1" 架构的概念和组成

组成：

逻辑视图 (LogicalView)
过程视图 (ProcessView)
物理视图 (PhysicalView)
开发视图 (DevelopmentView)
场景视图 (ScenariosView))

概念：

RUP 统一软件开发过程，是一个面向对象且基于网络的程序开发方法论。RUP 是 Rational 软件公司创造的软件工程方法，后来 Rational 公司被 IBM 井购。
"4+1" 架构方法采用用例驱动，在软件生命周期的各个阶段对软件进行建模，从不同视角对系统进行解读，从而形成统一软件过程架构描述

# 逻辑视图 (L1og'ic View)

主要用来描述系统的功能需求，反应出系统内部是如何组织和协作来实现功能的，不涉及具体的编译即输出和部署。

主要对应 UML 中的类图和对象图。

构件：类、类服务、参数化类。
连接件：关联、包含、使用、继承、实例化。

# 开发视图（Development/Module View）

主要用来描述软件模块的组织与管理（通过程序库或子系统）。

主要对应 UML 中的组件图。

・构件：模块、子系统、层。
・连接件：参照相关性、模块／过程调用。

# 进程视图 (Pro1cess'View)

主要描述系统的运行特性，侧重系统的性能和稳定性，主要关注进程、线程、对象、井发、同步、通信等运行时概念。服务千系统集成人员，方便后续性能测试。

主要对应 UML 中的顺序图、协作图、状态机图。

构件：进程、简化进程、循环进程。
连接件：未指定，消息、远程过程调用 (RPC) 、双向消息、事件广播。

# 物理视图 (Physicalview)

主要描述硬件配置。服务千系统工程人员，解决系统的拓扑结构、系统安装、通信等问题。

主要对应 UML 中的部署图。

构件：处理器、计算机、其它设备。
连接件：通信协议。

# 场景视图（Scenarios View）

用于刻画构件之间的相互关系，将四个视图有机地联系起来。

主要对应 UML 中的用例图和活动图。

构件：用例、活动等。
连接件：关联、泛化、依赖等。

# 视图间的关系：

逻辑视图，设计的对象模型（使用面向对象的设计方法时）。
进程视图，捕捉设计的井发和同步特征。
物理视图，描述了软件到硬件的映射，反映了分布式特性。
开发视图，描述了在开发环境中软件的静态组织结构。
场景视图，描述最终用户需求，为整个技术架构的上线文环境。

# 运用 “4+1” 架构

步骤

分而治之，其策略有分层法、模块法等。
对于模块化而言，对于每个模块实行不同的较为单一的操作，透明化模块内部的信息，是一种重要的方法论。
“4+1” 视图方法是一种架构设计的多重视图方法，属于一种特殊的模块法。

"4+1" 视图方法特点有：用例驱动、以架构为中心、迭代和增量过程。

首要问题：需求
首要问题：需求

# 场景视图

场景视图是根据用户的需求可以直接产生和描述，它是与需求关系最紧密的视图。

# 逻辑视图

找到场景中的所有关键交互；
使用软件术语描述出交互逻辑，注意一些场景可能是基千事件的；
设计一些更下层的元素，这些元素的合理组合可以最终实现这个场景。

# 开发视图

开发视图关注各种程序包的使用，进程视图关注运行时概念，物理视图关注程序和运行库、软件系统对物理机器的要求和配合方式。

# 用例图

# 用例图简介

表现一个系统中用例、参与者以及它们之间关系的图。
用例图＝参与者＋用例＋关系。
用例图是系统的蓝图。它从用户的视角来描述和建模整个系统，分析系统的功能与行为。

用例图主要回答

谁在使用软件系统。
软件系统提供了什么祥的功能。
用例图侧重千表示系统向外界提供哪些功能与服务，而非具体实现。
作为整个系统开发过程中的开发依据，用于指导和驱动其它模型。

用例图的功能与作用

描述系统环境（上下文）：确定系统边界、参与者。
捕获井描述用户需求：确定用例、用例与参与者间关系。

# 用例图的组成元素

用例图主要由参与者、用例、关系构成，还可以有注解、约束以及包。

# 参与者（actor/role）

参与者是与系统主体交互的外部实体类元。参与者以某种方式参与系统中若干用例的执行，体现了用户对系统功能的使用。

参与者处千系统边界之外，不作为系统的一部分。
参与者是客观世界中人或事物的抽象。

# 确定参与者

作用：通过对参与者进行分析，可以步的确定系统边界。

# 参与者的确定：从类别角度

为系统提供输入／输出的人或物；
需要接入的第三方系统或设备；
触发系统事件的因素（时间）；
负责支持／维护系统的人员。

# 参与者的确定：从角色角度

主要业务参与者：用例执行中的获益者。
主要系统参与者：用例的直接交互者。
外部服务参与者：对用例请求的响应者。
外部接收参与者：用例产出信息的非主要关联人员。

# 系统边界

界定系统的功能范围。

系统用一个长方框表示，边几位系统边界，系统的名字写在方框上或方框里面。

# 用例（use case）

也称为用况：是系统提供的一个内聚的功能单元或服务；该单元对应一组动作序列的执行，井向参与者提供可观测的结果。

用例表示：实线椭圆形。名称在椭圆中。
用例命名方式：简单命名和受限命名。

用例的作用：

捕获和描述用户需求。用例描述目标系统的应用场景，进而捕获和、描述用户需求。
定义系统的行为。用例定义系统的行为，表示系统所提供的服务。但不涉及内部结构与实现细节。
用例是外部观察者 “看到 “的系统服务，而非内部观察者定义的功能。

# 用例与参与者

用例与参与者之间存在关联关系。
一个用例可以隶属一个或多个参与者，一个参与者也可以参与一个或多个用例。

通过参与者入手来寻找用例：

参与者的主要任务是什么？
参与者需要系统的什么信息？
参与者可以为系统提供什么信息？
系统需要通知参与者发生的变化和事件吗？
参与者需要通知系统发生的变化和事件吗？

用例的特征

用例是动宾短语。
用例是相对独立的。
用例是由参与者启动的。
用例要有可观测的执行结果。
一个用例是一个单元。

用例的特征保证用例能够正确地捕捉功能性需求，同时也是判断用例是否准确的依据。

用例的粒度 (granularity) : 用例组织信息的方式和细化程度。
原则：业务建模阶段：每个用例对应一个完整的服务。

概念建模阶段：每个用例对应一个完整的事件流。如第二个图， “修改个人信息” 的粒度相对粗。
系统建模阶段：每个用例对应一个完整的交互。如第一个图，“修改密码 “的粒度相对细致。

参与者的泛化关系：

当系统中的几个参与者既扮演自身的角色，同时也有更一般化的角色时，可以通过建立泛化关系来进行描述。
如果父参与者是抽象的，可以用斜体表示，这是父参与者必须明确相应的子参与者。

参与者与用例间的关联关系：参与者与用例间的信息交互（消息、调用）。

用例间关系：

泛化 generalization)
依赖 (depende1ncy)

用例间的泛化关系 (generalization)

子用例继承父用例的行为和属性，子用例可增加或替换父用例行为。
子用例的实例可替代父用例实例，父用例同样可以定义为抽象用例。

依赖（dependency ）

包含 (include)
扩展 (extend)

包含关系 (include)

一个用例（基用例）包含其他用例（包含用例）的行为。
基用例一定要使用包含用例，而且是无条件的使用。
包含关系用千描述复用：多个基用例复用一个包含用例。
包含关系中，基用例与包含用例间有明显的整体 — 局部关系，不具有可替代性。

作用：
提供用例的利用率。
提高用例模型维护的效率。

扩展关系（extend）
一个用例（扩展用例）对另一个用例（基用例）行为的增强。

基用例对千扩展的存在不知情。
扩展用例的执行是有条件的。

扩展用例的使用包括：基用例、扩展用例、扩展关系、扩展点。

扩展点表示基用例中的一个或多个位置，表示在该位置会根据某条件来决定是否要中断基用例的执行从而执行扩展用例中的片段。

包含关系与扩展关系的区别

特征	include	extend
作用	增强基用例的行为	增强基用例的行为
执行过程	包含用例一定会执行	扩展用例可能被执行
对基用例的要求	在没有包含用例的情况下，基用例可以是也可以不是良构的	在没有扩展用例的情况下，基用例一定是良构的
表示法	箭头指向包含用例	箭头指向基用例
基用例对增强行为的可见性	基用例可以看到包含用例，井决定包含用例的执行	基用例对扩展用例一无所知
基用例每执行一次，增强行为的执行次数	只执行一次	取决于条件（0 到多次）

# 用例描述与文档

# 什么是用例描述

用例描述，通过文字详细的描述用例的细节内容，全面表达用户需求和系统功能。

用例描述的主要内容

用例名称
用例编号
参与者
用例描述
触发器
前置条件
基本事件流
扩展事件流
结论
后置条件
补充约束

用例描述的主要内容

用例名称：描述用例的意图或实现的目标。
用例编号：用例的唯一标识符，在其他位置可以使用该标识符来引用用例。
参与者：描述用例的参与者，包括主要参与者和其他参与者。
用例描述：对用例的一段简单的概括描述。
触发器：触发用例执行的一个事件。
前置条件：用例执行前，系统和参与者应处的状态，是用例得以执行的必要条件。
后置条件：用例执行结束后系统所处的状态，以及明确的结果（反馈给参与者）。

# 事件流

在特定场景下系统与参与者与交互过程的抽象，包括用例何时以及怎样开始和结束，用例如何与参与者交互，该过程的基本流和可选择的流。

事件流需要说明

用例因何开始、何时开始
用例何时与用户交互
用例与用户交换了什么信息
用例与外部交互的行为流程

分类

基本事件流
扩展事件流

# 基本事件流

用例中最核心的、大部分时间所进行的，最理想的执行场景。
"S-" 表示 subflow。

参与者将订单信息提交至系统。
系统验证用户信息及订单信息合法后作出响应。
对千订单中的每种产品，系统根据订单中的数昼检查产品库存数 m。 4 系统统计订单中产品的总价格。
系统从会员的系统账户余额中扣除相应金额。
系统生成井保存订单信息并将订单发送至分销中心。
系统生成订单确认页面井发送给会员。

# 可选事件流

记录基本事件流出现异常或变化时的用例行为。表示分支的、异常情况下的、备选的执行步骤。用 "A-" 表示。

A-2 如果订单信息非法，系统通知会员井提示重新提交订单。
A-3 如果订单中产品数量超过产品库存昼，则提示会员库存不足，暂无法购买，取消订单同时终止用例。
A-5 如果会员账户余额不足，系统给出相应提示，取消订单井终止用例。

# 结论与补充约束

补充约束：用来描述用例在系统功能之外的内容。

数据需求 (D -) : 用例相关数据项的说明
业务规则 (B -) : 业务相关的逻辑和操作规则
非功能性需求：性能、时效、稳定性等指标
设计约束：与后期分析、设计相关的一些约定

D-1 订单信息包括订单号、参与者的会员账户名、商品种类数量、商品种类名称以及每种商品的数量。
B-1 只有当订单中商品信息确认无误后才能要求会员进行支付。

# 使用用例图建模

对系统的用例视图建模方式

对系统的语境建模
对系统的需求建模

# 对系统的语境建模：

主要是为了说明参与者的身份、以及他所扮演角色的含义。

对系统的语境建模遵循的策略

识别系统边界。
识别参与者。
如果需要，将具有相同特征的参与者使用泛化关系加以组织。
如果需要，对某些参与者应用一个构造型以便加深理解。
识别参与者。针对某个参与者，考虑其期望系统提供的行为或与系统的交互。
提炼用例。将系统行为提炼成用例。
完善其他用例。分解用例中的公共行为与扩展行为。
创建用例图。如果需要，在用例图中添加一些注解或约束来陈述系统的非功能需求。

用例图构建需要注意以下要点：

用例图中应该只包含对系统而言必不可少的用例与相关参与者。
用例的名称不应该简化到使读者误解其主要语义的程度。
摆放元素时应尽量减少连接线的交叉，以提供更好的可视化效果。
组织元素时应使在语义上接近的用例和参与者在位置上也同样接近，便千读者理解用例图。
可以使用注解或给元素添加颜色等方式突出图中相对重要的内容。
用例图中不应该有太多的关系种类。

# 类图（class diagram）

# 类图的简介

类图是显示一组类、接口、协作以及它们之间关系的图。
通过系统中的类以及各个类之间的关系来描述系统的静态结构。

类图的功能与作用：

系统开发模型的核心模型。
实现系统功能的静态结构建模。
是通过正向和逆向工程构建可执行系统的基础。
* 正向工程：通过语言间的映射将模型转换为代码的过程。
逆向工程：通过语言间的映射将代码转换为模型的过程。

# 类图的组成元素

# 类

拥有相同属性、操作、方法、关系和行为（语义）的一组对象的抽象。

类的特征主要有三个

名称，由字符串进行唯一表示。
状态，由属性和关联来描述。
行为，由操作来实现。

# 类名

用千区别其他类的字符串，命名应来自问题域的词汇表。

简单名 (simplename)
限制名 (qualified name)

# 属性

描述了类的所有对象所共有的一些特性。表达了特性的实例可以取值的范围。

语法：可见性_opt 属性名 ⌊ : 类型⌋_opt 多重性。_opt ⌊= 初始值⌋_opt ⌊{特性}⌋_opt
可见性：访问范围 (public,protected,private,package/implementation)

属性名：属性的标识。
类型：决定属性所以可能取值的范围。
初始值：作为创建该类对象是这个属性的默认值。
多重性：数组。
特性：｛可变性的约束｝
可变 (changeable) 、单增 (addonly) 、冻结 (frozen) 。
例如： Pl: 3.14 {frozen}

# 操作 (operation&function)

由类定义，被类的任一对象请求的服务。

语法
可见性_opt 操作名⌊(参数列表）⌋_opt⌊: 返回类型⌋_opt⌊{特性｝⌋_opt

可见性：访问范围 (public,protected,private,package/implementation)。
操作名：操作的标识符。

参数列表：是一些按照顺序排列的属性定义了操作的输入。
返回类型：回送调用对象消息的类型。

特征：｛约束说明｝

抽象 (abstract) : 无实现。
叶子 (leaf) : 不能在派生类中重写此操作。
查询 (isQuery) : 不会改变系统状态。
顺序 (sequential) : 要求外部互斥访问该操作，不支持多控制流。
监护 (guarded): 被声明为监护特征的操作，可保证多控制流访问的顺序性（互斥）以及对象的语义正确及完整性（互斥性由外部线程间合作保证）。
并发 (concurrent): 操作是原子性的，支持多控制流井发访问（互斥性由类提供）。
静态 (static): 对同类多个对象，具有全局性（不区分具体对象）。

# 职责

职责是类的契约或责任。采用自由形式的文本表示，不是必须项目。主要说明类要负责的工作。

# 接口

是一个被命名的操作集合，用于描述类或组件的一个服务。

接口的特征

接口一般只有一些操作。
接口的所有内容都是公有的。
接口代表了一份契约，实现该接口的类元必须履行它。

接口的表述

表示为带有 <<interface>> 构造型的类。
表示为一个带名称的小圆圈。

供接口：表示类所提供的服务，表示为与类框连接的小圆圈。

接口由名称和操作构成

# 类图中的关系

关联
泛化
依赖
实现

# 关联

表示类元直接的链接 (link) 的抽象或类元间交互的抽象。

关联端：关联关系靠近被关联元素的端点。

二元关联：具有二个关联端的关联关系。

自关联：同一类的实例间的关联关系。

N 元关联：具有 N 个关联端的关联关系。

关联关系的表示：实线 +[箭头]

关联关系的内容：

名称：字符串，可选。
角色：关联端元素承担的职责。
多重性：关联端有多少对象与另一关联端的一个对象关联。
导航性：一个关联类对另一关联类信息传递的方向。
限定 (qualification): 给定一个关联端对象（受限对象），根据关联属性（限定符， qualifier) 确定另一关联端的一个或一组对象（目标对象）。是对属性的限制。
约束用来表示两个关联之间的关系。是对关联关系的限制。
约束表示：两个关联关系路径的虚线＋｛约束文字｝。

# 聚合（aggregation）

描述整体与部分关系的特殊关联。整体与部分间具有明确的导航特性。整体与部分是 ''has - a'' 关系。整体与部分的生存期无关。

聚合的表示：实线＋空心要形。

# 组合 (composition)

强聚合关联关系。

在某个时刻，局部对象只能属于一个整体对象。
整体对象与局部对象的生存期重合（相同或包含）。、
组合关系中的部分要完全依赖千整体。

组合表示为：实线＋实心要形。

# 泛化关系（generalization）

基于一般化元素 (parent) 而构建特化元素 (child) 的一种关系。

特化元素共享一般元素的结构与行为特征。

泛化的表示：使用空心三角形＋实线表示。箭头指向一般类。

泛化关系的特征

泛化是一种 "is a kind of" 关系。
子类对象可替代父类对象的任何出现，反之不成立。
传递性。
反对称性。

泛化关系的两种情况

单泛化是指每个类只能有一个父类；
多重泛化是指类可以有多个父类

# 依赖关系（dependency）

一个事物使用另一事物的信息或服务。

类图中的依赖关系主要描述一个类调用另一个类的操作，或以变量／参数的方式使用另一个类。

依赖的表示：使用虚线箭头表示。

对千类图而言，主要有以下需要使用依赖的情况：

使用者类向提供者类发送消息。
提供者类是使用者类的属性类型。
提供者类是使用者类操作的参数类型。

# 实现关系（realization）

类元间的一种语义关系：一个类元定义规范 (contact) , 另一类元负责实现。

实现关系的二种表示：

当接口元素以带构造型的类的方式表示时，用虚线三角形箭头表示。
当接口元素以小圆圈方式表示时，用实线表示。

# 类的高级概念

# 抽象类（abstract class）

不可实例化的类。当一些类聚于共同的属性和操作时，可定义抽象基类。
没有直接的实例。

抽象类表示：对类名添加 “斜体” 修饰。类的操作也有抽象性。

# 模板类（template）

模板又称为参数化元素，是对一类带有一个或者多个未绑定的形式参数的元素的描述。模板应用在类上时称为模板类。

对应概念： C++ 中的模板与 Java 中的泛型。

通过《 bind 》构造性的依赖关系表示从模板类创建新类。

# 关联类（association class）

具有类的特性的关联关系。

关联类具有关联和类二者的特性，它既可以关联类元素，也可以拥有属性和操作。

关联类表示：
一个类符号，井通过一条虚线连接到关联路径。

# 分析类

用千从业务需求向系统分析设计转化过程中的 “职责＂逻辑化（参见 MVC 开发模式）。

包括：
边界类、控制类、实体类。

边界类

用于对系统外部环境与其内部运作之间的交互进行建模的类。

控制类

对一个或多个用例所特有的控制行为进行建模的类。

实体类

用于对必须存储的信息和相关行为建模的类。

用户界面类：帮助与系统用户进行通信的类。
系统接口类：帮助与其他系统进行通信的类。
设备接口类：为用来监测外部事件的设备（如传感器）提供接口的类。
边界类：描述外部与系统内部交互的类；
控制类：控制其他类的类；
实体类：存储信息和相关行为的类。

# 应用类图建模

# 类图建模技术

类图用于对系统的静态设计视图建模。类图主要用千支持系统的功能需求，即系统提供给用户的服务。

常用方式

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

# 对系统词汇建模

识别用户或系统开发人员用千描述问题或解决问题的那些实体井抽象。可以使用基千用例分析的技术帮助用户发现这些抽象。
对千每个抽象，识别一个职责集。要明确地定义每个类，而且这些职责要在所有的类之间很好的均衡。
提供为实现每个类的职责所需的属性和操作。

# 对简单协作建模

识别要建模的机制。机制描述了正在建模的部分系统的一些功能和行为，这些功能起因于类、接口以及其他一些事物所组成的群体的相互作用。
识别元素及其关系。对于每一种机制，分别识别参与协作的类、接口和其他协作，井识别这些事物之间的关系。
用脚本排演这些事物。通过这种方法，可发现模型的哪些部分被遗珊以及哪些部分有明显语义错误。
把元素和其包含的内容娶集在一起。对千类而言，要做好职责的平均分配，然后逐渐把它们转换成具体的属性和操作。

# 对逻辑数据库模式建模

识别模型中那些状态必须超过应用程序生存时间的类作为需要作为永久数据存储的类。
创建一个包含这些类的类图。可以自己定义相关的构造型和标记值组合。
对类的结构细节进行细化。包括属性的细节、类之间的关联及其多重性。
注意那些增加数据库设计复杂化的公共模式并尽量简化，如循环关联、一对一的关联和 N 元关联等。
考虑类的行为。这些行为主要包括对数据存取和数据完整性约束重要的操作。一般情况下，这些业务规则应该被封装在这些永久类的上一层中。

# 面向对象的设计原则

# 开闭原则 (OCP)

基本思想：软件实体应当对扩展开放，对修改封闭。

优点：在扩展系统功能的同时，不影响现有代码。易于维护，适合迭代式开发。

设计原则：类图中使用接口和泛化，井且通过使用多态机制进行调用。

# 里氏替换原则（LSP）

基本思想：子类对千父类是完全可替换的。

优点：主张使用抽象和多态将设计中的静态结构改为动态结构，维持设计的封闭性。

设计原则：类鼓励使用继承与多态，以提高代码复用及代码扩展性；但严格限制多态与重载必须是父子完全可替换的。

# 依赖倒置原则

基本思想：高层次模块不应该依赖于低层次模块，二者都应该依赖千抽象；抽象不应该依赖于具体，具体应该依赖于抽象。

优点：降低层次间的耦合性。

设计原则：高层次类－＞抽象层－＞低层次类。

# 接口分离原则（ISP）

基本思想：采用多个与特定客户类有关的接口，而不是采用一个通用的接口，以避免客户类被迫依赖千不需要的接口。

优点：避免接口擁肿和接口污染。

设计原则：针对不同客户类，分别定义接口。

# 单一职责原则 (SRP)

基本思想：每个类只含有单一的职责，且该职责应由这个类完全封装。

优点：避免类间的高耦合。

设计原则：避免一个类包含多职责，或一个职责涉及多个类。

# 对象图

# 对象图简介

对象图 (object diagram) 显示了某一时刻的一组对象及它们之间的关系。

对象图的作用：主要用于说明系统在某一特定时刻的具体运行状态，一般在论证类模型设计时使用。

# 对象图的组成元素

# 对象

对象，是一个封装了状态和行为的具有良好边界和标识符的离散实体。

对象名：是一串字符串，类似于类的名称，对象名也可以有简单名和路径名之分。

stu : Student 标准表示法
*: Student 匿名表示法
stu 省略类名的表示法

状态：由对象的所有属性以及运行时的当前值组成。

# 链

链 (link) 是两个或多个对象之间的独立连接。
链主要用来导航。
链使用一根实线段来表示。

# 应用对象图建模

# 对象图建模技术

对象图通常用来对系统的对象结构建模。

类图可以完整表述系统类及其之间的关系，对象图不能详细的描述系统完整的对象结构。

对象图建模步骤

识别建模机制。
识别参与的类和接口等元素，以及这些元素之间的关系。
识别井选择对象。
按需要显示每个对象的状态。
识别井显示出对象之间的链即对象的类目之间关联的实例。

# 对象图使用要点

注重千表达系统静态设计视图或静态交互视图的一个方面。
表示由一个交互图描绘的动态场景的一个画面。
只包含对理解该方面不可缺少的那些元素。
提供与它的抽象层次相一致的细节，应该只显露出对理解是不可缺少的那些属性值和其他修饰。
不要过分的简化，这样会使读者对重要的语义产生误解。

# 包图（package diagram）

# 包图简介

包图 (package diagram) , 是用来描述模型层次和分组结构的一种通用机制。包图主要组成包括包以及包的依赖关系。

包图的作用

将语义关系紧密的一组建模元素组织为包，有利于理解这些元素的作用。
通过包的嵌套，可将模型组织为层次结构。
有助千理解模型中各组块间的访问控制。

# 包图的组成元素

# 包

用于把模型本身组织成层次结构的通用机制，它不能执行。
通过使用包，可方便描述系统组织结构、各组块间的访问控制。

包的表示：小矩形＋大矩形

包名称
包内模型元素
可见性

包名称

一般以大写字母开头，大小写混合，每个单词首字母大写，避免使用特殊符号。
包有简单名与路径名两种命名方法。同一层级下包名必须唯一。

包内元素

包中可以容纳各种高级的模型元素，甚至是一个完整的 UML 图。
包中可以含有包，这被称为包的嵌套。

包内元素的显示方式：

表示在包内
表示在包外

包内元素的可见性

Public (+): 对包外引用可见，相当千包的对外接口。
Protected (#) : 对派生类、友元类可见。
Private (-) : 对友元类可见。
Package (~) : 仅对当前包可见。

包的构造型

《 system》：表示整个系统。
《subsystem》：表示一个子系统。
《facade》：表示一个只引用其他包中元素的包，用千提供简略视图。
《stub》：代理包，表示服务于另一包的公共内容，常用千分布式系统建模。
《framework 》：表示一个包含可重用设计模式的包。

包的作用

组织模型中的元素。
控制元素的可见性。
在外部观察包时，可以将内部元素视作一个整体，方便将多个元素一同处理。
包内部的元素应该保证有相似、相同的语义，或者其元素有同时更改和变化的性质。

元素的分包原则

包与其所含模型元素间是一种从属关系，该关系是唯一的，且二者生存期一致。
包内模型元素不能重名。
包内元素语义上紧密相关。
包间尽可能独立、尽可能减少耦合度。

# 包的依赖关系

如果不同包内模型元素间存在依赖关系，则称包间存在依赖关系。

依赖关系的表示：带箭头的虚线。可以《》添加构造型。

循环依赖：依赖是广泛存在的。

包的依赖关系特征

不同包内模型元素间依赖关系的统一描述。
依赖关系需要包中元素的外部可见性。
包内对外部可见的元素构成了包的公共命名空间。
通过导入 (import) , 可将一个包的公共元素追加到另一包的公共命名空间。

# 包的建模技术

对成组元素建模
对体系结构视图建模

# 对成组元素建模

把建模元素分成一个个的小组。

对成组元素建模的策略

浏览模型中的元素，找出概念或语义上接近的元素分组。
将分好组的元素组织在一个包里，同时考虑包的嵌套。
对每一个包，区分哪些元素需要在包外被访问，进而确定包内元素的可见性。
使用引入依赖显式地在包之间建立关系。

# 对体系结构视图建模

用包表示 "4+1" 体系结构视图。

对体系结构视图建模的策略

识别对目标系统建模有意义的那些体系结构视图。
识别那些对千准确表述这些视图充分而且必要的模型元素，将其组织到包中。
如果有必要，将这些模型元素进一步组织到子包中。

# 顺序图

对系统动态过程视图建模的一种表示方法，通过对象，对象间关系、消息传递等建模元素对交互过程建模。

交互图分类：

顺序图
通信图
时间图

# 顺序图简介

按时间顺序显示对象交互的图。一种特殊的交互图。

顺序图的主要作用

细化用例的表达。将需求和服务转化为详细的交互过程。
有效描述类职责。根据顺序图中各对象之间的交互关系和发送的消息来进一步明确对象所属类的职责。

# 顺序图的组成元素

# 基本结构

横轴：类元轴，描述参与交互的对象／角色。
纵轴：时间轴，描述对象的生命线及交互过程。

# 对象

对象：系统参与者与构成系统的类实体。

矩形框表示，对象名：类名。
横向排列，主要参与者在左，次要参与者在右。
经常出现在图的顶端。

# 生命线

代表一次交互中的参与对象的生存周期。

表示为由对象头符号向下引出井延伸的虚线。

”X“表示生命线的结束。

# 激活

激活，又称为控制焦点，表示一个对象执行一个动作所经历的时间段。

激活的开始一般对应收到另一对象的消息。
激活的结束一般对应发出一个消息。
表示：显示在生命线上的细长矩形。

# 消息

由一个对象（发送者) 向另一对象（接收者）发送的信号，或一个对象（调用者) 调用另一对象（接收者) 的操作。

消息表示为从一个对象的生命线指向另一个对象的生命线的箭头。

消息的类型：

简单消息：泛指任何交互。
调用：调用接收者对象的
返回：一个操作的结束，或对某一消息的回应。
创建：创建一个接收者对象。
销毁：销毁一个对象。

消息的同步特性

同步消息：发送者与接收者的事务执行具有时间上的协调一致性。
异步消息：发送者与接收者的事务各自执行，不具有协调一致性。

# 顺序图中的结构化控制

传统顺序图可以描述单一、线性控制流，但不能描述循环、分支、多控制流并发。UML2 通过 “片段机制” 来表达更加复杂的动作序列。

控制符的表示

片段：控制符的作用区域，对应一个消息子序列。矩形区域。
标签：控制符类型。小五边形。
监护条件：分支、循环的条件，决定某个片段是否执行。［布尔表达式］。

控制符类型

可选片段 (opt) : 监护条件成立时，该片段执行。
井行执行 (par) : 控制符被水平分割为多个子片段，这些子片段在时间上可重叠执行，即井发。
循环执行 (loop) : 在监护条件成立时，控制符重复执行。
条件片段 (alt) : 控制符被垂直分割为多个子片段，对应监护条件的多个分支，满足条件的分支被执行。
交互片段 (ref) : 表示对一段交互的引用。

# 顺序图建模技术

使用顺序图的目的：按时间顺序对系统、子系统、用例等的控制流建模。

顺序图建模的步骤

设定交互的上下文：系统、子系统、类、操作、用例。
设定交互的场景：识别参与交互的对象，按重要性在顺序图中从左至右依次列出。
设定对象的生命线。
按时间顺序排列消息，标注其属性、语义。
设定控制焦点：使用激活（期）修饰生命线。
设定时间、空间约束：如有必要，给消息添加标注以修饰其时间或空间约束。
设定前、后置条件：如有必要，使用结构化控制符描述控制流的前、后置条件细节。

# 时间图

对象间交互过程以时间轴上状态变迁方式描述的一种建模方法。

时间图特点

有明确的时间标度。
采用状态而非控制焦点（动作）描述生命线。

时间图的组成

生命线：是一个命名元素，代表交互中的单个参与者。、
状态或条件时间线：随时间变化，一个单项状态的改变。
期间约束：设置某一时间区域发生。
时间约束：设置某一时间点发生。
销毁：表示生命线终止。

时间图与顺序图的不同之处

时间轴与对象轴交换了位置。在时间图中，纵向表示不同对象，横向表示时间的延伸。
不同对象的生命线在独立的矩形框中显示，矩形框纵向堆砌成整个图。
对象可以有不同的状态。每个对象的状态在其生命线的最左侧纵向排列，生命线通过上下起伏来表示对象当前所处的状态。
可以显示一个时间标尺。时间标尺上有时间刻度，用来表示时间间隔。
不同对象生命线上的时间是同步的。

# 通信图

# 通信图简介

表现对象协作关系的图。
对用例内部对象或角色间交互和消息传递的结构化组织特性进行分析、描述的建模表示方法。
通信图：数据结构＋数据流 + 控制流。
从结构方面来看，通信图包含了一个对象的集合井且定义了它们之间的行为方面的关系，表达了系统的一些静态内容。
从行为方面来看，通信图包含了在各个对象之间进行传递交换的列的消息集合，以完成协作的目的。
UML 1 中称为协作图
UML2.0 后称为通信图

通信图和顺序图的异同

相同：
都是对用例的实现进行描述。
不同：
顺序图强调交互的时序。
通信图强调交互的组织特性及消息流的数据结构。

通信图的作用：

通过描绘对象之间的传递情况来反映使用语境的逻辑表达。
显示了在交互过程中各个对象之间的组织交互关系以及对象彼此之间的链接。
可以说明类操作中使用到的参数、局部变量以及返回值等。

# 通信图的组成元素

对象／角色 (object)
消息 (message)
链 (Link)

# 对象

是一个封装了状态和行为的具有良好边界和标识符的离散实体。

对象的表示：矩形框表示，对象名：类名。

通信图中对象的特点

无孤立对象。
无生命线。

# 链

两个（或多个）对象之间的独立连接，是关联的实例。用一条实线表示。

链的特点：动态关联的实例。

# 消息

由一个对象（发送者）向另一对象（接收者）发送的信号，或一个对象（调用者）调用另一对象（接收者）的操作。

消息的编号

最高层级的消息用阿拉伯数字 1 编号。下一级的消息注明为 1 .1，1.2 。
井发消息用加字母的方式表示。例如： 1a1, 1b1 。

控制流建模
迭代表示：如 *[i:=1 .. n] 。

条件表示消息执行与否取决于一个布尔表达式的值。

条件建模是在消息的名称前增加一个条件字句，如 [x> 0], 表示根据表达式的不同执行不同的消息。

# 通信图与顺序图

共同点

主要元素相同
表达语义相同
对象责任相同

不同点

侧重点不同
对象状态不相同
激活情况不相同

# 通信图建模技术

目标：描述一个用例实现过程中各个对象之间的交互和消息传递。

绘制通讯图思路和步骤：

识别交互的语境；
识别相应的对象；
识别对象之间的关系；
设置对象之间的消息

# 状态机图

# 状态机图简介

状态机图 (state diagram, statechart diagram, state machine diagram) : 显示状态机的图，表示单个对象从一个状态到另外一个状态的控制流。

状态机是一种行为，它说明对象在其生命周期中响应事件所经历的状态变化序列以及对那些事件的响应。

状态机的构成

状态 (state)
转换 (transition)
事件 (event)
活动 (activity)
动作 (action)

功能与作用

状态机图描述了状态转换时所需的触发事件和监护条件等因素。
状态机图清楚地描述了状态之间的转换及其顺序。
清晰的事件顺序有利千开发人员在开发程序时避免出现事件错序的情况。
状态机图通过判定可以更好地描述工作流在不同的条件下而出现的分支。

# 状态机图的组成部分

状态机图的核心元素

状态 (state) 简单状态、伪状态、复合状态
转换 (transition)

# 状态

描述了一个对象稳定处千的某个持续的、可区分的过程。

简单状态
复合状态

状态的构成

名称：一个合法的标识符，用千区分不同状态；当某个状态可明显区分千其他状态时，名称可以省略。
入口／出口动作：由其他状态转移到当前状态，或从当前状态转移到其他状态时要附带执行的动作，用千描述状态的外部动态特性。
表示为 "entry / 动作表达式” 和"exit / 动作表达式”
内部活动：实体进入当前状态后持续执行的一系列动作。内部活动的结束一般会对应当前状态的结束和触发到另一状态的转换。
内部转换：是一种不导致状态改变的特殊转换，与普通转换相比，内部转换只有源状态而没有目标状态。（内部转换一般表示为：事件名称＋活动表达式）
可推迟事件：是一种特殊的事件，表示对象在某个特定状态下对此类事件的处理会被推迟，但不会丢失，也不会触发状态的转换。（表示为” 事件名称 /defer''）

# 转换

转换是两种状态间的一种关系。

转换表示：从源状态指向目标状态的实线箭头，井附有转换的标签。

⌊ 转换名称⌋ : opt 事件名称 opt ⌊(参数列表)⌋ opt ⌊[监护条件]⌋ opt ⌊/ 效果列表⌋ opt

# 事件

是在某一时间与空间下所发生的有意义的事情，是系统执行中发生的值得建模的事物。
一般被状态或转换所发送和接收。
是状态转换的触发器。
用事件名称＋参数列表的形式表示一个事件，参数列表用千描述向事件接收者传递的信息。

能够在触发器中接收的事件

调用事件：表示对象接收到一个调用操作的请求。其期待的结果是事件的接收者触发一个转换井执行相应的操作。
改变事件：表示发生了依赖千某个逻辑表达式所描述条件的事件。一般用 when+ 逻辑表达式的方式来表示。
信号事件：表示由一个对象发送给另一个或一组对象的异步信号，他是对象间通信的一种重要方式。
时间事件：状态转换依赖千事件中的一个时间表达式。一般使用 after 来辅助表示。

# 监护条件 (guard condition)

一个转换被激发必须满足的条件。
表现形式为逻辑表达式，该表达式可以根据触发器事件的参数、属性等写成。
当对象接收到触发事件时，只有监护条件为真，转换才能被激活。
对监护条件的检验是触发器计算过程的一部分。当一个事件发生时，对监护条件的检查进行一次且仅进行一次。

# 效果列表 (effect list)

效果列表是一个过程表达式，在转换被激活时执行，表示转换附加的效果。
效果列表包括多个动作，可以根据操作、属性、拥有对象的连接、触发器事件的参数等写成。
效果的表达语法与其实现的具体内容有关。

# 伪状态

在状态机中具有状态的形式，却具有特殊行为的顶点。
伪状态实际上是一个瞬间的状态。
最常见的伪状态包括初态、选择、分叉与结合、历史状态等。
初态。表示一个状态机的入口和开始位置。
选择。状态机中的一个伪状态节点，用千表示状态机中的分支结构。

# 复合状态 (composite state)

指包含有一个或多个嵌套状态机的状态。复合状态中包含的状态称为子状态。分类：顺序复合状态、井发复合状态。

# 顺序复合状态

顺序复合状态是仅含顺序子状态的一种复合状态。复合状态的特点是，在对象处千复合状态的任一时刻，只有一个子状态是活跃的。

# 并发复合状态

井发复合状态是含井发子状态的复合状态。在对象处千复合状态的任一时刻，有多个子状态同时是活跃状态。

# 历史复合状态

历史状态是应用与复合状态的一种伪状态。

用与表示最近一次离开该复合状态时所处的子状态。

# 状态机图建模技术

状态机图建模的目标是对那些在不同条件下对外反应不同的对象的生命周期建模。

状态图建模的条件

对象处千可知的若干稳定状态：状态图建模的基础。
存在确定的事件使对象所处状态相互转换：状态机建模的合理性。
对不同状态而言，对象对外的接口、行为特征各不相同：状态机建模的必要性。

状态机图建模的固定流程

确定状态机的语境。
设置状态机的初态和终态。
决定该对象的状态机中可能需要响应的事件。
从初态到终态，列出这个对象可能处于的所有顶层状态。用转移将这些状态连接起来，明确转移的触发器和监护条件，接着向转移中添加效果动作。
识别状态是否需要有入口动作和出口动作。如果需要，使用子状态来对顶层状态进行嵌套。
检查状态机中提供的事件是否与所期望的相匹配；检查所有事件是否都已经被状态机所处理。
检查状态机中的动作是否能由类或对象的关系、操作等支持。
跟踪状态机，确保状态机是良构的，即不存在无法到达的状态，也不会发生停机。

# 活动图

# 活动图简介

对系统动态过程视图建模的一种表示方法，通过活动、控制流、判定、分叉与结合等元素对系统工作流建模。

活动图本质上说是一个流程图，展示从活动到活动之间转移的控制流。

活动图的作用

对计算过程中的步骤及时序建模；
对活动序列中的数据流建模；
对一组对象间的交互过程建模；
对单个操作的控制流程建模。

# 活动图的组成元素

活动图的核心元素是活动和控制流，活动与活动之间通过控制流进行连接，构成有意义的动作网络。

活动图主要包括：动作；活动结点；控制流；泳道等。

# 动作

可执行的、原子性的计算行为。
动作描述：表达式的计算、调用操作、发送消息、创建或删除对象等。

# 活动

一组动作序列的执行过程。
活动结点是动作序列的简化表示。
表示方式：左右两端为圆弧的＂矩形框＂

# 开始符号

表示业务流程的起始位置
一个活动图仅有一个开始符号
表示方式：黑色实心圆点

# 终止符号

表示业务流程的结束位置。
一个活动图可以包含多个终止符号。
表示方式：内有一个黑色实心小圆点的空心圆圈。

# 控制流

用于表示业务流程从一个活动向另一个活动过渡的路径。
控制流既表示一个活动的结束，也表示另一活动的立即开始，无需其他约束或事件的触发。
表示方式：简单箭头

# 判断节点

表示基千某个条件判断的多个控制流选择。
一个进入控制流，两个或多个导出控制流。
导出控制流的箭头上附加控制条件。
表示方式：萎形。

# 合并节点 (merging)

多个控制流的合井，统一导出到一个离开控制流。
仅定义统一的出口，无同步语义。
至少有两个指向它的控制流，仅有一个输出控制流。

# 分叉节点 (forking)

表示多个控制流井发执行。
一个进入控制流，两个或多个导出控制流。
分叉节点是从线性流程进入井发过程的过渡节点。
表示方式：水平或垂直的粗线。

# 结合节点 (joining)

多个控制流的在结合点处相互等待，直至全部完成后，合井为一个离开控制流。
表示方式：水平或垂直的粗线。

# 泳道 (swimlanes)

将活动图中的活动按照其业务参与者分组，称为泳道。
每个活动只能属于一个泳道，转移可以跨越泳道。
表示方式：垂直的实线。

# 对象流

对象可出现在活动图中，表示某些活动会产生、访问、修改这些对象。
对象流是连接两个节点的活动边。

对象流的表示

表示方式：简单箭头。
活动节点到对象节点：创建、生成对象。
对象节点到活动节点：访问、激活动作。

# 扩展区域

扩展区域表示在一组数据元素上的迭代执行。
扩展区域的输入输出都是值的集合。
输入：一个或多个值序列（集合）；
输出：无输出，或多个值序列（集合）。
表示方式：虚线圈起来的区域。

# 活动图建模技术

建模语境

系统
子系统
类
操作
用例
协作

# 对工作流建模

工作流是系统参与者感知到的活动序列，它可以描述参与者与系统交互发生时的业务流程。

工作流建模主要步骤

设定工作流建模焦点（选择重要的工作流）。
选定工作流中承担高层职责的业务对象，井在活动图中建立泳道。
识别工作流的前置、后置条件，以便确定工作流边界。
从工作流的初始状态开始，按时间顺序在活动图中安排活动序列。
针对复杂的、重复出现的活动，创建单独的活动图。
确定连接这些活动序列的流：顺序、分支、井发等。
对千工作流中的重要对象，安排对象流，井显示其状态变化。

# 对操作建模

将活动图附加到任意建模元素上，其中最常见的是向一个操作附加活动图。

作为控制流图，对某些计算过程的执行细节描述、建模。

操作建模主要步骤

搜集这个操作涉及的抽象，包括：参数、返回值类型、所属类的属性、关联的类。
识别这个操作初态的前置条件和终态的后置条件，以及其所属类中不受该操作影响的量。
从初态开始，按时间顺序依次识别活动井表示为活动结点。
若有必要，使用分支结点表示条件路径和迭代。
对具有控制流的类，若有必要，可使用分叉表示井发。

# 组件图

# 组件图简介

对系统静态设计与实现视图建模的一种表示方法，通过接口、端口、组件及连接等元素对系统的物理实现建模。
描述组件与组件关系的图。

组件图的作用

通过小的部件描述一个复杂系统的物理构成。
组件图体现面向对象思想的核心。
有助千明确系统设计、降低沟通成本。

# 组件图的组成元素

组件图的主要元素包括组件、接口和端口。

# 组件

系统设计的一个模块化部分，它隐藏了内部的实现，对外提供了一组组接口。
组件具有可替换性。
组件的表示：矩形框＋相应标识。

组件与类的区别

类是一种逻辑抽象，而组件是一种物理抽象。
类具有直接属性与操作，而组件一般只有操作且仅通过接口访问。
类与组件间存在依赖关系。

组件的类型

配置组件：指系统运行时需配詈的组件。
工作产品组件：指开发过程中产生的、用于生成配置组件的中间产品。
执行组件：系统运行而创建的组件实例。

# 接口

类或组件所提供服务的抽象。
一组操作的集合。
接口表示一种约定，不涉及具体实现。

接口分类
供给接口 (provide interface)、需求接口 (required interface)

# 端口

端口是组件的对外窗口，是组件外部可见行为的总和。
端口允许把组件的接口划分为离散的井且可以独立使用的几部分。
跨立在组件边界上的方块。
每个端口都有一个名字。

端口的特征

端口具有身份，是可区分的。
接口是针对端口定义的操作集，因此接口可被分组井独立地被引用。
端口是组件的部件 (part) , 具有多重性。

依赖关系使用虚线箭头表示，主要用千组件与需求接口之间的依赖和组件之间的依赖。
实现关系使用虚线三角箭头表示，主要用千组件与提供接口之间的实现。

# 部件

部件：是组件实现所必须的内部单元。部件有名字和类型，也有多重性。

# 内部连接

内部连接：表现了内部部件间的依赖关系。

内部连接的类型

端口相连：部件间具有明确的依赖关系。
接口相连：部件间具有兼容的接口。
委托连接：内部端口与外部端口间的连接。

# 组件图建模技术

组件图表现的是系统的物理层次或实现层次上的静态结构，能够帮助开发团队加深对系统组成的理解。

组件图对源代码结构建模应湮循的策略

识别出感兴趣的源代码文件集合，井建模为组件。
如果系统规模较大，使用包对组件进行分组。
可以使用约束或注解来表示源代码的作者心版本号等信息。
使用接口和依赖关系来表示这些源代码文件之间的关系。
检查组件图的合理性，井识别源代码文件的优先级以便进行开发工作。

对可执行程序结构进行建模时，应逜循的策略

识别出相关的运行组件集合。
考虑集合中每个组件的类型。
如果系统规模较大，可以使用包对组件进行分组。这里包的使用可以对应千相应文件的文件存储结构。
分析组件之间的关系，使用接口和依赖关系建模这些关系。
考量建模结果是否实现了组件的各个特性，对建模的结果进行细化。

# 部署图

软件开发过程中，不同角色的关注点不同

软件开发人员

关注软件的静态结构
关注软件的配置
关注软件的动态特性

系统工程师

关注系统中硬件与软件的构成与配置
关注软、硬件间的折中和分工

# 部署图简介

是一种展示运行时进行处理的节点和在节点上存在的制品的配置的图。
对系统硬件配置及拓扑结构相关静态特征进行建模的一种表示方法。

部著图的作用

通过硬件配置及拓扑结构描述一个系统的物理构成。
确认软件的运行环境、约束及性能瓶颈。
有助于软件开发人员与系统集成工程师间的沟通。

# 部署图的组成元素

# 节点（node）

系统运行时的一个硬件对象（计算资源）。
节点的类型：处理器：具有计算能力的节点设备：外围 I/O 设备

# 连接（connection）

节点间的关联关系。
使用关联关系来表示节点之间的通信路径。
使用构造型来区分不同类型的通信路径或通信的实现方式。

# 部署图建模技术

部署图的意义在千对各种系统的静态部署视图进行建模，无论是 C/S 结构、 B/S 结构、嵌入式系统或分布式系统均可以使用部署图来有效表达。

# 对嵌入式系统建模

识别目标系统中的设备和物理节点。
提供清晰的视觉描述：使用 UML 扩展机制描述特定的设备类型，能够保证通过图标清楚区分不同类型的设备。
确定这些物理节点间的关系；确定实现视图中的软件制品与部署视图中物理节点间的关系。

# 对 C/S 系统建模

识别出代表客户和服务器的节点。
重点标注出与系统行为关系紧密的设备。
使用构造型描述这些节点，以便清晰提供视觉线索。
确定节点间的拓扑关系；确定软件制品与物理节点间配置关系。

# 对全分布式系统建模

分布式系统一般是由多级服务器组成的，建立在网络之上的软件系统。

对全分布式系统建模步骤

识别出系统中的处理机和设备节点。
若考虑系统网络性能及拓扑结构变化带来的影响，需对通信设备的细节进行充分描述。
使用包对这些节点进行逻辑分组。
可以引进用例图描述所感兴趣的行为类型。