tanhuobin_uml04a[1].Use-Case+Modeling+(Supplement).ppt

1、面向对象分析设计Object-Oriented Analysis & Design,谭火彬,第04章 用例建模(作业讲解),Use Case Modeling (Supplement),-3-,作业1：用例建模,总分：20分 参阅给定的考勤系统问题陈述（网站的文档中心下载），完成下面所要求的内容 完成“考勤系统”的系统用例图，注意用例的命名和用例间的关系的使用，并简单描述每个执行者和用例的含义（10分） 选择一个体现系统核心业务的系统用例，完成用例规约，如果该用例有“扩展”、“包含”或“泛化”的子用例，则至少还需要写出一个子用例的规约（10分）,-4-,作业的评分标准,1. 有明显的重大的错误

2、，则不及格，即为5 2. 按相关要点进行扣分：1-2 用例图 执行者的选择、关系 用例的选择、命名、粒度 用例关系的正确使用 “时间”执行者、外部系统执行者 用例文档 基本路径的编写 前置条件等其它部分 用例关系的描述,先看几个问题较多的用例图,-6-,1,2,3,4,-7-,再来分析每个问题,-9-,1.1时间执行者的使用,时间：执行者，一种习惯用法，用于激活那些系统定期的、自动执行的用例,-10-,1.2外部系统执行者的使用,外部系统作为一个外部不可控因素，在用例模型中以一个执行者表示 外部系统一般作为一个辅执行者，注意关联的方向,-11-,1.3“人”执行者的使用,“人”作为一个外部因素

3、，当他直接与系统交互时，在用例模型中作为一个执行者表示，但系统不能对他提出任何要求，因此注意用例与“人”关联的方向,-12-,1.4执行者之间的泛化-1,执行者之间的泛化意味着特化的执行者是泛化执行者的一个特例，会与泛化执行者有相同的行为,-13-,1.4执行者之间的泛化-2,执行者是系统外部的，因此它最主要的目标是为了提取用例，不带来任何用例的执行者没有意义,-14-,2.1用例的命名,用例的命名 （状语）动词+（定语+ ）宾语 用例名称要简单易懂，直接反映业务本质，少用“信息”、“数据”等弱名次,-15-,2.2用例体现系统需要完成的功能,用例描述了系统需要完成的功能，因此不是系统需要处理

4、的就不是用例,-16-,2.3用例粒度,用例是一组用例实例，太细陷入了功能分解，用例文档不好写，后面的用例分析更没法做,-17-,2.4用例关系的使用,用例之间的三种关系,-18-,扩展 VS. 包含-1,包含：由用例A连向用例B，表示用例A中使用了用例B中的行为或功能 扩展：由用例B连向用例A，表示用例A描述了一项基本需求，而用例B则描述了该基本需求的特殊情况，即一种扩展 扩展用例的目的是在不改变某个已存在（或假定存在）的用例的前提下为之增添新行为 这些附加的行为可能是必需的，也可能是可选的,-19-,扩展 VS. 包含-2,扩展和包含用例本质上其实非常相似，它们的主要区别在于用例实例中断基

5、用例、执行附加用例的方式 扩展和包含用例都于基用例相联。在基用例的执行过程中，可能在某种条件下基用例的执行流被中断，转而执行扩展或包含用例（在UML中统称为附加用例）的流。当附加用例流执行完毕，控制将返回到基用流原来被中断的那个位置恢复执行 扩展用例通过引用扩展点（extension point）建立与基用例的联系，扩展点指明了在基用例中的扩展位置,-20-,扩展关系的使用,使用扩展的一个潜在问题是创建过深的扩展依赖层次 Jacobson博士建议永远不要扩展一个扩展 对于在描述用例的时候，什么时候用扩展，什么时候用可选路径，Jacobson建议： 只有当扩展用例与被扩展用例完全分离（即它本身是

6、一个独立的具体用例或者是其他用例需要的一个小片段）时，才使用扩展关系 基用例自身必须是完整的，它的正确执行不需要扩展。否则，就应该用可选路径来描述附加行为,-21-,包含关系的使用,包含关系使用不当容易诱使人们进行攻能分解，从而导致对用例的误用 Jacobson说，“事实上，今天一些人误用了用例，把它们用来描述功能（注：指功能分解式的分析）而不是对象，反过来又指责用例概念存在问题”,-22-,关系,关于关系 uml1.1中有两种用例关系 关系和关系 它们都是泛化（generalization）关系的构造型（stereotype） uml1.3之后，提供了三种用例关系 关系、关系都是依赖（dep

7、endency）关系的构造型（stereotype） 泛化关系（generalization）,-23-,3.1用例规约中的前置条件,前置条件约束在用例开始前系统状态 后置条件约束用例执行后系统状态 前置、后置条件必须是系统能检测到的,-24-,3.2基本路径-1,用例的基本路径代表了本用例所要达到的主要目标 以执行者与系统进行交互的方式进行描述,-25-,3.2 基本路径-2,-26-,3.2 基本路径-3,-27-,3.4用例关系在文档体现,包含关系 主用例直接包含子用例 扩展关系 子用例通过主用例预定义的扩展点与主用例建立关联 泛化关系 子用例全盘继承主用例的所有要素，同时可以增加自己的要素，可以考虑通过不同的字体来描述,-28-,旅店预订系统精化后的用例模型,-29-,包含关系的描述,-30-,扩展关系的描述,-31-,3.5用例文档的其它部分,最后回到考勤信息,-33-,考勤系统要点-1,编辑和管理员工的考勤信息，并通过考勤信息来计算工资信息 三类员工：小时工、普通员工和销售人员 小时工和普通人员每天需要记录自己的考勤信息 销售人员不需要考勤，而是记录每天的订单信息 员工可以查看自己已经确认的工资和以前的工资和考勤信息；而已经提交的考勤信息不允许修改,-34-,考勤系统要点-2,系统在每个周五和月末自动计算员工工资 根据考勤信息(销售人员为销售记录)和工资级别