UML统一建模语言，由小白到大神的跃迁之路

面向对象编程

面向对象（ Object Oriented，简称 OO）方法将世界看作一个个相互独立的对象，相互之间并无因果关系，它们平时是 “鸡犬之声相闻，老死不相往来” 的。只有在某个外部力量的驱动下，对象之间才会依据某种规律相互传递信息。这些交互构成了这个生动世界的一个 “过程”。在没有外力的情况下，对象则保持着 “静止” 的状态。

• 对象提供了一种处理复杂问题的方式，有了对象，我们能够通过提升抽象级别来构建更大、更复杂的系统。
• 之所以面向对象方法会兴起，是因为这种认识论能够帮助我们构造更为复杂的系统来解释越来越复杂的现实世界。
• 比掌握具体的技术更重要的是掌握认识论所采用的方法和分析过程。
• 面向对象的特性：复用性、抽象层次。
• 抽象层次的好处：
  1. 不论在哪一个层次上，我们都只需要面对有限的复杂度和有限的对象结构，从而可以专心地了解这个层次上的对象是如何工作的；
  2. 低层次的零件更换不会影响高层次的功能；

要解决面向对象的困难我们需要这样一些方法

• 一种把现实世界映射到对象世界的方法；
• 一种用对象世界描述现实世界的方法；
• 一种验证对象世界行为正确反映了现实世界的方法；

UML 是一种建模语言

• UML 本身并没有包含软件方法，而仅是一种语言。

• 核心元素描述基本事物；核心视图表达这些事物构成的某种有意义的观点；核心模型则使用核心视图来描述需求、系统、设计等。

• UML 可视化的含义：UML 通过它的元模型和表示法，把那些通过文字或其他表达方法很难表达清楚的，隐晦的潜台词用简单直观的图形表达和暴露出来，准而直观地描述复杂的含义。把 “隐晦” 的变成 “可视” 的，也就是把文字变成图形。

面向对象分析设计完整过程

业务模型

业务模型真实映射了参与者在现实世界中的行为。

• 参与者：信息来源提供者、第一驱动者。现实世界中的 “人”。
• 用例：驱动者的业务目标。现实世界中的 “事”。
• 业务场景、用例场景：现实世界中的 “规则”。
• 业务对象模型：达成业务目标过程中的事物。现实世界中的 “物”。

概念模型

分析模型：建立适合计算机理解和实现的模型。

• 边界类：交互的边界。原始需求中的 “事”。

  从狭义上说，边界就是大家熟悉的界面，所有对计算机的操作都要通过界面进行。从广义上说，任何一件事物都分为里面和外面，外面的事物与里面的事物之间的任何交互都需要有一个边界。比如参与者与系统的交互，系统与系统之间的交互，模块与模块之间的交互等。

• 实体类：业务实体。现实世界中的 “物”。

• 控制类：原始需求中的动态信息，即业务或用例场景中的步骤和活动。现实世界中的 “规则”。

设计模型

在设计模型中，概念模型中的边界类可以被转化为操作界面或者系统接口；控制类可以被转化为计算程序或控制程序，例如工作流、算法体等；实体类可以转化为数据库表、XMI 文档或者其他带有持久化特征的类。

从概念模型向设计模型转化时，可以遵循的规则有：

• 软件架构和框架；
• 编程语言；
• 规范或中间件；

用例驱动

用例驱动是统一过程的重要概念，或者说整个软件生产过程就是用例驱动的。用例驱动软件生产过程是非常有道理的。让我们再次回顾建模公式，很容易得出一个推论，要解决问题领域就要归纳出所有必要的抽象角度（用例），为这些用例描述出可能的特定场景，并找到实现这些场景的事物、规则和行为。再换个说法，如果我们找到的那些事物、规则和行为实现了所有必要的用例，那么问题领域就被解决了。总之，实现用例是必须做的工作，一旦用例实现了，问题领域就解决了。这就是用例驱动方法的原理。

RUP—— 统一过程

RUP

统一过程归纳和整理了很多在实践中总结出来的软件工程的最佳实践，是一个采用了面对象思想，使用 UML 作为软件分析设计语言，并且结合了项目管理、质量保证等许多软件程知识综合而成的一个非常完整和庞大的软件方法。

统一过程归纳和集成了软件开发活动中的最佳实践，它定义了软件开发过程中最重要的阶段和工作（四个阶段和九个核心工作流），定义了参与软件开发过程的各种角色和他们的职责，还定义了软件生产过程中产生的工件，并提供了模板。最后，采用演进式软件生命周期（迭代）将工作、角色和工件串在一起，形成了统一过程。

UML & PUP

• RUP 是目前与 UML 集成和应用最好、最完整的软件方法。
• UML 是一种语言，用来描述软件生产过程中要产生的文档，统一过程则是指导如何产生这些文档以及这些文档要讲述什么方法。

实施统一过程的原因

1. 提高软件成熟度的需要；
2. 提高软件技术水平和质量的需要；
3. 统一过程适于开发稳定的架构；

软件项目真正的灵魂是「软件过程」

站在软件过程的角度看待问题：先了解一个软件项目是怎么做的，再去 UML 中寻找需要的工具，用 UML 中适合的工具把软件过程要达到的要求记录下来。

建模基础

建模：

通过对客观事物建立一种抽象的方法，用来表征事物并获得对事物本身的理解，再把这种理解概念化，并将这些逻辑概念组织起来，形成对所观察的对象的内部结构和工作原理的便于理解的表达。

• 做需求的时候，首要目标不是要弄清楚业务是如何一步一步完成的，而是要弄清楚有多少业务的参与者？每个参与者的目标是什么？参与者的目标就是你的抽象角度。
• 静态的事物（物）+ 特定的条件（规则）+ 特定的动作（参与者的驱动）= 特定的场景（事件）。

抽象层次

抽象层次越高，具体信息越少，但是概括能力越强。反之，具体信息越丰富，结果越确定，但相应的概括能力越弱。

抽象的两种方法：

1. 自顶向下：适用于从头开始认识一个事物。
2. 自底向上：适用于在实践中改进和提高认识。

对象分析方法

• 一切都是对象。
• 对象的独立性。对象与对象之间是天然独立的，只是在某个特定的场景下，它们的某一个特定的实例才相互联系在一起。
• 对象的原子性。在同一抽象层次上，在分析过程中都应当将对象视为一个不可分割的原子。
• 对象的可抽象性。
• 对象的层次性。

核心元素

版型

对 UML 元素基础定义的扩展，在同一个元素基础定义的基础上赋予特别的含义，使得这个元素适用于特定的场合。

参与者（actor）、主角

actor 是在系统之外与系统交互的某人或某事物。

• 参与者位于系统边界之外。
• 参与者一定是直接并且主动地向系统发出动作并获得反馈的。

业务主角

• 业务主角是参与者的一个版型，特别用于定义业务的参与者，在需求阶段使用。
• 业务主角是与业务系统有着交互的人和事物，他们用来确定业务范围。
• 业务主角针对的是业务人员而非计算机用户。

业务工人

人工坐席、被动参与业务，是系统边界中的一部分。

区分参与者和业务工人的方法：判断是在边界之外还是边界之内。

参与者 & 涉众 & 用户 & 角色

• 涉众是与要建设的这个系统有利益相关的一切人和事。
• 参与者是涉众的代表。
• 用户是参与者的代表，是系统的使用者（系统操作员）。
• 角色是参与者的职责，从众多参与者的职责众抽象出相同的那一部分，将其命名而形成一个角色。

参与者是涉众的代表，它代表涉众对系统的利益要求，并向系统提出建设要求；参与者通过代理给其他用户或将自身实例化成用户来使用系统；参与者的职责可以用角色来归纳，用户被指定扮演哪个或哪些角色因此来获得参与者的职责。
参与者的核心地位还体现在，系统是以参与的观点来决定的。参与者对系统的要求，对系统的表述完全决定了系统的功能性。

用例

用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值。

• 一个用例就是参与者交互的，并且给参与者提供可观测的有意义的结果的一系列活动的集合。
• 用例，就是一件事情，要完成这件事情，需要做一系列的活动。
• 用例场景：一个场景就是一个用例的实例。
• 一个完整的用例：参与者 + 前置条件 + 场景 + 后置条件。
• 用例的作用：捕捉功能性需求。

用例！= 功能

一个用例是一个参与者如何使用系统，获得什么结果的一个集合，通过分析用例，得出结构性的和功能性的内容，最终实现用例，也就实现了使用者的观点。

• 功能是计算机术语，它是用来描述计算机的，而非定义需求的术语。功能实际描述的是输入➡️计算➡️输出。
• 功能是脱离使用者的愿望而存在的。
• 功能是孤立的，给一个输入，通过计算就有一个固定的输出。
• 如果非要从功能的角度解释用例，那么用例可以解释为一系列完成特定目标的 “功能” 的组合，针对不同的应用场景，这些 “功能” 体现不同的组合方式。

用例的特征

用例的粒度

• 业务建模阶段：用例的粒度以每个用例能够说明一件完整的事情为宜，即一个用例可以描述一项完整的业务流程。
• 概念建模阶段：用例的粒度以每个用例能描述一个完整的事件流为宜。即一个用例描述一项完整业务中的一个步骤。
• 系统建模阶段：用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。
• 在同一个需求阶段，所有用例的粒度应该是同一个量级的。

业务用例

• 业务用例是用例版型中的一种，专门用于需求阶段的业务建模。
• 业务用例专门用于业务建模。

业务用例实现

• 专门用于需求阶段的业务建模。
• 业务用例实现表达了同一个业务用例的不同实现方式。

概念用例

• 概念用例用于概念建模。
• 概念用例用来获取业务用例中的核心业务逻辑。

系统用例 = 用例

系统用例是用来定义系统范围、获取功能性需求的。系统用例是软件系统开发的全部范围，系统用例是我们得到的最终需求。

用例实现

一个用例实现代表了用例的一种实现方式。

边界

• 面向对象里，任何一个对象都有一个边界，外界只能通过这个边界来认识对象，与对象打交道，而对象内部则是一个禁区。
• 边界决定视界。边界是可大可小的，由建模者主观臆定。
• 边界决定抽线层次。通过设定边界、组织边界大小来决定抽象层次，层层推进地描述对象。
• 边界还是一种分析方法。实际工作中应当学会灵活地使用边界，用边界来决定抽象层次和视角，进而排除边界外大量的杂音来降低复杂程度。

业务实体

业务实体代表业务角色执行业务用例时所处理或使用的 “事物”。

• 业务实体是类的一种版型，特别用于在业务建模阶段建立领域模型。
• 如果说参与者和用例描述了我们在这个问题领域中达到什么样的目的，那么业务实体就描述了我们使用什么来达到业务目标以及通过什么来记录这个业务目标。

理解业务实体

1. 业务实体来自现实世界。
2. 业务实体一定是在分析业务流程（业务用例场景）的过程当中发现的。
3. 业务实体作为类的一个版型，具有对象的所有性质，包括属性和方法。
   • 属性：在特定的场景下，只需要关心与这个场景直接关联的属性。
   • 方法：在特定的场景下，只需要关心与这个场景有直接关系的方法。

获取业务实体

1. 建立业务用例场景；
2. 从业务用例场景中逐个分析动词后面的名词，它们就是业务实体的备选对象；
3. 分析业务实体之间的关系，并决定哪些应当单独建模，哪些应当作为属性。

包

• 包最主要的用途是分类元素。
• UML 认为好的分包具有高内举、低耦合的性质。
• 同一个包中的元素应该是相互联系，甚至是不可分割的。
• 包之间无依赖关系或松耦合关系。
• 如果实际情况难以做到完全解除依赖关系，那么至少应当保证包之间的依赖关系不会被传递。
• 包之间的依赖关系应当是单向的，应当尽量避免双向依赖和循环依赖。

分析类

分析类用于获取系统中主要的 “职责簇”。它们代表系统的原型类，是系统必须处理的主要抽象概念的 “第一个关口”。

• 分析类是从功能性需求向计算机实现转化过程中的 “第一个关口”。
• 分析类可以产生系统设计的主要抽象 —— 系统的设计类和子系统。

边界类

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

边界类常用的场景：

• 参与者与用例之间；
• 用例与用例之间；
• 用例与系统边界之外的非人对象；
• 相关联的业务对象有明显的独立性要求；
• 从架构角度上来说，边界类主要位于展现层。

控制类

控制类用于对一个或几个用例所特有的控制行为进行建模。控制对象（控制类的实例）通过控制其他对象，因此它们的行为具有协调性质。

• 控制类来源于对用例场景中行为的定义。
• 控制咧主要起到协调对象的作用。
• 控制类主要位于业务逻辑层。
• 我们应当在边界类和边界类、边界类和实体类、实体类和实体类之间都默认加入控制类，将相应的处理逻辑放到控制类里去，哪怕该控制类只有一个操作。

实体类

实体类是用于对必须存储的信息和相关行为建模的类。实体对象（实体类的实例）用于保存和更新一些现象的有关信息。

• 实体类来源于业务模型中的业务实体。

设计类

「设计类」

设计类由类型、属性和方法构成。设计类的名称、属性和方法也直接映射到编码中相应的 class、
property 和 method。

• 设计类是系统实施中一个或多个对象的抽象。
• 设计类用于设计模型中。

可见性

类的属性和方法的可见性定义：

• 公有：除了类本身以外，属性和方法对其他模型元素也是可视的。

• 保护：属性和方法只对类本身、它的子类或友元取决于具体语言）是可视的。

• 私有：属性和方法只对类本身和类的友元（取决于具体语言）是可视的。

• 实施：属性和方法只在类本身的内部是可视的（取决于具体语言）。

关系

关联关系（association）

• 描述不同类的对象之间静态的、天然的结构关系。
• 静态关联，通常与运行状态无关。
• 强关联。
• 多重性：一对一关系、一对多关系、多对多关系。
• 在最终的代码里，关联对象通常是以 == 实例变量（成员变量）== 的形式实现的。

依赖关系（dependency）

• 描述一个对象在运行期会使用到另一个对象的关系。
• 临时性、弱关系，随运行场景而改变（动态的）。
• 依赖有单向依赖、双向依赖。
• 双向依赖是一种非常不好的结构，我们总是应当保持单向依赖，杜绝双向依赖的产生。
• 在最终的代码里，依赖关系体现为 == 类构造方法、类方法等的传入参数 ==。

扩展关系（extends）

• 它特别用于在用例模型中说明向基本用例中的某个扩展点插入扩展用例。
• 用于概念模型、业务模型。
• 表示 “可选”，而不是必须。

包含关系（include）

• 用于用例模型。
• 用于概念模型、业务模型。
• 包含用例表示 “必须”，而不是可选。

实现关系（realize）

实现所代表的含义是，基本用例描述了一个业务目标，但是该业务目标有多种可能的实现途径，每一种实现途径可以用用例实现（或称用例实例）来表示，而用例实现与基本用例之间就构成了实现关系。换言之，每个实现途径都实现了基本用例的业务目标。

• 用于在用例模型中连接用例和用例实现。

精化关系（refine）

• 一个基本用例可以分解出许多更小的关键精化用例，这些更小的 == 精化用例更细致地展示了基本用例的核心业务 ==。精化关系用来连接基本用例和精化用例，说明精化用例是由基本用例精化得来的。
• 精化关系也可以用于模型与模型之间，表示某个模型是通过精化另一个模型而得来的。比如说我们认为设计类是通过精化分析类而得来，我们可以用 XX 设计类 < >XX 分析类来表示它们之间的关系。
• 与泛化关系不同的是，精化关系表示由基本对象可以分解为更明确、精细的子对象，这些子对象并没有增加、减少、改变基本对象的行为和属性，仅仅是更加细致和明确化了。在泛化关系中基本对象被泛化成为子对象后，子对象继承了基本对象的所有特征，并且子对象可以增加、改变基本对象的行为和属性
• 另一方面，精化关系仅仅用于建模阶段，在实现语言中是没有精化这一语义的。泛化则等同于实现语言中的继承语义。

泛化关系（generalization）

• 泛化关系可以用于建模过程中的任意一个阶段，说明两个对象之间的继承关系。
• 泛化关系表示一个类对另一个类的继承。

聚合关系（aggregation）

A 聚合到 B 上，或者说 B 由 A 组成。

• 聚合关系用于类图，特别用于表示实体对象之间的关系，表达 == 整体由部分构成 == 的语义。例如个部门由许多人员构成。
• 与组合关系不同的是，== 整体和部分不是强依赖的，即使整体不存在了，部分仍然存在 ==。例如部门撤销以后，人员不会因此而消失，他们依然存在。

组合关系（composition）

A 组合成 B，或者说 B 由 A 组成。

• 组合关系用于类图，特别用于表示实体对象系，表达 == 整体拥有部分 == 的语义。例如母公司拥有许多子公司。
• 组合关系是一种强依赖的特殊聚合关系，如果整体不存在了，则部分也将消亡。例如母公司解体了，子公司也将不再存在。

组件

组件是系统中实际存在的可更换部分，它实现特定的功能，符合一套接口标准并实现一组接口。

• 建模过程中，我们通过组件这一元素对分析设计过程中的类、接口等进行逻辑分类，一个组件表达软件的一组功能。
• UML 中把组件定义为任何的逻辑代码模块。但是在笔者看来，一个组件应当具有完备性、独立性、逻辑性和透明性。
• UML 中组件之间唯一的关系就是依赖。但是在笔者看来，一个组件应当是一个独立的业务模块，有着完备的功能，可独立部署，一个组件可以看成是一个完备的服务。

节点

节点是带有至少一个处理器、内存以及可能还带有其他设备的处理元素。

在实际工作中，一般说来服务器、工作站或客户机可以称为一个节点。节点是应用程序的部署单元。节点元素特别用于部署视图，描述应用程序在物理结构上是如何部署在应用环境中的，是一种包括软、硬件环境在内的拓扑结构描述。

使用节点的场景：

• 分布式应用环境；
• 多设备应用环境；

核心视图

在 UML 里，结构性特征是用 == 静态视图 == 来表达的，行为性特征是用 == 动态视图 == 来表达的。

静态视图

静视图就是表达静态事物的。它只描述事物的静态结构，而不描述其动态行为。

用例图

• 用例视图采用参与者和用例作为基本单元，以不同的视角展现系统的功能性需求。

业务用例视图：使用业务主角和业务用例描述业务建模的功能性需求

业务用例视图的两个视角：

1. 业务主角视角：有利于向业务主角确认其业务目标是否都已经齐全，以此来检查是否有遗漏的业务用例没有发现。

   

2. 业务模块视角：有利于从业务的完整性角度出发，检查完成某个业务的所有业务主角和业务用例是否已经齐全，以此来检查是否有遗漏的业务用例没有被发现。

   

3. 其他视角

业务用例实现视图：描述业务的实现途径

概念用例视图

概念用例视图用于展现从业务用例中经过分析分解出来的关键概念用例，并表示概念用例和业务用例之间的关系。一般来说这些系有扩展、包含和精化。

• 一般以业务用例为单元展现。

系统用例视图

系统用例视图展现系统范围，将对业务用例进行分析以后得到的系统用例展现出来。

• 一般以业务用例为单位展现。
• 系统用例视图就是系统的开发范围。

它表达的含义是计算机系统将开发本视图中所列举出的系统用例，而检查借阅证可能是手工工作而不需要纳入系统建设范围。

系统用例实现视图

如果一个系统用例有多种实现方式，也应当为其绘制实现视图。

类图

类图用于展示系统中的类及其相互之间的关系。

本质上说，类图是现实世界问题领域的抽象对象的结构化、概念化、逻辑化描述。

在 UML 中，从开始的需求到最终的设计，类图也是围绕着这三个层次（概念层、说明层、实现层）的观点进行建模的。类图建模是先概念层而说明层，进而实现层这样一个随着抽象层次的逐步降低而逐步细化的过程

概念层类图

概念层的观点认为，在这个层次的类图描述的是 == 现实世界中问题领域的概念理解 ==，类图中表达的类与现实世界的问题领域有着明显的对应关系，类之间的关系也与问题领域中实际事物的关系有着明显的对应关系。需要注意的是，概念层类图中的类和类关系与最终的实现类并不一定有直接和明显的对应关系。在概念层上，类图着重于对问题领域的概念化理解，而不是实现，因此类名称通常都是问题领域中实际事物的名称。概念层的类图是独立于实现语言和实现方式的。

概念层类位于业务建模阶段。领域模型图、业务实体图描述。

说明层类图

说明层的观点认为，在这个层次的类图考察的是 == 类的接口 == 而不是实现，类图中表达的类和类关系应当是对问题领域在接口层次抽象的描述。

说明层类位于概念建模阶段。分析类、分析模型图描述。

实现层类图

实现层观点认为，类是 == 实现代码的描述 ==，类图中的类直接映射到可执行代码。在这个层次上类必须明确采用哪种实现语言、什么设计模式、什么通信标准、遵循什么规范等

实现层类图位于设计建模阶段。类图可视为伪代码。

包图

包图一般都用来展示高层次的观点。

在 UML 所有视图中，包图或许是最自由、约束最小的一种。除了特定的版型之外，包几乎可以用在任何阶段。

动态视图

故名思义，动态视图是描述事物动态行为的。需要注意的是，== 动态视图不能够独立存在，它必 ==
== 须特指一个静态视图或 UML 元素，说明在静态视图规定的事物结构下它们的动态行为。==

活动图

活动图描述了为了完成某一个目标需要做的活动以及这些活动的执行顺序。

活动图的两个层面：

1. 描述用例场景 —— 用例活动图；
2. 描述对象交互 —— 对象活动图；

活动图主要用于：

1. 业务场景建模；
2. 用例场景建模；

用例活动图

用例 —— 参与者的一个目标

用例场景 —— 如何来达到这个目标

活动图 —— 描述用例场景（业务流程）

对象活动图

展示对象的交互，不推荐使用。

泳道

泳道，顾名思义，就像一个游泳运动员只能在一个道里进行比赛一样，一个对象也只能在一个业务流程中担任一个（或一类）职责。泳道代表了一个特定的类、人、部门、层次等对象的职责区，这些对象在业务流程中负责执行的活动集合构成了它们的职责。
即使加入泳道后对象交互图有了些模样，笔仍然不推荐使用它。泳道最主要的用途是在分析用例场景时用来获取角色职责。

状态图

状态图显示一个状态机。状态机用于对模型元素的动态行为进行建模，更具体地说，就是 == 对系统行为中受事件驱动的方面进行建模 ==。通使用状态图来说明业务角色或业务实体可能的状态 —— 导致状态转换的事件和状态转换引起的操作。状态图常常会简化对设计的确认。对于类的对象所有可能的状态，状态图都显示它可能接收的消息、将执行的操作和在后类的对象所处的状态

时序图

时序图描述了在参与交互的对象中所发生的事件（从激活的角度来说明），以及这些对象如何通过相互发送消息进行通信。可以为用例事件流的各种不同形式制作时序图。

• 时序图用于描述 == 按时间顺序排列的对象之间的交互模式 ==。
• 通常使用时序图描述用例实现。

业务模型时序图

业务模型时序图用于为领域模型中的业务实体交互建模，其目的是实现业务用例。

概念模型时序图

概念阶段的时序图采用分析类来绘制，目标同样是实现业务用例。

设计模型时序图

设计模型时序图使用设计类作为对象绘制。目标是实现概念模型中的某个事件流，一般以某个完整交互为单位，消息细致到方法级别。

协作图

协作图描述了对象间交互的一种模式；它通过对象之间的连接和它们相互发送的消息来显示参与交互的对象。
协作图中可以有对象和主角实例，以及描述它们之间关系和交互的连接和消息。通过说明对象间如何通过互相发送消息来实现通信，协作图描述了参与对象中发生的情况。可以为用例事件流的每一个变化形式制作一个协作图。
与时序图的作用相似，协作图用于显示对象之间如何进行交互以执行特定用例或用例中特定部分的行为，协作图的建模结果用于获取对象的职责和接口。与时序图不同的是，协作图因为展示了对象间的关系，使得它更适用于获得对对象结构的理解，而时序图则更适于获得对于调用过程的理解。不过在本质上，它们是可以互换的。

[图片上传失败…(image-d222e7-1534144287983)]

核心模型

要建立什么模型，首先要确定的是该项目要采用什么样的生命周期。

用例模型

用例模型是系统既定功能及系统环境的模型。

• 业务用例模型用于识别和规定业务需求，概念模型用来分析和确认业务需求，而系统用例模型用来规定系统开发需求。这三者之间是一种精化的关系。

业务用例模型

• 业务用例模型要准确而完备地描述客户的现存或预想业务。
• 业务用例模型用于描述和明确业务需求，是为客户现实的业务建模的。

概念用例模型

概念用例模型帮助我们简化和理解业务模型，帮助我们初步从对象角度来理解业务，从而建立软件架构并产生系统用例。

系统用例模型 / 用例模型

系统建模 = 需求获取

系统用例模型代表了实际业务转化为计算机功能性需求以后的结果，是系统开发的契约。

领域模型

领域模型是采用业务对象建立起来的一种模型。

分析模型

分析模型使用分析类来建立系统原型，获得系统实现需求的第一手方案。

软件架构和框架

架构代表了一个软件项目对系统的定义和理解。软件架构在较高的抽象层次上，将系统规划为一些独立的逻辑部件，各负其责，这些部件通过标准的通信接口传递信息。一个架构就是一个系统的骨架。

框架是针对某个问题领域通用解决方案，它通常集成了最佳实践和可复用的基础结构，对开发工作起到减少工作量、指导和规范作用。

架构师系统蓝图，是对系统高层次的定义和描述。框架是解决方案，是加速和提高系统质量的半成品。

业务架构

业务架构在先启阶段建立，在精化阶段得以改进。业架构的目标是为业务领域建立一个维护和扩展的逻辑结构，描述业务的构成。业架构对我们理解客户业务，尤其是开发行业解决方案有着重要的作用。另一方面，业务架构是软件架构的重要输入。
业务架构来源于两个主要的输入：业务用例和领域模型。如果没有业务架构，只有业务用例和领域模型时，我们将 “只见树木不见森林” 因为不论是业务用例还是领域模型，它们都只是业务领域的一个部分，尤其业务用例本身就是一个独立的单元，仅凭对它们的理解不足以俯瞰整个业务领域。

软件架构

软件架构需要在业务架构的基础上引入计算机环境，计算机环境包括硬件环境和软件环境。软件架构需要说明业务架构如何分布在计算机环境中，并得以执行。

一个典型的软件架构包括两个视角: 广度视角和深度视角，这两个视角构成对软件架构的 “立体” 描述。

• 广度视角即是常见的软件层次结构它关注软件的分层，规定每一层的职责以及层之间的通信标准。一般使用层包元素来绘制。
• 深度视角是指广度视角中每一层的详细说明，它关注每一层以及每个部分的具体实现架构。

设计模型

设计模型是一个描述用例实现的对象模型，它可作为对实施模型及其源代码的抽象。设计模型用作实施和测试活动的基本输入。

设计模型就是我们所熟知的详细设计。

组件模型

实施模型

实施模型由配置节点和组件组成。