U8总体分析设计模板.doc

XXX产品
总体设计说明书

作者：
版本号：
时间：
版权所有：用友软件股份有限公司
UFIDA Corp. Ltd.
目 录
1. 变更说明 4
2. 引言 4
2.1. 编写目的 4
2.2. 背景 4
2.3. 定义 4
2.4. 参考资料 5
3. 设计原则 5
4. 总体结构设计 5
4.1. 需求规定 5
4.1.1. 业务角色 5
4.1.2. 业务场景 6
4.1.3. 业务流程 7
4.2. 总体解决方案 7
4.3. 总体结构 8
4.3.1. 业务场景实现 9
4.3.2. 模块1设计 10
4.3.3. 模块2设计 11
4.4. 组件部署 11
4.5. 开发环境 11
4.6. 运行环境 12
4.7. 网络安全及软件保护 12
5. 总体功能设计 12
5.1. 功能设计 12
5.1.1. 功能清单 12
5.1.2. 业务组件清单[可选] 12
5.2. 数据结构概要设计 12
5.2.1. ER图 12
5.3. 外部接口详细设计确认 13
6. 公共平台设计 13
6.1. 基类设计 13
6.2. 公共组件设计 14
6.3. 平台设计 14
7. 容错处理 14
7.1. 出错信息 14
7.2. 系统维护设计 15
8. 安装 15
9. 测试部分 15
9.1. 测试指南 15
9.2. 集成策略 15
9.3. 特殊考虑 15
10. 扩展策略 15
11. 其他非功能特性 15
12. 设计路标 15
13. 附录 16

1. 变更说明

序号
变更位置
变更内容说明
变更人
变更日期
1
4.4.8.2改进功能
补充“凭证并发制单”

2005-07-04
2
4.6.2.2改进功能
删掉：执行入库操作时，检查人才库中是否有这些人员的简历，如果有提示是否删除人才库中的简历。

2005-07-06
3
4.3.2.1新增功能
发一个只能五家公司进行合并的演示版

2005-07-08
4
4.3.2.4注意事项
合并报表升级注意事项增加第8条

2005-07-08
5
7.3零售管理系统环境要求
新增零售管理系统环境要求

2005-07-11
6
8.2零售管理系统安装说明
新增零售管理系统安装说明

2005-07-11
7
4.10.3注意事项
新增零售管理注意事项

2005-07-11
8
4.9.1.1改进功能
补充OA相关功能模块分类调整

2005-07-12

2. 引言

2.1. 编写目的
[说明编写这份总体设计说明书的目的,指出预期的读者。
本文档指导详细设计的内容。]
2.2. 背景
[说明：
a. 待开发软件系统的名称；
b. 列出此项目的任务提出者、开发者、用户。]
2.3. 定义
[列出本文件用到的专门术语的定义和外文首字母组词的原词组。]
2.4. 参考资料
[ 列出有关的参考文件,如：
a. 本项目的经核准的计划任务书或合同,上级机关的批文；
b. 属于本项目的其他已发表文件；
c. 本文件中各处引用的文件、资料,包括所要用到的软件开发标准。
列出这些文件的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。]
3. 设计原则
[可选][对于设计的原则性规范，包括对详细设计的指导和规范。因为总有些东西在后面的设计中没有办法描述得面面俱到。有了基本的原则，可以在发生争议时，人员变动时成为决策的依据。尽量贴近本产品的设计，如果确实没有，可以忽略。下面是举例。]
l 界面与数据的分离，通过对象模型，将界面与数据分离，同时将界面之间的耦合度也降低以实现界面的复用。
l 业务与技术分离：将软件的业务资源和技术分离开来，使得软件对于业务的扩展是开放的，同时对于技术的迁移也是开放的。业务可以给予不同的技术实现，同样的技术可以实现其他业务。
l 所有的复杂的业务逻辑应该进行完整地分析，设计和实现形成一个个具有通用性和代表性的单元，同时对需求进行某些范围内的估计，在设计时留有一些余地。因为一个简单需求的变化很可能导致整个设计结构的崩溃，所以必须加以控制。
l OCP原则
4. 总体结构设计
4.1. 需求规定
4.1.1. 业务角色
[按照下表去描述系统涉及到的所有角色，描述它们的重要性，它们的特点，可以根据需要，建立自己的表格。]
USER ROLE CODE
USER ROLE NAME
ROLE CATEGORY
ROLE IMPORTANCE
ROLE DESCRIPTION
QUESTION
UR1
客户执行层
External
B
客户的业务部门关心部门级的决策信息，甚至一些实时和明细的信息
这几天是多少
怎么样?
UR1-1
客户财务执行层
—
—
包括财务部门、会计部门
财务是多少，怎么样
UR1-2
客户营销执行层
—
—
企业内部供应链上的相关部门
营销是多少，怎么样?
UR1-3
客户人力资源执行层
—
—
企业人力资源相关部门
人力怎么样，是多少？
UR2
客户决策层
External
A
客户企业领导人对企业级信息的需求跨越了多个部门，大粒度的信息。新增加了对企业管理知识的需求，从传统的经验知识型向理智科学型转变
最近有异常吗？怎么解决？
UR2-1
客户决策者
—
—
决策者实际上并不直接接触系统，而是依赖于UR2-2、UR2-3和UR2-4整理的信息。
异常情况怎么解决？

表1 角色分类
4.1.2. 业务场景
SCENARIO ID
US1
SCENARIO ROLES
(UR2-3), 包括了UR1的角色
NAME
用户设计预算编制流程
IMPORTANCE
A
PRE SCENARIOS
无
DESCRIPTION
某用户指定预算编制包括战略规划、体系编制、体系下发、预算编制、数据校验、各级审核、汇总上报、上级审批（调整）、最终发布等过程。
FEATURE

SCENARIO ID

SCENARIO ROLES

NAME

IMPORTANCE

PRE SCENARIOS
无
DESCRIPTION

FEATURE

表2 业务场景表
4.1.3. 业务流程
[可选][对流程性强的产品，不仅要列出应用场景清单，而且需要明确关键业务流程。业务流程需要划分阶段的，在图的左侧划分。
如图：]

图1 XX业务关系图
4.2. 总体解决方案
[可选][网络拓扑图（Topology）。网络拓扑图的主要目的是让读者明白系统的网络概况。了解产品是C/S还是B/S应用。对于多级集团企业，如何支持总部与分子公司和办事处的网络通信。对于单一企业，明确其内部网络环境的划分和外部网络环境的划分，以及它们之间的联系。]

图 2 网络拓扑图
[ 根据产品策略提出产品总体解决方案，并对方案进行必要说明，对于重大问题要详细说明解决方案。
对总体解决方案中用到的核心技术逐一介绍。核心技术包括自己开发的核心技术和必须使用的第三方的核心技术,要求详细设计师和开发人员必须使用。比如MSMQ，ADO.NET，。对于常见的数据库平台等可以不作说明。]
4.3. 总体结构
[使用结构图。使用结构图重点要标出系统实现方面有哪些模块组成，这些模块之间的接口协议是什么，以及接口传输的内容语义。最好能够在图上标出模块清单中的模块标号和接口清单中的接口标号。]

图 3 使用结构图
[ 列出本产品的子产品（模块），可以用图/表方式，并对这些模块命名，这些命名是目录/包、数据库等命名的基础.模块的含义是指：根据系统运作的设想而划分的具有明确职责的单元，他不根据用户领域问题的具体流程去划分，但是能够解决用户的领域问题。]

模块编号

模块名称

模块依赖外部接口编号

模块对外接口编号

模块职责
请给出清晰的定义
模块编号

模块名称

模块依赖外部接口编号

模块对外接口编号

模块职责
请给出清晰的定义

表 3 模块表

接口编号

接口名称

模块1编号

模块2编号

接口内容语义
请给出清晰的定义，该模块的详细设计师能够按照此描述了解该接口的大致情况，可以构思实现方案。

批量/单条

通信协议/技术

性能要求
1000行/秒
备注

表 4 接口表
4.3.1. 业务场景实现
[针对每一个应用场景，用Sequence Diagram的形式画出实现方案，图中有前面归纳的角色出现，如果某个场景不需要画，请说明原因。
模块之间的协作图(不是类！) ]

图 4

图 5

4.3.2. 模块1设计
[分模块介绍主要功能以及解决用户的主要问题。
该模块内部的实现机制可以进行描写，但是需要你根据情况判断最核心的部分是那些，尽量少把详细设计的内容放在这里。]
[可选]
[功能明细清单：
核心工作原理/理论/技术：
内部模块清单：
数据访问层：
应用层（规则层）：
表示层：
分析模型示意图：]
4.3.3. 模块2设计
[分模块介绍主要功能以及解决用户的主要问题。
该模块内部的实现机制可以进行描写，但是需要你根据情况判断最核心的部分是那些，尽量少把详细设计的内容放在这里。
[可选]
功能明细清单：
核心工作原理/理论/技术：
内部模块清单：
数据访问层：
应用层（规则层）：
表示层：
分析模型示意图：
模块运行组合方案及模块组合控制关系，如启用、期初、结帐等]
4.4. 组件部署
[UML的Deployment View。描述部署节点、部署单元（组件）的分布关系。标注出组件之间的关系和通信。]

图 6 部署图

4.5. 开发环境
[ 介绍开发语言和工具（包括版本）及相关规范
分析、设计方法和工具及相应规范
开发和测试环境，如数据及版本、操作系统及版本]
4.6. 运行环境
[ 简要地说明本系统的运行环境支持（包括硬件环境和支持环境）的规定
如硬件
操作系统及版本
数据库及版本
网络]
4.7. 网络安全及软件保护
[ 介绍本系统的网络安全方案和软件保护解决方案（由于保密要求，这里只介绍解决方案）]

5. 总体功能设计
[总体功能设计是从用户能够使用的功能的角度描述产品
5.1. 功能设计
5.1.1. 功能清单
[ 列出菜单结构。]
5.1.2. 业务组件清单[可选]
[列出业务组件的文件结构设计。包括关键组件的文件，配置文件，其它信息。]
5.2. 数据结构概要设计
[分组件描述实体间关联关系，包括基本档案和业务数据]
5.2.1. ER图
[ 分组件列出业务组件清单]
5.3. 外部接口详细设计确认
[ 设计本组件与其他组件的接口关系，以及本组件与平台接口关系，需要明细到具体调用接口，各组可以将本组对外提供的服务设计为统一接口类
对外提供的接口]
序号
功能说明
提供的服务

语义

表 5 对外服务接口表
外部提供的接口
组件名
功能说明
提供的服务
平台

明晰
产品组

语义

表 6 外部服务接口表
6. 公共平台设计
[列出本系统公共平台的层次结构]
6.1. 基类设计
[列出本系统提供的所有基类（对于由Visual Basic开发工具的代码，每个Class都为基类），并逐个描述他的功能及使用说明，对复杂基类的设计见UML分析设计模型]

图 7 基类设计

6.2. 公共组件设计
[列出本系统提供的所有公共组件，并逐个描述他的功能及使用说明，对复杂公共组件的设计见UML分析设计模型，涉及的数据库设计见系统数据结构设计]
6.3. 平台设计
[列出本系统提供的所有组件，并逐个描述他的功能及使用说明，每个平台的详细设计见ROSE分析设计模型，涉及的数据库设计见系统数据结构设计]

7. 容错处理
7.1. 出错信息
[ 用一览表的方式说明每种可能的出错或故障情况出现时,系统输出信息的形式、含义及处理方法。]
7.2. 系统维护设计
[ 说明为了系统维护的方便而在程序内部设计中作出的安排,包括在程序中专门安排用于系统的检查与维护的检测点和专用组件。]

8. 安装
9. 测试部分
9.1. 测试指南
9.2. 集成策略
9.3. 特殊考虑
10. 扩展策略
[系统能够支持那些方面的扩展，扩展的方案是什么。]
11. 其他非功能特性
[交互性、界面、效率等
关键性能要求、相应速度、并发要求、传输速度。在这里可以单独列出易用性、效率、国际化等作为单独的一级标题，专题讨论。]
12. 设计路标
[1. 手条件限制本版不能解决的问题
2. 未来几个版本的规划，以及决策]
13. 附录
参考文献