《大象：thinking in uml 》(第二版) 5章 UML核心模型

只供参考，喜欢请支持正版图书

5.1 用例模型概述

用例模型的好坏将决定整个开发过程的好坏。

用例模型是系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的契约。用例是贯穿整个系统开发的一条主线。用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用
随着迭代的进行，用例不断地被识别，然后被实现，软件离现实世界的要求也就越来越近

到这里为止，我们只是粗略窥视了用例模型的综合概念。我们谈到过用例有三个层次解释：业务用例、概念用例、系统用例，自然地，用例模型也就有业务用例模型、概念用例模型和系统用例模型三个层次的模型，如图5.2所示。
业务用例模型用于识别和规定业务需求，概念模型用来分析和确认业务需求，而系统用例模型用来规定系统开发需求。这三者之间是一种精化的关系。

5.2 业务用例模型

我们习惯上理解的需求指的是系统需求，也就是大家熟悉的“软件需求规格说明书”里所描述的内容。系统需求是软件系统要实现的功能范围的契约，它与计算机软硬件环境是紧密相关的，受制于计算机环境。在统一过程中，系统需求是由系统用例模型来说明的。然而软件需求只是整个需求过程的一部分，它仅仅说明要在计算机里实现的那一部分业务需求，软件需求是来源于业务需求，业务需求即业务用例模型所描述的内容。

我们大都忽略了一个事实，要想得到系统需求，正确地理解现实业务是前提条件。很多时候我们并不重视业务理解，在调研需求的过程中，我们只是让业务理解存在于交谈过程中，停留在需求调查表里，淹没在往来邮件中，从没有想过是否应当为这些业务理解建立一个模型

为什么要建立业务模型呢？这是因为业务用例模型的目的是为现存的或客户预想中的真实业务建立模型，是我们为了理解客户的业务，并与客户达成业务理解上的共识而建立的模型，它不需要考虑计算机环境。相对于系统模型来说，业务模型是对现实业务的一种直观的理解，而没有加入其他的因素，因而更容易在客户和开发双方达成共同理解。

应当明确，业务用例模型讲述的是业务范围，与系统用例模型讲述的系统范围（需求范围）是不同的。因此，建立业务用例模型是为了理解客户业务，相当于对客户业务的整理和重现。它必须尊重事实，不要带有计算机设计的思考在里面。业务用例模型将在业务方和承建方之间建立这样的共识：要建立的计算机系统所面对的问题领域就是这个样子的

例如假设客户的计算机环境不具备宽带网络环境，即使客户预想的业务中有视频播放方面的要求或者大文件传输的要求，在业务用例模型中应当建立，但是否应该纳入系统用例模型就是值得商榷的

业务用例模型采用业务用例来绘制，表达业务的观点。然而，业务用例模型并不仅仅是很多人理解的由主角和业务用例绘制而成的视图，视图只是一个提纲和高层展示。图5.3展示了完整的业务用例模型应该具有的必要视图和工件，它们共同完成业务建模的工作。

5.2.1 业务用例模型主要内容

■　业务用例视图
业务用例视图包括业务主角和业务用例，它是业务的高层和概要视图，并作为其他建模要素的组织点存在。狭义理解就是我们一般所说的业务用例模型

■　业务用例场景
业务用例场景说明业务用例的执行过程，说明业务主角是如何使用业务用例完成业务目标的

■　业务用例规约
业务用例规约针对每一个业务用例编写，它要说明业务用例的使用者、目标、场景、相关业务规则、相关业务实体等

■　业务规则
业务规则是客户执行其业务必须遵守的法律法规、惯例、各种规定，也可能是客户的操作规范、约束机制等。业务规则可能影响软件外观、内部功能甚至架构

■　业务对象模型
描述业务模型中关键的业务对象，以及它们是如何贡献于业务目标的

■　业务用例实现视图
将业务用例实现用实现关系连接到业务用例，每一个业务用例实现代表了业务用例目标的一种实现方式。

■　业务用例实现场景
针对每一个业务用例实现，说明该实现方式的步骤。与业务用例场景类似，但更为明确。

■　包图
包图组织业务用例。可以按业务模块分包，也可以按业务主角分包，还可以按组织结构分包。

5.2.2 业务用例模型工件的取舍

除了图中所展示的必要工件外，业务用例模型还有其他一些工件。但不是什么时候都要完成所有工件。表5-1摘自统一过程官方文档，它给出了业务用例模型工件的取舍参考。

5.2.3 何时使用业务用例模型

毋庸置疑，业务用例模型是重要的。但是，业务用例模型是针对商业组织建模的，并不是所有的软件都需要从业务用例建模开始。下面笔者归纳了一些使用和不使用业务用例模型的理由，供读者参考。使用业务用例模型的理由：

■　你将开发一个针对商业组织的软件。
■　你将开发一个交互密集型软件。
■　你将开发一个较大规模的软件。
■　你所面对的问题领域有复杂的组织结构。
■　你所面对的业务有许多业务流程。
■　客户希望借信息化过程进行业务重组或优化。
■　你对这个行业的业务了解不多，因而希望首先对业务有清楚的认识。
■　你希望借由一个软件开发而打入一个行业应用软件市场。
■　虽然已经对这个行业的业务了如指掌，但你希望做行业标准，因而想要建立业务架构。
■　客户已有许多孤立的遗留系统，希望做应用整合。

不使用业务用例模型的理由：
■　你将开发一个非商业组织应用软件，如嵌入式系统。
■　你将开发一个计算密集型软件，如编码解码器。
■　你将开发的软件规模很小，如个人桌面软件。
■　你所面对的问题领域组织结构单一，如一个报表统计系统。
■　你所面对的问题领域没有或仅有很简单的业务流程，如网络论坛系统。
■　客户的信息系统已经非常成熟，只想做一些外围的小应用。
■　你对行业业务十分精通，想要快速和低成本完成项目，并且不打算做行业标准。
■　虽然对业务不大了解，但你正在进行的项目是一锤子买卖，将来不会在这个行业深入下去。

5.3 概念用例模型

概念用例模型位于先启阶段，有时在精化阶段进行，是业务用例建模的一个子集。在统一过程的官方文档中并未强调概念用例的建立，也没有专门的工作流来完成它们。但是笔者在实际工作中感受到它们的重要，因而特别用一节来讲述。这是因为当系统规模较大时，业务用例的粒度相应也会比较大，通常一个业务用例所能描述的业务很粗略。而系统用例由于必须适应软件开发的需要，其粒度需要较小，有时候甚至小到一次计算机交互的粒度。显然，从一个很粗粒度的业务用例过渡到很细粒度的系统用例存在着很多困难。而如果试图缩小一些业务用例的粒度，则又会导致业务用例数据激增。

例如，一个涉及工厂、物流、经销商、零售商、银行的管理系统，在业务用例建模时，比较适合的业务用例粒度类似于工厂→生产商品、物流公司→运输商品等。从这些庞大的业务用例中能够得到的业务对象、用例场景都是很粗略的。就拿生产商品业务用例来说，其粒度已经基本相当于一个子系统规模了，要想通过对它的分析来导出系统用例有着很大的困难

这时，我们需要一种方法来“分解”那些较大的业务用例，从中找到关键和核心的工作单元，针对这些工作单元建立模型来简化业务。这个模型能帮助我们更深入地理解业务用例，同时，通过这个模型的建立，我们将得到一组“缩小”了粒度的用例。即使我们不会对所有业务用例都进行这样的“分解”活动，一部分的“分解”结果也能够作为参照为我们从业务用例模型过渡到系统用例模型提供帮助。另一方面，这个模型的建立也能够帮助我们建立业务架构（如果需要）。

这种“分解”行动所产生的结果就是概念用例。请注意分解两字的引号，实际上用例不是功能，是不可分解的，同时由于用例具有“原子”性，用例也是不能分解的。正确的说法是抽象。抽象出的概念用例通过包含、泛化、扩展关系连接到基本业务用例

我们需要一种方法能够从业务用例中“抽取”出针对某个关键业务流程产生贡献的工作单元，再用这些工作单元来组织成这个业务流程，以得到对业务流程的理解。这个抽取过程也是概念用例的建立过程

5.3.1 概念用例模型的主要内容

■　概念用例视图概念用例视图将得到的概念用例用包含、泛化、扩展关系连接到基本业务用例，表示这些概念用例的来源及它们服务于哪个或哪些业务用例

■　概念用例分析
概念用例分析是从业务用例模型中挑选出重要和典型的业务用例场景，可能只是部分场景，也有可能跨多个业务用例，然后将得到的概念用例集中起来，绘制这些概念用例如何贡献或者说如何实现这些业务用例场景。

■　分析类视图
分析类视图绘制出从概念用例分析过程中抽象出的分析类的静态关系。分析类得到我们理解系统实现的第一个关口

■　分析场景
分析场景使用分析类绘制对象交互图，从对象的角度去实现概念用例分析场景。这些结果将对下一步建立软件架构和决定系统用例产生影响

5.3.2 获得概念用例

获取概念用例主要通过以下途径

■　观察现有的业务用例场景，发现那些有着相似名称，在不同的业务用例场景中多次出现，或者位于不同的泳道中的活动。这些活动很可能就是关键的工作单元，以此来获得备选的概念用例

■　通过对客户业务的分析，或者咨询业务专家，得知对客户来说最为重要的一些业务实体。然后了解对这些业务实体可能进行的主要操作来获得备选的概念用例

■　通过对客户业务流程的分析，或者咨询业务专家，得知对客户来说最为关心，影响整个流程成败的关键业务环节，然后了解这些关键业务环节做什么，以此来获得备选的概念用例。

■　通过绘制概念用例分析来检验备选的概念用例。关键的概念用例总是在许多业务用例场景中决定场景成败，控制场景进程，或者产生和控制最为重要的业务实体。

5.3.3 何时使用概念用例模型

使用概念用例模型的理由：
■　你所面对的业务领域规模庞大，业务用例粒度较大，不容易过渡到粒度较小的系统用例。
■　你所面对的业务领域业务是网状交叉的，有跨业务用例的业务流程存在。
■　某个业务用例场景过于复杂，步骤和分支过多，使用活动图绘制用例场景困难。
■　有超过7、8个甚至更多的泳道存在。
■　你想在项目早期就获得系统原型。
■　你想在项目早期就开始建立软件架构。
■　你是第一次开发这样的系统，对系统用例的决定有疑问。

不使用概念用例模型的理由：
■　你所面对的业务领域规模较小，业务用例粒度较小，很容易过渡到系统用例。
■　你所面对的业务领域较为单纯，基本上业务用例之间没有交叉业务。
■　业务用例场景简单，一般不超过10个步骤。
■　你不打算太早建立软件架构。
■　你已经不是第一次开发这样的系统，对如何决定系统用例驾轻就熟。

5.4 系统用例模型

系统建模就是我们通常所说的需求获取，系统用例模型也就是我们熟悉的用例模型。所以本节也将省略系统二字，直接使用用例模型这一叫法

用例模型要完整的描述需求，图5.5所展示的工件都是建立用例模型需要完成的

5.4.1 系统用例模型的主要内容

■　业务用例
在系统用例模型中用例使用精化关系连接到业务用例，表明软件过程的可追溯性，说明哪些用例是从哪个或哪些业务用例演化出来的。如果没有经历业务建模过程，业务用例就不需要表达追溯关系

■　概念用例
作为从业务用例到系统用例的过渡，概念用例对用例模型来说只起到获取用例的指导作用。它作为用例模型的附加说明存在

■　用例视图
用例视图包括参与者与用例，是系统功能性需求的高层视图。从狭义上理解就是一般我们所说的用例模型。该视图表达了功能性需求的全部

■　用例规约
用例规约应采用文档形式描述参与者如何启动和终止用例，参与者如何使用用例完成目标，用例的执行事件流，相应的规则等内容。

■　补充规约
补充规约应说明与用例相关的非功能性需求。例如响应时间、可靠性、可用性等。

■　业务规则
业务规则是客户执行其业务必须遵守的法律法规、惯例、各种规定，也可能是客户的操作规范、约束机制等

■　用例实现
一个用例实现是用例的一种实现方式，通常代表不同的应用环境。例如可以通过电话、网站、业务代理完成同一个缴纳电话费用例。

■　用例场景
用例场景说明参与者如何与计算机（即代表了计算机逻辑的分析对象）之间交互以达成其目的。可以使用任何一种交互图来描述

■　分析对象
分析对象是用例场景中代表计算机逻辑的概念化产物。它是将来分析模型的重要来源。

5.4.2 获得系统用例

推导系统用例的基本方法是分析业务用例场景，尤其是活动图。因为采用活动图绘制业务用例场景时将业务主角和业务工人作为泳道，因此特别方便观察他们的职责（活动）。系统用例可以从这些职责里抽取出来

■　排除用例
如果参与者不使用计算机来使用这个用例，则可以排除它，如果该用例可以用计算机实现，但是代价巨大，是项目成本不可承受的，则与客户沟通，更换实现方案或者放弃它。

■　合并用例
观察剩下的候选用例，分析参与者使用它们的目的。目的通常可以从参与者关心的结果看出来。虽然候选用例可能有不同的名字，但是如果它们的结果是相同的或相似的，应当考虑合并它们

例如虽然审批A文件、审查B文件是两个不同的候选用例，但是它们的结果都导致某业务得到批准，那么可以考虑合并为一个审查文件用例。合并后，审批A文件和审查B文件是审查文件用例的泛化。

■　抽象用例
例如查询A报表和查询B报表是两个不同的目的，有不同的结果。但是它们选择查询条件的过程是一样的，可以考虑抽象出一个设置查询条件的用例，查询A报表和查询B报表都包含这个用例

■　补充用例
向用例模型中加入那些与业务实现无关，但对系统运行必须的非业务需求。例如管理用户账号、备份系统数据等

5.5 领域模型

本书遵循的是用例驱动方法（UDD），而不是领域驱动方法（DDD）

5.5.2 基本概念

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

■　业务对象实体，表示业务中使用到或产生的东西。如定单、账号、合同等。
■　系统需要处理的现实世界中的对象和概念。如商品、买家、卖家等。
■　将要发生或已经发生的事件。如购买、撤单、付费等。

5.5.3 领域模型的主要内容

你需要做的是从业务场景出发，针对某些重要的业务问题来建立领域模型，再用业务对象去验证该模型。所以笔者建议先建立业务模型，再来推导领域模型，见图5.6

5.6 分析模型

分析模型应当成为面向对象设计的核心，因为：

■　分析模型是采用分析类在软件架构和框架的约束下来实现用例场景的产物。如果分析类完全实现了这些用例和场景，我们就能肯定地说分析类已经满足了需求。

■　分析模型是高层次的系统视图，在语义上，分析类不代表最终的实现。它是计算机系统元素的高层抽象。分析类具化以后才产生真正的实现类。

■　相对而言，设计模型只是分析模型的一种实现手段，分析类具化以后才产生真正的实现类。如果分析模型建立得很好，再具体化分析类形成实现类是很容易的。

■　分析模型是MVC模式的经典应用。从分析类的名称就可以看出来。读者应当还记得笔者反复谈到的一个观点：“商业系统无论多复杂，无论什么行业，其本质无非是人、事、物、规则。人是一切的中心，人做事，做事生物，规则限制人、事、物。人驱动系统，事体现过程，物记录结果，规则则是控制。无论面向对象
也好，UML也好，复杂的表面下其实只是一个简单的法则，系统分析员弄明白有什么人，什么人做什么事，什事产生什么物，中间有什么规则，再把人、事、物之间的关系定义出来，商业建模也就基本完成了。”对比分析类的名称，考虑一下MVC模式，读者应该能够发现分析类在对象世界和现实世界中精妙的对应关系：人、事、物、规则——参与者、边界类、实体类、控制类

5.6.1 如何使用分析模型

获得分析类的方法并不复杂，笔者推荐先采用时序图，在用例场景中的参与者与系统之间加入一个边界类代表操作界面，在边界类与实体交互之间加入一个控制类代表业务逻辑，然后对照用例场景，一步一步忠实地把用例场景过程用分析类实现出来。例如一个网上购物的业务场景，用分析类绘制的结果如图5.7所示

由于分析类采用了MVC模式，所以在定义分析类之间的关系时，应当注意以
下几个原则：
■　边界类不应当与实体类之间有依赖关系。边界类只能通过控制类与实体类交互。
■　实体类和实体类之间可以有聚合或组合关系，但不应当有依赖关系。它们不应当直接交互，而只能通过控制类间接交互。
■　控制类和控制类之间不应当有聚合或组合关系，如果可能，应当尽量减少依赖关系。
■　正确的依赖关系应当是边界类依赖于控制类，控制类依赖于实体类，而不能反过来。

5.6.2 分析模型的主要内容

图5.9展示的各个视图就是分析模型要完成的工作

5.6.3 分析模型的意义

分析模型采用MVC模式，将用例场景中描述的业务分解为边界（操作界面和展示界面）、控制（业务逻辑）和实体（业务数据），用这三个元素建立实现用例场景的对象模型。分析模型一方面为我们提供了系统如何实现需求的理解，一方面为下一步演化到设计模型提供了极好的输入

5.7 软件架构和框架

现实中，很多人把架构和框架搞混，有的人认为架构和框架就是同一个东西。实际上架构和框架是非常不同的。框架是针对某个问题领域的通用解决方案，它通常集成了最佳实践和可复用的基础结构，对开发工作起到减少工作量、指导和规范作用。

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

5.7.1 软件架构

这两个方面分别针对业务领域的理解和系统领域的理解，我们可以称之为业务架构和软件架构

5.7.1.1 业务架构

业务架构在先启阶段建立，在精化阶段得以改进。业务架构的目标是为业务领域建立一个维护和扩展的逻辑结构，描述业务的构成。业务架构对我们理解客户业务，尤其是开发行业解决方案有着重要的作用。另一方面，业务架构是软件架构的重要输入

业务架构来源于两个主要的输入：业务用例和领域模型

业务架构可以使用领域包和组织结构包来表示业务主要领域和组织结构关系。图5.10展示了一个网上购物系统的业务架构示例

5.7.1.2 软件架构

软件架构需要在业务架构的基础上引入计算机环境，计算机环境包括硬件环境和软件环境。硬件环境指网络拓扑结构、服务器及其他设备等，而软件环境则指操作系统、应用服务器、中间件、数据库以及其他第三方支持软件等。软件架构需要说明业务架构如何分布在计算机环境中，并得以执行。

一个典型的软件架构包括两个视角：广度视角和深度视角

广度视角即是常见的软件层次结构，它关注软件的分层，规定每一层的职责以及层之间的通信标准。一般使用层包元素来绘制。图5.12展示了一个典型的多层架构的层次模型
软件架构还需要描述深度视角。所谓深度视角，是指广度视角中每一层的详细说明，它关注每一层以及每个部分的具体实现架构。例如可以针对业务实体层进行架构描述，也可以针对XMLBean进行架构描述。图5.13展示了业务实体层的深度视角视图，这个视图仅仅是为了说明，读者不必研究这个视图的合理性

5.7.2 软件框架

前面已经说过，软件框架是针对一个普遍问题的最佳实践或解决方案，它通常都是一个半成品，提供基本类库、编程模型和编程规范，甚至包括IDE工具。例如，J2EE是企业级应用的架构，为了解决异步通信的问题，各厂商依据各种消息规范开发出许多解决这一问题的框架，例如IBM的MQ。这些解决方案都包含有规范、开发支持环境，甚至IDE工具，以及运行时环境等。再例如，为了解决OR-Mapping的问题，许多开源框架被开发出来，Hibernate就是其中著名的一种。

5.7.3 何时使用架构和框架

5.8 设计模型

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

5.8.2 设计模型的主要内容

5.8.3 从分析模型映射到设计模型

下面将讨论实现分析角色的可能方法：
■　一个分析类可以成为设计模型中的单个类。
■　一个分析类可以成为设计模型中某个类的一部分。
■　一个分析类可以成为设计模型中的一个聚合关系类（这意味着不能在分析模型中直接建立此聚合关系类各部分的模型）。
■　一个分析类可以成为设计模型中从同一个类继承而来的一组类
■　一个分析类可以成为设计模型中一组功能相关的类。
■　一个分析类可以成为设计模型中的一个包（这意味着它可以成为一个构件）。
■　一个分析类可以成为设计模型中的一项关系。
■　分析类之间的一项关系可以成为设计模型中的一个类。
■　分析类主要处理功能性需求以及来自“问题”领域的模型对象；设计类则处理非功能性需求以及来自“解决方案”领域的模型对象。
■　分析类可用来代表“我们希望系统支持的对象”，而不用决定用硬件支持分析类的多大部分，用软件支持分析类的多大部分。因此，某个分析类的一部分可以通过硬件来实现，根本不用在设计模型中建模。

5.9 组件模型

5.9.1 何时使用组件模型

5.9.2 广义组件的用法

■　你打算描述应用系统中的各个逻辑模块之间的关系，可以使用组件模型。这时候组件代表的含义是模块，如登录模块

■　你打算描述应用系统中各个子系统之间的关系，可以使用组件模型。这时候组件代表的含义是子系统，如发布话题子系统

■　你打算描述应用程序中使用到的或生成的各个公共或基础类库之间的关系，可以使用组件模型。

■　你打算描述应用系统中各个可执行部分之间的关系，可以使用组件模型

■　你打算描述应用系统中各个程序包之间的关系，可以使用组件模型

5.10 实施模型

作为例子，图5.20展示了图5.18所示论坛系统组件的实施模型

只供参考，喜欢请支持正版图书