l用例图.pptVIP

格式:教材P30-31，表3.2和表3.3 四种常见的错误：P31 例子3.5至3.8分别对应了4种错误和修改 编写要点： ⑴ 使用简单的语法：主语明确，语义易于理解，能清晰表述动作即可； ⑵ 明确写出“谁控制球”：即在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制； ⑶ 从俯视的角度来编写：指出参与者的动作，以及系统的响应，也就是从第三者观察的角度； ⑷ 显示过程向前推移：即每一步都有前进的感（如，用户按下tab键作为一个事件就是不合适的）；如果过程繁杂，超过了9步，那么考虑提高目标层次，即“向前推移” ⑸ 显示参与者的意图而非动作:如果只描述动作，人们不能够很容易地直接从事件流描述中理解用例(如通过操纵系统的用户界面来描述用户的动作，这是在编写用例时常见的一种严重错误，它使得编写的目标处于一个很低的层次，叫做界面细节描述。在需求文档中，我们只关心界面所要达到的意图，总结在执行者之间传递的信息。可将这些低层次的步骤合并成一个步骤。 1、用例分析技术步骤（不固定，可根据需要调整）： ⑴ 找出系统外部的参与者和外部系统，确定系统的边界和范围。 ⑵ 确定每一个参与者所期望的系统行为 ⑶ 把这些系统行为命名为用例 ⑷ 使用泛化、包含、扩展等关系处理系统行为的公共或变更部分 ⑸ 编制每一个用例的脚本 ⑹ 绘制用例图 ⑺ 区分基本事件流和异常情况的事件流，如有需要可以把表示异常情况的事件流作为单独的用例来处理 ⑻ 细化用例图，解决用例间的重复与冲突。 例：课表查询系统 （1）教师、学生、教务管理人员、辅导员等等。 （2）教师、学生可以查询自己的课表；教务管理人员可以管理和维护课表（增、删、改、打印报表等） （3）命名 如何绘制用例图----寻找用例的方法 ● 启发性原则：P34 ● 和用户交互 ● 把自己当作参与者,与设想中的系统进行交互 ● 确定用例和确定参与者不能截然分开 ● 寻找用例的启发式问题：P35 ● 是针对每一个参与者的。 参与者为什么要使用该系统？ 参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者又是如何来完成这些操作的？ 参与者是否会将外部的某些事件通知给该系统？ 系统是否会将内部的某些事件通知该参与者？ 问题:在一个系统中,有几个相似的功能,那么将他们防在同一个用例中,还是分成几个用例?假设有这样的需求,在学生档案管理总,管理员经常要做3件事：增加一条学生记录、修改一条学生记录、删除一条学生记录.如果要画出用例图,则以下两种方法哪种更合适? 方法1:用例如图所示,分成3个脚本,分别画3个交互图。脚本1为增加学生记录,脚本2为修改学生记录,脚本3为删除学生记录。 方法2:用例如图所示,以后每个用例画一个交互图. 注：交互图包括顺序图和协作图 答: 从捕获用户需求的角度考虑,(教材)建议采用方法1. 采用方法2的一个主要问题是限制了分析人员的思路,虽然从用例 图可以发现，对学生记录的操作有增加、修改和删除，但事实上，用 户的真正目的可能不是对记录进行增加、修改或删除,而是别的目的. 如学生转学这个要求,虽然这个要求回涉及学生记录的增加、修改和 删除,但如果采用了方法2有可能会忽视了学生转学这个真正的用户需 求. 采用了方法2的分析人员往往还是从数据处理的角度考虑,而不是 从捕获用户需求的角度考虑.该例子是用例分析中一个典型的问题,被 称作CRUD(create,retrieve,update,delete)问题.解决着类问题的要 点是从用例需求的角度考虑,而非数据处理,因此不大可能用到类似方 法2中的用例图了. 常见问题分析 Evaluation only. Created with Aspose.Slides for .NET 3.5 Client Profile 5.2.0.0. Copyright 2004-2011 Aspose Pty Ltd. Case 工具－UML with Rational Rose 第三章　用例和用例图 Evaluation only. Created with Aspose.Slides for .NET 3.5 Client Profile 5.2.0.0. Copyright 2004-2011 Aspose Pty Ltd. 用例之间的关系 1、泛化关系Generalization 代表一般与特殊的关系。（类似与继承） 在用例泛化中，子用例表示父用例的特殊形式，子用例继承了父用例的行为和属性，也可以