信息系统分析与设计案例201X-2ppt课件

《信息系统分析与设计案例201X-2ppt课件》由会员分享，可在线阅读，更多相关《信息系统分析与设计案例201X-2ppt课件（55页珍藏版）》请在金锄头文库上搜索。

1、 课程案例一 第二部分 用例用例图用例场景和用例描述参与者和参与者描述用例关系技术讨论 内容 简介 1 用例对用户眼中的系统功能进行建模 即到目前为止用户所关注的系统做什么 它所做的对用户有价值的事情 用例模型提供了一种对需求调查阶段所获得的大量信息进行组织 分类和记录的一种方式 因此 它是开发过程中需求定义的一个组成部分 用例通常用图形表示 即用例图 并且被文本描述 用例描述 参与者描述和场景 所支持 用例图和支持文本都是简单的和直观的 它们是理想的工具用于同用户讨论和清楚表明开发者对用户需求理解 简介 2 一旦用例模型完成并同用户一起检查 它就形成一个结构化信息的基础源 系统其它的模型都能

2、在其基础上作出 用例模型对系统的测试也是有帮助的 用例建模时在面向对象软件开发过程的不同阶段进行的 在各个阶段的信息类型和详细程度取决于模型的用途 在开发的早期阶段 用例模型的主要目的是用于同用户沟通 不包括系统详细设计和实施的信息 随后 诸如用户界面的设计这样相关的技术细节被增加 以便为编程人员提供信息 用例图 用例模型由用例图 一组用例描述 一组参与者描述和一组场景组成 用例图使用四个概念对问题领域进行图形化建模 用例 usecase 参与者 actor 关系连接 relationshiplink 和边界 boundary 图2 1表示了Wheels案例研究的一个用例图 新系统的功能被分解

3、成5个用例 维护自行车登记表 Maintainbikelist 维护顾客登记表 Maintaincustomerlist 处理询问 Handleenquiries 出租自行车 Issuebike 以及处理自行车返还 Handlebikereturn 概念上 用例图类似于顶层菜单 其列出了系统做的5个主要的事情 确定用例 1 根据参与者确定用例我们看到了Annie和Simon开始谈论的是如何出租自行车 这是Annie每天主要的工作任务之一 因此 出租自行车是一个用例 出租自行车包括找出合适的自行车 计算租金 收钱 给收据 以及记录顾客和租赁交易的细节 然后 会谈涉及到关于自行车返还处理的讨论 A

4、nnie将这当做与出租自行车分开的任务 因为其在时间上上是不同的 并且涉及一组不同的过程 检查日期 检查自行车的车况 以及返还押金 确定用例 2 根据参与者确定用例 续1 在会谈中Annie告诉我们 一个自行车的登记表已经存放在计算机中 但是不能用来帮助他们进行工作 这个自行车登记表需要如此存储 以便其能用来回答诸如此类问题的询问 Wheels有什么样的自行车 是否这些车可以租借 它们的押金是多少 租金是多少 如此等等 维护这个自行车登记表是另一个用例 处理询问被Annie视作是与出租自行车不同的另外任务 她经常遇到有人到商店或打电话来仅仅为了了解有哪些自行车可以租借 以及费用如何 有时这种询

5、问会导致租借 但更多的时候不会导致自行车的租借 因此 我们能确定 处理询问 Handleenquiries 是一个单独的用例 确定用例 3 根据参与者确定用例 续2 在会谈中 发现顾客的信息 以及他们以前租借自行车的记录没有被保存 而这类信息从市场营销的角度是非常有用的 其能简化对相同自行车租借的处理 参见问题定义图2 2 问题和需求列表图2 3 以及会谈总结图2 4 因此 维护顾客登记表 Maintaincustomerlist 能被确定为一个用例 用例场景 1 根据用例场景确定用例一个场景描述了用户和系统之间一系列的交互以便达到特定的目的 一个场景描述了一个特定的事件序列 例如 当Anni

6、e成功地将自行车出租给用户时将会发生什么事情 参见图2 5 取决于所在的阶段 系统开发人员能够使用场景来描述在一个情况下实际发生什么 或者 可能已经发生什么 或者他们要求在新系统中将要发生的事情 用例场景 2 根据用例场景确定用例 续 一个精心研究的场景既描述了系统的典型应用 又描述了系统的例外的应用 它是一个非常好的工具 用来理解系统做什么 以及它是如何使用的 她是一个从下到上理解系统的方法 你从了解系统如何被使用的细节着手 以此发现整个的目标和目的是什么 进而理解用例是什么 每个用例代表了一组场景 属于同一用例的场景有共同的目的 而在这个组中的每个场景描述了涉及达到 或不能达到 这个用例目

7、的的一个不同的事件序列 图2 5和图2 6描述了属于出租自行车 Issuebike 用例的场景 在两种情况下 Annie都试图将一辆自行车出租给一位顾客 用例场景 3 场景应该用文档记录一个典型的事件序列导致达到用例的目的 即一个顾客租到了一辆自行车 明显地 有些特殊情况 例如 一位顾客租借一辆以上的自行车 租借时间是一样的 一位顾客租借一辆以上的自行车 但每辆车的租借时间长短不一 一位顾客租借一辆特殊的自行车 等等 也有一些事件序列表示用例的目的不能达到 例如 顾客不能发现他所喜欢的自行车 顾客认为费用太高 等等 开发人员需要确信其理解并用文档记录了系统应该如何响应每一个可能发生的事件 小的

8、 简单的用例利用用例描述就能充分地描述了 用例描述 1 什么是用例描述用例描述是一种描述性文档 其以普通的术语描述了用例的功能需求 典型地 它描述了用例的目的 给出了通常会发生什么的一般性描述 事件的正常过程 以及任何小的变化的简要描述 换言之 这种描述是概况的 其书写的方式是应该包括涉及用例的每一个事件序列和每一个场景 这种描述表明系统应该做什么 而不是它应该如何做 在这些情节后面的程序编写 数据存储结构 以及其它的实施细节不应出现在用力描述中 仅仅是用户能见到的发生事情 用例描述 2 高层次的用例描述有两种不同类型的用例描述是有用的 在软件开发的早期 此时关于系统设计 特别是系统用户界面的

9、设计的详细决策没有被制定 一个简短的 非结构化的描述是足够的 这种描述被称为高层描述 参见图2 7 这些描述仅需要记录用例的目的 涉及的参与者 以及发生什么的总体概述 用例描述 3 扩展的用例描述随后 一个更详细的 结构化得描述是有用的 其被称为扩展用例描述 参见图2 8 扩展用例描述比高层用例描述更详细 结构化更强 它应该记录 什么发生来触发用例哪些参与者被涉及哪些数据应该被输入用例的输出是什么用例需要哪些存储的数据什么发生来表示用例的完成事件序列的微小变化 图2 9 参与者与参与者描述 1 参与者参与者在系统外部 他们代表了同系统交互 并从中获得某种收益的某些人或事物 通常 一个参与者是一

10、位用户 但有时它是诸如银行或财务系统这样的其它系统 一个参与者也可以代表诸如打印机这样的硬件 一般而言 一个参与者是某个输入信息到系统或接收来自系统的信息 或二者具备 的实体 更严谨地 一个参与者代表了利用系统的一种特殊的方法 一种同系统交互以取得用例目的的方法 它经常被描述成某个实体在用例中所扮演的角色 Theactorsintheusecasediagramin在用例图图2 1中的参与者是管理者 Administrator 和接待员 Receptionist 接待员租出自行车 管理者维护自行车登记表和顾客登记表 在Wheels中即没有管理者的任务头衔 也没有接待员的任务头衔 这是因为我们不

11、是表示任何个人 相反我们表示任何被授权使用系统来完成特定任务的人 参与者与参与者描述 2 参与者 续 每个参与者能代表着若干不同的人和若干不同的任务头衔 例如 管理者可能是首席机械师Naresh 商店经理Annie 或者甚至是商店老板Mike 每个人或任务头衔能扮演若干个不同的角色 接待员的角色通常是由Annie扮演 然而 当她不在的时候 任何一个机械师或者Mike能作为接待员使用计算机系统 即他们能扮演接待员的角色 另一个思维的方式是用户在使用系统时能戴不同的帽子 Naresh能戴管理者或接待员的帽子来使用本系统 参与者在需求获取时通过询问下列问题来确认 谁涉及诸如出租自行车这样的主要系统过

12、程 谁将使用新系统 谁给系统提供信息 谁获得系统的输出 参与者与参与者描述 3 参与者描述参与者描述借助角色和任务头衔来简要描述参与者接待员使用系统来回答关于自行车的可得性和费用的询问 租出自行车 以及记录自行车的返还 接待员可以是商店经理Annie 任何一位机械师 或者商店老板Mike 管理者使用系统来维护顾客和自行车登记表 管理者可以是首席机械师Naresh 商店经理Annie 或者商店老板Mike 用例关系 1 通讯关联在用例图中 连接参与者和用例的连接线被称作为通讯关联 参见图2 1 通讯关联告诉我们哪个参与者同哪个用例是相互关联的 每个参与者可能被关联到许多用例 每个用例能被关联到许

13、多参与者 包括 Include include 关系是用例之间的关系 当你发现你有一部分行为对若干用例是共同的时候 它是有用的 不需要在若干个用例描述中重复地描述这部分行为 这部分共同的行为能分割成一个单独的用例 然后用 include 关系连接到所有相关的用例 确定对若干用例是共同的功能是重要的 它允许开发人员避免无谓的努力 一部分功能能被一次确定 研究和建模 然后在需要时重用 用例关系 通讯关联 include和extend 2 包括 Include 续 图2 10表示了一个初始Wheels的用例图 参见图2 1 的精炼版本 用例 Maintainbikelist Handleenquir

14、ies Issuebike 和 Handlebikereturn 都需要在自行车记录表中发现一辆特定的自行车 因此 我们产生一个新用例 Findbike 然后将它用 include 关系连接到前面四个需要它的用例 这告诉我们这些用例将总使用 Findbike 用例 同样 Issuebike 的用例描述的第一部分重复了用例 Handleenquiries 的行为 Annie在出租自行车之前总是要告诉顾客一辆自行车每天的租金和押金 取代在两个用例中重复描述同一行为 我们能将其从 Issuebike 用例中去掉 然后在 Issuebike 和 Handleenquiries 之间使用一个 inclu

15、de 关系 注意虚线箭头从主要用例指向它所包括的用例 即从 Issuebike 指向 Handleenquiries 用例关系 通讯关联 include和extend 3 扩展 Extend extend 关系被用作为在一个用例中定义一个特定的有意义的替代行为的方法 它通常记录用户能选择在正常情况以外的功能 在这个方面使用 extend 关系仅仅是为了记录不同于正常事件过程的重要变化 小的变化能在扩展用例描述中所覆盖 如果我们要描述下列情况 则需要使用一个 extend 关系 另外的功能在需要时是能够得到的 例如 打印一个列表 而不是仅仅在屏幕上显示它 仅在特定条件下的行为 例如 如何没有返还

16、全部押金 则打印另外的收据 用例关系 通讯关联 include和extend 4 扩展 Extend 续1 在图2 10中 我们已经产生了一个新用例 Printreceipt 和一个这个新用例同 Handlebikereturn 用例之间的 extend 其意义是表示有时在返还一辆自行车时可能涉及到打印一张收据 虽然正常情况下不会发生 如果顾客租借自行车的天数超出他们预付的租金的天数 或者还回的自行车有损坏 则必须打印新的收据 相反 打印收据总是 Issuebike 用例的组成部分 所以我们在 Issuebike 和 Printreceipt 之间定义了一个 include关系 注意现在虚线箭头是从新扩展的用例指向主用例 即从 Printreceipt 指向 Handlebikereturn 这种方向的改变似乎没有特别的理由 仅仅是规则所规定 用例关系 通讯关联 include和extend 5 扩展 Extend 续2 如果我们决定用例 Issuebike 的部分将相当频繁地涉及增加新顾客 或者更新我们已有顾客的细节 那么在 Issuebike 和 Maintaincustomerl