概要设计说明书模板

软件设计类的设计说明

项目名称 概要设计说明书

项目编号： 文件版次： 编写人/日期： 审核人/日期： 批准人/日期：

软件设计类的设计说明

变 更 记 录

注：对本文档内容增加、删除或修改均需填写此变更记录，详细记载变更信息，以保证其可

追溯性。

软件设计类的设计说明

1．引言

1.1目的

概述本文档的编写目的、主要阐述内容以及通过编写此文档能够达到的目的。

1.2范围

概述本文档适用的范围以及预期读者。

1.3定义、首字母缩写词和缩略语

建议提供全部术语、缩写词及略语的定义，以便对本文档进行适当的解释。

1.4参考资料

建议按文档号和标题列出本报告引用的所有文档，包括所使用的标准等。

软件设计类的设计说明

2．系统架构

2.1系统技术原则

描述对于系统后续设计开发有重要指导意义的技术原则与技术决策

示例如下：

根据客户的要求，我们决定采用J2EE技术路线来进行系统开发，具体的参数如下所示： 技术路线：J2EEV1.4

应用服务器与数据库产品见系统部署方案 Java版本：JDK1.5.0-04 客户端：Internet Explorer6.0+

2.2系统部署方案

通过使用UML部署图来描述系统部署方案，并且描述硬件环境，以及与系统有重要关

系的第三方软件产品

示例如下：

软件设计类的设计说明

2.3系统分层关系

描述系统的分层架构，如果系统基于某个已有明确分层架构描述的开发平台之上，且自身又没有对于分层架构的扩展，那么可以直接引用开发平台的分层原则

软件设计类的设计说明

示例如下：

采用J2EE的分层原则

2.4系统分解

描述系统的功能模块分解图，可以按照子系统、模块以及子模块的方式来划分，最小力度为子模块。当在一副图中无法完全描述所有模块时，可以使用多幅图的方式来描述。

示例如下：

系统主要由两个子系统构成：管理预订与客户登记，其中管理预订子系统还可以分解房

间预订、房间退订、订单查询以及订单更新四个模块。

2.5系统依赖

描述系统的功能模块依赖图，该图要对应上面的系统分解，箭头的方向表示依赖。当在

一副图中无法完全描述所有模块依赖时，可以使用多幅图的方式来描述。

示例如下

软件设计类的设计说明

由于在预订之前必须要对预订人进行登记，因此管理预订子系统依赖于客户登记子系

统。

在管理预订子系统中，订单更新依赖于已经查询出来的订单，因此订单更新依赖于订单

查询。

2.6异常与错误处理机制

描述系统整体的异常与错误处理机制

示例如下：

系统采用平台的统一异常处理机制，通过配置的方式将系统中出现的异常转向到一个具体的异常页面。

每个子系统都可以定义自己的个性化异常，并指定它们出现时转向到哪个具体的页面。

2.7与外部系统的集成策略

描述系统与外部系统的集成方式

示例如下：

该系统目前不需要与外部系统进行集成，但将来可能会与银行系统进行集成，以实现网

软件设计类的设计说明

上缴费。

2.8非功能性需求的解决方案

根据软件需求规格说明书的要求，描述系统的非功能性需求的解决方案

示例如下： 性能：

在100并发的压力下，房间预订的页面出现时间不超过2s：

由于该页面有一些属性值需要从数据库中动态的加载，而这些值并不经常发生变

化，因此可以使用缓存技术来缓存动态参数，避免数据库操作，从而极大提高响应速度

在100并发的压力下，检索可用房间的时间不超过3s：

由于酒店剩余的房间随时可能被预订出去，因而此处无法使用简单的读缓存技术，

而是要考虑更灵活的读/写缓存技术，即在保证数据正确性的前提下使用缓存，并且要支持集群环境

对用户查询可用房间的操作进行计时限制，不允许无意义的频繁查询，以免浪费数

据库资源

可靠性：

不允许出现同一个房间在同一时间段被多个客户预订的现象：

在每次提交预订之前，都需要检索当前房间是否还可以被预订，并且在这个检索时

需要加入同步锁，避免多个客户同时检索

软件设计类的设计说明

2.9设计风险及应对方案

结合需求部分对技术风险的描述与分析，对当前架构设计部分已知的风险进行描述与分析，并且阐述应对的方案。 示例如下：

软件设计类的设计说明

3．系统设计

从3.1节开始编号。分节标识和描述各功能模块。

如果各模块内还有子模块，那么在3.1.5小节中按照3.1的结构再进行描述

3.1 管理预订

3.1.1基本职责与原理说明

描述该子系统或模块的基本职责，如果它内部有一些特定或重要的技术实现，那么需要

阐述实现原理

示例如下：

该模块的编码：Abstract-Reservation-Module-001

管理预订子系统提供客户（Customer）对酒店房间（Room）的预订（Reservation），

它将采用读缓存（Read-Cache）的方式来记录房间类型（Property）从而提高页面显示效率，采用读/写缓存（Read/Write-Cache）的方式来提高房间预订的效率，采用同步锁的方式来确保房间约定的正确性。

3.1.2域模型定义

通过对用户需求以及软件需求的分析，得到系统的域模型，在本节中使用类图的方式将域模型描述出来，并阐述各个域模型的作用

示例如下：

软件设计类的设计说明

在管理预订子系统中，包含了上述四个主要的实体：

Reservation（预订）：记录客户预订的相关信息，包括房间号、客户ID、时间等

等；

Room（房间）：记录酒店房间信息，包括房型等 Property（属性）：记录房间的相关属性，例如房型属性等 Customer（客户）：记录客户相关信息，包括姓名、电话等

3.1.3业务逻辑定义

根据软件需求规格说明书的描述，定义系统的业务逻辑

3.1.3.1系统协作定义：

房间预订业务如下所示：

使用UML中的协作图来描述系统的组件协作关系，并结合文字进行描述

软件设计类的设计说明

首先，客户通过主页面中（MainUI）的房间预订按钮进入到具体的预订页面中，在这

个过程中，系统会向后台发起请求，并获得相应的页面属性用以生成页面（ResvUI）。

其次，客户输入查询条件，来查询他希望预订的房间。

第三，客户执行查询操作，向后台发起请求，后台根据用户的查询条件查询出剩余可用

的房间数量以及编号，并在页面中显示出来。

最后，客户选择一个或多个他需要的房间，并确认这次预订。

3.1.3.2服务组件定义：

ResvService是管理预订子系统的服务组件，它完成了管理预订的各种行为，它的类图如下：

使用类图来描述上面协作图中的服务组件

软件设计类的设计说明

3.1.4异常机制定义（可选）

…… 此处隐藏：1202字，全部文档内容请下载后查看。喜欢就下载吧 ……