trees. The evaluation of the 236 alternatives is perfectly feasible and the optimal adding sub-tree for these five numbers could be selected. We could then be able to replace the five numbers and with a single node representing the optimal adding sub-tree. So that we have now achieved a reduction in the numbers to be added from 50 to 46, i.e.,45 numbers and a sub-total from the sub-tree.
The process could be repeated taking five numbers at a time and replacing them, similarly, with a single satisfactory sub-tree or design.
The process would involve thirteen cycles, 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 12x236, i.e., 2832 separate designs (Emery, 1969).
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 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. So that design is no longer impossible but merely tedious and formidable.
The above is an example of a design heuristic, a rule-of thumb used by the designer to reduce drastically the size of selection 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.
The similarity 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, one 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:
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.
Spoken with almost-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 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 untrustworthy.
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 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.
1.3 DESIGN CRITERIA
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 criterion, 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 suppose that the parent decision-maker, from the information available about fare structures, timetables and so on, has assembled the table shown as Fig.1.3.
The three modes of transport are called P, Q and R to disguise our own prejudices. For each mode, 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 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 only with how you arrived at it.)
If you arrived 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.
You probably 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.
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 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 anyway.
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. 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 be noted that selection can be formalized to take all the factors mentioned above into account, by developing what is known as a multi-attribute utility function. However, these are deep waters and we had better turn back before we all sink.
1.3.1 Pressures and criteria
So far, we have not considered why the family decision-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-maker. 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.
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 dozing 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 pressures to the satisfaction of all. Or at least, so that not too much dissatisfaction is experienced by anybody. We can note also that the trading off process will be conditioned by the relative weights that the decision-maker places on the competing pressures.
The idea of associating weights with pressures is fundamental to the activities of the software designer, to whom we must now return.
1.3.2 Pressures and software design
When studying earlier material concerning the software life cycle you were asked to complete an exercise (Exercise 2.2) asking for 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 important ones would include:
Economy, Reliability, maintainability, Robustness, Integrity, Security
The definitions for the first three are reasonably obvious. But what do you understand 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 more 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 destruction of programs and data. Whereas ‘security’ applies to a system’s resistance to deliberate damage.
The point that we are coming to is that we are now examining another pressure situation, one that is illustrated in Fig.1.5.
The pressures are shown as originating with the user as a single entity. 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 the designer is in exactly the same position as the harassed parent in the previous section, needing to resolve
上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] ... 下一页 >>
在线考试系统论文(源代码+流程图) 第2页下载如图片无法显示或论文不完整，请联系qq752018766
