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

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.