第N次迭代—软件设计说明书模板

密级：内部公开

文档编号：ZIZI_SD_TEMP_SJSMS_YF

版本号：V1.6

发布日期：

实施日期：

***模块

第N次迭代—软件设计说明书

兹兹新能源科技股份有限公司

文档编号：ZIZI_SD_TEMP_SJSMS_YF 第1 页共12 页

文件更改摘要：

––––––––––––––––––––––––––––––––––––––

兹兹新能源科技股份有限公司对本文件资料享受著作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。

文档编号：ZIZI_SD_TEMP_SJSMS_YF 第2 页共12 页

目录

1概述 (5)

1.1编写目的 (5)

1.2设计范围简述 (5)

1.3名词术语 (5)

1.4参考资料 (5)

2软件设计目标 (5)

2.1目标范围 (5)

2.2功能性目标 (5)

2.3非功能目标 (6)

3设计概述 (6)

4结构设计 (6)

4.1层次结构框图 (7)

4.1.1顶层结构 (7)

4.1.2子模块1结构 (7)

4.1.3子模块2结构 (7)

4.1.4.... .. (7)

4.1.5公共基础子模块结构 (7)

4.2模块职责设计 (7)

4.3模块交互设计 (7)

5子模块1设计 (7)

5.1界面设计 (7)

5.1.1界面的组织 (8)

5.1.2界面描述 (8)

5.1.3界面的切换逻辑 (8)

文档编号：ZIZI_SD_TEMP_SJSMS_YF 第3 页共12 页

5.2程序接口 (8)

5.3数据模型 (9)

5.4数据流设计 (9)

5.5对象模型设计 (9)

5.5.1静态模型设计 (10)

5.5.2动态模型设计 (10)

5.6应对变化设计 (11)

6子模块2设计 (11)

7约束和假定 (12)

8遗留的问题 (12)

文档编号：ZIZI_SD_TEMP_SJSMS_YF 第4 页共12 页

1概述

1.1编写目的

本说明书为了充分的理解**需求目标，采用面向对象的分析与设计的手段和原则，分析并设计软件的实现方案。同时，本说明书在对需求和问题域的充分理解的基础之上分析可能的需求变化点，以提高系统的可扩充性和可升级性。

本说明书完成后，将作为后续开发、变更的基础。

1.2设计范围简述

对本说明书设计的软件范围要完成什么，所面向的用户以及系统运行的环境的简短描述，可参考需求说明书的开始部分。

1.3名词术语

1.4参考资料

至少包含所基于的需求规格说明书

2软件设计目标

这部分论述整个系统的设计目标，明确地说明哪些功能是系统决定实现而哪些时不准备实现的。同时，对于非功能性的需求例如性能、可用性等，亦需提及。需求规格说明书对于这部分的内容来说是很重要的参考，看看其中明确了的功能性以及非功能性的需求。

这部分必须说清楚设计的全貌如何，务必使读者看后知道将实现的系统有什么特点和功能。在随后的文档部分，将解释设计是怎么来实现这些的。

2.1目标范围

2.2功能性目标

该部分描述我所理解的功能目标。也就是说在该部分由“设计人员”站在自己的角度描述从文档编号：ZIZI_SD_TEMP_SJSMS_YF 第5 页共12 页

需求人员处得到的功能目标，以及在设计的过程中体会到的功能的目标。

说明：该处的描述必须与设计完全一致，但不必与需求人员的描述或文档完全一致，其正确与否和偏差留待本文档的评审会上决定。

2.3非功能目标

该部分描述“设计人员”所理解的、关键的非功能性要求。也就是说在该部分由“设计人员”站在自己的角度描述从需求人员处得到的、关键的非功能性要求，它是在设计的过程中必须考虑以某种方式达到的非功能性指标。

其形式可以参考“目标-场景-决策表”，如下：

3设计概述

这部分要求突出整个设计所采用的方法（是面向对象设计还是结构化设计）、系统的体系结构（例如客户/服务器结构）、技术框架以及使用到的相应技术和工具（例如OMT、Rose）

4结构设计

以框图的形式描述本功能模块中的各软件模块的划分、职责分配、层次结构、简单的数据流动描述，以外部模块代表其他的功能模块并将它们绘制在框图中。

最好是把逻辑结构同物理结构分离，对前者进行描述。别忘了说明图中用到的俗语和符号。文档编号：ZIZI_SD_TEMP_SJSMS_YF 第6 页共12 页

4.1层次结构框图

以层次结构框图的形式描述各软件模块在整个功能模块中的位置、以及相互之间的配合，并加以简单的数据流动描述。另外图中也应该包括外部模块。

4.1.1顶层结构

4.1.2子模块1结构

4.1.3子模块2结构

4.1.4….

4.1.5公共基础子模块结构

4.2模块职责设计

描述每个软件模块的职责、数据、与其它软件模块的交互、以及用户看到的效果。

4.3模块交互设计

不管功能模块，还是公共服务，还是功能模块之间的集成程序，都可作为各个软件子模块，下面几个章节根据不同数量的软件子模块进行分别设计。

5子模块1设计

子模块的设计由于其职责不同，其设计的侧重点不同，以下内部章节可参考

5.1界面设计

该处以用户界面为主，目标是以界面为核心描述功能的启动、操作过程、操作结果，并且说明界面设计与数据模型的对应关系。

外观设计方面，

1.由用户控制界面：

文档编号：ZIZI_SD_TEMP_SJSMS_YF 第7 页共12 页

不强迫用户进入不必要的或不希望的动作，允许用户交互可以被中断和撤消，能够针对不同熟练程度的用户定制界面；

2.减少记忆负担：

减少对用户短期记忆的要求，建立有意义的缺省，定义直觉性的捷径，快捷方式，界面的视觉布局应该基于真实世界的隐喻；

3.保持界面一致：

用户应能以一致的方式展示和获取信息，所有可视信息的组织均按照贯穿所有屏幕显示所保持的设计标准，允许用户将当前任务放入有意义的语境，在应用系列内保持一致性备注：如果在需求规格说明书中已经对用户界面有了叙述，此处不用再重复，可以指引读者参考需求说明。

5.1.1界面的组织

界面与界面之间存在着聚合关系与先后顺序关系，此处从这个角度描述界面之间的关系。

5.1.2界面描述

每个界面的描述

此处提供界面的布局图，并描述输入的数据（如有可能请描述数据的来源，例如用户输入、文件读取或者数据库读取等等）、输入和输出的数据验证以及用户操作验证的逻辑、用户的操作顺序、本界面输出的数据、某些控件的响应逻辑、所属功能模块。

5.1.3界面的切换逻辑

以状态图的形式描述界面切换的顺序，并在状态变换的路径上描述导致界面切换的逻辑与动作。

5.2程序接口

本模块提供了对其它模块或系统的接口。

文档编号：ZIZI_SD_TEMP_SJSMS_YF 第8 页共12 页

5.3数据模型

此处的重点在与描述数据模型与界面（含程序接口）设计之间的对应关系，一个数据模型中的实体可能会对应一个界面或一组有关系的界面，一个界面也可能用来展示一个或多个有关系的数据模型中的实体。但本着从简的原则，不必描述实体的属性与界面元素之间的对应关系。

总的来说原则就是应该在贴合用户的习惯的前提下由数据驱动界面，而不是由界面影响模型。

5.4数据流设计

如果一组界面之间存在关系，则以一组界面为单位否则以单个界面为单位，描述界面的前提数据、数据在各界面之间的流动、输出的数据。

5.5对象模型设计

使用UML图描述类、接口、协作以及它们之间关系，本着从简的原则，重点放在职责、协作与关系上；并只描述系统主体的对象模型即可。除了传统的派生、关联、依赖关系之外，要以关联关系的形式描述对象实例组织上的关系，也就是抽象意义上的容器与元素的关系。类图只能描述静态的模型关系，动态的关系与配合过程交给协作图、时序图等动态图描述。

一个一般性的设计思路是从问题域出发，将问题域的类与关系映射为软件中的类与关系，根据共同点、不同点抽象出接口与派生关系，根据需要增加控制类、关系类、业务逻辑类等。初步的将职责分配给各个类，职责的分配应该符合封装性的原则以降低耦合性，并且要确保职责分配的平衡；然后进一步的针对复杂的或关键的本软件模块的业务功能目标，使用协作图描述各个对象的相互配合以完成功能，在这个过程中继续细分和调整各个类的职责。

职责的分配应该清晰合理，并且职责的分配依据主要考虑问题域的本质规律，应该忽略业务功能的影响或者使之尽量的小。从面向对象设计的基本原则出发评审对象模型的设计，例如：单一职责原则、开放——封闭原则、接口隔离原则、稳定依赖原则、最少信息原则、依赖倒置原则等。

文档编号：ZIZI_SD_TEMP_SJSMS_YF 第9 页共12 页

5.5.1静态模型设计

5.5.1.1主体对象（类）模型

提供系统主体的对象模型，如果模型过大，按照可行的标准把它划分成小块，例如可以把客户端和服务器端的对象模型分开成两个图表述。

对象图应该包含主要的系统对象。这些对象都是从理解需求后得到的。要明确哪些应该、哪些不应该被放进图中。

所有对象之间的关联必须被确定并且必须指明联系的基数（一对一、一对多还是多对多，0..1，*，1..*）。聚合和继承关系必须清楚地确定下来。每个图必须附有简单的说明。

5.5.1.2主体对象（类）描述

在这个部分叙述每个对象的细节，它的属性、它的方法。在这之前必须从逻辑上对对象进行组织。你可能需要用结构图把对象按子系统划分好。

为每个主体对象做一个条目。在系统对象模型中简要的描述它的用途、约束（如只能有一个实例），列出它的属性和方法。如果对象是存储在持久的数据容器中，标明它是持久对象，否则说明它是个临时对象（transient object）。

5.5.1.2.1对象（类）1

用途、约束、持久性；

5.5.1.2.2对象（类）2

5.5.2动态模型设计

这部分的作用是描述系统如何响应各种事件。例如，可以建立系统的行为模型。一般使用顺序图、活动图、状态图、协作图这些动态UML图。

确定不同的场景（Scenario）是第一步，不需要确定所有可能的场景，但是必须至少要覆盖典型的系统用例。不要自己去想当然地创造场景，通常的策略是描述那些客户可以感受得到的场景。

文档编号：ZIZI_SD_TEMP_SJSMS_YF 第10 页共12 页

对每个场景做一则条目，包括以下内容：

1.场景名：给它一个可以望文生义的名字

2.场景描述：简要叙述场景是干什么的以及发生的动作的顺序。

3.UML动态图：描述各种事件及事件发生的相对时间顺序、对象交互等。

5.5.2.1场景1

5.6应对变化设计

与界面有关的可能的变化包括五个部分，

1.数据模型的变化：包括实体属性的变化，实体类型的变化，实体关系的变化；

2.界面设计的变化：包括布局的变化、界面关系的变化、界面划分的变化

3.用户操作的变化；

4.功能目标的变化；

5.所依赖模块的接口的变化。

本设计针对预期中的这些变化，在不改动程序的结构的前提下可以采取的应对措施和方案。

与模型有关的可能的变化包括三个部分，

1.对象模型的变化：包括对象属性的变化，对象类型的变化，对象关系的变化；

2.是功能目标的变化；

3.是所依赖模块的接口的变化。

本设计针对预期中的这些变化，在不改动程序的结构的前提下可以采取的应对措施和方案。6子模块2设计

与上章雷同

文档编号：ZIZI_SD_TEMP_SJSMS_YF 第11 页共12 页

7约束和假定

描述系统设计中最主要的约束，这些是由客户强制要求并在需求说明书写明的。说明系统是如何来适应这些约束的。

另外如果本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助，那么系统可能还受到其它的约束。这种情况下，要求清楚地描述与本系统有交互的软件类型（比如某某某数据库软件，某某某EMail软件）以及这样导致的约束（比如只允许纯文本的Email）。

实现的语言和平台也会对系统有约束，同样在此予以说明。

对于因选择具体的设计实现而导致对系统的约束，简要地描述你的想法思路，经过怎么样的权衡，为什么要采取这样的设计等等

8遗留的问题

现有的设计目前没有处理的问题以及将来处理不了或很难处理的变化。

对于这些可能的变化之所以不进行处理是因为认定它们出现的几率较低或者耗费的资源过大，其恰当与否、全面与否留待本文档的评审会上决定。

文档编号：ZIZI_SD_TEMP_SJSMS_YF 第12 页共12 页