UML 用例图、关系图、活动图

7.5用例图—认识用例图用例角色关系注意：图中的虚线是解释7.5用例图（续）用例图：用于描述一组用例、角色以及它们之间的关系。一个系统的用例图通常是概要地反映整个系统提供的外部可见服务和工作范围。用例图的基本元素：用例、角色和关系。进行需求分析时，通常将整个系统看作一个黑盒子，从系统外部的视点出发观察系统：它应该做什么？谁要它做？做了以后的结果送给谁？这些正是用例图要现的。用例在UML中用例的符号是一个椭圆，通常以动词或短语来命名。用例是软件开发的核心元素，需求是由用例来表达的，界面是在用例的辅助下设计的，类是根据用例来发现的，测试数据是根据用例来生成的，整个开发的管理和任务分配，也是依据用例来组织的。用例简直太重要了！角色角色是指与系统交互的人或物。角色可以有四种类型：系统的使用者、硬件设备、外部系统和时间。系统使用者是最重要的角色，例如，在图信息管理系统中的系统使用者有读者和图书馆的工作人员，包括采购、编目和办公室的工作人员。其他外部应用系统。硬件设备，不同的硬件设备具有不同的特性和不同的处理方式。时间作为角色,经过一定的时间触发系统中的某个事件。关系——角色与用例之间的关系通信关系——描述角色与用例之间的关系。例如，当读者还书时，图书馆工作人员启动系统的“还书”用例，进行还书处理。用例也可以启动与角色的通信，例如，还书时，如果该书有预订记录，则系统的“”用例启动与读者的通信，通知读者前来借书。用例之间的关系包含关系——包含关系用于构造多个用例共同的活动。例如，在ATM系统中，取钱、查询、更改密码等功能都需要验证用户名和密码。这种情况下应该将密码验证功能独立出来，便于复用、减少冗余。用例之间的关系（续）扩展关系——允许一个用例扩展另一个用例的功能。例如，在图书信息管理系统中，读者还书时，系统检查所还图书是否有预订记录，如果有则执行“通知”用例。在UML中扩展关系表示为箭头和《extend》形式。注意使用关系和扩展关系之间的区别，A使用B本质上是A一定使用B，同时增加自己的专属行为；而A被用例B扩展是说明A是一个一般用例，B是一个特殊用例，A在某些条件下可能使用B。用例或角色之间的继承关系泛化关系——有时角色或用例之间存在一种继承关系。例如，客户区分为公司客户与个人客户，公司客户又区分为政府机构和私人公司，这时，描述角色之间的关系就可以用泛化关系表示。注意用例之间的泛化关系就像类之间的泛化关系一样，子用例继承父用例的行为和含义。例如，一个银行系统中，有一个“验证用户”用例，用于验证用户的合法性，它有两个特殊的子用例，一个是“检查密码”，另一个是“检查指纹”，它们都有父用例“验证用户”的行为，并且可以出现在父用例出现的任何地方，还可以添加自己的行为。用例图实例以前面图书信息管理系统为例，画出用例图。先找出参与系统地的角色：（1）读者描述：可以查询图书；预订和取消预订图书；（2） 工作人员描述：帮助读者实现借书、还书、预订书、取消预订、查询操作；接下来我们从角色入手寻找用例。主要角色“读者”通过“流通组工作人员”实现预订图书、取消预订、借书、还书等活动。由此，可以找出下面的一些用例：（1）预订图书——本用例提供了预订图书的功能，读者可以通过浏览器直接从网上预订图书；图书管理员也可以根据读者的要求预订某本图书。（2）取消预订——本用例提供取消预订图书的功能。（3）还书——完成还书任务，在还书是要检查所还的书是否超期、是否有其他读者预订，有的话要通知预订者。（4）借书——提供借阅书功能。分析这个用例图，发现“还书”用例应该被扩展，因为在还书时检查所还图书是否有预订记录，若有，则应该通知预订者前来借书。当欲借图书已全部被借出时，应该可以转向“预订”用例。读者可以直接从网上查询、预订或取消预订图书。根据以上几点，画出初始的用例图如下：注意在画用例图时要特别注意：用例图是系统分析、设计和实现的一个最基础的图形，在初期是不一定要考虑太多的处理细节。一个用例内部的具体处理细节是由其他图形工具描述的，用例图只是反映系统的总体功能，以及与这些功能的相关的角色。有些人可能在画“借书”用例时，情不自禁地就考虑了“输入读者号和书号”，“检查图书是否在库？”，“图书数量减1”，“添加读者借书记录”等等，一旦考虑了这些细节，就会发现用例图画不下去了。因此，读者注意用例图中不要考虑处理细节。用例图练习下面是关于一个公司的人事信息管理系统的需求的简单描述,建立其相应的用例模型:该人事管理系统的用户是公司的人事管理干部.该系统具有人事档案库,保存员工的人事信息,包括姓名,性别,出生年月,健康状况,文化程度,学位,职称,岗位,聘任时间,任期,工资,津贴,奖罚记录,业绩,论著和家庭情况等,系统提供的基本服务有人事信息的管理,包括人事的调动与聘任,职称评定,奖罚等,并且可以按照限查询人事信息,生成与输出统计报表等.该人事系统每月向公司的财务系统提供员工的工资,津贴等数据.7.6活动图描述从一个活动到另一个活动的流程，用于对系统的动态特性建模。在需求分析时用活动图描述一个用例内部活动流的操作步骤等。认识活动图—图书馆图书信息管理系统借书活动图活动图中的主要图形元素泳道：活动图中的分隔线，说明谁负责执行该泳道中的活动。开始状态：活动流的开始点。表示符号为黑点。活动：活动流可能由多个活动组成，一个活动的表示符号为椭圆。操作：一个活动可以有多个操作步骤，这些操作可能发生在进入活动时、退出活动时、活动内或特定的事件发生时。对象：活动流影响的实体对象。活动可能会改变某个对象的状态，将活动影响的对象及其状态也标识在活动图中，使得活动图表示的信息更加完整。表示的符号为。用虚线表示哪个活动影响对象的状态。交接：是描述活动流如何从一个活动转移到下一个活动的。表示符号是活动之间的箭头线。决策：活动流中的分支判断点，在这点上根据条件判断活动流走哪个分支路径。表示符号为菱形。同步：活动流中多个活动可以同时发生。例如，下面的图示说明活动1、活动2和活动3是同时进行的，当三个活动完成之后，进行另一个同步，也叫做连接。结束点：活动流的结束点。并发活动图书馆图书信息管理系统借书活动图的说明图中有两个泳道，说明借书用例所涉及的角色有两个：读者和图书馆工作人员。读者以“借书申请”活动开始这个工作流，这个活动将读者编号和图书编号传递给图书馆工作人员工作人员检查“读者”类，看该“读者编号”是否存在；然后检查读者的借书数量是否已经超出限制，如果读者编号有效，并且借书数量没有超限，则检查图书是否在库中，否则，提示读者“读者无效”。如果欲借图书已经都被借出，则提示“图书已经被借出，是否预订？”当读者确认预订后，转去执行“预订处理”。如果库中有欲借图书，则首先检查“预订记录”，如果该读者已经预订了此书，则删除预订记录。修改此书在库数量，创建“借书记录”，结束借书过程。注意：活动图描述多个角色之间的处理非常有效，一张活动图只能有一个开始状态，但可以有多个结束状态。一个活动可以与多个实体对象相关，这里的相关指的是一种访问操作。在上面“借书”活动图中，“检查读者有效”的活动，要访问“读者”对象和“借还书记录”对象，检查“读者编号”的有效性和读者借书数量。活动图练习某公司销售人员接到订单后,将订单传给财务人员和仓库人员.财务人员开具发票,并收款.仓库人员准备货物,并查看是否货物加急,若是加急采用EMS方式发货,否则采用普通包裹方式发货.完成之后由销售人员关闭该订单.根据上面描述画出该公司销售过程的活动图.7.7状态图状态图用于对系统动态特征建模，主要是帮助理解反应型对象的行为变化。一个反应型对象是这样的对象，它的行为是通过对来自外部的事件作出反应来刻画的。状态图中主要描述一个对象的三种信息：1)对象的各种状态；2)引起状态变化的事件；3)每个状态改变时所发生的动作。认识状态图注意读者要注意状态图与活动图的区别，活动图反映控制流程，状态图反映一个对象的各个状态的变化。例如在图书管理信息系统中，我们可以对“读者”对象、“图书”对象的状态变化画出状态图；而对借书、还书、采购这些活动画出活动图。状态图中的转移可以由三部分组成：事件[条件]/动作其中的每一部分都可以省略。事件导致对象从一个状态变换到另一个状态，但有时也可以没有事件而自动发生对象的状态转移，这时对象可能在一个状态下完成某些活动后自动转移到其它状态。括号中的条件是控制转移发生的条件，例如，上图中借书的事件发生时，能否转移到借出状态，要先检查借阅者证件是否有效，并且书库有该书，满足了这些条件后，作出库动作，图书状态到达“借出”状态。练习：建模航班状态图创建一个状态图来描述航班如何从提出申请、制定航班计划、售票、起飞、飞行、到着陆的状态过程。练习步骤；1）标识出要建模的实体。2）标识出实体的状态。