Evaluation
At this point, we defined an initial set of components and their possible connections, completing a first pass at the definitions for the software architecture. A complete architecture diagram with all proposed connections is shown in Figure 6. A key aspect of the process was the continual reference to the growth and change issues. This method is appropriate because it is in the definition of the software architecture that the quality attributes, such as maintainability, extensibility, modularity, etc., get designed into the final product. By being aware of the change cases while we are defining components and allocating responsibilities, we increase the likelihood that the design is as modular as it needs to be. Being good designers, however, requires that we explicitly demonstrate that our design definitions meet the requirements. For that reason, we should carry out the evaluation described next. Simple evaluations, done early, are very helpful.
The inputs to the preliminary architecture included use cases and some change cases. The evaluations we can do at this point consist of qualitative walk-throughs of the use and change on the architecture.
In summary, it can be noticed that in defining the architecture for a software system there are no right or wrong answers, only trade-offs. It may be noticed that the architecture and its evaluation in this example do not represent a perfect design, but they depict the line of thinking contained in this pattern. Our intention is not to show a perfect design, but to demonstrate a process for developing and evaluating designs, and for finding and fixing problems. There are a lot of problems in this example, some of which were discussed, a few fixed, and some which have not been found yet.
Jorge Luis Ortega Arjona.