uml状态图_项目经理学习UML

UML实践--用例图、顺序图、状态图、类图、包图、协作图

用例图、类图、对象图、顺序图、协作图、状态图、活动图、组件图、配置图

写软件就好像建造建筑物一样。系统越复杂，参与编写与配置软件的人员之间的交流也就越重要。“建筑蓝图”。

一个模型model就是根本问题的抽象。域domain就是问题所处的真实世界。

模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的。记住把一个对象想象成“活着的”。对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）。对象的属性的值决定了它的状态state。

类Classes是对象的“蓝图”。一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）。对象是类的实例instances。

用例图（https://www.cnblogs.com/duanxz/p/5566567.html）

用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象。强调这个系统是什么而不是这个系统怎么工作。

用例图与情节紧紧相关的。情节scenario是指当某个人与系统进行互动时发生的情况。下面是一个医院门诊部的情节。

“一个病人打电话给门诊部预约一年一次的身体检查。接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录。”

用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和。角色actor是发动与这个工作有关的事件的人或者事情。角色简单的扮演着人或者对象的作用。下面的图是一个门诊部Make Appointment用例。角色是病人。角色与用例的联系是通讯联系communication association（或简称通讯communication）

角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线。

一个用例图是角色，用例，和它们之间的联系的集合。我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分。注意一个单独的用例可以有多个角色。

用例图在三个领域很有作用。

决定特征（需求）。当系统已经分析好并且设计成型时，新的用例产生新的需求

客户通讯。使用用例图很容易表示开发者与客户之间的联系。

产生测试用例。一个用例的情节可能产生这些情节的一批测试用例。

类图

类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统。类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响。

下面是一个顾客从零售商处预定商品的模型的类图。中心的类是Order。连接它的是购买货物的Customer和Payment。Payment有三种形式：Cash，Check，或者Credit。订单包括OrderDetails（line item），每个这种类都连着Item。

UML类的符号是一个被划分成三块的方框：类名，属性，和操作。抽象类的名字，像Payment是斜体的。类之间的关系是连接线。

类图有三种关系。

关联association－表示两种类的实例间的关系。如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联。在图中，关联用两个类之间的连线表示。

聚合aggregation－当一个类属于一个容器是的一种特殊关系。聚合用一个带菱形的连线，菱形指向具有整体性质的类。在我们的图里，Order是OrderDetails的容器。

泛化generalization－一个指向以其他类作为超类的继承连线。泛化关系用一个三角形指向超类。Payment是Cash，Check和Credit的超类。

一个关联有两个尾端。每个尾端可以有一个角色名role name来说明关联的作用。比如，一个OrderDetail实例是一个Order实例的项目。

关 联上的方向性navigability箭头表示该关联传递或查询的方向。OrderDetail类可以查询他的Item，但不可以反过来查询。箭头方向同 样可以告诉你哪个类拥有这个关联的实现；也就是，OrderDetail拥有Item。没有方向性的箭头的关联是双向。

关 联尾端的数字表示该关联另一边的一个实例可以对应的数字端的实例的格数，通过这种方式表达关联的多样性multiplicity。多样性的数字可以是一个 单独的数字或者是一个数字的范围。在例子中，每个Order只有一个Customer，但一个Customer可以有任意多个Order。

下面这个表给出了最普遍的多样性示例。

每个类图包括类，关联和多样性表示。方向性和角色是为了使图示得更清楚时可选的项目。

包和对象图

为了简单地表示出复杂的类图，可以把类组合成包packages。一个包是UML上有逻辑关系的元件的集合。下面这个图是是一个把类组合成包的一个商业模型。

dependencies关系。如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B。

包是用一个在上方带有小标签的矩形表示的。包名写在标签上或者在矩形里面。点化线箭头表示依赖

对象图Object diagrams用来表示类的实例。他们在解释复杂关系的细小问题时（特别是递归关系时）很有用。

这个类图示一个大学的Department可以包括其他很多的Departments。

这个对象图示上面类图的实例。用了很多具体的例子。

UML中实例名带有下划线。只要意思清楚，类或实例名可以在对象图中被省略。

每个类图的矩形对应了一个单独的实例。实例名称中所强调的UML图表。类或实例的名称可能是省略对象图表只要图的意义仍然是明确的。

顺序图

类图和对象图是静态模型的视图。交互图是动态的。他们描述了对象间的交互作用。

顺序图将交互关系表示为一个二维图。纵向是时间轴，时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。类元角色用生命线表示。当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。

消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列。

协作图

协作图也是互动的图表。他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色。在序列图中，对象的角色放在上面而消息则是连接线。

对象角色矩形上标有类或对象名（或者都有）。类名前面有个冒号（：）。

协作图的每个消息都有一个序列号。顶层消息的数字是1。同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等。

状态图

对象拥有行为和状态。对象的状态是由对象当前的行动和条件决定的。状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移。

我们的模型例图建立了一个银行的在线登录系统。登录过程包括输入合法的密码和个人账号，再提交给系统验证信息。

登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及 Rejecting。每个状态都有一套完整的转移transitions来决定状态的顺序。

状态是用圆角矩形来表示的。转移则是使用带箭头的连线表示。触发转移的事件或者条件写在箭头的旁边。我们的图上有两个自转移。一个是在Getting SSN，另一个则在上Getting PIN。

初始状态（黑色圆圈）是开始动作的虚拟开始。结束状态也是动作的虚拟结束。

事件或条件触发动作时用（/动作）表示。当进入Validating状态时，对象并不等外部事件触发转移。取而代之，它产生一个动作。动作的结果决定了下一步的状态。

活动图

活动图activity diagram是一个很特别的流程图。活动图和状态图之间是有关系的。状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程。活动图告诉了我们活动之间的依赖关系。

对我们的例子来说，我们使用如下的过程。

“通过ATM来取钱。”

这个活动有三个类Customer, ATM和 Bank。整个过程从黑色圆圈开始到黑白的同心圆结束。活动用圆角矩形表示。

活动图可以被分解成许多对象泳道swimlanes ，可以决定哪些对象负责那些活动。每个活动都有一个单独的转移transition连接这其他的活动。

转移可能分支branch成两个以上的互斥的转移。保护表达式（在[]中）表示转移是从一个分支中引出的。分支以及分支结束时的合并merge在图中用菱形表示。

转移也可以分解fork成两个以上的并行活动。分解以及分解结束时的线程结合join在图中用粗黑线表示

组件与配置图

组件component是代码模块。组件图是是类图的物理实现。

配置图Deployment diagrams则是显示软件及硬件的配置。

下面的配置图说明了与房地产事务有关的软件及硬件组件的关系。

物理上的硬件使用节点nodes表示。每个组件属于一个节点。组件用左上角带有两个小矩形的矩形表示。

用例图中三种关系详解（转）

共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

1、包含(include)

包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的 关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。
包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。

例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

2、扩展(extend)

扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。

对于一个扩展用例，可以在基用例上有几个扩展点。
例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：

4、泛化(generalization)

泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。

例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示：

上面是我参考的一篇文章，觉得将三种关系的区别讲得很清晰，在此基础上结合自己的系统，对项目(在线购物系统)的用例做了整体的描绘。
*****************************************************************
(1)系统整体用例图

按照先整体用例，后子系统用例来进行描绘的，欢迎大家提出好的建议!

转：UML中扩展和泛化的区别
泛化表示类似于OO术语“继承”或“多态”。UML中的Use Case泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case，并将不可合并部分单独成各自的子Use Case；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下：
●泛化侧重表示子用例间的互斥性；
●包含侧重表示被包含用例对Actor提供服务的间接性；
●扩展侧重表示扩展用例的触发不定性；详述如下：

既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况：
⒈无条件发生：肯定发生的；
⒉有条件发生：未必发生，发生与否取决于系统状态；

因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。进一步，用例的存在是为Actor提供服 务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。

另外一点需要提及的是：泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在

UML各种图总结-精华

UML（Unified Modeling Language）是一种统一建模语言，为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。下面将对UML的九种图+包图的基本概念进行介绍以及各个图的使用场景。

一、基本概念　　

　　如下图所示，UML图分为用例视图、设计视图、进程视图、实现视图和拓扑视图，又可以静动分为静态视图和动态视图。静态图分为：用例图，类图，对象图，包图，构件图，部署图。动态图分为：状态图，活动图，协作图，序列图。

1、用例图（UseCase Diagrams）：

　　用例图主要回答了两个问题：1、是谁用软件。2、软件的功能。从用户的角度描述了系统的功能，并指出各个功能的执行者，强调用户的使用者，系统为执行者完成哪些功能。

2、类图（Class Diagrams）：

　用户根据用例图抽象成类，描述类的内部结构和类与类之间的关系，是一种静态结构图。 在UML类图中，常见的有以下几种关系: 泛化（Generalization）, 实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)。

　　　各种关系的强弱顺序： 泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖

2.1.泛化

　　　　【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何继承父类的所有特征和行为。例如：老虎是动物的一种，即有老虎的特性也有动物的共性。

2.2.实现

　　　　【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现。

2.3.关联

　　　　【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。

【代码体现】：成员变量

2.4.聚合　

　　　　【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。如车和轮胎是整体和部分的关系，轮胎离开车仍然可以存在。

聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。

【代码体现】：成员变量

2.5.组合

　　　　【组合关系】：是整体与部分的关系，但部分不能离开整体而单独存在。如公司和部门是整体和部分的关系，没有公司就不存在部门。

组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。

　　　　【代码体现】：成员变量

　　　　【箭头及指向】：带实心菱形的实线，菱形指向整体

2.6.依赖　　

　　【依赖关系】：是一种使用的关系，即一个类的实现需要另一个类的协助，所以要尽量不使用双向的互相依赖.

【代码表现】：局部变量、方法的参数或者对静态方法的调用

【箭头及指向】：带箭头的虚线，指向被使用者

2.7 各种类图关系

3、对象图（Object Diagrams）:

　描述的是参与交互的各个对象在交互过程中某一时刻的状态。对象图可以被看作是类图在某一时刻的实例。

4、状态图（Statechart Diagrams）：

是一种由状态、变迁、事件和活动组成的状态机，用来描述类的对象所有可能的状态以及时间发生时状态的转移条件。

5、活动图（Activity Diagrams）：

是状态图的一种特殊情况，这些状态大都处于活动状态。本质是一种流程图，它描述了活动到活动的控制流。　　　　

交互图强调的是对象到对象的控制流，而活动图则强调的是从活动到活动的控制流。

活动图是一种表述过程基理、业务过程以及工作流的技术。

它可以用来对业务过程、工作流建模，也可以对用例实现甚至是程序实现来建模。

5.1 带泳道的活动图

　　　　　　泳道表明每个活动是由哪些人或哪些部门负责完成。

5.2 带对象流的活动图

　　　　用活动图描述某个对象时，可以把涉及到的对象放置在活动图中，并用一个依赖将其连接到进行创建、修改和撤销的动作状态或者活动状态上，对象的这种使用方法就构成了对象流。对象流用带有箭头的虚线表示。

6、序列图-时序图（Sequence Diagrams）：

交互图的一种，描述了对象之间消息发送的先后顺序，强调时间顺序。

　　　　序列图的主要用途是把用例表达的需求，转化为进一步、更加正式层次的精细表达。用例常常被细化为一个或者更多的序列图。同时序列图更有效地描述如何分配各个类的职责以及各类具有相应职责的原因。

　　消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列。

　　序列图中涉及的元素：

6.1 生命线

　　　　生命线名称可带下划线。当使用下划线时，意味着序列图中的生命线代表一个类的特定实例。

6.2 同步消息

　　　　同步等待消息

6.3 异步消息

　　　　异步发送消息，不需等待

6.4 注释

6.5 约束

6.6 组合　　　　

组合片段用来解决交互执行的条件及方式。它允许在序列图中直接表示逻辑组件，用于通过指定条件或子进程的应用区域，为任何生命线的任何部分定义特殊条件和子进程。常用的组合片段有：抉择、选项、循环、并行。

7、协作图（Collaboration Diagrams）：

交互图的一种，描述了收发消息的对象的组织关系，强调对象之间的合作关系。时序图按照时间顺序布图，而写作图按照空间结构布图

8、构件图（Component Diagrams）：

构件图是用来表示系统中构件与构件之间，类或接口与构件之间的关系图。其中，构建图之间的关系表现为依赖关系，定义的类或接口与类之间的关系表现为依赖关系或实现关系。

9、部署图（Deployment Diagrams）：

描述了系统运行时进行处理的结点以及在结点上活动的构件的配置。强调了物理设备以及之间的连接关系。

部署模型的目的：

描述一个具体应用的主要部署结构，通过对各种硬件，在硬件中的软件以及各种连接协议的显示，可以很好的描述系统是如何部署的；平衡系统运行时的计算资源分布；可以通过连接描述组织的硬件网络结构或者是嵌入式系统等具有多种硬件和软件相关的系统运行模型。

二、图的差异比较

1.序列图(时序图)VS协作图

序列图和协作图都是交互图。二者在语义上等价，可以相互转化。但是侧重点不同：序列图侧重时间顺序，协作图侧重对象间的关系。

共同点：时序图与协作图均显示了对象间的交互。

不同点：时序图强调交互的时间次序。

协作图强调交互的空间结构。

2.状态图VS活动图

状态图和活动图都是行为图。状态图侧重从行为的结果来描述，活动图侧重从行为的动作来描述。状态图描述了一个具体对象的可能状态以及他们之间的转换。在实际的项目中，活动图并不是必须的，需要满足以下条件：1、出现并行过程&行为；2、描述算法；3、跨越多个用例的活动图。

3.活动图VS交互图

　　二者都涉及到对象和他们之间传递的关系。区别在于交互图观察的是传送消息的对象，而活动图观察的是对象之间传递的消息。看似语义相同，但是他们是从不同的角度来观察整个系统的。

三、UML与软件工程

UML图是软件工程的组成部分，软件工程从宏观的角度保证了软件开发的各个过程的质量。而UML作为一种建模语言，更加有效的实现了软件工程的要求。

　　如下图，在软件的各个开发阶段需要的UML图。

　　下表是UML使用人员图示：

参考自：http://m.blog.csdn.net/article/details?id=38467715

http://www.cnblogs.com/wolf-sun/p/UML-collaboration-diagram.html