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
<< 上一页 [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] 下一页