实验2 用例分析.ppt

实验2 用例分析 实验要素 迭代周期1的选取 模型的组织 实体类的完备性 交互图：正确性、完备性、可行性等 参与类类图（VOPC）：正确性、完备性等 …… 实验2：用例分析-题目要求 在实验1所构建的用例模型基础上，完成分析过程 确定第一个迭代周期（提供该周期的用例图） 简单描述系统的备选构架，并将分析过程所发现的类（对象）放入到相应的层次结构中 对实验1中已经完成用例规约的一个用例进行用例分析： 完成该用例的参与类类图（VOPC类图） 描述一个基本路径的交互 考勤系统第一个迭代周期 两个用例 维护个人考勤(简化版-只考虑基本路径) 计算工资(简化版-只考虑临时工) 模型组织：4+1视图 模型组织：按备选构架组织 按MVC构架寻找相应的对象（类） 边界类 Boundary Classes 控制类 Control Classes 实体类 Entity Classes 领域模型 模型组织：由用例实现来组织 用例分析过程围绕着用例完成，通过用例实现(use-case realization)来组织 该用例实现与用例模型中用例之间的关系 跟踪图 该用例的实现过程交互图 基本路径 备选路径 该用例的参与类类图 VOPC类图 边界类和控制类 在分析的前期，一般情况下 为每对参与者/用例定义一个边界类 为每个用例定义一个控制类 在用例分析过程中，可以根据实际情况进行灵活分析，如： 在维护个人考勤时存在两个非常独立的路径：记录考勤(分创建和提交两个阶段)、查询考勤 可以每个路径定义一个边界类和控制类 考勤系统迭代周期1边界和控制类 实体类 难点！也是用例分析的重点 实体类体现系统的核心业务数据 识别出用例规约中的名词和名词短语，将它们作为实体或属性的候选对象 来自用例规约 名词性短语 系统的关键抽象 实体类的完备性 实体类是后续数据库设计的基础 关键抽象 关键抽象(Key Abstractions)即在需求中揭示的系统核心概念，系统必须处理的信息 关键抽象的来源 领域知识 需求 词汇表 领域模型(业务模型) 本系统迭代周期1实体类类图 实体类的典型问题 “系统”实体类 系统是一个什么样的实体类？事实上，它应该是一个全局的控制类，负责所有的核心流程，成了上帝类！它掩盖了实际的业务流程， 使得分析过程失去意义！ “数据库系统”实体类 在您做这个系统之前已经有现成的数据库吗？ 如果有的话，那么它应该作为外围系统，对于本系统而言就应该是一个接口 如果没有，您就应该做数据库设计，而这是在分析之后工作的，分析是还没有数据，又谈何数据库接口呢？ “系统”实体类带来错误的交互图 记录考勤-添加新考勤 记录考勤-提交考勤 记录考勤-VOPC类图 计算工资(小时工)-交互图 计算工资VOPC图 * * 思考：为什么？ 用例分析是面向对象的分析阶段，其产生的工件应该都组织在逻辑视图（Logical View）中