uml建模 状态图

UML中的活动图和状态图的区别与实际应用案例解析UML（Unified Modeling Language）是一种用于软件系统建模的标准化语言，它提供了一套丰富的图形符号和规范，帮助开发人员更好地理解和设计软件系统。

在UML中，活动图和状态图是两种常用的图形表示方式，用于描述系统中的活动流程和对象状态。

本文将探讨这两种图形的区别，并通过实际应用案例来解析它们的具体应用。

活动图是一种用于描述系统中活动流程的图形表示方式。

它主要由活动（Action）、控制流（Control Flow）和决策节点（Decision Node）等元素组成。

活动图可以清晰地展示系统中的各种活动以及它们之间的关系和顺序。

活动图通常用于描述业务流程、系统交互和软件系统中的算法等。

例如，在一个在线购物系统中，我们可以使用活动图来描述用户选择商品、添加到购物车、填写订单信息、确认支付等流程。

通过活动图，我们可以更好地理解和设计系统中的各个步骤，从而提高系统的可靠性和可维护性。

与活动图相比，状态图主要用于描述系统中对象的状态和状态之间的转换。

状态图由状态（State）、转移（Transition）和事件（Event）等元素组成。

状态图可以清晰地展示对象在不同状态之间的转换和触发条件。

状态图通常用于描述系统中的状态机、对象的生命周期和系统中的并发操作等。

例如，在一个自动售货机系统中，我们可以使用状态图来描述售货机的工作状态，如待机状态、售货状态和故障状态等。

通过状态图，我们可以更好地理解和设计系统中对象的状态变化，从而提高系统的可靠性和性能。

活动图和状态图在应用上有一些区别。

活动图主要用于描述系统中的活动流程，强调活动之间的顺序和关系。

它更适合于描述系统中的业务流程和交互流程等。

而状态图主要用于描述系统中对象的状态和状态之间的转换，强调对象状态的变化和触发条件。

它更适合于描述系统中的状态机和对象的行为。

下面通过一个实际应用案例来进一步解析活动图和状态图的具体应用。

1.1跟我学UML建模工具StarUML（第12部分）——应用StarUML创建状态图的创建示例1.1.1UML状态图及相关技术1、状态机图和状态机图中的状态（1）状态机图UML状态图（也称UML状态机图）是展示对象状态与状态转换的视图，在UML中，状态机图用于对具有事件驱动的特性的动态行为的建模。

（2）状态机图中的状态状态是状态机图的重要组成部分，所有对象都具有状态，状态是对象执行了一系列活动的结果。

当某个事件发生后，对象的状态将发生变化。

2、状态图（State Diagram）（1）什么是状态图用来描述一个特定对象的所有可能状态及其引起状态转移的事件，从而可以实现对单个的对象行为建模。

（2）状态图的主要作用大多数面向对象技术都用状态图表示单个对象在其生命周期中的行为，同时也显示了该实体如何根据当前所处的状态对不同的时间做出反应的。

3、什么场合中应该要采用状态图当功能行为的改变和状态有关时才需要创建出UML状态图，因为通过状态图可以显示对象在其生命周期中依次经历的各种状态。

但如果要表示由系统内部生成的功能操作（而非外部事件）驱动的事件流时，则一般使用UML活动图。

如下给出一个Account对象的状态图示例：4、为什么要使用UML状态图（1）动态特性是由事情所触发的一个完全静态的系统是无任何应用价值的，因为没有事件发生也就不可能产生出具体的功能。

所有真正的软件应用系统自身都含有某些动态的特性，并且这些动态的特性是由内部或外部发生的事件所触发。

比如，在一个ATM机上，动作是由一个用户按下相关的功能按钮引发而开始一个事件；在一个自动机器人中，动作是由机器人碰上一个对象而引发的；在一个网络路由器中，动作是由检测消息缓冲区是否溢出而引发的。

如下图为一个图书销售业务的状态图示例：（2）为单个的对象和共同工作的对象建模使用UML交互图可以对共同工作的对象群体的行为进行建模，而使用状态图，则可以对单个的对象行为进行建模。

本文和大家重点讨论一下UML活动图和状态图的概念，这两种图都有各自的特点和作用，那么他们之间有什么区别和联系呢，请看本文详细介绍。

UML活动图和状态图一、UML活动图：◆流程图常被用来建立算法模型◆UML活动图与流程图类似，不同在于它支持并行活动.◆缺点：不能清楚的表示二、作用：1、描述一个操作的执行过程中所完成的工作或者动作2、描述对象内部的工作3、描述用例的执行4、处理多线程5、显示如何执行一组相关的动作，以及这些动作如何影响周围对象三、以下情况不用UML活动图1、显示对象之间的合作2、显示对象在其生命周期内的运转情况。

这两点是通过序列图和协作图完成的。

四、UML活动图的基本要素：◆活动状态◆活动状态之间的转移（箭头）◆判断（决策点）◆保证条件◆同步条：活动之间的同步◆起点和终点--起点有且只有一个，终点可以有n个。

五、泳道：用于对UML活动图中的活动进行分组，用于描述对象之间的合作关系。

----所谓泳道技术，就是将活动用线分成一些纵向区域，这些纵向区域称为泳道。

UML状态图一、状态图：◆描述一个特定对象的所有可能状态以及由于各种事件的发生而引起的状态之间的转换。

例如呼叫中心系统。

◆状态图符--状态：矩形（四角圆弧）--转移--起点--终点1、状态机：◆一种行为：描述了一个对象或一个交互在生命周期内响应事件所经历的状态序列。

◆单个类或者一组类之间协作的行为可以用状态机来描述◆一个状态机涉及到一些其他元素，包括状态、转换、事件2、状态：在对象的生命周期中满足某些条件、执行某些活动或等待某些事件的一个条件活状况。

1）名称2）进入协作和退出动作3）内部转换4）子状态5）延迟事件3、转换：两个状态之间的一种关系，表示对象将在第一个状态中执行一定的动作并在某个特定事件发生而某个特定条件满足时进入第二个状态。

1）源状态2）事件触发3）监护条件4）动作5）目标状态例子：电话机状态图二、UML活动图与状态图的区别：状态：行为的结果活动：行为的动作在uml中图符不一样。

UML各种图例——用例图、类图、状态图、包图、协作图、顺序图面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML（也就是Unified Modeling Language™），这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题，测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题，我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂，设计师和施工人员之间的交流就越重要.蓝图就成为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂，参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师，设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）.对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）.对象是类的实例instances.用例图用例图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.每个类图包括类，关联和多样性表示.方向性和角色是为了使图示得更清楚时可选的项目.包和对象图为了简单地表示出复杂的类图，可以把类组合成包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.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.。

A、State Diagram（状态图）、State Machine Diagrams（状态机图）状态机图是说明一个元素（通常是类）能在不同状态之间变动。

状态机图的其它方面进一步描述和解释其运动和行为。

状态图主要用来描述对象、子系统、系统的生命周期。

通过状态图可以了解到一个对象所能到达的所有状态以及对象收到的事件（收到消息，超时，错误，条件满足）对对象状态的影响等。

状态所有对象都有状态，状态是对象操作的前一次活动的结果。

类的状态由类中的指定属性来说明。

事件当某些事情发生时对象的状态发生改变，我们称改变对象状态的事情为事件。

B、状态图的模型元素B.1、Initial（起点）初始态Initial元素是伪状态用于表明一个复合状态的默认状态。

可以在每一个复合状态的区域有一个初始顶点。

B.2、Final（终点）终态B.3、State（状态）State描述一些不变条件成立的情形。

这个条件可以是静态的（等待某个事件）也可以是动态的（正在执行一组活动）。

状态建模通常用于阐述类。

你可以适用State的operation(操作)来定义enter(进入)、internal(内部)、exit(退出)动作。

State 也可以有Attributes(属性)。

B.3、State Machine（状态机）状态机是一组相关状态元素的容器。

你可以创建状态机图的各个部分。

B.4、Synch（同步）Synch状态用于描述状态机的并发部分同时发生。

在同步发生后Synch状态的新兴过滤路径将合并。

B.5、Choice（选择）Choice伪状态用于组成复制过滤路径，例如：在状态机图中一个过滤的路径取决于一个动态的运行时的条件。

这个运行时的条件是由状态机路径选择决定的。

B.5、Junction（汇合）Junction伪状态用于设计复杂过滤路径。

一个Junction可以用来汇合或组合多个过滤路径为一个过滤路径。

另外一个Junction可以把一个进来的路径分割成多个路径。

如何使用UML状态图进行系统建模与分析UML（Unified Modeling Language）状态图是一种用于系统建模与分析的工具。

它能够帮助软件工程师和系统分析师更好地理解和描述系统的行为和状态转换。

本文将介绍如何使用UML状态图进行系统建模与分析，以及它的重要性和应用场景。

一、UML状态图的基本概念UML状态图是一种描述对象在其生命周期中各种状态和状态转换的图形化表示方法。

它由状态、转换、事件和动作等元素组成。

1. 状态（State）：表示对象在某一时刻的特定情况或属性。

状态可以是离散的，如“打开”、“关闭”等，也可以是连续的，如“运行中”、“停止”等。

2. 转换（Transition）：表示对象从一个状态转变到另一个状态的过程。

转换可以由事件触发，也可以由条件控制。

3. 事件（Event）：触发状态转换的外部或内部事件。

事件可以是用户的操作、系统的响应或者时间的变化等。

4. 动作（Action）：在状态转换过程中执行的操作。

动作可以是改变对象属性、调用方法或发送消息等。

二、使用UML状态图进行系统建模与分析的步骤使用UML状态图进行系统建模与分析可以帮助我们更好地理解系统的行为和状态转换，从而更好地设计和实现系统。

下面是一些使用UML状态图进行系统建模与分析的步骤：1. 确定系统的关键对象和其状态：首先要确定系统中的关键对象，然后确定每个对象可能的状态。

例如，一个电梯系统中的关键对象可以是电梯，它的状态可以是“开门”、“关门”、“上行”、“下行”等。

2. 绘制状态图：在状态图中，使用矩形表示状态，使用箭头表示状态之间的转换。

在状态之间的转换上标注事件和条件。

在状态图中可以添加动作，表示状态转换过程中执行的操作。

3. 分析状态转换：分析每个状态之间的转换条件和事件，确定状态转换的触发条件和动作。

例如，在电梯系统中，当电梯处于“开门”状态时，如果检测到有人进入电梯，则触发状态转换到“关门”状态。

状态图目录：一、状态图简介（Brief introduction）二、状态图元素（State Diagram Elements）1、状态（States）2、转移（Transitions）3、动作（State Actions）4、自身转移（Self-Transitions）5、组合状态（Compound States）6、进入节点（Entry Point）7、退出节点（Exit Point）8、历史状态（History States）9、并发区域（Concurrent Regions）三、状态图案例分析（State Diagram Example Analysis）四、总结（Summary）一、状态图简介（Brief introduction）状态图（Statechart Diagram）主要用于描述一个对象在其生存期间的动态行为，表现为一个对象所经历的状态序列，引起状态转移的事件（Event），以及因状态转移而伴随的动作（Action）。

一般可以用状态机对一个对象的生命周期建模，状态图用于显示状态机（State Machine Diagram），重点在与描述状态图的控制流。

如下图例子，状态机描述了门对象的生存期间的状态序列，引起转移的事件，以及因状态转移而伴随的动作（Action）.状态有Opened、Closed、Locked。

事件有Open、Close、Lock和Unlock。

注意：1、并不是所有的事件都会引起状态的转移，比如当门是处于【Opened】状态，不能进行【Lock】事件。

2、转移（Transition）有警备条件（guard condition），比如只有doorWay->isEmpty 条件满足时，才会响应事件。

二、状态图元素（State Diagram Elements）1、状态（States）指在对象的生命周期中的某个条件或者状况，在此期间对象将满足某些条件、执行某些活动活活等待某些事件。

实验报告学院：专业：班级：姓名学号实验组实验时间指导教师成绩实验项目名称对象状态模型——状态图实验掌握利用UML动态建模工具——状态图的方法。

目的实验对案例《XX公司网上招聘系统》进行系统分析、通过用状态图对该系统进行状态建模。

要求实验利用UML建模工具建立系统状态模型。

原理实验Windows 2000 professional 以上环境，Rationsl Rose 2003,Sybase Power Designer 10 等。

环境实验见实验数据步骤实验内容系统整体结构根据用户的需求陈述，可以确定本项目分为客户端和管理端，客户端主要功能是提供应聘者的查询职位、简历录入、回答试题，提交简历等。

管理端的功能提供公司人力资源管理人员进行的知识库管理、试卷管理、职位管理、简历管理、用户管理等。

他们的关系如图A-1。

1我们采用面向对象分析作为主要的系统建模方法，使用UML(Unified Modeling Language)作为建模语言。

UML 为建模活动提供了从不同角度观察和展示系统的各种特征的方法。

在UML 中，从任何一个角度对系统所作的抽象都可能需要几种模型来描述，而这些来自不同角度的模型图最终组成了系统的映像。

Use Case 描述的是“actor ”(用户、外部系统以及系统处理)是如何与系统交互来完成工作的。

Use Case 模型提供了一个非常重要的方式来界定系统边界以及定义系统功能，同时，该模型将来可以派生出动态对象模型。

设计Use-case 时，我们遵循下列步骤：第一步，识别出系统的“actor ”。

Actor 可以是用户、外部系统，甚至是外部处理，通过某种途径与系统交互。

重要的是着重从系统外部执行者的角度来描述系统需要提供哪些功能，并指明这些功能的执行者(Actor)是谁。

尽可能地确保所有Actor 都被完全识别出来。

第二步，描述主要的Use Case 。

可以采取不断地问自己“这个Actor 究竟想通过系统做什么？”来准确地描述Use Case 。

实验报告册课程： UML系统建模学号：专业：网络工程班级：指导老师：凌凤彩2011 至 2012 学年第 2 学期洛阳师范学院信息技术学院实验注意事项：1、要求实验前做好充分的准备。

2、实验过程中严格遵守实验规则，认真完成实验内容，详细记录实验结果。

3、实验结束后，认真填写实验报告册，并做好实验分析和实验体会。

实验时间： 6 月 20 日 3,4 节星期二实验地点：逸夫楼A204实验名称：对瑞天图书管理系统的动态建模之状态图实验目的：1. 掌握状态图的基本定义，组成结构，用途。

2.能够对于给定的系统区分区分对象的状态变化3．能够熟练的应用rose来创建状态图。

4. 在用例图的基础上创建瑞天图书管理系统的状态图。

实验准备瑞天图书管理系统已连接成功实验环境：一台能够正常工作的具有rose软件的计算机实验原理：1.状态图清晰地描述了状态之间的转换顺序，通过状态的转换顺序可以清晰看出事件的执行顺序。

状态图通过判定可以更好地描述工作流因为不同的条件发生的分支。

2. 在瑞天图书管理系统中，只有图书卡与图书有状态的转变，因此只需确定这两者的状态图。

实验步骤：1.确定状态图的主体，他可以是一个系统，一个用例，一个对象。

在瑞天图书管理系统中可以确定状态图的主体为：图书卡和图书。

2.确定主体的生存期的各种稳定的状态及顺序；对于图书卡的状态有：正常，挂失，停止，注销，停用。

对于图书的状态有：在库，下架，预定，借出，注销。

3.确定状态迁移的事件，如：对于图书卡：由正常-挂失的事件为“丢失”；由正常-停用的事件为“申请”；由停用-正常的事件为“启用”；由挂失-正常的事件为“解挂失”；由正常-注销的事件为“申请”；对于图书：由在库-下架的事件为“图书下架”；由在库-预定的事件为“读者预定”；由预定-在库的事件为“预定超时”；等4. 附加上必要的动作，把动作附加到相应的迁移线上或对应的状态框内；5. 审核状态图，确认所有状态在事件触发下都可到达、死锁状态（无迁移）。