Attribute-Driven Design Minsoo Ryu Hanyang University msryu@hanyang.ac.kr
Attribute-Driven Design The ADD method is an approach to defining a software architecture in which the design process is based on the software quality attribute requirements ADD follows a recursive process that decomposes a system or system element by applying architectural tactics and patterns that satisfy its driving quality attribute requirements 2 2
Plan, Do, and Check ADD essentially follows a Plan, Do, and Check cycle: Plan: Quality attributes and design constraints are considered to select which types of elements will be used in the architecture Do: Elements are instantiated to satisfy quality attribute requirements as well as functional requirements Check: The resulting design is analyzed to determine if the requirements are met 3 3
Steps of ADD 4 4
Inputs to ADD ADD Inputs and Outputs Functional requirements Eg) The system shall allow users to review account activity Design constraints Eg) System services must be accessible through the World Wide Web Quality attribute requirements Eg 1) buildability: The system shall be buildable within six months Eg 2) availability: The system shall recover from a processor crash within one second Eg3) portability: The system shall allow the user interface (UI) to be ported to a new platform within six months 5 5
ADD Inputs and Outputs Outputs to expect from ADD The output of ADD is a system design in terms of the roles, responsibilities, properties, and relationships among software elements Software element: a computational or developmental artifact that fulfills various roles and responsibilities, has defined properties, and relates to other soft-ware elements to compose the architecture of a system Role: a set of related responsibilities Responsibility: the functionality, data, or information that a software element provides Property: additional information about a software element such as name, type, quality attribute characteristic, protocol, and so on Relationship: a definition of how two software elements are associated with or interact with one another 6 6
Step 1. Confirm There Is Sufficient Requirements Information You confirm that there is sufficient information about the requirements to proceed with ADD In essence, you make sure that the system s stake-holders have prioritized the requirements according to business and mission goals You should also confirm that there is sufficient information about the quality attribute requirements to proceed As the architect, you use the prioritized list of requirements to determine which system elements to focus on during the design You consider requirements and their potential impact on the architecture s structure in descending order of importance to stakeholders Requirements that have not been prioritized should be flagged and returned to the stakeholders for ranking 7 7
Step 2: Choose an Element of the System to Decompose You choose which element of the system will be the design focus in subsequent steps You can arrive at this step in one of two ways: You reach Step 2 for the first time as part of a greenfield development The only element you can decompose is the system itself By default, all requirements are assigned to that system You are refining a partially designed system and have visited Step 2 before In this case, the system has been partitioned into two or more elements, and requirements have been assigned to those elements You must choose one of these elements as the focus of subsequent steps 8 8
Step 3: Identify Candidate Architectural Drivers At this point, you have chosen an element of the system to decompose, and stake-holders have prioritized any requirements that affect that element During this step, you ll rank these same requirements a second time based on their relative impact on the architecture This second ranking can be as simple as assigning high impact, medium impact, or low impact to each requirement If you use simple high/medium/low rankings, the groups would be (H,H) (H,M) (H,L) (M,H) (M,M) (M,L) (L,H) (L,M) (L,L) 9 9
Selecting Requirements You should choose several (five or six) high-priority requirements as the focus for subsequent steps in the design process The selected requirements are called candidate architectural drivers for the element currently being decomposed 10 10
Step 4: Choose a Design Concept That Satisfies the Architectural Drivers You should choose the major types of elements that will appear in the architecture and the types of relationships among them Design constraints and quality attribute requirements (which are candidate architectural drivers) are used to determine the types of elements, relationships, and their interactions 11 11
Six Sub-steps 1. Identify the design concerns that are associated with the candidate architectural drivers 2. For each design concern, create a list of alternative patterns that address the concern 3. Select patterns from the list that you feel are most appropriate for satisfying the candidate architectural drivers (Record the rationale for your selections) 12 12
Six Sub-steps 4. Consider the patterns identified so far and decide how they relate to each other 5. Describe the patterns you ve selected by starting to capture different architectural views, such as Module, Component-and-Connector, and Allocation views 6. Evaluate and resolve inconsistencies in the design concept 13 13
Step 5: Instantiate Architectural Elements and Allocate Responsibilities You instantiate the various types of software elements you chose in the previous step Instantiated elements are assigned responsibilities according to their types For example, in a Ping-Echo pattern, a ping-type element has ping responsibilities and an echo-type element has echo responsibilities Responsibilities for instantiated elements are also derived from the functional requirements associated with candidate architectural drivers and the functional requirements associated with the parent element At the end of Step 5, every functional requirement associated with the parent element must be represented by a sequence of responsibilities within the child elements 14 14
Step 6: Define Interfaces for Instantiated Elements You define the services and properties required and provided by the soft-ware elements in our design In ADD, these services and properties are referred to as the element s interface Note that an interface is not simply a list of operation signatures Interfaces describe the PROVIDES and REQUIRES assumptions that software elements make about one another An interface might include any of the following syntax of operations (e.g., signature) semantics of operations (e.g., description, pre- and postconditions, restrictions) information exchanged (e.g., events signaled, global data) quality attribute requirements of individual elements or operations error handling 15 15
Step 7: Verify and Refine Requirements and Make Them Constraints for Instantiated Elements You verify that the element decomposition thus far meets functional requirements, quality attribute requirements, and design constraints You also prepare child elements for further decomposition 16 16
Step 8: Repeat Steps 2 through 7 for the Next Element of the System You Wish to Decompose Once you have completed Steps 1 7, you have a decomposition of the parent element into child elements Each child element is a collection of responsibilities, each having an interface description, functional requirements, quality attribute requirements, and design constraints You can now return to the decomposition process in Step 2 where you select the next element to decompose 17 17
Integrating QAW and ADD
Architecture Centric Design Methods Proposed by Anthony J. Lattanze on January 1st, 2006. The architecture-centric methods: are explicitly focused on quality attributes directly link to business and mission goals explicitly involve system stakeholders are grounded in state-of-the-art quality attribute models and reasoning frameworks are documented for practitioner consumption 19 19
Architecture Centric Methods and Process Activities 20 20
Software Qualities and Software Architecture 21 21
QAW Overview The Quality Attribute Workshop (QAW) is a facilitated method that engages system stakeholders early in the life cycle to discover the driving quality attribute requirements of a software-intensive system 22 22
ADD Overview The Attribute-Driven Design (ADD) method is an approach to defining a software architecture by basing the design process on the quality attribute requirements of the system 23 23
ATAM Overview The Architecture Tradeoff Analysis Method (ATAM) is a method that helps a system s stakeholder community understand the consequences of architectural decisions with respect to the system s quality attribute requirements 24 24
Life Cycle Integration 25 25
QAW Activity 26 26
ADD Activity 27 27
ATAM Activity 28 28
Architectural Tactics Architectural tactics are tactics for the architect to create a design using design patterns, architectural patterns, or architectural strategies 29 29
Designing for Availability Faults vs. Failures Tactics Fault detection Fault recovery Fault prevention 30 30 30
Fault detection Ping/echo; Heartbeat; Exceptions Fault recovery Tactics for Availability Mostly redundancy based [byzantine faults] Voting: multiple processes working in parallel. [crash, timing] Active redundancy hot restart [crash] Passive redundancy (warm restart), Spare. Reintroduction: shadow operation, resynchronization, checkpoint/rollback Fault prevention Removal from service; Transactions 31 31
Modifiability Modifications to a software system during its lifetime are a fact of life Ideal: modifiable systems that are easier to change/evolve Modifiability should be assessed in context of how a system is likely to change No need to facilitate changes that are highly unlikely to occur Impact of designing for modifiability is rarely easy to quantify Minimizing dependencies increases modifiability Changes isolated to single components likely to be less expensive than those that cause ripple effects across the architecture 32 32
Modifiability Tactics Reduce the number of modules affected by a change localize modifications Limited modifications of these modules prevent ripple effects Control deployment time and cost defer binding time 33 33
Modifiability Tactics 34 34
Performance Many examples of poor performance in enterprise applications Performance requirements: Multiple metrics: Throughput, response time, deadlines Average (sustained) vs. peak. Guarantees? Often specified as median and 99%tile. 35 35
Performance Tactics 36 36
Testability Estimate: 40% of development cost goes to testing Testability: assuming that the software has at least one fault, the probability that this will be detected in the next testing round Need a system that is controllable and observable Testing harness: control internal state of components,, pass inputs to the system, observe output 37 37
Testability Tactics 38 38