Difference between revisions of "Attribute Driven Design"

From Suhrid.net Wiki
Jump to navigationJump to search
Line 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 architectural drivers
** Choose a pattern/style that satisfies these drivers.
+
## Choose a pattern/style that satisfies these drivers.
** Instantiate modules and allocate functionality to them from the use cases.
+
## 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.
+
## 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.
+
## 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

  1. Choose module to decompose - Usually starts with the whole system.
  2. Refine Module
    1. Choose architectural drivers
    2. Choose a pattern/style that satisfies these drivers.
    3. Instantiate modules and allocate functionality to them from the use cases.
    4. Define interfaces of child modules. Decomposition provides modules and constraints on module interactions - document this info in the interface document for each module.
    5. Verify and refine use cases and quality scenarios and make them constraints for child modules.
  3. Repeat steps for every module that needs decomposition.