软件开发详细设计说明书（软件工程设计说明书）
本篇文章给大家谈谈软件开发详细设计说明书，以及软件工程设计说明书对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：
在软件开发中，需求规格说明书和系统设计说明书有什么区别？
1、内容有区别
需求规格说明书主要是描述软件系统应该完成的功能，包含硬件、功能、性能、输入输出、接口需求、警示信息、保密安全、数据与数据库、文档和法规的要求等等。
设计说明书是说明如何实现这些功能、性能的。设计书中会对功能进行重新的分解，并需要描述这些功能如何实现，甚至包括如何用代码实现。
2、目的不同
需求规格说明书的作用在于便于用户、开发人员进行理解和交流，反映出用户问题的结构，可以作为软件开发工作的基础和依据，并作为确认测试和验收的依据。
系统设计说明书编制的目的是说明对程序系统的设计考虑，包括程序系统的基本处理流程、程序系统的组织结构、模块划分、功能分配、接口设计、运行设计、安全设计、数据结构设计和出错处理设计等，为程序的详细设计提供基础。
3、阅读对象不同
需求规格说明书主要从用户角度（需求或市场人员根据用户要求编写）描述软件需要实现的功能。
系统设计说明书主要从软件开发（程序员）角度描述软件需要实现功能。
参考资料：百度百科-软件需求说明书
参考资料：百度百科-概要设计说明书
Java企业软件开发设计说明书如何做
1、组织与风格(1).关键词和操作符之间加适当的空格。(2).相对独立的程序块与块之间加空行(3).较长的语句、表达式等要分成多行书写。(4).划分出的新行要进行适应的缩进，使排版整齐，语句可读。(5).长表达式要在低优先级操作符处划分新行，操作符放在新行之首。(6).循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分。(7).若函数或过程中的参数较长，则要进行适当的划分。(8).不允许把多个短语句写在一行中，即一行只写一条语句。(9).函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格。注：如果大家有兴趣可以到安安DIY创作室博客，有相关说明性的文章和解释。2、注解Java 的语法与 C++ 及为相似，那么，你知道 Java 的注释有几种吗？是两种？// 注释一行/* ...... */ 注释若干行不完全对，除了以上两种之外，还有第三种，文档注释：/** ...... */ 注释若干行，并写入 javadoc 文档注释要简单明了。String userName = null; //用户名边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。在必要的地方注释，注释量要适中。注释的内容要清楚、明了，含义准确，防止注释二义性。保持注释与其描述的代码相邻，即注释的就近原则。对代码的注释应放在其上方相邻位置，不可放在下面。对数据结构的注释应放在其上方相邻位置，不可放在下面；对结构中的每个域的注释应放在此域的右方；同一结构中不同域的注释要对齐。变量、常量的注释应放在其上方相邻位置或右方。全局变量要有较详细的注释，包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等的说明。在每个源文件的头部要有必要的注释信息，包括：文件名；版本号；作者；生成日期；模块功能描述（如功能、主要算法、内部各部分之间的关系、该文件与其它文件关系等）；主要函数或过程清单及本文件历史修改记录等。/*** Copy Right Information : Neusoft IIT* Project : eTrain* JDK version used : jdk1.3.1* Comments : config path* Version : 1.01* Modification history :2003.5.1* Sr Date Modified By Why What is modified* 1. 2003.5.2 Kevin Gao new**/在每个函数或过程的前面要有必要的注释信息，包括：函数或过程名称；功能描述；输入、输出及返回值说明；调用关系及被调用关系说明等/*** Description :checkout 提款* @param Hashtable cart info* @param OrderBean order info* @return String*/public String checkout(Hashtable htCart,OrderBean orderBean)throws Exception{}javadoc注释标签语法@author 对类的说明 标明开发该类模块的作者@version 对类的说明 标明该类模块的版本@see 对类、属性、方法的说明 参考转向，也就是相关主题@param 对方法的说明 对方法中某参数的说明@return 对方法的说明 对方法返回值的说明@exception 对方法的说明 对方法可能抛出的异常进行说明3、命名规范定义这个规范的目的是让项目中所有的文档都看起来像一个人写的，增加可读性，减少项目组中因为换人而带来的损失。（这些规范并不是一定要绝对遵守，但是一定要让程序有良好的可读性）较短的单词可通过去掉元音形成缩写；要不然最后自己写的代码自己都看不懂了，那可不行。较长的单词可取单词的头几发符的优先级，并用括号明确表达式的操作顺序，避免使用默认优先级。使用匈牙利表示法Package 的命名Package 的名字应该都是由一个小写单词组成。package com.neu.utilClass 的命名Class 的名字必须由大写字母开头而其他字母都小写的单词组成,对于所有标识符，其中包含的所有单词都应紧靠在一起，而且大写中间单词的首字母。public class ThisAClassName{}Class 变量的命名变量的名字必须用一个小写字母开头。后面的单词用大写字母开头userName , thisAClassMethodStatic Final 变量的命名static Final 变量的名字应该都大写，并且指出完整含义。/***DBConfig PATH**/public static final StringDB_CONFIG_FILE_PATH =com.neu.etrain.dbconfig;参数的命名参数的名字必须和变量的命名规范一致。数组的命名数组应该总是用下面的方式来命名：byte[] buffer;而不是：byte buffer[];方法的参数使用有意义的参数命名，如果可能的话，使用和要赋值的字段一样的名字：SetCounter(int size){this.size = size;}4、文件样式所有的 Java(*.java) 文件都必须遵守如下的样式规则：版权信息版权信息必须在 java 文件的开头，比如：/** Copyright ? 2000 Shanghai XXX Co. Ltd.* All right reserved.*/其他不需要出现在 javadoc 的信息也可以包含在这里。Package/Importspackage 行要在 import 行之前，import 中标准的包名要在本地的包名之前，而且按照字母顺序排列。如果 import 行中包含了同一个包中的不同子目录，则应该用 * 来处理。package hotlava.net.stats;import java io.*;import java.util.Observable;import hotlava.util.Application;这里 java。io.* 使用来代替InputStream and OutputStream 的。Class接下来的是类的注释，一般是用来解释类的。/*** A class representing a set of packet and byte counters* It is observable to allow it to be watched, but only* reports changes when the current set is complete*/接下来是类定义，包含了在不同的行的 extends 和 implementspublic class CounterSetextends Observableimplements CloneableClass Fields接下来是类的成员变量：/*** Packet counters*/protected int[] packets;public 的成员变量必须生成文档（JavaDoc）。proceted、private和 package 定义的成员变量如果名字含义明确的话，可以没有注释。存取方法接下来是类变量的存取的方法。它只是简单的用来将类的变量赋值获取值的话，可以简单的写在一行上。/*** Get the counters* @return an array containing the statistical data. This array has been* freshly allocated and can be modified by the caller.*/public int[] getPackets() { return copyArray(packets, offset); }public int[] getBytes() { return copyArray(bytes, offset); }public int[] getPackets() { return packets; }public void setPackets(int[] packets) { this.packets = packets; }其它的方法不要写在一行上构造函数接下来是构造函数，它应该用递增的方式写（比如：参数多的写在后面）。访问类型 (public, private 等.) 和 任何 static, final 或 synchronized 应该在一行中，并且方法和参数另写一行，这样可以使方法和参数更易读。publicCounterSet(int size){this.size = size;}克隆方法如果这个类是可以被克隆的，那么下一步就是 clone 方法：publicObject clone() {try {CounterSet obj = (CounterSet)super.clone();obj.packets = (int[])packets.clone();obj.size = size;return obj;}catch(CloneNotSupportedException e) {throw new InternalError(Unexpected CloneNotSUpportedException: +e.getMessage());}}类方法下面开始写类的方法：/*** Set the packet counters* (such as when restoring from a database)*/protected finalvoid setArray(int[] r1, int[] r2, int[] r3, int[] r4)throws IllegalArgumentException{//// Ensure the arrays are of equal size//if (r1.length != r2.length || r1.length != r3.length || r1.length != r4.length)throw new IllegalArgumentException(Arrays must be of the same size);System.arraycopy(r1, 0, r3, 0, r1.length);System.arraycopy(r2, 0, r4, 0, r1.length);}toString 方法无论如何，每一个类都应该定义 toString 方法：publicString toString() {String retval = CounterSet: ;for (int i = 0; i data.length(); i++) {retval += data.bytes.toString();retval += data.packets.toString();}return retval;}}main 方法如果main(String[]) 方法已经定义了, 那么它应该写在类的底部.5、代码可读性避免使用不易理解的数字，用有意义的标识来替代。不要使用难懂的技巧性很高的语句。源程序中关系较为紧密的代码应尽可能相邻。6、代码性能在写代码的时候，从头至尾都应该考虑性能问题。这不是说时间都应该浪费在优化代码上，而是我们时刻应该提醒自己要注意代码的效率。比如：如果没有时间来实现一个高效的算法，那么我们应该在文档中记录下来，以便在以后有空的时候再来实现她。不是所有的人都同意在写代码的时候应该优化性能这个观点的，他们认为性能优化的问题应该在项目的后期再去考虑，也就是在程序的轮廓已经实现了以后。不必要的对象构造不要在循环中构造和释放对象使用 StringBuffer 对象在处理 String 的时候要尽量使用 StringBuffer 类，StringBuffer 类是构成 String 类的基础。String 类将 StringBuffer 类封装了起来，（以花费更多时间为代价）为开发人员提供了一个安全的接口。当我们在构造字符串的时候，我们应该用 StringBuffer 来实现大部分的工作，当工作完成后将 StringBuffer 对象再转换为需要的 String 对象。比如：如果有一个字符串必须不断地在其后添加许多字符来完成构造，那么我们应该使用StringBuffer 对象和她的 append() 方法。如果我们用 String 对象代替StringBuffer 对象的话，会花费许多不必要的创建和释放对象的 CPU 时间。大家可以来安安DIY创作室一起讨论。避免太多的使用 synchronized 关键字避免不必要的使用关键字 synchronized，应该在必要的时候再使用她，这是一个避免死锁的好方法。7、编程技巧byte 数组转换到 characters为了将 byte 数组转换到 characters，你可以这么做：Hello world!.getBytes();Utility 类Utility 类（仅仅提供方法的类）应该被申明为抽象的来防止被继承或被初始化。初始化下面的代码是一种很好的初始化数组的方法：objectArguments = new Object[] { arguments };枚举类型JAVA 对枚举的支持不好，但是下面的代码是一种很有用的模板：class Colour {public static final Colour BLACK = new Colour(0, 0, 0);public static final Colour RED = new Colour(0xFF, 0, 0);public static final Colour GREEN = new Colour(0, 0xFF, 0);public static final Colour BLUE = new Colour(0, 0, 0xFF);public static final Colour WHITE = new Colour(0xFF, 0xFF, 0xFF);}这种技术实现了RED, GREEN, BLUE 等可以象其他语言的枚举类型一样使用的常量。他们可以用 '==' 操作符来比较。但是这样使用有一个缺陷：如果一个用户用这样的方法来创建颜色 BLACK new Colour(0,0,0)那么这就是另外一个对象，'=='操作符就会产生错误。她的 equal() 方法仍然有效。由于这个原因，这个技术的缺陷最好注明在文档中，或者只在自己的包中使用。8、编写格式代码样式代码应该用 unix 的格式，而不是 windows 的（比如：回车变成回车+换行）文档化必须用 javadoc 来为类生成文档。不仅因为它是标准，这也是被各种 java 编译器都认可的方法。使用 @author 标记是不被推荐的，因为代码不应该是被个人拥有的。缩进缩进应该是每行2个空格. 不要在源文件中保存Tab字符. 在使用不同的源代码管理工具时Tab字符将因为用户设置的不同而扩展为不同的宽度.如果你使用 UltrEdit 作为你的 Java 源代码编辑器的话，你可以通过如下操作来禁止保存Tab字符, 方法是通过 UltrEdit中先设定 Tab 使用的长度室2个空格，然后用 Format|Tabs to Spaces 菜单将 Tab 转换为空格。页宽页宽应该设置为80字符. 源代码一般不会超过这个宽度, 并导致无法完整显示, 但这一设置也可以灵活调整. 在任何情况下, 超长的语句应该在一个逗号或者一个操作符后折行. 一条语句折行后, 应该比原来的语句再缩进2个字符.{} 对{} 中的语句应该单独作为一行. 例如, 下面的第1行是错误的, 第2行是正确的:if (i0) { i ++ }; // 错误, { 和 } 在同一行if (i0) {i ++}; // 正确, { 单独作为一行} 语句永远单独作为一行.如果 } 语句应该缩进到与其相对应的 { 那一行相对齐的位置。括号左括号和后一个字符之间不应该出现空格, 同样, 右括号和前一个字符之间也不应该出现空格. 下面的例子说明括号和空格的错误及正确使用:CallProc( AParameter ); // 错误CallProc(AParameter); // 正确不要在语句中使用无意义的括号. 括号只应该为达到某种目的而出现在源代码中。下面的例子说明错误和正确的用法:if ((I) = 42) { // 错误 - 括号毫无意义if (I == 42) or (J == 42) then // 正确 - 的确需要括号9、代码编译1.编写代码时要注意随时保存，并定期备份，防止由于断电、硬盘损坏等原因造成代码丢失。2.同一项目组内，最好使用相同的编辑器，并使用相同的设置选项。3.合理地设计软件系统目录，方便开发人员使用。4.打开编译器的所有告警开关对程序进行编译。5.在同一项目组或产品组中，要统一编译开关选项。6.使用工具软件（如Visual SourceSafe）对代码版本进行维护。如果大家有不明白的可以到安安DIY创作室留言。10、可移植性Borland Jbulider 不喜欢 synchronized 这个关键字，如果你的断点设在这些关键字的作用域内的话，调试的时候你会发现的断点会到处乱跳，让你不知所措。除非必须，尽量不要使用。换行如果需要换行的话，尽量用 println 来代替在字符串中使用\n。你不要这样：System.out.print(Hello,world!\n);要这样：System.out.println(Hello,world!);或者你构造一个带换行符的字符串，至少要象这样：String newline = System.getProperty(line.separator);System.out.println(Hello world + newline);PrintStreamPrintStream 已经被不赞成（deprecated）使用，用 PrintWrite 来代替它。
软件详细设计说明书
面向对象软件设计说明书模板
1 概述
1.1 系统简述
对系统要完成什么，所面向的用户以及系统运行的环境的简短描述，这部分主要来源于需求说明书的开始部分。
1.2 软件设计目标
这部分论述整个系统的设计目标，明确地说明哪些功能是系统决定实现而哪些时不准备实现的。同时，对于非功能性的需求例如性能、可用性等，亦需提及。需求规格说明书对于这部分的内容来说是很重要的参考，看看其中明确了的功能性以及非功能性的需求。
这部分必须说清楚设计的全貌如何，务必使读者看后知道将实现的系统有什么特点和功能。在随后的文档部分，将解释设计是怎么来实现这些的。
1.3 参考资料
列出本文档中所引用的参考资料。（至少要引用需求规格说明书）
1.4 修订版本记录
列出本文档修改的历史纪录。必须指明修改的内容、日期以及修改人。
2 术语表
对本文档中所使用的各种术语进行说明。如果一些术语在需求规格说明书中已经说明过了，此处不用再重复，可以指引读者参考需求说明。
3 用例
此处要求系统用用例图表述（UML），对每个用例（正常处理的情况）要有中文叙述。
4 设计概述
4.1 简述
这部分要求突出整个设计所采用的方法（是面向对象设计还是结构化设计）、系统的体系结构（例如客户/服务器结构）以及使用到的相应技术和工具（例如OMT、Rose）
4.2 系统结构设计
这部分要求提供高层系统结构的描述，使用方框图来显示主要的组件及组件间的交互。最好是把逻辑结构同物理结构分离，对前者进行描述。别忘了说明图中用到的俗语和符号。
4.2.1 顶层系统结构
4.2.2 子系统1结构
4.2.3 子系统2结构
4.3 系统界面
各种提供给用户的界面以及外部系统在此处要予以说明。如果在需求规格说明书中已经对用户界面有了叙述，此处不用再重复，可以指引读者参考需求说明。如果系统提供了对其它系统的接口，比如说从其它软件系统导入/导出数据，必须在此说明。
4.4 约束和假定
描述系统设计中最主要的约束，这些是由客户强制要求并在需求说明书写明的。说明系统是如何来适应这些约束的。
另外如果本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助，那么系统可能还受到其它的约束。这种情况下，要求清楚地描述与本系统有交互的软件类型（比如某某某数据库软件，某某某EMail软件）以及这样导致的约束（比如只允许纯文本的Email）。
实现的语言和平台也会对系统有约束，同样在此予以说明。
对于因选择具体的设计实现而导致对系统的约束，简要地描述你的想法思路，经过怎么样的权衡，为什么要采取这样的设计等等。
5 对象模型
5.1 系统对象模型
提供整个系统的对象模型，如果模型过大，按照可行的标准把它划分成小块，例如可以把客户端和服务器端的对象模型分开成两个图表述。
对象图应该包含什么呢？
在其中应该包含所有的系统对象。这些对象都是从理解需求后得到的。要明确哪些应该、哪些不应该被放进图中。
所有对象之间的关联必须被确定并且必须指明联系的基数（一对一、一对多还是多对多，0..1，*，1..*）。聚合和继承关系必须清楚地确定下来。每个图必须附有简单的说明。
可能经过多次反复之后才能得到系统的正确的对象模型。
6 对象描述
在这个部分叙述每个对象的细节，它的属性、它的方法。在这之前必须从逻辑上对对象进行组织。你可能需要用结构图把对象按子系统划分好。
为每个对象做一个条目。在系统对象模型中简要的描述它的用途、约束（如只能有一个实例），列出它的属性和方法。如果对象是存储在持久的数据容器中，标明它是持久对象，否则说明它是个临时对象（transient object）。
对每个对象的每个属性详细说明：名字、类型，如果属性不是很直观或者有约束（例如，每个对象的该属性必须有一个唯一的值或者值域是有限正整数等）。
对每个对象的每个方法详细说明：方法名，返回类型，返回值，参数，用途以及使用的算法的简要说明（如果不是特别简单的话）。如果对变量或者返回值由什么假定的话，Pre-conditions和Post-conditions必须在此说明。列出它或者被它调用的方法需要访问或者修改的属性。最后，提供可以验证实现方法的测试案例。
6.1 子系统1中的对象
6.1.1 对象：对象1
用途：
约束：
持久性：
6.1.1.1 属性描述：
1. 属性：属性1
类型：
描述：
约束：
2. 属性：属性2
6.1.1.2 方法描述：
1. 方法：方法1
返回类型：
参数：
返回值：
Pre-Condition：
Post-Condition：
读取/修改的属性：
调用的方法：
处理逻辑：
测试例：用什么参数调用该方法，期望的输出是什么……
7 动态模型
这部分的作用是描述系统如何响应各种事件。例如，可以建立系统的行为模型。一般使用顺序图和状态图。
确定不同的场景（Scenario）是第一步，不需要确定所有可能的场景，但是必须至少要覆盖典型的系统用例。不要自己去想当然地创造场景，通常的策略是描述那些客户可以感受得到的场景。
7.1 场景（Scenarios）
对每个场景做一则条目，包括以下内容：
场景名：给它一个可以望文生义的名字
场景描述：简要叙述场景是干什么的以及发生的动作的顺序。
顺序图：描述各种事件及事件发生的相对时间顺序。
7.1.1 场景：场景1
描述：
动作1
动作2
7.2 状态图
这部分的内容包括系统动态模型重要的部分的状态图。可能你想为每个对象画一个状态图，但事实上会导致太多不期望的细节信息，只需要确定系统中一些重要的对象并为之提供状态图即可。
7.2.1 状态图1：
8 非功能性需求
在这个部分，必须说明如何处理需求文档中指定的非功能性需求。尽可能客观地评估系统应付每一个非功能性的需求的能力程度。如果某些非功能性需求没有完全在设计的系统中实现，请务必在此说明。另外，你也需要对系统将来的进化作一个估计并描述本设计如何使系统能够适应这些可预见的变化。
9 辅助文档
提供能帮助理解设计的相应文档。
10 词汇索引
文章录入
软件开发详细设计说明书的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于软件工程设计说明书、软件开发详细设计说明书的信息别忘了在本站进行查找喔。
