基于UML的需求分析和系统设计

概要：

本文主要讲解如何在项目过程各阶段采用合适的UML图形进行分析和设计，重点关注以下问题：

怎样在实际中有效地使用UML使之发挥应有的作用

怎样捕捉用户心中的需求并转换成明确的UML图形

怎样把自己心中的设计意图通过UML图形准确地表达出来

怎样通过UML进行项目各阶段的平稳推进（分析→设计→编码）

本文将采用两个案例进行实例演示：

【电子化采购系统】案例背景介绍

客户企业是一家大型家电制造商，主要业务是制造和销售家电产品。客户企业的信息系统包括了一个大型ERP。因为想要厂商提供更加即时快捷的服务，客户企业委托设计一个电子化采购系统。

【信仁医院住出院系统】案例背景介绍

信 仁医院是一家区域医院，共有200张病床，医院的只能科室包括内科、外科以及皮肤科。该医院在2000年采购了一套医院内部的医院管理系统，其中包括门诊 系统、挂号系统、收费管理系统、医保申报系统以及财会系统。以往，信仁医院在办理住院出院时都必须使用人工填表的方式，只有在医保给付、门诊医嘱以及收费 管理方面，才能进入医院管理系统进行记录。但为了实现“e化医院项目”，信仁医院需要重新设计一整套住院、出院系统。

本文使用的UML绘制工具是：Enterprise Architect

一、项目开始阶段

这个阶段，也就是相当于传统软件工程中的问题定义和可行性研究，这个阶段主要是通过与用户的访谈，以确认待开发系统“要做什么”，并进行可行性研究，简单来说就是从企业的角度出发研究这个项目是否能做、是否能盈利，否则最终项目失败那对企业就会造成损失了。

项目开始阶段的初期访谈需要抓住以下几个重点：

项目的范围：先找出目前已存在的系统，了解该系统是否提供了相关的集成接口，这一点与你所要开发的项目的复杂度有相当大的关系。

必要的业务流程：在摸索业务流程时，初期应该尽可能只捕捉就“必要的”业务流程，在该业务流程中，尽量避免对细节的研究。

项目的技术限制：包括使用的技术以及其他系统间的交流接口规范。

项目的成功关键因素：要充分了解利益相关方对于整体项目成功与否最关切的问题是什么，并且评估问题和项目成败的风险是否相关。

上述四个重点，其实在一开始就决定了项目是否会成功，如果在项目开始时就落入了细节性的讨论，反而容易造成项目的失败，对于开发团队来说不可不慎。

本阶段结束之后，如果正式立项，那么便进入下一个阶段——需求分析。

二、需求分析阶段

需求分析阶段，主要是跟客户（领域专家）沟通，进行需求的收集和分析，然后通过标准的文书准确地表达出来，并形成需求规格说明书之类的文档，交由设计人员进行后续的系统设计工作。

UML中的用例图正是用于需求收集和表达的有力工具，但是如何找出用例并非易事，这是因为从用户那里收集来的信息很可能是零散的、没有系统性的，要直接从中找出正确的用例非常困难。

因此在分析用例之前，可以先对企业级的业务流程进行规划和设计，抓住企业的本质工作流，为后续进行详细的需求收集和用例分析做好准备。

1、业务流程设计

对于企业的经营管理团队来说，业务流程规划与企业的永续经营之间存在着密切关系。简单来说，业务流程就是为了服务客户而执行的一连串业务内部活动。业务流程分析的目的在于了解整体流程对企业目标的支持分别有何贡献，进而对流程的细节进行规划。

那 么如何进行业务流程的设计呢？Jacbson认为，利用“用例”的“目标导向”特性，可以通过一个“企业级的用例”来完善工作流程的规划与设计。不过衡量 实际状况，大部分领域专家对“用例”的接受度较差，因此可以使用另一个工具来进行企业的建模，这个工具是由Erickson和Penker所提出的一个活 动图的构造型，称为“Eriksson-Penker业务扩展模型”。

1）业务流程规划——Eriksson-Penker业务扩展模型

Eriksson-Penker业务扩展模型是一种“目标导向”的流程分析方式，主要是将与业务流程相关的重要人、事、物以及这个业务流程所要实现的目标做一个链接，描述了企业中重要的人、事、物与流程的关系，这个图中通常不会过多地介绍业务流程的内部细节。在项目开始阶段，需求分析人员可以通过“Eriksson-Penker业务扩展模型”找出要开发系统的重要性，利用“目标导向”方式，对业务流程进行适当的切割。

关于Eriksson-Penker业务扩展模型，详细请看Enterprise Architect官方网站的介绍：业务过程建模→「Eriksson-Penker 业务建模 Profile」节

★ Eriksson-Penker业务扩展模型示例

针对一家大型家电制造商要开发的电子化采购系统的业务流程：

※ 图中之所以分成两个不同的流程，是因为两个流程有不同的“实现目标”。

2）业务流程分析——活动图

在 与领域专家进一步沟通后，就可以对“Eriksson-Penker业务扩展模型”中的每一个“处理”绘制一个对应的活动图，在绘制活动图时，应该将重点 放在“活动”本身，而不需要加入其他因素（文件、数据、表单等）。在活动图中，这些因素应该要在上层的“Eriksson-Penker业务扩展模型”就 表达完成。

活动图最适合用来描述企业的本质工作流。在绘制活动图时千万不要去研究活动的细节，活动图所要捕捉的是整体业务流程的“大方向”。有关细节的相关描述应该是在讨论“用例”时才需要捕捉。

活动图的使用场景：

项目起始阶段，需求分析人员可以使用活动图，针对与项目相关的企业活动，与领域专家一起设计流程

项目上线阶段，可以用利用起始阶段的活动图作为集成测试的重要参考依据

项目维护阶段，企业管理人员可以通过活动图了解企业现行的流程以及未来可以改善的方向

在设计活动图时需要遵循以下原则：

活动图的目的在于表达“流程完整性”而非活动细节。

活动图中的元素（主要是活动）不必考虑复用性。

如果在活动图中绘制了一个“分叉点“，则一定要有一个”会合点“与之对应。

活动图中尽量不要表达”文件“或”数据“。

关于设计活动图时的两点重要建议：

绘制活动图时，最好和领域专家直接当面沟通，最好在访谈过程中直接绘制活动图，并根据活动图附属一次在访谈中所收集到的相关信息。这样，活动图所收集到的信息将更加贴近实际。

在绘制活动图时千万不要去研究活动的细节，活动图所要捕捉的是整体业务流程的“大方向”。有关细节的相关描述应该是在讨论“用例”时才需要捕捉。

★ 表达业务流程的活动图示例

针对上面的电子化采购系统业务流程图中的——“请购流程”，在与领域专家详细沟通后，可以绘制出如下请购流程的活动图。

在完成各主要业务流程的分析，绘制出活动图以后，便可以开始下个分阶段的工作——从业务流程中找出用例，进行需求收集，完成用例模型。

2、需求收集——用例图

1）关于用例的相关介绍

用例是一个系统中所进行的一连串的处置活动，该活动主要是要能够满足系统外部的执行者对于系统的某种期望。

每一个信息系统的用例代表着用户对于系统的“某一个完整期望”。

通常来说，用例是“需求收集及整理”的工具，通过用例与执行者的关系，可以让需求分析人员“聚焦”在特定的“相关人员”（也就是执行者）与”主题“（也就是用例）中。

2）找出用例的三个步骤

根据前面所绘制的业务流程的活动图，可以通过以下三个步骤找出用例：

① 利用与用户的对话找出信息系统的用例

将活动图中的每个“活动”当作“用例”的候选，接着针对每个”活动“询问用户以下几个问题：

在这个活动中谁是主要参与者？

这个活动的进行中需要系统提供服务吗？

系统需要提供什么服务？

系统需要其他信息系统的支持吗？

然后对候选用例进行必要的合并和关系（比如“包含”）分析， 从而得出业务流程相关的用例图。

★ 业务流程相关的用例图示例

针对上面请购流程的活动图进行上述分析，可以得出以下用例图：

② 完成用例的正常流叙述

编写用例叙述时遵循的原则：

每个叙述都必须是肯定句

在叙述中，切记不要描述过多细节

③ 完成用例的替代流及意外处理叙述

替 代流本身仅仅只是正常流的“分支”而非“主干”。举例来说，如果在正常流2有三个替代流，则在替代流的区块中，就会有2a、2b、2c三个分支，而在这三 个分支的编写中，仍然必须遵循着每一句都是“肯定句”的原则。如果在其中又有替代流，则一样必须要利用分支的方式来编写。这样，由于每个叙述都是简短的肯 定句，自然而然增加了未来的扩展空间。

配合“迭代增量”的开发方式，这三个步骤不是一次就全部完成，而必须要分批完成。

项目开始阶段（通常是一到两个星期）必须完成第一个步骤，也就是找出六成用例，在这个部分，切记要保留未来增加用例的空间。

接着，针对用例进行开发顺序的权重排序，这个排序主要针对“复杂度”、“与外部系统的关系”以及“重要性”来进行，权重越高的用例应该要越早开发。

在每个用例中，第二个步骤（找出用例正常流叙述）必须是开发的第一个迭代，在该开发迭代进行到系统设计以及编码阶段时，需求分析师才需要进行第三个步骤的分析，也就是收集更详细的信息以及相关的替代流。

3）关于用例的用例叙述

用例的叙述一般来说至少分成四种：

用例的简述：通常是用一两句话来说明这个用例的目的是什么。

用例的正常流：在这个流程中，必须说明执行者与系统交互的过程，不过在这个交互过程中，必须假设整个流程都必须实现，也就是说这是一个“快乐路径”，在这个流程描述中，所有句子都必须是“肯定句”。

用例的替代流：在正常流中，如果有“替代路径”，必须要利用另外的替代流来说明，而不是直接在正常流中写“if-then-else“。

用例的意外处理：通常指系统例外状态的处理，与替代流不同，替代流往往是执行者对于流程有不同的指示，因为将流程导向不同的结束点，而意外处理则通常是系统发生错误导致的正常流的意外状况。

用例的叙述是非常关键的部分，必须能够准确地把握用户的真正期望是什么，后续的设计工作都将围绕用例特别是用例叙述来展开。

4）编写用例的测试案例

一般来说，在找出用例后就应该编写用例的测试案例，测试案例的编写主要利用“输入→预期产出“的方式来描述，每个测试案例都需要准备对应的测试数据。

三、系统设计阶段

前一阶段的主要产物是用例图，后续的设计和开发阶段都将以用例驱动，围绕用例展开，而系统设计阶段的主要工作，便是实现用例。

1、实现用例

实现用例的目的在于保证系统的设计可以满足用户的功能性需求，在实现用例的过程中，应该利用Jacobson所分类的三种分析类：

控制对象（Control Object） ：控制对象包装了一个或多个用例的功能性需求，属于功能性对象，而且这个功能与用例有相当密切的关系。

实体对象（Entity Object） ：实体对象管理了信息及其衍生资源的存取，是属于系统本质面的概念性对象，这类对象并不会随着用例的增多而有所变动。

边界对象（Boundary Object） ：边界对象是属于与外部桥接的对象，这类对象将与外部直接接轨，直接受到外部的限制。（注意：这里的“对象”并非指类的实例那种对象）

1）勾勒用例的控制对象

① 针对每个用例提供一个“控制对象”

② 明确这个控制对象的责任（Responsibility）是什么

从“主执行者”在正常流的叙述中出现的次数来决定系统要提供几个服务；

再从每一个“对话块”中，“系统”当主语的最后一句话，找出这个责任的名称。

③ 明确这个服务的输入输出

判断这个服务中，是否需要“主执行者”提供什么信息，而“系统”又需要回复主执行者什么信息

④ 进入到服务内部，审视服务的实现方式

在控制对象的内部，每一个以“系统”当主语的叙述都可以独立成一个新的功能函数；

只是该功能函数并非是提供给主执行者的，因此是一个“私有”的函数，只提供给控制对象使用。

勾勒用例的控制对象示例过程

针对前面用例图中的第一个用例“产生请购需求（RFP）”，我们可以提供一个“产生请购需求（RFP）控制对象”。

“产生请购需求（RFP）”的“正常流”叙述：

(1) ERP系统提供[年度物料采购计划]给系统。

(2) 系统根据[BR1]产生[厂商询价推荐名单]。

(3) 系统依照[厂商询价推荐名单]请通知系统将[物料请购需求]传给名单上的厂商。

分析过程如下：

从（1）得知“主执行者”是：ERP系统；

“主执行者”总共出现了1次，也就是所只有一个“对话块”，所以系统要提供1个服务；

“对话块”中“系统”当主语的最后一句（3），可得知系统所需提供的服务是：产生厂商询价推荐名单；

从（1）可知服务的输入是：年度物料采购计划；

从（3）可知服务的输出是：厂商询价推荐名单；

从（2）可知服务内部必须完成的第一件事：根据[BR1]产生[厂商询价推荐名单]；

从（3）可知服务内部必须完成的第二件事：依照[厂商询价推荐名单]请通知系统将[物料请购需求]传给名单上的厂商；

所以从上面两步可知控制对象内部需要两个“私有函数”。

★ 控制对象的类图示例

2）针对控制对象绘制序列图

前面探讨了如何找出信息系统中所需的控制对象，但这样仍然不够，因为前面并没有完整描述出究竟对象与对象之间是如何通力协作，来满足用例所描述的用户需求。因此，必须要使用序列图来说明这个交互过程。

在绘制序列图时，可以采用两阶段序列图绘制法：

① 把信息系统当黑箱，利用用例叙述找出系统所应负责的服务。

这个步骤可以先绘制一个序列图，然后把用例叙述放在该序列图的右方（这样便于对比），然后参照用例图，把相对应的用例转换为一个叫做“系统”的对象。

② 把黑箱打开，加入找出的分析对象，并把系统所需实现的责任分配给适当的对象。

把上个步骤得到的“黑箱”序列图中的“系统”换成实际的控制对象，并且依据找出的控制对象的责任，看看是否一致，这样就完成了序列图的设计了。

★ 控制对象的“黑箱”序列图示例

针对上面的产生请购需求的控制对象，根据步骤①，把信息系统当作一个“黑箱”，便可得到以下序列图：

3）找出用例的实体对象

可 以通过Peter Coad的“交易模式”找出用例的实体对象，这个模式的假设是：当发现企业所关心的问题领域存在必须要记录的某些事件时，这代表着这个事件是一个交易。而 系统设计人员可以从交易出发，依次去找出与这些交易相关的企业概念（人、地、物），如此就可以迅速地得出这个企业的概念模型。

总之，实体对象主要是根据对于问题领域的理解来找出问题领域中的重要概念，对于实体对象的分析，无论是对于进行“实体关系图的”的数据库设计，或是利用“对象模型”做的“结构分析”来说，都是相当重要的设计准则。

实体对象属于领域模型的重要概念，将在下一节“建立领域模型”中重点讲解。

4）系统设计阶段的开发流程

① 通过对用例的理解以及对用例叙述的分析，找出系统的控制对象及其操作。

② 通过与领域专家的访谈过程，找出系统的实体对象以及重要熟悉。

③ 设计人员利用两阶段绘制的序列图，验证前述的控制对象及操作的正确性。

前面通过三种分析类实现用例的方式，会从用例出发分别找出控制对象、实体对象和边界对象，在找出这些“对象”（这里的对象并非指类的实现，而是指一种分析类）之后，便可以建立完整的“领域模型”了。

2、建立领域模型

1）“领域模型”的概念

要了解领域模型，就要先了解何为软件的“本质”：“本质”指得就是要想办法直指想要解决的问题的“核心”。

从软件结构的层面来看，“本质”指的就是你所要解决的问题领域中的重要“概念”在抽象层次的呈现。一般来说，这样的呈现方式的会通过“概念模型”来表示。

“概念模型”就是能够用最简化的方式表达一个完整的“问题领域”的抽象表示法。概念模型的原始定义是表达问题领域中的概念，因此，通常将概念模型称为“领域模型”。

2）使用类图表达领域模型

在UML中通常建议使用“类图”作为表达领域模型的图形。

类图主要表达的是问题领域的“抽象概念”，在这个抽象概念中，除了表达该抽象概念的名称外，另外需要表达该抽象概念的“属性”与”行为”。

类图的主要目的是在进行软件开发前，先对软件所需面对问题领域的本质作一个通盘性的了解，但类图在软件设计之初并不完全正确，必须通过后续的检查才能够逐渐趋近于真实世界的领域模型。

3) 信仁医院住出院管理系统案例演示

接下来将采用信仁医院住出院管理系统的案例来进行演示，为了分析和设计流程的连贯性，将从业务流程分析的部分开始。

（1）住出院系统业务流程

在项目立项之后，需求分析师与医院的领域专家通过面对面的访谈，整理出了医院实际上的住院出院流程，并绘制成活动图。

（2）住出院系统用例模型

需求分析师基于企业的业务流程图，与领域专家通过进一步沟通，进行需求的收集，最终绘制出用例图。当然下图中没有包含用例叙述。

（3）住出院系统领域模型

在得到用例图之后，便进入实现用例的阶段，可以通过上一节所介绍的三种分析类找到问题领域中的重要概念，从而得到领域模型，然后通过类图来表达。

比如针对上一节用例图中的“登记出院记录”用例，通过分析可以得到一个控制对象（登记出院记录BPO）和多个实体对象（病床、病人、医生、护士、病症等），并绘制成如下的类图。

4）包图

通常领域模型中会包含很多的类，必须对这些类进行分类，放置在不同的命名空间中，利用命名空间之间的关系图，来限制住不同分类对象之间的访问，这就是“包图”的使用场景。

“包图”是一个高阶的视图，由于所有的类都必须属于某一个包，因此当包之间的关系被限定时，该包内部所有的类，都会受到包图中设置的影响。

★ 住出院系统包图

比如最基本的分类就是按照上面所说的三种分析类，对上面的领域模型，按照这种方式进行分类，便可以绘制出如下包图：

3、表达对象交互

一般来说，我们在用例分析中将系统应该满足的用户期望找出来了；而在类图中则将系统的架构构造出来。但是，针对每个特定的用例的场景，要如何利用类图所规范的对象，通过交互协作来完成用例所交付的任务，就必须要用序列图来表达。

1）序列图

序列图的主要目的在陈述用例的正常事件流中，对象彼此之间的交互关系。也就是说，序列图的主要来源是用例的叙述。

序列图的主要任务包括：

表达设计人员心中关于将来程序在运行时的对象协作模型

验证软件领域模型的正确性

为程序员提供编码的蓝图

绘制序列图的两点重要建议：

在绘制序列图时，要首先打破一个迷思：序列图并不需要“务求精细”，因为它毕竟只是一个“蓝图”，并非是完整的“施工计划”。

在设计“序列图”时，要遵循一个原则：一个序列图的大小，最好能够限制在一张A4纸可以打印的范围内，最大也不要超过一张A3纸的打印范围。超过这个范围的序列图通常是无效的产出。为了达到这一点，最好把正常流与替代流分开来绘制不同的序列图，每个序列图有自己的重点，不要把所有的逻辑都表达在同一个序列图中。

★ 登记出院记录序列图

针对“登记出院记录”的用例，根据用例叙述，得到以下序列图。

验证领域模型正确性

从前面的类图来看，“登记出院记录BPO”是与“住院事件”想关联的，但在序列图中，“登记出院记录BPO”却是和“病床”有消息传递，这似乎并不符合类图所表达的领域模型。我们可以进一步通过另一个表达对象交互协作的通信图来进行验证。

2）通信图

通信图与序列图其实都是在表达同一件事情：对象相互合作，以实现用例的“事件流”。

为什么要使用通信图进一步验证呢？

由于序列图是以时间做横轴，因此对未来的程序设计而言，序列图具有“蓝图”的效果，但如果需要同时表达对象的结构与彼此间的协作关系，则只有通信图才能较为完整地进行呈现。

究竟项目设计人员在设计序列图时，心中是否对象模型，因此希望项目设计人员能利用“通信图”来重新审视自己对对象模型的理解，来确认序列图有没有违反领域模型。

★ 登记出院记录通信图

3）交互概述图

在绘制序列图和通信图等交互图时，需要注意：

不能“务求精细”过于详尽，因为交互图只需要描述一个“蓝图”而不是完整的“”施工计划；

一张交互图不能太大，最好能在一张A4纸的可以打印的范围内，顶多一张A3纸，否则会成为无效的产出；

每个交互图应该有表达的重点，不要在一个图中表达所有的逻辑，如果有替代流，那么就针对一个替代流再绘制一个单独的交互图。

那么，这些分散的交互图怎么才能组合在一起呢？这时可以利用交互概述图。

交互概述图主要是利用活动图作为基础，只是在“控制流”间连接的UML元素并非活动，而是交互图（包括：序列图、通信图、时间图以及交互概述图）。

4、表达微观设计

1）对象图

对象图旨在描述特定时间点中所有对象在系统中的结构；因此，可以将对象图当成系统在某一个时间点的快照。

对象图表达的是在某一个特定时间点中，系统所存在的所有对象的快照，其主要目的是验证设计师设计的类图是否符合实际状况。

对象图的使用场景：

当与领域专家沟通时，可以用对象图解释类图的设计，以验证类图的正确性。

当与编码人员沟通时，可以利用部分的对象图，来解释类图中的复杂结构。

★ 住出院系统对象图

针对前面设计的信仁医院住出院系统的领域模型，可以参考日剧《白色巨塔》作为范本，将该剧中最重要的一个“佐佐木先生”住院事件转换为对象图。

2）状态机图

类图中某一个实体对象，它的状态迁移分散在不同的用例中，需要在这些状态和事件之间进行一番整理，才能让项目开发人员更简便地完成设计，这时可以使用状态机图来表达。

为了成功地设计软件，将“状态”分配到不同的“领域模型”中，并利用“状态机图”来表达这些状态的迁移情形。

★ 病床状态机图

在信仁医院住出院系统的领域模型中，有一个“病床”实体对象，它的状态迁移分散在不同的用例中，可以使用如下状态机图统一表达这些状态的迁移。

3）时间图

如果在状态迁移中牵涉到时间因素，则可以利用时间图来强调事件因素的重要性。设计人员可以把时间图当成状态机图的辅助说明工具。

★ 过期取消预定时间图

关于前面病床的撞他，如果病人预定了病床，但是后来一直没有去使用病床，那么这个病床该怎么办呢？总不能直接空着吧？关于这一点，信仁医院的处理是这样的：超过半小时病床状态要自动迁移到Empty。这个设计内容很难在状态机图中表达，这时可以使用时间图。

总结和展望

到此为止，本文已经讲解了需求分析阶段和系统设计阶段使用的主要UML图，除了这些图之外，还有其他UML图，本文不做过多介绍。

本文由哈喽比特于2年以前收录，如有侵权请联系我们。
文章来源：http://mp.weixin.qq.com/s?__biz=MzIyNjE4NDcyMA==&mid=2247493889&idx=1&sn=5ecd2adbd531a1a610a719c91fc382b1&chksm=e876f27edf017b68a83fd8847ad7a776cff8a82015dfae218fe5e22cfe4c35d5755c89b6004c&mpshare=1&scene=1&srcid=0314gfGYPrCkaJNUDL34WgVA&sharer_sharetime=1647221944831&sharer_shareid=7f2af9604fbdc84c4e358e57e738e84a#rd