4.OOSE 方法
OOSE 是面向对象软件工程的缩写，它是由 Ivar Jacobson 提出的。它在 OMT 的基础
上，对功能模型进行了补充，提出了“用例”的概念，最终取代数据流图进行需求分析和建
立功能模型。
8.4.3 统一建模语言
统一建模语言（Unified Modeling Language，UML）是用于系统的可视化建模语言，它将
OMT、OOSE 和 Booch 方法中的建模语言和方法有机地融合在一起，是国际统一的软件建
模标准。虽然它源于 OO 软件系统建模领域，但由于其内建了大量扩展机制，也可以应用
于更多的领域中，例如工作流程、业务领域等。
1．UML 是什么
UML 是一种语言：UML 在软件领域中的地位与价值就像“1、2、3、+、 、…”等符号在
数学领域中的地位一样。它为软件开发人员之间提供了一种用于交流的词汇表和一种用于软
件蓝图的标准语言。
UML 是一种可视化语言：UML 只是一组图形符号，它的每个符号都有明确语义，是一种直
观、可视化的语言。
UML 是一种可用于详细描述的语言：UML 所建的模型是精确的、无歧义和完整的，因此适
合于对所有重要的分析、设计和实现决策进行详细描述。
UML 是一种构造语言：UML 虽然不是一种可视化的编程语言，但其与各种编程语言直接相
连，而且有较好的映射关系，这种映射允许进行正向工程、逆向工程。
UML 是一种文档化语言：它适合于建立系统架构及其所有的细节文档。
2．UML 的结构
UML 由构造块、公共机制和架构三个部分组成。
（1）构造块。构造块也就是基本的 UML 建模元素（事物）、关系和图。
建模元素：包括结构事物（类、接口、协作、用例、活动类、组件、节点等）、行为事物（交
互、状态机）、分组事物（包）、注释事物。
关系：包括关联关系、依赖关系、泛化关系、实现关系。
图：UML 2.0 包括 14 种不同的图，分为表示系统静态结构的静态模型（包括类图、对象图、
包图、构件图、部署图、制品图），以及表示系统动态结构的动态模型（包括对象图、用例
图、顺序图、通信图、定时图、状态图、活动图、交互概览图）。
（2）公共机制。公共机制是指达到特定目标的公共 UML 方法，主要包括规格说明、
修饰、公共分类和扩展机制 4 种。
规格说明：规格说明是元素语义的文本描述，它是模型的重要组成部分。
修饰：UML 为每一个模型元素设置了一个简单的记号，还可以通过修饰来表达更多的信息。
公共分类：包括类元与实体（类元表示概念，而实体表示具体的实体）、接口和实现（接口
用来定义契约，而实现就是具体的内容）两组公共分类。
扩展机制：包括约束（添加新规则来扩展元素的语义）、构造型（用于定义新的 UML
建模元素）、标记值（添加新的特殊信息来扩展模型元素的规格说明）。
（3）架构。UML 对系统架构的定义是：系统的组织结构，包括系统分解的组成部分、
它们的关联性、交互、机制和指导原则，这些提供系统设计的信息。而具体来说，就是指 5
个系统视图。
逻辑视图：以问题域的语汇组成的类和对象集合。
进程视图：可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例。
实现视图：对组成基于系统的物理代码的文件和组件进行建模。
部署视图：把组件物理地部署到一组物理的、可计算的节点上。
用例视图：最基本的需求分析模型。
3．用例图基础
用例是什么呢？Ivar Jacobson 是这样描述的：“用例实例是在系统中执行的一系列动作，
这些动作将生成特定参与者可见的价值结果。一个用例定义一组用例实例。”首先，从定义
中得知用例是由一组用例实例组成的，用例实例也就是常说的“使用场景”，就是用户使用
系统的一个实际的、特定的场景。其次，可以知道，用例应该给参与者带来可见的价值，这
点很关键。最后，用例是在系统中的。
而用例模型描述的是外部参与者所理解的系统功能。用例模型用于需求分析阶段，它的
建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。图
8-12 就是一个用例图的例子。
（1）参与者。参与者代表与系统接口的任何事物或人，它是指代表某一种特定功能的
角色，因此，参与者都是虚拟的概念。在 UML 中，用一个小人表示参与者。
图 8-12 中的“图书管理员”就是参与者。对于该系统来说，可能可以充当图书管理员
角色的有多个人，由于他们对系统均起着相同的作用，扮演相同的角色，因此只用一个参与
者来表示。切忌不要为每一个可能与系统交互的真人画出一个参与者。
（2）用例。用例是对系统行为的动态描述，它可以促进设计人员、开发人员与用户的
沟通，理解正确的需求，还可以划分系统与外部实体的界限，是系统设计的起点。在识别出
参与者之后，可以使用下列问题帮助识别用例。
每个参与者的任务是什么？
有参与者将要创建、存储、修改、删除或读取系统中的信息吗？
什么用例会创建、存储、修改、删除或读取这个信息？
参与者需要通知系统外部的突然变化吗？
需要通知参与者系统中正在发生的事情吗？
什么用例将支持和维护系统？
所有的功能需求都对应到用例中了吗？
系统需要何种输入/输出？输入从何处来？输出到何处？
当前运行系统的主要问题是什么？
（3）包含和扩展。两个用例之间的关系可以主要概括为两种情况。一种是用于重用的
包含关系，用构造型<<include>>或者<<use>>表示；另一种是用于分离出不同的行为，用构
造型<<extend>>表示。
包含关系：当可以从两个或两个以上的原始用例中提取公共行为，或者发现能够使用一个组
件来实现某一个用例的部分功能是很重要的事时，应该使用包含关系来表示。所提取出来的
公共行为称为抽象用例。包含关系的例子如图 8-13 所示。
扩展关系：如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多
种事情。可以将这个用例分为一个主用例和一个或多个辅用例，描述可能更加清晰。扩展关
系的例子如图 8-14 所示。
希赛教育专家提示：此处介绍的包含和扩展关系属于用例之间所特有的关系，因为用例
也是 UML 的一种结构事物，因此，事物之间的 4 种基本关系对用例也是适用的。