3章 用例图.ppt

* 基用例可以看到为他设置属性的包含用例，但不能访问包含用例的属性，因为基用例重新得到控制后，包含用例应经结束了。 * 包含关系有位置属性，也就是说，在基用例的行为序列体中的恰当的位置插入包含。当执行基用例到达该位置的时候，用例实例执行包含用例，随后继续执行基用例。位置是隐含的。另外，包含用例只执行一次。 * 用例太多 具体划分依赖经验，学校一级的管理系统，划分为多个系统，划分多个包。用例告诉的不是如何做，而是告知有那些需求 * 用例是用命名的椭圆表示，如果没有对这个用例做具体的说明，不清楚这个用例到底会完成什么功能，没有描述的用例就像一本书的目录，我们只是知道书的标题，并不知道具体内容是什么。 * 用例太多 具体划分依赖经验，学校一级的管理系统，划分为多个系统，划分多个包。用例告诉的不是如何做，而是告知有那些需求 * Jacobson 提出以下问题： 每个actor的主要任务是什么？ 该actor是否将读、写或修改系统的任何信息？ actor是否该把系统外部的变化通知系统？ actor是否希望系统把预料之外的变化通知自己？ 寻找用例时需要注意的问题： 不要一开始就去捕捉所有的细节。 全面地认识和定义每一个use case，要点是以穷举的方式考虑每一个actor与系统的交互情况。 * 利用参与者捕获用例 对所有的参与者（把自己作为参与者），提问下列问题： 每个参与者的主要任务是什么？ 为了达到某种目的，它们参加什么活动？该参与者是否将读写系统的任何信息？参与者是否该把系统外部的变化通知系统？参与者是否希望系统把预料之外的变化通知自己？ 在交互过程中，它们是怎样使用系统的服务来完成它们的任务以达到目的？ 它们参加了什么在本质上是不同的过程？ 是什么事件引起了与系统进行交互的序列？ * 从系统功能角度捕获用例 用于本步骤的一些简单的指导如下： 一个用例描述一项功能，这项功能不能过大。例如，把一个企业信息管理系统粗略地分为生产管理、供销管理、财务管理和人事管理等几大方面的功能，就显得粒度太大了，应该再进行细化。 全面地认识和定义每一个用例，要点是以穷举的方式考虑每一个参与者与系统的交互情况，看看每个参与者要求系统提供什么功能，以及参与者的每一项输入信息将要求系统作出什么反映，进行什么处理。 * 从系统功能角度捕获用例 用于本步骤的一些简单的指导如下： 以穷举的方式检查用户对系统的功能需求是否能在各个用例中体现出来。 一个用例应该是一个完整的任务，通常应该在一个相对短的时间段内完成。如果一个用例的各部分被分配在不同的时间段，尤其被不同的参与者执行，最好还是将各部分作为单独的用例对待。 考虑对例外情况的处理。针对用例描述的基本流，要详尽地考虑各种其他的情况 * 审查 参与者 确定系统环境中的所有角色，并都归入了相应的参与者。 每个参与者都至少和一个用例关联； 若一个参与者是另一个参与者的一部分，或扮演了类似的角色，考虑在它们之间使用泛化关系； 用例 每个用例都至少和一个参与者相关； 若两个用例有相同或相似的序列，可能需要合并它们，或抽取出一个新用例，在它们之间使用包含、扩展或泛化关系。 若用例过于复杂，为了易于理解，考虑进行分解；若一个用例中有完全不同的事件流，最好把它分解成不同的用例 * 举例: 一个简化的学生选课系统，学生可以使用该系统选修课程 用户需求说明: 1. 系统管理员为每个使用系统的人员设置权限，只有通过权限验证的人才能使用系统。 2. 学生可以使用该系统查看课程信息、选修课程。 3. 学生选课时，系统要通过财务管理系统核对学生是否交费，只有交费的学生才能选修课程。 4. 系统录入员负责录入选修课程信息和教师信息。 * 学生选课系统的系统用例 * 3、对用例进行描述 用例名：选课参与者： 学生前置条件：成功登录，进入选课界面。 后置条件：退出选课界面。 基本事件流： 1. 浏览本学期预开设的课程。 2.学生选择要选修的课程并确认。 3. 系统通过财务系统检查学生是否交费。 4. 系统更新该学生所选课程。 5. 系统显示学生所选课程。 6. 学生提交所选课程。 7. 系统保存学生所选课程。 备选事件流： 2.a 如果学生没有交费，给出提示，结束。 5.a 如果学生没有提交，给出提示，结束。 * 4、确定用例、参与者之间的关系，构造用例模型 按照用例进行分析，看一看每一个用例都和哪些参与者相关。 * * 三、需求描述 用户需求分析的结果需要用规范的文档记录下来，这就是用户需求文档。 * 方案1 由于选课和查看学分都需要登录，故专门设立一个“登录”用例。若登录成功，则可以进行选课，也可以进行查看学分 如下为对用例“登录”的描述 研究生启动系统；系统提示研究生输入研究生证号和密码； 研究生输入研究生证号和密码； 系