03.状态图、活动图、时序图、协作图、组件图、部署图

状态图

状态图可以展现一个对象拥有的状态,还可以说明事件如何随着时间的推移来影响这些状态。例如:图书有借阅,在馆,报废等状态。

概念

下面几个概念需要掌握:
状态:状态是给定类的对象的一组属性值,这组属性值对所发生的事件具有相同性质的反应。

转换:转换是状态间的关联。当一个特定事件发生或者某些条件得到满足时,一个源状态下的对象在完成一定的动作后将发生状态转变,转向另一个称为目标状态的状态。一般状态之间的转移是由事件触发的。例如:再馆的图书由于读者借书事件触发转换为借阅状态。
转换不但能在两个状态之间发生,还可能在单个状态中发生。

事件:事件表示在某一特定的时间或空间出现的能够引发状态改变的运动变化。例如上面的借书就是一个事件。
在这里插入图片描述

实例-图书管理系统中图书状态图

图书借阅中图书的状态有:可借阅、已预约、已借阅、下架状态。(当然实际中还有更加复杂的状态,例如:遗失、破损、逾期等)
制作在不同事件下图书状态变化的状态图。
在这里插入图片描述

活动图

活动图可以用于描述系统的工作流程和并发行为,它用于展现参与行为的类所进行的各种活动的顺序关系。
活动图中活动的改变不需要事件触发,源活动执行完毕后自动触发转移,转到下一活动。
活动图中的组成元素主要有:动作状态(Activity State)、活动状态(Action State)、判定(Decisions)、转换(Transitions)、动作流(Action Flow)、分支(Branch)与合并(Merge)、分叉(Fork)与汇合(Join)、泳道(Swim Lane),以及对象流(Object Flow)。

动作状态(Activity State)

动作状态对象的动作状态是活动图的最小单位的构造块,是指执行原子的、不可中断的动作并在此动作完成后通过完成转换转向另一个状态的状态。
在这里插入图片描述

活动状态(Action State)

活动状态用于表达一个非原子的运行。对象的活动状态可以被理解成一个组合,它的控制流由其他活动状态或动作状态组成。
和动作状态不同,Rose的活动状态可以有入口动作和出口动作,也可以有内部转移。
PD里面不像rose有专门的活动状态图标,而是使用动作状态进行嵌套:
在这里插入图片描述

判定(Decisions)

一个活动序列几乎总是要到达某一点,在这一点处要做出判定。一组条件引发一条执行路径,另一组条件则引发另一条执行路径,并且这两组执行条件是互斥的。使用菱形来表示。
在这里插入图片描述

转换(Transitions)与动作流(Action Flow)

当一个动作状态或活动状态结束时,该状态就会转换到另外一个状态。这就是无触发转移称为自动转移。所有动作状态之间的转换流称为动作流。用实线和实心箭头表示。
在这里插入图片描述

分支(Branch)与合并(Merge)

分支实际上就是多种情况,和判定差不多,

在活动图中,对于同一个触发,可根据不同的触发条件转移到不同的活动,每个可能的转移就是是一个分支。分支一般用于表示对象类所具有的条件行为(和判定一样),合并表示从对应的分支开始的条件行为的结束。
例如:打开淘宝网站,分支:登录用户如何如何,未登录如何如何,最后合并,关闭网站。
PD中的分支(Branch)与合并(Merge)和 判定一样用菱形。
在这里插入图片描述

分叉(Fork)与汇合(Join)

分叉用于将动作流分为两个或者多个并发运行的分支,而汇合则用于同步这些并发分支,以达到共同完成一项事务的目的。
可见分叉与分支不同,分叉考虑的是并行完成任务,每个子任务都要执行,而分支只执行其中一个支线任务。
分叉与汇合使用粗横线表示。如果有需要可以在粗横线右键转化为垂直状态。
在这里插入图片描述

泳道(Swim Lane)

泳道是活动图中水平方向的区域划分,根据每个活动的职责对所有活动进行划分,每个泳道代表一个责任区。泳道关心的是业务流程中每个角色所涉及的职责。
下图是HIS中的泳道
在这里插入图片描述

对象流(Object Flow)

对象流是动作状态或者活动状态与对象之间的依赖关系,对象流表示动作使用对象或者动作对对象的影响,用活动图描述某个对象时,可以把涉及到的对象放置在活动图中,并用一个依赖将其连接到进行创建、修改和撤销的动作状态或者活动状态上,对象的这种使用方法就构成了对象流。
活动图中没有数据流,可以用对象流来表达数据流。

实例-借书活动图

制作图书借阅业务流程的活动图

角色:读者、图书管理员

读者活动:借书申请

管理员活动:验证读者权限、验证图书状态、保存出借记录、更新读者状态、更新图书状态

简单画一下,下图是按ctrl+a全选要导出的对象,然后点击菜单【edit】,然后选择【Export Image】得到的。
在这里插入图片描述

时序图

时序图描述类系统中类和类之间的交互,以及对象之间消息交互的时间顺序,也可称为顺序图。
时序图是一种强调消息的时序交互图,它由活动者(Actor)、对象(Object)、消息(Message)、生命线(Life line)和控制焦点(Focus of control)组成。

时序图中的对象

在这里插入图片描述
上图没有什么实际意义,单纯用来说明时序图中的对象。

活动者

Actor_1:活动者,通常是业务流程中的对象,例如图书馆操作员。也可以理解为用例图、协作图中的Actor,实际上,我们可以直接引用例图、协作图中定义的Actor。

对象

对象是类的实例,具有特定的属性和操作。女如果对象位于时序图的顶部,!则说明在交互开始之前该对象已经存在了。如果对象是在交互的过程中创建的,那么它应当位于图的中间部分。
Object_1、Object_2:对象,相当类图中的类,协作图中的功能(接口),这里主要是从各个功能的调用(交互)关系、生命周期进行理解的。
在对象的【General】属性页中,可在Classifier中选择已经创建好的类,或者直接点击右边第一个按钮创建新的类。
在这里插入图片描述
例如上图中,我们创建了一个Class_1类,并在该类中设置了一个Operation名叫test,那么在下面消息传递过程中可以选择该Operation:
在这里插入图片描述
设置后效果如下:
在这里插入图片描述
表示Object_1调用Object_2的test函数。

消息

消息定义的是对象之间某种形式的通信,它可以激发某个操作、唤起信号或导致目标对象的创建或撤销。简单地说,消息就是对象与对象、活动者与活动者,或者对象与活动者之间的某种通信方式。
Message_1、Message_2:普通消息,不涉及到调用等待
Message_3:普通自消息
Message_4:调用消息(会自动产生activation)
Message_5:自调用消息(会自动产生activation)
Message_6:返回消息(会自动产生activation)
Message_7:自返回消息
异步消息:在消息的【Detail】属性页面中,可以选择消息的类型为:Asynchronous,则会出现半边箭头的消息表示。
在这里插入图片描述

生命线

生命线是一条垂直的虚线,表示时序图中的对象在一段时间内的存在。
Actor_1、Object_1、Object_2下面的虚线。普通消息和返回消息的【Detail】属性页,可以设置【Action】选项,是否终结对象。
在这里插入图片描述
显示结果就是一个叉叉:
在这里插入图片描述

控制焦点

控制焦点是对象生命线上的一个窄矩形,用于装饰对象生命线。表示对象执行一个动作所经历的时间长度。矩形的顶部表示动作的开始,底部表示动作的结束。
Object_1、Object_2下面的矩形,在PD里面叫activation,它只是一个图标,没有任何含义,用于表示消息处理过程需要一定的时间。

思考:活动者的生命线上可以放置activation吗?

在PD中,支持UML 2.0支持描述当前时序图之外的接口交互,例如:
在这里插入图片描述
这里的大方块相当于一个子序列图。

实例-借书时序图

1.先定义借书涉及到的类图:实体类、业务类、数据访问类。
在这里插入图片描述
2.画时序图
在这里插入图片描述

协作图

协作图显示了一系列的对象和在这些对象之间的联系,以及对象间发送和接收的消息。
协作图也是一种交互图。强调的是发送和接收消息的对象之间的组织结构。
在UML2.0里面协作图叫通信图(communication diagram)了。

时序图vs协作图

时序图和协作图都属于交互图,都用于描述系统中对象之间的动态关系。
协作图以对象图的方式绘制各个参与对缘,强调的是交互的语境与参与交互的对象的整体组织;
时序图可以描述对象的创建和撤销的情况,强调的是交互的时间顺序。

实例

时序图是可以自动生成协作图的(注意:对象没有关联类的不会生成),具体点击菜单项看下图。
在这里插入图片描述
转化后需要调整一下布局:
在这里插入图片描述

组件图

组件是系统高层的可重用的组成部件。组件图描述软件组件,以及组件之间的关系,组件本身是代码的物理模块,组件图则显示了代码的结构。
组件图没有什么难点,在绘制的过程中需要注意组件粒度,例如从比较粗的粒度来看,软件的组件图可以这样画:
在这里插入图片描述
当然可以加上之前的创建的类:
在这里插入图片描述
PD中组件图中除了组件外,还有以下对象:
接口,与类接口概念一致
端口,主要表示类元(classifier)、对象或实体之间的可见交互操作
零件,只可在类或组件内创建,例如组件内部包含某主管零件,和内部密码管理零件,然后可以将这两个零件连接起来

部署图

部署图提供了一个由通信链路连接的节点的视图。在图中我们可以设计节点、文件对象,连接节点之间的关系。节点中包含之前组件图中的实例,这些实例可以部署到数据库、应用程序或网络服务器中并在其中执行。
在这里插入图片描述

  • 12
    点赞
  • 108
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
书馆管理系统 一.书馆管理系统需求分析 1、系统目标设计 系统开发的总目标是实现内部书借阅管理的系统化、规范化和自动化。 能够对书进行注册登记,也就是将书的基本信息(如:书的编号、书名、作者、价格等)预先存入数据库中,供以后检索。 能够对借阅人进行注册登记,包括记录借阅人的姓名、编号、班级、年龄、性别、地址、电话等信息。 提供方便的查询方法。如:以书名、作者、出版社、出版时间(确切的时间、时间段、某一时间之前、某一时间之后)等信息进行书检索,并能反映出书的借阅情况;以借阅人编号对借阅人信息进行检索;以出版社名称查询出版社联系方式信息。 提供对书籍进行的预先预订的功能。 提供旧书销毁功能,对于淘汰、损坏、丢失的书目可及时对数据库进行修改。 能够对使用该管理系统的用户进行管理,按照不同的工作职能提供不同的功能授权。 提供较为完善的差错控制与友好的用户界面,尽量避免误操作。 2、系统功能需求分析 (1) 读者管理:读者信息的制定、输入、修改、查询,包括种类、性别、借书数量、借书期限、备注等。 (2) 书籍管理:书籍基本信息制定、输入、修改、查询,包括书籍编号、类别、关键词、备注。 (3) 借阅管理:包括借书,还书,预订书籍,续借,查询书籍,过期处理和书籍丢失后的处理。 (4)系统管理:包括用户权限管理,数据管理和自动借还书机的管理 UML书馆管理系统建模设计 2 满足以上需求的系统主要包含有一下几个子系统 (1)基本业务功能子系统:该系统中主要包含了借书还书和预订等功能。 (2)基本数据录入功能子系统:该子系统主要包含有书籍信息和读者信息录入功能。 (3)信息查询子系统:包含了多功能的查询书籍信息和读者信息。 (4)数据库管理功能子系统:主要包含了借阅信息管理功能,书籍信息管理功能和预订信息管理功能。 (5)帮助功能子系统。 二、系统动态建模 1、用例、 3 书馆管理系统的用例 从用例中我们可以看出管理员和读者之间对本系统所具有的用例。 管理员所包含的用例有: (1) 登录系统:管理员可以通过登录该系统进行各项功能的操作 (2) 书籍管理:包括对书籍的增删改等。 UML书馆管理系统建模设计
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

oldmao_2000

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值