第五章协同过程模型实例精要.ppt

内容安排 1. 协同过程模型 协同过程模型 迭代一：确定参与者和事件（续） 提取事件----需要注意的问题 建立事件表----需要注意的问题 初始阶段首次迭代检查点 迭代二：用例分析与初步建模 迭代二：用例分析与初步建模（续） 确定系统用例的两个切入点 确定Use Case时需要注意的问题 迭代二：用例分析与初步建模 勾画用例路径 用例路径分类 用例路径分类 用例路径描述的视角 用例路径描述的视角 勾画用例路径 评估迭代二 迭代三：细化基本路径和准备系统初始构架 细化用例基本路径 评估迭代三 内容安排 协同过程模型 协同过程模型 挖掘类 类的类型 挖掘类（续） 对象图 分析模型 评估迭代一 评估迭代一 协同过程模型 用户接口原型开发的目标 需要注意的问题 收集用户接口需求 确定参与者和用例边界 确定参与者和用例边界 提取用户接口需求 分析用例耦合 构造UI原型 从原型中获取信息 评价UI原型 评价UI原型（续） 评价UI原型（续） 我们从原型中获取了什么？ 评估迭代二 评估迭代二（续） 协同过程模型 在项目当前阶段，动态建模的作用 动态建模的依据 UML四种动态模型----顺序图 顺序图（续） 顺序图与基本路径 UML四种动态模型----顺序图 从顺序图中获取什么 UML四种动态模型 ----顺序图 应用矩阵 事件/频率矩阵 事件/频率矩阵（续） 事件/频率矩阵（续） 应用矩阵 对象/位置矩阵 对象/位置矩阵（续） 对象/位置矩阵（续） 应用矩阵 对象/容积矩阵 对象/容积矩阵（续） 应用矩阵 评估迭代三 评估迭代三（续） 协同过程模型 “最终构架”部分包括三方面内容 选择构架模式----三个逻辑层模型 逻辑层与物理层（续） 逻辑层与物理层（续） 选择构架模式----六个逻辑层模型 层间如何通信 应用程序构架 评估迭代四 内容安排 协同过程模型 迭代一：数据库设计与创建 迭代一：数据库设计与创建 将类映射到表 存储过程和触发器 存储过程和触发器（续） 存储过程和触发器（续） 应用程序的六层模型 数据转化服务和数据访问服务层 （续） 数据转化服务层 ICrud接口 评估迭代一 评估迭代一（续） 协同过程模型 迭代二：组件设计与创建 应用程序的六层模型 业务上下文服务层 业务上下文服务层（续） 业务规则服务层 业务规则服务层（续） 建立各层间的动态模型 迭代二：组件设计与创建（续） 评估迭代二（续） 迭代二：组件设计与创建（续） 协同过程模型 迭代三：网络设计与创建 内容安排 协同过程模型 协同过程模型 存储过程和触发器违背了面向对象的原则和概念 触发器使用依赖DBMS的语言编写，如Oracle的PL/SQL。无法在数据库平台上移植 触发器包含了应用程序所特有的商业规则，而且这个规则不仅约束指定DBMS语言，而且约束数据访问语言（SQL） P* 使用存储过程和触发器的基本原则 在遇到性能问题时再使用 需要处理非常复杂的商业规则时，才使用 决策过程的底线是达到应用程序的性能目标 这种从程序代码到数据库代码的迁移并不简单，需要花费一些时间 P* 数据转化服务 将业务层的请求转化为合适的语言（SQL） 数据访问服务 通过给定访问的API（如ADO）传送合适语言 数据库服务 表示物理意义上的数据库技术（如Oracle） 提供传统的用户界面技术（Windows等） 表示服务 提供语法和上下文编辑 业务上下文服务 实现业务规则 业务规则服务 P* 包装数据转化服务层的方法 使用一个类，其中对每一个逻辑服务请求（例如，检索指定日期之后的所有订单）都有一个公共的操作 优点：在系统中产生较少的类 缺点：可能会产生一个庞大的类，这不符合“类只做一件事而且要把这件事做好的”原则 为每一个业务类使用一个数据转化类。例如对应于Customer的CustomerDT(DT代表数据转化)。 优点：更加面向对象，为较小的类提供了高度的内聚性 缺点：系统中的类的数目太多 P* 包含业务类，诸如Customer，Order等 处理大部分的工作流，并提供易于使用的对象接口 与数据转化层的其它类通信 业务规则服务 (BRSVC.DLL) 包括与业务类一一对应匹配的转化类 如 CustomerDT 和 OrderDT 等 建立SQL语句，并将其传递给数据访问服务层 数据转化服务 DTSVC.DLL 包括一般的利用ADO的SQL访问操作 如 DARetrieve、DAQuery 等 对于 DARetrieve 的请求，将随查询结果返回一 个字符串数组 数据访问服务 DASVC.DLL P* CustomerDT Customer ICrud 接口 .getInfo() .Insert() .Delete() .Upda