外文翻譯---問(wèn)題解決和決策

1、<p><b>　　Selection</b></p><p>　　1.1 PROBLEM-SOLVING AND DECISION-MAKEING</p><p>　　It is helpful at this stage to introduce the ideas of problem solving, a structure for which wa

2、s first described by Dewey (1910). The stages identified by John Dewey were: What is the problem? What are the alternatives? Which alternative is best? You should now be in a position to identify a resemblance between De

3、wey’s three stages and the software life cycle. </p><p>　　Enough has been said about the life cycle earlier for us to spot a distinct resemblance between the first stage of problem definition and our require

4、ments analysis phase. In fact many organizations use the term ‘problem’ or ‘project definition’ rather than ‘requirements analysis’. The final two stages may similarly be identified as being equivalent to the phase that

5、we refer to as ‘design’.</p><p>　　A more recent, but very relevant structure has been supplied in the context of decision-making (Simon, 1960). Professor Simon labels the stages of decision-making as follows

6、: Intelligence activity, Design activity and Choice activity.</p><p>　　The term ‘Intelligence’ is used here in the military sense, i.e., searching the environment for conditions requiring a decision to be ma

7、de. ‘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

8、 corresponds to the intelligence activity. Although the software designer does not need to search too hard for circumstances requiring a decisio</p><p>　　However Simon’s use of the term ‘Design’ differs from

9、 ours. Whereas Simon uses the word to describe the generation of possible solution, we use it in the sense that selection is included also.</p><p>　　There seems to be some justification for believing that pr

10、oblem-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 ju

11、st 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 questio

12、ns</p><p>　　1.2 SIZE OF SELECTION</p><p>　　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

13、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.</p><p>　　In order to ma

14、ke 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 mini

15、mized. 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 consumptio

16、n of your car. Such a property, in this case t</p><p>　　1.2.1 Combinatorial explosion</p><p>　　In the foregoing example the design problem was trivial, for the selection had to be made from thre

17、e 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 num

18、bers. 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.</p><p>　　As is usual in computing, the trees are upside down

19、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 tre

20、e, 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. </p><p>　　It is not too difficult to calculate the number of

21、 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.</p><p>　　This is a considerable increas

22、e 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 e

23、lements, 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 desi

24、gns – a conversation-stopper i</p><p>　　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

25、 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 ele

26、ctronic means, say, it takes one-millionth of a second to examine and assess each of the possible adding trees fo</p><p>　　This particular design problem would take 2.17x1066 centuries to complete thus indic

27、ating 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

28、 many intelligent people knowingly attempt the impossible, often to good effect.</p><p>　　1.2.2 Constraints</p><p>　　Design, in general, is helped considerably if as many alternatives as possibl

29、e 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

30、 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</p><p

31、>　　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 reje

32、cted. Similarly, designs that will cost in excess of the user’s budget to implement must go.</p><p>　　Although the application of constraints can severely limit the number of choices available to the designe

33、r, 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 co

34、mes in the form of what are termed design heuristics or, if you prefer, rules-of-thumb.</p><p>　　1.2.3 Design heuristics</p><p>　　Let us turn again to problem of adding fifty numbers and its 6.8

35、5x1081 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 o

36、thers are not. We know that the prospect of adding these five numbers will give rise to 236 possible adding trees. The evaluation of the 236 alternatives is perfectly feasible and the optimal adding sub-tree for thes<

37、/p><p>　　The process could be repeated taking five numbers at a time and replacing them, similarly, with a single satisfactory sub-tree or design.</p><p>　　The process would involve thirteen cycles

38、, each one involving the evaluation of 236 designs, except the last. The last cycle would involve only two numbers and this would permit only once design. Consequently, the total process would involve the evaluation of 1

39、2x236, i.e., 2832 separate designs (Emery, 1969).</p><p>　　Even with this reduction in the number of separate designs, there is still a lot to do. If it takes a quarter of an hour to examine and assess each

40、alternative, how long would it take to design the optimal adding tree using the above procedure? Design would now take 708 hours. Or , assuming that one designer is working on the problem, just under 18 working man-weeks

41、. So that design is no longer impossible but merely tedious and formidable.</p><p>　　The above is an example of a design heuristic, a rule-of thumb used by the designer to reduce drastically the size of sele

42、ction until it becomes a manageable problem. The source of such design heuristics may experience or the native cunning of the designer, or it may be part of the folklore of the profession.</p><p>　　The simil

43、arity with folklore does not stop there. You are, no doubt, familiar with a number of folkloric expressions of the ‘red sky at night, shepherds’ delight’ type. On hearing this from the lips of some weather-beaten sage, o

44、ne can almost hear the quotation marks. And so it is with designers. The expert at designing adding trees for fifty numbers, when holding forth in the local drinking establishment, might well say: </p><p>　　

45、Take five numbers that for some reason should be close together on the tree, replace them with a single node representing the optimal sub-tree, and repeat until one tree remains.</p><p>　　Spoken with almost-

46、audible quotation marks such a statement may take on the authority of holy writ, and therein lies a danger. The danger is that a particular heuristic may have been regarded so favorably by practitioners that it is taken

47、to be a fundamental truth. The trouble is that times change and, particularly in computing, so does technology. So that a design heuristic that has been used successfully for some time may rapidly become obsolete and unt

48、rustworthy.</p><p>　　Despite these difficulties, design could not take place at all without heuristics. You will find soon that design strategy usually makes use of them, and they also play an important part

49、 in ‘polishing’ or refining a first design acquired by other techniques. Thus part of a designer’s skill lies in his or her ability, not only to apply heuristics, but also to choose them with care.</p><p>　　

50、1.3 DESIGN CRITERIA</p><p>　　We commenced sec. 1.2 with a simple problem, designing the transportation arrangements for a family day-out to the seaside. We noted that with three alternatives and a single cri

51、terion, direct costs or journey time, the problem is trivial. But we also stated that if both criteria are important then the design problem becomes rather more difficult. To take this matter a little further, let us sup

52、pose that the parent decision-maker, from the information available about fare structures, timetables </p><p>　　The three modes of transport are called P, Q and R to disguise our own prejudices. For each mod

53、e, estimates of direct costs and journey time are entered. It is clear that if direct cost is the sole criterion then R is favorite; if journey time is of lone importance then P wins, hands down. Try and imagine yourself

54、 in the position of the parent decision-maker. On the basis of the information in Fig.1.3, what would your choice be? (Just for once we are not concerned with your actual answer but onl</p><p>　　If you arriv

55、ed at a decision, and whether your answer was P, Q or R, you almost certainly got there by using the process of trading off, although you may not have been aware that you were so doing.</p><p>　　You probably

56、 posed yourself questions such as: ‘is it worth incurring extra costs of £2.35 in order to save 25 minutes on the journey?’ and from the answers that you gave yourself, you arrived at your conclusion.</p><

57、;p>　　You may also have thought that it was a daft question for, in practice, you would need to take other properties or attributes into account, e.g., comfort, convenience and if Aunt Gloria insists on coming (as she

58、usually does), the scenic beauty of the route, perhaps. You may have noted at the same time that these three attributes of the transport mode are intangible, so that trading them off against direct costs is a non-starter

59、 anyway.</p><p>　　You may also have toyed with ideas of uncertainty, bearing in mind that engineering works, traffic jams, staff shortages and breakdowns could completely invalidate the stated journey times.

60、 These complaints are quite reasonable but, nevertheless, people do take decisions like the one we have been discussing here, all the time. Largely, they will use a combination of trading off and intuition. But it should

61、 be noted that selection can be formalized to take all the factors mentioned above into acc</p><p>　　1.3.1 Pressures and criteria</p><p>　　So far, we have not considered why the family decision-

62、maker in the previous section lighted upon direct costs and journey time as the exclusive design criteria. If we think about this carefully we realize that this is due to pressures being brought to bear on the decision-m

63、aker. We do not exclude such pressures being self-generated but it is simpler to regard them as arising from outside. We are then able to represent the situation neatly and graphically by a sketch as in Fig. 1.4.</p&g

64、t;<p>　　We see now the origins of the design criteria. The thrifty spouse is insisting on low costs; impatient children are demanding a short journey time. No doubt Aunt Gloria (who likes nothing better than dozin

65、g in National Park car parks and is filthy rich the bargain), if she existed, would also be exerting a pressure that would be well-nigh irresistible. So that the decision will be taken in an attempt to resolve these pres

66、sures to the satisfaction of all. Or at least, so that not too much dissati</p><p>　　The idea of associating weights with pressures is fundamental to the activities of the software designer, to whom we must

67、now return.</p><p>　　1.3.2 Pressures and software design</p><p>　　When studying earlier material concerning the software life cycle you were asked to complete an exercise (Exercise 2.2) asking f

68、or your views on the attributes or properties to be taken into account when comparing software designs. In the solution to the exercise it was suggested that they were many and various but that a list of the most importa

69、nt ones would include: </p><p>　　Economy, Reliability, maintainability, Robustness, Integrity, Security</p><p>　　The definitions for the first three are reasonably obvious. But what do you under

70、stand by robustness, integrity and security? You will recall from the exercise solution that by robustness we mean the capability of a system to handle variations in volumes of transactions. Integrity and security are mo

71、re difficult to define with any authority as very often they are used interchangeably. The authors’ preference is to use the term ‘integrity’ to describe resistance to accidental corruption or destru</p><p>

72、　　The point that we are coming to is that we are now examining another pressure situation, one that is illustrated in Fig.1.5.</p><p>　　The pressures are shown as originating with the user as a single entity

73、. In practice, of course, different individuals and departments within the user organization will have different vested interests in the software performance and the pressures that they exert will differ accordingly. But

74、 the designer is in exactly the same position as the harassed parent in the previous section, needing to resolve the design problem in such a way that the user’s satisfaction is maximized.</p><p>　　The desig

75、ner really needs some composite measure that could be derived for every competing design, which reflects as closely as possible the user’s comparative rating of the attributes for importance and makes due allowance for u

76、ncertainty. What the designer really needs , therefore, is a multi-attribute utility function. But we have shied away from this once and we shall do so again. The excuse for being so chicken is that such functions are in

77、credibly difficult to derive in the software design</p><p>　　However, in very limited circumstances (which we shall explain later) a designer may feel obliged to introduce some objectivity into his or her se

78、lection mechanism. This will usually involve a development of the trading off process that we have already encountered and requires the application of what is known as the value function. In the simplest terms this means

79、 forming a weighted average of individual attributes. For instance, we might represent the value of a software design V (S), as follow</p><p>　　{c1 x value of attribute 1}+{c2 x value of attribute 2}+{c3 x v

80、alue of attribute 3}+</p><p>　　…+{cn x value of attribute n} (1)</p><p>　　Where c1, c2, c3, …, cn are weighting factors.</p><p>　　It is

81、often convenient to represent both the value of any one attribute and the value of the combination of attributes over a standard range, say from 0 to 100. In these circumstance, the condition (c1+c2+c3+…+cn=1) is imposed

82、 (Chapman, 1980).</p><p>　　In order to demonstrate the use of the value function let us assume that a designer is due to make a final choice from three candidates designs. We will assume also that the pressu

83、res on the designer are limited to three: economy, reliability and robustness. The data relative to the three designs is assembled in Fig.1.6.</p><p>　　The diagram shows for each of the designs, X, Y and Z,

84、the estimated attribute values for each design criterion. You will note that we represent economy by the operating costs of the system in thousands of pounds per year. The measure of reliability is percentage availabilit

85、y, i.e., the proportion of time that the software is expected to be functioning correctly. Robustness is represented by the percentage tolerances on the volume that the system is being designed to handle. Our first move

86、must </p><p>　　Value function – single attribute A value function merely expresses the desirability of different ‘quantities’ of a particular attribute. We construct it by ranking all possible values for the

87、 attribute in order of desirability, assigning 0 to the least desirable, 100 to the most desirable and appropriate values in the range 0 to 100 to the others. We might thus arrive at value functions for the three criteri

88、a of interest to us, as in Fig.1.7.</p><p>　　The functions should represent, as far as can possibly be determined, the values of the attributes to the user. Note that the functions are not necessarily linear

89、 although we have shown two of them as being so. Note also that we show the worst result at the left-hand side of the horizontal axis and the best result at the right. This means that for economy, for which low results a

90、re preferred, the scale decreases from left to right. For the other two, it increases from left to right. We now have </p><p>　　Value function – multi-attribute We evaluate each of the three competing design

91、s in terms of economy, reliability and robustness by using a version of expression (1) p.49:</p><p>　　V(S)= {c1 x value of economy}+{c2 x value of reliability}+{c3 x value of robustness} (2)</p><

92、;p>　　All that remains is to assign values to the three weighting factors c1, c2 and c3 and these evaluations should reflect the relative severity of the corresponding pressures on the designer.</p><p>　　S

93、ummary There is a certain amount of caution to be observed if serious use is to be made of the multi-attribute value function. First, a theoretical condition, known as preferential independence must be met. This conditio

94、n is only satisfied if preferences which hold between any pair of attributes are independent of the values of any other attributes. For instance, if a design with estimated operating costs of £25000 per year and 97

95、per cent availability is preferred to design with operating cost</p><p>　　A second difficulty lies in the choice of weighting factors. We saw in Exercise 1.3 how a casual change in the factors threw up a new

96、 best design. A mere reaction to conflicting pressures on the part of the designer may not be an adequate mechanism for valuing the factors. It may be necessary to adopt more formal methods for deriving them. These invol