项目名称概要设计说明书v10.docx

项目名称概要设计说明书v10.docx

《项目名称概要设计说明书v10.docx》由会员分享，可在线阅读，更多相关《项目名称概要设计说明书v10.docx（17页珍藏版）》请在冰豆网上搜索。

项目名称概要设计说明书v10

XXX概要设计说明书

变更记录

日期

版本

变更说明

作者

YYYY-MM-DD

1.0

初始版本

XXX

签字确认

系统模块

对应章节

对应部门

负责人签字

目录

1引言3

1.1编写目的3

1.2背景4

1.3基线4

1.4特殊名词定义4

1.5参考资料4

2总体设计4

2.1概述4

2.1.1功能描述4

2.1.2运行环境5

2.1.3开发环境6

2.2系统设计构思7

2.2.1系统功能层次说明7

2.2.2关键技术与算法11

2.2.3关键数据结构（待定）12

3系统功能设计12

3.1系统功能12

3.1.1文件上传12

3.1.214

4系统数据结构设计（待定）17

4.1说明17

4.2数据结构17

4.3数据结构与系统元素的关系18

5系统出错处理设计18

5.1出错信息18

5.2补救措施18

6系统维护设计（如没涉及可不做说明）18

6.1检测点的设计18

6.2检测专用模块的设计18

7尚待解决的问题19

1引言

1.1编写目的

书写要求：

本说明书目的在于明确说明系统各功能的实现方式，指导开发员进行编码。

本说明书的预期读者为：

XXX等。

1.2背景

书写要求：

待开发软件系统的名称：

XXX

此软件系统任务提出者：

XXX

此软件系统任务开发者：

XXX

此软件系统任务用户：

XXX

1.3基线

书写样例：

XXX需求分析说明书v1.0

1.4特殊名词定义

XXX：

YYY。

1.5参考资料

书写样例：

属于本项目的其他已发表的文件。

本文件中引用的其他文献、资料以及软件开发标准。

2总体设计

2.1概述

2.2功能描述

系统包括的范围：

XXX。

2.2.1运行环境

2.2.1.1软件环境

分类

名称

版本

语种

操作系统

操作系统的附加功能

数据库平台

数据库平台补丁

应用平台

应用平台补丁

邮件系统

客户端软件

2.2.1.2硬件环境

服务器

最低配置

推荐配置

应用和数据库服务器

邮件服务器

2.2.2开发环境

2.2.2.1服务器软件环境

分类

名称

版本

语种

操作系统

操作系统的附加功能

数据库平台

数据库平台补丁

应用平台

应用平台补丁

版本控制系统

目录服务系统

邮件系统

客户端软件

2.2.2.2服务器硬件环境

服务器

最低配置

推荐配置

应用服务器、数据库服务器、邮件服务器、目录服务器

2.2.2.3开发机器软件环境

分类

名称

版本

语种

操作系统

操作系统的附加功能

数据库平台

应用平台

开发平台

客户端软件

2.2.2.4开发机器硬件环境

分类

最低配置

推荐配置

开发机器

2.3系统设计构思

2.3.1系统功能层次说明

书写要求：

根据系统设计的功能层次逐一说明（与需求分析中的“系统功能总体说明

”部分的内容基本一致）

2.2.1.2系统架构设计说明

书写要求：

根据系统的功能需求设计并说明系统开发所采用的软件开发架构。

书写样例1：

具体架构层次如图4.3所示。

SSH架构结构图（图例1）

⏹各层实现功能及开发技术说明

1.四层结构的优势

1）通过成熟的开源产品实现各层功能开发，比起自己开发能缩短开发周期，且架构所用到的开源产品均有很广泛的用户群，经受过实践的考验，质量和性能更有保障。

2）层与层之间松散偶合，增加代码重用率。

3）各层分工明确，这样也利于团队的明确分工。

2.表示层

这一层是面向用户的界面，是用户与系统之间交互的媒介。

如：

用户在界面发送请求，系统接收请求，进行处理，然后通过界面将结果呈现于用户。

这一过程包括了用户动作、数据传递、界面显示。

大家熟悉的MVC模式就是将这三者分离，减少三者耦合。

我们在该层借助了Struts来实现。

2）Struts的实现的功能:

管理用户的请求，做出相应的响应。

提供一个Controller，委派调用业务逻辑和其它上层处理。

处理异常，抛给StrutsAction.

为显示提供一个模型。

UI（Userinterface）验证。

以下部分则不该在Struts显示层的编码中经常出现。

因为在表示层引入这些代码，则会带来高偶合和非常麻烦的维护代价。

直接的与数据库通信，如JDBC调用。

与你应用程序相关联的业务逻辑以及校验。

3.业务层

业务层在实际的项目开发中，每个领域都会有自己独特的业务逻辑，正因为这样，致使项目中代码高度偶合，原本有可能被重用的代码或功能，因为与具体的业务逻辑绑定在一块而导致很难被重用。

因此我们将实现这些具体逻辑的代码抽取出来分为单独的一层，其目的是希望通过分层，来降低它与系统其他部分的偶合度。

现实中世界是变化的，既然该层实现的是现实中具体的业务逻辑，那该层的实现代码不可避免的会发生变更。

怎样让该层适应最大的变化，做到最小的改动?

通常我们在编码的时候会尽量考虑到同一业务多种实现的兼容和可扩展的能力。

因此我们在该层借助了Spring，通过依赖注入、AOP应用、面向接口编程，来降低业务组件之间的偶合度，增强系统扩展性。

2）Spring实现的功能:

处理应用程序的业务逻辑和业务校验。

管理事务。

提供与其它层协同工作的接口。

管理业务层级别的对象的依赖。

在显示层和持久层之间增加了一个灵活的机制，使得他们不直接的联系在一起。

通过揭示从显示层到业务层之间的Context来得到businessservices。

管理程序的执行（从业务层到持久层）。

4.数据持久层

数据持久层在开发中与数据库进行数据交互必不可少，通常我们归为CRUD（添加、读取、修改、删除），这些操作占据了系统开发中大部分的时间，同时我们还需要考虑与数据库交互的性能问题，如连接池、数据缓存等等。

系统内部的持续层不但需要大量调试时间，而且还经常缺少功能使之变得难以控制。

针对这点我们引入ORM开源架构Hibernate。

2）Hibernate实现的功能:

查询对象的相关信息的语句。

存储，更新，删除数据库记录。

支持大部分主流数据库，并且支持Parent/Child关系，事物处理，继承和多态。

5.各层中的封装类

各层的封装类的主要功能都是一致的，就是将有一定联系的数据集合装载在其实力对象中，这样做的道路是显而易见的，通过对象来传递数据集合的效率会更高更方便。

显示层的FormBean类是用封装来自页面form提交的信息的，一般情况下这个类的私有变量是与页面form的元素一一对应的。

另外FormBean封装类的对象还负责将要显示的信息传递到显示层，其作用是双向的。

业务逻辑层的ValueObject类是用来封装一定业务功能实现过程中需要的数据集合的，也就是说要封装的数据都是由业务功能的需要决定的。

持久层的PersistObject类，其实例化对象所封装的数据集是与数据库中表相对应的，即表项对应要封装的数据项。

我们根据上面封装类的说明可以看出，FormBean、ValueObject、PersistObject、三者的作用相似都是为了封装数据信息，不同的是这些对象所在的是不同架构层面，这样做的好处是数据的处理和转递比较有条理，层次清晰易于维护。

封装类在架构中的情况如图4.4所示。

各层封装类的情况（图例2）

书写样例2：

Jsp&Servlet&JavaBean架构

具体架构层次如图例所示。

Jsj架构结构图（图例3）

⏹各层实现功能说明

View层是与客户的交互层，负责提交用户请求和数据，并将后台的响应结果返回给客户层。

同时提供客户提交信息的javasript验证功能。

Control层负责项目中业务功能实现流程的管理工作。

如：

具体的业务功能由哪些类来实现，实现结果有谁来显示等等，必须由Control层来决定。

同时Control层还要负责与其它两层的通信，这个过程还需要一些bean类来协助传递信息，另外Control层还要负责请求的转发与从定向。

从Control层所负责的功能上不难想象的到在业务逻辑相对复杂的时候此层代码编写会略显繁重和复杂。

Model层主要是一些实现具体业务功能的类，在这里可以统一简称为Business类。

也可以将架构中除了Servlet控制器之外的所有类统一叫做Javabean类。

从这种命名方式上可以看出，model层在实现业务功能是具体的实现方式比较自由，但在业务逻辑比较复杂的情况下model层职能的划分会出现问题，可能会造成一定混乱和不便。

设想一下如果可以更明确的将model层进一步划分使之变得更有条理，这样就会增强该层的可维护性了。

特别说明，图4.1中的“bean”可以看作数据封装类，它以实例对象的形式作为各层之间数据通信的载体，实际上这些对象也属于业务对象，如User对象、Book对象。

2.3.2关键技术与算法

书写要求：

对系统中比较复杂的功能的实现方式或应用的特殊技术加以说明要求通俗直观便于客户参考。

书写样例：

查询统计（科学项目的查询和统计，科学成果的查询和统计，科学奖励的查询和统计，科技人才的查询和统计）

组合检索：

组合检索由拥有搜索权限的用户在组合类别的下拉框中选择需要查询的项目，如科技项目的检索：

项目类别+项目资金+项目所属公司+时间；没有选择的项，下拉框默认为空白。

点击搜索，系统将对数据库的字段进行模糊搜索，搜索结果列表显示于组合搜索下面，分页显示搜索结果。

注：

其它的科技成果搜索，科技奖励搜索，科技人才搜索采用统一的组合搜索形式

统计图表：

各分公司统计：

根据用户在科技项目申请，科技成果申请，科技奖励申请，科技人才的输入的数据，当拥有该权限的用户点击各分公司统计，系统将从数据库中读取以上的部分数据，进行统计，然后以统计图形的形式显示出来，对各分公司进行比较，方便领导制定企业决策。

某分公司统计：

当拥有权限的用户点击某分公司统计，系统将从数据库中读取这对该公司的数据进行统计，显示统计图，该统计主要面向集团和分公司领导。

注：

其它的科技成果搜索，科技奖励搜索，科技人才搜索采用统一的统计形式

3系统功能设计

书写要求：

此部分主要对关键功能进行设计，描述其实现方式。

要求结合具体页面及功能实现过程说明各模块功能。

界面要求对输入输出项进行说明，实现过程尽量能细化到每一个操作。

（最好附以特征界面和数据表设计）。

解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。

对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。

3.1系统功能

书写样例：

3.1.1文件上传

3.1.1.1功能描述

文件上传功能用到了专门为对文档进行上传下载功能而设计的两个包，调用包中特定类的特定方法，然后传入对应的文档路径参数就能实现文档的上传下载。

而且还能实现多文档上传。

文档上传时，用户单击增及按钮就会多出一个文本框供用户选取上传文档的路径，单击减少按钮就会相应的减少一个文本框。

最少要上传一个文件，最多只能同时上传五个文件。

用户操作效果如下图例3、4。

文档上传客户页面初始

页面（图例3）

文档批量上客户页面（图例4）

3.1.1.2接口设计

输入操作：

用户输入文件路径。

输出效果：

上传成功的文件列表。

输入操作通过界面进行。

文件路径用文件选择框。

3.1.1.3功能实现流程图（也可用活动图等描述）

3.1.2组织管理列表（树状图）

3.1.2.1功能描述

组织管理采用javascript实现动态树，管理员可以定位到动态树的特定节点，每个节点都有他对应的操作，管理员可以对这个节点进行他需要的操作，如子公司的增删改、公司部门的增删改等。

当操作子公司的时候，点击

按钮时，组织结构树会自动展开以展现所有集团下的子公司，这时可以对子公司进行各种删改。

同理，子公司下有部门，部门下还有部门，只要按相应的按钮，组织结构树就会自动展开，相应的增删改操作就能实现。

点击

按钮时，树就折叠起来，方便管理员有针对性地进行操作。

3.1.2.2接口设计

输入操作：

查看公司结构。

输出效果：

以树状结构输出公司结构。

输入操作通过界面进行。

输入操作：

删除操作。

输出效果：

是否删除成功。

输入操作通过界面进行。

输入操作：

输入公司/部门名。

输出效果：

以树状结构输出公司结构。

输入操作通过界面进行。

增加公司/部门用页面弹出对话框。

3.1.2.3流程图（流程图）

活动图：

4系统数据结构设计（如另外撰写数据库设计说明书，该部分可省略）

4.1说明

在面向对象的设计方法中，数据也可以作为一个对象来处理，如果数据附属于某一对象，可以将其纳入该对象的属性管理之中。

所以在面向对象的设计过程中，对数据的设计是在对对象的设计过程中完成的。

4.2数据结构

书写要求：

列出本系统使用的主要数据结构，包括它们的名称、标识符及数据项等。

4.3数据结构与系统元素的关系

书写要求：

各个数据结构与访问这些数据结构的各个系统元素之间的对应关系。

将数据和系统的程序模块有机地结合起来。

可以进一步向系统最终的数学模型（程序语言）靠近。

5系统出错处理设计

5.1出错信息

书写要求：

要求说明系统对异常信息的处理和显示方式，异常信息包括代码执行时的异常报错（例如：

新增数据失败等）、系统逻辑判断产生的错误提示等信息（例如：

用户登录身份验证信息）。

5.2补救措施（如没涉及可不做说明）

书写要求：

说明故障出现后可能采取的变通措施，包括：

a.后备技术当原始系统数据万一丢失时启用的副本的建立和启动的技术。

b.降效技术使用另一个效率稍低的方法来求得所需结果的某些部分，如手工操作和数据的人工记录。

c.恢复和再启动技术使系统从故障点恢复执行或使系统从头开始重新运行的方法。

6系统维护设计（如没涉及可不做说明）

书写要求：

说明为了系统维护的方便，在程序内部设计中作出的安排。

6.1检测点的设计（如没涉及可不做说明）

书写要求：

说明在程序中专门安排用于系统检查与维护的检测点。

6.2检测专用模块的设计（如没涉及可不做说明）

书写要求：

说明在程序中专门安排用于系统检查与维护的专用模块。

6.3尚待解决的问题（如没涉及可不做说明）

说明在本设计中没有解决而系统完成之前应该解决的问题。