Difference between revisions of "Attribute Driven Design"

From Suhrid.net Wiki
Jump to navigationJump to search
 
(2 intermediate revisions by the same user not shown)
Line 7: Line 7:
 
* Output of ADD is first levels of module decomposition.
 
* Output of ADD is first levels of module decomposition.
 
* System is described as a set of containers for functionality and interactions between them.
 
* System is described as a set of containers for functionality and interactions between them.
 +
 +
[[Category:SYAR]]
  
 
= Input to ADD =
 
= Input to ADD =
Line 15: Line 17:
  
 
= ADD Steps =
 
= 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.

Latest revision as of 02:42, 17 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.