软工系列之----概要设计

上一章讲的是需求分析。下面是需求模型和设计模型的关系图。

 

概要设计的目标：

    通过这个阶段的工作将划分出组成系统的物理元素-程序、文档、数据库、人工过程和文档。
但每个物理元素是黑盒子，其具体同以后的详细设计。
设计软件的结构，确定系统每个程序是由哪些模块构成，以及模块之间的相互关系。

    概要设计任务：

1、  指定规范：应为软件开发组指定在设计时应该共同总受的标准。

2、  软件系统结构的总他方案设计：

1)      采用某些设计放啊，将一个复杂的系统按功能划分为模块的层次结构

2)      确定每个模块的功能，建立与需求的对应关系

3)      确定模块间的调用关系。

4)      确定模块间的接口，即模块传递的信息。设计接口的信息结构。、

5)      评估模块划分质量及导出模块结构的规则。

3、  处理方式设计

1）  确定满足功能的算法，评估算法的性能；

2）  确定满足性能的算法和模块间控制方式（性能设计）：周转时间，吞吐量，精度。

3）  确定外部信号的接受发送形式。

4、  数据结构设计：确定软件设计的文件系统结构以及数据库的模式、子模式，进行数据完整性和安全性的设计。

1）  确定输入、输出文件的详细数据结构；

2）  结合算法，确定数据结构及操作；

3）  确定逻辑数据结构必须的操作模块。

4）  确定与操作系统和调度程序接口的数据结构和使用规则。

5）  数据保护性设计

防卫性设计：自动检错，报错和纠错功能

一致性设计：a、保证数据类型和取值范围不变； b、并发处理过程中使用封锁和解除封锁机制保持数据不被破坏。

冗余设计：利表决或纠错，保证容错。

5、  可靠性设计：也叫质量设计。确定可靠性和质量标准；考虑措施，使得软件易于修改和维护。

6、  编写概要设计阶段的文档。包括：

概要设计说明书：给出系统目标、总体设计、数据设计、处理方式设计、运行设计、出错设计等。

数据库设计说明书：给出使用数据库的简介、数据库模式设计、物理设计等。

用户手册。对需求分析阶段编写的初步的用户手册审定。

指定初步的测试计划：测试的策略、方法和步骤。

7、  评审

自顶向下逐步求精。

这是一个反复推敲的过程。简化、分化。最初说明知识概念性的描述了系统的功能或信息，但并未提供有关功能的内部实现机制或有关信息的内部结构的任何信息。
设计人员对初始说明自习推敲，进行功能细化或信息细化，给出实现的细节，划分出若干份。然后在对这些成分，施行同样的细化工作。随着细化工作的逐步展开，设计人员就能得到越来越多的细节。

 

模块化。

模块是构成程序的基本构建。过程、函数、自过程、宏以及对象、对象内方法（服务）都可以作为模块。模块化就是把程序作为独立命名的且可独立访问的模块，每个模块完成一个子功能，集成这些模块成为一个整体，可以完成软件的需求。
模块化方法带来了许多好处。
一方面模块化设计降低了系统的复杂性，使得系统容易修改。
另一方面，推动了各个部分的并行开发，从而提高了软件的生产效率。
模块化原理。
问题 P，函数C(p)是问题p的复杂度，函数E（p）是解决问题p所需要的工作量。
若有两个问题p1和p2，有
C（p1）>C(p2)则E（P1)>E(p2)
规律 ：C(p1+p2)>C(p1)+C(p2)
E(p1+p2)>E(p1)+E(p2)
不可忽略接口的开销。当模块数增加，模块之间的联系也随着增加，连接这些模块的工作量也随着增加。

一个模块即使必须“整体”实现，不能做模块划分，也可以按照模块化的概念进行设计。

过程抽象：

在软件工程中，从系统定义到实现，每一步都可以看作是对软件解决方法的抽象化过程的一次细化。在软件计划阶段，软件被当作整个计算机系统中的一个元素来看待。在软件需求分析阶段，用“问题所处环境的为大家所熟悉的术语来描述软件解决方法。而从概要设计到详细设计的过程中，抽象化的层次逐次降低。

数据抽象：

数据抽象也过程抽象一样，允许设计人员在不同的层次上描述数据对象的细节。例如，可以定义一个draw数据对象，并将它规定为一个抽象数据类型，用它构成元素来定义它内部的细节。此时，数据抽象draw本身是由另外一些数据类型之后，就可以应用它来定义其他的数据对象，而不必涉及到draw的内部细节。

控制抽象：

 与过程抽象和数据抽象一样，控制抽象可以包含一个程序控制机制而无须贵姓内部细节。
控制抽象的例子，就是操作系统中用以协调某些活动的同步信号。

模块的独立性：

 

 

模块的改进。

       完善模块功能。

       一个完整的功能模块，不仅能购完成指定的功能，而且还应当能够告诉使用者完成任务的状态，以及不能完成的原因。一个完成的模块应当有一下几个部分：
执行规定的的功能部分。
出错处理的部分：返回出错标志，向使用者报告原因。
如需要返回数据给调用者，完成加工时应返回一个执行是否正确的结束标识。
       改进软件结构。

       通过分析软件结构，分解或合并模块，力求降低耦合提高内聚。
完全相似：合并，改进数据描述。
局部相似：相似部分独立成下一层模块。
通过分解或合并模块，减少控制信息的传递对全程数据的引用，并降低接口复杂程度。

      模块功能应适中。

       模块规模不应过大，语句行数最好能写在一页纸内。（50行——100行）
过大的模块通常是因为分解不充分。分解不应降低模块的独立性。
过小的模块可能降低软件效率，使系统接口复杂。

      深度 宽度 扇入 扇出 。

      1、程序结构的深度
      程序结构的层次数称为结构的深度。结构的深度在一定意义上反映了程序结构的规模和复杂程度。
     2、程序结构的宽度。
     层次结构中同一层模块的最大模块个数称为结构的宽度。
     3、模块的扇入和扇出。
    扇出表示一个模块直接调用（或控制）的其他模块数目。扇入则定义为调用（或控制）一个给定模块个数。
多扇出意味着需要控制和协调许多下属模块。而多扇入的模块通常是公用模块。
系统平均扇出是3-4，上限是9.
扇出过大意味着模块过分复杂，需要控制和协调许多下属模块。
扇入越大，则共享该模块的上级模块越多。但不能违背模块独立性原理追求高扇入。
    模块作用域应该控制范围内。

     模块作用域：为受模块内一个判定影响的所有的模块的集合。
模块的控制域：本身及所有直接或间接从属于他的模块的集合。
如果一个判定的作用范围包含在这个判定所在的模块的控制范围之内，这种结构是简单的。

      降低接口的复杂度。

       模块接口的复杂性包括三个因素：传送信息的数量，联系方式，传送信息的结构。
调用中出现大量参数，说明模块功能太多，可分解成功能简单的模块，就可减少参数个数，降低接口复杂性。降低耦合度。
模块联系方式（调用方式）有两种：call和直接引用。
call使用标准的过程调用，接口复杂性较低，耦合性低。后者是一个模块访问另一个模块内部的数据或指令，耦合性高。
参数类型上尽量少使用指针、过程类型的参数。
传送信息应以标准、直接的方式提供。

       降低单入单出模块。模块功能可以预测。

       把一个模块看作一个“黑箱”，对于相同的输入，总能产生相同的输出，这个模块的功能就是可以预测的。
为了适应用户的新要求或环境的变更，模块中局部数据结构的大小应是可控的。
调用者可通过模块结构上的参数或预定义外部参数来规定。接口也可通过改变参数来调用。

       只写了一部分，其他的在word文档中，总结的想吐了。。。继续。。。
 

 关于概要设计如何写文档，以及文档的格式、、所以补充网址：http://blog.csdn.net/lilongsheng1125/article/details/6846582