<< Chapter < Page | Chapter >> Page > |
In the second example, the customer requires the following for a software system: the system must read input data from a specific card reader from a specific manufacturer. Besides the goal, the designer finds the following restriction. The specific manufacturer does not provide the card reader drivers for one of the operating systems the system must execute on. If it werenât for this restriction, the design for the input data module would be quite straightforward: just rely on the hardware driver to fetch the input data from cards. But now the designer will have to work out an alternative design to handle this restriction. One design possibility could be emulating one of the operating systems supported by the manufacturer when the system is executing in a non-supported environment. This would mean the creation of a layer of abstraction that would represent the supported environment and eventually be implemented by a native or an emulated system. Another possibility could be just designing and implementing the missing driver.
A design alternative is a possibility of solution. Since design problems often have multiple solutions, since design problems often have multiple solutions, the designer is expected to generate multiple design alternatives for a single problem. We must understand that the designer, after understanding the problem's goals and constraints, has two concerns: the alternative generation and the solution election among the alternatives.
Alternative generation poses the real challenge for a designer. Unlike decision problems area where decision alternatives are known or can be discovered through search methods, design alternatives must be created. This creation process then must be controlled by design enabling techniques, and designer's experiential knowledge and creative imagination . "Enabling Techniques" will present some essential techniques for a designer.
The solution election is simply the choice of one of the alternatives that, according to the designer, will best solve the problem. This choice must be made employing reasoned analysis and experience. The following subsections better explain solutions and their representations.
Back to our sorting program example, let us only consider one aspect of it, the sorting algorithm to be used, and see how many alternatives a designer could generate. A quick search on the Internet returned nine algorithms that respect the growth rate of constraint (binary tree sort, heapsort, in-place merge sort, introsort, library sort, merge sort, quicksort, smoothsort, strand sort). So, we have nine design alternatives that can be easily achieved. On the other hand, an experienced designer, who knows that these algorithms may run better or worse according to the input, proposes that two algorithms will added to the design and, on every run, one is elected to be used according to the input. Then, we have more design alternatives being generated. Please notice that the alternative generation can go on and on as the designer considers more aspects of the problem. Nevertheless, she must know when to stop the alternative generation, since design problems have potentially infinite alternative solutions. Such knowledge comes with experience.
Notification Switch
Would you like to follow the 'Software architecture for experts-to-be' conversation and receive update notifications?