Difference between revisions of "Attribute Driven Design"
From Suhrid.net Wiki
Jump to navigationJump to searchLine 18: | Line 18: | ||
# Choose module to decompose - Usually starts with the whole system. | # Choose module to decompose - Usually starts with the whole system. | ||
# Refine Module | # Refine Module | ||
− | + | ## Choose architectural drivers | |
− | + | ## Choose a pattern/style that satisfies these drivers. | |
− | + | ## Instantiate modules and allocate functionality to them from the use cases. | |
− | + | ## Define interfaces of child modules. Decomposition provides modules and constraints on module interactions - document this info in the interface document for each module. | |
− | + | ## Verify and refine use cases and quality scenarios and make them constraints for child modules. | |
# Repeat steps for every module that needs decomposition. | # Repeat steps for every module that needs decomposition. |
Revision as of 02:11, 7 April 2012
Intro
- ADD takes as input a set of QA scenarios and uses knowledge about relation between quality attribute achievement and architecture in order to design the architecture.
- ADD is an approach to defining a software architecture that bases the decomposition process on the quality attributes that the software has to fulfill.
- Recursive decomposition process where at each stage, tactics and architectural patterns are chosen.
- ADD is started after requirements analysis - where the QA drivers are thought to be well understood.
- Output of ADD is first levels of module decomposition.
- System is described as a set of containers for functionality and interactions between them.
Input to ADD
- Functional requirements - typically expressed as use cases.
- Quality requirements - must be expressed as system specific quality scenarios.
- Design constraints.
ADD Steps
- Choose module to decompose - Usually starts with the whole system.
- Refine Module
- Choose architectural drivers
- Choose a pattern/style that satisfies these drivers.
- Instantiate modules and allocate functionality to them from the use cases.
- Define interfaces of child modules. Decomposition provides modules and constraints on module interactions - document this info in the interface document for each module.
- Verify and refine use cases and quality scenarios and make them constraints for child modules.
- Repeat steps for every module that needs decomposition.