quality attribute design primitives and the attribute driven design method

20
Quality Attribute Design Primitives and the Attribute Driven Design Method Len Bass, Mark Klein, and Felix Bachmann Software Engineering Institute Tzu-Chin Chien 1

Upload: wenda

Post on 23-Feb-2016

92 views

Category:

Documents


0 download

DESCRIPTION

Quality Attribute Design Primitives and the Attribute Driven Design Method . Len Bass, Mark Klein, and Felix Bachmann Software Engineering Institute Tzu-Chin Chien. Introduction. - PowerPoint PPT Presentation

TRANSCRIPT

1

Quality Attribute Design Primitives and the Attribute Driven Design Method

Len Bass, Mark Klein, and Felix BachmannSoftware Engineering Institute

Tzu-Chin Chien

2

Introduction

• This paper discuss the understanding of quality attributes and their application to design of a software architecture

Quality attributes

Functional requirements

Software Architecture

Quality attribute : performance, usability, security, reliability and modifiability

3

Introduction

Software Architecture

Design Phase

Requirement Engineering

• This means that the design decisions embodied by a software architecture are strongly influenced by the need to achieve quality attribute goals.

• We have embarked on an effort to identify and codify architectural patterns that are primitive with respect to the achievement of quality attributes.

• We call this set of architectural patterns attribute primitives.

4

Introduction

The questions are

1. How to characterize quality attribute and capture architecture pattern

2. How the pattern achieves a quality attribute goal and What impact the pattern

3. Design decisions embodied by a software architecture

5

Related work

• Softgoal [Chung L. – Nonfunctional Requirements in Software Engineering]

1. A softgoal is a goal with no clear-cut definition and/or criteria as to whether it is satisfied or not. (availability vs. security)

2. Quality attribute goals as softgoals and develop a process that involves viewing a design as a point on a quality attribute space are characterized.

3. Each design decision is made on the basis of how it might move the design in the quality attribute space. Modifiability

Performance

• Design & Use of Software Architecture [Bosch]

1. thinks Functional requirements more important than quality attribute

2. Believes perform functional requirements that quality attributes can be achieved

6

Short summary

Authors said,

1. We do not believe that quality attribute goals are softgoals. They can be precisely specified and criteria developed to determine whether they have been satisfied.

2. We believe that the “shape” of an architecture is determined by its quality requirements and these are the requirements that determine the initial iteration of a design.

7

ADD in Life cycle

ADD takes requirements, quality as well as functional, as input. Therefore, ADD’s place in the life cycle is after the requirement analysis phase.

8

Quality Attributes & Generic scenarios

• Attribute communities have a natural tendency to expand, because many of the attributes are intertwined.

• We are not trying to define an attribute by deciding what is within its purview.

• General scenario is introduced by which the yardsticks can be measured or observed.

9

Generic scenarios

• Each general scenario consists of

– the stimuli that requires the architecture to respond,– the source of the stimuli,– the context within which the stimuli occurs,– the type of system elements involved in the response,– possible responses, and– the measures used to characterize the architecture’s response

10

Generic scenarios (cont.)

• For example, a performance general scenario is: “External events arrive at a system periodically (stimuli and their source) during normal operation (the context).

• The system (the system element) must respond to the message within a specified time interval (response and response measure).”

11

Conceptual vs. Concrete architecture

Concrete architecture

Conceptual architecture

The conceptual architecture :component A exchanges information X with component B

The concrete architecture:component B invokes method E of component A in order to receive an object Y of typeX.

12

Step of ADDArchitectural

drivers

Attribute primitives

Instantiate

Multiple Views

Verify

Decompose

Design element

Refine

Finish

Next part

13

Design element

• the portion of the system being decomposed or the elements of the decomposition

Decompose

Design element

Refine

Finish

Next part

Conceptual subsystem or component

• Recursive• Factors

1. The personnel on the team2. The incorporation of new

technology3. The knowledge of the domain

14

Architectural drivers

• Some requirements are more influential than others on the design of the architecture and the decomposition of each design element.

• Functional• Quality• Business – e.g. build a product line

Architectural drivers

Attribute primitives

Instantiate

Multiple Views

Verify

Refine

15

Attribute primitives

• The goal of this step is to establish an architectural style that satisfies the quality architectural drivers by composing selected attribute primitives.

Quality Attribute Design Primitives : http://www.sei.cmu.edu/reports/00tn017.pdf

16

Instantiation of an attribute primitive

Producer Consumer

Data Router

Sensor Guidance

DiagnosisData Router

17

Multiple views

Some criteria that can be used to group functionality are:

1. Functional coherence2. Similar patterns of data or

computation behavior3. Similar levels of abstraction4. Locality of responsibility

Architectural drivers

Attribute primitives

Instantiate

Multiple Views

Verify

Refine

The functional drivers are derived from the abstract functional requirements (e.g. features) or concrete functional requirements (e.g. use cases, list of responsibilities, etc.).

18

Multiple Views

19

Verify

• The first step is assigning the functional requirements of the parent element to its children by defining responsibilities of the children elements.

• Assigning responsibilities to the children in a decomposition also leads to discovery of necessary information exchange.

• With the usage of attribute primitives came specific patterns on interactions between the element types of the primitive.

20

Conclusion

• Our basic premise is that architectural design is driven by quality requirements.

• Quality attributes are hard to define because of – ambiguous definitions: The lack of a precise definition for many quality

attributes inhibits the exploration process.– Overlapping definitions : Attributes are not discrete or isolated– Granularity : Attribute analysis does not lend itself to standardization– Attribute specificity : It is difficult to understand how the various

attribute-specific analyses interact

• My idea is how to use ADD method to evaluate a legacy system architecture.