Posted on by SATURN Conferencein
Rick Kazman, University of Hawaii and Carnegie Mellon Software Engineering Institute, and Humberto Cervantes, Universidad Autónoma Metropolitana-Iztapalapa
Design is hard. Architects need insight into types of architectural drivers, guidance on selecting design concepts, and what drives certain design decisions to make good decisions by considering these consciously. Architects also need an approach to negotiate with management and stakeholders better to make these good decisions. In this tutorial session, Kazman and Cervantes presented an updated version of the 2006 Architecture-Driven Design Method 2.0 to address these concerns.
ADD 3.0 covers the four main phases of the life cycle:
Architectural Drivers > Design > Documentation > Evaluation.
The drivers are the requirements that shape the architecture, including functional requirements, quality attribute requirements, constraints, design objectives, type of system, and concerns, which include decisions that the architect will need to make but that aren't stated explicitly as requirements. Remember that constraints can be your friends. They are simply design decisions over which you have little or no control, and they can reduce the size of the decisions base. The architectural design maps the problem domain onto the solution domain. Documenting the decisions is important for communicating and analyzing them. There are many architecture design methods: RUP, ADD, ACDM, Microsoft, and more. Most cover the whole life cycle but contain little detail about how actually to do design. There's just a "do design now" step. A method such as ADD 3.0 will help you even if you don't follow it precisely. A method can be performed in a systematic and repeatable way and help you prioritize requirements. Without this, architecture design is a mystic activity performed by gurus, not a field aspiring to an engineering discipline. ADD 2.0 promoted an iterative approach to design and provided steps, but it had limitations: The only inputs were QA and functional requirements, each iteration decomposed only a single element that was chosen before the drivers, design concepts included only patterns and tactics, and it did not include initial documentation. The steps of ADD 3.0 are as follows:
In these steps, the design is produced, but it's not necessarily BDUF because an iteration can be small. The approach relies on Design Concepts. Architects want to avoid reinventing the wheel, and it's faster to use proven solutions. The creativity comes in adapting and combining them. Design Concepts include
The second half of the tutorial worked through three illustrations of iterations for a Network Management System "Marketecture" that provides network status, event lists, and performance data.
And that's the first iteration of three example iterations. In the second iteration, you now have a system structure, so next you should work toward supporting the primary functionality. Selections of reference architectures and patterns will change according to the iteration goal and elements involved. Note that an element's functionality will cross layers. The third illustration focuses on a specific quality attribute, the availability scenario. Addressing QAs usually involves multiple design concepts, and Humberto recommends starting with tactics. When do we finish design? "Never" and "when you run out of time" are not good answers. Ideally, you are done when you have reached your design goal by making decisions for the most important drivers and most important technical risks. "Architecture design transforms drivers into structures."