uml用例建模.pptVIP

* 是include还是extend * -*- 包含关系误用 -*- 泛化关系 同一业务目的不同技术实现： 一个用例可以特化另一个更普通用例（更普通用例泛化特殊用例） UML 1.5: 用例间的泛化关系表明子用例包含父用例中定义的所有属性、行为序列和扩展点，并且参与父用例中所有的关系 -*- 重构后的用例图：POST -*- 用例关系的准则 不要过度使用用例关系，更不要将用例关系用到编程当中。用例的目标是澄清需求。 用例泛化：如果一个用例有几种变体，那么就用抽象用例建模公共的行为，再特化每种变体。 用例包含：如果一项用例包含有一段定义良好且有可能用在其他场合的行为片段，那么就该为该行为定义一项用例，并把该用例包含在原始用例中。 用例扩展：如果用可选特性来定义一项有意义的用例，那么要把基行为建模为用例，并用扩展关系来增加特性。 包含关系和扩展关系：都可以把行为分解成较小的片段。但是，包含关系隐含着被包含行为是配置系统的一个必要的部分，而扩展关系暗示着没有增加的行为的系统也是有意义的。 -*- 4.2为什么要对用例进行分类 用例和开发周期 开发周期是围绕用例的需求来组织的 一个开发周期要被指派一个到多个用例，如果完全版本的用例在一个开发周期中处理起来太复杂的话，那就采用简化版本的用例 开发周期 开发周期 开发周期 用例A -简化版本 用例A -完整版本 用例B 用例C -*- 用例分类原则 用例分类的一个基本原则 高级别的用例是那些对系统核心体系结构影响最大的用例 提高用例级别的特性： a. 对体系结构设计有重要影响的用例，如在领域层中增加多个类的用例或者需要持久化的用例 b. 不需要花费很多努力就可以从中获得重要信息和线索的那些用例 c. 含有开发风险、时间紧迫或功能复杂的用例 d. 涉及到重要技术研究或者新技术和高风险的用例 e. 代表主要的在线业务流程的用例 f. 能产生直接经济效益或者降低成本的用例 -*- 用例分类实施策略(1) 可以使用一个简单的但是有些不精确的分类方法，如将用例划分成高、中、低三个等级 -*- 用例分类实施策略(2) 依照上述的影响用例级别的特性给用例打分（用例也可能带有权值 -*- 用例的组织 对用例进行分包 让用例图能够更为清晰地表现出系统的业务逻辑关系和层次 对系统进行模块的分割，这将影响到今后的开发和系统的最终表现形式 常见的分包方式 按参与者分包 按主题分包 按开发团队分包 按发布情况分包 可以先按主题分包，主题内再按开发团队和发布情况分包 -*- 基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3 详细、完整地描述需求 进行用例阐述 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包 5. 确定参与对象 -*- 确定参与对象 确定每个Use Case的参与对象； 参与对象对应于问题空间的主要概念→形成术语表； 参与对象的确定产生了最初的分析模型： 对象的描述、属性可由用户评审； 作为整个分析模型与用户／客户衔接的部分，通常不会用完整的分析模型“烦恼”用户。 -*- 确定参与对象的试探法 开发人员或用户为理解Use Case所必须阐明的术语； Use Case中的常用名词（如，事件）； 系统需要跟踪的现实世界实体（如，现场工作人员、资源）； 系统需要跟踪的现实世界过程（如，紧急操作计划）； Use Case本身（如，报告紧急情况）； 数据来源或数据接受器（如，打印机）； 接口产品（如，工作站）； 总要使用的应用域的术语。 -*- 确定参与对象示例 针对前面举例的事故管理系统中的“报告紧急情况”用例，最初可能确定出以下参与对象： 调度员、紧急情况报告、现场工作人员、事件 报告紧急情况用例的参与对象见下表： -*- -*- 补充需求规约Supplementary Specification 补充需求规约Supplementary Specification 非功能需求(URPS) 可用性（Usability） 可靠性（Reliability） 性能（Performance） 可支持性（Supportability） 设计约束 用Oracle数据库平台，用PB开发… 软件必须符合ISO×××标准 …… 本质上不是需求，只是从商业、行政、技术上的约束 词汇表Glossary 描述数据 -*- 题外话：何时适用用例建模 用例是从参与者角度捕获系统功能，当系统只有一个或者没有参与者时，显然它们不是非常有效的 用例捕获功能需求，因此它们对于系统的非功能需求不是有效 当遇到下述情况时，用例是需求捕获的最好选择 系统由功能需求所主导 系统具有很多类型的用户，系统对他们提供不同的功能 系统具有很多