|
|
知识路径： > 信息系统开发和运行管理知识 > 系统分析设计基础知识 > 面向对象分析设计与统一建模语言（UML） > 系统分析工具——统一建模语言（UML） >
|
被考次数：12次
被考频率：高频率
总体答错率：42%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：12个
|
|
|
|
|
UML的目的是建模，在UML中，建立的模型有三个要素：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
结构事物是UML模型中的静态部分，描述概念或物理元素。共有7种结构事物。
|
|
|
|
①类（class）是对一组具有相同属性、相同操作、相同关系和相同语义的对象的描述。一个类实现了一个或多个接口。在图形上，把一个类画成一个矩形，通常矩形中写有类的名称、类的属性和类的操作，如下图所示。
|
|
|
|
|
|
|
|
②接口（interface）是描述了一个类或构件的一个服务的操作集。因此，接口描述元素的外部可见行为。一个接口可以描述一个类或构件的全部行为或部分行为。接口定义了一组操作的描述（即特征标记），而不是操作的实现。在图形上，把一个接口画成一个带有名称的圆。接口很少单独存在，而是通常依附于实现接口的类或构件，如下图所示。
|
|
|
|
|
|
|
|
③协作（collaboration）定义了一个交互，它是由一组共同工作以提供某协作行为的角色和其他元素构成的一个群体，这些协作行为大于所有元素的各自行为的总和。因此，协作有结构、行为和维度。一个给定的类可以参与几个协作。这些协作因而表现了系统构成模式的实现。在图形上，把一个协作画成一个通常仅包含名称的虚线椭圆，如下图所示。
|
|
|
|
|
|
|
|
④用例（Use Case）是对一组动作序列的描述，系统执行这些动作将产生一个对特定的参与者有价值而且可观察的结果。用例用于对模型中的行为事物结构化。在图形上，把一个用例画成一个实现椭圆，通常仅包含它的名称，如下图所示。
|
|
|
|
|
|
|
|
⑤活动类（Active Class）也是一种类，其对象至少拥有一个进程或线程，因此它能够启动控制活动。活动类的对象所描述的元素的行为与其他元素的行为并发，除了这一点之外，它和类是一样的。在图形上，活动类很像类，只是它的外框是粗框，通常它包含名称、属性和操作，如下图所示。
|
|
|
|
|
|
|
|
⑥组件（component）是可重用的系统片段，具有良好定义接口的物理实现单元。组件包含了系统设计中某些类的实现。组件设计的原则：良好的组件不直接依赖于其他组件，而是依赖于其他组件所支持的接口。这样的好处是系统中的组件可以被支持相同接口的组件所取代。在一个系统中，你将遇到不同类型的部署组件，如COM+构件和Java Bean，以及在开发过程中所产生的制品组件，如源代码文件。通常组件是一个描述了一些逻辑元素（如类、接口和协作）的物理包。在图形上，把一个组件画成一个带有小方框的矩形，通常在矩形中只写该组件的名称，如下图所示。
|
|
|
|
|
|
|
|
⑦结点（node）是在运行时存在的物理元素，它表示了一种可计算的资源，它通常至少有一些记忆能力和处理能力。一个组件集可以驻留在一个结点内，也可以从一个结点迁移到另一个结点。在图形上，把一个结点画成一个立方体，通常在立方体内只写它的名称，如下图所示。
|
|
|
|
|
|
|
|
|
|
行为事物是UML模型的动态部分，描述了跨越时间和空间的行为，共有两类主要的行为事物。
|
|
|
|
①交互（interaction）是这样一种行为，它由在特定语境中共同完成一定任务的一组对象之间交换的消息组成。一个对象群体的行为或单个操作的行为可以用一个交互来描述。交互涉及一些其他元素，包括消息、动作序列（由一个消息所引起的行为）和链（对象间的连接）。在图形上，把一个消息画成一条有向直线，通常在表示消息的线段上总有操作名，如下图所示。
|
|
|
|
|
|
|
|
②状态机（state machine）是这样一种行为，它描述了一个对象或一个交互在生命期内响应事件所经历的状态序列。单个类或一组类之间协作的行为可以用状态机来描述。一个状态机涉及到一些其他元素，包括状态、转换（从一个状态到另一个状态的流）、事件（触发转换的事物）和活动（对一个转换的响应）。在图形上，把一个状态画成一个圆角矩形，通常在圆角矩形中含有状态的名称及其子状态，如下图所示。
|
|
|
|
|
|
|
|
|
|
分组事物是UML模型的组织部分。它们是一些由模型分解成的“盒子”。在所有的分组事物中，最主要的分组事物是包。
|
|
|
|
包（package）是把元素组织成组的机制，这种机制具有多种用途。结构事物，行为事物甚至其他的分组事物都可以放进包内。包不像构件（仅在运行时存在），它纯粹是概念上的（即它仅在开发时存在）。在图形上，把一个包画成一个左上角带有一个小矩形的大矩形，在矩形中通常仅含有包的名称，有时还有内容，如下图所示。
|
|
|
|
|
|
|
|
|
|
注释事物是UML模型的解释部分。这些注释事物用来描述，说明和标注模型的任何元素。有一种主要的注释事物，称为注解。注解（note）是一个依附于一个元素或一组元素之上，对它进行约束或解释的简单符号。在图形上，把一个注解画成一个右上角是折角的矩形，其中带有文字或图形解释，如下图所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
①依赖（dependency）是两个事物间的语义关系，其中一个事物（独立事物）发生变化会影响另一个事物（依赖事物）的语义。在图形上，把一个依赖画成一条可能有方向的虚线，偶尔在其上还有一个标记，如下图所示。
|
|
|
|
|
|
|
|
②关联（association）是一种结构关系，它描述了一组链，链是对象之间的连接。聚合是一种特殊类型的关联，它描述了整体和部分间的结构关系。在图形上，把一个关联画成一条实线，它可能有方向，偶尔在其上还有一个标记，而且它经常还含有诸如多重性和角色名这样的修饰，如下图所示。
|
|
|
|
|
|
|
|
③泛化（generalization）是一种特殊／一般关系，特殊元素（子元素）的对象可替代一般元素（父元素）的对象。用这种方法，子元素共享了父元素的结构和行为。在图形上，把一个泛化关系画成一条带有空心箭头的实线，它指向父元素，如下图所示。
|
|
|
|
|
|
|
|
④实现（realization）是类元之间的语义关系，其中的一个类元指定了由另一个类元保证执行的契约。在两种地方要遇到实现关系：一种是在接口和实现它们的类或构件之间；另一种是在用例和实现它们的协作之间。在图形上，把一个实现关系画成一条带有空心箭头的虚线，它是泛化和依赖关系两种图形的结合，如下图所示。
|
|
|
|
|
|
|
|
|
|
图（diagram）是一组元素的图形化表示，大多数情况下把图画成顶点（代表事物）和弧（代表关系）的连通图。为了对系统进行可视化，可以从不同的角度画图，这样图是对系统的投影。除了非常微小的系统外，图是系统组成元素的省略视图。有的元素可以出现在所有图中，有的元素可以出现在一些图中（很常见），还有的元素不能出现在图中（很罕见）。在理论上，图可以包含任何事物及其关系的组合。然而，实际上仅存在着少量的常见组合，它们要与5种最有用的组成了软件密集型系统的体系结构的视图相一致。由于这个原因，UML中的图可以分为几下几类：
|
|
|
|
①第一类是用例图，从用户角度描述系统功能，并指出各功能的操作者。
|
|
|
|
②第二类是静态图（Static Diagram），包括类图、对象图和包图。
|
|
|
|
.类图描述系统中类的静态结构。不仅定义系统中的类，表示类之间的联系如关联、依赖、聚合等，也包括类的内部结构（类的属性和操作）。类图描述的是一种静态关系，在系统的整个生命周期都是有效的。
|
|
|
|
.对象图是类图的实例，几乎使用与类图完全相同的标识。它们的不同点在于对象图显示类的多个对象实例，而不是实际的类。一个对象图是类图的一个实例。由于对象存在生命周期，因此对象图只能在系统某一时间段存在。
|
|
|
|
.包由包或类组成，表示包与包之间的关系。包图用于描述系统的分层结构。
|
|
|
|
③第三类是行为图（Behavior Diagram），描述系统的动态模型和组成对象间的交互关系。包括状态图和活动图。
|
|
|
|
.状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。通常，状态图是对类图的补充。在实际应用时并不需要为所有的类画状态图，仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。
|
|
|
|
.活动图描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动。
|
|
|
|
④第四类是交互图（Interactive Diagram），描述对象间的交互关系。包括顺序图和合作图。
|
|
|
|
.顺序图显示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互。
|
|
|
|
.合作图描述对象间的协作关系，合作图跟顺序图相似，显示对象间的动态合作关系。除显示信息交换外，合作图还显示对象以及它们之间的关系。如果强调时间和顺序，则使用顺序图；如果强调上下级关系，则选择合作图。这两种图被合称为交互图。
|
|
|
|
⑤第五类是实现图（Implementation Diagram）。包括组件图和配置图。
|
|
|
|
.组件图描述代码部件的物理结构及各部件之间的依赖关系。一个组件可能是一个资源代码部件、一个二进制部件或一个可执行部件。它包含逻辑类或实现类的有关信息。组件图有助于分析和理解部件之间的相互影响程度。
|
|
|
|
.配置图定义系统中软硬件的物理体系结构。它可以显示实际的计算机和设备（用结点表示）以及它们之间的连接关系，也可显示连接的类型及部件之间的依赖性。在结点内部，放置可执行部件和对象以显示结点跟可执行软件单元的对应关系。
|
|
|
|
使用用例图、类图、对象图、构件图和配置图等5个图形建立的模型都是静态的，是标准建模语言UML的静态建模机制；使用状态图、活动图、顺序图和协作图等4个图形建立的模型或者可以执行，或者可以表示执行时的时序状态或交互关系，是动态的、是标准建模语言UML的动态建模机制。因此，标准建模语言UML的主要内容也可以被归纳为静态建模机制和动态建模机制两大类。
|
|
|
