软件工程分析与设计1.1 问题解决和决策在现阶段，介绍杜威在1910年首先阐述的一种解决问题的结构方法是很有益处的。

约翰杜威确定的阶段是：问题是什么？可供选择的办法由那些？那种办法是最好的？你现在应该努力识别杜威的三个阶段与软件生命周期的相似之处。

为了弄清第一阶段的问题定义与我们的需求分析阶段之间的相似之处，在前面我们已经对生命周期介绍得足够多了。

事实上，许多组织使用词汇‘问题’或‘项目定义’而不用‘需求分析’。

后两个阶段同样的被认为相当于我们所提到的设计阶段。

最近（1960），西蒙在有关决策的文章中提出了相应的结构。

西蒙教授对决策阶段作以下分类：信息收集活动，设计活动以及选择活动。

单词‘信息收集’在这里使用其军事方面的意义，也就是，在外界环境中搜索做出决策所需的各种条件。

‘设计’与发明及开发行为可能的发展方向有关。

挑选一个详细的行动方案的活动称为选择。

于是，我们的需求分析对应于信息收集活动。

尽管软件设计员不需要拼命寻找作决定所需的环境条件，但人们通常会在软件设计员的桌子上看到‘需求说明书’。

但是，西蒙所用的单词‘设计’与我们所用的不同。

我们所用的‘设计’同时包括选择的意义，而西蒙的‘设计’用来描述可能的解决方案的产生。

有理由相信问题解决.决策.软件分析和设计共享一个公共构架。

主张前两项活动实际上在效果上是相同的，而最后一项活动恰是这一现象的一个详细实例是有一定道理的。

因此，我们将坚持把软件设计当成解决问题的活动，并这样处理他。

这表示我们必须在产生可能的解决方案和从中选择一个最佳方案两方面投入一定的精力。

1.2 选择规模让我们以非常简单的设计问题开始。

作为一个小家庭的双亲之一，你决定带着孩子和配偶到斯卡伯勒去游玩。

你的设计问题是确定旅行的最好的方法。

你有如下选择：乘火车，坐公汽或驾驶私人轿车。

要做出选择你需要其他一些东西。

除非这三种选择之一能提供一些对你来说分重要的或是最佳的特性，否则你很难决定那种是最好的。

因此，如果你想要把外出的费用减小到最少，根据火车的票价和乘轿车需消耗的燃料，立刻就可以做出决定。

以这样的标准，最少的成本就称作设计标准或设计目标。

类似的，你可以把旅行时间作为设计标准，研究一下旅行时间表和你的轿车的性能立刻就可以做出选择。

顺便提一下，如果花销和旅行时间都很重要，那么做出选择是很困难的。

这一点以后将会讨论。

目前，我们必须专注于选择规模。

1.2.1 组合的爆炸在上述例子中设计问题的价值并不是很高，因为选择是在三个很容易评估的方案中做出的。

但是，回想过去我们要你确定添加三个数字会存在多少种可能的设计这一问题。

我们发明并使用了一个称之为添加树的设计得出共有四种可能（见表1.1）。

在计算机科学中，通常树梢向下，而树根在上，但他所表达的意义分清晰。

树叶代表数字，标记为A.B和C。

树枝代表数字从根部向尖端移动的次数。

树枝相交的地方我们称之为节点，在节点处就可以产生一个简单的追加。

计算增加五个节点可能的方案数也并不困难。

事实上，总共有236设计方案，在表1.2中相应的列举了少数的几个添加树。

这对于添加三个数有四种可能来说是一个相当大的增长，它就是我们称之为组合爆炸的一个例子。

换句话说，当考虑把许多因素组合到一起而形成的各种方法时，只要因素的数目增加了，方案数就会增加许多。

你可以从以前的章节回想一下，增加50个数据这样一个貌似简单的问题就会产生6.85x1081种设计乘车花销或旅行时间，问题很简单。

但是如果两个标准都重要，那设计就相当困难了。

进一步讲，我们假设双亲中的决策者根据获得的费用结构.时间表等信息构造了表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.c3…cn为加权因数。

用从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赋值了，这些值必须反映对设计员的相应压力大小。

总之，如果要使用多属性值函数作重大的决定就一定要谨慎小心。

理论上讲，首先必须满足独立。

只有参数选择是在任何一对独立于其他属值性的属性之间进行时这种情况才满足。

例如，如果评估耐用性都为20%的两种设计，则运行费用每年25000英镑.可靠性为97%的设计优先于运行费用每年30000英镑.可靠性为99%的设计，如果两种设计的耐用性都变为15%，那么会有同样的选择。

不难想象条件改变的情况。

我们的例子可能很恰当。

可能在许多使用者的眼里，象上面那样耐用性降低了，可靠性应该更重要了，而选择应该是相反的。

第二个困难在于加权因数的选择。

我们在练习1.3中可以看到加权因数一个偶然的改变就会产生新的最佳设计方案。

仅仅是设计员对压力的反应并非评估加权因数的充分机制。

有必要采用更加正式的方法来得到他们。

这包括向使用人员问一些假定问题，特别是如果包括大量的标准，通常会很耗时间。

查普曼（1980）给出了这些方法恰当的描述。

最后的也是最重要的困难是许多重要的设计标准是很难计量的。

举一个可维护性的方面例子，很难为其构思一个优先的方法，所以任何基于数字的选择机制都同样难以执行。

因此，一个设计员想使用值函数处理大量的选择工作是不可能的。

更合适的是他用以使用者直觉地参数选择为基础的简单的处理技术作为一个大致的筛选来排除那些最不可能的选择。

只有当设计方案的数量被减少到相当小时，才能产生最完善的评估技术。