软件工程 — 总体设计

总体设计阶段两个阶段

1.系统设计阶段：确定系统的具体实现方案

• 划分出组成系统的物理元素——程序、文件、数据库、人工过程和文档等.
• 设计系统的结构,也就是要确定系统中每个程序是由哪些模块组成的,以及这些模块相互间的关系

2.结构设计阶段：确定软件结构

三层结构

• 表达层: 控制怎样把数据通过用户界面显示给用户,同时接受用户的交互输入
• 业务层: 把跟这个应用相关的业务流程和业务规则集中在一起形成一个独立部分
• 数据层: 负责与数据库打交道,把数据库中的表,记录等细节隐藏起来,使业务层见到的是普通的函数或者数值对象

关系：表达层(表达逻辑)业务层(业务逻辑)数据层(数据存储)数据库

雪球理论

• 从坚实的内核做起: 雪球起点不是一堆散雪而是捏了又捏的很紧密的雪核
• 从小到大慢慢来: 一点一点由小变大,而不是通过一次性组装变大
• 边滚边看边调整: 不能朝一个方向一直滚下去,往往是看着哪个缺了,重新换个方向继续滚
• 任何时候都接近圆: 任何时候滚出来的都是圆(及早集成,这样在开发中遇到的困难就越小)

总体设计阶段的工作步骤(七步)

• 提供多种可能实现的方案.
• 选取合理的方案.
• 推荐最佳的方案
• 对程序的结构设计：确定程序由那些模块组成,模块需要完成那些适当的子功能,以及模块之间的关系（至于过程设计属于详细设计阶段的任务.过程设计：确定每个模块的处理过程 ）
• 设计数据库
• 制定测试计划
• 书写文档：计入总体设计的结果(文档总类: 1.系统说明 2.用户手册 3.测试计划 4.详细的实现计划 5.数据库设计结果)

结构设计

要求:

结构设计简单明确

体系结构:

在保证色戒能够完成系统目标的前提下,减少不必要的中间层次和模块,能够直接通话的尽量直接通话,除非非常有必要.别人的东西不要在重复一遍,吧系统的规模保持在最小的程度.同时注意除去多余的联系和耦合

类结构:

类结构的设计的继承关系应该经过仔细推敲,真正反映普遍和特殊的关系,同时在数量上是精简的,在继承结构上是扁平化的

数据结构:

数据结构做到精简成员变量意义明确,提高算法效率高减少功能作用类似的局部变量

概念的一致性:

在整个设计中使用统一,连贯的系统分析法,角度,和一致性的平衡尺度,直到在每个部分使用同样的类比和词汇

模块划分

–模块划分首先要有合理性,有助于对模块的认识和理解

1)种类:

• 基于逻辑关系(例:分层结构的层次间的依赖关系)
• 基于功能

2)判断划分的好坏:

看模块之间的耦合程度和方式,越少越好,越简单越好.有适当的依赖是件好事,证明模块之间有共享和复用,但不可取的是”你中有我,我中有你”,以致模块如一堆乱麻彼此分不开来.做到能不耦合在一起就尽量分开来,能不相互依赖就不要相互依赖

应该遵守原理

1.模块化:

把程序划分为若干个独立的访问且完成一个子功能的模块,且把这些模块集合起来变可以满足用户所需求的功能.

2.模块化好处：

• 使软件结构清晰,不仅容易设计也容易阅读和理解.
• 容易测试和调试,提高软件的可靠性.
• 提高软件的可修改性.
• 有助于软件开发工程的组织管理.

3.抽象：

把这些相似的方面集中和概括起来,暂时忽略它们之间的差异,这就是抽象.或者说抽象就是考虑事物间被关注的特性而不考虑它们其他的细节.

4.逐步求精:

为了能集中精力解决主要问题而尽量推迟对问题细节的考虑.因为每次面临的因素太多,是不可能做出精确思维的.处理复杂系统的唯一有效的方法是用层次的方法构造和分析它,把精力集中在与当前开发阶段最相关的那些方面上,而忽略那些对整体解决方案来说虽然必要的,然而目前还不需要的细节.每一步对软件解法的抽象层次的一次精化.

5.信息隐藏和局部化：

应该这样设计模块,使得一个模块内包含的信息对于不需要这些信息的模块来说,是不能访问的.把一些关系密切的软件元素物理地放得彼此靠近.优点—如果在测试期间和以后的软件维护期间需要修改软件不会把影响扩散到别的模块.

6.为何软件设计中应该追求尽可能松散的系统/p>

这样的系统中可以研究、测试和维护任何个模块,不需要对系统的其他模块有很多了解.模块间的偶合程度强烈影响系统的可理解性、可测试性、可靠性和可维护性.

耦合

定义:

是指不同模块彼此间互相依赖的紧密程度；

耦合的分类(五类)：

• 数据耦合: 如果两个模块通过参数交换信息,而且交换的信息仅仅是数据,那么这种耦合就是数据耦合.
• 控制耦合: 如果两个模块通过参数交换信息,交换的信息有控制信息,那么这种耦合就是控制耦合.
• 特征耦合: 如果被调用的模块需要使用作为参数传递进来的数据结构中的所有数据时,那么把这个数据结构作为参数整体传送是完全正确的.但是,当把整个数据结构作为参数传递而使用其中一部分数据元素时,就出现了特征耦合.在这种情况下,被调用的模块可以使用的数据多于它确实需要的数据,这将导致对数据的访问失去控制,从而给计算机犯错误提供机会.
• 公共环境耦合: 当两个或多个模块通过公共数据环境相互作用时,他们之间的耦合称为公共环境耦合.
• 内容耦合: 有下列情形之一,两个模块就发生了内容耦合
  • 一个模块访问另一个模块的内部数据
  • 一个模块不通过正常入口而转到另一个模块的内部
  • 一个模块有多个入口

在进行软件结构设计时,应该采用的原则：

尽量使用数据耦合,少用控制耦合和特征耦合,限制公共环境耦合的范围,完全不用内用耦合.

内聚

定义:

是指在模块内部各个元素彼此结合的紧密程度.

内聚的分类(大三类,小七类)：

• 低内聚
  • 偶然内聚：如果一个模块完成一组任务,这些任务彼此间即使有关系,关系也比较松散,就叫做偶然内聚.
  • 逻辑内聚：如果一个模块完成的任务在逻辑上属于相同或相似的一类,则称为逻辑内聚.
  • 时间内聚：如果一个模块包含的任务必修在同一段时间内执行,就叫时间内聚.
• 中内聚
  • 过程内聚：如果一个模块内的处理元素是相关的,而且必须以特定次序执行,则称为过程内聚.
  • 通信内聚：如果模块中所有元素都使用同一个输入数据和产生一个输出数据,则成为通信内聚.
• 高内聚
  • 顺序内聚：如果一个模块内的处理元素同一个功能密切相关,而且这些处理必须顺序执行,则称为顺序内聚.
  • 功能内聚：如果模块内所有处理元素属于一个整体,完成一个单一的功能,则称为功能内聚.

内聚在设计中的要求:

设计时力争做到高内聚,并且能够辨认出低内聚的模块,有能力通过修改设计提高模块的内聚程度降低模块间的耦合程度

软件结构设计的启发式规则(七点)

1、改进软件结构提高模块独立性.
2、模块规模应该适中.
3、深度,宽度,扇出和扇入都应适当.

• 深度: 表示软件结构中控制的层数,它往往能够粗略的标志一个系统的大小和复杂程度.
• 宽度: 是软件结构在同一层次上的模块总数的最大值.一般来说,宽度越大系统就越复杂.
• 扇出: 指一个模块直接调用的模块的数目,经验表明,一个设计的好的典型系统的平均扇出通常是3或4个,太多或太少都不好.
• 扇入: 指一个模块被别的多少个模块直接调用.扇入越大越好.

4、模块的作用域应该在控制域之内
5、力争降低模块接口的复杂程度
6、设计单入口单出口的模块
7、模块功能应该可以预测:

如果一个模块可以当作一个黑盒子,也就是说,只要输入相同的数据就能产生同样的的输出,这个模块的功能就是可以预测的.带有内部“存储器”的模块的功能可能是不可预测的,因为它的输出取决于内部存储器的状态.由于内部存储器对于上级模块是不可见的,所以这样的模块既不易理解又难于测试和维护.

************************************************************************
以上的启发式规则多数是经验规律,对改进设计,提高软件质量,往往有重要的参考价值；但是,他们既不是设计的目标也不是设计时应该普遍遵循的原理.

设计优化(五点)

1、考虑设计优化问题时应该记住“一个不能工作的‘最佳设计’的价值是值得怀疑的”.
2、应该在设计的早期阶段尽量对软件结构进行精化.可以导出不同的软件结构,然后对他们进行评价和比较,力求得到“最好”的结果.这种优化的可能是把软件结构设计和过程设计分开的真正优点之一.
3、结构简单通常即表示设计风格优雅,又表明效率高.设计优化应该力求做到在有效的模块化的前提下使用最少量的模块,以及在能够满足信息要求的前提下使用最简单数据结构.
4、优化时遵守一句格言：“先使它能工作,然后再使它快起来.”

来源：kz_ang