Attribute Driven Design - Revision history

Suhridk: /* Intro */

2012-04-17T10:42:22Z

Intro

Suhridk: /* ADD Steps */

2012-04-07T10:11:20Z

ADD Steps

Suhridk: /* ADD Steps */

2012-04-07T10:10:24Z

ADD Steps

Suhridk: /* ADD Steps */

2012-04-07T09:57:28Z

ADD Steps

Suhridk: /* Intro */

2012-04-07T09:57:04Z

Intro

Suhridk: /* Intro */

2012-04-07T09:44:03Z

Intro

Suhridk: Created page with "= 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 architectur..."

2012-04-07T09:38:17Z

Created page with "= 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 architectur..."

New page

= 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.

@@ Line 7: / Line 7: @@
 * 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 =

@@ Line 18: / Line 18: @@
 # Choose module to decompose - Usually starts with the whole system.
 # 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.

← Older revision		Revision as of 10:10, 7 April 2012
Line 15:		Line 15:

	= 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.

← Older revision		Revision as of 09:57, 7 April 2012
Line 14:		Line 14:
	* Design constraints.		* Design constraints.

−	== ADD Steps ==	+	= ADD Steps =

← Older revision		Revision as of 09:57, 7 April 2012
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.
		+
		+	= Input to ADD =
		+
		+	* Functional requirements - typically expressed as use cases.
		+	* Quality requirements - must be expressed as system specific quality scenarios.
		+	* Design constraints.
		+
		+	== ADD Steps ==

← Older revision		Revision as of 09:44, 7 April 2012
Line 3:		Line 3:
	* 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 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.		* 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.