chapter06用例图教案分析.ppt

*/66 使用Rose绘制用例图 ⑷ 添加参与者与用例 ① 绘制参与者 要创建参与者，首先要单击用例图工具栏中的图标，然后在用例图编辑区内单击画出参与者。接下来可以对这个参与者命名，单击已画出的参与者，会弹出如下对话框。 */66 使用Rose绘制用例图 ⑷ 添加参与者与用例 ① 绘制参与者 对于一个完整的用例图来说，参与者往往不只一个，这就需要创建参与者之间的关系。 */66 使用Rose绘制用例图 ⑷ 添加参与者与用例 ② 绘制用例 单击工具栏中的图标，然后在用例图编辑区内单击鼠标左键画出用例。单击已画出的用例，弹出如图如下所示的对话框。 */66 使用Rose绘制用例图 ⑸ 添加参与者与用例之间的关系 */66 使用Rose绘制用例图 ⑹ 添加用例之间的关系 ① 包含关系 单击用例图工具栏中的图标，然后在需要创建包含关系的两个用例之间拖动鼠标，双击虚线段，弹出如下对话框。 */66 用例之间的包含关系 */66 实例：图书管理系统的用例图 使用Rose绘制用例图 ⑹ 添加用例之间的关系 ② 扩展关系 */66 实例：图书管理系统的用例图 使用Rose绘制用例图 ⑹ 添加用例之间的关系 ③ 泛化关系 */66 下课 * * 功能性：详细描述了系统必须有能力执行的动作，通过详细说明所期望的输入和输出条件来描述系统行为 非功能性： 使用性：人为因素（审美学、易学性、易用性）和用户界面、用户文档、培训资料的一致性 可靠性：失败的频率和失败严重性、可恢复性、可预测性和准确性 性能：在功能性需求上施加的条件，如需求详述了交换率、速度、有效性、准确性、响应时间、恢复时间和内存使用，同时还加上了必须执行某个活动的条件 可支持性：易测性、可维护性和其它在系统发布以后维持系统更新需要的质量。 * * 时间 气温不是，仅是一个条件 * * * */66 参与者 */66 参与者 */66 在获取用例前要先确定系统的参与者，可以根据以下的一些问题来寻求系统参与者。 ⑴ 谁将使用该系统的主要功能； ⑵ 谁将需要该系统的支持以完成其工作； ⑶ 谁将需要安装、维护、管理该系统，以及保持该系统处于工作状态； ⑷ 系统需要处理哪些硬件设备 ⑸ 与该系统发生交互的是什么系统 ⑹ 谁或什么系统对本系统产生的结果感兴趣 参与者的识别 */66 参与者的识别 */66 总结：如何发现参与者？ 人员—— 系统的直接使用者 直接为系统服务的人员 设备—— 与系统直接相联的设备 为系统提供信息 在系统控制下运行 不与系统相联的设备 × 计算机设备 × 外系统—— 上级系统 子系统 其它系统 */66 超市销售管理系统 收款员 供货员 上级系统 收款员、供货员、导购员、经理、保安、顾客 收款机？ */66 识别参与者：考勤卡系统 开发者：谁将使用这个应用程序？客 户：所有用它来记录可记帐以及不可记帐的工时的雇员……开发者：现在考勤卡应用程序是什么样的？客 户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者：这个收费项目代码可以从什么地方得到？……开发者：谁来管理收费项目代码？客 户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。…… */66 多个参与者之间可以具有与类之间相同的关系。 在用例图中，可以使用泛化关系来描述多个参与者之间的公共行为。 参与者间的关系 */66 例如，在图书馆管理系统中，借书者可以泛化成两类：学生和老师。 再如，航空售票系统接受客户预定机票，客户可以进行电话预定和网上预定，如果不考虑客户是如何与系统接触的，可以使用一般角色的参与者，即父类；如果强调接触发生的形式，那么必须使用实际的参与者，即子类。 参与者间的关系 */66 更具一般的，可以由下图表示参与者之间的关系。 参与者间的关系 */66 思考：识别参与者？ 寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑； 在这个叙述里，谁是寻呼台系统的Actor？用户？气温？时间？ */66 用例是外部可见的系统功能单元。 用例是对一个系统或一个应用的一种单一的使用方式所作的描述。 用例的用途是，在不揭示系统内部构造的前提下定义系统的行为。 在UML中，用例用一个椭圆来表示，用例的名字可