Bass et al take up the issue of design in Chapter 7 of their book Software Architecture in Practice, 2nd ed. The chapter is written by Felix Bachmann. In his Evolutionary Delivery Life Cycle, a Preliminary Requirements Analysis results in a small handful of "architectural drivers, ... the highest priority business goals." (p155). Not all of the business goals may have an impact on the structure of the software system however so only those that will have an impact on the architecture are chosen.
One question that comes up in class that is difficult to answer is how to square the interative methodology of the Evolutionary Delivery Life Cycle (and Agile methods in general) with the waterfall approach that is described elsewhere. In short, I cannot except to say that at some point you need to move forward. Hopefully you won't make too many mistakes. But it is clear that some of the earliest architectural decisions constrain those that follow. Once made, they are difficult to revisit without risking a great deal of prior work. My answer has been that it requires judgment and experience to know. Ironically these are the two qualities of the team members that management seems to ignore when they advocate adoption of Agile methods.
The selection of the architectural drivers sets the stage for the beginning of the Attribute Driven Design methodology(ADD). One good aspect of ADD is that it puts the focus on the quality (non-functional) attributes desired of the system and not the functionality. I think this is key and I don't find a satisfying explanation in the text.
At the lowest level there are only functions. Yet what is desired is non-functional. How can this be? Somehow non-functional attributes emerge from a collection of functions. What the ADD does is focus the designer on those non-functional aspects of the system to be delivered and make them reason about how their selection of functional decisions will cause these non-functional attributes to emerge. But I digress from their text...
At the beginning of the design, the designer is faced with the software equivalent of a blank page; a single box with input, and output. Like a surgeon making the first cut, the designer must decompose this single module into two or more with relationships between and among them. The justification for this decomposition must be the furthering of some non-functional attribute.
The book doesn't explicitly say this but after the decomposition the non-functional attribute has either been satisfied by this decomposition or it follows one or more of the newly created modules. So the new modules will inherit a combination of functional and non-functional requirements from this decomposition. The clear implication here is that some combination of functional elements with the correct relations between them create the non-functional attribute. As the decomposition progresses, it eventually reaches a level of decomposition where the designer is no longer concerned that the attribute will not be achieved. One of two things will have happened by that time: either the design no longer pushes non-functional requirements onto decomposed modules leaving purely functional specifications for those modules; or the achievement of the non-functional requirements is self-evident, at least to the designer.
ADD stresses the choice of pattern or tactic to be used to achieve this decomposition. Since these patterns are know to further specific non-functional attributes, this makes sense. I think in my teaching I did not emphasis this quality to functional relationship that is seen in these patterns. From the standpoint of possible research and tool development this is an exciting aspect. While hardly mechanical, once the desired attributes are identified, the system can prompt with possible patterns/tactics that can be tried. The designer can pick the most likely candidate and have the system assist with moving functionality and qualities to the appropriate modules. Some modules will inherit all the functionality or qualities of their parent. But often the functionality or quality will attach to some subset.
Bachmann makes an astute observation on page 158 re the possibility that not all design proceeds strictly top-down. When it is a mature domain with experienced designers, there are probably few surprises that would cause a rethinking of prior decompositions. However this is a high bar and even mature domains when met with novel business requirements can pose challenges. In this case, the decision tree may proceed to a relatively low level (for architecture) before the designer becomes aware of a dead end or an unacceptable trade off. Or perhaps it is unclear whether or which decisions will lead to the achievement of a particular attribute. In those cases prototyping or some other form of contingent design is needed. The design space must be explored so as to ascertain that a particular choice will lead to the needed result.
This chapter helped me answer a question that came up that I did not give a satisfactory answer to: what is the difference/relationship between a tactic and a pattern? Tactic is defined in opposition to strategy. Where strategy is the overall plan which will encompass many operations, a tactic has to do with the execution, the doing. In software this will be the equivalent of implementation. So while architecture deals with the strategic element of the project, the decisions that commit to a course of action are the tactics. I would say that the choice of how to divide a given module, even when that module is the first one attacked, the entire system, that choice is a tactical decision. If it is possible, the subsequent decomposition decisions will be at least roughly known and anticipated. However this definition of tactic doesn't get me where I need be for this explanation.
On page 100 in chapter 5, Bachmann, Klein and Wood define tactic as "a design decision that influences the control of a quality attributes response". This at least gets us into the domain of software design. It also gives me the crack I need for my piton. If the tactic is the decision, that decision will result in some form. The pattern is the form that results. To apply a pattern is to make a tactical decision or to employ a tactic. I can forgive the students for not working their own way through these semantics.
In ADD, a pattern is chosen to enhance the attribute desired. But patterns rarely promote a single attribute and often diminish one while advancing another. Therefore each decision causes an evaluation of the tradeoffs between these attributes. If the designer is lucky, the attributes diminished by the choice are not critical to the success. But if they are, other patterns must be sought to achieve considered. The book offers the example of using an interpreted language to achieve modifiability. While the use of HTML does improve modifiability, it also comes with a performance price.
No comments:
Post a Comment