Design Proposal
From ZenWiki
Contents |
Point of Contact
- The point of contact during Spring 2007 semester is Lung-San (Allen) Hsu.
- The point of contact for this document during the Fall 2006 semester is Sajjad Mustehsan. The original version of this document can be found here.
Introduction
The Design Proposal outlines the design approached used by Team Zen. The focus of this proposal is to ensure that the architecture satisfies the main architectural drivers.
Approaches
The main approaches we are going to apply are Quality Attributes Workshop (QAW), Attribute-Driven Design Method (ADD) and Architecture Trade-off Analysis Method (ATAM). Additionally, we tailor the experiment in ACDM as a vehicle to conduct ADD and mini-ATAM iteratively.
QAW
Since the Zen Development Method takes an architecture-centric approach towards design, it is proposed that the actual development of the architecture will be based on the project's quality attributes. Quality attributes are scenario based, system specific characteristics that reflect how the customer expects the subject system to behave on upon deployment. Each of these characteristics is given a priority value on a three-point scale and all this information is then used to refine the system's architecture so that the final system shall reflect these quality attributes (QA).
To collect quality attributes, the usual technique used is called the Quality Attributes Workshop (QAW). This is a multi-hour client-development team meeting in which quality attributes are defined and recorded based on client input and joint client-developer evaluation of the subject system's runtime scenarios. Once the quality attributes are identified and given priority values, they are recorded in a quality attributes document, which is often an extension to the requirements specification document.
In light of the above stated importance of using quality attributes to base and/or refine the architecture, the Zen team hereby proposes the use of this technique.
ADD
We use tailored experiment as a vehicle to conduct ADD. Each experiment is designed to focus on a particular element of the architecture.
The overall method is based on the following steps (as listed in the ADD document by the SEI cited below):
- Choose the element to decompose.
- Refine the element according to these steps:
- Choose the architectural drivers.
- Choose an architectural pattern that satisfies the architectural drivers.
- Instantiate elements and allocate functionality from the use cases using multiple views.
- Define interfaces of the child elements.
- Verify and refine use cases and quality scenarios and make them constraints for the child elements.
- Repeat these steps for the next element.
ATAM
We incorporate mini-ATAM in each experiment, so ADD and mini-ATAM are conducted concurrently. The mini-ATAM focus on local concerns, i.e., the trade-off analysis may be limited to the areas specified in each experiment. We conduct a larger scale ATAM in the end of each iteration to evaluate the consolidated architecture with the help from mentors and architecture experts outside our project.
Artifacts
QAW
Upon completion of the Quality Attributes Workshop, when the quality attributes have been identified and given priority values, they are recorded in a quality attributes document. In this document, each quality attribute is given a unique identifier so that it can be referenced-to in other documents. The document within which the quality attributes are recorded is often a standalone or an extension to the requirements specification document. This document is the major artifact that is produced by this step.
ADD
- The result of ADD is documented in the design template for each experiment.
- Chief Architect is responsible for consolidating the design from each experiment. The ultimate goal of ADD is to create the Architecture document for the project.
ATAM
- The trade-off analysis is documented in the design template for each experiment.
- The Architecture Trade-off Analysis section in the architecture document will record the consolidated trade-off analysis for the whole architecture.
Analysis
- Quality attribute scenarios are used to drive the design of the architecture. We reflect on whether the scenarios are clearly defined without ambiguity.
- We reflect on the effectiveness of embedding ADD and mini-ATAM into experiments.
References
- Len Bass, Mark Klein, Felix Bachmann, "Quality Attribute Design Primitives and the Attribute Driven Design Method." 4th International Workshop on Product Family Engineering. Bilbao, Spain, 3-5 October 2001.
- "Attribute-Driven Design Method". Software Engineering Institute, Carnegie Mellon University. November 27, 2006 <http://www.sei.cmu.edu/architecture/add_method.html>.
- “Software Architecture: Principles and Practices Course” by Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA
- "The Architecture Tradeoff Analysis Method (ATAM)". Software Engineering Institute, Carnegie Mellon University. November 30, 2006 <http://www.sei.cmu.edu/architecture/ata_method.html>.
Reflection
- Reflection is conducted at the end of every iteration. The result is documented separately in the Team Reflection.
- Comprehensive Reflection activities will take place in the Fall 2007 semester.
