UML-用例图.pptVIP

2012年4月 UML与设计模式第三章 用例图 UML模型的图形 UML图的作用 UML 可以用于: 使用用例（use cases）和参与者（actors）描述系统的边界和它的主要功能。 使用交互图（顺序图、协作图）具体描述用例的实现。 使用类图表示系统的静态结构。 使用状态转换图模型化对象的行为。 使用构件图和部署图展现系统的物理实现体系结构。 使用衍型（stereotypes）扩展建模能力。 1、用例图：参与者（Actors） 参与者定义了一组与系统有信息交互关系的人、事、物。它是用例的客户并与用例进行交互。一个参与者针对每一个与之通信的用例扮演一种角色。 角色可以是人或外部系统。它定义了系统的边界。 用例（Use Cases） 一个用例是一种系统应表现行为的模式: 每个用例是一个参与者与系统在一次对话中所执行的相关事务的序列。 要调查参与者以确定他们的要求： Registrar（注册管理员）－ 维护所有课程信息 Professor（教授）－ 要求选课名单 Student（学生）－ 维护选课表 Billing System（记账系统）－ 从注册中心接受记账信息 用例之间关系 包含 扩展 泛化 使用 包含（Include） 即在一个用例中重用另一个用例中的步骤。 扩展关系（extend） 扩展用例是在原用例的基础上增加新的步骤序列形成的。 原用例被称为基用例（base use case）。扩展只能发生在基用例的序列中的某个具体制定点上，这个点叫做扩展点（extension points）。 扩展关系 VS 包含关系 在扩展关系中，基用例不必知道扩展用例的任何细节，事实上基用例没有扩展也是完整的，只有特定的条件发生了，扩展用例的行为才被执行，而包含关系则不同。 泛化关系（generalization） 用例阐述文档 场景（scenario）： 是参与者和被讨论系统之间的一系列特定活动和交互。每个用例是一组场景的集合，而每个场景又是一个步骤序列。 用例阐述文档针对每个用例，描述各个场景 “Borrow Book”用例中的场景 如，在“Borrow Book”这个用例中，包含着几个相关的scenario： Scenario-1：顺利地借到书 Scenario-2：该种书刊不存在 Scenario-3：物理书刊都已借出 Scenario-4：没有该借阅者信息 谁来写用例文档 最完美：业务人员接受训练，写出优美的用例文档 最现实：业务人员提供素材，开发人员写用例文档 最糟糕：业务人员不管，完全由开发人员杜撰 用例阐述组成 用例名称 用例概述 涉及的参与者 前置条件Preconditions 后置条件Postcondition 事件流Flow of events 分支流Subflows 备选流Alternate flow 前置、后置条件(1) 前置条件约束在用例开始前系统的状态 把它们看做是看门人，它阻止参与者触发该用例直到满足所有条件 说明在用例触发之前什么必须为真 后置条件约束用例执行后系统的状态 用例执行后什么必须为真 对于有多个事件流的用例，则应该有多个后置条件 前置、后置条件(2) 某些用例依赖于其他用例 一个用例在离开系统时，可能是另一个用例的前置条件（例如：“登录”和“管理系统”） 有助于识别漏掉的用例 如果一个用例的前置条件不能有执行其他用例满足，可能意味着丢失了用例（例如：“管理订单”却没有“登录”用例） 事件流描述要点 1.只书写“可观测”的 2.使用主动语句 3.句子必须以参与者或系统作为主语 4.不要涉及界面细节 要点1：只写“可观测”的 系统通过ADO建立数据库连接，传送SQL查询语句，从“商品表”查询商品的详细信息… 系统按照查询条件搜索商品的详细信息 要点2：主动语句 欧文丛贝克汉姆处得到传球，守门员… 贝克汉姆传球给欧文，欧文射门，守门员扑救… 图书管理员…… 系统…… 要点3：以参与者或系统作主语 参与者…… 系统…… 图书管理员输入书目和借阅者信息； 系统检索书目 系统检索借阅者 图书管理员将图书借给借阅者 系统记录借阅信息 ….. 要点4：不涉及界面细节 会员从下拉框中选择类别 会员在相应文本框中输入查询条件 会员点击“确定”按钮 Encounter CourtyardImage (including game characters) 1 Initialize Use Case for Encounter Initialize Use Case for Encounter Engage Foreign Character Use Case 以“图书管理系统”为例，首先标识参与者： Librarian 图书管理员：创建、修改、删除借阅者信息；添加、编辑、删除馆藏图书信息；添加