概要设计说明书.docx

概要设计说明书.docx

《概要设计说明书.docx》由会员分享，可在线阅读，更多相关《概要设计说明书.docx（23页珍藏版）》请在冰点文库上搜索。

概要设计说明书

密级：

秘密

系统名称：

XXXX系统

系统版本：

X.X

文档分类：

系统设计

文件编号：

XXXX系统VerX.X

概要设计说明书

XXX计算机有限公司

XXXX年X月

1.引言

1.1文档目的

简要说明编写这份概要设计说明书的目的，指出预期的读者。

本概要设计说明书的编写目的是为了说明系统总体设计的技术方案，从程序系统的设计考虑，包括系统的基本处理流程、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等内容，以向整个设计期提供关于程序系统的逻辑和数据功能实现方式的总体描述，从而作为程序详细设计或编码的基础。

设计阶段将以本文档为核心文档。

本概要设计说明书的适用读者为：

软件开发者、测试人员。

1.2项目概述

1.说明待开发的软件系统的名称

2.列出本项目的任务委托单位、开发单位、协作单位、用户单位

3.说明项目背景，叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。

如果本次开发的软件系统是一个更大的系统的一个组成部分，则要说明该更大系统的组成和介绍本系统与其它相关系统的关系和接口部分

4.保密说明：

本项为可选项，一般的软件公司都会要求对软件开发的概要设计文档进行保密，不允许被复制、使用和扩散到公司之外的范围，如果需要强调则允许做相关的保密说明

5.版权说明：

本项为可选项，若有必要，才要作有关的描述。

1.3参考资料

列出编写本报告时参考的文件（如经核准的计划任务书或合同、上级机关的批文等）、资料、技术标准，以及他们的作者、标题、编号、发布日期和出版单位。

这些文件主要包括：

⏹本软件开发所经核准的合同或标书或可行性报告等文档

⏹软件开发计划书

⏹需求分析报告

⏹测试方案（若存在初稿的话）

⏹与本项目有关的已发表的文件或资料

⏹本文件中各处引用的文件、资料，所采用的软件开发标准和规范

编号

资料名称

简介

作者

日期

出版单位

列出编写本报告时查阅的Intenet上杂志、专业著作、技术标准以及他们的网址。

网站

简介

1.4术语定义

列出本文档中所引用到的专门术语的定义和首字母缩写词、缩略语的原文，以便对概要设计说明书进行适当的解释

1.5修改记录

编号

修改内容描述

修改人

审核人

批准人

修改日期

备注

2.

系统概述

概要地介绍本软件系统，只要求提供影响设计的一般因素，不必太详细地描述大量细节，本章主要目的仅仅是使本设计说明书更加易于理解，建议根据系统设计的实际需要可以有选择地从以下方面进行概要描述：

系统实现目标、条件与限制、运行环境、需求概述

2.1系统实现目标

说明完成本项目要达到的目标，可从以下几方面考虑设计：

⏹人力与设备费用的节省；

⏹处理速度的提高；

⏹控制精度或生产能力的提高；

⏹管理信息服务的改进；

⏹决策系统的改进；

⏹人员工作效率的提高；

⏹安全可靠性的保证；

2.2条件与限制

为可选项，只要当软件系统的设计或开发受到某种特定的限制，或者可直接能影响系统设计的某种因素，这些因素可能成为系统的设计约束，他们的改变可能会影响某些需求的实现时，才需要做概要介绍。

若存在以下方面的系统约束或条件限制时，可以进行相关的阐明：

（但不限于这些）

1.为完成本软件系统应具备的特定条件、开发单位已具备的条件以及尚需创造的条件,如：

现阶段还未到位的设备、资源等需要做出相应的约束说明

2.必要时，还应说明用户及分合同承包者承担的工作、完成期限及其他条件与限制，如果用户及分合同承包者对系统的实现起到的某些作用会直接影响系统设计的成败则要特别说明

3.本系统的设计规范需要受到某些特定的行业规范的限制

4.本系统的开发需要受到用户对系统的工程化管理的某些特别的要求，包括用户规定对系统实现的全过程的变更规定

5.本系统设计工作所需的一些假定条件和必须满足的约束，如本功能的开发假定用户会熟练使用SQL语言，本功能的实现应该在某功能实现前开发完成等

6.本系统的设计可能需要使用的所有购入构件、所有适用的许可或使用限制，以及所有相关的兼容性及互操作性或接口标准的有关限制和规定

2.3运行环境

概要地说明本软件系统的运行环境的拓朴结构和布局，分别说明前、后台及网关或中间件的运行环境,应包括通讯条件、网络环境、硬件配置、软件系统等

其中硬件环境：

要求列出为运行本软件所要求的硬件最小配置：

⏹处理器的型号、内存容量

⏹所要求的硬盘空间、分区格式、相关的记录格式、设备的型号和数量、联机/脱机等

⏹I/O设备（联机/脱机）

⏹网络相关设备（型号、数量）

支持软件：

说明为运行本软件所需要的支持软件，如：

⏹操作系统名称、对应的版本号、相关的ServicePackage

⏹编译器和对应的版本号

⏹数据库管理系统和对应版本号

⏹其他支持软件

这里只要求概要的说明一下，以便帮助理解本概要设计说明书，可参考以下格式：

【前台】计算机：

IBMPC兼容机。

操作系统：

MicrosoftWindows95/97/98/2000/NT操作系统

数据库系统：

IBMDB2数据库系统（客户端）

应用软件：

XXXXXXXX（客户端）

网络：

Ethernet,TCP/IP

【后台】计算机：

IBMRS/6000

操作系统：

IBMAIX操作系统

数据库系统：

IBMDB2数据库系统（服务端）

应用软件：

XXXXXXXX（服务端）

网络：

Ethernet,TCP/IP

3.需求概述

根据系统设计的实际需要，简要介绍系统的需求情况，不必详细描述需求的具体细节，只仅仅要求能够更好帮助理解本设计说明书的内容，建议有选择地从功能需求、性能需求和运行需求进行分别描述，对于直接影响系统设计的关键或主要功能、性能以及运行要求等方面进行概要介绍，如果性能和运行需求方面对设计影响不大，则允许不必说明

3.1.总体描述

对系统的整体需求进行概述

3.2.系统角色

描述系统的用户，权限等

Actor

缩写

名称

描述

[英语简称]

3.3.系统功能

3.3.4.功能划分

对系统进行功能划分

3.3.5.用例清单

根据划分，列出各个功能模块

功能ID

功能名称

系统角色使用权限

描述

列出所有系统角色，并用√表示具有相应权限

3.4.性能和运行需求

4.总体设计

4.1设计原则

介绍本系统的结构设计原则和总体设计指导思想，主要从系统设计实现的目标来考虑，比如：

处理速度、安全保密性、可扩展性等方面进行阐述，可以使用一些套话稍做修改即可。

建议参考以下范例进行描述：

⏹数据实时性强

监控的实时性是不言而喻的。

无论实时检测还是动态显示交易汇总数据和盘中异常结果，都要求实时监控的算法尽量优化，处理简洁，这样才能真正达到实时监控的目的，为总部进行盘中稽核和及时处理异常情况提供有效的手段。

⏹可扩充性强

由于交易业务是不断扩展的，监控的指标及功能都是不断扩大或变化的，故系统必须具有良好的可扩充性。

系统设计应尽可能结构化、模块化，并与其他子系统预留相应的接口。

⏹可维护性好

由于证券市场、政策及其管理是随着整个国民经济的发展而变化的，要求对交易业务的实时监控具有相当的灵活性，以便于维护。

⏹先进性

系统采用国际流行的J2EE开放式框架，主要软硬件设备符合国际标准，集成了国际水平的主流生产厂的先进产品，应用软件采用B/S结构。

⏹数据完整性、安全性高

财务系统数据的完整性和安全性是非常重要的。

一个安全的客户/服务器系统应该是客户端机器的任何操作都通过服务器来实现其一致性和完整性控制。

数据库及财务稽核系统本身都应提供分级授权、日志记录等手段来确保系统的安全。

4.2设计规范

说明可以引用公司现有的各种设计规范或各种软件开发的国家标准或规范，主要包括：

（不限于以下几种，也不指定）

⏹命名约定

规定系统和子系统名,程序名,数据库表（文件）名,数据名,变量名等的编制规范。

⏹界面约定

规定屏幕界面的总体布局，如菜单行、显示主体、图标按钮、提示信息、出错信息等规范化，统一风格。

⏹程序编写规范

根据采用的编程工具特点，制定规范化要求，使程序易读易懂，可维护，可移植。

具体选用的规范，只要对设计有所帮助就可以罗列，编号及相关规范标题可以自行决定。

对于引用公司事先制订的有关规范或现存的各种国家标准等规范，则可以简单地描述，并参见《XXXXXXXX》规范或标准，文件可以作为本概要设计说明书的附件进行保存

如果一个系统比较大需要拆分成若干个子系统，而每个子系统需要各自编制概要设计文档，则只需要在一个总的概要设计说明书进行描述，其他子系统允许不专门进行描述，或注明参见《XXXXXXX》概要设计说明书。

4.3软件体系结构

简要介绍系统的总体结构和概要功能，可以通过画系统设计总体框架结构图的方式，再附上简单的文字说明,对本软件系统的总体功能进行概要描述。

对于采用J2EE平台的系统，参考如下：

系统的体系架构是一个系统的骨架，其重要性对一个系统的建设能否成功至关重要。

建立一个合适的体系架构关系到系统的业务需求；关系到系统的运行模式；关系到系统的性能需求，如安全性、可扩展性等。

在本系统中，我们将遵循J2EE规范进行设计和开发。

J2EE体系结构由SUN公司提出，它定义了如何开发、配置及实现一个企业应用，提供了对EJB、Servlets、JSP、JDBC、CORBA以及XML技术的全面支持。

J2EE提供了一个企业级的计算模型和运行环境，用于开发和部署多层体系结构的应用。

它通过提供企业计算环境所必须的各种服务，使得部署在J2EE平台上的多层应用可以实现高可用性、安全性、可扩展性和可靠性。

上图中是一个典型的分布式多层应用的模型，它将整个应用按照功能划分为表示层、商业逻辑层和数据层三个部分。

各个层次在逻辑上相互独立。

表示层是应用的用户接口部分，它担负着用户与应用间的对话功能。

它可用于检查用户从键盘等输入的数据，显示系统处理后输出的数据。

在变更用户接口时，只需要改写显示控制和数据检查程序，而并不会因此影响其他层的功能。

而数据检查的功能也只是限于数据的形式和实际取值范围，不包括有关业务本身的处理逻辑。

另外图形界面的结构也是不固定的，这便于以后可灵活变更。

例如：

可以在一个窗口中不是放入几个功能，而是按照功能分割窗口，以便每个窗口的功能简洁。

在原有C/S结构中客户端的业务逻辑现在统一并入到新增出的商业逻辑层中。

商业逻辑层实际是整个应用的本体，它负责整个系统的业务处理逻辑。

表示层和商业逻辑层间的数据交换尽量简洁，避免“一次业务处理，表示层和商业逻辑层间有多次数据交换。

”

数据层实际是DBMS，它负责管理对数据库的访问和控制数据库数据的读写。

数据层应能够迅速执行大量数据的更新和检索操作。

本系统采用了先进的B/S架构，提供分布式应用解决方案。

系统是以完全基于J2EE标准的电子商务平台技术为基础创建的纯Java的大型电子商务交易系统，其充分发挥了Java基于Web的特性和良好跨平台性，保证了系统良好的可扩展性，为实现向综合交易平台的过渡打下基础。

在确保查询正确的前提下，系统还采用了数字证书技术提供可靠的加密/解密、数字签名等手段，以保证系统中数据传输的安全性。

系统体系结构如下：

5.模块结构设计

5.1组件模块总体设计

主要对整个系统中公共组件模块进行描述。

5.1.1.组件模块的划分和功能描述

说明本系统的系组件模块的划分，扼要说明每个组件模块的标识符和功能说明

模块

ID

模块

描述

1.

5.1.2.组件模块关系

主要描述组件模块和组件模块之间的调用关系。

如下图中

5.1.3.组件模块的物理分布

通过物理分布图描述组件模块在物理环境中的分布。

示例如下：

5.1.4.组件模块与用例映射

列出实现用例时需要用到哪些组件模块，用√表示在实现某个用例时需要调用某个组件模块

ModuleID

UseCase

组件

模块1

组件

模块2

组件

模块3

组件

模块4

组件

模块5

。

。

。

用例名

√

√

5.2组件模块描述

描述系统中各个组件模块相应功能的全部细节，要求对每一个模块的设计都可以被实现，并能够被验证的，主要就是描述每一个组件模块的输入、输出和处理流程，必要时，可以借助数据流图来描述。

5.2.1.组件模块1

1.组件模块概述

⏹功能说明

对模块功能进行总体描述，着重描述该模块的调用者，以及调用者通过该模块完成什么样的功能，及描述“做什么”.

⏹前置条件

描述运行该模块之前必须满足的前提条件

⏹后置影响

描述运行该模块之后将会产生的影响。

⏹子模块划分

对该模块划分成更小的模块，并对每个子模块的功能简要说明。

若该模块较小，则不必细分。

2.组件模块接口设计

对每个组件模块对外提供的方法进行描述。

⏹方法1

方法名

方法功能描述

输入参数

输出返回值

主要处理逻辑

备注

⏹对于复杂的输入参数需要详细描述，描述示例如下：

使用xml格式描述完成该子模块所需要的输入数据格式，同时要注明哪些数据是由用户输入的，哪些是数据是由系统生成的。

同时还要描述数据的具体格式要求，如最大长度，日期型还是整型，小数精确到几位等。

例如登录模块的输入数据格式如下：

cbx

1234

2002-6-910:

20:

9

192.168.3.33

数据域

产生方式

数据类型

最大长度

最小长度

精确度

Username

用户输入

String

15

5

Password

用户输入

String

15

6

Logintim

系统产生

DateTime

⏹对于复杂的输出返回需要详细描述，描述示例如下：

描述该模块执行后的输出数据，包括成功失败两种情况。

对失败要枚举出各种可能的结果。

如果该输出格式比较复杂，建议也用xml格式。

example（login）

返回值

条件

登录成功

返回sessionid、基础数据等

登录失败

用户名和密码不对；

服务器忙；

无效IP地址；

你已经在线；

…

⏹对于复杂的处理逻辑建议适用流程图或者活动图来描述

6.用例实现

6.1用例1

1.用例概述

⏹用例功能说明

对用例功能进行总体描述，着重描述该模块的调用者，以及调用者通过该模块完成什么样的功能，及描述“做什么”.

⏹用例前置条件

描述运行该模块之前必须满足的前提条件

⏹用例后置影响

描述运行该模块之后将会产生的影响。

2.用户界面

对于用户界面的设计可以为可选项，如果缺少有关界面的设计描述，将给开发人员带来对概要设计的二义性时则要求设计界面。

界面的设计，要求根据本软件所事先制订的有关界面约定或设计规范，初步画出各个用户的操作界面。

用户界面的贴图

或输出报表样式

界面要素

显示名称

描述

约束条件

备注

1）操作

操作名称

描述

约束条件

备注

3.流程图（或活动图）

4.前后台交互的数据内容

5.涉及主要组件模块和功能模块

列出实现该用例时所需要的组件模块名称，功能类，文件等等

6.用例实现

1）类图

2）时序图

7.数据结构设计

表名或视图名[Table_NameorView_Name]

ID

字段名

字段代码

类型和长度

字段说明

可空

缺省值

取值范围

键值

索引

8.接口设计

为可选项，若存在有关的接口并且需要特别说明，否则容易产生开发者对系统设计的二义性时需要详细描述。

接口分为外部接口和内部接口，其中外部接口如：

用户界面、软件接口与硬件接口等，内部接口如：

子系统之间的接口关系，模块之间的接口，主要是有关传递信息,参数等等。

本章若存在N个接口，则可分为N节来描述，每个接口单独为一节，标题可自行决定。

9.系统安全设计

为可选项，如果系统设计对安全保密性有特别的要求，则需要详细描述，主要可以从以下几方面进行考虑：

系统故障预防与恢复、用户管理和权限控制、数据备份和恢复等

9.1系统故障预防和恢复

为可选项，如果存在可能出现的系统故障需要恢复的情况，则要进行设计描述，主要说明将使用的恢复再启动技术，使软件从故障点恢复执行或使软件从头开始重新运行的方法，建议可按照以下格式进行说明：

为恢复系统（包括软硬件）故障和人为因素引起的数据错，特设计以下措施：

出错现象

可能原因

措施

盘后清算出现异常

本地柜台的交易数据出错

恢复昨日盘后数据，重新接受交易所当日委托数据，重新进行清算

9.2用户管理和权限控制

说明在数据库的设计中，将如何通过区分不同的访问者、不同的访问类型和不同的数据对象，进行分配权限并分别对待而获得的数据库安全保密的设计考虑。

9.3数据备份与恢复

为可选项，如果存在数据备份与恢复的需求要求，则要做相应的设计描述。

对数据备份与恢复的设计，主要说明在适当的时间点上，如何设计系统的数据备份和数据恢复功能，以便在系统失效、出现意外及数据出错、或有充分的需要的时候，可以在可接受的时间内得以恢复到最近或以前某个时间点的数据备份上，要求描述清楚实现数据备份和恢复的整个设计思想以及实现方法。

9.3.1.数据备份

系统是一套24小时实时运行的加以系统，数据库中存储的数据大部分是非常重要的商业交易数据，它要求高度的安全性和强健的完整性，所以，必须制定功能完善的数据备份策略，充分保证数据库系统的安全和完整。

为此制定以下安全备份措施：

⏹所有交易数据库，全部对应建立历史备份数据库，定期将当前数据库中的数据追加到历史数据库中。

⏹对历史数据库中的数据，定期备份。

一般当前数据，每月一次自动复制到历史数据库中；历史数据保留半年后，使用光盘刻录设备，进行2份以上备份存档，然后可清除历史数据库和当前数据库中的这部份数据，以提高系统运行效率，释放部分硬件资源。

⏹主数据库服务器使用磁带备份系统，对数据库中的实时数据作更新备份和增量备份（不包括历史库）。

1.数据库日备份：

系统每日自动将更新操作后的数据备份到磁带机上。

2.数据库周备份：

每周一次，系统自动将所有数据库备份到磁带机上。

3.数据库月备份：

每月一次，系统自动备份所有数据库到磁带机上。

⏹主数据库服务器使用跟踪带，对系统操作进行跟踪记录。

9.3.2.数据恢复

数据的恢复措施主要与数据备份相对应：

⏹如果当前数据库因故遭到破坏，不能保证其完整性时，应进行恢复。

步骤如下：

1.先将历史库中的数据追加到当前库中。

2.将磁带上的数据按月备份、周备份、日备份的顺序，依次恢复到当前数据库中。

3.按照跟踪带上的操作顺序，将当天的数据进行恢复。

可根据具体情况选择其中的若干步执行。

如需查询历史数据，可将光盘中部分或全部历史数据，重新导入数据库中。

10.系统运行设计

为可选项，当系统足够大被拆分成若干子系统，如果不专门介绍系统运行时各子系统之间的运行机制和控制关系，则开发人员无法理解本概要设计说明书而导致无法实现系统功能时，才有必要进行相关运行设计的描述。

运行设计，主要用来说明运行模块的组合，进行软件系统的构造设计，确定系统的运行控制方法及资源分配情况

10.1运行模块组合

说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合，说明每种运行所历经的内部模块和支持软件，建议画出系统运行机制结构图来表示，再附上简要的文字说明，以描述清楚各个运行模块（包括各种运行的进程），分别如何运行在各自指定的硬件上（必要时要说明相关的硬件配置及其在运行环境下所起的作用）

10.2运行控制

描述清楚各个运行模块进行运行控制的方式、方法和操作步骤，以及每种运行模块组合将各自占用的各种资源情况，以及对时间响应的要求，可以分别从以下几方面进行描述：

多机管理，一台服务器应允许多台客户端机器加入应用系统，则要描述清楚服务器是如何进行管理多台机器的。

合法性检查，当客户端需要访问后台数据库的业务数据时，有关应用系统的网关服务或其他相关服务程序是如何进行用户身份的合法性校验，一般系统都会要求每一个用户发出某个服务请求后，必须首先输入自己的用户名和密码

请求响应，有关服务器对用户的各种请求的响应，采用多线程的并发处理还是单线程的串行顺序处理等方式的实现情况，以及对事务处理的时间响应要求等

控制界面，关于用户监控系统（如：

国泰君安实时监控系统）的监控屏幕上应该显示各种业务处理信息，出现异常时要求要实时报警或做相应妥善的处理。

通讯控制，描述清楚系统所采纳的通讯平台的有关说明，包括前台和后台之间的通讯、网关之间的数据转换处理，以及通讯时所采用的通讯协议等内容

核心业务处理，说明对客户的许多关键或主要业务的系统实现，在整个运行机制中是如何进行控制的

11.系统出错处理设计

为可选项，如果不专门对系统出错信息进行设计描述，将导致开发人员无法理解本概要设计的有关出错信息的处理说明，无法实现有关出错处理功能时，才需要描述本章节的内容

11.1出错处理信息

罗列本软件系统可能的出错或故障情况出现的各种出错处理信息，包括系统出错信息提示的形式（包括出错对话框的设计）、含义及处理方法等。

在操作出错或数据出错等情况下，系统显示或记录的有关出错代码／信息，要求要符合相关的《系统出错处理设计规范》（如果规范存在的话）

出错的分类可以参考以下：

11.1.1.通讯线路错误

11.1.2.系统环境错误

11.1.3.应用设计错误

11.2出错处理对策

说明故障出现或系统出错后可能采取的变通补救办法，主要包括：

设置后备技术、性能降级（即降效技术）、恢复及再启动等等。

设置后备技术，体现在：

当原始系统数据万一丢失时则启用的副本的建立或启动的技术，采用磁带备份等

降效技术，也是一种后备技术，体现在：

使用另一种效率稍低的系统或方法求得所需结果的某些部分，如手工操作。

下述为对于系统环境出错处理对策参考：

系统故障根据系统类型可分为四类：

系统软件故障、应用软件故障、硬件系统故障、网络系统故障。

系统维护工作的进行，应建立在对系统正常按章操作的基础上，把人为损坏的因素降到最低。

因此，良好和规范的操作习惯是保证系统稳定运行的重要保障。

系统类型

故障类型

维护措施

系统软件

UNIX系统故障

·设置专职系统管理员·UNIX系统故障类型较多，具体故障对应具体的