|
|
知识路径： > 信息化和信息系统 > 信息系统及其技术和开发方法 > 软件工程 > 面向对象的分析、设计与开发 >
|
被考次数：29次
被考频率：高频率
总体答错率：42%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
考试要求：熟悉
相关知识点：4个
|
|
|
|
|
|
|
|
|
统一建模语言（Unified Modeling Language，UML）是一种通用的可视化建模语言，它是面向对象分析和设计的一种标准化表示，用于对软件进行描述、可视化处理、构造和建立软件系统的文档。
|
|
|
|
UML描述了系统的静态结构和动态行为，它将系统描述为一些独立的相互作用的对象，构成为外界提供一定功能的模型结构，静态结构定义了系统中重要对象的属性和服务，以及这些对象之间的相互关系，动态行为定义了对象的时间特性和对象为完成目标而相互进行通信的机制。
|
|
|
|
|
|
|
|
.不是一种可视化的程序设计语言，而是一种可视化的建模语言。
|
|
|
|
.是一种建模语言规范说明，是面向对象分析与设计的一种标准表示。
|
|
|
|
.不是过程，也不是方法，但允许任何一种过程和方法使用它。
|
|
|
|
.简单且可扩展，具有扩展和专有化机制，便于扩展，无须对核心概念进行修改。
|
|
|
|
.为面向对象的设计与开发中涌现出的高级概念（如协作、框架、模式和组件）提供支持，强调在软件开发中对架构、框架、模式和组件的重用。
|
|
|
|
|
|
|
|
面向对象技术和UML的发展经历了长期的过程。1996年底，UML已稳占面向对象技术市场的85%，成为可视化建模语言事实上的工业标准。1997年，OMG采纳UML1.1作为基于面向对象技术的标准建模语言，至今，UML已发展至2.X版本。UML代表了面向对象方法的软件开发技术的发展方向，具有巨大的市场前景。
|
|
|
|
|
|
|
|
.使UML成为一个通用的建模语言，可供所有建模者使用。
|
|
|
|
|
|
.应该能够准确表达当前软件开发中的热点问题，比如软件规模、分布、并发、方法和团队开发等。
|
|
|
|
.在尽可能简单的同时能够对应用系统的各个方面建模。
|
|
|
|
|
|
|
|
|
|
表示两个事物间的语义关系，其中一个事物（独立事物）发生变化会影响另一个事物（依赖事物）的语义。用可能有方向的虚线表示，如下图所示。
|
|
|
|
|
|
|
|
|
|
是一种结构关系，它描述了一组链，链是对象之间的连接。聚集（Aggregation）是一种特殊类型的关联，它描述了整体和部分间的结构关系。关联用下图表示，可以标注重复度和角色。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
是一种特殊／一般关系，特殊元素（子元素）的对象可替代一般元素（父元素）的对象。用这种方法，子元素共享了父元素的结构和行为。图形上表示为一条带有空心箭头的实线，指向父元素，如下图所示。
|
|
|
|
|
|
|
|
|
|
是类元之间的语义关系，其中一个类元指定了由另一个类元保证执行的契约。有两种情况需要用到实现关系：一种是在接口和实现它们的类或构件之间；另一种是在用例和实现它们的协作之间。图形上用一条带有空心箭头的虚线表示，如下图所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
显示了一组对象、接口、协作和它们间的关系。在面向对象系统的建模中所建立的最常见的图就是类图，类图给出系统的静态设计视图，如下图所示。
|
|
|
|
|
|
|
|
|
|
显示了一组对象以及它们之间的关系。对象图描述了在类图中所建立的事物的实例的静态快照。和类图一样，对象图给出系统的静态设计视图或静态进程视图，但它们是从真实的或原型案例的角度建立的。这种视图主要支持系统的功能需求。利用对象图可以对静态数据结构建模。
|
|
|
|
|
|
显示了一组用例、参与者（actor）以及它们之间的关系。用例图通常包括用例、参与者、扩展关系、包含关系，如下图所示。
|
|
|
|
|
|
|
|
包含（include）关系为用例建模提供了从两个或更多用例的描述中抽取通用部分的能力。一般情况下，如果若干个用例的某些行为是相同的，则可以把这些相同的行为提取出来作为一个单独的用例，这个用例称作抽象用例，其他用例可以包含该抽象用例。所以，在描述用例之前就开始抽取包含用例是不可取的。在UML的较早版本中也有uses关系，在UML2.2中uses和includes被include取代，称为包含关系。
|
|
|
|
扩展（extend）关系提供了使用另外的可选流程来补充或插入到一个已存在的用例中的能力。因此，这是一种能够扩展原用例却不用对原来的用例进行重新描述的方法。
|
|
|
|
|
|
.包含关系中，对基用例来说，如果缺少了被包含用例，则基用例不完整；扩展关系中，如果去掉扩展关系，基用例仍然完整。
|
|
|
|
.包含关系中，被包含用例对基用例是可见的；扩展关系中，基用例对扩展用例可见，而扩展用例对基用例不可见。
|
|
|
|
.扩展关系中，扩展用例本身具有独立的功能，而非从其他用例中抽取。
|
|
|
|
.包含关系中，被包含用例通常应被两个以上的其他用例所包含。
|
|
|
|
用例图用于对系统的静态用例视图进行建模。这个视图主要支持系统的行为，即该系统在它的周边环境的语境中所提供的外部可见服务。
|
|
|
|
|
|
序列图和协作图均被称为交互图，它们用于对系统的动态方面进行建模。一张交互图显示的是一个交互，由一组对象和它们之间的关系组成，包含它们之间可能传递的消息。序列图是强调消息时间顺序的交互图；协作图是强调接收和发送消息的对象的结构组织的交互图。交互图一般包含对象、链和消息。
|
|
|
|
（1）序列图（Sequence Diagram）。
|
|
|
|
序列图是场景的图形化表示，描述了以时间顺序组织对象之间的交互活动。如下图所示。
|
|
|
|
|
|
|
|
|
|
.序列图有对象生命线。对象生命线是一条垂直的虚线，表示一个对象在一段时间内存在。
|
|
|
|
.序列图有控制焦点。控制焦点是一个瘦高的矩形，表示一个对象执行一个动作所经历的时间段，既可以是直接执行，也可以是通过下级过程执行。
|
|
|
|
（2）协作图（Collaboration Diagram）。
|
|
|
|
协作图强调收发消息的对象的结构组织。协作图有两个不同于序列图的特征：
|
|
|
|
.协作图有路径。为了指定一个对象如何与另一个对象链接，可以在链的末端附上一个路径构造型。通常只需要显式地表示local（局部）、parameter（参数）、global（全局）以及self（自身）这几种链的路径，不必表示association（关联）。
|
|
|
|
.协作图有顺序号。为表示一个消息的时间顺序，可以给消息加一个数字前缀（从1号开始），在控制流中，每个新消息的顺序号单调增加（如2、3等）。为了显示嵌套，可使用带小数点的号码（1表示第一个消息，1.1表示嵌套在消息1中的第一个消息，等等）。嵌套可为任意深度。另外，沿同一个链可以显示许多消息，且每个消息都有唯一一个顺序号。
|
|
|
|
|
|
|
|
显示了一个状态机，它由状态、转换、事件和活动组成。状态图关注系统的动态视图，它对于接口、类和协作的行为建模尤为重要，强调对象行为的事件顺序。状态图通常包括简单状态和组合状态、转换（事件和动作）。如下图所示。
|
|
|
|
|
|
|
|
|
|
活动图是一种特殊的状态图，它显示了在系统内从一个活动到另一个活动的流程。活动图专注于系统的动态视图，它对于系统的功能建模特别重要，并强调对象间的控制流程。活动图一般包括活动状态和动作状态、转换和对象。
|
|
|
|
活动图可以表示分支和汇合。当对一个系统的动态方面建模时，通常有两种使用活动图的方式：
|
|
|
|
.对工作流建模。此时所关注的是与系统进行协作的参与者所观察到的活动。
|
|
|
|
|
|
|
|
显示了一组构件之间的组织和依赖。构件图关注系统的静态实现视图，它与类图相关，通常把构件映射为一个或多个类、接口或协作。
|
|
|
|
|
|
显示了运行处理节点以及其中构件的配置。部署图给出了体系结构的静态实施视图。它与构件图相关，通常一个节点包含一个或多个构件。
|
|
|
|
|
|
为方便起见，用视图来划分UML中的概念和组件。视图只是表达系统某一方面特征的UML建模组件的子集，在每一类视图中使用一种或多种特定的图来可视化地表示视图中的各种概念。
|
|
|
|
在上层，视图被划分成三个视图域：结构、动态行为和模型管理。
|
|
|
|
|
|
|
|
模型管理说明了模型的分层组织结构。包是模型的基本组织单元，特殊的包还包括模型和子系统。模型管理视图跨越了其他视图，并根据系统开发和配置组织这些视图。
|
|
|
|
下表列出了UML的视图和视图所包括的图以及每种图有关的主要概念。
|
|
|
|
|
|
|
