4+1视图方式的销售管理系统架构.docVIP

销售管理系统项目架构设计文档 版本1.0  文档创建信息 产品项目名称 销售管理系统（SMS） 产品项目编号 产品经理 项目经理 创建日期 总页数 正文页数 附录页数 文档修订记录 修改日期 修改的章节 修改类型 修改描述 修改人 审核人 版本号 修改类型分为 A – ADDED（增加） M – MODIFIED（修改） D – DELETED（删除） 目 录 引言 编写目的 系统描述销售管理系统架构概况，结合图例说明架构设计的原理、功能、实现方式、如何应用以及如何应对需求变化。本文档针对系统架构设计实现的开发人员应着重阅读架构设计原理实现方式等部分说明描述，针对应用开发人员应着重阅读架构如何应用，功能实现以及如何应对需求变化部分。 背景 项目中文名称：销售管理系统 项目英文名称：SMS1.0（Sale management system) 项目任务提出者：中企动力销售管理部门 项目开发者：CE信息化部门 项目最终用户：中企动力商务人员及商务管理者 涉众怎样使用文档 本节列出了的最重要的涉众角色以及这些角色如何使用文档包来满足其关注点。 项目新成员：阅读，以便进而了解编档视图的方式。阅读系统概述和系统 项目经理：为了协助项目计划，应该强调，因为它能帮助定义工作任务，并确认必须是合格的。查阅部署视图，以便了解必须获取的硬件环境，该硬件环境将协助确认需要建立的测试环境。 性能工程师：查阅视图，以便了解可能的并发单元。查阅部署视图，以便了解如何将软件分配到硬件。安全性分析人员：查阅部署视图，以便了解系统操作的物理环境。 维护人员：查阅视图，以便了解现有实现单元和各实现单元的责任范围。查阅部署视图的顶层视图包，以便了解每个软件单元的分配位置。查阅视图，了解将代码单元分配到开发环境的方式尤其应该查阅每个视图和每个接口规范中的基本原理。 客户：查阅系统概述。查阅部署视图以便概括性地了解如何为执行系统任务对系统进行组织，并对构建系统所必须完成的工作进行认识。 用户：用户通常不需要查阅构架文档，但是，他们能阅读视图中的行为规范，以便了解系统各部分的行为方式。开发人员：查阅视图，了解系统中的基本软件单元；查阅，；查阅视图，了解开发人员可以使用哪些软件；查阅 目标客户数据的采集录入，解决重复查找资料的问题,提高工作效率 目标客户资料的规范应用，解决客户“骚扰”问题 意向客户、机会客户的业务跟进与业务保护, 规范商务体系管理 商务员工的业务工作跟进记录与分析，提供人资绩效数据 客户转化分析与业务预测 商务体系任务、计划的下达与跟进管理 《中企动力销售管理系统1.0产品项目规划方案》 《中企动力销售管理系统1.0产品需求文档》（初稿） 《销售管理系统非功能需求说明书》 系统架构设计概述 本系统使用vs2005系统开发，数据库为sql server2005。使用组件化开发方式，数据库使用分布式数据库部署方式，达到可以通过扩展部署范围持续提高数据库的访问性能。应用使用负载均衡方式部署，达到可以通过扩展部署范围持续提高应用的访问性能。数据库的增、删、改均使用xml数据请求模型完成，所有的查询均使用sql语句完成。辅助开发工具使用数据库结构到xml数据请求格式的映射工具。 为了保持可以快速增加功能发布层，对其它系统提供本系统的业务功能，业务规则验证层与业务规则验证层使用统一返回格式进行交互。 此开发层次模型是依据划分业务领域和需求分层理念进行规划，可以支持需求与开发并行开始，系统结构清晰，便于后期应用维护，并容易行成统一的需求分析、设计、开发模式，弱化人员能力对于开发的影响，可以更有效的控制开发过程。但可能出现不同业务领域相互交互时的数据库事务同步问题，在本结构中纳入事务补偿机制，解决此问题。 架构视图模版 架构视图采用4+1视图的方式,参照IBM架构文档格式。 [/developerworks/cn/rational/06/r-wenyu/index.html] 逻辑视图: 根据功能需求进行初步设计，进行大粒度的职责划分。逻辑视图关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的辅助功能模块；它们可能是逻辑层、功能模块等。 开发视图: 软件架构的开发视图应当为开发人员提供切实的指导。任何影响全局的设计决策都应由架构设计来完成，这些决策如果漏到了后边，最终到了大规模并行开发阶段才发现，可能造成程序员碰头儿临时决定的情况大量出现，软件质量必然将下降甚至导致项目失败。 其中，采用哪些现成框架、哪些第三方