|
|
知识路径： > 系统开发和运行维护知识 > 系统分析基础知识 > 面向对象分析方法 > 面向对象分析方法 >
|
|
相关知识点：22个
|
|
|
|
|
统一建模语言（Unified Modeling Language，UML）是面向对象软件的标准化建模语言。由于其简单、统一，又能够表达软件设计中的动态和静态信息，目前已经成为可视化建模语言事实上的工业标准。
|
|
|
|
从企业信息系统到基于Web的分布式应用，甚至严格的实时嵌入式系统都适合用UML来建模。因为UML是一种富有表达力的语言，可以描述开发所需要的各种视图，然后以此为基础装配系统。
|
|
|
|
|
|
|
|
（1）构造块。UML有3种构造块：事物、关系和图。事物是对模型中最具有代表性的成分的抽象；关系把事物结合在一起；图聚集了相关的事物。
|
|
|
|
（2）规则。规则是支配构造块如何放置在一起的规定，包括给构造块命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行。
|
|
|
|
（3）公共机制。公共机制是指达到特定目标的公共UML方法，主要包括规格说明（详细说明）、修饰、公共分类（通用划分）和扩展机制4种。规格说明是事物语义的细节描述，它是模型真正的核心；UML为每个事物设置了一个简单的记号，可以通过修饰来表达更多的信息；UML包括两组公共分类：类与对象、接口与实现；扩展机制包括约束、构造型和标记值。
|
|
|
|
UML对系统架构的定义是系统的组织结构，包括系统分解的组成部分，以及它们的关联性、交互机制和指导原则等提供系统设计的信息。具体来说，有以下5种系统视图：
|
|
|
|
（1）逻辑视图。逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。
|
|
|
|
（2）进程视图。进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。
|
|
|
|
（3）实现视图。实现视图对组成基于系统的物理代码的文件和构件进行建模。
|
|
|
|
（4）部署视图。部署视图把构件部署到一组物理节点上，用来表示软件到硬件的映射和分布结构。
|
|
|
|
|
|
|
|
UML中有4种事物：结构事物、行为事物、分组事物和注释事物。
|
|
|
|
（1）结构事物（structural thing）。
|
|
|
|
结构事物是UML模型中的名词。它们通常是模型的静态部分，描述概念或物理元素。UML有7种结构事物：类（class）、接口（interface）、协作（collaboration）、用例（use case）、主动类（active class）、构件（component）和节点（node）。结构事物的图形表示如下图所示。
|
|
|
|
|
|
|
|
类是描述具有相同属性、方法、关系和语义对象的集合，一个类实现一个或多个接口。接口是指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外可见的动作。协作定义了交互的操作，使一些角色和其他事物一起工作，提供一些合作的动作。用例是描述一系列的动作，产生有价值的结果。在模型中用例通常用来组织行为事物。用例是通过协作来实现的。主动类的对象有一个或多个进程或线程。构件是物理上或可替换的部分，它实现了一个接口的集合。节点是一个元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。一个构件集合一般来说位于一个节点，但有可能从一个节点转到另一个节点。
|
|
|
|
|
|
行为事物是UML模型的动态部分。它们是模型中的动词，描述了跨越时间和空间的行为。共有两类主要的行为事物：交互（interaction）和状态机（state machine）。
|
|
|
|
交互由在特定语境中共同完成一定任务的一组对象之间交换的消息组成。一个对象群体的行为或单个操作的行为可以用一个交互来描述。交互涉及一些其他元素，包括消息、动作序列（由一个消息所引起的行为）和链（对象间的连接）。在图形上，把一个消息表示为一条有向直线，通常在表示消息的线段上标注操作名，如下图（a）所示。
|
|
|
|
|
|
|
|
状态机描述了一个对象或一个交互在生命期内响应事件所经历的状态序列。单个类或一组类之间协作的行为可以用状态机来描述。一个状态机涉及一些其他元素，包括状态、转换（从一个状态到另一个状态的流）、事件（触发转换的事物）和活动（对一个转换的响应）。在图形上，把状态表示为一个圆角矩形，通常在圆角矩形中含有状态的名称及其子状态，如上图（b）所示。
|
|
|
|
|
|
分组事物是UML模型的组织部分。它们是一些由模型分解成的“盒子”。在所有的分组事物中，最主要的分组事物是包（package）。包是把元素组织成组的机制，这种机制具有多种用图。结构事物、行为事物甚至其他分组事物都可以放进包内。包与构件（仅在运行时存在）不同，它纯粹是概念上的（即它仅在开发时存在）。包的图形化表示如下图所示。
|
|
|
|
|
|
|
|
（4）注释事物（annotational thing）。
|
|
|
|
注释事物是UML模型的解释部分。这些注释事物用来描述、说明和标注模型的任何元素。注解（note）是一种主要的注释事物。注解是一个依附于一个元素或者一组元素之上，对它进行约束或解释的简单符号。注解的图形化表示如下图所示。
|
|
|
|
|
|
|
|
|
|
UML中有四种关系：依赖、关联、泛化和实现。关系的图形表示如下图所示。
|
|
|
|
|
|
|
|
|
|
依赖是两个事物间的语义关系，其中一个事物（独立事物）发生变化会影响另一个事物（依赖事物）的语义。在图形上，把一个依赖画成一条可能有方向的虚线，如上图（a）所示。
|
|
|
|
|
|
关联是一种结构关系，它描述了一组链，链是对象之间的连接，如上图（b）所示。聚集（aggregation）是一种特殊类型的关联，它描述了整体和部分间的结构关系，如上图（c）所示。需要说明的是，在关联上可以标注重复度（multiplicity）和角色（role）。
|
|
|
|
|
|
泛化（generalization）是一种特殊／一般关系，特殊元素（子元素）的对象可替代一般元素（父元素）的对象。用这种方法，子元素共享了父元素的结构和行为。在图形上，把一个泛化关系画成一条带有空心箭头的实线，它指向父元素，如上图（d）所示。
|
|
|
|
|
|
实现是类元之间的语义关系，其中一个类元指定了由另一个类元保证执行的契约。在两种地方要用到实现关系：一种是在接口和实现它们的类或构件之间；另一种是在用例和实现它们的协作之间。在图形上，把一个实现关系画成一条带有空心箭头的虚线，如上图（e）所示。
|
|
|
|
这四种关系是UML模型中可以包含的基本关系事物。它们也有变体，例如，依赖的变体有精化、跟踪、包含和延伸。
|
|
|
