In order to have a software architecture design method that achieves quality attribute requirements several aspects of the method must be in place. First there must be some way to specify quality attribute requirements so that it can be determined whether the designed architecture can achieve them. Secondly, there must be some way for modularising the knowledge associated with quality attributes so that the design method does not need to know how to reason about all of the multiplicity of quality attributes that exist. Finally, there must be some way for managing the interactions among the quality attributes so that either the requirements can be satisfied or the ones that cannot be satisfied are identified. The authors describe a structure called a 'reasoning framework' as a modularisation of quality attribute knowledge. The requirements that the architecture must satisfy are specified as concrete quality attribute scenarios. Each reasoning framework provides mechanisms that will transform the architecture with respect to a given quality attribute theory. Within a reasoning framework, the authors distinguish between an architectural model and a quality attribute model and characterise the actions that a reasoning framework undertakes as basic architectural transformations. Finally, the process of identifying interactions among reasoning frameworks is begun so that conflicting requirements can be managed. The use of reasoning frameworks is situated inside an existing architectural design method so that a useful method exists while the open issues of designing to achieve quality attribute requirements are resolved.
Summary (Fritz Solms)
Introduce ADD (Attribute Driven Design).
State that any SADM must (i) specify quality requirements,
(ii) modularize knowledge about quality requirements,
(iii) understand & control interactions between quality requirements.
Use quality attribute based reasoning framework as architecture probes: stimulus
on subject in state & environment and measure response.
Requires predictive model for quality attributes (acknowledge, only available for some).
Provide formal model for latency.
Use strategy/tactic impact matrix to see how introducing one architectural decision
impacts on others.
Point out functional design also required for quality attribute realization.
Focus only on quality requirements - no arch responsibilities and concepts within
which functionality is to be specified.
Architecutre evilution:
- Inputs: architecture requirements, architecture description, architecture probe
- Perform measurement.
- Update tactics to evolve architecture to new architecture.
Introduce modifiability measure as amount of work developers has to do to add
functionality (no of compontns, no of lines of code excl functionality, ...).
Highlight that one cannot focus only on software architecture. Need to also include
hardware architecture (no of processors, their speed, memory, networking, ...)
To hint on interplay between architecture and functional design (discuss logic for
authentication and authorization).
%0 Journal Article
%1 bachmann_designing_2005
%A Bachmann, Felix
%A Bass, Len
%A Klein, M.
%A Shelton, C.
%D 2005
%J IEE Proceedings - Software
%K , Reasoning, Software, architectural, architecture; attribute, design, formal, framework, interaction; knowledge; method; quality, quality; requirements; specification
%N 4
%P 153--165
%R 10.1049/ip-sen:20045037
%T Designing Software Architectures to Achieve Quality Attribute Requirements
%V 152
%X In order to have a software architecture design method that achieves quality attribute requirements several aspects of the method must be in place. First there must be some way to specify quality attribute requirements so that it can be determined whether the designed architecture can achieve them. Secondly, there must be some way for modularising the knowledge associated with quality attributes so that the design method does not need to know how to reason about all of the multiplicity of quality attributes that exist. Finally, there must be some way for managing the interactions among the quality attributes so that either the requirements can be satisfied or the ones that cannot be satisfied are identified. The authors describe a structure called a 'reasoning framework' as a modularisation of quality attribute knowledge. The requirements that the architecture must satisfy are specified as concrete quality attribute scenarios. Each reasoning framework provides mechanisms that will transform the architecture with respect to a given quality attribute theory. Within a reasoning framework, the authors distinguish between an architectural model and a quality attribute model and characterise the actions that a reasoning framework undertakes as basic architectural transformations. Finally, the process of identifying interactions among reasoning frameworks is begun so that conflicting requirements can be managed. The use of reasoning frameworks is situated inside an existing architectural design method so that a useful method exists while the open issues of designing to achieve quality attribute requirements are resolved.
@article{bachmann_designing_2005,
abstract = {In order to have a software architecture design method that achieves quality attribute requirements several aspects of the method must be in place. First there must be some way to specify quality attribute requirements so that it can be determined whether the designed architecture can achieve them. Secondly, there must be some way for modularising the knowledge associated with quality attributes so that the design method does not need to know how to reason about all of the multiplicity of quality attributes that exist. Finally, there must be some way for managing the interactions among the quality attributes so that either the requirements can be satisfied or the ones that cannot be satisfied are identified. The authors describe a structure called a 'reasoning framework' as a modularisation of quality attribute knowledge. The requirements that the architecture must satisfy are specified as concrete quality attribute scenarios. Each reasoning framework provides mechanisms that will transform the architecture with respect to a given quality attribute theory. Within a reasoning framework, the authors distinguish between an architectural model and a quality attribute model and characterise the actions that a reasoning framework undertakes as basic architectural transformations. Finally, the process of identifying interactions among reasoning frameworks is begun so that conflicting requirements can be managed. The use of reasoning frameworks is situated inside an existing architectural design method so that a useful method exists while the open issues of designing to achieve quality attribute requirements are resolved.},
added-at = {2013-02-28T11:13:35.000+0100},
author = {Bachmann, Felix and Bass, Len and Klein, M. and Shelton, C.},
biburl = {https://www.bibsonomy.org/bibtex/2e59a9f017337371185d846ae4b73660c/fritzsolms},
doi = {10.1049/ip-sen:20045037},
interhash = {20df725295755553a065fc0de029920e},
intrahash = {e59a9f017337371185d846ae4b73660c},
issn = {1462-5970},
journal = {{IEE} Proceedings - Software},
keywords = {, Reasoning, Software, architectural, architecture; attribute, design, formal, framework, interaction; knowledge; method; quality, quality; requirements; specification},
month = aug,
number = 4,
pages = {153--165},
review = {{Summary} {(Fritz Solms)}
Introduce ADD (Attribute Driven Design).
State that any SADM must (i) specify quality requirements,
(ii) modularize knowledge about quality requirements,
(iii) understand \& control interactions between quality requirements.
Use quality attribute based reasoning framework as architecture probes: stimulus
on subject in state \& environment and measure response.
Requires predictive model for quality attributes (acknowledge, only available for some).
Provide formal model for latency.
Use strategy/tactic impact matrix to see how introducing one architectural decision
impacts on others.
Point out functional design also required for quality attribute realization.
Focus only on quality requirements - no arch responsibilities and concepts within
which functionality is to be specified.
Architecutre evilution:
- Inputs: architecture requirements, architecture description, architecture probe
- Perform measurement.
- Update tactics to evolve architecture to new architecture.
Introduce modifiability measure as amount of work developers has to do to add
functionality (no of compontns, no of lines of code excl functionality, ...).
Highlight that one cannot focus only on software architecture. Need to also include
hardware architecture (no of processors, their speed, memory, networking, ...)
To hint on interplay between architecture and functional design (discuss logic for
authentication and authorization).},
timestamp = {2013-02-28T11:13:40.000+0100},
title = {{Designing Software Architectures to Achieve Quality Attribute Requirements}},
volume = 152,
year = 2005
}