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

注意 读者要注意状态图与活动图的区别，活动图反映控制流程，状态图反映一个对象的各个状态的变化。例如在图书管理信息系统中，我们可以对“读者”对象、“图书”对象的状态变化画出状态图；而对借书、还书、采购这些活动画出活动图。 状态图中的转移可以由三部分组成： 事件[条件]/动作 其中的每一部分都可以省略。事件导致对象从一个状态变换到另一个状态，但有时也可以没有事件而自动发生对象的状态转移，这时对象可能在一个状态下完成某些活动后自动转移到其它状态。 括号中的条件是控制转移发生的条件，例如，上图中借书的事件发生时，能否转移到借出状态，要先检查借阅者证件是否有效，并且书库有该书，满足了这些条件后，作出库动作，图书状态到达“借出”状态。 练习： 建模航班状态图 创建一个状态图来描述航班如何从提出申请、制定航班计划、售票、起飞、飞行、到着陆的状态过程。 练习步骤； 1）标识出要建模的实体。 2）标识出实体的状态。 武当山旅游门户网站（ ） 分类信息 7.5用例图—认识用例图 用例 角色 关系 注意：图中的虚线是解释 7.5 用例图（续） 用例图：用于描述一组用例、角色以及它们之间的关系。一个系统的用例图通常是概要地反映整个系统提供的外部可见服务和工作范围。 用例图的基本元素：用例、角色和关系。 进行需求分析时，通常将整个系统看作一个黑盒子，从系统外部的视点出发观察系统：它应该做什么？谁要它做？做了以后的结果送给谁？这些正是用例图要表现的。 用例 在UML中用例的符号是一个椭圆，通常以动词或短语来命名。 用例是软件开发的核心元素，需求是由用例来表达的，界面是在用例的辅助下设计的，类是根据用例来发现的，测试数据是根据用例来生成的，整个开发的管理和任务分配，也是依据用例来组织的。用例简直太重要了！ 角色 角色是指与系统交互的人或物。 角色可以有四种类型：系统的使用者、硬件设备、外部系统和时间。 系统使用者是最重要的角色，例如，在图书信息管理系统中的系统使用者有读者和图书馆的工作人员，包括采购、编目和办公室的工作人员。 其他外部应用系统。 硬件设备，不同的硬件设备具有不同的特性和不同的处理方式。 时间作为角色,经过一定的时间触发系统中的某个事件。 关系——角色与用例之间的关系 通信关系——描述角色与用例之间的关系。例如，当读者还书时，图书馆工作人员启动系统的“还书”用例，进行还书处理。用例也可以启动与角色的通信，例如，还书时，如果该书有预订记录，则系统的“通知”用例启动与读者的通信，通知读者前来借书。 用例之间的关系 包含关系——包含关系用于构造多个用例共同的活动。例如，在ATM系统中，取钱、查询、更改密码等功能都需要验证用户名和密码。这种情况下应该将密码验证功能独立出来，便于复用、减少冗余。 用例之间的关系（续） 扩展关系——允许一个用例扩展另一个用例的功能。例如，在图书信息管理系统中，读者还书时，系统检查所还图书是否有预订记录，如果有则执行“通知”用例。在UML中扩展关系表示为箭头和《extend》形式。 注意 ?使用关系和扩展关系之间的区别，A使用B本质上是A一定使用B，同时增加自己的专属行为；而A被用例B扩展是说明A是一个一般用例，B是一个特殊用例，A在某些条件下可能使用B。 用例或角色之间的继承关系 泛化关系——有时角色或用例之间存在一种继承关系。例如，客户区分为公司客户与个人客户，公司客户又区分为政府机构和私人公司，这时，描述角色之间的关系就可以用泛化关系表示。 注意 用例之间的泛化关系就像类之间的泛化关系一样，子用例继承父用例的行为和含义。例如，一个银行系统中，有一个“验证用户”用例，用于验证用户的合法性，它有两个特殊的子用例，一个是“检查密码”，另一个是“检查指纹”，它们都有父用例“验证用户”的行为，并且可以出现在父用例出现的任何地方，还可以添加自己的行为。 用例图实例 以前面图书信息管理系统为例，画出用例图。先找出参与系统地的角色： （1）读者 描述：可以查询图书；预订和取消预订图书； （2）?工作人员 描述：帮助读者实现借书、还书、预订书、取消预订、查询操作； 接下来我们从角色入手寻找用例。主要角色“读者”通过“流通组工作人员”实现预订图书、取消预订、借书、还书等活动。由此，可以找出下面的一些用例： （1）预订图书——本用例提供了预订图书的功能，读者可以通过浏览器直接从网上预订图书；图书管理员也可以根据读者的要求预订某本图书。 （2）取消预订——本用例提供取消预订图书的功能。 （3）还书——完成还书任务，在还书是要检查所还的书是否超期、是否有其他读者预订，有的话要通知预订者。 （4）借书——提供借阅书功能 。 分析这个用例图，发现“还书”用例应该被扩展，因为在还书时检查所还图书