Designing an Architecture
1. Design Strategy
•
•
•
Decomposition
Designing to Architecturally Significant Requirements
Generate and Test
This generate-and test approach views a particular design as a hypothesis: namely
the design satisfies the requirements. Testing is the process of determining
whether the design hypothesis is correct.
• Creating the initial hypothesis
• Existing systems
• Frameworks
• Patterns and tactics
• Domain decomposition
• Design checklists
• Choose the tests
•
•
•
•
•
The analysis techniques
The design checklists
The architecturally significant requirements
Generating the next hypothesis
Terminating the process
Designing an Architecture
2. The Attribute-Driven Design Method
• ADD is an iterative method, at each iteration do the following
• Choose a part of the system to design
• Marshal all the architecturally significant requirements for that part
• Create and test a design for that part
•
Inputs to ADD:
• Known ASRs
• Context description
• What are the system boundaries of the system being designed?
• What are the external systems, devices, users, and environmental conditions with
which the system being designed must interact?
•
Output of ADD:
• A set of sketches of architectural views with incremental completeness and details:
• Module decomposition view
• Other views according to the design solutions chosen along the way
Designing an Architecture
Designing an Architecture
3. The Steps of ADD
• Step 1: Choose an element of the system to design
• For green-field designs, the element to begin with is simply the entire system.
• The first iteration of ADD will create a collection of elements that together constitute the
entire system, based on (high-level) ASRs.
• A later iteration of ADD will take one of these elements, called chosen element, and
design it, resulting in still finer-grained elements.
• Refinement strategies to pursue with ADD
• Breadth first: all second-level elements are designed before any the third-level
elements, and so forth.
• Depth first: one downward chain is completed before beginning a second
downward chain.
• Business and technical factors that influence refinement:
• Personal availability may dictate a refinement strategy
• Risk mitigation may dictate a refinement strategy
• Deferral of some functionality or quality attribute concerns may dictate a
mixed approach
• All else being equal, a breadth-first refinement strategy is preferred because it
allows to apportion the most work to the most teams soonest.
Designing an Architecture
3. The Steps of ADD
• Step 2: Identify ASRs for this element
• To support the design process, the utility tree guides the stakeholders in prioritizing the
quality attribute requirements, with the two factors:
• Business value
• Architectural impact
•
Step 3: Generate a design solution for the chosen element
• The heart of the ADD
• The application of the generate-and-test strategy
• For the chosen element and identified ASRs, develop a solution by choosing a candidate
design approach: architectural patterns, tactics, and design checklists.
• The design decisions made in this step now become constraints on all future steps of the
method.
Designing an Architecture
3. The Steps of ADD
• Step 4: Verify and refine requirements and create input for the next iteration
• A test step that applied to the current design for the chosen element.
• Backtrack: an important requirement was not satisfied and cannot be satisfied by further
elaborating this design, which may also be related to the parent element in terms of
quality attribute requirements, functional responsibility, and constraint.
Designing an Architecture
3. The Steps of ADD
• Step 4: Verify and refine requirements and create input for the next iteration
• Sequence through the quality attribute requirements, responsibilities, and constraints for
the chosen element just design.
• For each one, there is one of 4 resulting possibilities after the sequencing
• The quality attribute requirement, functional requirement, or constraint has been
satisfied.
• The quality attribute requirement, functional requirement, or constraint is delegated
to one of the children.
• The quality attribute requirement, functional requirement, or constraint is
distributed among the children.
• The quality attribute requirement, functional requirement, or constraint cannot be
satisfied with the current design, with 2 solution options:
• Backtrack: revisit the design to see if the constraint or quality attribute
requirement can be satisfied some other way
• Push back on the requirement to the stakeholder(s) with convincing arguments.
•
Step 5: Repeat steps 1-4 until done
Designing an Architecture
3. The Steps of ADD
• Step 5: Repeat steps 1-4 until done
• After steps 1-4, each element has a set of responsibility, a set of quality attribute
requirements, and a set of constraint assigned to it.
•
If it is clear that all the requirements are satisfied, then the ADD process should end.
•
The ADD process can be terminated when only a sketch of the architecture is available
or more with more detailed levels, depending on trust levels between the architect and
the implementation team.
• More trust, less architecture design details
• Less trust, more architecture design details
• Early architecture design can be released before the ADD process terminates, for
stakeholder communication and evaluation.