UML顺序图画法

合集下载

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.UML类的符号是一个被划分成三块的方框:类名,属性,和操作.抽象类的名字,像Payment是斜体的.类之间的关系是连接线.类图有三种关系.关联association-表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中,关联用两个类之间的连线表示.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.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.。

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.标准文档UML类的符号是一个被划分成三块的方框:类名,属性,和操作.抽象类的名字,像Payment是斜体的.类之间的关系是连接线.类图有三种关系.关联association-表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中,关联用两个类之间的连线表示.标准文档标准文档为了简单地表示出复杂的类图,可以把类组合成包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.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.标准文档标准文档标准文档。

UML动态建模中的UML顺序图

UML动态建模中的UML顺序图

2、消息的UML图形表示 (1)在UML中,消息的图形表示是用带有箭头的线段将消息 的发送者和接收者联系起来 (2)箭头的类型表示消息的类型、方向为从源对象指向目 标接收者对象,其上标有表示消息的文字的内容标签。
注意:同步消息用带三角箭头的实箭线表示,异步消息用 带半叉箭头的实箭线表示。
3、对消息的类型的说明 (1)简单消息(Simple Message) 消息在单个控制线程中运行,一般用于描述控制如何 在对象间进行传递,而不考虑通信的细节。 (2)同步消息(Synchronous Message) 调用者发出消息后必须等待消息返回,只有当处理消 息的操作执行完毕后,调用者才可继续执行自己的操作。 (3)异步消息(Asynchronous Message) 当调用者发出消息后不用等待消息的返回即可继续 执行自己的操作。
异步消息主要用于描述实时系统中的并发行为。
1、顺序图(序列图) (1)含义 作为交互图中的一种,序列图显示参与交互作用的参 与者或对象,以及它们生成的按时间排序的事件。 通常,序列图显示特定用例实例产生的事件并且侧重 描述消息在对象之间如何传送。 (2)主要的作用 按时间顺序对控制流建模,主要用于对用例中的控制 流的建模---体现用例的实现过程。 它显示出随着时间的变化对象之间是如何通信的。 同时也清楚地表示在实现某个用例时所涉及的各个类 (3)顺序图中的各个坐标的含义 顺序图中的纵向维代表时间,按时间先后依次向下排序。 横向维代表不同的主角或对象
UML动态建模中的UML顺序图
UML动态建模---顺序图
在本讲您能了解如下内容
动态建模所涉及的内容 对象间的交互---消息 动态建模中的顺序图 顺序图应用及要点 在Rose中创建出顺序图
一、动态建模所涉及的内容

UML中各种图的画法(全)

UML中各种图的画法(全)

UML中各种图的画法(全)一、UML中基本的图范畴:在 UML 2 中有二种基本的图范畴:结构图和行为图。

每个 UML 图都属于这二个图范畴。

结构图的目的是显示建模系统的静态结构。

它们包括类,组件和(或)对象图。

另一方面,行为图显示系统中的对象的动态行为,包括如对象的方法,协作和活动之类的内容。

行为图的实例是活动图,用例图和序列图。

二、UML中的类图:1.类图的表示:类的 UML 表示是一个长方形,垂直地分为三个区,如图 1 所示。

顶部区域显示类的名字。

中间的区域列出类的属性。

底部的区域列出类的操作。

在一个类图上画一个类元素时,你必须要有顶端的区域,下面的二个区域是可选择的(当图描述仅仅用于显示分类器间关系的高层细节时,下面的两个区域是不必要的)。

描述:顶部区域显示类的名字。

中间的区域列出类的属性。

底部的区域列出类的操作。

当在一个类图上画一个类元素时,你必须要有顶端的区域,下面的二个区域是可选择的(当图描述仅仅用于显示分类器间关系的高层细节时,下面的两个区域是不必要的)。

·类名:如果是抽象类,则采用斜体·类属性列表:name : attribute type 如 flightNumber : Integer,这是最常见的表达形式n ame : attribute type = default value 如balance : Dollars = 0,这是带有默认值的表达形式·类方法列表:name(parameter list) : type of value returned注意:在业务类图中,属性类型通常与单位相符,这对于图的可能读者是有意义的(例如,分钟,美元,等等)。

然而,用于生成代码的类图,要求类的属性类型必须限制在由程序语言提供的类型之中,或包含于在系统中实现的、模型的类型之中。

2.继承的表示:为了在一个类图上建模继承,从子类(要继承行为的类)拉出一条闭合的,单键头(或三角形)的实线指向超类。

UML顺序图ppt课件

UML顺序图ppt课件

getCustomerInput(cash,selection) checkAvailability(selection)
returnCash(cash)
Sold out
displayPrompt("sold out")
23
零钱数量不对的场景
这种场景是顾客多给钱的场景。比如可 乐3块,投入了4块。饮料机可以把多的 钱找回给顾客。
displayPrompt("use correct change)
26
练习
“发传真”用例的最理想的场景。 其中对象包括:发送方传真、接受方传 真、传真件和一台用来对传真和电话呼 叫选择路由的中央“交换机”。
27
发传真类似打电话
打电话
主叫
被叫
主叫拿起电话,拨被叫电话号码,通过交换机向 双方发电话铃声,被叫接电话,铃声停止。
[2] Joseph Schmuller.UML基础、案例与应 用.人民邮电出版社,2004,8:P90-105
38
}
tv.close();
…..;
}
}
}
31
消息的代码表示 tv.close();
消息= 接受对象名+接受者能做的操 作
32
顺序图中的消息
调用消息 异步消息 返回消息 阻止消息:消息发送者发出消息给接收者,如
果接收者无法立即接收消息,则发送者放弃该 消息。 超时消息:消息发送者发出消息给接收者并按 指定时间等待,如果接收者无法在指定时间内 接收消息,则发送者放弃该消息。
28
使用UML表示
caller
exchange
receiver
1: lift receiver

UML课件4 顺序图与协作图课件

UML课件4 顺序图与协作图课件

? 条件短语通常用伪代码或真正的程序语言来表示, UML并不规定其语法
?
例如, [x<0] 4: invert(x, color)
? 序列表达式 (sequence-expression)
?
语法 [integer | name] [recurrence] :
? integer 为指定消息顺序的序列号,消息1是消息序列的 开始消息消息,1.1是消息1的处理过程中的第一条嵌套 的消息,消息1.2是消息1的处理过程中的第二条嵌套的 消息,一个消息序列的例子如1, 1.1, 1.2, 1.2.1, 1.2.2, 1.3, 等。这样的序列号不仅能够表示消息的顺序而且还 能表示消息的嵌套关系(当消息是异步消息时消息为嵌套 的操作调用及返回)
4.2.5 消息
? UML三种消息:
? 返回(Return ) ? 表示消息的返回。消息上方放置返回值 ? 同步消息的返回可以画出(如果想明确表达返回 值),也可以不画出,直接隐含。 ? 异步消息可以有返回,也可以没有。(可以响应异 步消息,也可以不响应该异步消息。) ? 如果顺序图上显示有编号,则返回消息的编号和当 初发送消息的编号完全一样。 ? 虚线箭头表示,和依赖关系不要混淆
? Rose 扩充:
? 阻止(Balking ) ? 超时(Time-out )
4.2.5 消息
? UML三种消息:
? 调用(Procedure Call ) ? 发送者把消息发送后,等待直到接收者返回控制, 可以表示同步; ? 实心箭头符号
4.2.5 消息
? UML三种消息:
? 异步(Asynchronous ) ? 消息发送后,发送者继续操作,不等待,常用于并 发;
? Q:这两种消息可以看做是同步or 异步消息?

UML建模风格之顺序图

UML建模风格之顺序图

UML建模风格之顺序图和合作图、活动图一样,UML顺序图( Rumbaugh、Jacobson、和booch, 1999)是一种动态建模方法。

UML顺序图一般用于:1.确认和丰富一个使用情境的逻辑。

一个使用情境就是系统潜在的使用方式的描述,也就是它的名称所要描述的。

一个使用情境的逻辑可能是一个用例的一部分,或是一条备选线路;一个贯穿单个用例的完整流程,例如动作基本过程的逻辑描述,或是动作的基本过程的一部分再加上一个或多个的备用情境的逻辑描述。

或是包含在几个用例中的流程,例如一个学生注册入学之后,立即就要在三个班级注册。

2.研究你的设计,因为它们为你提供了一种方式,你可以使用这种方式来可视化的调用类定义的操作。

3.检测面向对象的设计中的瓶颈。

通过观察什么消息被发送给一个对象,以及通过概略的观察运行被调用的方法需要花费多长时间,你很快就能了解那里的设计需要变化,以达到在系统内部平衡负荷的目的。

实际上某些CASE工具甚至能够让你模拟软件这些特征。

4.使你能够感觉到你的应用程序的那个类将会变得复杂的,这是个信号,意味着你需要为那些类画状态图了。

指南∶通用准则尽力保持消息的顺序从左到右排列将分类器分层用和你的用例图一致的名称命名角色用和你的类图一致的名称命名类一个角色的名称可以和类的名称相同包含一个逻辑的叙述性描述在图的最左边放置初始的角色在图的最左边放置人和组织角色在图的最右边放置系统角色只在合适的时候才建模对象的Destruction分类器的原则当你在消息上引用对象时要命名他们当存在部分相同的类型时需要命名对象一致地应用文本版型少量地应用可视化的版型集中在关键的交互消息的原则把消息名放在箭头旁边直接创建对象为软件消息使用操作符号为涉及人和组织角色的消息使用叙述性文字推荐使用参数名称,而不是参数类型为参数占位符注明类型类的消息实现为静态操作为用例调用使用<<include>>版型返回值的原则当返回值非常明显时就不要对返回值建模只有当你需要在别处引用返回值时才对返回值建模在箭头旁边调整返回值返回值建模为方法调用的一部分为返回值占位符注明类型明确的为简单值标明实际值一、通用准则1.尽力保持消息的顺序是从左到右排列的一个顺序图的消息流开始于左上方,消息乙的位置比消息甲低,这意味着消息乙的顺序比消息乙要迟。

UML---顺序图

UML---顺序图

建立顺序图的步骤
1. 确定交互过程的上下文(context); 2. 识别参与交互过程的对象; 3. 为每个对象设置生命线,即确定哪些对象存在于整个交互过 程中,哪些对象在交互过程中被创建和撤销; 4. 从引发这个交互过程的初始消息开始,在生命线之间从顶到 下依次画出随后的各个消息; 5. 如果需要表示消息的嵌套,或/和表示消息发生时的时间点, 则采用FOC; 6. 如果需要说明时间约束,则在消息旁边加上约束说明; 7. 如果需要,可以为每个消息附上前置条件和后置条件。
图书管理系统——借书顺序图
练习1:还书顺序图
练习2:解释下面的顺序图
:顾客 接收顾客现钞和选择 获得顾客输入 [现钞>价格]找零 [没有零钱]返还现金 显示提示信息 《transaction over》[没有 零钱] [售完]返还现金 显示提示信息 《transaction over》[售完] 更新现钞储存 检查库存 :前端 :记录仪 :分配器
初步类图
购买饮料主要场景的顺序图
已售完场景的顺序图
“零钱数目不对”的场景
“零钱找不开”场景的顺序图
一般的顺序图
:顾客 接收顾客现钞和选择 获得顾客输入 [现钞>价格]找零 [没有零钱]返还现金 显示提示信息 《transaction over》[没有 零钱] [售完]返还现金 显示提示信息 《transaction over》[售完] 更新现钞储存 检查库存 :前端 :记录仪 :分配器
用例阐述:
“购买饮料”用例的次要场景1—饮料已售完 1)若饮料已售完,记录仪要求显示屏显示“已售完” 2)记录仪将钱币从退币口返回给顾客 “购买饮料”用例的次要场景2—需要找零 1)记录仪查找自己的现金储备以便找零; 2)记录仪更新自己的钱币存储记录; 3)记录仪将找回的钱通过退币口返还给顾客; 4)记录仪通知饮料分配器传送一罐饮料到出货口。 “购买饮料”用例的次要场景3—零钱找不开 1)记录仪查找自己的现金储备以便找零; 2)如果无法找零,记录仪要求显示屏显示“投入正好的货 币” 3)记录仪将钱币从退币口返回给顾客
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
UML顺序图
【学习目标】
· 定义顺序图 · 为什么要建立顺序图 · 了解顺序图的标记符组件 · 理解如何使用消息进行通信 · 学习顺序图使用的其他技术 · 学习如何建模顺序图
UML交互图
在标识出系统的类图之后,仅给出了实现用例的组成结构,这 时还需要描述这些类的对象是如何交互来实现用例功能的。即不但 需要把用例图模型转化为类图模型,还要将它转化为交互图模型。
ห้องสมุดไป่ตู้
五、 顺序图的其他技术 学习如何在创建顺序图的过程中创建对象。与活动图一样,可 以在顺序图中设臵拥有控制权的对象状态。另外一点和活动图相似 的是,可以通过使用分支和从属控制流来以多种方式修改顺序图的 控制流。 1.创建对象 创建对象的标记符如下图中的示例所示。有一个主要步骤用来 把“create” 消息发送给对象实例。对象创建之后就会具有生命线, 可以使用该对象发送和接收消息。在处理新创建的对象,或者处理 顺序图中的任何其他对象时,都可以发送“destroys”消息来删除 对象。若要想说明某个对象被销毁,需要在被销毁对象的生命线上 放一个X字符。
四、如何使用消息进行通信 消息是顺序图活动对象之间通信的惟一方式。UML中的消息 使用了一些简洁的标记符。 消息可以包含条件以便限制它们只在满足条件时才能发送。 条件显示在消息名称上面的方括号中,如下图所示。
下面示例演示了如何建模一个顺序图来显示登录尝试。如果 登录失败,会在放弃登录之前重试一次,如下图所示。
上面的图例说明了参与者和对象可以把消息发送给顺序图中 的任何参与者或者对象。它们可以把消息发送给不是其直接相邻 的参与者或者对象。 下面看一个意义更加丰富的示例。对于Compile Application 用例,我们可以创建一个成功编译工作流的顺序图,如下图所示。
这个顺序图中有4个活动对象:Developer、Compiler、 Linker和FileSystem。Developer是系统的参与者。Compiler是 Developer交互的应用程序。Linker是一个用来链接对象文件的独 立进程。FileSystem是系统层功能的包装器,用来执行文件的输人 和输出例程。 Compile Application用例的顺序图操作: Developer请求Compiler执行编译 Compiler请求FileSystem 加载文件 Compiler通知自己执行编译 Compiler请求FileSystem 保存对象代码 Compiler请求Linker链接对象代码 Linker请求 FileSystem加载对象代码 Liker通知自己执行链接 Linker请求FileSystem保存编译的结果
从属流还允许控制流根据条件改变,但是只允许控制流改变为 相同对象的另一条生命线分支,如下图所示。
在下面的示例中,Editor在用户删除文件或者保存文件时向 Filesystem发送一条消息。显然,Filesystem将会执行两种完全 不同的活动,并且每一个工作流都需要独立的生命线,如下图 所示。
练习:阅读一个顺序图 阅读下图所示的顺序图,该图说明了开发者编译应用程序的 步骤。在阅读顺序图时,请指出我们到目前为止已经学习过的标 记符组件。 练习步骤 1)指出顺序图中的参与者和对象。 2)指出出错处理发生的位臵。 3)按照控制流的顺序指出各个消息。
六、学习如何建模顺序图 创建顺序图包含4项任务: 1)确定需要建模的工作流。 2)从左到右布臵对象。 3)添加消息和条件以便创建每一个工作流。 4)绘制总图以便连接各个分图。 1.确定工作流 建模顺序图的第一步是确定将要建模的工作流。对于这个练 习,我们将要建模Grading system的View Grades用例。为此,需 要至少标识出3个要建模的工作流: •教师成功地检查学生分数 •教师试图检查某个学生分数,但是该学生在系统中不存在。 •教师试图检查某个学生分数,但是该学生分数在系统中不存在。
2.分支和从属流 有两种方式来修改顺序图的控制流:使用分支和使用从属流。 这两种方式很相似,各自的标记符略微不同。控制流的改变是由 于不同的条件导致控制流走向不同的道路。 分支允许控制流走向不同的对象,如下图所示。
注意消息的开始位臵是相同的,分支消息的结束“高度”也是 相等的。这说明在下一步中,其中之一将会执行,如下图所示。
三、顺序图的标记符 顺序图有两个主要的标记符:活动对象和这些活动对象之间 的通信消息。活动对象可以是任何在系统中扮演角色的对象,不 管它是对象实例还是参与者,如下图所示。
活动对象之间发送的消息是顺序图的关键。消息说明了对象之 间的控制流,对象是如何交互的,以及什么条件会改变控制流。 1.活动对象 活动对象可以是系统的参与者或者任何有效的系统对象。对 象是类的实例,它使用包围名称的矩形框来标记。名称带下划线, 顺序图中对象的标记符如下图所示。
2.布臵对象 建模顺序图的下一步是从左到右布臵所有的参与者和对象, 包含要添加消息的对象生命线,如下图所示。
3.添加消息和条件 接下来,对每一个工作流作为独立的顺序图建模。从基本的工 作流开始,它是没有出错条件,并且需要最少决策的工作流。在本 例中,基本工作流是教师成功地检查某个学生的分数,如下图所示。
交互图表示类(对象)如何交互来实现系统行为。交互图具有 如下两种形式。 1) 顺序图 它描述对象按时间顺序的消息交换过程,它体现出系统用例的 行为。 2) 协作图 它描述对象间的组织协作关系,它也可体现出系统用例的行为。 顺序图和协作图都可以表示对象间的交互关系,但它们的侧重 点不同。顺序图用消息的几何排列关系来表达对象间交互消息的先 后时间顺序。而协作图则建模对象(或角色)间的通信关系。
2.消息 消息用来说明顺序图中不同活动对象之间的通信。它可在一 个对象需要取消不同对象的进程时或者需要向另一个对象提供服 务时,使用消息。 消息从活动对象生命线到接收对象生命线的箭头表示。箭头 上面标记要发送的消息,如下图所示。
把参与者表示为活动对象的建模可以说明参与者如何与系统交 互,以及系统如何与用户交互。参与者可以调用对象,对象也可以 通知参与者,如下图所示。
练习:建模一个顺序图 在这个练习中,将要为在销售商品后从库存清单中删除该商品 条目的用例创建顺序图。综合运用自己掌握的顺序图的各种UML标 记符,包括消息传递和消息类型、条件、分支,以及从属流。 练习步骤: 1)确定将要作为独立的顺序图建模的工作流。 2)布臵各个独立的顺序图的对象。 3)为各个独立的顺序图添加消息和条件。 4)从各个独立的顺序图建模一个总顺序图。
注意选择适当的消息类型(异步、同步、简单和返回)。接下 来以独立的顺序图建模从属工作流。此处只建模否定的条件,如下 图所示。
注意使用条件来指示在什么时候发送什么消息,如下图所示。 现在已经完成了每一个工作流的顺序图。
4.绘制总图 建模顺序图的最后一步是把所有独立的工作流连接为一个总图, 如下图所示。 在此阶段,如果觉得前面的消息和交互对于当前的顺序图过于 详细,可以让它们更加泛化一些,但是在软件建模的下一个阶段, 就会觉得初始的各个顺序图越详细越好。
使用顺序图建模
一、定义顺序图 顺序图是两种类型的交互图之一。顺序图用来建模以时间顺 序安排的对象交互,并且把用例行为分配给类。它是用来显示参与 者如何采用若干顺序步骤与系统对象交互的模型。 二、为什么要建模顺序图 建模顺序图有许多理由,顺序图与活动图具有类似的作用。其 中重要的理由就是实现用例。任何用例都可以使用顺序图进一步阐 明和实现。
相关文档
最新文档