UML的主要作用是帮助用户对软件系统进行面向对象的描述和建模。
UML是可视化的建模语言。
建模是通过将用户的业务需求映射为代码，保证代码满足这些需求，并能方便地回溯到需求的过程。
视图（View）
——表达系统某一方面特征的UML建模元素的子集，由多个图构成，是在某一个抽象层上对系统的抽象表示。
图（Diagram）
——模型元素集的图形表示，通常是由弧（关系）和顶点（其他模型元素）相互连接构成的。
视图是由图组成的，UML定义了9种图：
用例图（Use Case Diagram）
用例（Use Case）
用例用来记录用户或外界环境从头到尾使用系统的一系列事件。
活动者（Actor）
活动者可以是人，也可以是另一个系统。它与当前的系统进行交互，向系统提供输入或从系统中获得输出。
依赖、泛化及关联关系
一般将活动者和用例之间的关系称为通信。
在UML中，关系使用实线表示，实线可以有箭头，也可以没有箭头。
用例与用例之间可以存在的关系分为3种：
泛化（也称为概括）(generalization)
泛化表示几个元素的某些共性。
在用例泛化中，子用例表示父用例的特殊形式。子用例从父用例处继承行为和属性，还可以添加行为或覆盖、改变已继承的行为。
当系统中具有一个或多个用例是较一般用例的特化时，就使用用例泛化。另外、活动者和活动者之间也可以存在泛化关系。
包含(include)
包含关系使得一个用例的功能可以在另一个用例中使用。
一般在如下两种情况下引入包含关系：
如果两个以上的用例有相同的功能，则可以将这个功能分解到另一个用例中。
一个用例的功能太多时，可以用包含关系建立两个小的用例。
扩展(extend)
扩展关系是把新行为插入到已有用例（基础用例）的方法。
基础用例提供了一组扩展点（Extension points），在这些扩展点中可以添加新的行为，而扩展用例提供了一组插入片断，这些片断能够被插入到基础用例的扩展点。
基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。
事实上，基础用例没有扩展点也是完整的，这一点与包含关系有所不同。
在一般情况下，基础用例的执行不会涉及扩展用例的行为，如果特定条件发生，扩展用例的行为才被执行，然后流继续。
序列图（Sequence Diagram）
•序列图将交互关系表示为一个二维图，纵向是时间轴，时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。类元角色的活动用生命线表示。当对象存在时，生命线用一条纵向虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。•消息用从一个对象的生命线到另一个对象的生命线的箭头表示。箭头以时间顺序在图中从上到下排列。序列图中包含如下元素：
类角色
生命线
激活期
消息
协作图（Collaboration Diagram）
有两种交互图：
序列图（swquence diagram）：强调消息时间顺序的交互图。
协作图（collaboration diagram）：强调参加交互的各对象的组织。
协作图和序列图都来自UML元模型的相同信息，因此它们的语义是等价的，它们可以从一种形式的图转换成另一种形式的图，而不丢失任何信息。
活动图（Activity Diagram）
考虑使用流程图来描述事件流，在UML中把这种图称为活动图，它是事件流的另一种建模方式。
活动图用来捕捉用例的活动。
活动图着重描述操作（operation）以及用例或对象中的活动。
活动图是一种描述工作流的方式，它用来描述采取何种动作、做什么（对象状态改变）、何时发生（动作序列）以及在在何处发生（泳道）。
活动图可以用于以下目的：
描述一个操作执行过程中所完成的工作（动作），这是活动图最常见的用途。
描述对象内部的工作。
显示如何执行一组相关的动作，以及这些动作如何影响它们周围的对象。
显示用例的实例如何执行动作以及如何改变对象状态。
说明一次商务活动中的人（角色）、工作流组织和对象是如何工作的。
起始状态（start state）
终止状态（end state）
状态转移（state transition）
决策（decision）
守护条件（guard condition）
同步条（synchronization bar）
泳道（swimlane）
状态图（State Diagram）
•在UML中，可以使用状态图展现对象状态的变化。•对象从产生到结束，可以处于一系列不同的状态。状态影响对象的行为，当这些状态的数目有限时，就可以用状态图建模对象的行为。状态图显示了单个类的生命周期。•在画对象的状态图时，要考虑以下因素：•对象有哪些有意义的状态。•如何决定对象的可能状态。•对象的状态和其他模型之间如何进行映射。•状态图是状态节点通过转移连接的图，描述了一个特定对象的所有可能状态，以及由于各种事件的发生而引起状态之间的转移。•大多数面向对象技术都使用状态图来描述一个对象在其生命周期中的行为。状态图用初始状态表示对象创建时的状态，每一个状态图只有一个初始状态；但每一个状态图可能有多个终止状态。
从一个状态到另—个状态之间的连线称为转移(transitions)。
•状态图中可以有多个状态框，每个状态框中有两格：上格放置名称，下格说明处于该状态时，系统或对象要进行的活动(activity)。•状态之间的过渡事件(event)，对应对象的操作。事件有可能在特定的条件下发生，在UML中这样的条件称为守护条件(guandcondition)。发生事件时的处理称为动作(action)。
类图（Class Diagram）
关系（Relationship）是事物间的联系。
在类的关系中，最常用的有以下4种：
依赖（Dependency）：表示类之间的使用关系。
•依赖是两个元素之间的关系，对一个元素（提供者）的改变可能会影响或提供消息给其他元素（客户）。•在实际的建模中，类元之间的依赖关系表示某一类元以某种方法依赖于其他类元。•从语义上理解，关联、实现和泛化都是依赖关系，但因为他们有更特别的语义，所以在UML中被分离出来作为独立的关系。依赖是两个元素之间的关系，对一个元素（提供者）的改变可能会影响或提供消息给其他元素（客户）。
在实际的建模中，类元之间的依赖关系表示某一类元以某种方法依赖于其他类元。
从语义上理解，关联、实现和泛化都是依赖关系，但因为他们有更特别的语义，所以在UML中被分离出来作为独立的关系。
泛化（Generalization）：表示类之间的一般和特殊的关系。
•泛化是一般事物（称为超类或父类）和该事物的较为特殊的种类（称为子类）之间的关系。
关联（Association）：表示对象之间的结构关系。
关联是一种结构关系，它指明一个事物的对象与另一个事物的对象间的联系。
在UML中，关联用一条实线表示，可以加上箭头来表示导航性。
4种应用于关联的修饰
名称
角色
多重性
聚合聚合是一种特殊的关系，它表示类间的关系是整体与部分的关系。更简单的说，关联关系中一个类描述了一个较大的事物，它由较小的事物组成，这种关系就是聚合，它描述了“has-a”的关系，即整体对象拥有部分对象。
在UML中，聚合关系用空心的菱形头的实线表示。
组成关系（Composition Relationship）
•聚合是表示部分和整体关系的关联，组成是更强形式的关联，整体有管理部分的特有的职责并且它们有一致的生命期。
•组成是另一种形态的聚合，它在聚合的基础上添加了更精确的一些语义。
•在UML中，聚合关系用实心的菱形头的实线表示。
实现（Realization）：它是规格说明和其实现之间的关系。
实现是规格说明和其实现间的关系。它表示不继承结构而只继承行为。大多数情况下，实现关系用来规定接口和实现接口的类或组件之间的关系。
接口是能够让用户重用系统一组操作集的UML组件。一个接口可以被多个类或组件实现，一个类或组件也可以有多个接口。
可以在两种情况下使用实现关系：
在接口与实现该接口的类间
在用例以及实现该用例的协作间
实现关系还有一种省略的表示法：将接口表示为一个小圆圈并和实现它的类用一条线相连。
对象图（Object Diagram）
组件图（Component Diagram）
配置图（Deployment Diagram
用例图描述了从外部看来系统在做什么，强调的是系统在做什么而不是怎样做。
序列图和协作图都属于交互图（interaction diagram），描述了系统对象之间相互协作的过程。
序列图描述了对象之间的相互作用，什么时候对象之间发送怎样的消息进行交互。它按照时间序列进行组织，操作中的对象按照消息发生的次序列表。
协作图反映的信息和序列图相同，但是它侧重于对象的角色而不是消息发送的时序关系。
活动图本质上是一种特别的流程图，着重描述当个过程活动的流程。活动图显示了这些活动之间如何相互依赖。
状态图显示对象的可能状态以及状态之间的迁移，它回答的问题是对象在某时刻处于什么状态。
类图描述了系统中类的组成及它们之间的关系，方框内表示的是类，类与类之间的连线表示类的关联。
组件图对模型中的组件建模，描述应用程序搭建的软件单元以及组件之间的依赖，从而可以估计更改的影响。它还对类及其它元素在组件中的分配建模。
配置图显示了系统的软件和硬件的物理配置。
模型元素（Model Element）
——代表面向对象中的类、对象、消息和关系等概念，是构成图的最基本的元素。
通用机制（General Mechanism）
——用于表示其他信息，比如注释、模型元素的语义等。
2432
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
