标签归档:uml

uml活动图的概念与作用

uml是程序员需要掌握一个重要工具,特别在研究hadoop(http://www.iigrowing.cn/hadoop)系统中,有很多相关的uml图形需要绘制,为了方便大家了解uml,在网络上找了些uml方面的文章(http://www.iigrowing.cn/?s=uml)在参考资料中,在uml参考资料中缺少活动图方面的介绍,因此特地在网络上寻找了一些资料,然后整理成一篇文章,供大家参考,水平有限疏漏难免,请谅解.

一.UML概述

以下内容对uml进行简单介绍,读者有兴趣可以阅读,建议读者可以阅读其他uml等文章,最后有时间在了解这个部分内容。这样可以先去实践一些uml,然后在回到这里的一些简单的理论介绍,收获会大些。

UML 全称Unified Modeling Language 又称统一建模语言或标准建模语言,是始于1997年一个OMG标准,它是一个支持模型化和软件系统开发的图形化语言,为软件开发的所有阶段提供模型化和可视化支持。

UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程。

作为一种建模语言,UML的定义包括UML语义和UML表示法两个部分。

(1) UML语义 描述基于UML的精确元模型定义。元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明,使开发者能在语义上取得一致,消除了因人而异的最佳表达方法所造成的影响。此外UML还支持对元模型的扩展定义。

(2) UML表示法 定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型,在语义上它是UML元模型的实例。

标准建模语言UML的重要内容可以由下列五类图(共9种图形)来定义:

第一类是用例图,

从用户角度描述系统功能,并指出各功能的操作者。

第二类是静态图 (Static diagram),

包括类图、对象图和包图。其中类图描述系统中类的静态结构。不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构(类的属性和操作)。类图描述的是一种静态关系,在系统的整个生命周期都是有效的。

对象图是类图的实例,几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例,而不是实际的类。一个对象图是类图的一个实例。由于对象存在生命周期,因此对象图只能在系统某一时间段存在。

包由包或类组成,表示包与包之间的关系。包图用于描述系统的分层结构。

第三类是行为图(Behavior diagram),

描述系统的动态模型和组成对象间的交互关系。行为图包括:状态图、活动图、顺序图和协作图。其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。通常,状态图是对类图的补充。在实用上并不需要为所有的类画状态图,仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。 而活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动。活动图是一种特殊的状态图,它对于系统的功能建模特别重要,强调对象间的控制流程。 顺序图展现了一组对象和由这组对象收发的消息,用于按时间顺序对控制流建模。用顺序图说明系统的动态视图。 协作图展现了一组对象,这组对象间的连接以及这组对象收发的消息。它强调收发消息的对象的结构组织,按组织结构对控制流建模。 顺序图和协作图都是交互图,顺序图和协作图可以相互转换。

第四类是交互图(Interactive diagram),

描述对象间的交互关系。其中顺序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;合作图描述对象间的协作关系,合作图跟顺序图相似,显示对象间的动态合作关系。除显示信息交换外,合作图还显示对象以及它们之间的关系。如果强调时间和顺序,则使用顺序图;如果强调上下级关系,则选择合作图。这两种图合称为交互图。

第五类是实现图 ( Implementation diagram )。

其中构件图描述代码部件的物理结构及各部件之间的依赖关系。一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。它包含逻辑类或实现类的有关信息。部件图有助于分析和理解部件之间的相互影响程度。

配置图定义系统中软硬件的物理体系结构。它可以显示实际的计算机和设备(用节点表示)以及它们之间的连接关系,也可显示连接的类型及部件之间的依赖性。在节点内部,放置可执行部件和对象以显示节点跟可执行软件单元的对应关系。

从应用的角度看,当采用面向对象技术设计系统时,

首先是描述需求;

其次根据需求建立系统的静态模型,以构造系统的结构;

第三步是描述系统的行为。

其中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图(包含包)、对象图、组件图和配置图等五个图形,是标准建模语言UML的静态建模机制。

其中第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言UML的动态建模机制。因此,标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。

二.活动图介绍

1. 简介

活动图是uml的动态模型的一种图形,一般用来描述相关用例图。准确的活动图定义:活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动。活动图是一种特殊的状态图,它对于系统的功能建模特别重要,强调对象间的控制流程。

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

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

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

2. 活动图示例

下图是个简单的活动图例子,里面包括了大部分活动图的相关元素,大家应该都能看的差不多吧,有不明白的可以继续看,下面有针对各个元素有介绍啦,相信大家看完后面的,看这个图就不会有问题的。

另外,若想学会画活动图,必须先看大量的图,看明白别人的图,在慢慢画,慢慢一个图形就弄明白了。

其实uml包括了各种各样的图形,把每种图形都会画啦,基本uml也就会啦。

wps_clip_image-29542[3][1]

3. 活动图与流程图的区别

活动图描述系统使用的活动、判定点和分支,看起来和流程图没什么两样,并且传统的流程图所能表示的内容,大多数情况下也可以使用活动图表示,但是两者是有区别的,不能将两个概念混淆。

wps_clip_image-6467[3][1]

活动图与流程图的区别

⑴ 流程图着重描述处理过程,它的主要控制结构是顺序、分支和循环,各个处理过程之间有严格的顺序和时间关系

活动图描述的是对象活动的顺序关系所遵循的规则,它着重表现的是系统的行为,而非系统的处理过程。

⑵ 活动图能够表示并发活动的情形,而流程图不能。

⑶ 活动图是面向对象的,而流程图是面向过程的。

4. 活动图与状态图区别

活动图与状态图都是状态机的表现形式,但是两者还是有本质区别:

状态图着重描述从一个状态到另一个状态的流程,主要有外部事件的参与。

wps_clip_image-5186[3][1]

上图是一个典型的状态图

活动图着重表现从一个活动到另一个活动的控制流,是内部处理驱动的流程。

wps_clip_image-23087[3][1]

5. 活动图基本元素

1) 初始节点和活动终点:

实心圆表示初始节点(只有一个),圆圈内加一个实心圆来表示活动终点(可有多个)。wps_clip_image-11674[3][1]

2) 活动节点:

用来表示一个活动

wps_clip_image-9712[3][1]

3) 转换:

一条带箭头的直线来表示。 一旦前一个活动结束马上转到下一个活动(无触发转换)。wps_clip_image-32407[3][1]

4) 分支与监护条件:

分支是用菱形表示的,它有一个进入转换(箭头从外指向分支符号),一个或多个离开转换(箭头从分支符号指向外)。而每个离开转换上都会有一个监护条件,用来表示满足什么条件的时候执行该转换。

wps_clip_image-9047[3][1]

5) 分叉与汇合:

分叉用于将动作流分为两个或者多个并发运行的分支,而汇合则用于同步这些并发分支,以达到共同完成一项事务的目的。

分叉可以用来描述并发线程,每个分叉可以有一个输入转换和两个或多个输出转换,每个转换都可以是独立的控制流。

汇合代表两个或多个并发控制流同步发生,当所有的控制流都达到汇合点后,控制才能继续往下进行。

wps_clip_image-3562[3][1]

每个汇合可以有两个或多个输入转换和一个输出转换。

汇合将两条路径连接到一起,合并成一条路径。汇合指的是两个或者多个控制路径在此汇合的情况。汇合是一种便利的表示法,省略它不会丢失信息。汇合和分支常常成对的使用,合并表示从对应分支开始的条件行为的结束。

分叉和汇合都使用加粗的水平线段表示。

wps_clip_image-21739[3][1]

6. 抽象的活动图示例

wps_clip_image-30765[3][1]

UML的活动图中包含的图形元素有动作状态、活动状态、动作流、分支与合并、分叉与汇合、泳道和对象流等。

7. 带泳道的活动图

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

wps_clip_image-16451[3][1]

每个泳道代表特定含义的状态职责的部分。在活动图中,每个活动只能明确的属于一个泳道,泳道明确的表示了哪些活动是由哪些对象进行的。

每个泳道都有一个与其他泳道不同的名称。

每个泳道可能由一个或者多个类实施,类所执行的动作或拥有的状态按照发生的事件顺序自上而下的排列在泳道内。

wps_clip_image-16992[3][1]

在活动图中泳道区分了负责活动的对象,它明确地表示了哪些活动是由哪些对象进行的。

在包含泳道的活动图中每个活动只能明确地属于一个泳道

wps_clip_image-7452[3][1]

上图是一个未采用泳道的活动图

wps_clip_image-22809[3][1]

上图是采用泳道技术后的活动图

从两幅图的对比中,我们可以了解泳道技术是非常重要的,可以更明确表达出活动图的意图。

泳道将活动图中的活动化分为若干组,并把每一组指定给负责这组活动的业务组织,即对象。

wps_clip_image-12866[3][1]

泳道区分了负责活动的对象,它明确地表示了哪些活动是由哪些对象进行的。

在包含泳道的活动图中,每个活动只能明确地属于一个泳道。

wps_clip_image-27229[3][1]

在活动图中,泳道用垂直实线绘出,垂直线分隔的区域就是泳道。

在泳道上方可以给出泳道的名字或对象(对象类)的名字,该对象(对象类)负责泳道内的全部活动。

泳道没有顺序,不同泳道中的活动既可以顺序进行也可以并发进行。

动作流和对象流允许穿越分隔线。

8. 带对象流的活动图

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

wps_clip_image-30329[3][1]

wps_clip_image-30539[3][1]

对象流是动作状态或者活动状态与对象之间的依赖关系

对象流表示动作使用对象或者动作对对象的影响。

wps_clip_image-32275[3][1]

对象流中对象的特点:

⑴ 一个对象可以由多个动作操纵;

⑵ 一个动作输出的对象可以作为另一个动作输入的对象;

对象流中对象的特点:

⑶ 在活动图中,同一个对象可以多次出现,它的每一次出现表明该对象正处于对象生存期的不同时间点。

在活动图中,对象流用带有箭头的虚线表示。

如果箭头从动作状态出发指向对象,则表示动作对对象施加了一定的影响。

施加的影响包括创建、修改和撤销等。如果箭头从对象指向动作状态,则表示该动作使用对象流所指向的对象。

状态图中的对象用矩形表示,矩形内是该对象的名称,名称下的方括号表明对象此时的状态。

还可以在对象名称的下面加一个分隔栏表示对象的属性值。

9. 信号发送和接收

发送信号与接收信号

wps_clip_image-9203[3][1]

10. 引脚

是一个对象节点,代表活动连接输入、输出值的连接点

用来标明每个活动节点所需输入的数据或者所产生的数据(建模业务流时则可表示产生或者消耗的资源)

wps_clip_image-16855[3][1]

11. 扩展区

表示重复或循环

wps_clip_image-16146[3][1]

12. 辅助活动图

当活动图过于复杂时可以用活动的分解来处理

wps_clip_image-29273[3][1]

一个活动可以分为若干个动作或子活动,这些动作和子活动本身又可以组成一个活动图。

不含内嵌活动或动作的活动称之为简单活动;

嵌套了若干活动或动作的活动称之为组合活动,组合活动有自己的名字和相应的子活动图

wps_clip_image-2191[3][1]

wps_clip_image-25344[3][1]

三.活动图绘制要点

⑴ 识别要对工作流描述的类或对象。找出负责工作流实现的业务对象,这些对象可以是显示业务领域的实体,也可以是一种抽象的概念和事物。找出业务对象的目的是为每一个重要的业务对象建立泳道。

⑵ 确定工作流的初始状态和终止状态,明确工作流的边界。

⑶ 对动作状态或活动状态建模。找出随时间发生的动作和活动,将它们表示为动作状态或活动状态。

⑷ 对动作流建模。对动作流建模时可以首先处理顺序动作,接着处理分支与合并等条件行为,然后处理分叉与汇合等并发行为。

⑸ 对对象流建模。找出与工作流相关的重要对象,并将其连接到相应的动作状态和活动状态。

⑹ 对建立的模型进行精化和细化。

虚拟商品在线交易系统UML分析与设计文档

本小组项目任务是开发一个虚拟商品在线交易系统。卖家需要一个全新的在线交易系统,用于向网络买家提供一个集在线购买和在线下载功能于一身的网络交易平台,销售的物品主要是正版软件和网络游戏充值卡等非实体的虚拟商品。本系统需要支持和集成支付宝公司的“虚拟商品交易服务”接口,并通过该接口收取买家费用,在交易完成后返回到本系统界面下给买家下载软件安装程序、软件激活码或充值卡密码等。

系统允许卖家在系统后台对商品进行维护,卖家可以在后台管理系统中对所销售的软件产品和充值卡商品进行修改、添加和删除,并可以查询所有买家信息。

系统允许买家在注册后对个人信息进行修改和维护,并查阅自己的购买记录;对于没有注册的临时买家,也可以直接购买,在交易完成后把其信息记录到数据库,但不会为临时买家注册系统ID。

系统允许买家在交易完成后通过网页界面在线下载软件安装程序,但需要做到防盗链,即防止软件的下载地址被公开或盗用,此项主要针对不需要激活码激活的软件产品。而对于软件激活码或充值卡密码,除了在交易完成后会在页面上显示外,也会自动E-MAIL一份到买家的电子邮箱里去。

同时,服务器使用Linux系统,安装有Apache、PHP和MySQL,需要把销售情况记录到MySQL数据库中,以便业务人员查询销售情况和进行管理。

系统需要对每周和每月销售的情况进行统计,并列印成报表,同时允许在线生成Excel及PDF格式文件以便保存。

2 需求分析

2.1 用例图

虚拟商品在线交易系统的用例图如图2-1所示,包括:用户登陆系统、商品展示系统、购物车、结算付款、支付宝服务接口、用户及定单管理系统、商品管理。

wps_clip_image-15689

图2-1. 虚拟商品交易系统用例图

2.2 术语表

User:用户、顾客;

Shop Administrator:网上商店管理员、商家;

Products:商品、虚拟商品、非实体的商品;

Shopping Cart:购物车;

Payment:结算付款;

Alipay.com Server:支付宝服务器、与我方制作支付宝收款接口相连;

Order:在线定单。

2.3 活动图

2.3.1结算付款系统活动图

如图2-2所示,对应的用例规约请见表2.4-1:

wps_clip_image-5185

图2-2. 结算付款系统活动图

2.4 用例规约

2.4.1用例规约Login

表2.4-1. 用例规约Login

主要参与者

用户及网上商店管理员

前置条件

输入正确的用户名、密码

后置条件(成功后的保证)

登入系统

基本流程(主要成功场景)

1) 输入用户名、密码

2) 验证用户名、密码

3) 如验证正确,登入系统

辅助流程(替代流程)

输入用户名或密码不正确:

1) 统显示错误信息

2) 提示用户重新输入

2.4.2用例规约Payment

表2.4-2. 用例规约Payment

主要参与者

用户或游客

前置条件

用户或游客已经把商品加入到购物车,并按下结算按钮

后置条件(成功后的保证)

返回商品结算清单及所需费用

基本流程(主要成功场景)

1) 户按下结算按钮

2) 系统显示购物列表及总价

3) 系统询问游客是否注册或登陆

4) 定单提交到支付宝接口

5) 用户通过支付宝或信用卡完成付款

6) 支付完成返回网上商店,显示下载地址及产品注册码、或点卡密码

辅助流程1(替代流程)

游客不登陆或注册:

1) 以游客身份把定单提交到支付宝接口

辅助流程2(替代流程)

游客以注册用户名登陆或注册:

1) 登陆后返回购物车

2) 以注册用户身份提交定单到支付宝接口

辅助流程3(替代流程)

用户或游客未完成支付或支付出错:

1) 返回网上商店

2) 显示定单未结算,不能下载虚拟商品

(*对应的活动图请参考图2-2)

2.4.3用例规约Shopping Cart

表2.4-3. 用例规约Shopping Cart

主要参与者

用户或游客

前置条件

用户或游客已经挑选商品,并且商品已经为勾选状态。

后置条件(成功后的保证)

返回商品名称、数量、价格及总计

基本流程(主要成功场景)

1) 系统显示购物列表及总价

2) 系统提供对所购物品的修改处理,或继续购物的功能选择

3) 转到结算模块

4) 转回购物网站

辅助流程1(替代流程)

游客不登陆或注册:

1) 以游客身份显示购物列表

辅助流程2(替代流程)

游客以注册用户名登陆或注册:

1) 登陆后返回购物车

2) 以注册用户身份显示购物列表

辅助流程3(替代流程)

用户或游客未完成挑选物品:

1) 返回提示未进行购物

2) 选择返回购物网页

2.4.4用例规约User Management

表2.4-4. 用例规约User Management

主要参与者

管理员

前置条件

以管理员身份登陆,并按下管理按钮。

后置条件(成功后的保证)

返回管理后台首页

基本流程(主要成功场景)

1) 显示已注册用户列表

2) 在列表中选择一个要操作的用户

3) 选择一种操作

4) 显示操作页面

5) 完成操作,并保存操作中更改的信息

辅助流程1(替代流程)

选择以显示的方式进行操作

1) 显示用户的注册信息

辅助流程2(替代流程)

选择以修改的方式进行操作

1) 显示用户的可修改的信息

2) 对信息进行修改

3) 显示修改的项目信息,对修改进行确认

辅助流程3(替代流程)

选择以删除的方式进行操作

1) 对删除进行确认

辅助流程4(替代流程)

选择以搜索的方式进行操作

1) 显示搜索页面

2) 填写需要搜索的关键字

3) 选择搜索方式(按名字,按注册日期,等)

4) 显示搜索后的内容

2.4.5用例规约Products Management

表2.4-5. 用例规约Products Management

主要参与者

管理员

前置条件

以管理员身份登陆,并按下管理按钮。。

后置条件(成功后的保证)

返回管理后台首页

基本流程(主要成功场景)

1) 显示商品分类

2) 添加、修改、删除商品(添加软件程序、点卡激活码等)

1、 商品查询

2、 库存管理

3、 商品批量修改

4、 商品评论浏览

5、 完成操作,并保存操作中更改的信息

辅助流程1(替代流程)

选择以显示的方式进行操作

1、显示商品分类

辅助流程2(替代流程)

选择以修改的方式进行操作

1、 商品的可修改的信息

2、进行修改

3、显示修改的项目信息,对修改进行确认

辅助流程3(替代流程)

选择以添加、删除的方式进行操作

1、 添加商品,并确认

2、 删除商品,并确认

辅助流程4(替代流程)

选择以搜索的方式进行操作

1、显示搜索页面

2、填写需要搜索的关键字

3、选择搜索方式(按商品名称,按修改日期,等)

4、显示搜索后的内容

2.4.6用例规约Order Management

表2.4-6. 用例规约Order Management

主要参与者

用户或管理员

前置条件

用户或管理员已经登陆

后置条件(成功后的保证)

返回管理后台首页

基本流程(主要成功场景)

1、检查以何种身份登陆

2、进入所属权限的订单管理页面

3、对订单进行管理操作

4、保存管理操作的结果

5、返回订单管理页面

辅助流程1(替代流程)

用户对已完成购买的订单进行历史记录查看

1、显示已完成购买的订单

辅助流程2(替代流程)

用户对未完成购买的订单进行记录查看

1、显示未完成购买的订单

辅助流程3(替代流程)

用户对未完成购买的订单进行记录删除

1、删除未完成购买的订单

2、对删除进行确认

辅助流程4(替代流程)

管理员对已经销售的订单进行历史记录查看

1、显示已完成销售的订单

辅助流程5(替代流程)

管理员对未完成销售的订单进行操作记录查看

1、显示未完成销售的订单

2、进入管理员人工销售操作页面

辅助流程6(替代流程)

管理员对未完成销售的订单进行人工销售操作

1、人工完成未完成销售的订单,订单确认

2、订单转到已经销售部分

2.5 补充文档

2.5.1 补充规约:支付接口的选择

由于支付宝接口在10月20日起对所有支付宝接口实施包年套餐的租借方式,严重影响项目的开发和调试,所以系统再Payment处增加一个对应中国贝宝(PAYPAL)的支付接口,使用户可以自由选择付款接口,对应的用例规约如下表2.5-1:

表2.5-1. 补充用例规约:支付接口的选择

主要参与者

用户或游客

前置条件

用户或游客已经把商品加入到购物车,并按下结算按钮

后置条件(成功后的保证)

返回商品结算清单及所需费用

基本流程(主要成功场景)

1、用户按下结算按钮

2、系统显示购物列表及总价

3、用户选择支付接口(PAYPAL中国或支付宝)

辅助流程1(替代流程)

用户选择PAYPAL:

1、系统把定单提交到PAYPAL.COM.CN接口。

辅助流程2(替代流程)

用户选择支付宝:

1、系统把定单提交到ALIPAY.COM接口。

3 分析与设计

3.1 架构分析

本系统使用B/S架构,以三层架构组成,由上到下分别是:界面层、业务流程层、数据库层。系统架构分层如图3-1。

wps_clip_image-14014

图3-1 系统架构分层图

3.1.1 界面层

界面层向客户或系统管理员展示系统前台及后台操作界面,它集成的界面有:系统前/后台登陆界面、购物车、系统管理界面、在线支付结果界面等。

3.1.2 业务逻辑层

业务流程中与用户提交信息相关的服务在这一层中被定义。界面层的用户信息通过业务逻辑层访问数据库,对所指定的业务进行查询、增加、修改和删除等操作。

3.1.3 数据库层

数据库层由业务逻辑层访问,并返回结果到界面层。

3.2 关键抽象

本系统的关键抽象包括客户类、管理员类、提交信息类、界面类、结算类和数据库类,如图3-2所示。

wps_clip_image-8202

图3-2. 关键抽象

3.3 用例实现

3.3.1 客户购买商品的用例实现

客户购买商品的用例中包括客户类(User)、界面类(UI)、信息提交类(File Offering)、数据库类(Database)、结算接口类(Alipay.com: Payment),用顺序图表示出来,如图3-3所示:

wps_clip_image-23826

图3-3 客户购买商品的用例实现顺序图

对应的协作图如图3-4所示:

wps_clip_image-14755

图3-4 客户购买商品的用例实现协作图

3.3.2 管理员操作的用例实现

管理员操作的用例中包括管理员类(Admin)、界面类(UI)、信息提交类(File Offering)、数据库类(Database),用顺序图表示出来,如图3-5所示:

wps_clip_image-11684

图3-5 管理员操作的用例实现顺序图

对应的协作图如图3-6所示:

wps_clip_image-9846

图3-6 管理员操作的用例实现协作图

4 用例分析

4.1 分析类

分析类包括:

1) 界面类:管理员类、用户类、界面类。

2) 控制类:提交信息制类。

3) 实体类:数据库类、支付接口类。

4.2 分析类的功能

4.2.1 管理员类

职能:login();update_profile()。

属性:WebManager;UI。

4.2.2 用户类

职能:login();update_profile();AddtoCart()。

属性:WebManager;UI;CartDetail。

4.2.3提交信息制类

职能:count_totalprice();user_management();order_management();products_management();download()。

属性:SubmitInfo;UI。

4.2.4 数据库类

职能:alipay_service();verify_result()。

属性:userId;OrderId;OrderDetail。

4.2.5支付接口类

职能:return_url()。

属性:OrderNumber;OrderStatus;Date。

4.3 类图及类之间的关联

根据关键抽象及类的功能,得出类之间的联系如图4-1:

wps_clip_image-10160

图4-1 系统类图

4.4 数据库设计

4.4.1 Admin Table

Table Name

admin

Field Name

Field Type

Size

Not Null

Default

Value

Extra

Description

admin_id

INT

11

Not Null

auto_increment

PRIMARY KEY

admin_email_address

VARCHAR

96

Not Null

Login name for admin login page.

admin_password

VARCHAR

40

Not Null

permission

tinyint

1

NULL

1 for admin

admin_logdate

datetime

Last login date & time.

4.4.2 User Table

Table Name

customers

Field Name

Field Type

Size

Not Null

Default

Value

Extra

Description

customers_id

INT

11

Not Null

auto_increment

PRIMARY KEY

customers_email_address

VARCHAR

96

Not Null

Login name for UI

customers_telephone

VARCHAR

32

Not Null

customers_password

VARCHAR

40

Not Null

customers _logdate

datetime

Last login date & time.

4.4.3 Shopping Cart Table

Table Name

customers_basket

Field Name

Field Type

Size

Not Null

Default

Value

Extra

Description

customers_basket_id

INT

11

Not Null

auto_increment

PRIMARY KEY

customers_id

INT

11

Not Null

0

products_id

INT

11

Not Null

0

customers_basket_quantity

INT

3

Not Null

0

products quantity

final_price

decimal

10,2

Not Null

0.00

customers_basket_date_added

VARCHAR

8

4.4.4 Categories Table

Table Name

categories

Field Name

Field Type

Size

Not Null

Default

Value

Extra

Description

categories_id

INT

11

Not Null

auto_increment

PRIMARY KEY

categories_name

VARCHAR

32

Not Null

categories_image

VARCHAR

64

商品分类图片

parent_id

INT

11

Not Null

0

上级商品目录ID

sort_order

INT

3

4.4.5 Manufacturers Table

Table Name

manufacturers

Field Name

Field Type

Size

Not Null

Default

Value

Extra

Description

manufacturers_id

INT

11

Not Null

auto_increment

PRIMARY KEY

manufacturers_name

VARCHAR

32

Not Null

manufacturers_url

VARCHAR

255

Not Null

manufacturers_image

VARCHAR

64

4.4.6 Orders Table

Table Name

orders

Field Name

Field Type

Size

Not Null

Default

Value

Extra

Description

orders_id

INT

11

Not Null

auto_increment

PRIMARY KEY

customers_id

INT

11

Not Null

0

payment_method

VARCHAR

32

Not Null

last_modified

datetime

date_purchased

datetime

orders_status

INT

5

Not Null

0

orders_date_finished

datetime

4.4.7 Orders Detail Table

Table Name

orders_products

Field Name

Field Type

Size

Not Null

Default

Value

Extra

Description

orders_products_id

INT

11

Not Null

auto_increment

PRIMARY KEY

orders_id

INT

11

Not Null

0

products_id

INT

11

Not Null

0

final_price

decimal

10,2

Not Null

0.00

products_quantity

INT

3

Not Null

0

4.4.8 Orders Products Download Table

Table Name

orders_products_download

Field Name

Field Type

Size

Not Null

Default

Value

Extra

Description

orders_products_download_id

INT

11

Not Null

auto_increment

PRIMARY KEY

orders_id

INT

11

Not Null

0

orders_products_id

INT

11

Not Null

0

orders_products_filename

VARCHAR

255

Not Null

0

URL for download products

download_maxdays

INT

2

Not Null

0

download_count

INT

2

Not Null

0

4.4.9 Products Table

Table Name

products

Field Name

Field Type

Size

Not Null

Default

Value

Extra

Description

products_id

INT

11

Not Null

auto_increment

PRIMARY KEY

products_name

VARCHAR

64

Not Null

products_description

TEXT

products_quantity

INT

4

Not Null

0

库存数量

products_image_small

VARCHAR

64

产品小图片

products_image_large

VARCHAR

64

产品大图片

products_filename_download

VARCHAR

255

Not Null

0

same as orders_products_filename

products_price

decimal

10,2

Not Null

0.00

products_status

tinyint

1

Not Null

0

manufacturers_id

INT

11

categories_id

INT

11

4.4.10 Products in Categories Table

Table Name

products_to_categories

Field Name

Field Type

Size

Not Null

Default

Value

Extra

Description

products_id

INT

11

Not Null

0

PRIMARY KEY

categories_id

INT

11

Not Null

0

PRIMARY KEY

*此表作用是可使一个商品从属于多个不同分类。

4.4.11 数据库结构及各表间的关系

数据库结构及各表间的关系如图4-2:

wps_clip_image-25182

图4-2 数据库结构图

货物管理系统uml模型

货物管理系统

一、 需求分析

1.1系统开发的目的:

随着计算机技术特别是网络技术的飞速发展,计算机的应用领域不断扩大,各行各业都离不开计算机,货物管理也不例外,使之能跟上时代的发展。本需求分析报告的目的是规范化本软件的编写,旨在于提高软件开发过程中的能见度,便于对软件开发过程中的控制与管理,同时提出了货物管理系统的软件开发过程,便于程序员与客户之间的交流、协作,并作为工作成果的原始依据,同时也表明了本软件的共性,以期能够获得更大范围的应用。

1.2应用范围:

理论上能够实现于超市、仓库等部门的货物管理系统,其目的在于实现超市、仓库等部门的货物更有效的管理,使超市、仓库货物能够更方便、更有效率的完成日常工作,以期实现完善日常生活中货物管理的各种功能。

1.3系统功能需求

系统主要包括以下几个页面:

(1)管理员登录页面

(2)管理员添加删除货物页面

(3)货物标题信息页面

(4)货物信息查询页面

(5)货物信息显示页面

二、 用例图

用例图如图2-1所示

主要参与者:管理员、销售员

主要用例:登录、货物信息、标题信息、查询货物信息

wps_clip_image-14004

图2-1货物管理用例图

三、 类图

类图如图2-2所示

主要类:管理员、货物、标题、销售员、销售信息

wps_clip_image-29568

图2-2货物管理类图

四、 活动图

活动图如图2-3所示

wps_clip_image-3909

图2-3货物管理活动图

五、 顺序图

顺序图如图2-4所示

销售员通过发送一个通知货物消息通知管理员已经没有货物或者货物已经售出,管理员接受这个消息,进行增加和删除货物信息,然后对货物进行更新,更新完返回给销售员,告诉他已经更新完成

wps_clip_image-10604

图2-4货物管理顺序图

六、 协作图

顺序图如图2-5所示

销售员通过发送一个通知货物消息通知管理员已经没有货物或者货物已经售出,管理员接受这个消息,进行增加和删除货物信息,然后对货物进行更新,更新完返回给销售员,告诉他已经更新完成

wps_clip_image-9922

图2-5货物管理协作图

七、 状态图

状态图如图2-6所示

wps_clip_image-20178

图2-6货物管理状态图

八、 组件图

组件图如图2-7所示

wps_clip_image-11291

图2-7货物管理组件图

九、 部署图

部署图如图2-8示

wps_clip_image-12992

图2-8物管理部署图

十、 实验总结

面向对象开发作为一种新兴的软件开发方法,正在逐渐取代传统方法,日益成为当前软件工程领域的主流方法。通过本次对“货物管理系统”的课程设计实验,理解了UML的8种不同的图:

一、 静态图:用例图、类图、组件图和部署图

二、 动态图:顺序图、协作图、状态图和活动图

UML 序列图

来自: IBM Rational Edge

wps_clip_image-7979[3][1]

现在是二月,而且到如今你或许已经读到、或听到人们谈论UML 2.0 —— 包括若干进步的 UML 的新规范,所做的变化。考虑到新规范的重要性,我们也正在修改这个文章系列的基础,把我们的注意力从 OMG 的 UML 1.4 规范,转移到 OMG 的已采纳 UML 2.0草案规范(又名 UML 2)。我不喜欢在一系列文章的中间,把重点从 1.4 变为 2.0 ,但是 UML 2.0 草案规范是前进的重要一步,我感觉需要扩充文字。

由于一些理由,OMG 改良了 UML 。主要的理由是,他们希望 UML 模型能够表达模型驱动架构(MDA),这意味着 UML 必须支持更多的模型驱动的符号。同时, UML 1.x 符号集合有时难以适用于较大的应用程序。此外,为了要使图变成更容易阅读,需要改良符号元件。(举例来说,UML 1.x 的模型逻辑流程太复杂,有时不可能完成。对UML 2 中的序列图的符号集合的改变,已经在序列化逻辑建模方面取得巨大的进步)。

注意我上面所述的文字:“已采纳UML2.0草案规范。”确实,规范仍然处于草案状态,但是关键是草案规范已经被 OMG 采用,OMG是一个直到新标准相当可靠,才会采用它们的组织。 在 UML 2 完全地被采用之前,规范将会有一些修改,但是这些改变应该是极小的。主要的改变将会是在 UML 的内部 —— 包括通常被实施 UML 工具的软件公司使用的功能。

本文的主要目的是继续把我们的重点放在基础UML图上;这个月,我们进一步了解序列图。再次请注意,下面提供的例子正是以新的 UML 2 规范为基础。

图的目的
序列图主要用于按照交互发生的一系列顺序,显示对象之间的这些交互。很象类图,开发者一般认为序列图只对他们有意义。然而,一个组织的业务人员会发现,序列图显示不同的业务对象如何交互,对于交流当前业务如何进行很有用。除记录组织的当前事件外,一个业务级的序列图能被当作一个需求文件使用,为实现一个未来系统传递需求。在项目的需求阶段,分析师能通过提供一个更加正式层次的表达,把用例带入下一层次。那种情况下,用例常常被细化为一个或者更多的序列图。

组织的技术人员能发现,序列图在记录一个未来系统的行为应该如何表现中,非常有用。在设计阶段,架构师和开发者能使用图,挖掘出系统对象间的交互,这样充实整个系统设计。

序列图的主要用途之一,是把用例表达的需求,转化为进一步、更加正式层次的精细表达。用例常常被细化为一个或者更多的序列图。序列图除了在设计新系统方面的用途外,它们还能用来记录一个存在系统(称它为“遗产”)的对象现在如何交互。当把这个系统移交给另一个人或组织时,这个文档很有用。

符号
既然这是我基于 UML 2的 UML 图系列文章的第一篇,我们需要首先讨论对 UML 2 图符号的一个补充,即一个叫做框架的符号元件。在 UML 2中,框架元件用于作为许多其他的图元件的一个基础,但是大多数人第一次接触框架元件的情况,是作为图的图形化边界。当为图提供图形化边界时,一个框架元件为图的标签提供一致的位置。在 UML 图中框架元件是可选择的;就如你能在图 1 和 2 中见到的,图的标签被放在左上角,在我将调用框架的“namebox”中,一种卷角长方形,而且实际的 UML 图在较大的封闭长方形内部定义。

wps_clip_image-23398[3][1]

图 1: 空的 UML 2 框架元件

除了提供一个图形化边框之外,用于图中的框架元件也有描述交互的重要的功能, 例如序列图。在序列图上一个序列接收和发送消息(又称交互),能通过连接消息和框架元件边界,建立模型(如图 2 所见到)。这将会在后面“超越基础”的段落中被更详细地介绍。

wps_clip_image-9121[4][1]

图 2: 一个接收和发送消息的序列图

注意在图 2 中,对于序列图,图的标签由文字“sd”开始。当使用一个框架元件封闭一个图时,图的标签需要按照以下的格式:

图类型 图名称

UML 规范给图类型提供特定的文本值。(举例来说,sd代表序列图,activity代表活动图,use case代表用例图)。

基础
序列图的主要目的是定义事件序列,产生一些希望的输出。重点不是消息本身,而是消息产生的顺序;不过,大多数序列图会表示一个系统的对象之间传递的什么消息,以及它们发生的顺序。图按照水平和垂直的维度传递信息:垂直维度从上而下表示消息/调用发生的时间序列,而且水平维度从左到右表示消息发送到的对象实例。

生命线
当画一个序列图的时候,放置生命线符号元件,横跨图的顶部。生命线表示序列中,建模的角色或对象实例。 1 生命线画作一个方格,一条虚线从上而下,通过底部边界的中心(图 3)。生命线名字放置在方格里。

wps_clip_image-14430[3][1]

图 3: 用于一个实体名为freshman的生命线的Student类的一个例子

UML 的生命线命名标准按照如下格式:

实体名 : 类名

在如图3所示的例子中,生命线表示类Student的实体,它的实体名称是freshman。这里注意一点,生命线名称带下划线。当使用下划线时,意味着序列图中的生命线代表一个类的特定实体,不是特定种类的实体(例如,角色)。在将来的一篇文章中,我们将会了解结构化建模。现在,仅仅评述序列图,可能包含角色(例如买方和卖方),而不需要叙述谁扮演那些角色(例如Bill和Fred)。这准许不同语境的图重复使用。简单拖放,序列图的实例名称有下划线,而角色名称没有。

图 3 中我们生命线例子是一个命名的对象,但是不是所有的生命线都代表命名的对象。相反的,一个生命线能用来表现一个匿名的或未命名的实体。当在一个序列图上,为一个未命名的实例建模时,生命线的名字采用和一个命名实例相同的模式;但是生命线名字的位置留下空白,而不是提供一个例图名字。再次参考图 3,如果生命线正在表现Student类的一个匿名例图,生命线会是: “Student”。同时, 因为序列图在项目设计阶段中使用,有一个未指定的对象是完全合法: 举例来说,“freshman”。

消息
为了可读性,序列图的第一个消息总是从顶端开始,并且一般位于图的左边。然后继发的消息加入图中,稍微比前面的消息低些。

为了显示一个对象(例如,生命线)传递一个消息给另外一个对象,你画一条线指向接收对象,包括一个实心箭头(如果是一个同步调用操作)或一个棍形箭头(如果是一个异步讯号)。消息/方法名字放置在带箭头的线上面。正在被传递给接收对象的消息,表示接收对象的类实现的一个操作/方法。在图 4 的例子中,analyst对象调用ReportingSystem 类的一个实例的系统对象。analyst对象在调用系统对象的 getAvailableReports 方法。系统对象然后调用secSystem 对象上的、包括参数userId的getSecurityClearance 方法,secSystem的类的类型是 SecuritySystem。 2

wps_clip_image-17740[4][1]

图 4: 一个在对象之间传递消息的实例

除了仅仅显示序列图上的消息调用外,图 4 中的图还包括返回消息。这些返回消息是可选择的;一个返回消息画作一个带开放箭头的虚线,向后指向来源的生命线,在这条虚线上面,你放置操作的返回值。在图 4 中,当 getSecurityClearance 方法被调用时,secSystem 对象返回 userClearance 给系统对象。当 getAvailableReports 方法被调用时,系统对象返回 availableReports。

此外,返回消息是序列图的一个可选择部分。返回消息的使用依赖建模的具体/抽象程度。如果需要较好的具体化,返回消息是有用的;否则,主动消息就足够了。我个人喜欢,无论什么时候返回一个值,都包括一个返回消息,因为我发现额外的细节使一个序列图变得更容易阅读。

当序列图建模时,有时候,一个对象将会需要传递一个消息给它本身。一个对象何时称它本身?一个纯化论者会争辩一个对象应该永不传递一个消息给它本身。然而,为传递一个消息给它本身的对象建模,在一些情境中可能是有用的。举例来说,图 5 是图 4 的一个改良版本。 图 5 版本显示调用它的 determineAvailableReports 方法的系统对象。通过表示系统传递消息“determineAvailableReports”给它本身,模型把注意力集中到过程的事实上,而不是系统对象。

为了要画一个调用本身的对象,如你平时所作的,画一条消息,但是不是连接它到另外的一个对象,而是你把消息连接回对象本身。

wps_clip_image-17090[4][1]

图 5: 系统对象调用它的 determineAvailableReports 方法

图 5 中的消息实例显示同步消息;然而,在序列图中,你也能为异步消息建模。一个异步消息和一个同步的画法类似,但是消息画的线带一个棍形矛头,如图 6 所示。

wps_clip_image-3219[3][1]

图 6: 表示传递到实体2的异步消息的序列图片段

约束
当为对象的交互建模时,有时候,必须满足一个条件,消息才会传递给对象。约束在 UML 图各处中,用于控制流。在这里,我将会讨论UML 1.x 及UML 2.0两者的约束。在 UML 1.x 中,一个约束只可能被分配到一个单一消息。UML 1.x中,为了在一个序列图上画一个约束,你把约束元件放在约束的消息线上,消息名字之前。图 7 显示序列图的一个片段,消息addStudent 方法上有一个约束。

wps_clip_image-7094[4][1]

图 7:UML 1.x 序列图的一个片段,其中addStudent 消息有一个约束

在图 7 中,约束是文本“[ pastDueBalance=0]”。通过这个消息上的约束,如果应收帐系统返回一个零点的逾期平衡,addStudent 消息才将会被传递。约束的符号很简单;格式是:

[Boolean Test]

举例来说,

[pastDueBalance = 0]

组合碎片(变体方案,选择项,和循环)
然而,在大多数的序列图中,UML 1.x“in-line”约束不足以处理一个建模序列的必需逻辑。这个功能缺失是 UML 1.x 的一个问题。UML 2 已经通过去掉“in-line”约束,增加一个叫做组合碎片的符号元件,解决了这一个问题。一个组合碎片用来把一套消息组合在一起,在一个序列图中显示条件分支。UML 2 规范指明了组合碎片的 11 种交互类型。十一种中的三种将会在“基础”段落中介绍,另外两种类型将会在“超越基础”中介绍,而那剩余的六种我将会留在另一篇文章中介绍。(嗨,这是一篇文章而不是一本书。我希望你在一天中看完这部分!)

变体
变体用来指明在两个或更多的消息序列之间的、互斥的选择。 3 变体支持经典的“if then else”逻辑的建模(举例来说,如果 我买三个,然后 我得到 我购买的20% 折扣;否则 我得到我购买的 10% 折扣)。

就如你将会在图 8 中注意到的,一个变体的组合碎片元件使用框架来画。单词“alt”放置在框架的namebox里。然后较大的长方形分为 UML 2 所称的操作元。 4 操作元被虚线分开。每个操作元有一个约束进行测试,而这个约束被放置在生命线顶端的操作元的左上部。 5 如果操作元的约束等于“true”,然后那个操作元是要执行的操作元。

wps_clip_image-20215[4][1]

图 8:包含变体组合碎片的一个序列图片段

图 8作为一个变体的组合碎片如何阅读的例子,显示序列从顶部开始,即bank对象获取支票金额和帐户结余。此时,序列图中的变体组合碎片接管。因为约束“[balance >= amount]”,如果余额超过或等于金额,然后顺序进行bank对象传递 addDebitTransaction 和 storePhotoOfCheck 消息给account对象。然而,如果余额不是超过或等于金额,然后顺序的过程就是bank传递addInsuffientFundFee 和 noteReturnedCheck 消息给account对象,returnCheck 消息给它自身。因为“else”约束,当余额不大于或者等于金额时,第二个序列被调用。在变体的组合碎片中,不需要“else”约束;而如果一个操作元,在它上面没有一个明确的约束,那么将假定“else”约束。

变体的组合碎片没被限制在简单的“if then else”验证。可能需要大量的变体路径。 如果需要较多的变体方案,你一定要做的全部工作就是把一个操作元加入有序列约束和消息的长方形中。

选择项
选择项组合碎片用来为序列建模,这些序列给予一个特定条件,将会发生的;或者,序列不发生。一个选择项用来为简单的“if then”表达式建模。(例如,如果架上的圈饼少于五个,那么另外做两打圈饼)。

选择项组合碎片符号与变体组合碎片类似,除了它只有一个操作元并且永不能有“else”约束以外(它就是如此,没有理由)。要画选择项组合,你画一个框架。文字“opt”是被放置在框架的 namebox 里的文本,在框架的内容区,选择项的约束被放置在生命线顶端上的左上角。 然后选择项的消息序列被放在框架的内容区的其余位置内。这些元件如图 9 所示。

wps_clip_image-24546[4][1]

图 9:包括选择项组合碎片的一个序列图片段

阅读选择项组合碎片很容易。图 9 是图 7 的序列图片段的再加工,但是这次它使用一个选择项组合碎片,因为如果Student的逾期平衡等于0,需要传递更多的消息。按照图 9 的序列图,如果Student的逾期平衡等于零,然后传递addStudent,getCostOfClass和chargeForClass消息H绻鸖tudent的逾期平衡不等于零,那么在选择项组合碎片中,序列不传递任何一个消息。

例子图 9的序列图片段包括一个选择项约束;然而,约束不是一个必需的元件。在高层次、抽象的序列图中,你可能不想叙述选择项的条件。你可能只是想要指出片段是可选择的。

循环
有时候你将会需要为一个重复的序列建模。在 UML 2 中,为一个重复的序列建模已经改良,附加了循环组合碎片。

循环组合碎片表面非常类似选择项组合碎片。你画一个框架,在框架的 namebox 中放置文本“loop”。在框架的内容区中,一个生命线的顶部,循环约束 6 被放置在左上角。然后循环的消息序列被放在框架内容区的其余部分中。在一个循环中,除了标准的布尔测试外,一个约束能测试二个特定的条件式。特定的约束条件式是写作“minint = [the number]”(例如,“minint = 1”)的最小循环次数,和写作“maxint = [the number]”(例如,“maxint = 5”)的最大循环次数。通过最小循环检验,循环必须运行至少指定次数,而循环执行次数不能达到约束指定的最大循环次数。

wps_clip_image-1800[4][1]

图 10:循环组合碎片的一个序列图例子 (单击放大)

在图 10 中显示的循环运行,直到 reportsEnu 对象的 hasAnotherReport 消息返回false。如果循环序列应该运行,这个序列图的循环使用一个布尔测试确认。为了阅读这个图,你和平常一样,从顶部开始。当你到达循环组合碎片,做一个测试,看看值 hasAnotherReport 是否等于true。如果 hasAnotherReport 值等于true,于是序列进入循环片断。然后你能和正常情况一样,在序列图中跟踪循环的消息。

超越基础

我已经介绍了序列图的基础,应该使你可以为将会在系统中通常发生的大部份交互建模。下面段落将会介绍用于序列图的比较高阶的符号元件。

引用另外一个序列图
当做序列图的时候,开发者爱在他们的序列图中,重用存在的序列图。 7 在 UML 2 中开始,引进“交互进行”元件。追加交互进行的可以说是 UML 2 交互建模中的最重要的创新。交互进行增加了功能,把原始的序列图组织成为复杂的序列图。由于这些,你能组合(重用)较简单的序列,生成比较复杂的序列。这意味你能把完整的、可能比较复杂的序列,抽象为一个单一的概念单位。

一个交互进行元件使用一个框架绘制。文字“ref”放置在框架的 namebox 中,引用的序列图名字放置在框架的内容区里,连同序列图的任何参数一起。引用序列图的名字符号如下模式:

序列图名[(参数)] [: 返回值]

两个例子:

1. Retrieve Borrower Credit Report(ssn) : borrowerCreditReport

或者

2. Process Credit Card(name, number, expirationDate, amount : 100)

在例子 1 中,语法调用叫做Retrieve Borrower Credit Report的序列图,传递给它参数 ssn。序列Retreive Borrower Credit Report返回变量 borrowerCreditReport 。

在实例 2 中,语法调用叫做Process Credit Card的序列图,传递给它参数name,number,expiration date,和 amount。然而,在例子 2 中,amount参数将会是值100。因为例子2没有返回值标签,序列不返回值(假设,建模的序列不需要返回值)。

wps_clip_image-13841[4][1]

图 11: 一个引用两个不同序列图的序列图

图 11 显示一个序列图,它引用了序列图“Balance Lookup”和“Debit Account”。序列从左上角开始,客户传递一个消息给teller对象。teller对象传递一个消息给 theirBank 对象。那时,调用Balance Lookup序列图,而 accountNumber作为一个参数传递。Balance Lookup序列图返回balance变量。然后检验选择项组合碎片的约束条件,确认余额大于金额变量。在余额比金额更大的情况下,调用Debit Account序列图,给它传递参数accountNumber 和amount。在那个序列完成后,withdrawCash 消息为客户返回cash。

重要的是,注意在图 11 中,theirBank 的生命线被交互进行Balance Lookup隐藏了。因为交互进行隐藏生命线,意味着theirBank 生命线在“Balance Lookup”序列图中被引用。除了隐藏交互进行的生命线之外,UML 2 也指明,生命线在它自己的“Balance Lookup”序列中,一定有相同的 theirBank 。

有时候,你为一个序列图建模,其中交互进行会重叠没有 在交互进行中引用的生命线。在那种情况下,生命线和正常的生命线一样显示,不会被重叠的交互进行隐藏。

在图 11 中,序列引用“Balance Lookup”序列图。“Balance Lookup”序列图在图 12 中显示。因为例子序列有参数和一个返回值,它的标签 —— 位于图的 namebox 中 —— 按照一个特定模式:

图类型 图名 [参数类型:参数名]

[: 返回值类型]

两个例子:

1. SD Balance Lookup(Integer : accountNumber) : Real

2. SD Available Reports(Financial Analyst : analyst) : Reports

图 12 举例说明例子 1,在里面,Balance Lookup序列把参数 accountNumber 作为序列中的变量使用,序列图显示返回的Real对象。在类似这种情况下,返回的对象采用序列图实体名。

wps_clip_image-25844[4][1]

图 12: 一个使用 accountNumber 参数并返回一个Real对象的序列图

图 13 举例说明例子 2,在里面,一个序列图获取一个参数,返回一个对象。然而,在图 13 中参数在序列的交互中使用。

wps_clip_image-26627[4][1]

图 13: 一个在它的交互中使用参数、返回一个Reports对象的序列图


前面的段落展示如何通过参数和返回值传递信息,引用另一个序列图。然而,有另一个方法在序列图之间传递消息。门可能是一个容易的方法,为在序列图和它的上下文之间的传递消息建模。一个门只是一个消息,图形表示为一端连接序列图的框架边缘,另一端连接到生命线。使用门的图 11 和 12 ,在图 14 和 15 中可以被看到重构。图 15 的例图有一个叫做getBalance的入口门,获取参数 accountNumber。因为是箭头的线连接到图的框架,而箭头连接到生命线,所以 getBalance 消息是一个入口门。序列图也有一个出囗门,返回balance变量。出口门同理可知,因为它是一个返回消息,连接从一个生命线到图的框架,箭头连接框架。

wps_clip_image-9373[4][1]

图 14: 图 11 的重构,这次使用门

wps_clip_image-32427[4][1]

图 15: 图 12 的重构,这次使用门

组合碎片(跳转和并行)
在本文前面“基础”的段落中呈现的,我介绍了“变体”,“选择项”,和“循环”的组合碎片。这些三个组合碎片是大多数人将会使用最多的。然而,有二个其他的组合碎片,大量共享的人将会发现有用——跳转和并行。

跳转
跳转组合碎片几乎在每个方面都和选择项组合碎片一致,除了两个例外。首先,跳转的框架namebox的文本“break”代替了“option”。其次, 当一个跳转组合碎片的消息运行时,封闭的交互作用的其他消息将不会执行,因为序列打破了封闭的交互。这样,跳转组合碎片非常象 C++ 或 Java 的编程语言中的break关键字。

wps_clip_image-23901[4][1]

图 16: 来自图 8 的序列图片段的重构,片段使用跳转代替变体

跳转最常用来做模型异常处理。图 16 是图 8 的重构,但是这次图16使用跳转组合碎片,因为它把balance < amount的情况作为一个异常对待,而不是一个变体流。要阅读图 16,你从序列的左上角开始,向下读。当序列到达返回值“balance”的时候,它检查看看是否余额比金额更少。如果余额不少于金额,被传递的下一个消息是 addDebitTransaction 消息,而且序列正常继续。然而,在余额比金额更少的情况下,然后序列进入跳转组合碎片,它的消息被传递。一旦跳转组合的消息的已经被传递,序列不发送任何其它消息就退出(举例来说,addDebitTransaction)。

注意有关跳转的一件重要的事是,它们只引起一个封闭交互的序列退出,不必完成图中描述的序列。在这种情况下,跳转组合是变体或者循环的一部分,然后只是变体或循环被退出。

并行
今天的现代计算机系统在复杂性和有时执行并发任务方面不断进步。当完成一个复杂任务需要的处理时间比希望的长的时候,一些系统采用并行处理进程的各部分。当创造一个序列图,显示并行处理活动的时候,需要使用并行组合碎片元件。

并行组合碎片使用一个框架来画,你把文本“par”放在框架的 namebox 中。然后你把框架的内容段用虚线分为水平操作元。框架的每个操作元表示一个在并行运行的线程。

wps_clip_image-25959[4][1]

图 17: oven 是并行做两个任务的对象实例

图 17 可能没有举例说明做并行活动的对象的最好的计算机系统实例,不过提供了一个容易理解的并行活动序列的例子。序列如这样进行:hungryPerson 传递 cookFood 消息给oven 对象。当oven 对象接收那个消息时,它同时发送两个消息(nukeFood 和 rotateFood)给它本身。这些消息都处理后,hungryPerson 对象从oven 对象返回 yummyFood 。

总结
序列图是一个用来记录系统需求,和整理系统设计的好图。序列图是如此好用的理由是,因为它按照交互发生的时间顺序,显示了系统中对象间的交互逻辑。

参考

· UML 2.0 Superstructure Final Adopted Specification (第8章部分) http://www.omg.org/cgi-bin/doc?ptc/2003-08-02

· UML 2 Sequence Diagram Overview http://www.agilemodeling.com/artifacts/sequenceDiagram.htm

· UML 2 Tutorial http://www.omg.org/news/meetings/workshops/UML%202003%20Manual/Tutorial7-Hogg.pdf

脚注
1 在完全建模系统中,对象(类的实例)也将会在系统的类图中建模。

2 当阅读这个序列图时,假定分析师登录进入系统之内。

3 请注意,附着在不同的变体操作元上的、两个或更多的约束条件式的确可能同时是真,但是实际最多只有一个操作元将会在运行时发生(那种情况下变体的“wins”没有按照 UML 标准定义)。

4 虽然操作元看起来非常象公路上的小路,但是我特别不叫它们小路。泳道是在活动图上使用的 UML 符号。请参考The Rational Edge 早期关于 活动图的文章。

5 通常,附上约束的生命线是拥有包含在约束表达式中的变量的生命线。

6 关于选择项组合碎片,循环组合碎片不需要在它上放置一个约束条件。

7 可能重用任何类型的序列图(举例来说,程序或业务)。我只是发现开发者更喜欢按功能分解他们的图。

参考资料

· 您可以参阅本文在 developerWorks 全球站点上的 英文原文。

关于作者
Donald Bell是IBM全球服务的一个IT专家,在那儿他和IBM的客户一起致力于设计和开发基于软件解决方案的J2EE。

http://www.cnblogs.com/wander/articles/415646.html

UML协作图编写规范

一、协作图简述

协作图是一种交互图(interaction diagram),强调的是发送和接收消息的对对象之间的组织结构。一个协作图显示了一系列的对象和在这些对象之间的联系以及对象间发送和接收的消息。对象通常是命名或匿名的类的实例,也可以代表其他事物的实例,例如协作、组件和节点。使用协作图来说明系统的动态情况。

协作图(Collaboration Diagram)显示某组对象如何为了由一个用例描述的一个系统事件而与另一组对象进行协作的交互图。使用协作图可以显示对象角色之间的关系,如为实现某个操作或达到某种结果而在对象间交换的一组消息。如果需要强调时间和序列,最好选择序列图;如果需要强调上下文相关,最好选择协作图。

协作图用于显示对象之间如何进行交互以执行特定用例或用例中特定部分的行为。设计员使用协作图和序列图确定并阐明对象的角色,这些对象执行用例的特定事件流。它们是主要的信息来源,用于确定类的职责和接口。

与序列图不同,协作图显示了对象之间的关系。序列图和协作图表述的是相似的信息,但表述的方式却不同。协作图显示对象之间的关系,它更有利于理解对给定对象的所有影响,也更适合过程设计。

协作图的格式决定了它们更适合在分析活动中使用(请参见活动:用例分析)。它们特别适合用来描述少量对象之间的简单交互。随着对象和消息数量的增多,理解 协作图将越来越困难。此外,协作图很难显示补充的说明性信息,例如时间、判定点或其他非结构化的信息,而在序列图中这些信息可以方便地添加到注释中。

协作图强调参与一个交互对象的组织,它由以下基本元素组成:活动者(Actor)、对象(Object)、连接(Link)和消息(Message)。在UML中,使用实线标记两个对象之间的连接,

协作图中的消息,由标记在连接上方的带有标记的箭头表示。协作图包含类元角色和关联角色,而不仅仅是类元和关联。类元角色和关联角色描述了对象的配置和当 一个协作的实例执行时可能出现的连接。当协作被实例化时,对象受限于类元角色,连接受限于关联角色。关联角色也可以被各种不同的临时连接所担当,例如过程 参量或局部过程变量。连接符号可以使用构造型表示临时连接(《parameter》或《local》)或调用同一个对象(《self》)。虽然整个系统中 可能有其他的对象,但只有涉及到协作的对象才会被表示出来。换而言之,协作图只对相互之间具有交互作用的对象和对象间的关联建模,而忽略了其他对象和关 联。

二、协作图的内容

协作图中可以有对象和主角实例,以及描述它们之间关系和交互的连接和消息。通过说明对象间如何通过互相发送消息来实现通信,协作图描述了参与对象中发生的情况。您可以为用例事件流的每一个变化形式制作一个协作图。如图2-1

wps_clip_image-4832[3][1]

图 2-1

描述回收机系统的接收储存项用例中部分事件流的协作图。

在协作图中,您可以按照以下方式使用对象:

1.可以不指定对象的类。通常先制作只带有对象的协作图,而后再指定它们的类。

2.可以给对象命名,但如果您要区分同一个类的不同对象,则应给对象命名。

3.如果对象的类主动参与了协作,则可以将类本身在协作图中表现出来。

三、协作图使用

协作图用于显示组件及其交互关系的空间组织结构,它并不侧重于交互的顺序。协作图显示了交互中各个对象之间的组织交互关系以及对象彼此之间的链接。与序列图不同,协作图显示的是对象之间的关系。另一方面,协作图没有将时间作为一个单独的维度,因此序列号就决定了消息及并发线程的顺序。协作图是一个介于符号图和序列图之间的交叉产物,它用带有编号的箭头来描述特定的方案,以显示在整个方案过程中消息的移动情况。

协作图具有以下用途:

1)、通过描绘对象之间消息的移动情况来反映具体的方案。

2)、显示对象及其交互关系的空间组织结构,而非交互的顺序。

3.1、创建协作图

3.1.1生成协作图

1)、启动 IDE(如果需要)。

2)、在“项目”窗口中,展开 "UMLTutorialProject" >“模型”节点。

3)、选择以下类节点:

u ATM

u Branch

u Consortium

注意:通过按住 Ctrl 键并单击每个类节点可以选择多个类。

4)、右键单击最后选定的类,然后从弹出式菜单中选择“通过选定的元素创建图”。将打开新建向导,其中显示“创建新图”页。

5)、在“图类型”列表中,选择“协作图”。

6)、在“图名称”字段中,键入 CollaborationDiagram。

7)、保留“名称空间”字段中的缺省设置,然后单击“完成”。
IDE 将执行以下操作:

在“项目”窗口的“模型”节点下创建 CollaborationDiagram 节点

在图编辑器中显示新图(该图由三个表示为生命线元素的类构成)

打开建模组件面板

3.1.2、完善生成的图

1)、单击并拖动元素以重新排列图,使其与下面的图3-1类似。

wps_clip_image-6600[3][1]

图 3-1

2)、在“项目”窗口中,选择标记为 User 的类节点。

3)、将选定的类拖放到图编辑器中,使其位于 ATM 生命线元素的上方,

如下图3-2所示。

wps_clip_image-15891[3][1]

图 3-2

3.2、添加连接器链接

协作图中的每个元素均可通过连接器链接与其他元素建立连接。您可以标识这些链接,并在其中添加消息流。

1)、从建模组件面板的“基本”类别中,选择 "Connector" 。

2)、单击标记为 User 的生命线元素,然后单击 ATM。
将在两个元素之间绘制一条连接器链接。

3)、使用相同的步骤绘制以下链接:

u 从 ATM 至 Consortium 的链接

u 从 Consortium 至 Branch 的链接

u 从 ATM 至 Branch 的链接

注意:在创建从 ATM 至 Branch 的链接时,请由 ATM 生命线向右水平拉出链接线,并在到达 Branch 生命线正上方时单击一下鼠标。这样便会在链接线上放置一个顶点,然后再垂直向下绘制链接以到达 Branch 生命线。

此时,协作图应当与下面的图3-3类似。
wps_clip_image-474[3][1]

图 3-3

4)、在图编辑器中的任意位置单击鼠标右键以取消选择 "Connector" 图标。

3.3、显示消息编号

协作图通过使用带有编号的消息来表示特定的方案。缺省情况下,UML 建模设置将隐藏这些编号。请使用以下步骤来显示消息号:

1)、在 CollaborationDiagram 图编辑器的背景中单击鼠标右键。

2)、从弹出式菜单中选择“显示消息号”。
这样当您插入操作流(在下一部分中介绍)时,便会显示消息号。

3.4、显示操作流

操作流在图中显示为与链接平行的带标记箭头。此链接用于向目标元素传输消息或实现这种传输。

1)、在图编辑器中,选择 User 和 ATM 之间的连接器链接。

2)、右键单击距 ATM 生命线最近的连接器链接部分。

3)、从弹出式菜单中选择“操作”> "public float getCashOnHand"。
将在图中放置一个编号为 1 的操作流。

注意:单击“适应窗口大小”按钮 wps_clip_image-20866[3][1]以在图编辑器中查看整个图。

4)、选择 ATM 和 Consortium 之间的连接器链接,然后右键单击靠近 Consortium 元素的链接部分。

5)、从弹出式菜单中选择“操作”> "public void validateAccountInfo"。
IDE 会在此链接上放置选定的操作,并将其编号为 1.1。

注意:您可以根据需要选择并移动操作流。

3.5、向类中添加操作

在此过程中,您将向连接器链接添加一个新的操作。该操作还会被添加到 ClassDiagram 图的 Branch 类以及 Java 源代码中。

1)、右键单击 Consortium 和 Branch 之间靠近 Branch 生命线元素的连接器链接。

2)、从弹出式菜单中选择“操作”>“添加操作”。
图中将出现一个标签,并突出显示 Unnamed 一词。

3)、键入 verifyCardWithBank。

4)、使用向右方向键将光标移至操作参数字段。

5)、键入 int stringCardStrip 作为参数,然后按 Enter 键。
该链接将被标记为 1.1.1: public void verifyCardWithBank( int stringCardStrip ),并且添加的操作会显示在 ClassDiagram 图的 Branch 类中。

6)、在 ATM 和 Branch 之间的连接器链接上,右键单击靠近 Branch 生命线的链接部分。

7)、从弹出式菜单中选择“操作”> "public char getConnected"。
该链接将被标记为 1.2: public char getConnected()。

完成的协作图应当与下面的图3-4类似。

wps_clip_image-19139[3][1]

图 3-4

3.6、保存图

完成协作图后,您可以保存该图。

1)、在图编辑器中,右键单击 "CollaborationDiagram" 标签。

2)、从弹出式菜单中选择“保存文档”。
将关闭菜单并保存图。

注意:退出 IDE 时,系统会提示您是否要保存项目。