1.前言

本文是以《软件架构设计》和《大象Think in UML》两本书的内容为基础进行讲述，以个人的理解做了提炼和总结，旨在能够通过本文对UML语言以及其在系统设计中的应用有一个概括性的了解。

2.《软件架构设计》

图 架构设计过程的节奏

图 架构设计的6个步骤

需求分析

确定关键需求

概念架构设计

2.1需求分析

愿景分析：愿景=业务目标+范围+Feature+上下文图。

需求分析 

用例图

用例简述（用户故事）

用例规约  

用例实现（鲁棒图）

2.2.领域建模

领域模型：类图、状态图

领域模型在软件开发中的作用

2.3.确定关键需求

关键质量

关键功能：核心功能、必做功能、高风险功能、独特功能。

2.4.概念架构设计

关键需求进、概念架构出。

左手功能：鲁棒图。

右手质量：目标-场景-决策表。

要领1：功能需求与质量需求并重。

要领2：1个决定、4个选择。

2.5.细化架构设计

5个视图、15个任务

逻辑架构=模块划分+接口定义+领域建模。

开发架构=技术选型+文件划分+编译关系。

物理架构=硬件分布+软件部署+方案优化。

运行架构=技术选型+控制流划分+同步关系。

数据架构=技术选型+存储格式+数据分布。

3.《大象Think in UML》

3.1概念

UML（Unified Modeling Language）统一建模语言

RUP（Rational Unified Process）统一过程

3.2UML核心元素

版型：是对一个UML元素基础定义的扩展，UML几乎每一个元素都有很多版型，例如：用例有业务用例、业务用例实现、系统用例等版型；类有接口、边界类、实体类、控制类等。在建模的不同阶段，问了区分视图之间的不同点，会采用不同的图示来表示。

参与者：参与者是在建模过程中处于核心地位的。

参与者位于边界之外。

参与者可以非人。

业务主角和业务工人的区别。

参与者与涉众的关系

参与者与用户的关系

参与者与角色的关系

用例：用例是一种把现实世界捕获下来的方法，用例定义了一组用例实例，其中每一个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值。

用例是相对独立的。

用例执行结果对参与者来说是可以观测和有意义的。

这件事必须由一个参与者发起，不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。

用例必须是以动宾短语形式出现的。

业务用例、业务用例实现、概念用例、系统用例、用例实现

边界：

边界决定视界

边界决定抽象层次

业务实体：业务实体是一种版型，在业务建模阶段建立领域模型。

包：

领域包、子系统、组织结构、层

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

分析类代表系统的主要“职责簇”，意味着分析类是从功能性需求向计算机实现转换的第一个关口。

分析类可以产生系统的设计类和子系统，意味着计算机实现是可以通过某种途径产生出来的。

边界类

控制类

 实体类

类：属性、方法、可见性

关系：关系是重要的语义，它抽象出对象之间的联系，让对象构成某个特定的结构。

关联 它描述不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。A对象知道B对象的存在。

依赖 它表示一个对象的修改会导致另一个对象的修改的关系。A对象保存了B对象的ID，如果A没有使用B，则是关联关系，如果A使用了B对象，则是依赖关系。

扩展它特别用于用例模型中说明向基本用例中的某个扩展点插入扩展用例。一般来说，扩展用例是带有抽象性质的，它表示用例场景中的某一个支流，由特定的扩展点触发而被启动。用例是可选的。

包含它特别用于用例模型，说明在执行基本用例的实例的用例实例过程中插入行为端。用例是必须的而不是可选的。

实现A实现B，在用例模型中连接用例与用例实现，说明基本用例的一种实现方式。

精化A精化了B，一个基本用例可以分解出许多更小的关键精化用例，这些精化用例更细致地展示了基本用例的核心业务。

泛化A继承自B，说明两个对象之间的继承关系。

聚合聚合关系用于类图，特别用于表示实体对象之间的关系，表达整体由部分构成的语义。与组合不同的是，聚合不是强依赖的，即使整体不存在了，部分仍然存在。

组合组合关系用于类图，特别用于表示实体对象关系，表达整体拥有部分的含义，组合关系是一种强依赖的特殊聚合关系，如果整体不存在了，则部分也消亡了。

组件

组件是系统中实际存在的可更换部分，它实现特定的功能，符合一套接口标准并实现一组接口。组件代表系统中的一部分物理实施，包括软件代码或其等价物（如脚本或命令文件）。

3.3UML核心视图

3.3.1静态图

3.3.1.1用例图

用例图采用参与者和用例作为基本元素，以不同的视角展现系统的功能性需求。用例视图是了解视图的第一个关口，人们通过用例视图得知一个系统将会做什么。对客户来说，用例视图是客户业务领域的逻辑化表达，对建设单位来说，用例视图是系统蓝图的开发依据。

 

1. 业务用例视图：业务用例视图使用业务主角和业务用例展现业务建模的结果。大多数情况下，业务用例视图要从业务主角和业务模块两个视角进行展示。

2. 业务用例实现视图：业务用例实现视图展现业务用例有哪些实现途径。业务用例是业务需求，而业务用例实现则是业务的实现途径，从软件工程的角度说，这个视图展示了需求的可追溯的特点。

            

3. 概念用例视图：用于展示业务用例中分析出来的关键概念用例，并表示概念用例和业务用例之间的关系，一般来说这些关系有扩展、包含、精化。对于概念用例来说，一般以业务用例为单元来展现的，即将试图名称命名为业务用例名称，如果某几个业务用例关系紧密也可以放在一个视图里展示。概念用例不是必须的，如果业务用例关系复杂，绘制概念用例有助于细化和更准确地理解业务用例。

3. 系统用例视图：系统用例视图展现系统范围，将对业务用例分析以后得到的系统用例展现出来。系统用例就是系统给的开发范围。

4. 系统用例实现视图：如果一个系统用例有多种实现方式，也应当为期绘制实现视图。虽然繁琐，还是建议为即使只有一种实现方式的系统用例也绘制实现视图。

 

3.3.1.2 类图

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

UML解决面向对象困难的方法源于面向对象的方法中对类理解的三个层次观点,这三个层次是概念层、说明层和实现层。类图建模是先建概念层而说明层，再建实现层的过程。

1. 概念层类图：这个层次的类描述的是现实世界中问题领域的概念理解，类图中表达的类与现实世界的问题领域存在着明显的对应关系，类之间的关系也与问题领域中实际事物的关系有着明显的对应关系。概念层中的类和类之间的关系与最终的实现类并不一定有直接和明显的对应关系。类图着重对问题领域的概念理解，而不是实现，因此类名称通常问题领域的实际事物的名称。
2. 说明层类图：这个层次的类图考察类的接口而不是实现，类图中表达的类和类关系应当时对问题领域在接口层次抽象的描述。说明层视图是搭建在现实世界和最终实现之间的一座桥梁。在这个阶段，类通常都很粗略。
3. 实现层类图：类是实现代码的描述，类图中的类直接映射到可执行的代码。实现层类图位于设计阶段。在这个阶段，类图可以视为伪代码。

 

3.3.1.3 包图  

包图一般用来展示高层次的观点。包具有多种版型，通过包这个容器从大到小、从粗到细地建立关系是一种很好的办法。

 

3.3.2 动态图

动态视图不能独立存在，它必须特指一个静态视图或UML元素。

 

3.3.2.1 活动图

活动图描述了为了完成某一目标需要做的活动以及这些活动的执行顺序。UML中有两个层面的活动图，一种用于描述用例场景，另一种用于描述对象交互。

在面向对象的眼中是没有业务流程这种东西的，所谓流程只不过是在某个外部力量推动下对象之间相互交流的一个过程，它只是瞬时的。

活动图在描述用例场景时仍然是十分有效的工具，关键还是建模者自己要避免被过程化的观点所困扰，而不必忌讳使用活动图。

1. 用例活动图：用例表达了参与者的一个目标，用例场景则描述了如何达到这个目标。活动图用来描述用例场景，也就是通常所说的业务流程。业务流程一般包括一个基本业务流程和一个或多个备选业务流程，而业务流程则通过多个活动按照一定的条件和执行顺序来推进，活动图可以是手动执行的，也可以是自动执行的任务，每个活动完成一个工作单元。活动图有几个关键元素：起始点、活动、判断、同步、结束点、基本流、支流、异常流、组合活动。
2. 对象活动图：对象活动图用于展示对象的活动。
3. 泳道：泳道技术的引入解决了活动图不能描述对象职责的遗憾，一个对象只能在一个业务流程中担任一个（或一类）职责，泳道代表了一个特定的类、人、部门、层次等对象职责区。
4. 业务场景建模：以业务主角（客户代表）为泳道，以从业务主角处获取的业务用例作为活动来编排活动图，这种活动图对我们获取正确的业务用例和检查已经获得的业务用例有着很好的帮助。它能够：帮助发现业务用例、帮助检查业务用例粒度、帮助检查业务主角、帮助检查业务用例。
5. 用例场景建模：在获取了业务用例之后，我们的到了参与者和业务目标，我们通过用例场景来说明如何达到业务目标。我们以业务主角和业务工人为泳道，以工作单元作为活动来编排活动图来描述用例场景。这种视图对我们获取概念用例、角色和业务对象（业务实体）有着很好的帮助。它能够：帮助发现概念用例、帮助发现角色、帮助发现业务实体、帮助建立领域模型。

状态图

状态图显示一个状态机，状态机用于对模型元素的动态行为进行建模，更具体地说就是对系统行为中受时间驱动的方面进行建模。通常使用状态图来说明业务角色或业务实体可能的状态—导致状态转换的事件和状态转换引起的操作。状态图中的关键元素包括：初始状态、状态、复合状态、转移、事件、条件、最终状态。

1. 时序图

用于描述按时间顺序排列的对象之间的交互模式，时序图在概念层、说明层、实现层的视图分别是：业务模型时序图、概念模型时序图、设计模型时序图。

1. 业务模型时序图：业务模型时序图用于为领域模型中的业务实体交互建模，其目标是实现业务用例。在时序图中常用的UML元素有：对象、生命周期线、消息、会话、销毁。绘制业务模型时序图时要注意：第一，时序图以达成业务目标为准则；第二，这个阶段处于业务阶段，使用的描述语言应当采用业务术语；第三，时序图表达的内容会对将来的分析设计带来帮助，但是对于编码实现来讲由于太粗略而不能够作为依据。
2. 概念模型时序图：概念阶段的时序图采用分析类来绘制，目标同样是实现业务用例。但是，由于分析类本身代表系统原型，所以这个阶段的时序图已经带有计算机理解。
3. 设计模型时序图：设计模型时序图采用设计类来绘制，目标是实现概念模型中的某个事件流，一般以一个完整交互为单位消息细致到方法级别。建议在设计模型阶段，只需要用框架中的关键类描述典型的交互场景即可，不需要为每一个交互都绘制时序图。

3.3.2.4 协作图

协作图描述了对象之间的一种交互模式，它通过对象之间的连接和它们相互发送的消息来显示参与交互的对象。协作图中可以有对象和主角实例，以及描述它们之间关系和交互的连接和消息。可以为用例事件流中的每一个变化绘制一个协作图。

协作图用于显示对象之间如何进行交互以执行特定用例或用例中特定部分的行为，协作图的建模结果用于获取对象的职责与接口。协作图因为展示了对象之间的关系，使得它更适合获取对对象结构的理解，而时序图则更适合于获得对于调用过程的理解。

针对概念层、说明层、设计层分别对业务实体对象、分析类对象和设计类对象绘制协作图，分别得到业务模型协作图、概念模型协作图和设计模型协作图。

1. 业务模型协作图：采用业务实体来绘制，目标是实现用例场景。
2. 概念模型协作图：采用分析类进行绘制，目标是实现业务用例。
3. 设计模型协作图：采用设计类进行绘制，目标是实现概念模型中的某个事件流。

 3.4 UML核心模型

3.4.1 用例模型

用例模型是系统既定功能或系统环境的模型，它可以作为客户和开发人员之间的契约。用例是贯穿整个系统开发的一条主线。用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用。

统一过程是一种演进式的软件过程，在整个产品生命周期之内充满了许多小规模的迭代，而每个迭代的开始几乎都是从识别用例开始，从用例被实现而结束。

用例模型有业务用例模型、概念用例模型和系统用例模型。

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

3.4.1.1 业务用例模型

业务用例模型位于统一过程的先启阶段，在业务建模核心工作流中完成。业务模型目的是为现存的或客户预想中的真实业务建立模型，是我们为了理解客户的业务，并与客户达成业务理解上的共识而建立的模型，它不需要考虑计算机环境。

1. 业务模型的主要内容包括：
   1. 业务用例视图：业务用例视图包括业务主角和业务用例，它是业务的高层和概要视图，并作为其他建模要素的组织存在。
   2. 业务用例场景
   3. 业务用例规约
   4. 业务规则
   5. 业务对象模型
   6. 业务用例实现视图
   7. 业务用例实现场景
   8. 包图

3.4.1.2 概念用例模型

概念用例模型位于先启阶段，有时在精化阶段进行，是业务用例建模的一个子集。业务用例是粗略的，我们需要一种方法来分解那些较大的业务用例，从中找到关键和核心的工作单元，针对这些工作单元建立模型来简化业务。

1. 概念用例模型的主要内容：
   1. 概念用例视图
   2. 概念用例分析
   3. 分析类视图
   4. 分析场景

3.4.1.2 系统用例模型

系统用例模型位于统一过程的先启阶段的末期以及精化阶段的早期。

1. 业务用例模型的主要内容：
   1. 业务用例
   2. 概念视图
   3. 用例视图
   4. 用例规约
   5. 补充规约
   6. 业务规则
   7. 用例实现
   8. 用例场景
   9. 分析对象

 

3.4.2 领域模型

领域模型是采用业务对象建立起来的一种模型，我们把领域模型当中使用到的业务对象成为领域类，一般来说，领域类有三种形式：

        业务对象实体，表示业务中使用到或产生的东西，如订单、账号、合同等。

        系统需要处理的现实世界的对象和概念，如商品、买家、买家。

        将要发生和已经发生的事件，如购买、撤单、付费等。

领域模型建立的目的是视图挖掘这一系列对象之间交互关系的本质。领域模型的研究高于特定业务场景的一般规律。可以说，领域模型是从所有业务场景对象交互模型当中抽象出来的更高级别的业务对象模型；它表示了业务对象结构和交互的一般规律，揭示了业务运行的本质和核心。要求建模者有深厚的行业知识背景，或者具备高度的抽象能力，并且遍历了绝大部分的业务用例场景。

领域模型可以帮助我们理解问题领域的关键概念和关键对象，帮助我们理解这些对象如何工作，以及如何解决问题。

1. 领域模型的主要内容：
    

3.4.3 分析模型

分析类用于获取系统中的主要“职责簇”。它们代表系统的原型类，是系统必须处理的主要抽象概念的第一个关口。分析模型使用分析类来建立系统原型，获得系统实现需求的第一手方案。

3.4.4 软件架构和框架

1. 软件架构：架构需要描述两个方面，这两个方面分别针对业务领域的理解和系统领域的理解，我们称之为业务架构和系统架构，这两者是需要和谐统一的。
   1. 业务架构：业务架构在先启阶段建立，在精化阶段得以改进。
   2. 软件架构：软件架构需要在业务架构的基础上引入计算机环境，计算机环境包括硬件环境和软件环境。
   3. 架构描述：架构描述通过架构文档记录，至少需要描述以下方面：业务架构概述、组织结构、业务模块、业务对象模型、典型用例场景、软件架构概要、计算环境、软件层次、实现架构、协议和接口、软件框架、典型用例场景的架构实现、非功能性需求。
2. 软件框架：软件框架是针对一个普遍问题的最佳实践或解决方案，它通常是一个半成品，提供基本类库、编程模型和编程规范，甚至包括IDE工具。

 3.4.5 设计模型

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

从分析模型映射到设计模型：分析类代表设计元素的实例所承担的角色；这些角色可以由一个或多个设计模型元素来实现。此外，单个设计元素可以实现多个角色。

        一个分析类可以成为设计模型中的单个类。

        一个分析类可以成为设计模型中的某各类的一部分。

        一个分析类可以成为设计模型中的一个聚合关系类。

        一个分析类可以成为设计模型中从同一个类继承而来的一组类。

        一个分析类可以成为设计模型中一组功能相关的类。

        一个分析类可以成为设计模型中一个包。

        一个分析类可以成为设计模型中一项关系。

        分析类之间的一项关系可以成为设计模型中的一个类。

        分析类主要处理功能性需求以及来自“问题”领域的模型对象；设计类则处理非功能性需求以及来自“解决方案”领域的模型对象。

        分析类可用来代表“我们希望系统支持的对象”，而不用决定用硬件支持分析类的多大部分，用软件支持分析类的多大部分。

3.4.6组件模型

组件总是用来容纳分析类和设计类的，从这个角度说，组件可以理解为一种特殊的包，只不过普通的包起到组织和容纳的作用，而组件的组织行为却有着特别的目标：这些分析类或设计类被组织起来完成一组特定的功能。

组件的四个特性：完备性、独立性、逻辑性和透明性。如何组织代码来保证这些特性呢？答案是架构。组件总是与架构密不可分的，如果没有架构就谈不上组件。生产组件的目的是为了像积木一样构建一个应用系统，为了能够搭建它们并且保证它们的交互，组件必须符合某个架构的规范要求。

定义组件是为了这样的一些目的：

1. 这些组件将成为可复用的单位。
2. 每个组件都有一组特定的功能。
3. 这些组件将成为可独立部署的单位。
4. 这些组件将遵循架构规范。

 

何时使用组件：

应当根据实际情况决定是否需要组件，以下场合可以选择不使用组件，其他情况需要建立：

1. 如果你所实施的项目不是一个分布式的系统，通常没有必要为组件建模。
2. 如果你所实施的项目不需要想第三方提供支持服务，通常不需要组件建模。
3. 如果你所实施的项目中没有将某部分业务功能单独抽取出来形成一个可复用的单元，在许多系统或子系统中使用的要求，通常不需要组件建模。
4. 如果你所实施的项目没有与客户其他现存的系统或第三方系统集成的要求，通常没有必要为组件建模。
5. 如果系统没有采用架构开发，通常不需要组件建模。

 

广义的组件的用法：

1. 描述应用系统中各个逻辑模块之间的关系，此时含义是模块。
2. 描述应用系统中各个子系统之间的关系，此时的含义是子系统。
3. 描述应用系统中各个可执行部分之间的关系，此时的含义是可执行程序。
4. 描述应用系统中各个程序包之间的关系，此时的含义是包。

 

 

3.4.7实施模型

实施模型由配置节点和组件组成。其中配置节点使用节点元素绘制，它用来描述系统硬件的物理拓扑结构；组件使用组件元素绘制，它用来表示在配置图中描述的结构上执行的软件。

何时使用实施模型：

1. 分布式系统，为了描述各种资源在不同节点上的分布情况。
2. 系统需要与来自多方的程序、模块等交互，为了描述这些程序的分布情况。
3. 系统具有多个硬件，为了描述可执行程序在不同硬件设备上的分布情况。

 

3.5统一过程核心工作流程

软件过程明确了软件的生命周期，明确了软件生命周期过程中的成果物和可交付物，同时也就明确了需要什么样的模型。

3.5.1业务建模工作

业务建模位于统一过程的先启阶段，它主要使用到的模型包括业务用例模型、概念用例模型和领域模型。

业务建模的工作流程如下：

业务建模的活动集如下：

 

 

业务建模的工件集如下：

角色	活动集	工件集
业务流程分析员	评估目标组织 设定和调整目标 获取常用业务词汇 查找业务主角和用例 制定业务规则 定义业务架构	业务词汇表 业务规则 目标组织评估 业务前景 业务用例模型 业务对象模型 业务架构文档 补充业务用例规约
业务设计员	详细说明业务用例 详细说明业务角色 查找业务角色和实体 详细说明业务实体 定义自动化需求	业务用例 组织单元 参与者 业务实体 业务用例实现 业务角色
业务模型复审员	复审业务用例模型 复审业务对象模型

 

业务建模的目标：

        了解目标组织的结构和机制。

        了解目标组织中当前存在的问题并确定改进的可能性。

        确保客户、最终用户和开发人员就目标组织达成共识。

        导出支持目标组织所需的系统需求。

业务建模的作用在于：

        业务模型是需求工作流程的一种重要的输入，用来了解对系统的需求。

        业务实体是分析设计工作流程的一种输入，用来确定设计模型中的实体类。

3.5.2系统建模工作

工作流程：

 

系统建模工作主要位于先启阶段和精化阶段，先启阶段侧重于“分析问题”和“理解涉众需要”，而精化阶段则侧重于“定义系统”和“改进系统定义”。“管理系统规模”和“管理需求变更”的活动贯穿项目始终。

系统建模的首要问题是要了解我们利用该系统视图解决的问题的定义和范围。

 

活动集和工件集

 

 

角色	活动集	工件集
系统分析员	制定需求管理计划 确定前景 获取涉众请求 获取常用词汇 查找主角和用例 管理依赖关系 建立用例模型	需求管理计划 前景 涉众请求 词汇表 补充规约 需求属性 用例规约
架构设计员	确定用例的优先级
用例阐述者	详细说明用例 详细说明软件需求	用例 用例包 软件需求规约
用户界面设计员	用户界面建模 设计用户界面原型	主角（人员） 边界类 用户界面原型 用例示意板
需求复审员	复审需求

 

系统建模的目标

        与客户和其他涉众在系统的工作内容方面达成一致并保存。

        是系统开发人员能够更清楚地了解系统需求。

        定义系统边界（限定）。

        为计划迭代的技术内容提供基础。

        定义系统的用户界面，重点是用户的需要和目标。

系统建模工作流程与其他工作流程的关系为：

        业务建模工作流程为系统建模工作流程提供了业务规则、业务用例模型和业务对象模型，包括领域模型和系统的组织环境。

        分析设计工作流程从系统建模工作流程中获取主要输入。在分析设计中可以发现用例模型的缺陷；随后将生成变更请求，并应用到用例模型中。

        测试工作流程对系统建模工作流程确定的系统进行测试，以便验证代码是否与用例模型一致。

3.5.3分析设计工作

分析设计建模即我们所熟知的概要设计和详细设计过程。它主要使用分析模型和设计模型来完成分析设计过程。它主要在精化阶段实施。

工作流程

 

定义备选架构

改进被选架构

分析行为

设计非实时组件

设计实施组件

分析设计活动集

分析设计工件集

分析设计的目标:

1. 将需求装换为未来的设计。
2. 逐步开发健壮的系统构架。
3. 使设计适合于实施环境。
    

分析设计与其他工作流程的关系为：

1. 业务建模工作流程为系统提供组织环境。
2. 需求工作流程为分析设计提供输入。
3. 测试工作流程测试在分析设计过程中所设计的系统。

 

推荐的分析设计工作流程：

分析过程概要

 

设计过程概要

3.5.4实施建模工作

工作流程

活动集

工件集

推荐的实施建模工作流程

3.5实践

准备工作

了解问题领域

涉众分析

规划业务范围

客户访谈

获取需求

定义边界

发现主角

发现业务用例：用例图

业务建模：活动图（泳道）、时序图、协作图、用例规约、业务对象模型、业务用例实现视图、业务用例实现场景、包图

领域建模：分析类图、时序图、协作图

提炼业务规则：全局规划、交互规则、内禀规则

获取非功能性需求

主要成果物

需求分析

关键概念分析：概念用例、概念模型

业务架构

系统原型

系统分析

系统用例

分析业务规则：全局规则、交互规则、内禀规则

用例实现：系统用例、系统用例实现、系统用例实现场景。

软件架构和框架

分析模型：分析类、时序图

组件模型

部署模型

系统设计

设计模型：设计类、设计模型、设计类实现（时序图）

接口设计

包设计