1.<default.asp>
图4-2 用户登录界面图
2.<selectsubject.asp>
图4-3 考试科目选择界面图
3.<test.asp>
图4-4 考试界面图
4.<result.asp>
图4-5 考试结果界面图
5.<login.asp>
图4-6 管理员登录界面图
6. <primary.asp>
图4-7 管理界面图
7.<mgsubject.asp>
图4-8 管理科目界面图
8.<mgscore.asp>
图4-9 管理记录界面图
9.<mgquestion.asp>
图4-10 管理试题界面图
选择
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个数据构成的
<< 上一页 [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] 下一页