#软件设计规范-文档整理byCHA

1、软件设计规范目录概述 1数据库设计 4概述软件设计是把需求转化为软件系统的最重要的环节， 系统设计的优劣在根本上决定了软 件系统的质量。在此，主要阐述软件系统设计的 5 个核心内容：体系结构设计、用户界面设计、数据库 设计、模块设计、数据结构和算法设计。旨在帮助开发人员搞清楚“设计什么”以及“如何 设计”。一般把设计过程划分为两个阶段：概要设计阶段和详细设计阶段，如下所示： 概要设计阶段的重点是体系结构设计。详细设计阶段的重点是用户界面设计、 数据库设计、 模块设计、数据结构和算法设计等。 可根据项目的情况进行文档裁减和过程合并， 如项目开发过程只有一个设计阶段和设计 文档。体系结构体系结构如

2、同人的骨架。如果某个家伙的骨架是猴子，那么无论怎样喂养和美容，这家 伙始终都是猴子，不会成为人。由此可见，体系结构乃是系统设计的重中之重。目前业 界比较 流行的 软件结构 模式有 C/S（Client/Server 即客 户/ 服务器模 式）、 B/S（browers/servers 即浏览器和服务器 ）、层次结构 （ 上下级层次结构、 顺序相邻的层次结构、 含中间件的层次结构 ）体系结构设计原则 合适性。高水平的设计师高即体系结构是否适合于软件的“功能性需求”和“非功能性需求”就高在 “设计出恰好满足客户需求的软件， 并且使开发方和客户方获取最大的利益， 而不是 不惜代价设计出最先进的软件。

3、 结构稳定性详细设计阶段的工作如用户界面设计、 数据库设计、 模块设计、 数据结构和算法设计等 等，都是在体系结构确定之后开展的， 而编程和测试则是更后面的工作， 因此体系结构应在 一定的时间内保持稳定。软件开发最怕的就是需求变化， 但“需求会发生变化”是个无法逃避的现实。 人们希望 在需求发生变化时， 最好只对软件做些皮皮毛毛的修改， 可千万别改动软件的体系结构。 如 果当需求发生变化时， 程序员不得不去修改软件的体系结构， 那么这个软件的系统设计是失 败的。高水平的设计师应当能够分析需求文档， 判断出哪些需求是稳定不变的， 哪些需求是可 能变动的。 于是根据那些稳定不变的需求设计体系结构，

4、 而根据那些可变的需求设计软件的 “可扩展性” 。 可扩展性 可扩展性是指软件扩展新功能的容易程度。可扩展性越好，表示软件适应“变化” 的能 力越强。可扩展性越来越重要，这是由现代软件的商业模式决定的： 社会的商业越发达，需求变化就越快。需求变化必将导致修改（或者扩展 ）软件的功能，现代软件的规模和复杂性要比十年前的大得多（对比一下操作系统的变化就明白了 ），如果软件的可扩展性比较差的话，那么修改 （或者扩展 ）功能的代价会很高。现代软件产品通常采用“增量开发模式” ，开发商不断地推出软件产品的新版本，从而 不断地获取增值利润。如果软件的可扩展性比较差的话，每次开发新版本的代价就会很高。 虽然

5、开发商抓住了商机，但却由于设计水平差而导致没有赚取多少利润，真是要活活气死。 可复用性由经验可知， 通常在一个新系统中， 大部分的内容是成熟的， 只有小部分内容是创新的。 一般地可以相信成熟的东西总是比较可靠的（即具有高质量 ），而大量成熟的工作可以通过复用来快速实现 （即具有高生产率 ）。可复用性是设计出来的， 而不是偶然碰到的。 要使体系结构具有良好的可复用性， 设计 师应当分析使用域的共性问题， 然后设计出一种通用的体系结构模式， 这样的体系结构才可 以被复用。用户界面设计为了提高用户界面的易用性和美观程度， 总结了十个设计原则。 用于提高易用性的界面 设计原则有 8 个：用户界面适合于

6、软件的功能容易理解风格一致 及时反馈信息 出错处理 适应各种用户 国际化 个性化 用于提高美观程度的设计原则有 合理的布局和谐的色彩 用户界面适合于软件的功能 用户界面的合适性是指界面和软件功能相融洽的程度。 软件的功能需要通过用户界面来 展现， 用户界面一定要适合于软件的功能， 这是最基本的要求。 界面的合适性既提倡外美内 秀，又强调恰如其分。 容易理解 提高用户界面可理解性的一些规则如下： 界面中的所有元素 （如菜单、工具条等 ）没有错误，也不会让人误解。 所有的界面元素应当提供充分而必要的提示， 例如当鼠标移动到工具条上的某个图标按 钮时，应当在该图标旁边出现功能提示。界面结构能够清晰地

7、反映工作流程，以便用户按部就班地操作。 对于复杂的用户界面而言，最好提供界面“向导” ，及时让用户知道自己在界面结构中 所处的位置。例如对于基于 Web 的使用软件，应该在界面上显示“当前位置” ，否则用户很 容易在众多的页面中迷失方向。 风格一致风格一致有两方面的含义：（1）一个软件的用户界面中，同类的界面元素应当有相同的视感和相同的操作方式。例 如命令按钮是最常见的界面元素， 所有命令按钮的形状、 色彩以及对鼠标的响应方式都是一 致的。（2）同一类型软件的用户界面应当有一定程度的相似性。例如 Microsoft 公司的 Office 家族里有 Word 、Excel、PowerPoint

8、、Outlook 等软件， 这些软件提供的 “复制、 剪切、粘贴” 功能的操作方式都是相同的。 及时反馈信息用户进行某项操作后，如果过了一会儿（几秒钟 ）用户界面一点反应都没有，这将使用户感到迷茫和不安， 因为他不知道是自己操作错了还是软件的原因导致死机了。 所以及时反馈 信息很重要，至少要让用户心里有数，知道该任务处理得怎么样了，有什么样的结果。例如下载一个文件， 界面上应当显示 “百分比”或相关数字来表示下载的进度，否则人 们不知道要等待多少时间。 如果某些事务处理不能提供进度等数据， 那么至少要给出提示信 息如“正在处理，请等待” ，最好是提供合适的动画，让用户明白软件正在干活、没有死

9、机。 出错处理 在设计用户界面时必须考虑出错处理， 目的是让用户不必为避免犯错误而提心吊胆、 小 心翼翼地操作。常见的错误处理方式有：提供对输入数据进行校验的功能。当用户输入错误的数据时，及时提醒用户改正数据。对于在某些情况下不应该使用的菜单项和命令按钮，将其“失效”（屏蔽 ）可以有效防止该项功能被错误地使用。 例如： 对于某些管理软件，不同的用户有不同的操作权限。如果低 权限的用户登录到系统， 那些只有高级权限用户才能使用的功能应当被屏蔽（如变成“灰色”不可操作 ）。提供 Undo 功能，用以撤销不期望的操作。执行破坏性的操作之前， 应当获得用户的确认。 例如用户删除一个文件时， 应当弹出对

10、 话框：“真的要删除该文件吗” ，当用户确认后才真正删除文件。 合理的布局首先， 界面的布局应当符合逻辑， 最好能够和工作流程吻合。 界面设计人员只有仔细地分析软件的需求，才能提取对界面布局有价值的信息。其次，界面的布局应当整洁 （整齐清爽 ）。界面元素应当在水平或者垂直方向对齐，行、 列的间距保持一致。 窗体的尺寸要合适， 各种控件不能过分拥挤也不能过分宽松。 要善于利 用窗体和控件的空白，以及分割用的线条。 和谐的色彩用户界面是否美观， 主要取决于该界面的布局和色彩搭配。实现“合理的布局”相对比 较容易一些， 设计和谐的色彩太困难了， 因为色彩的组合千变万化， 并且人们对颜色的喜好 也极不

11、相同。对于广大软件开发人员而言，虽然我们没有必要让普通软件的界面漂亮到 Windows XP 这种程度，但是掌握一些界面色彩的设计原则无疑是非常有益的。如果不是为了显示真实感的图形和图像， 那么应当限制一帧屏幕的色彩数目， 因为人们 在观察屏幕的时候很难同时记住多种色彩。应当根据对象的重要性来选择颜色，重要的对象应当用醒目的色彩表示。 使用颜色的时候应当保持一致性， 例如错误提示信息用红色表示， 正常信息用绿色表示， 那么切勿篡用红色和绿色。在表达信息时，不要过分依赖颜色，因为有些用户是色盲或色弱。数据库设计 开发和平台无关的数据库使用程序目前国际上使用最广泛的数据库系统有Oracle、 DB

12、2、 Informix 、 Sybase 和 SQL Server。这些数据库系统之间的激烈竞争即有好处又有坏处。 竞争的好处是使数据库系统不断发 展和完善， 并且避免价格垄断。 竞争的最大坏处是逼迫数据库厂商不断开发出独特的功能以 吸引更多的用户， 所以各个数据库系统的独特功能无法形成统一标准， 导致用户难以开发出 和平台无关的数据库使用程序，因为用户很难抵御数据库系统独特功能的诱惑。读者也许会问： “结构化查询语言 （SQL）难道不是数据库系统的标准吗 ?”是的， SQL是数据库系统的标准查询语言。 可是数据库厂商提供了太多超出 SQL标准的 特色功能，使人们陷入了进退两难的境地：如果你想

13、使程序和数据库平台无关， 那么只能使用 SQL，放弃各个数据库系统的独特功 能。如果你超越 SQL，使用了某个数据库系统的独特功能， 那么这样的程序就是和平台相关 的。类似问题也存在于操作系统、 Web 浏览器这些领域。理论上讲，只有绝对垄断才能形 成绝对统一的标准， 但是人们既希望打破垄断又希望有统一的标准， 这种矛盾无法彻底解决， 只能折衷、妥协。建议如下：如果你开发的是通用的数据库使用软件， 不想让使用软件和特定的数据库系统捆绑在一 起，那么你就老老实实地用 SQL语言写程序。如果你开发的是行业专用的数据库使用软件，并且这个行业已经指定了数据库系统（这种局部垄断现象普遍存在 ），最近若干

14、年都不会改变的话，那么你可以超越SQL 使用该数据库系统的独特功能。 数据库性能优化问题数据库设计的主要挑战是“高速处理大容量的数据” 。如何优化数据库的性能是设计人 员经常面临的问题。数据库性能优化主要有两种途径：优化表结构本身。 例如对第三范式的表结构进行反规范化处理， 允许表中存在冗余数据， 从而减少多个表链接操作，达到提高性能的目的。优化数据库的环境参数。例如提高硬件设施，调整表的空间尽量减少数据碎片等。 在表的物理设计阶段，设计人员应当按照第三范式设计表结构（即规范化处理 ）。这样做的好处是： 表中没有冗余数据， 表结构很清晰，将来修改或者扩充非常方便。但是按第三范 式设计也存在一些

15、缺点： 产生了许多表， 每个表有相对较少的列， 并且这些列必须使用 “主 健/外健”关联起来，因此某个查询操作可能会产生复杂的表链接，导致性能降低。反规范化处理是指对第三范式的表进行修改， 通过合并一些表， 或者在表中创建冗余的 列，从而减少表链接操作代价， 达到提高性能的目的。 要注意的是反规范化处理存在很大的 负面影响： 管理冗余数据很麻烦， 如果冗余数据不同步的话， 那么会发生数据错误这种严重 的问题。所以，对表进行第三范式的规范化处理是第一重要的，而反规范化处理则需谨慎考虑、 不宜过多使用。 “规范化处理”以及“反规范化处理”不是自相矛盾之举，而是性能优化的 策略。除了优化表结构之外，

16、 优化数据库的环境参数也能够提高数据库的性能。 例如给服务器 配置更快的 CPU，增加内存。 运行数据库是非常消耗内存的， 内存对数据库性能影响比较大。 由于现在市场上的内存条越来越便宜， 所以为服务器配置足够多的内存恐怕是成本最低、 难 度最低、见效最快的性能优化方法。在安装数据库系统时，要为系统指定“块大小”（一次物理读写操作所设计的字节数 ）。在创建表时，也要为表指定一定的空间。如果“块大小”和“表空间”和实际的数据存储不 匹配的话，那么会产生许多磁盘碎片，这将降低数据库物理操作的性能。能否有效地优化使用软件数据库的性能， 主要取决于开发者对数据库系统的熟悉程度以 及开发经验。 数据库安

17、全问题提高软件系统的安全性应当从 “管理” 和“技术” 两方面着手。 这里仅考虑技术手段 （因 为安全管理超出了软件工程范畴 ），一般原则如下：用户只能用帐号登陆到使用软件， 通过使用软件访问数据库， 而没有其它途径可以操作 数据库。对用户帐号的密码进行加密处理，确保在任何地方都不会出现密码的明文。 确定每个角色对数据库表的操作权限，如创建、检索、更新、删除等。每个角色拥有刚 好能够完成任务的权限， 不多也不少。 在使用时再为用户分配角色， 则每个用户的权限等于 他所兼角色的权限之和。模块设计在设计好软件的体系结构后， 就已经在宏观上明确了各个模块应具有什么功能， 应放在 体系结构的哪个位置。

18、我们习惯地从功能上划分模块，保持“功能独立” 是模块化设计的基 本原则。因为， “功能独立”的模块可以降低开发、测试、维护等阶段的代价。但是“功能 独立” 并不意味着模块之间保持绝对的孤立。 一个系统要完成某项任务， 需要各个模块相互 配合才能实现，此时模块之间就要进行信息交流。评价模块设计优劣的三个特征因素： “信息隐藏” 、“内聚和耦合” 和“封闭开放性” 。 信息隐藏 为了尽量避免某个模块的行为去干扰同一系统中的其它模块， 在设计模块时就要注意信 息隐藏。应该让模块仅仅公开必须要让外界知道的内容，而隐藏其它一切内容。模块的信息隐藏可以通过接口设计来实现。接口是模块的外部特征，应当公开;而

19、数据结构、算法、实现体等则是模块的内部特征， 应当隐藏。一个模块仅提供有限个接口 （Interface） ， 执行模块的功能或和模块交流信息必须且只须通过调用公有接口来实现。如果模块是一个C+对象，那么该模块的公有接口就对应于对象的公有函数。如果模块是一个COM 对象，那么该模块的公有接口就是 COM对象的接口。一个 COM 对象可以有多个接口，而每个接 口实质上是一些函数的集合。 高内聚内聚 (Cohesion)是一个模块内部各成分之间相关联程度的度量。内聚程度从低到高大致 划分为低端、中段和高端，如图 3-15 所示。模块设计者没有必要确定内聚的精确级别，重 要的是尽量争取高内聚，避免低内

20、聚。顺序性内聚 功能性内聚时序性内聚 过程性内聚 通讯性内聚偶然性内聚 逻辑性内聚低端 中段 高端各种内聚类型的含义如下：偶然性内聚。 如果一个模块的各成分之间的关系彼此松散(几乎无关 )，称为偶然性内聚。逻辑性内聚。 几个逻辑上相关的功能被放在同一模块中，则称为逻辑性内聚。 例如一个模块读取各种不同类型外设的输入。时序性内聚。如果一个模块内的几个功能必须在同一时间内执行(如系统初始化 )，但这些功能只是因为时间因素关联在一起，则称为时间性内聚。过程性内聚。 如果一个模块内部的处理成分是相关的， 而且这些处理必须以特定的次序 执行，则称为过程性内聚。通信内聚。 如果一个模块的所有成分都操作同一

21、数据集或生成同一数据集， 则称为通信 内聚。顺序内聚。如果模块内的某个成分的输出作为另一个成分的输入，则称为顺序内聚。 功能内聚。模块的所有成分对于完成单一的功能都是必须的，则称为功能内聚。 低耦合耦合 (Coupling) 是模块之间依赖程度的度量。内聚和耦合是密切相关的，和其它模块存 在强耦合的模块通常意味着弱内聚， 而强内聚的模块通常意味着和其它模块之间存在弱耦合。耦合的强度依赖于以下几个因素： (1)一个模块对另一个模块的函数调用数量;(2)一个模块向另一个模块传递的数据量 ;(3)一个模块施加到另一个模块的控制的多少;(4)模块之间接口的复杂程度。耦合程度从低到高大致划分为低端、中段

22、和高端，如图 3-16 所示。模块设计应当争取 “高内聚、低耦合” ，而避免“低内聚、高耦合” 。印记耦合 控制耦合公共耦合 内容耦合非直接耦合 数据耦合低端 中段 高端各种耦合类型的含义如下： 非直接耦合。模块之间没有直接的信息传递，称为非直接耦合。 数据耦合。模块之间通过接口传递参数 (数据 )，称为数据耦合。 标记耦合。模块间通过接口传递内部数据结构的一部分(而不是简单的参数 )，称为印记(Stamp)耦合。此数据结构的变化将使相关的模块发生变化。控制耦合。模块传递信号 (如开关值、标志量等 )给另一个模块，接收信号的模块根据信 号值调整动作，称为控制耦合。公共耦合。两个以上的模块共同引

23、用一个全局数据项，称为公共耦合。内容耦合。 当一个模块直接修改或操作另一个模块的数据,或者直接转入另一个模块时，就发生了内容耦合。数据结构和算法设计设计高效率的程序是基于良好的数据结构和算法，而不是基于编程小技巧。一般说来，数据结构和算法就是一类数据的表示及其相关的操作(这里算法不是指数值计算的算法 )。从数据表示的观点来看， 存储在数组中的一个有序整数表也是一种数据结构。 算法是指对数据结构施加的一些操作，例如对一个线性表进行检索、插入、 删除等操作。一 个算法如果能在所要求的资源限制 (Resource Constraints) 范围内将问题解决好，则称这个算 法是有效率 (Efficient) 的。例如一个资源限制可能是“用于存储数据的内存有