2.3 软件设计

一.软件设计

设计是一个创造性的过程，对一些设计者来说需要一定的资质，而最后设计通常都是由一些初步设计演变而来的。从书本上学不会设计，只能经过实践，通过对实际系统的研究和实践才能学会。对于高效的，良好的设计是关键，一个设计得好的应该是可直接实现和易于维护、易懂和可靠的。设计得不好的系统，尽管可以工作，但很可能维护起来费用昂贵、测试困难和不可靠，因此，设计阶段是过程中最重要的阶段。 

直到最近，软件设计在很大程度上仍是一个特定过程。一般用自然语言给定一集，预先作非正式设计，常常用流程图的形式说明，接着开始编码，当系统实现时设计还需修改。当实现阶段完成后，设计往往已与起初形式相去甚远以至于设计的原始文档完全不适合对系统的描述。 

软件设计的这种方法导致了许多动态的和非常昂贵的工程失败。现在已经认识到一些完全非正规的表示法，诸如接近于编程语言的流程图，不适用于系统设计的描述和表达。大家认识到，精确的（尽管并不一定是正规的）说明是设计过程的必要部分。软件设计是一个反复的、不能用任何单一表示法来表示的多层次活动。相应地，大量的设计表示法，如数据流图、层次式输入-处理-输出结构图和设计描述语言已经开发出来，这些表示法能比流程图更好地表达软件设计。 

给定一个需求定义，软件工程师必须以此导出满足这些需求的系统的设计，此导出过程是通过下述步骤来完成的： 
1.必须建立组成程序系统的。 
2.必须把每个子系统分解成分离的成分，并且子系统规范通过定义这些成分的操作来建立。 
3.每个程序可以用相互作用的子成分设计。 
4.每个成分还须进行优化，这通常需要将每个成分规范化成层次式的子成分。 
5.优化过程中的某个阶段，各成分中的算法必须详细说明。 
除了程序系统设计中的这些阶段之外，软件工程师也可能需要设计允许系统中各进程之间进行通信的通信机制。他们或许要设计结构，并且很可能要设计用于程序的数据结构，他们还需要设计确认程序的测试事例。 
确定何为“成功”的设计无一定之规，取决于其应用和特定的工程要求。一个成功的设计应该是：能生成高效的代码，实现尽量紧凑的最小设计，或是一个最易维护的设计。最后一个标准是本文采用的质量标准，可维护性设计意指系统修改费用最低，设计可懂度高和修改是局部性的。只有逻辑上高度结合而相互间松散地耦合的软件设计才能实现以上两个因素。 
有效的软件设计最好利用一致性设计方法。有大量的在不同应用环境中开发并使用的设计方法，其中有些是由皮特森(1980)、布兰克和克瑞境(1983)描述的。实质上，这些方法大多数可划分为三： 
1.由上至下的功能设计：从功能的观点设计系统，从高层的观点着手将系统逐步地提炼成更具体的设计。结构化设计和阶梯式优化就是使用此方法的例子。 

2.面向目标设计：把系统作为目标集合而不是功能的集合，信息在目标与目标之间传送，每个目标有它自己的相互关联操作集。面向目标的设计方法是基于信息隐藏的观点，该观点由巴拿斯(1972)最先提出，最近又由罗滨逊(1981)和保什(1983)描述。 

3.数据驱动设计：此方法由杰克逊(1975)和万勒尔(1977)提出，认为软件系统的结构应该反映该系统所处理数据的结构。因此，软件设计应由对系统输入、输出数据进行分析后而导出

/*****************************************************************************/

 

二.软件评价：

往往在解决一个困难之后，就会出来一个新的困难。当我们渐渐意识到越早发现错误，就越容易解决问题的时候，我们开始了看上去比较正规的评价活动，对计划、、设计等进行评价。在一段时间之后，我们失望的发现，这对我们遇到的困难帮助不大，我们的评价活动存在流于形式的问题。

    但我无意于对所有的评价活动发表意见，只想就比较熟悉的设计评价进行讨论。

    软件设计通过软件统来表示（参见《再议模型》），软件设计评价是对设计模型的评价。在这里，我们使用源系统表示软件要实现自动化的系统，它处于实体空间；目标系统表示要实现的软件本身，它处于形式空间。软件表示模型（即系统分析模型和系统设计模型，参见《再议模型》）是沟通源系统和目标系统的桥梁。表示模型的形成需要一个过程，我们称其为过程空间。下面我们使用图形方式来描述：


   这样，软件设计评价应该具有三标准，分别是实体空间标准、过程空间标准和形式空间标准。

   实体空间标准以源系统做为标准来系统设计模型。这依赖于我们对于源系统的认识程度，我们知道应该具有这样一个标准，但实行起来非常困难。设计的合理性就是实体空间标准，它没有一个具体的内容和形式。

   过程空间标准在设计评价中经常被使用。它可以看作实体空间的间接标准，基于分析模型和设计模型是出于同一实体，其中具有自然的关联。我们说，设计是否附合需求，就是检验设计模型和分析模型的一致性。

    形式空间标准以目标系统的角度检验系统设计。从上述两种标准，可以保证目标系统的功能满足源系统，但不能保证目标系统在运行状态下的质量属性。所以形式空间标准是从目标系统的质量出发来考察系统设计的。考虑到质量，我们使用McCall/GE质量模型，它围绕产品改进、产品运行、产品移交三种使用情况来组织质量属性，可以看出是基于目标系统的。国际上有很多现行的基于质量评价系统设计的方法，我们后面会参考其中的部分。

虽然从理论上我们可以知道软件设计评价具有三类标准，但却没有办法真正按照这些标准去检验一个软件的设计。

   实体空间标准应该是一个软件设计最终应该附合的标准。但是，这个标准很难直接应用于软件设计模型上，因为软件设计是思维的产物，在实体上检验这个产物是否正确，恐怕只能说“实践是检验真理的唯一标准”了。只有在错误非常明显的情况下，这个标准才会起作用。

    过程空间标准相对好一些。通过和软件生产过程前期阶段产物进行对比，可以找到其中不一致的地方，这可能就是设计上的问题了。同时，现代软件开发一般采用迭代的方式进行，设计活动可能分多次进行。这种迭代也要求我们检查设计对需求的覆盖情况。

    通过形式空间标准对软件设计进行检验时，往往并不存在一个唯一的检验标准。这是因为实际软件的质量要求不是唯一的，不同的软件有不同的质量属性要求。而特定软件的质量要求，是在、设计的过程中逐步形成的。这些质量要求，最终成为我们检验软件设计的标准之一。

    根据这些标准，我们现在设计一个软件设计评价表模版：

软件设计评价表 
软件名称   迭代周期   
设计人员   
评审人员   
设计合理性  
    
需求附合度 
功能点覆盖率（FPC） ?% 重点功能点覆盖率（IFPC） ?% 
优先功能覆盖率（PFPC） ?% 需求一致度(Should be 100%) ?% 
质量属性 
模块性 权重 在过程中确定权重 分数，100分制，下同 
可修改性 权重 权重之和应为100%   
可扩展性 权重 下同   
性能 权重     
可靠性 权重     
可用性 权重     
可移植性 权重     
可维护性 权重     
灵活性 权重     
可重用性 权重     
可理解性 权重     
弹性 权重     
安全性 权重     
容错性 权重     
评审结论 
 
 
 
  

    在设计合理性方面，主要考虑以下内容：


类的职责单一、明确 
模块结构清晰、完整 
活动、行为描述清晰 
实体关联清楚，状态合理

    对需求附合度的要求要在评价之间确定。

    质量属性的评价权重一般在设计开始之前确定，这个工作多数在设计时刻完成。最后，根据质量属性的权重，可以计算设计的总体质量分数。这些都是最终评审结论的素材。

    一般来说，对于设计的评价通过建立场景的方法来实现。比如评价可修改性，一般先建立一个修改的场景，对设计进行模拟修改，观察其是否易于修改。有些质量属性无法通过这种方法检验，只能通过对设计模型进行观察得出结论。