研发专家讲坛之五—NC软件研发过程及方法模型方法与技术教案.ppt

流程示例-出库传应收 流程示例-出库传应收 问题2：如何确定设计过程及方法 影响因素 现有方法的影响 现有开发语言与平台 开发方法的影响 上下游的影响 产品的规模 产品的阶段 产品的特性[业务、技术、交互……] 关于设计方法 每种方法的适应情况均有其适用场景 每种方法都有一些最佳实践 每种方法都有缺点 可以使用混合方法 敏捷 计划 软件过程连续光谱 问题3：如何形成领域模型 如何形成领域模型 详细需求 测试用例 设计文档 源代码 设定在理想环境下展开工作通常不太现实，需要立足现在达到想要的结果 改进式创新，而不是破坏式创新 * * “UML includes several implicit links between these two sets of diagrams (e.g., sequence and collaboration diagrams can use the entities defined in class diagrams). However, UML does not emphasize any first-class and compact way of describing large-scale units of behavior that emerge from the collective efforts of many system components (e.g., transactions spanning a network).” [Am99-2] “There exists a large conceptual gap between use cases and their realization in terms of behavioral diagrams where the system’s internals are refined with sub-components. Reasoning about this gap and the big picture using the current UML diagrams is often puzzling since much mental effort is required to integrate many details from many diagrams of different styles.” [Am99-2] 人工活动 需要人在系统中完成的任务 例如审批 自动任务 由系统执行的任务 例如自动生成凭证 手工任务 需要人在系统外完成的任务 例如电话预订等 子流程 一组可以拆分活动组合 * 业务分析角色及产生的文档 领域架构设计 关键活动 架构设计 领域分析和设计 角色 设计架构师 主设计师 应用架构师 需求分析师 成果 领域架构设计 公共框架设计 参考/输入 已有成果的参考 业务模型 新技术或模式 技术 架构设计模式 领域驱动设计 分析模式 EA技术等 领域架构设计元模型 建模元素 架构风格 业务处理过程 架构模型 领域视图 领域视点 关键特征 领域设计要求等 领域设计 业务组件内的领域模型开发组件设计 实体/值对象 操作/活动 服务 事件等 数据库结构设计 表结构 键及索引 关键算法/SQL语句 考虑扩展性等设计要求 性能、灵活性、扩展性、伸缩性等 领域设计元模型 建模元素 业务组件 实体 值对象 服务 业务活动 事件等 领域模型 实体组件设计器 领域模型 服务/活动组件设计器 Factory和Repository的关系 Factory负责处理对象生命周期的开始，而Repository帮助管理生命周期的中间和结束。 重建一个已存储的对象并不是创建一个新的概念对象。从领域的角度看， Factory和Repository具有完全不同的职责。 Factory负责制造新对象，而Repository负责查找已有对象。 Repository应该让客户感觉到那些对象就像驻留在内存中一样。对象可能被重建，但是它是同一概念对象，仍旧处于生命周期的中间。 这种职责上的明确区分还有助于Factory摆脱所有持久化职责。Factory的工作是用数据来实例化一个可能很复杂的对象。如果产品是一个新对象，那么客户将知道在创建完成之后应该把它添加到Repository中，由Repository来封装对象在数据库中的存储。 服务 服务分层 应用层 应用中需要的不涉及业务规则及状态改变的服务 领域层 处理业务规则，改变业务状态 平台层 没有任何业务含义 示例 资金转账 应用层 资金转账应用服务 读取服务（如XML请求） 发送消息给领域服务，要求处理 监听确认信息 决定用基础设施层的服务发送通知 领域层 资金转账领域服务 必