SElecture07 1面向对象的设计开发2用例建模.ppt

(4)读图小结 通过以上几部分的讲解，不难得出棋牌馆用例图所表示的含义。这张用例图首先定义了三个基本用例：预订座位、安排座位和处理结账。 客户通过Internet启动“预订座位”用例，在“预订座位”用例的执行过程中，将“检查座位信息”（被包含用例），如果没有空闲的座位或满意的座位，可以选择进入等候队列，这样就将启动扩展用例“处理等候队列”。 总台服务员在客户到棋牌馆时，启动“安排座位”用例，在执行过程中，将启动被包含用例“检查座位信息”。 当客户要离开棋牌馆时，总台服务员将启动“处理结账”用例，并且定义了两种“收款”用例，一个是“处理现金结账”，另一个是“处理银行卡结账”，而后一个用例将通过与外部系统“银联POS系统”交互来完成。 -*- -*- 用例关系：扩展 VS. 泛化 采用不同关系，文档结构不同 收集更多的需求 -*- -*- 寻找新关系 Login Change password -*- -*- 修订用例文档 其余略 -*- -*- 重构后的用例图：考勤卡系统 -*- 4.2为什么要对用例进行分类 用例和开发周期 开发周期是围绕用例的需求来组织的 一个开发周期要被指派一个到多个用例，如果完全版本的用例在一个开发周期中处理起来太复杂的话，那就采用简化版本的用例 开发周期 开发周期 开发周期 用例A -简化版本 用例A -完整版本 用例B 用例C -*- 用例分类原则 用例分类的一个基本原则 高级别的用例是那些对系统核心体系结构影响最大的用例 提高用例级别的特性： a. 对体系结构设计有重要影响的用例，如在领域层中增加多个类的用例或者需要持久化的用例 b. 不需要花费很多努力就可以从中获得重要信息和线索的那些用例 c. 含有开发风险、时间紧迫或功能复杂的用例 d. 涉及到重要技术研究或者新技术和高风险的用例 e. 代表主要的在线业务流程的用例 f. 能产生直接经济效益或者降低成本的用例 -*- 用例分类实施策略(1) 可以使用一个简单的但是有些不精确的分类方法，如将用例划分成高、中、低三个等级 -*- 用例分类实施策略(2) 依照上述的影响用例级别的特性给用例打分（用例也可能带有权值 -*- 用例的组织 对用例进行分包 让用例图能够更为清晰地表现出系统的业务逻辑关系和层次 对系统进行模块的分割，这将影响到今后的开发和系统的最终表现形式 常见的分包方式 按参与者分包 按主题分包 按开发团队分包 按发布情况分包 可以先按主题分包，主题内再按开发团队和发布情况分包 -*- 补充需求规约Supplementary Specification 补充需求规约Supplementary Specification 非功能需求(URPS) 可用性（Usability） 可靠性（Reliability） 性能（Performance） 可支持性（Supportability） 设计约束 用Oracle数据库平台，用PB开发… 软件必须符合ISO×××标准 …… 本质上不是需求，只是从商业、行政、技术上的约束 词汇表Glossary 描述数据 -*- 题外话：何时适用用例建模 用例是从参与者角度捕获系统功能，当系统只有一个或者没有参与者时，显然它们不是非常有效的 用例捕获功能需求，因此它们对于系统的非功能需求不是有效 当遇到下述情况时，用例是需求捕获的最好选择 系统由功能需求所主导 系统具有很多类型的用户，系统对他们提供不同的功能 系统具有很多接口 当遇到下述情况时，用例是一个糟糕的选择： 系统有非功能需求所主导（如：google） 系统具有很少的用户 系统具有很少的接口（非内部功能） 如：嵌入式系统、算法复杂但接口少的系统等 -*- 用例和OO “发明”于OO的环境（Ivar Jacobson） 从外部Actor的角度描述系统功能（和对象的消息类似） 不暴露内部结构 OO设计的最好开始，是OO技术进入第二代的标志 -*- 下一步？ 需求 用例 面向对象 分析设计 结构化 分析设计 其它方法 自己的 土方法 系统 * * * * 系统边界问题：业务建模 定义业务活动，识别相关的业务参与者 有意义的系统交互：图书馆、读者（感兴趣的，用户所关心的，要解决的）， 如系统的打印功能，与打印机的交互，这些交互已经被别人解决了，我们并不需要考虑细节 是责任边界，非物理边界 * 1、actor 是pig actor 的泛化(generalization) 2、此观点得到来自于Rational Rose 的官方支持，因为Rose 完全赋予了用户画出这种use case 图的能力。 3、Rational 只是默许用户这样做，但目前还没有迹象表明他们鼓励用户这样做。我们或 许可以期待在将来的UML 版本中，以明确的方式规定actor 完全