在线考试系统论文(源代码+流程图)
The term ‘Intelligence’ is used here in the military sense, i.e., searching the environment for conditions requiring a decision to be made. ‘Design’ is concerned with inventing and developing possible courses of action. The activity of selecting a particular course of action from those available is known as ‘chose’. In this case our requirements analysis corresponds to the intelligence activity. Although the software designer does not need to search too hard for circumstances requiring a decision to be made, they will normally be found lying on his or her desk labeled ‘Specification of requirement’.
However Simon’s use of the term ‘Design’ differs from ours. Whereas Simon uses the word to describe the generation of possible solution, we use it in the sense that selection is included also.
There seems to be some justification for believing that problem-solving, decision-making and software analysis and design share a common framework. And it is not stretching the point too far to claim that the first two are, in effect, exactly the same thing while the last is just a particular instance of this phenomenon. Consequently, we shall persist in regarding software design as a problem-solving activity and treating it as such. This means that we must devote some attention to the questions of generating possible solutions (i.e., designs), and the selection of one from this number.
1.2 SIZE OF SELECTION
Let us start with a very simple design problem. As one of the parents of a nuclear family you decide take your spouse and your two and a half children to Scarborough for the day. Your design problem is to establish the best way of making the journey. You establish the alternatives as being: British Rail, National Bus or private car.
In order to make your choice you need something else. You cannot possibly decide which is the best unless there is some property possessed by the three alternatives which is important to you and which you wish to see maximized or minimized. Hence, if you wish to minimize the cost of the outing, say, the decision is soon made, given some understanding of the fare structures of British Rail and National, and a realistic appraisal of the fuel consumption of your car. Such a property, in this case the direct cost of the journey, is known as the design criterion or design objective. Similarly, you might take journey time as the design criterion and once again the study of timetables and knowledge of your car’s capabilities would enable a ready choice to be made. In passing, we should note that if both costs and journey time are important then the choice might be more difficult. But the latter point is for future development. For the moment we must concentrate on size of selection.
1.2.1 Combinatorial explosion
In the foregoing example the design problem was trivial, for the selection had to be made from three alternatives, each one of which was easily evaluated. But now recall that sometime in the past we asked you to determine the number of possible designs that exited of you were faced with the problem of adding three numbers. We concluded that four designs were possible and in Fig.1.1 we show them by inventing and using a device that we might call an adding tree.
As is usual in computing, the trees are upside down with the root pointing to the stars, but the representation is plain. The leaves of the trees represent the original numbers, symbolized as A, B and C. The branches represent the flow of numbers and sub-totals up the tree, terminating with the total at the root. Where branches meet we have what we may call a node and at each of these a simple addition takes place.
It is not too difficult to calculate the number of designs that are possible for adding five numbers. In fact, there are 236 possible designs and a handful of the corresponding adding trees are illustrated in Fig.1.2.
This is a considerable increase over the four possible designs for adding three numbers and is an example of what is sometimes known as the combinatorial explosion. In other words, when faced with considering different ways of combining a number of elements, you rapidly arrive at a large number of alternatives as the number of element increase. You may recall from an earlier chapter that the deceptively simple problem of adding fifty numbers generated 6.85x1081 designs – a conversation-stopper if we ever met one.
The design of a substantial piece of software poses a similar problem: a very large number of alternatives all of which, in theory, need to be examined and assessed if the best design is to be selected. We say, in theory, because if we calculate how long it takes to assess each design, we will immediately see that a comprehensive assessment of all designs is not possible. If using electronic means, say, it takes one-millionth of a second to examine and assess each of the possible adding trees for fifty numbers, how long would it take to select (i.e., design) the optimum tree?
This particular design problem would take 2.17x1066 centuries to complete thus indicating that on the face of it and except for trivial cases, design is impossible. Nevertheless all over the world and everyday, people are designing systems, and some of them are quite good. So we must now consider how so many intelligent people knowingly attempt the impossible, often to good effect.
1.2.2 Constraints
Design, in general, is helped considerably if as many alternatives as possible may be struck out before the attempt at selection begins. Constraints do exactly this. We first met constraints in the guise of non-functional requirements when examining the requirements analysis phase of the Software Life Cycle. We found that they are often stated explicitly in the user requirement document and frequently relate to hardware, software, time or money. Hence, a statement to the effect that new software is to be implemented on an Olivetti M24 successfully eliminates all designs that could not be implemented thereon. Similarly, a non-functional requirement that standard input/output software is to be used, cuts out all those designs involving purpose-built input/output software.
Time and money also constrain design. If it is essential that the software is available for operational use by a certain date, then all designs that are so complex that they could not meet the deadline must be rejected. Similarly, designs that will cost in excess of the user’s budget to implement must go.
Although the application of constraints can severely limit the number of choices available to the designer, the size of selection will still seem unmanageable. After all a very large number, less a large number, is still a very large number. So a designer still needs some help in tackling the selection problem. This help comes in the form of what are termed design heuristics or, if you prefer, rules-of-thumb.
1.2.3 Design heuristics
Let us turn again to problem of adding fifty numbers and its 6.85x1081 adding trees. Just suppose that it is possible to identify five of the numbers as being related in some way so that they could be close together in the adding tree, e.g., they are all octal, perhaps, whereas the others are not. We know that the prospect of adding these five numbers will give rise to 236 possible adding366
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] ... 下一页 >>