软件工程分析与设计

软件工程分析与设计选择1.1 问题解决和决策在现阶段，介绍杜威在1910年首先阐述的一种解决问题的结构方法是很有益处的。约翰杜威确定的阶段是：问题是什么？可供选择的办法由那些？那种办法是最好的？你现在应该努力识别杜威的三个阶段与软件生命周期的相似之处。为了弄清第一阶段的问题定义与我们的需求分析阶段之间的相似之处，在前面我们已经对生命周期介绍得足够多了。事实上，许多组织使用词汇问题或项目定义而不用需求分析。后两个阶段同样的被认为相当于我们所提到的设计阶段。最近（1960），西蒙在有关决策的文章中提出了相应的结构。西蒙教授对决策阶段作以下分类：信息收集活动，设计活动以及选择活动。单词信息收集在这里使用其军事方面的意义，也就是，在外界环境中搜索做出决策所需的各种条件。设计与发明及开发行为可能的发展方向有关。挑选一个详细的行动方案的活动称为选择。于是，我们的需求分析对应于信息收集活动。尽管软件设计员不需要拼命寻找作决定所需的环境条件，但人们通常会在软件设计员的桌子上看到需求说明书。但是，西蒙所用的单词设计与我们所用的不同。我们所用的设计同时包括选择的意义，而西蒙的设计用来描述可能的解决方案的产生。有理由相信问题解决、决策、软件分析和设计共享一个公共构架。主张前两项活动实际上在效果上是相同的，而最后一项活动恰是这一现象的一个详细实例是有一定道理的。因此，我们将坚持把软件设计当成解决问题的活动，并这样处理他。这表示我们必须在产生可能的解决方案和从中选择一个最佳方案两方面投入一定的精力。1.2 选择规模让我们以非常简单的设计问题开始。作为一个小家庭的双亲之一，你决定带着孩子和配偶到斯卡伯勒去游玩。你的设计问题是确定旅行的最好的方法。你有如下选择：乘火车，坐公汽或驾驶私人轿车。要做出选择你需要其他一些东西。除非这三种选择之一能提供一些对你来说十分重要的或是最佳的特性，否则你很难决定那种是最好的。因此，如果你想要把外出的费用减小到最少，根据火车的票价和乘轿车需消耗的燃料，立刻就可以做出决定。以这样的标准，最少的成本就称作设计标准或设计目标。类似的，你可以把旅行时间作为设计标准，研究一下旅行时间表和你的轿车的性能立刻就可以做出选择。顺便提一下，如果花销和旅行时间都很重要，那么做出选择是很困难的。这一点以后将会讨论。目前，我们必须专注于选择规模。1.2.1 组合的爆炸在上述例子中设计问题的价值并不是很高，因为选择是在三个很容易评估的方案中做出的。但是，回想过去我们要你确定添加三个数字会存在多少种可能的设计这一问题。我们发明并使用了一个称之为添加树的设计得出共有四种可能（见表1.1）。在计算机科学中，通常树梢向下，而树根在上，但他所表达的意义十分清晰。树叶代表数字，标记为A、B和C。树枝代表数字从根部向尖端移动的次数。树枝相交的地方我们称之为节点，在节点处就可以产生一个简单的追加。计算增加五个节点可能的方案数也并不困难。事实上，总共有236设计方案，在表1.2中相应的列举了少数的几个添加树。这对于添加三个数有四种可能来说是一个相当大的增长，它就是我们称之为组合爆炸的一个例子。换句话说，当考虑把许多因素组合到一起而形成的各种方法时，只要因素的数目增加了，方案数就会增加许多。你可以从以前的章节回想一下，增加50个数据这样一个貌似简单的问题就会产生6.85x1081种设计令人瞠目结舌。大型软件的设计会造成类似的问题：如果想要选出最好的设计方案，理论上就需要审核与评估无数的选择方案。我们说在理论上，因为如果我们计算评估一个方案需要多长时间，就会发现综合评估所有的方案是不可能的。如果使用电子手段，而审阅和评估一种方案需要百万分之一秒，那么增加50个数据需要多长时间来挑选最佳树呢？这种详细设计方案将用去2.17x1066世纪。事实上，除了一些没什么价值的案例，这种设计方法是不可能实现的。不过，世界上每天都有人在设计系统，其中的一些系统还相当好用。所以，我们现在必须考虑那些聪明的人是怎样达到如此好的结果的。1.2.2 制约通常，在选择开始之前尽可能的进行取舍是相当有帮助的。约束恰恰是作这件事的。我们最初在审阅软件生存周期的需求分析阶段进行非功能性需求分析时遇到的约束问题。我们发现约束常常在用户需求文档中有所明确，也常常与硬件、软件时间和金钱有关。因此，总而言之，将要在奥利维蒂公司M24上执行的新软件即使能排除所有其它的设计方案也无法立即执行。类似的，需要使用一个非功能性需求的标准输入输出软件，用来删除与约束矛盾的所有设计方案。时间和金钱同样制约着设计。如果软件必须在某一日期之前投入使用，那么那些复杂的、无法在最后期限之前完成的实际方案必须被抛弃。同样，超过预算的设计方案也会被淘汰。尽管制约的应用可以严格的限制设计员选择方案的数目，但是选择方案的规模看上去仍然无法控制。所以在解决选择方案问题时设计员仍然需要一些帮助。这些帮助来自启发式的设计条件或者说是经验法则。1.2.3 启发式的设计让我们再转到添加50个数据和它的6.85x1081个添加树问题上来。假设可以把相关的5个数（例如他们可能都是把进制的，而其他的不是）确定为一组，这样，这5个数在添加树中就可以紧挨着。我们知道增加这5个数据的会导致增加236个添加树。对这236种选择进行评估是相当可行的，这5个数据的最佳的子树也可以确定。然后，我们可以用一个节点把这5个数据构成的最佳子树放回去。这样，我们就完成了把数据从50个减少到46个，即45个数据和一个子树。这个过程也可重述为提出5个数据然后设计一个满足条件的子树，再用它替代这5个数据。这一过程包括13个循环，除了最后一个循环，每个循环包括236种设计。最后一个循环只包括2个数据，只能有一个设计方案。因此，整个过程就包括12x236个评估，也就是2832个独立的设计方案（1969）。即使这样减少设计方案的数目，还是太多。如果审查和评估每一种可能的选择需要15分钟的话，那么按上述程序设计一个最佳的添加树需要用多长时间呢？需要用708小时。假如一个设计员要解决这个问题，他需要18周。所以，如此设计并非不可能，但是却相当的艰难和乏味。以上是一个启发式的设计的例子，设计员用经验法则来彻底的减小设计的规模，直到该设计变成易处理的问题。这种启发式的设计的基础是设计员的经验或个人天赋，也可能是某种硬性规定。类似于民俗的硬性规定还没完。毫无疑问，你应该对民俗中的红色的夜空，高兴的牧羊人之类的说法相当熟悉。一从老人们那嘴里听到这些东西，你差不多可以想到下文。设计员也是这样。擅长于设计添加树的人，在设计时会说：把5个相近的数据从添加树中提出来，用一个代表最佳子树的节点来代替他们，反复做，直到只剩下一个树。这种硬性规定的方法存在着危险，其危险就是从业者把经验法则当作一个基本原理。问题是科技会随着而时间变化，特别是在计算机领域。因此，以前很成功的设计经验法则可能很快会变得陈旧的和不可靠。尽管有这些困难，如果没有经验法则设计将无法进行。你很快会发现设计方法通常会用到他们，他们也会在对使用其它方法获得的最初设计进行精选时发挥重要作用。所以说设计员的技能与他选择和应用经验法则的能力有关。1.3 设计标准我们在第二节从一个简单的问题开始，对一个家庭到海边游玩一天的旅行进行设计安排。我们注意到，共有三种选择和一个标准乘车花销或旅行时间，问题很简单。但是如果两个标准都重要，那设计就相当困难了。进一步讲，我们假设双亲中的决策者根据获得的费用结构、时间表等信息构造了表1.3。 为了去掉我们自己的成见，把这三种方式称为P、Q和R。评估每种方式的乘车花销或旅行时间。很明显，如果乘车花销作为唯一标准的话R是最好的选择，如果旅行时间最重要的话应该选P。想象你就是双亲之一的决策者。基于表1.3给出的信息你将做如何的选择呢？(以前我们并不在乎你的实际答案，而真正关心你的实现过程。)如果你完成了一个选择，不管结果是P、Q或是R，尽管你可能不是很清楚，但是你一定是经过了上述过程而得出的结果。你的问题可能是：多花2.35英镑来节省25分钟的时间时不是值得。根据你自己的回答，你就能够得出结论。你也可能认为这是一个愚蠢的问题，因为实际上，你需要把其他的东西计算在内，例如：舒适性、便捷性以及格洛丽亚姨妈的坚持（向她以往的那样），或者是一路的秀丽风景。同时我们注意到这三个属性和旅行方式是无法确定的，所以他们与直接费用的折衷方案是不可能的。你也可能会苦恼那些能够使定期的旅行无法进行的不确定的事件，例如工程任务、交通堵塞、人员不齐以及车抛锚。这些抱怨都相当的合理，但是，人们总是按照我们在这里讨论的方法进行选择的。多数情况下，人们是通过组合折衷和直觉的办法来选择。但是必须指出，可以通过把以上提及的所有因素综合起来形成一个功能函数来进行性选择。但是，这些太深了，我们必须返回到原来所讨论的问题上去。1.3.1 压力和标准迄今为止，我们还没思考过为什么在前些节中要把费用和旅行时间作为唯一的设计标准。认真考虑我们就会发现这是由于外界对决策者的压力。我们不排除内部产生的压力，但通常我们都把它看成外部产生的。见图1.4。我们现在来看设计标准的起源。节俭的妻子坚持费用要低；不耐烦的孩子们要求旅程时间要短。毫无疑问，如果格洛丽亚姨妈（她特别喜欢在国家公园的停车场里打盹以及非常热衷于便宜货）坚持的话，几乎是无法拒绝的。所以选择应该试图令所有这些要求都得到满意的解决。或者至少任何人不会产生十分的不满。必须注意的是，处理步骤是由决策者认为这些压力的相对重要性所决定的。压力的相关重要性的思想是以软件设计员的行为为基础的，我们再来谈谈软件设计员。1.3.2 压力和软件设计在研究早期的关于软件生存期的资料的时候，你需要做一个练习（练习2.2），以便在软件设计时把你对各属性的观点计算在内。在练习的答案中可以看到属性有很多个，但最重要的属性包括：经济性、可靠性、可维护性、耐用性、完整性和安全性。前三个属性的定义相当的明显了。但是你怎样理解耐用性、完整性和安全性呢？你可以回想练习的答案，耐用性就是系统在进行大量事务处理时所表现出的性能。完整性和安全性更难定义，因为他们经常可以交替使用。我更倾向于用完整性来描述程序和数据对突发事件的抵抗能力。而安全性适用于对故意破坏的抵抗能力。我们下一个要讨论的问题是研究另一种压力情况，见图表1.5。在开始时使用者把压力作为一个单独的实体。当然，实际上使用单位不同的部门和个人在软件运行时会有不同的既得的重要性，相应地，他们施加的压力就会有所不同。但是在前面的章节中，决策者恰恰是疲惫的父亲，所以就需要以使用者的需求得到最大满足的方法来进行设计。设计员实在是需要一些可以从比较设计中导出的复合方法，这些设计应尽可能满足使用者相对重要的属性要求，并对不确定性留有适当的余量。因此，设计员真正需要的是一个多功能函数。但是我们曾经躲避过这个问题，现在我们同样要避开它。原因是这样的函数在软件设计的上下文中是不可能导出的，所以没有一个设计者试图要导出它。但在十分有限的条件下（以后会解释），设计员在把客观现实加入到它的设计机制中时会感到很大的压力。这通常涉及到我们以前遇到过的处理过程的发展，并需要应用值函数。简单的讲就是为各属性形成一个加权平均值。例如，我们可以用V（S）来代表软件设计值，如下：V（S）=c1 x 属性1的值+c2 x 属性2的值+c3 x 属性3的值+cn x 属性n的值 (1)c1、c2、c3cn为加权因数。用从0到100这一标准范围来代表每一个属性及复合属性是很方便的。在这种情况下，强制（c1+c2+c3+cn=1）。（查普曼，1980年）。为了示范值函数的应用，我们假定一个设计员想要从三个候选设计中作一个最终选择。同时我们假定对设计员的压力限于以下三个：经济性、可靠性和耐用性。三个设计的相关数据见表1.6。X、Y、Z每个设计的图表说明了每个设计标准的估计参数值。必须注意到，我用系统运行费用每年几千英镑来反映其经济性。可靠性的评估使用实用性的百分数，也就是说，软件预期正常运行时间百分比。系统处理大量错误时的容错百分数反映其耐用性。我们首先要为每个属性建立一个值函数。值函数-单一属性 一个值函数仅仅表示某一特殊属性不同量的愿望。我们按照意愿的先后排列所有可能的属性值来构建值函数。最不希望的赋值为0，最希望的赋值100，其余的在0到100之间适当的赋值。这样我们就根据影响我们的三个标准得出了值函数，见表1.7。函数应尽可能的体现使用者的属性值。必须指出，尽管我们以前举的是两个线性函数的例子，但是该函数并非必须是线形的。我们把最糟的结果放在水平轴线的左边，最佳的结果放在水平轴线的右边。这意味着如果按照经济性，较低的计算结果为首选，从左到右可能性逐渐增加。另两个结果从左到右安升序排列。我们现在需要把所有设计的结果作为一个整体。值函数-多属性 我们根据经济性、可靠性、耐用性，使用表达式（1）来评估这三个设计：V（S）=c1 x 属性1的值+c2 x 属性2的值+c3 x 属性3的值 （2）现在只剩下给加权因数c1、c2、c3赋值了，这些值必须反映对