UML 定义

引言

关于流程空间中的关键概念的一些通用定义。

A

Activity

一个 *角色* 可能被要求执行的工作单元。

活动图

表示一个*状态机*的特殊情况，用于对涉及一个或多个*分类器*的流程进行建模。

Actor

表示系统外部与系统交互的某人或某物。

聚合

显示一个关联，该关联对聚合（整体）与其组成部分之间的整体-部分关系进行建模。

分析与设计

统一过程中的一个*学科*，其目的是展示系统*用例*将如何在实现中得到实现；（通用）在战略和战术决策以满足系统所需的功能和质量*需求*的活动。

分析类

系统中角色扮演的设计元素的抽象，通常在*用例实现*的上下文中。分析类可能为多个角色提供抽象，代表这些角色的共同行为。分析类通常演变为一个或多个设计元素；例如，设计*类*和/或*组件*，或设计子系统。

应用程序编程接口 (API)

表示一个软件接口，它使应用程序能够相互通信。API 是可以在应用程序中编码以获取底层操作系统或服务程序提供的特定功能和服务的编程语言构造或语句集。

架构

表示系统在其环境中的最高级别概念。软件系统的架构（在给定时间点）是其组织或重要*组件*通过*接口*交互的结构，这些组件由连续更小的组件和接口组成。架构可以递归地分解为通过接口交互的部分、连接部分的关联以及组装部分的约束。通过接口交互的部分包括*类*、*组件*和*子系统*。

构件

信息的一部分

1. 由流程生成、修改或使用，
2. 定义一个责任区域，并且
3. 受版本控制。

构件可以是*模型*、*模型元素*或*文档*。文档可以包含其他文档。

关联

表示一个关联，该关联对实例之间的双向语义连接进行建模。

B

边界类

用于对系统环境与其内部工作之间的通信进行建模的类。

业务参与者

表示业务外部与业务交互的某人或某物。

业务实体

业务实体代表由*业务参与者*和*业务工作者*操纵的重要且持久的信息。

业务用例

业务用例定义了一组*业务用例实例*，其中每个实例是业务执行的一系列动作，该系列动作产生对特定业务参与者有价值的可观察结果。业务用例类包含与产生“有价值的可观察结果”相关的所有主流程和备用流程。

业务用例模型

业务预期功能的模型。业务用例模型是识别组织中角色和可交付成果的基本输入。

C

类

对具有相同成员的对象的集合的描述。

组件 (Component)

它代表了系统的一个非琐碎的、几乎独立的、可替换的部分，该部分实现了清晰的功能。组件应符合并提供一组*接口*的实现。

组件图

显示*系统*中*组件*之间存在的组织和依赖关系的图。

组成

表示一种*聚合*关联，具有强大的所有权和与整体生命周期相同的生命周期。

D

部署图

显示运行时处理节点以及驻留在其上的*组件*、*进程*和*对象*的配置的图。

开发案例

执行组织使用的软件工程过程。它作为统一过程产品的配置或定制而开发，并适应项目需求。

学科

学科是一组相关的活动，这些活动与一个主要的“关注领域”相关。RUP 中的*学科*包括：*业务建模*、*需求*、*分析与设计*、*实现*、*测试*、*部署*、*配置与变更管理*、*项目管理*和*环境*。

文档

文档是“打算在纸上表示”或在利用纸张隐喻的介质中表示的信息集合。网页可以作为文档。

E

说明

表示统一过程的第二个*阶段*，在该阶段定义产品的*愿景*及其*架构*。

实体类

用于对系统中存储的信息以及相关行为进行建模的*类*。它通常定义一组实体对象，这些对象参与多个用例，并且通常在这些用例之后仍然存在。

环境

表示软件工程过程中的一个*学科*，其目的是定义和管理系统正在开发的*环境*。包括过程描述、*配置管理*和开发工具。

可执行架构

可执行*架构*是系统的部分实现，用于演示选定的系统功能和属性，特别是那些满足非功能性要求的。

扩展关系

从用例类 A 到用例类 B 的扩展关系表明，B 的实例可以在特定条件下（在扩展中指定）包含 A 指定的行为。单个目标用例的多个扩展者指定的行为可以在单个用例实例中发生。

F

功能

系统提供的、直接满足*利益相关者需求*的、可从外部观察到的服务。

我

Inception

统一过程的第一个*阶段*，在此阶段将上一代的种子理念、投标请求，推进到（至少在内部）获得资助以进入*细化*阶段。

L

Layer

层表示架构的水平切片。

M

里程碑

表示给定迭代正式结束的时间点。

模型

表示从特定视角对系统的描述，该描述以一种无需额外信息即可理解该系统（从该视角）的方式来描述系统。

模型元素

表示从正在建模的系统中提取的抽象元素。

N

节点

节点是一个分类器，它表示一个运行时计算资源，通常至少具有内存，并且通常具有处理能力。运行时对象和组件可能驻留在节点上。

P

包

表示用于将元素组织成组的通用机制。

R

细化

描绘了一种关系，该关系表示对已在一定详细程度上指定的某物的更完整的规范。

关系

表示模型元素之间的语义连接。

要求

需求描述了系统必须符合的条件或能力；直接来自用户需求，或在合同、标准、规范或其他正式要求的文件中陈述。

风险

表示一个持续的或即将发生的担忧，该担忧有很大可能对主要里程碑的成功产生不利影响。

RUP

Rational Unified Process

S

场景

表示说明行为的特定动作序列。

面向服务架构 (SOA)

面向服务架构是软件系统结构的概念描述，它以组件及其提供的服务来表示，而不考虑这些组件、服务以及组件之间连接的底层实现。

软件需求

对系统可从外部观察到的行为的规范；例如，系统的输入、系统的输出、系统的功能、系统的属性或系统环境的属性。

利益相关者

表示系统结果对其有实质性影响的个人。

利益相关者需求

表示为了证明购买或使用是合理的，必须满足的业务或运营问题（机会）。

T

模板

表示*构件*的预定义结构。

可追溯性

将项目元素追溯到其他相关项目元素的能力。

U

用例

表示系统行为的描述，以动作序列的形式。

用例图

表示显示系统中参与者与用例之间关系的图。

V

视觉

用户对要开发的产品的视图，以关键*利益相关者需求*和系统*功能*的级别进行指定。