系统分析与设计方法 · UML 结构与用例图

统一建模语言 UML，Unified Modeling Language，是用于系统的可视化建模语言，它将 OMT、OOSE 和 Booch 方法中的建模语言和方法有机地融合在一起，是国际统一的软件建模标准。虽然它源于面向对象软件系统建模领域，但由于其内建了大量扩展机制，也可以应用于更多的领域，例如工作流程、业务领域等。原文还从五个角度定义了 UML 是什么，逐条来。

UML 是一种语言：它在软件领域中的地位与价值就像数字和加减号等符号在数学领域中的地位一样，为软件开发人员之间提供了一种用于交流的词汇表和一种用于软件蓝图的标准语言。UML 是一种可视化语言：它只是一组图形符号，每个符号都有明确语义，是一种直观、可视化的语言。UML 是一种可用于详细描述的语言：UML 所建的模型是精确的、无歧义和完整的，因此适合于对所有重要的分析、设计和实现决策进行详细描述。

UML 是一种构造语言：UML 虽然不是一种可视化的编程语言，但其与各种编程语言直接相连，而且有较好的映射关系，这种映射允许进行正向工程、逆向工程。注意「不是编程语言」这句，判断题常考。UML 是一种文档化语言：它适合于建立系统架构及其所有的细节文档。五个「是」——语言、可视化语言、详细描述语言、构造语言、文档化语言。

UML 由构造块、公共机制和架构三个部分组成。先说构造块，它就是基本的 UML 建模元素，分为三类：事物、关系和图。建模元素也就是事物包括：结构事物，有类、接口、协作、用例、活动类、组件、节点等；行为事物，有交互、状态机；分组事物，就是包；注释事物。关系包括四种：关联关系、依赖关系、泛化关系、实现关系。图，UML 2.0 包括 14 种不同的图。

14 种图按动静分组，原文的清单要背。静态模型，表示系统静态结构，包括：类图、对象图、包图、构件图、部署图、制品图，六种。动态模型，表示系统动态结构，包括：对象图、用例图、顺序图、通信图、定时图、状态图、活动图、交互概览图，八种。加起来正是十四种。

对，原文就是这么写的——静态模型里有对象图，动态模型里也有对象图，两处重叠后合计还是 14 种。考试若数静态是六种、动态是八种，加一个重复的正好十四。最容易考的几对归类：类图是静态，顺序图、通信图、定时图是动态交互图，状态图、活动图是动态行为图。

公共机制是指达到特定目标的公共 UML 方法，主要包括 4 种：规格说明、修饰、公共分类和扩展机制。规格说明，是元素语义的文本描述，它是模型的重要组成部分。修饰，UML 为每一个模型元素设置了一个简单的记号，还可以通过修饰来表达更多的信息。公共分类，包括两组：类元与实体，类元表示概念，而实体表示具体的实体；接口和实现，接口用来定义契约，而实现就是具体的内容。

扩展机制包括三种：约束，添加新规则来扩展元素的语义；构造型，用于定义新的 UML 建模元素；标记值，添加新的特殊信息来扩展模型元素的规格说明。这三个的定义将来做选项时按关键词对号：新规则对约束、新建模元素对构造型、新信息对标记值。

UML 对系统架构的定义是：系统的组织结构，包括系统分解的组成部分、它们的关联性、交互、机制和指导原则，这些提供系统设计的信息。而具体来说，就是指 5 个系统视图：逻辑视图，以问题域的语汇组成的类和对象集合；进程视图，可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例；实现视图，对组成基于系统的物理代码的文件和组件进行建模；部署视图，把组件物理地部署到一组物理的、可计算的节点上；用例视图，最基本的需求分析模型。

用例视图处在中心，描述系统外部看到的系统功能，其余四个视图围绕它展开，所以俗称 4 加 1 视图。选择题问「最基本的需求分析模型是哪个视图」，答用例视图；问「逻辑视图的一次执行实例是哪个视图」，答进程视图——这两问都是原文的精确表述。

Ivar Jacobson 是这样描述的：用例实例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果，一个用例定义一组用例实例。从定义里抠三个要点：第一，用例是由一组用例实例组成的，用例实例也就是常说的使用场景，就是用户使用系统的一个实际的、特定的场景；第二，用例应该给参与者带来可见的价值，这点很关键；第三，用例是在系统中的。

用例模型描述的是外部参与者所理解的系统功能，用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。用例是对系统行为的动态描述，它可以促进设计人员、开发人员与用户的沟通，还可以划分系统与外部实体的界限，是系统设计的起点。

不是，这是最容易错的地方。参与者代表与系统接口的任何事物或人，它是指代表某一种特定功能的角色，因此，参与者都是虚拟的概念。在 UML 中，用一个小人表示参与者。原文举例：可能可以充当图书管理员角色的有多个人，由于他们对系统均起着相同的作用，扮演相同的角色，因此只用一个参与者来表示。切忌不要为每一个可能与系统交互的真人画出一个参与者。

原文给了一串帮助识别用例的问题：每个参与者的任务是什么？有参与者将要创建、存储、修改、删除或读取系统中的信息吗？什么用例会创建、存储、修改、删除或读取这个信息？参与者需要通知系统外部的突然变化吗？需要通知参与者系统中正在发生的事情吗？什么用例将支持和维护系统？所有的功能需求都对应到用例中了吗？系统需要何种输入输出，输入从何处来，输出到何处？当前运行系统的主要问题是什么？这串问题的功能是帮助你从参与者出发穷举用例，本身也能出「以下哪个问题不用于识别用例」之类的题。

两个用例之间的关系可以主要概括为两种情况：一种是用于重用的包含关系，用构造型 include 或者含箭头表示；另一种是用于分离出不同的行为，用构造型 extend 表示。原文措辞先记骨架，再拆第 8 题。

正确答案是从两个或两个以上的原始用例中提取公共行为，或者发现能够使用一个组件来实现某一个用例的部分功能是很重要的事时，应该使用包含关系来表示，所提取出来的公共行为称为抽象用例。干扰项逐个拆：B 选项「分离出不同行为场景」是扩展关系的作用；C 选项「定义新的 UML 建模元素」是构造型扩展机制的作用，注意这题偷换了概念，把构造型和用例的构造型关系混在一起；D 选项「添加新规则来扩展元素的语义」是约束的作用。第 8 题等于把这一集和 UML 扩展机制串在一起考，你四条定义都背了才稳。

扩展关系再补全：如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种事情，可以将这个用例分为一个主用例和一个或多个辅用例，描述可能更加清晰，这就用扩展关系。一句话区分：包含是提取公共、扩展是分离场景。还有希赛教育专家提示：此处介绍的包含和扩展关系属于用例之间所特有的关系，因为用例也是 UML 的一种结构事物，因此，事物之间的 4 种基本关系对用例也是适用的。

本集必背：UML 融合 OMT、OOSE、Booch，是国际统一的软件建模标准；五个「是」——语言、可视化语言、详细描述语言、构造语言、文档化语言，不是可视化编程语言但支持正向逆向工程；UML 由构造块、公共机制、架构组成；事物分结构、行为、分组即包、注释四类，关系有关联、依赖、泛化、实现四种；14 种图，静态六种是类图、对象图、包图、构件图、部署图、制品图，动态八种是用例图、顺序图、通信图、定时图、状态图、活动图、交互概览图、对象图；

公共机制四条是规格说明、修饰、公共分类、扩展机制，扩展机制里构造型定义新建模元素、约束加新规则、标记值加新信息；5 个系统视图，用例视图是最基本的需求分析模型，进程视图是逻辑视图的一次执行实例；用例给参与者带来可见的价值；参与者是虚拟的角色不是真人；包含关系提取公共行为称抽象用例，扩展关系分离不同场景。

下一集把类图这块硬骨头啃了：类的三格表示、属性和操作的语法、四种类关系各自的图形记号——依赖虚线箭头、泛化空心箭头实线、聚合空心菱形、组合实心菱形、实现空心箭头虚线（第 7 题和第 15 题），还有多重性的读写。