实用软件工程
本章导读\r\n 软件需求是软件设计的基础，软件设计是软件开发的核心。\r\n 本章首先讨论软件设计概论和软件设计原理，然后介绍软件架构设计和软件详细设计，重点是论述面向过程、面向数据和面向对象的三种详细设计方法，以及软件设计的属性和度量。最后介绍IT企业的软件设计文档和设计管理文档编写的参考指南。
本章对读者的要求
了解：\r\n (1）软件设计的输入输出\r\n (2）概要设计与详细设计之间的差异\r\n (3）命名规范的概念 \r\n 理解：\r\n (1）软件设计原理\r\n (2）软件架构设计方法\r\n (3）软件详细设计概念\r\n (4）软件设计属性和度量\r\n (5）软件设计管理文档
本章对读者的要求
掌握：\r\n (1）面向过程详细设计\r\n (2）面向数据详细设计\r\n (3) 面向对象详细设计\r\n (4）《概要设计说明书》的编写方法\r\n (5）《详细设计说明书》的编写方法
6.1 设计方法概论
软件设计的输入是《需求规格说明书》，输出是《概要设计说明书》和《详细设计说明书》。\r\n概要设计\r\n 概要设计，一是要覆盖《需求规格说明书》的全部内容，二是要作为指导详细设计的依据。\r\n 概要设计注重于宏观上和框架上的设计，它是软件系统的总体结构设计、全局数据库(包括数据结构)设计、外部接口设计、功能部件分配设计、部件之间的接口设计。\r\n 概要设计又称为架构设计。
详细设计
详细设计，一是要覆盖《概要设计说明书》的全部内容，二是要作为指导程序设计的依据。\r\n 详细设计注重于微观上和框架内的设计，它是各子系统的公用部件实现设计、专用模块实现设计、存储过程实现设计、触发器实现设计、外部接口实现设计、部门角色授权设计、其他详细设计等。\r\n 模块实现设计包括：登录注册模块设计、信息发布模块设计、菜单模块设计、录入修改模块设计、查询统计模块设计、业务逻辑处理模块设计、报表输出模块设计、前台网站模块设计、后台数据处理模块设计、数据传输与接收模块设计等等。
详细设计
在设计之前要确定命名规范。包括系统命名规范，模块命名规范，构件命名规范，变量命名规范，以及表名、字段名、索引名、视图名、存储过程名的命名规范等。\r\n 软件设计时，一方面要善于将需求规格说明书中的冗余去掉，将公用功能提炼出来，并将它设计为构件，标准化后加入到公司构件库中。另一方面，还要尽量调用公司构件库中已有的构件。\r\n 按照“五个面向理论”，概要设计主要方法是面向数据，详细设计和程序设计主要方法是面向对象。\r\n 所有的详细设计都是面向模块(部件/构件)的，不是面向组织结构或部门单位的。一个组织或单位，根据角色的不同授权，可以挂上不同的模块或部件。
*6.2 软件设计原理
“设计”在IEEE中的定义是：“定义一个系统或部件的架构、组成、接口或其它特征的过程”。\r\n 软件设计是一个过程，它是软件生命周期中的一部分，是对软件需求分析后产生软件内部结构的一种描述。软件设计的结果，应能描述软件的架构，即软件中各个部件是如何分解并组合在一起的。\r\n 架构设计有时也称为概要设计，用于描述系统最顶的结构和组织形式，标识出软件的各个组成部分。\r\n 详细设计用于详细描述每个部件的内部结构，用以指导程序人员编写代码，便于每个部件能够得以顺利实现。
原理1：抽象
(1) 控制抽象\r\n 面向过程设计 ，通过控制抽象(控制流程和接口)，对软件进行分解，达到降低软件复杂度的目的。\r\n 面向对象设计 ，通过数据抽象和控制抽象，实现使数据和控制溶为一体，构成一个完整的对象。\r\n (2) 过程抽象\r\n 将数据处理抽象成函数或方法，获得最终的执行结果，而不必去关心它们的内部实现细节。\r\n (3) 数据抽象\r\n 在数据库建模和面向对象建模时，使用数据抽象，设计出数据库的表及字段，或设计出类及类的属性。
原理2：分解
将一个软件分解成许多小模块(代码行在200~400之间)，不同模块负责不同的功能。\r\n (1) 在架构设计中，将软件系统分解为子系统和模块；\r\n (2) 在详细设计中，将子系统和模块分解成类和接口。
原理3：低耦合高内聚
模块在系统中不能孤立存在，每个模块具有一定的功能，他们共同完成系统的总功能，这样模块之间就必然会存在联系或依赖。\r\n 对于低内聚的模块，通过重新分解，来提高模块内部的紧凑性，使其成为高内聚模块，从而降低块间联系，提高模块的独立性。\r\n 对于高耦合的模块，通过重新组合，将联系紧密的部分组合成新的模块，使其成为低耦合模块，从而提高模块的可维护性。\r\n 模块耦合程度由低到高的分级如下：
(1) 数据耦合(或参数传递耦合)，属于低级别耦合。例如，模块间通过参数传递或数据结构来访问。\r\n (2) 控制耦合，属于中级别耦合。例如，操作系统中的进程调度程序，通过就绪进程的优生级来调度。那么调度程序与进程之间的耦合，就是控制耦合。\r\n (3) 外部耦合(或共用耦合)，它属于高级别耦合。例如，模块间共享全局变量，或共同访问全局数据区中的数据项，就是共用耦合。\r\n (4) 内容耦合，它属于最高级别耦合。例如，一个模块利用分支或跳转技术，转入到另一个模块中去执行，就是内容耦合。\r\n 耦合可发生在软件设计、软件编程之中。
原理4：封装
封装是将信息隐藏在一个实体中，使其内部细节对外部不可见。\r\n 封装是实现“低耦合高内聚”的技术手段之一。要进行正确的封装，必须遵守下列原则：\r\n (1). 实体间相互隐藏内部实现；\r\n (2). 尽量减少全局的共享数据。
原理5：接口和实现分离
接口和实现分离的思想起源很早。上世纪五十年代，就出现了“子程序和函数”的概念，人们在实现和调用它们的时候，就运用了这种思想。\r\n 将接口和实现分离开来，对外只提供接口，隐藏具体实现。接口与实现的分离，保证了实现的独立变化，降低了模块间的耦合。
*6.3 软件架构设计
当对象、类、构件、组件等概念出现并成熟之后，软件概要设计（总体设计/系统设计），就改名为架构设计。\r\n1.架构设计基本概念\r\n (1) 系统\r\n 系统是部件的集合，以完成某项特定的功能。\r\n (2) 架构\r\n 架构是描述系统中部件间相互关系及部件与环境间相互关系的基本框架。\r\n 架构就是使用别人搭好的舞台，你来做表演。
1. 架构设计基本概念(续)
(3) 系统架构\r\n 系统架构是实体、实体属性以及实体关系的集合。\r\n(4) 软件架构\r\n 软件架构是软件部件、部件属性以及它们之间相互作用的集合，以描述软件系统的基本属性和限制条件。\r\n 架构及软件架构尚处在发展期，对于其定义，学术界尚未形成一个统一的意见，而不同角度的视点也会造成对软件架构的不同理解。
1. 架构设计基本概念(续)
(5) 架构视图\r\n 架构视图，是指从一个特定的视角对系统或系统的一部分进行描述。架构可以用不同的架构视图进行描述，例如逻辑视图用于描述系统功能，进程视图用于描述系统并发，物理视图用于描述系统部署。\r\n(6) 架构视点\r\n 架构视点描述如何创建和使用架构视图，包含名称、涉众、关注点、建模规则等信息。\r\n(7) 软件架构建模\r\n 软件架构建模，是与软件架构定义和管理相关的分析、设计、文档化、评审等活动。
1. 架构设计基本概念(续)
(8) 软件架构建模的目的：\r\n a. 捕获早期的设计决策。设计决策将影响到后续设计、开发、部署、维护和演变。\r\n b. 捕获软件运行环境。\r\n c. 为底层实现提供限制条件。\r\n d. 为开发团队的结构组成提供依据。\r\n e. 设计系统满足可靠性、可维护性、其他性能等。\r\n f. 方便开发团队间的交流。
1. 架构设计基本概念(续)
(9) 软件架构应描述以下问题：\r\n a. 软件系统中包含了哪些子系统 / 部件。\r\n b. 每个子系统 / 部件都完成哪些功能。\r\n c. 子系统 / 部件对外提供或使用外部的哪些接口。\r\n e. 子系统 / 部件间的依赖关系，以及对实现和测试的影响。\r\n f. 系统是如何部署的。\r\n软件架构不包括硬件、网格以及物理平台的设计。软件架构只描述创建软件所需要的各种环境，而不是详细描述整个系统。
2. 软件架构风格(模式)
定义1：\r\n 模式(pattern)是表示周境、动机、解决方案三个方面关系的一个规则，模式描述了一个在某种周境下不断重复发生的问题，以及该问题解决方案的核心所在，模式既是一个事物（thing）又是一个过程(process)，不仅描述该事物本身，而且提出了通过怎样的过程来产生该事物。\r\n 定义2：\r\n 模式就是解决某一类问题的方法论。你把解决某类问题的方法总结归纳到理论高度，那就是模式。
模式1：数据流模式
数据流系统的特点是包含两个或多个数据处理的部件，数据处理部件将输入转换为输出。典型的数据流系统包括：\r\n a. 批处理程序\r\n b. 管道/过滤器程序\r\n 数据处理部件以顺序的方式依次处理数据，前一个处理部件的输出作为下一个处理部件的输入。这种形式也称为管道，如图6-2、6-3所示。
数据流模式
模式2：调用返回模式
调用返回系统的特点是包含一个主控制器，由它来控制操作的调用。典型的调用返回系统包括：\r\n a. 主程序 / 子程序\r\n b. 远程过程调用系统\r\n 主程序 / 子程序系统是经典的系统架构，例如C程序和C 程序都有一个主程序来控制系统的执行，如图6-4所示。
调用返回模式
模式3：虚拟机模式
虚拟机系统执行规定的语言符号，为其它的技术提供一个语义层。虚拟机结构通常由四个主要部件组成：解释引擎、包含“伪程序”的内存、解释引擎控制状态、程序的执行状态。 \r\n 典型的虚拟机系统包括：\r\n a. 工作流系统\r\n b. 游戏程序\r\n c. 大型ERP
模式4：共享数据模式
共享数据系统以一个或多个数据库 / 数据仓库为中心进行组织，其它部件可以从中读写存储的数据。共享数据系统还提供并发访问、容错处理、访问权限控制等功能。\r\n 典型的共享数据系统包括：\r\n a. 数据库\r\n b. 知识库\r\n c. 源代码控制程序
模式5：信息系统模式
现代信息系统平台模式，主要考虑B/S模式。\r\n B/S模式的三层：表示层（presentation），业务层（business），和数据存储层（data access）。\r\n B/S模式的优点：\r\n a. 架构简化了客户端。它无需象C/S模式那样在不同的客户机上安装不同的客户应用程序，而只需安装通用的浏览器软件。\r\n b. 简化了系统的开发和维护。\r\n c. 使用户的操作变得更简单。\r\n d. 特别适用于网上信息发布 。
模式6：数据库设计模式
第三者插足模式。\r\n列变行模式。\r\n四个原子化模式。\r\n用视图进行数据处理模式。
6.4 软件详细设计
软件详细设计，又称为软件实现设计。若在概要设计中将软件系统划分为各个不同的子系统，则详细设计就是各个子系统的实现设计。若在概要设计中将软件系统划分为各个不同的模块，则详细设计就是各个模块的实现设计。若在概要设计中将软件系统划分为各个不同的部件，则详细设计就是各个部件的实现设计。\r\n 本节分别介绍面向过程、面向数据和面向对象三种详细设计方法，重点是说明这三种详细设计方法的实质、各自的描述工具及其相互之间的关系。
详细设计的任务与步骤
1. 基本任务 回答的关键问题：“怎样具体地实现这个系统”。主要任务是设计出程序的“蓝图”,供程序员日后根据这个蓝图编写出实际的程序代码。 2. 基本步骤 a. 确定模块如何实现 b. 编写详细设计说明书 c. 制定单元测试计划 d. 评审详细设计
6.4.1 面向过程详细设计
面向过程详细设计，实质上就是面向算法分析设计，是其他各种详细设计的基础。\r\n 一般而言，面向过程详细设计的描述工具有下列四种：\r\n1. 流程图(Flowchart)\r\n 流程图是用图形化的方式，表示程序中一系列的操作以及操作执行的顺序，其表示元数如表6-2所示。
流程图(Flowchart)
【例6-1】 使用流程图，描述并打印N的阶乘，如图6-6所示。
2. N-S图(Nassi-Schneiderman Diagram)
N-S图是流程图的另一种表达形式，由Nassi和Schneiderman提出，简称N-S图。与流程图对应的三种结构 (顺序、分支、循环)，用图形表示。如图6-7所示。
3. 程序设计语言PDL
程序设计语言也称结构化英语或伪代码，它使用结构化编程语言的风格描述程序算法，但不遵循特定编程语言的语法。程序设计语言允许你在比源代码更高的层次上进行设计。\r\n 【例6-3】 使用程序设计语言描述打印N的阶乘\r\n 读入N\r\n 置F的值为1，置M的值为1\r\n 当M <= N时，执行：\r\n 使F = F * M\r\n 使 M= M 1\r\n 打印F
4. 决策表(DT)
决策表以紧凑的形式描述复杂的逻辑。决策表与if-else、switch-case语句类似，将条件判断与执行的动作联系起来。\r\n 决策表通常分成四个区域，如右图6-9所示。
【例6-4】 条件对应于一个变量、关系或预测，其可能的组合在条件选择中列出。动作是一个函数或操作。动作选择当条件满足时所执行的动作，如右图6-10所示。
5. 日本的PAD
PAD是问题分析图（Problem Analysis Diagram）的英文缩写，由日立公司发明，已经得到推广。\r\n PAD图有以下优点：\r\n a.使用PAD图设计出来的程序必然是结构化的程序； b. PAD图所描述的程序结构非常清晰； c. PAD图表现的程序逻辑易读、易懂、易记； d. 容易将PAD图转换成程序； e. PAD图还可以描述数据结构； f. PAD图支持自顶向下、逐步求精方法的使用。
6.4.2 面向数据详细设计
面向数据设计，它以实体--关系模型为基础，按照一定的规则将概念数据模型CDM转换成能被某种数据库管理系统接受的物理数据模型PDM，创建物理上的数据库表、索引和视图，并且用存储过程和触发器来实现各种业务规则。\r\n 实践证明，凡是用存储过程能实现触发器功能的地方，就坚决用存储过程，而不用触发器，因为过多的触发器不但影响数据库的运行性能，而且可能导致数据库系统崩溃。
面向数据详细设计
面向数据详细设计，实质上就是面向元数据详细设计。元数据是数据库和数据仓库中的重要概念，元数据是关于数据的数据，组织数据的数据，领导数据的数据，管理数据的数据。\r\n 在详细设计时，对于这些元数据，都要用图形、数据字典或文字进行详细描述。对存储过程中的算法，也要进行详细设计。因此，面向数据详细设计的描述工具，主要是概念数据模型CDM、物理数据模型PDM和存储过程。80%以上的工作，可以在CDM上完成。
面向数据详细设计
在图6-11中，需要说明2点。\r\n （1）图书与图册关系的理解与处理。\r\n 实体“图书”与实体“图册”之间的关系，是一对多关系。这种处理的好处是：读者预借或者借阅，只是直接与图册打交道，而不直接与图书打交道，从而防止了极少数读者将别人的图册偷来冒称自已的图册还书。\r\n （2）多对多关系的理解与处理。\r\n 实体“读者”与实体“图册”之间的关系，是多对多关系，这种多对多的复杂关系，是通过两个实体“预约记录”和“借阅记录”来简化的。而实体“图书”与实体“作者”之间的多对多关系，是通过实体“图书作者”来简化的。
面向数据详细设计
由于CASE工具Power Designer具有正向和逆向的双向功能，所以既可以从CDM生成PDM，又可以从PDM生成CDM。由此可见，数据模型设计，也可以从PDM开始进行。\r\n 在详细设计时，对于图6-12中物理数据模型中的表名和字段名，以及在此基础上产生的索引名、视图名、存储过程名都要进行详细定义与解释，对存储过程中的算法也要具体说明。同时，还要对数据库的表结构与系统的录入界面及输出报表之间的关系，作出详尽的描述。
6.4.3 面向对象详细设计
软件系统的架构设计完成后，利用UML的描述工具：类图、顺序图、状态图、部件图、部署图，分别将架构中的部件(组件/构件)进行实现设计，直到可以编程为止；\r\n 在实现设计中，对类类的属性定义、类的方法算法、接口说明、接口实现、类之间的关系、对象与消息之间的关系、实体之间的状态转换，均要详细说清楚。
*6.4.4 软件详细设计方法总结
运用详细设计的描述工具，将架构内的构件，设计成编程实现的兰图，就是详情设计。\r\n 对于B/S的系统，“面向数据方法用在数据库服务器层次上系统的设计与实现，面向对象方法用在除数据库服务器层次之外的其他层次上系统的设计与实现，面向过程方法用在其他两种方法本身内部函数的设计与实现”。\r\n 这三种方法是互相帮助、取长补短、彼此有关的。一般而言，对于一个大型信息系统的建设，由于其分析、设计、实现、测试、维护的重点是数据库服务器上的数据，所以在实施的过程中，在宏观上仍然要遵守“五个面向”的实施理论，即：“面向流程分析、面向数据设计、面向对象实现、面向功能测试、面向过程管理”。
*6.5 软件属性和度量 6.5.1 设计属性
软件架构的设计属性，表现在它们的可用性和可管理性上。\r\n1．可用性\r\n 可用性是系统正常运行时间的概率，即：\r\n可用性=平均正常工作时间 /\r\n（平均正常工作时间 平均修复时间）
影响可用性的因素
不充分的测试。 \r\n更改管理问题。 \r\n缺少在线监视和分析。 \r\n操作错误。 \r\n弱编码。 \r\n与外部服务或应用程序的交互。 \r\n不同的操作条件（使用级别更改、峰值重载）。 \r\n异常事件（安全性失败、广播风暴）。 \r\n硬件故障（硬盘、控制器、网络设备、服务器、电源、内存和 CPU）。 \r\n环境问题（电源、冷却、火、洪水、灰尘、自然灾害）。
提高可用性的办法
(1)使用群集。\r\n 集群包括至少将两个系统连接到一起，使两个服务器能够像一台机器那样工作或者看起来好像一台机器。 \r\n 集集是高可用性的关键技术，因为它在出现失败时，提供即时故障转移应用程序服务。\r\n (2)使用网络负载平衡。\r\n “网络负载平衡”(NLB) ，它通过检测某服务器失败后，能自动将通信量重新分发给仍然运行的服务器。
提高可用性的办法(续)
(3)使用服务级别协议。\r\n 定义期望的服务级别。这样的服务级别协议应包括这样的细节：“该应用程序应每周 7 天、每天 24 小时运行，年可用性为 99.9%”。\r\n (4)提供实时的监视。\r\n 连续监视操作工作负荷和失败数据，对于发现趋势和改善服务至关重要。\r\n (5) 使用数据备份。\r\n (6) 检查所有安全计划。\r\n 安全性是指确保应用程序服务只对有资格的用户可用。安全性还意味着保护应用程序使用的所有分布式组件和资源。
2. 可管理性
（1）可靠性\r\n 软件可靠性是指应用程序能在多大程度上，在不发生失败的情况下，准确地提供在原始规范中定义的服务：\r\n 可靠性 = 小时数 / 失败次数\r\n 例如，假设预期应用程序提供的可靠性为：每天 24 小时操作，每 30 天发生一次失败（大约每 720 小时失败一次）。测试表明应用程序运行 1800 小时中发生两次失败，所以，\r\n可靠性 = 1800/2 = 900 小时\r\n 软件可靠性的一个重要概念，是当软件发生失败时，软件仍可用并继续执行的程度。
2. 可管理性(续)
(2) 可维护性\r\n 可移植性：软件系统能否在不同的硬件、操作系统上运行。\r\n 可修改性：添加新功能或修改现有功能的难易程度。可修改性差的系统有以下表现：\r\n a. 脆弱。修改脆弱的软件系统将破坏现有的功能。\r\n b. 僵化。软件系统难以用简单的方式进行修改。\r\n c. 重复。重复代码散布各个角落，使之难于修改。\r\n 易理解性：只有理解原有的系统才能对它进行修改。\r\n 可调试性：支持多级的在线调试。
2. 可管理性(续)
(3) 其它属性\r\n 文化适应性：是否提供多语言版本支持，提供对不同文件差异的支持。\r\n 可测试性：软件可以有效的测试。\r\n 易用性：提供友好的人机界面。\r\n 危险性：系统对现实世界不会带来灾难。
6.5.2 设计度量
设计度量是指评估和量化软件设计的结构、质量等方面的属性，用于项目的质量控制和进度控制。\r\n1. 面向过程设计的度量\r\n (1) 内聚度量\r\n 利用数据切片对功能内聚进行度量。内聚度量SFC则是超级胶合数据与所有数据的比值：\r\n\r\n\r\n\r\n\r\n\r\n SFC的值越大，内聚程度越高。
参数及符号说明：
SFC：strong functional cohesion(强功能性内聚)\r\nP：procedure\r\nSA：slice abstraction(切片抽取)\r\nSG(SA(p))：(表示位于所有SA(p)数据切片上的数据符号集合)\r\nTockens(p)：表示过程p的数据符号集合。
1. 面向过程设计的度量(续)
(2) 耦合度量\r\n 耦合度F反映了模块与模块之间、模块与全局数据之间、模块与环境之间的关联，F的值越大，耦合度越高。计算公式为：\r\n F = 1/ (i1 q1i2 u1 q2u2 g1 q3g2 w r)\r\n其中：\r\n i1 = 输入数据参数的个数\r\n i2 = 输入控制参数的个数\r\n u1 = 输出数据参数的个数\r\n u2 = 输出控制参数的个数\r\n g1 = 全局变量用于数据的个数\r\n g2 = 全局变量用于控制的个数\r\n w = 被调用模块的个数\r\n r = 调用该模块的模块个数\r\n q1, q2, q3 = 2
1. 面向过程设计的度量(续)
(3) 复杂度度量\r\n 程序复杂度反映出其可靠性和可维护性，从复杂度的分析中可以找到系统潜在的不可靠的区域。复杂度与程序的大小无关，只取决于程序的判断分支结构。从图论出发，复杂度度量公式为：\r\n v = e -n 2p\r\n其中：\r\n e = 图形顶点数 \r\n n = 边数\r\n p = 相连部件的数量
2. 面向对象设计的度量
目前广泛被采用的面向对象的度量标准，是由Chidamber和Kemerer提出的，简称为CK度量套件。CK度量套件中提出了6个设计度量：\r\n 度量1：每个类的加权方法（Weighted Methods Per Class，WMC）\r\n设M1，…，Mn是类C的方法， 并且M1，…，Mn的复杂度分别为C1，…，Cn。那么
2. 面向对象设计的度量(续)
度量2：继承树的深度（Depth of Inheritance Tree，DIT）\r\n 指一个类到根类的深度，如果涉及多重继承，取深度的最大值。DIT值反映了一个类受其父类的影响程度的大小。一个类的DIT值越大，它所继承的方法越大，要预测它的行为越困难。\r\n 度量3：子类数量（Number of Children，NOC）\r\n NOC指一个类的直接子类的数量。一个类的子类越多，其复用性越高。NOC值越大，该类的被正确抽象的可能性越低，对子类的影响就越大，需要对该类进行更多的测试。
2. 面向对象设计的度量(续)
度量4：对象类间的耦合（Coupling between object classes，CBO）\r\n CBO指与一个类相耦合的类的数量。类间耦合越高，其模块化程度和复用性越差。一个类的CBO值越大，对设计的其它部分的更改越敏感，其可维护性越差，需要进行的测试更多。\r\n 度量5：类的响应（Response For a Class，RFC）\r\n RFC指一个类的消息响应集合的势。一个类的消息响应集合是指当一个类的对象接收到一个消息时，可能会被执行的方法的集合。RFC值越大，类的复杂度越高，测试和调试工作量越大。
2. 面向对象设计的度量(续)
度量6：方法中缺少内聚(Lack of Cohesion in Methods，LCOM）\r\n 一个类具有相似的方法越多，类的内聚性越高，其封装性越好。当一个类内聚性低时，应该将该类分割成多个子类。
3. 面向数据设计的度量
度量1：复杂关系(多对多关系)的个数r。设法将复杂关系(多对多)转化为简单关系(一对多)；\r\n 度量2：基本表的个数t。若基本表的个数太多，则说明数据集成度差。若基本表个数太少，则可能要进行列变行；\r\n 度量3：字段(数据项)的个数f。若字段的个数太多，则说明可能存在冗余。若字段个数太少，则可能要进一步将属性原子化；\r\n 度量4：基本表中记录的条数n。若基本表中记录的条数太多，则说明可能要对该表要作水平分割 ；\r\n 度量5：报表的个数p。若报表的个数太多，则要设法将某些报表改为查询格式，以减少打印的数量；\r\n 度量6：报表中字段算法的复杂程度d。若算法太复杂繁琐，则要进行算法优化处理。
面向数据设计度量的计算公式
面向数据设计度量值ZCL计算如下：\r\nZCL = q1*r q2*t q3*f q4n q5*p q6*d\r\nZCL值越大，系统设计的难度系数越高。\r\n 其中加权系数qi的经验估算为：\r\n q1=200至600之间\r\n q2=100至200之间\r\n q3=1\r\n q4=0.001\r\n q5=10\r\n q6=20
6.6 软件设计文档
软件设计包括概要设计和详细设计。有时将数据库设计单独作为一个设计文档，有时将数据库设计放在概要设计之中。有的人将详细设计划分到软件实现的范畴之内，我们仍然主张将详细设计与编程实现分开。\r\n 本节介绍的软件设计文档包括《概要设计说明书》和《详细设计说明书》。\r\n 这里介绍的软件设计文档格式与内容，都是按照CMMI的要求，规范化处理后的格式与内容，它比较详细、全面，使用中可进行裁剪，灵活处理。
6.6.1 概要设计说明书
1．导言（Introduction） \r\n2．软件架构设计（Software Architecture Design）\r\n3．模块（部件）功能分配（Functional Distribution of Module）\r\n4．数据结构设计（Design of Data Structure） \r\n5．接口设计（Interface Design）\r\n6．其他设计（Other Design）\r\n7．设计检查列表（Check-up List of Design）
6.6.2 详细设计说明书
1．导言（Introduction）\r\n2．模块实现设计（Implemental Design of Module）\r\n3. 接口实现设计（Implemental Design of Interface）\r\n4．其他实现设计（Other Implemental Designs）\r\n5．详细设计检查列表（Check-up List of Design）
6.6.3 设计管理文档
设计管理文档有：\r\n（1）《概要设计说明书评审记录表》\r\n（2）《详细设计说明书评审记录表》\r\n 它的格式与内容如表6-25所示。
6.7 本 章 小 结
通过本章的学习，我们已经懂得，“面向数据方法用在数据库服务器层次上系统的设计与实现，面向对象方法用在除数据库服务器层次之外的其他层次上系统的设计与实现，面向过程方法用在其他两种方法本身内部函数的设计与实现”。\r\n 不管任何设计方法，都要遵守“抽象、分解与模块化、低耦合高内聚、封装、接口和实现分离”的设计原理。\r\n 我们要牢记：没有抽象思维，实践经验就不能上升到理论。没有通俗解释，高深理论就不能被普及，更不能转化为生产力。
本 章 小 结
通过本章的学习，我们已经明白，对于一个大型信息系统的建设，由于其分析、设计、实现、测试、维护的重点是数据库服务器上的数据，所以在软件生存周期的任何开发模型中，在宏观上仍然要遵守五个面向的实施理论，即：“面向流程分析、面向数据设计、面向对象实现、面向功能测试、面向过程管理”。