UML系统用例及用例关系.ppt

知识回顾—需求获取教学内容需求是客户在项目立项时就有的一个远景，客户需求将决定在整个项目中需求承办方具体做些什么，即承办方的任务。承办方在明确了需求后，就会开始后期的设计、开发、测试、部署等工作。在需求获取过程中，主要需要弄清楚三个问题二用例图相关概念介绍2.用例图的作用参与者，Actor
关键词：边界
参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物要点
系统外
参与者代表在系统边界之外的真实事物，并不是系统的成分
系统边界
参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定
有意义交互的任何事物
人、外系统、外部因素、时间识别参与者思路参与者的类型和职责参与者之间的关系用例1用例2识别用例识别用例要点可观测：用例止于系统边界边界---Boundary结果值：有意义的目标系统执行：结果值由系统生成参与者观测：用户观点而非系统观点要点：用例粒度用例粒度-1用例粒度-2“四轮马车”
C(Create)
R(Read)
U(Update)
D(Delete)
所有业务最终会成为CRUD？
CRUD能为Actor提供价值？
CRUD掩盖业务，锐变成关系数据库的建模：
“系统就是数据的增删改查”
关心数据的存储和维护，反而忽略了用户的目的
用例粒度-4用例粒度-5用例的命名用例关系包含关系1包含关系2包含关系包含举例1包含举例2扩展关系1扩展关系2扩展关系2基用例路径本身是完整的
可能是一条扩展路径
扩展路径步骤多
扩展路径内部还可以有扩展点－扩展之扩展
扩展路径未定或容易变化－分离以“冻结”基用例
基础用例可以单独存在，但在一定条件下，他的行为可以被另一个用例作为扩展扩展举例泛化关系泛化包含用例与扩展用例的区别用例关系：扩展VS.泛化小结思考思考1：识别参与者？思考2：获取需求-考勤卡应用程序思考2：识别参与者：考勤卡系统思考2：识别用例：考勤卡系统思考2：考勤卡系统思考3：识别用例思考3：识别用例-正确下一讲内容