D2 1 2 2 Appendix B v1 0 Public Version

Evolution Management and Process for

Real-Time Embedded Software Systems

Pattern-Based Architecture Analysis

and Design of Embedded Software

Product Lines

Deliverable D.2.1-D2.2 Appendix B

Written by Ronny Kolb and Joachim Bayer, FH IESE

Edited by Hans-Gerhard Groß, FH IESE

& Stefan Van Baelen, K.U.Leuven

15 December 2003

Version 1.0

Status final

Public Version

Pattern-Based Architecture Analysis and Design of Embedded
Software Product Lines

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

This document is part of the work of the EUREKA

! 2023 – ITEA 00103 project EMPRESS.

Authors/Partners:

Partner

Author

Fraunhofer IESE

Hans-Gerhard Groß grossh@iese.fhg.de

Fraunhofer IESE

Ronny Kolb

kolb@iese.fhg.de

Fraunhofer IESE

Joachim Bayer

bayer@iese.fhg.de

Document History:

Date

Version Editor

Description

15 Dec 03

1.0

Stefan Van Baelen

Public version based on internal version 1.1

Filename: D2.1_D2.2_v1.0_Appendix_B_Public_Version.doc

Pattern-Based Architecture Analysis and Design of Embedded
Software Product Lines

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

Table of Contents

Introduction........................................................................................................................ 5

1.1

Product Line Architectures............................................................................................ 6

1.2

Quality for Product Line Architectures .......................................................................... 8

1.3

Quality Models .............................................................................................................. 9

The Quality Model.............................................................................................................. 9

2.1

Existing Work on Quality Models ................................................................................ 10

2.2

The Meta-Model .......................................................................................................... 13

2.3

Variability in Quality Models ........................................................................................ 15

Quality Attributes and Patterns for Embedded Product Lines................................... 16

3.1.1

Homogenous Redundancy Pattern ...................................................................... 23

3.1.2

Diverse Redundancy Pattern ............................................................................... 24

3.1.3

Monitor-Actuator Pattern ...................................................................................... 24

3.1.4

Sanity-Check Pattern ........................................................................................... 25

3.1.5

Watchdog Pattern ................................................................................................ 26

3.1.6

Safety Executive Pattern ...................................................................................... 27

Design of Embedded Product Line Architectures ....................................................... 28

4.1

Overview ..................................................................................................................... 28

4.2

Preparation.................................................................................................................. 29

4.2.1

Business Goal Elicitation...................................................................................... 29

4.2.2

Functionality Elicitation......................................................................................... 30

4.2.3

Quality Goal Elicitation ......................................................................................... 30

4.2.4

View Elicitation and Definition .............................................................................. 31

4.3

Design and Analysis.................................................................................................... 32

4.3.1

Select Scenarios and Plan Next Iteration............................................................. 33

4.3.2

Define Evaluation Criteria .................................................................................... 34

4.3.3

Choose Means and Patterns................................................................................ 35

4.3.4

Instantiate Patterns .............................................................................................. 35

4.3.5

Document Architecture using Views .................................................................... 35

4.3.6

Evaluate Architecture ........................................................................................... 35

Pattern-Based Architecture Analysis and Design of Embedded
Software Product Lines

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

4.3.7

Analyse Problem .................................................................................................. 35

4.4

Learning from Experience........................................................................................... 36

Summary .......................................................................................................................... 37

References ....................................................................................................................... 37

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

1 Mapping to the Empress Process

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

1 Mapping to the Empress Process

This section discusses the mapping of the method for the design and analysis of product line
architectures presented in this document to the Empress process. In particular, it describes to
which discipline and sub-discipline the presented method relates and what the inputs to and
outputs of the method are. In addition, we discuss relations of the method to other work done
in the Empress project.

As shown in Figure 1, the method presented in this document is related to the “Analysis and
Design” discipline of the Empress process and mainly addresses the “Inception” and
“Elaboration” phases. With respect to the sub-disciplines of “Analysis and Design”, our
pattern-based architecture analysis and design method addresses the sub-discipline “Define a
Candidate Architecture” with its activities “Architecture Analysis”, “Architectural Guidelines”,
and “Influencing software architecture with NFRs” as well as the sub-discipline “Refine the
Architecture”. Regarding the “Refine the Architecture” sub-discipline, our method addresses
the activity “Analyse Behaviour”. The method takes as input functional and quality
requirements, which have been elicited and specified as part of the “Requirements” discipline.
The output of the method is a product line architecture that satisfies the stated requirements
and that is documented using a number of architectural views which have been selected and
defined as part of the architecture analysis and design step. The architecture is the input for
detailed design and later implementation.

The method described in this chapter has relations to the non-functional requirements
framework developed as part of Task 3.1 and described in deliverable D.3.1.1. Also, relations
to the topic “Traceability between NFRs, FRs, and architectural decisions” elaborated in Task
3.2 and documented in deliverable D3.2.1 exist.

Disciplines

Business Modeling

Requirements

Analysis and Design

Implementation

Verification & Validation

Deployment

Configuration & Change

Management

Project Management

Environment

Phases

Inception

Elaboration

Construction

Transition

Run-Time

Iterations

Initial

Elab

Const

Tran

Elab

Tran

Figure 1. The Empress Process

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

2 Introduction

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

2 Introduction

The development and evolution of embedded systems is more complex and expensive than of
desktop applications. Embedded systems contain computers as part of larger systems and
interact with electrical devices and (indirectly) with mechanical ones. Found in a broad range
of applications, such as avionics, automotive control, or medical electronic devices,
embedded systems are typically subject to limited memory and processing power and many
embedded systems are also real-time systems that have strict performance constraints. Even
for non-real time embedded systems, developers have to take into account the timeliness,
robustness, and safety of the systems. The fact that embedded systems are embedded, that
is they cannot easily be taken out of their environment to be maintained or evolved, poses
stringent reliability requirements.

The points just mentioned have the consequence that the evolution of embedded systems is
problematic. Product lines provide a means to address these problems at design-time of an
embedded system.

Product lines are a way to support the evolution of software systems. A product line
encompasses a number of related software products that are planned and developed together
in a systematic way. The result is a reuse infrastructure that supports the location, the
evaluation, and the adaptation of reusable assets, as well as a more accurate planning of
development projects. The coverage of multiple software products increases the chances that
the evolution of a specific product line member is already covered by the product line. If this is
not the case, however, the evolution is facilitated by the flexible nature of the product line and
of the assets it consists of. Additionally, product lines also support the decision whether an
evolution step of a product line member is to be done at all or whether it would extend the
product line too far. This is possible due to the scoping activities that determine the
boundaries of the product line as well as the explicit handling of variations throughout the
development of the product line.

2.1 Product Line Architectures

Figure 2 shows a simplified software development process. As the figure shows, the software
architecture is the first artefact that describes a system from a solution-oriented point of view.
It describes the structure of the solution as well as the components (along with their externally
visible properties and the relationships among them) that the software system consists of.
Detailed requirements on the components can then be further elaborated, leading to a
component design and, finally, to an implementation.

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

2 Introduction

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

Architectures provide critical abstractions that enable reasoning about a software system as

well as a description of the structure and behaviour of the system. There are several reasons
why an architecture-based development and careful evaluations of software architectures are
critical:

First, architectures facilitate communication about a system in an early phase of system
development. There are several stakeholders concerned with different aspects of a system.
Examples are customers, users, project managers, coders, or testers. Architectures provide a
means to express, negotiate, and resolve competing concerns at an early stage of the
development of a software system.

Second, important design decisions are made at that phase in the software life cycle. Several
decisions have to be made in the design phase of the software development life cycle. The
earlier design decisions are made, the harder they are to change in later phases and the more
far-reaching effects they have. The decisions made in the architecture phase have to be made
carefully, being aware of their impact.

Third, architectures are transferable abstractions of a system that can be reused. Examples
are entire families of systems sharing a common architecture (i.e., product lines) or a
component-based approach to development, where systems can be built by plugging
externally developed components to a pre-defined architecture that complies with a given
standard.

'RPDLQ(QJLQHHULQJ

'RPDLQ

DVPDOOLQYLVLEOHOLQH

$QDO\VLV

'RPDLQ

DVPDOOLQYLVLEOHOLQH

'HVLJQ

'RPDLQ

DVPDOOLQYLVLEOHOLQH

,PSOHPHQWDWLRQ

'RPDLQ

DVPDOOLQYLVLEOHOLQH

$QDO\VLV

'RPDLQ

DVPDOOLQYLVLEOHOLQH

$QDO\VLV

'RPDLQ

DVPDOOLQYLVLEOHOLQH

'HVLJQ

'RPDLQ

DVPDOOLQYLVLEOHOLQH

'HVLJQ

'RPDLQ

DVPDOOLQYLVLEOHOLQH

,PSOHPHQWDWLRQ

'RPDLQ

DVPDOOLQYLVLEOHOLQH

,PSOHPHQWDWLRQ

$SSOLFDWLRQ(QJLQHHULQJ

$SSOLFDWLRQ

DVPDOOLQYLVLEOHOLQH

$QDO\VLV

$SSOLFDWLRQ

DVPDOOLQYLVLEOHOLQH

'HVLJQ

$SSOLFDWLRQ

DVPDOOLQYLVLEOHOLQH

,PSOHPHQWDWLRQ

$SSOLFDWLRQ

DVPDOOLQYLVLEOHOLQH

$QDO\VLV

$SSOLFDWLRQ

DVPDOOLQYLVLEOHOLQH

$QDO\VLV

$SSOLFDWLRQ

DVPDOOLQYLVLEOHOLQH

'HVLJQ

$SSOLFDWLRQ

DVPDOOLQYLVLEOHOLQH

'HVLJQ

$SSOLFDWLRQ

DVPDOOLQYLVLEOHOLQH

,PSOHPHQWDWLRQ

$SSOLFDWLRQ

DVPDOOLQYLVLEOHOLQH

,PSOHPHQWDWLRQ

3URGXFW

Figure 3. Product Line Engineering

Figure 3 shows the generic product-line engineering life cycle. This life cycle is split in the two
phases domain engineering and application engineering. Domain engineering itself is

Problem

Description

System

Requirements

Architecture

Component

Requirements

Component

Design

Source Code

Problem

So
lut
ion

Problem

Description

System

Requirements

Architecture

Component

Requirements

Component

Design

Source Code

Problem

So
lut
ion

Figure 2. Simplified Software Development Process

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

2 Introduction

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

decomposed into domain analysis (i.e., the scoping of the domain by determining the products
covered by the product line and the creation of reusable requirements that specify the product
line), domain design (i.e., the creation of a common architecture for all systems in the product
line), and domain implementation (i.e., the implementation of reusable assets used to build
the systems in the product line).

The result of domain engineering is a product line infrastructure that contains assets that are
used during application engineering. Application engineering is also split in three phases
(application analysis, application design, and application engineering), in which the assets that
have been built during domain engineering are used to build actual systems covered by the
product line.

Product line architectures (or: reference architectures) are the central asset of the reuse
infrastructure; they capture the software architectures of all product line members. A product
line architecture consists of two parts: first, an architecture built for (re-) use during the
application engineering process, and second, a decision model that represents the knowledge
needed to build specific architectures for product line members.

In a product line architecture description, there are two types of information captured:
information that is valid for all systems in the family (i.e., commonalities) and information that
varies from system to system (i.e., variabilities). Variation points in the architecture description
denote variability by showing the different possible alternatives.

The variation points in a product line architecture must be resolved when the architecture of a
particular product line member is specified. Resolving variation points means that parts of the
architecture description are specialized, included, or excluded.

There are typically a large number of variation points in a product line architecture.
Consequently, it is, even for experts, hard to control the rationales for each variation point, as
well as the complex interrelationships and dependencies among them. To support the
intellectual control, a decision model, which captures this kind of domain knowledge, is built
on top of the variation points.

A decision model consists of a decision hierarchy, which is grounded on simple decisions that
capture the rationale and the possible choices for a single point of variation. Dependencies
among decisions are explicitly captured by constraints. Usually, additional decisions are
introduced. These decisions are not directly related to a point of variation of an asset but they
represent domain variability at a higher level of abstraction. This higher abstraction level is
related to sets of interdependent variation points.

A product line member architecture is an architecture that is developed with the reuse of
product line assets for a particular customer. It is one of the outputs of application
engineering, the process of developing specific product line members by instantiating the
decision model.

2.2 Quality for Product Line Architectures

Quality plays an important role in several activities performed to create, use, and evolve
product line architectures. In all these activities, quality models can provide support to
explicitly capture quality requirements. The activities in which quality is important are
presented in more detail in the following.

As mentioned above one of our goals is supporting the development of high quality reference
architectures. As a first step towards this goal, the impact that certain design decisions have

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

3 The Quality Model

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

on a product line architecture is elicited. This is done by collecting patterns that are used in
architectures and investigating their impact on the satisfaction of quality requirements. The
quality model that is presented later provides a means to establish the relation between a
pattern and the quality attribute it supports. A quality attribute is a general characteristic of a
system or a product line. A quality requirement is a concrete requirement derived from a
quality attribute given in terms of stimulus/response pairs.

2.3 Quality

Models

Having established a collection of patterns together with their impact on the achievement of
quality requirements can be a starting point for designing high quality product line
architectures. At any point in the design, patterns can be selected that help fulfil the specific
requirements on the reference architecture. To support this, styles and patterns that are
beneficial for product line architectures are identified and classified to be reused for further
projects. With the help of quality models, their benefits can be quantified and compared.

Additionally, quality models can be used as basis for developing specific customized
architectural views. These quality-related architectural views highlight the respective quality
attribute in the description of the reference architecture. The quality model is also used to
document the quality requirements on the product line architecture and the impact the quality
attributes have on each other (i.e., the pair wise positive/negative influence of quality
attributes).

Quality models can also be used in the documentation of product line members. The quality
models presented in this document are generic in the sense that they cover the quality
attributes and requirements of all members of a product line. As described above, the
architecture of a specific product line member can be derived from the reference architecture
by instantiating it. In the same way, the quality model can be instantiated. The result is a
quality model that documents the quality requirements for one specific product line member.

To exploit quality requirements to the fullest extent possible, they must be made explicit.
Quality models are a means to do that. They enable a fine-grained definition of quality
attributes (and of quality requirements) and capture the relationships among different quality
attributes. The quality model definition as proposed in this work provides a means to define
and document quality attributes in the context of product lines. As described above, the final
goal of IESE’s activities in task 2.1 is to provide reference architecture designers with
methods and technologies that help them create high quality product line architectures. To
achieve that goal, first, the impact of design decisions on the quality of a product line
architecture is investigated. This is done by integrating the knowledge gained by investigating
the impact of architectural parameters and the adapted evaluation approaches into existing
reference architecture design approaches. Architectural styles and patterns are collected and
their impact on the satisfaction of certain quality requirements is elicited. A second goal is to
extend existing architecture evaluation approaches for single system architectures to also
support reference architectures.

3 The Quality Model

In the previous section, several usage scenarios for quality models were presented. In this
section, the requirements on quality models are derived from these usage scenarios and from

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

3 The Quality Model

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

existing work on quality models. We concentrated on established standards and approaches
in the context of evaluating software architectures.

3.1 Existing Work on Quality Models

There are established standards for defining quality of software and quality models (e.g., [11],
[13]), as well as approaches for evaluating the quality of software architectures that are widely
used. Examples are the different approaches developed at the SEI, the Software Architecture
Analysis Method (SAAM) [14] [15] and the Architecture Trade-Off Analysis Method (ATAM)
[16], as well as the work by Chung et al. on goal-oriented architecture design [6]. These are
taken into account for eliciting the requirements on the quality model. After an introduction into
the standards and approaches that have been considered when defining the quality model,
the necessary elements of the quality model, as well as the necessary relationships are
presented.

McCall’ s quality model is the first attempt to categorize and document quality on software
[18]. It is given here, because it is the basis for the standards presented later. McCall,
Richards, and Walters proposed a useful categorization of factors that affect software quality.

These factors focus on three aspects of a product:

•

Operational characteristics (Use)

•

Ability to undergo change (Evolution)

•

Adaptability to new environments (Maintenance)

In their model (shown in Figure 4), a quality factor represents a behavioural characteristic of
the system. A quality criterion is an attribute of a quality factor that is related to software
production and design. A quality metric is a measure that captures some aspect of a quality
criterion.

Chung et al. proposed a quality model that breaks down a quality requirement into goals to be
achieved to satisfy the quality requirement [6]. The goals can potentially be conflicting or
synergistic and are used to guide and rationalize the various design decisions during
architecture development. Design decisions are related to goals in a quality model along with

0DLQWHQDQFH

(YROXWLRQ

8VH

3RUWDELOLW\
5HXVDELOLW\
,QWHURSHUDELOLW\

0DLQWDLQDELOLW\
)OH[LELOLW\
7HVWDELOLW\

&RUUHFWQHVV
5HOLDELOLW\
8VDELOLW\
,QWHJULW\
(IILFLHQF\

Figure 4. McCall’s Quality Model

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

3 The Quality Model

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

information on the influence of the design decision on the achievement of the respective goal
((very) positive or negative).

The IEEE 1061 standard provides a methodology for using quality requirements throughout all
phases of any software life cycle [11]. It defines the relevant terms and sets up a process for
developing and using quality requirements. It also defines a framework for classifying software
quality.

Figure 5 contains the software quality metrics framework being part of the IEEE 1061
standard. A quality of a system is broken down into quality factors that represent management
and user-oriented views. If necessary, quality subfactors are then assigned to each quality
factor. One or more direct metrics are associated with a quality factor. They serve as a
quantitative representation of the quality factor. Quality subfactors represent software-oriented
attributes that indicate quality. Quality subfactors are independent attributes of software and
can be therefore associated with more than one quality factor. Quality subfactors are
decomposed into metrics used to measure system products and processes during the
development life cycle.

The quality model of ISO/IEC 9126 categorizes software quality into six characteristics
(functionality, reliability, usability, efficiency, maintainability, and portability), which are further
subdivided into sub-characteristics [12]. In addition, definitions are given for each quality
characteristic as well as the sub-characteristics influencing the characteristic. The resulting
tree is presented in Figure 6.

Software Quality

Quality Factor

Direct Metric(s)

Quality Subfactor

Metric

Figure 5. IEEE 1061 Software Quality Metrics Framework

Software Quality

Usability

Reliability

Functionality

Efficiency

Maintainability

Portability

Suitability

Accuracy

Interoperability

Security

Compliance

Maturity

Fault Tolerance

Recoverability

Compliance

Understandab.

Learnability

Operability

Attractiveness

Compliance

Time Behavior

Resource

Utilization

Analyzability

Changeability

Stability

Testability

Compliance

Adaptability
Installability

Co-Existence

Replaceability

Compliance

Figure 6. ISO/IEC 9126 Software Quality Characterization

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

3 The Quality Model

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

The figure contains the six characteristics in which software quality attributes are categorized
as well as their respective sub-characteristics.

Being compatible with the IEEE1061quality metrics framework and ISO/IEC 9126 Standard
requires a hierarchical decomposition of software quality attributes into characteristics and
sub-characteristics with associated metrics. To be able to cope with different decompositions
than the one proposed by the standard, we decided to require a free hierarchical
decomposition of quality attributes without different names for different decomposition levels
and without prescribing an actual hierarchy.

In ATAM, a scenario-based method for architecture analysis, quality attributes are
characterized by stimuli, responses, and architectural parameters. Stimuli are events that
cause the architecture under consideration to respond or change. In order to evaluate an
architecture for satisfaction of quality attribute requirements, the requirements have to be
expressed in a concrete measurable or observable way. These measurable or observable
quantities are captured as responses. Architectural parameters (or architectural decisions) are
those aspects of an architecture that have a direct impact on achieving quality attribute
responses.

The example shown in Figure 7 is a (partial) characterization of availability. It is taken from [7].

Stimuli and responses together form scenarios that describe how an architecture should react
on a certain stimulus. That is, they capture quality requirements on the architecture.
Architectural parameters on the other hand capture how the response to a certain stimulus is
achieved. Hence, they capture the mechanisms in the architecture that enable a satisfaction
of the respective quality requirement.

Availability

Architectural

Parameters

Stimuli

Responses

Hardware Fault

Software Fault

Hardware Redundancy

Exact/Analytic

Degree

Failure Rate

Repair Rate

Failure Detection Time

Failure Detection Accuracy

Software Redundancy

...

Voting

Retry

Failover

Watchdog

Mean Time To Failure

Reliability

Levels of Service

...

Figure 7. ATAM Characterization of Availability

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

3 The Quality Model

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

3.2 The

Meta-Model

The quality model is presented here by means of a meta-model. This meta-model contains
the definition of quality attributes and of how they are related to yield a quality model. As
shown in Figure 8, the quality model is closely related to patterns that are mechanisms to
realize quality requirements in product line architectures.

In the preceding paragraphs, several quality models have been presented along with the
impact they had on our quality model. Now, the results of this investigation of existing
standards and approaches are used to derive the necessary elements of our quality model.
The result is shown in Figure 9.

Quality Model

Pattern

<<import>>

Figure 8. Overview Meta-Model

LQIOXHQFH

VXEFKDUDFWHULVWLF

4XDOLW\0RGHO

4XDOLW\$WWULEXWH

LQIOXHQFH

VXEFKDUDFWHULVWLF

4XDOLW\0RGHO

4XDOLW\$WWULEXWH

0HWULF

0HDQV

6WLPXOXV

5HVSRQVH

$EVWUDFW6FHQDULR

Figure 9. Quality Model Meta-model

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

3 The Quality Model

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

The quality of a software artefact, a software process, or a software organization is a result of
an interaction of several quality attributes. The quality is a combination of the degrees to
which the artefact (the process/the organization) satisfies the individual quality attributes [2].
Like in the quality models proposed in the IEEE 1061 standard and the ISO/IEC 9126
Standard, quality is decomposed into a number of quality attributes that can, again, be
decomposed (Software Quality - Quality Factor - Quality Subfactor in the IEEE 1061 standard,
Software Quality - Characteristic - Subcharacteristic in ISO/IEEE 9126).

We decided to allow free (domain- or project-specific) decompositions of quality and to not
restrict the number of allowed decomposition levels. As a result the entities residing in the
different decomposition levels are all called the same (quality attribute). There is a relation of
type “subcharacteristic” that connects the different decomposition levels.

The positive or negative influence between quality attributes is captured by documenting the
pair wise influence relationships between two quality attributes.

A quality attribute is associated with a number of metrics that can be used to measure the
degree to which a product line architecture satisfies a quality requirement. Metrics are
functions that enable to measure the degree to which an architecture possesses a quality
attribute.

A quality requirement is an actual requirement on a product line architecture derived from a
quality attribute. A quality requirement is given by a stimulus/response pair. These
stimulus/response pairs (or scenarios) are abstract in our case. An abstract scenario has a
number of alternative responses from which one is chosen to concretise the scenario.
Abstract scenarios can also be associated with metrics.

Architectural styles and patterns are mechanisms that help architecture designers in creating
reference architectures. They provide solutions for recurring problems in the design of
software (and product line) architectures. The pre-defined solutions have proven to be
beneficial in certain situations; they have usually been applied multiple times. Therefore, their
impact on the quality of the architecture is known.

In our quality model the relation between a quality attribute and a pattern is established via
concrete scenarios. A scenario describes the anticipated behaviour that is assured by a style
or a pattern. As an intermediate step, means are introduced. Means are principles,
techniques, or mechanisms that facilitate the achievement of certain qualities in a product line
architecture. They are abstract patterns that capture a way to achieve a certain quality
requirement, but are not concrete enough to be used in design directly, that is they have to be
instantiated as patterns. The pattern metamodel is shown in Figure 10. We use the term
pattern, because it is well established. However, we do not restrict a pattern to be at an object-
oriented design-level, but we include all kinds of documented mechanisms to solve recurring
problems with a generic solution (e.g., analysis patterns, architectural styles, design patterns,
or idioms).

Patterns are given by a problem addressed, a rationale justifying why the patterns solves the
problem, and a description of the actual solution. The justification given in the rationale should
address known effects on quality attributes imposed on the software system in which the
pattern is applied. Patterns can employ other patterns to provide a solution for a given
problem (i.e., a pattern uses another pattern). Patterns can also be specialized for different
contexts. There are also patterns that conflict with certain other patterns. Finally, related
patterns are captured with a pattern to enable the search for a different solution to a problem
at hand.

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

3 The Quality Model

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

The relation between the system of patterns described here and the quality model are the
scenarios. The abstract scenarios defined in the quality model can have multiple responses
and might contain variability. In order to be addressed by a pattern, the abstract scenario must
be concretised. This is done by resolving the variations using the decision model and by
selecting one of the responses. One or more patterns can then be selected that satisfy the
concrete scenario (or a number of concrete scenarios).

3.3 Variability in Quality Models

In a product line context, a quality model should describe quality attributes and requirements
for the complete product line. That is, the quality model captures the common as well as the
varying quality attributes and requirements of the different product line members. There is
currently no approach that handles variability in quality models.

Because the quality requirements for different product line members can potentially be
different, we use generic quality models. Like other generic software artefacts, generic quality
models describe the quality attributes and quality requirements for all product line members.
Variation points denote points in the generic quality models that differ for different members of
the product line. A decision model contains the information on how the different quality models
for the different product line members differ. It can be used to derive a specific quality model
for one product line member.

The elements of the quality model that can potentially contain variability and, therefore,
variation points are: quality attribute, means, abstract scenarios, stimuli, and responses. The
pattern elements that can contain variability are problem, rationale, and solution. The
introduction of variability handling leads to the meta-model presented in Figure 11.

4XDOLW\0RGHO$EVWUDFW

6FHQDULR

&RQFUHWH6FHQDULR

VDWLVILHV

4XDOLW\0RGHO$EVWUDFW

6FHQDULR

4XDOLW\0RGHO$EVWUDFW

6FHQDULR

&RQFUHWH6FHQDULR

VDWLVILHV

XVHV

VSHFLDOL]HV

5DWLRQDOH

3UREOHP

6ROXWLRQ

FRQIOLFWV

3DWWHUQ

Figure 10. Pattern Metamodel

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

4 Quality Attributes and Patterns for Embedded Product Lines

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

4 Quality Attributes and Patterns for Embedded Product

Lines

In this section, we will model some typical quality attributes for product lines of embedded
systems using the quality metamodel described in the previous section. We also present
some patterns extracted from the literature and relate them to the defined quality models in
order to show which quality attributes they support or hinder.

Typically, embedded real-time systems must operate under more severe constraints than
information systems – including timing – and are subject to stringent computing resource
restrictions such as memory shortage and limited processing power. Furthermore, embedded
systems usually have to follow rigorous constraints for safety as many of them are found in
critical application domains, such as aircraft flight control, nuclear power plants, fire control,
and medical devices, in which human life and commercial assets depend on the correct
functioning of the systems. In contrast to information systems, therefore, embedded real-time
systems have different quality requirements, most of them inherent in the application domain.
According to literature, embedded systems, whether real-time or not, generally possess a
strong focus on the following quality attributes in addition to classical qualities, such as
reusability, portability, or integrability:

•

Safety. Many embedded systems, whether real-time or not, are found in life or mission
critical domains such as avionics, medical equipment, or nuclear power plants and

LQIOXHQFH

VXEFKDUDFWHULVWLF

4XDOLW\0RGHO

4XDOLW\$WWULEXWH

LQIOXHQFH

VXEFKDUDFWHULVWLF

4XDOLW\0RGHO

4XDOLW\$WWULEXWH

0HWULF

RUJDQL]HV

9DULDWLRQ3RLQW

'HFLVLRQ0RGHO

9DULDEOH 0RGHO(OHPHQW

0HDQV

6WLPXOXV

5HVSRQVH

$EVWUDFW6FHQDULR

Figure 11. Quality Model Meta-Model with Variability Handling

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

4 Quality Attributes and Patterns for Embedded Product Lines

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

therefore have very high criticality. For these systems, it is undesirable to fail since a
failure can potentially lead to injury, loss or damage of property, or even loss of life.
Consequently, these systems must not only be reliable, but they must also be safe. If such
a systems fails, it has to do so without causing damage of property, injury, or loss of life.
To summarize, a system is deemed safe if it is impossible, or at least highly unlikely, that
the system ever causes loss of physical property, physical harm, or loss of life. Although
safety is intimately related to reliability, a reliable system is not necessarily safe, but the
probability that an unreliable system is unsafe is more likely. Hence, safety and reliability
go hand in hand in many real-time systems. Also note that safety does not imply
correctness. For example, a system may be incorrect and unreliable, but safe because
failures are not hazardous. On the other hand, a system may be correct and reliable but
unsafe due to errors in the specification.

•

Reliability. As just mentioned, reliability is intimately related to safety and for many
embedded systems it is important to perform reliable for long periods of time. Reliability is
defined as the ability of a system or component to perform its required functions and its
specified level of performance under stated conditions for a specified period of time.
Reliability is similar to availability (i.e., the degree to which a system is operational and
accessible when required for use [10]) and has the following subcharacteristics:

−

Fault Tolerance. The ability of a system or component to continue normal operation
and to maintain a specified level of performance in cases of failures of portions of a
system and unplanned situations such as unexpected inputs, hardware or software
faults, or stressful environmental conditions. Notice that fault tolerance is sometimes
also referred to as robustness.

−

Recoverability. The ability of a system or a component to restore itself to a working
state after an interruption, such as in case of a failure. This includes to recover from
certain classes of errors to a predefined state, to re-establish a specified level of
performance, and to recover data directly affected by the interruption.

−

Predictability. For many embedded systems, predictable behaviour is a key aspect
and especially for mission-critical and life-critical systems, predictability with respect to
schedulability and memory is crucial. Predictability, in general, is the quality of being
predictable and the predictability of a system is the extent to which its response
characteristics to all possible events can be known in advance. The more predictable a
system is, the more reliable it will generally be.

•

Performance. According to [10], performance is the degree to which a system or
component accomplishes its designated functions within given constraints, such as speed,
accuracy, or memory usage. In the ISO/IEC 9126 standard, performance is referred to as
efficiency [13]. Performance has the following two subcharacteristics:

−

Time Behaviour. Embedded systems either control or monitor hardware and physical
processes, or both and must respond to real-world events. Therefore, the systems
must typically react in a timely fashion to external events and have rigorous timing
requirements and constraints, such as deadlines, in which functions must be
performed. Time behaviour of a system is defined as the speed or response and
processing times and throughput rates in performing its function. As many embedded
systems are also real-time systems, time behaviour (or timeliness) is essential to
correctness for these systems. In other words, the correctness of a system not only
depends on the logical correctness of the computations performed, but also upon time

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

4 Quality Attributes and Patterns for Embedded Product Lines

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

factors. That is, it is essential that under all conditions timing constraints, such as
finishing certain tasks within specified time limits, are met.

−

Resource Utilization. As mentioned earlier, embedded systems typically are subject
to stringent computing resource restrictions such as memory shortage or limited
processing power. The amount of resources used and the duration of such use in
performing its function is commonly referred to as resource utilization.

•

Maintainability. Especially for evolving real-time embedded systems, maintainability is an
important quality. Defined as the ease with which an existing system or component can be
corrected, improved, or adapted to new or changing requirements or to a changed
environment, maintainability has the following subcharacteristics:

−

Modifiability. The ability of a system or component to be modified in response to fault
removal and changes in specification and both functional and non-functional
requirements.

−

Extensibility. The ability of a system or component to be extended in response to new
requirements.

−

Adaptability. The ability of a system to be easily adapted to different specified
environments and to new or changed hardware devices such as sensors and
actuators. Adaptability might also include the ability to adapt a system or component to
fulfil requirements for which it was originally not constructed. Note that in the ISO/IEC
9126 standard, adaptability is a subcharacteristic of portability.

To summarize, although embedded systems may vary greatly in the addressed application
domain, performance, reliability, and safety are important quality attributes that generally have
to be addressed. In addition, maintainability, just as for traditional software system, is crucial
for embedded systems. In the following, we therefore present quality models described using
our quality metamodel for the quality attributes performance, maintainability, and reliability.
Notice that these quality models only serve as an example and therefore are not intended to
be complete.

Figure 12 illustrates an exemplary quality model for the quality attribute performance. Actually,
the figure only shows a part of the quality model. In Figure 13, an example for an abstract
scenario and two concrete scenarios is given. To show the relation to the metamodel,
stereotypes are used in both cases. As Figure 12 shows, performance has two
subcharacteristics and influences maintainability, reliability, and security. For example, a
layered architecture is very maintainable but generally influences performances negatively.
Furthermore, performance has six metrics that can be used for measurements. In order to
achieve good performance in an architecture or a system, several means can be applied as
shown in the figure. Notice that performance modelling is actually a means to predict or
analyse the performance that an architecture is expected to have, rather than to design a
system that has good performance.

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

4 Quality Attributes and Patterns for Embedded Product Lines

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

The abstract scenario shown in Figure 13 is associated to the means efficiency. The scenario
is abstract because it connects to one stimulus and two responses. Note that the grey colour
of the response “Throughput” denotes variability (i.e., in this example throughput is not
considered in all product line members). The abstract scenario is concretised by the two
scenarios “Good Object Creation Response Time” and “High Object Creation Throughput”,
where the latter is an optional scenario as it has an optional response.

In Figure 14, a quality model for maintainability is shown. As illustrated in the figure,
maintainability influences performance and reliability. Means for achieving maintainability are
separation, encapsulation, indirection, modularity, abstraction, and location transparency. In
general, stimuli for maintainability are anticipated changes, whether internal or external, to the
system. External changes are driven by external factors such as, for example, a new or
improved standard, a changed resource, or a new or changed COTS component. Internal
changes, on the other, are driven from within the organization developing the system.
Examples for internal changes are a defect fix (i.e., a change fixing a detected defect), a new
or upgraded function, or improved quality of service. For the means encapsulation, stimuli
might be “change occurs inside encapsulated function” or “change crosses encapsulation
boundary”. Note that another categorization of stimuli for maintainability is according to the
type of change. Changes can be adaptive, corrective, or perfective. Adaptive changes are
performed to make the system usable in a changed environment, whereas corrective changes
aim to correct faults in the system and perfective changes are performed to improve the
system in terms of new functionality or additional quality attributes. Responses might be, for
example, difficulty, the number of affected components, and effort (i.e., time and cost required
to make the change).

«Quality Attribute»

Performance

«Quality Attribute»

Maintainability

«Quality Attribute»

Reliability

«Quality Attribute»

Security

«influence»

«Means»

Workload

«Means»

Efficiency

«Means»

Parallelism

«Means»

Sharing

«Means»

Locality

«Means»

Performance Modeling

«Metric»

Throughput

«Metric»

Access Time

«Metric»

Response Time

«Metric»

Utilization

«Metric»

Capacity

«Metric»

Cost

«Quality Attribute»

Time Behavior

«Quality Attribute»

Resource Utilization

«subcharacteristic»

Figure 12. Quality Model for Performance

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

4 Quality Attributes and Patterns for Embedded Product Lines

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

Figure 15 finally gives a quality model for reliability. As the figure shows, reliability has an
influence on maintainability, availability, safety, and performance. The means to achieve
reliability are again split in two groups. Whereas fault avoidance is a principle for improving
reliability by avoiding faults and errors, the others are concrete mechanisms to design reliable
systems. In the following, we will focus on redundancy as a common means to improve the
reliability of a system. Basically, redundancy implies the presence of auxiliary components in a
system to perform the same or similar functions as other elements for the purpose of
preventing or recovering from failures. Just as to any other means, a number of abstract
scenarios can be related to redundancy. For these scenarios, the stimuli are basically faults.
Faults can be either hardware or software failures or events arriving at the system for which it
was not prepared. Such events could be, for example, invalid inputs, unknown messages,
unexpected timing behaviour (e.g., too fast, too late, or too many events), unavailable
resources (e.g., disk space), or values outside bounds. The faults can also be classified as
either being internal or external. Internal faults arise inside a component of the system and
propagate to other components and possibly to the environment. External faults, on the other
hand, arise in the environment and propagate into system components. Stimuli for
redundancy in particular and reliability in general can also be single point failures and
systematic errors. Finally, possible responses in the case of redundancy might be availability,
levels of service, recovery time, and cost.

«Means»

Efficiency

«Abstract Scenario»

Object Creation

should be efficient

Minimize

Overhead

«Response»

Response Time

«Response»

Throughput

«Stimulus»

New Object

instantiated

«Concrete Scenario»

Good Object Creation

Response Time

«Concrete Scenario»

Good Object Creation

Response Time

«Concrete Scenario»

High Object Creation

Throughput

«Concrete Scenario»

High Object Creation

Throughput

The system must be

able to create 1000

objects of class X

per second

Time for Creation of

Object of class X

must not exceed 0.1ms

In average

Figure 13. Abstract Scenario for Efficiency

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

4 Quality Attributes and Patterns for Embedded Product Lines

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

«Quality Attribute»

Maintainability

«Quality Attribute»

Performance

«Quality Attribute»

Reliability

«influence»

«Quality Attribute»

Modifiability

«Quality Attribute»

Extensibility

«subcharacteristic»

«Quality Attribute»

Adaptability

«Means»

Encapsulation

«Means»

Indirection

«Means»

Modularity

«Means»

Abstraction

«Means»

Separation

«Means»

Location

Transparency

«Metric»

Required Effort

«Metric»

Affected Components

«Metric»

Cohesion

«Metric»

Coupling

«Metric»

Change Time

«Quality Attribute»

Maintainability

«Quality Attribute»

Performance

«Quality Attribute»

Reliability

«influence»

«Quality Attribute»

Performance

«Quality Attribute»

Reliability

«influence»

«Quality Attribute»

Modifiability

«Quality Attribute»

Extensibility

«subcharacteristic»

«Quality Attribute»

Adaptability

«Quality Attribute»

Modifiability

«Quality Attribute»

Extensibility

«subcharacteristic»

«Quality Attribute»

Adaptability

«Means»

Encapsulation

«Means»

Indirection

«Means»

Modularity

«Means»

Abstraction

«Means»

Separation

«Means»

Location

Transparency

«Means»

Encapsulation

«Means»

Indirection

«Means»

Modularity

«Means»

Abstraction

«Means»

Separation

«Means»

Location

Transparency

«Metric»

Required Effort

«Metric»

Affected Components

«Metric»

Cohesion

«Metric»

Coupling

«Metric»

Change Time

«Metric»

Required Effort

«Metric»

Affected Components

«Metric»

Cohesion

«Metric»

Coupling

«Metric»

Change Time

Figure 14. Quality Model for Maintainability

«Quality Attribute»

Reliability

«Quality Attribute»

Performance

«Quality Attribute»

Maintainability

«Quality Attribute»

Safety

«influence»

«Means»

Recovery

«Means»

Failover

«Means»

Redundancy

«Metric»

Mean Time to Failure

«Metric»

Fault Detection Time

«Metric»

Fault Recovery Time

«Metric»

Complexity

«Metric»

Repair Time

«Quality Attribute»

Fault Tolerance

«subcharacteristic»

«Quality Attribute»

Recoverability

«Quality Attribute»

Predictability

«Means»

Fault Detection

«Means»

Separation of

Computation

«Means»

Fault Avoidance

«Quality Attribute»

Availability

Figure 15. Quality Model for Reliability

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

4 Quality Attributes and Patterns for Embedded Product Lines

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

To illustrate the usage of our pattern meta-model and to depict how to relate patterns to
quality models, we present some architectural patterns in the following. The patterns have
been extracted from literature and are described using the meta-model. Note that the
presented collection of patterns is by no means complete and only serve as an example
illustrating the notion of our quality model and pattern meta-model. The patterns are given by
the problem addressed, a description of the actual solution, and a rationale justifying why the
pattern solves a problem. The justification given in the rationale addresses known effects on
quality attributes imposed on the system in which the pattern is applied.

In order to improve the reliability of a system, some form of redundancy is commonly applied.
In the literature, we found four architectural patterns that involve redundancy in some way to
decrease the risk of a system to fail due to either software or hardware errors. Each of these
redundancy patterns increases reliability, and often also safety, and has its own merits and
drawbacks that will be discussed in the following. Before presenting the individual patterns, we
describe a number of concrete scenarios that will later be used for discussing the applicability
of the patterns in numerous situations. As mentioned earlier, possible stimuli for these
scenarios are software fault, hardware fault, unexpected event, and invalid input. Responses
are availability, fault detection, fault tolerance, performance, levels of service, and cost. When
discussing redundancy and redundancy patterns, we therefore have potentially the following
concrete scenarios:

♦

High availability in the presence of software faults

♦

High availability in the presence of hardware faults

♦

High availability in the presence of unexpected events

♦

High availability in the presence of invalid inputs

♦

Tolerate hardware faults

♦

Tolerate software faults

♦

Tolerate unexpected events

♦

Tolerate invalid inputs

♦

Detect hardware faults

♦

Detect software faults

♦

Detect unexpected events

♦

Detect invalid inputs

♦

Good performance in the presence of hardware faults

♦

Good performance in the presence of software faults

♦

Good performance in the presence of unexpected events

♦

Good performance in the presence of invalid inputs

♦

High levels of service in the presence of hardware faults

♦

High levels of service in the presence of software faults

♦

High levels of service in the presence of unexpected events

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

4 Quality Attributes and Patterns for Embedded Product Lines

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

♦

High levels of service in the presence of invalid inputs

♦

High reliability at low costs in the presence of hardware faults

♦

High reliability at low costs in the presence of software faults

♦

High reliability at low costs in the presence of unexpected events

♦

High reliability at low costs in the presence of invalid inputs

In the literature [8], we’ve found four architectural patterns that involve redundancy in some
form. Basically, the patterns are homogenous redundancy and diverse (or heterogeneous)
redundancy. The latter has some special subtypes that are referred to as Monitor-Actuator
and Sanity-Check.

4.1.1 Homogenous Redundancy Pattern

Problem: Increase

reliability

and safety in the presence of single point hardware failures

but not systematic errors without great effort.

Solution:

The homogenous redundancy pattern, as shown in Figure 16, uses a number
of identical channels that are run in parallel and whose output is compared by a
controller to increase reliability. The channels are a set of devices including
processors and software running on processors that handle a related cohesive
set of data or control flows from incoming event to ultimate system response.
When using an odd number of channels, a majority-wins policy can be
implemented that can detect and correct failures in the minority channels.

Rationale:

Due to the fact that all channels are identical and thus need only be cloned
rather than redeveloped, robustness in the presence of failures in the channels
can be improved without a large development overhead. However, since all
channels are by definition identical, all redundant channels contain the same
error if one channel contains an error. Therefore, this pattern only detects
failures but no errors. In fact, homogenous redundancy only protects against
hardware failures, but not against software errors. Because of the duplicated
hardware devices, there is an increase in recurring cost. Also note that
redundant hardware generally requires more space and power and generates
more heat that might be an important problem in some systems.

Controller

Subsystem

Channel

Subsystem

Controller

Homogeneous

Redundancy

Pattern

Redundant

Channel

Figure 16. Homogenous Redundancy Pattern

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

4 Quality Attributes and Patterns for Embedded Product Lines

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

4.1.2 Diverse Redundancy Pattern

Problem: Increase

reliability

and safety in the presence of single point failures and

systematic errors.

Solution:

The diverse redundancy pattern, which is shown in Figure 17, mitigates the
primary disadvantages of homogenous redundancy by providing redundant
channels that are implemented using different means. This way, the diverse
redundancy pattern increases reliability and safety also in the presence of
systematic errors. Depending on how the redundant channels are
implemented, diverse redundancy patterns possess different characteristics.
The most expensive type of diverse redundancy is when all the channels are
approximately equal in terms of accuracy, throughput, and reliability and each
channel is implemented differently using different software and hardware
components. Two special types of this pattern are the Monitor-Actuator pattern
and the Sanity-Check pattern that are much less expensive.

Rationale:

Since all channels are implemented differently using different software and
hardware components, a system implemented using this pattern cannot only
detect failures and errors, but can also continue to execute correctly in the
presence of such faults.

4.1.3 Monitor-Actuator

Pattern

Problem: Increase

reliability

and safety in the presence of single point failures and

systematic errors at reasonable costs.

Solution:

The monitor-actuator pattern is a special type of diverse redundancy and
separates the channels into monitor and actuator channels, as shown in Figure
18. While actuator channels perform the actions, such as controlling or moving
mechanical devices, the monitor channel keeps track of what the actuation is
supposed to be doing and monitors the physical environment to ensure that the
results of the actuator are appropriate. The basic concept behind this pattern is
that the monitor channel identifies actuation channel failures so that
appropriate fault-handling mechanisms can be executed.

Controller

Subsystem

Channel

Subsystem

Controller

Diverse

Redundancy

Pattern

Diverse

Redundant

Channels

Channel

Subsystem

Channel

Subsystem

Channel

Interface

Figure 17. Diverse Redundancy Pattern

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

4 Quality Attributes and Patterns for Embedded Product Lines

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

Rationale:

Although the additional monitoring channel increases the recurring cost, the
monitor-actuator pattern allows to increase reliability and safety of a system in
a more cost-effective way than compared to the diverse redundancy pattern. In
addition, the system continues to be correct if the monitor channel fails and the
actuator didn’t fail. Since the monitor and actuator channels often exchange
messages periodically to ensure both are operating properly, performance
might be influenced negatively in some cases.

4.1.4 Sanity-Check

Pattern

Problem:

Provide a simple and cost-effective means for ensuring correctness and
detecting faults rather than tolerating faults particularly when there is a known
fail-safe state.

Solution:

As a type of diverse redundancy, the sanity-check pattern includes two
channels: a primary channel that realizes the functionality and a lightweight
secondary channel that does not have same accuracy and/or range. The
secondary channel only ensures the correctness of the primary channel by
performing a reasonableness or sanity check on the results from the primary
channel.

Rationale:

Since the secondary channel does not have the same accuracy and/or range
of the primary channel, the sanity check pattern is much better at fault
detection than fault tolerance. In fact, the secondary channel can identify when
the primary channel is broken but typically cannot take over all its duties when
this occurs. Thus, other fault tolerance means must be present if the system
must remain operational in the presence of errors. However, the sanity check
pattern is not very expensive to implement and manufacture.

To summarize the previous discussions, Table 1 shows some of the concrete scenarios that
are satisfied by the various redundancy patterns.

Controller

Subsystem

Actuation

Channel

Controller

Monitor-Actuator

Pattern

Actuator
Channel

Monitor

Channel

Monitor

Channel

Figure 18. Monitor-Actuator Pattern

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

4 Quality Attributes and Patterns for Embedded Product Lines

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

Pattern Satisfied

Scenarios

Homogenous Redundancy

High availability in the presence of hardware faults.

Detect hardware faults.

Tolerate hardware faults.

High reliability at low costs in the presence of hardware faults.

Good performance in the presence of hardware faults.

Diverse Redundancy

High availability in the presence of hardware faults.

High availability in the presence of software faults.

Detect hardware faults.

Detect software faults.

Tolerate hardware faults.

Tolerate software faults.

Good performance in the presence of hardware faults.

Good performance in the presence of software faults.

Sanity Check

Detect hardware faults.

Detect software faults.

Monitor-Actuator

High availability in the presence of software faults.

High reliability at low costs in the presence of hardware faults.

High reliability at low costs in the presence of software faults.

Table 1. Concrete scenarios satisfied by discussed redundancy patterns

The patterns presented so far involved redundancy in some form in order to detect and
tolerate faults and so to increase the reliability of a system. In the following, we present two
patterns that manly contribute to safety by providing means for detecting and handling failures
and faults and for managing safety processes.

4.1.5 Watchdog

Pattern

Problem:

Provide a very simplistic and low-cost solution to detect and handle failures
and faults during the execution of safety-critical systems.

Solution:

A watchdog, as shown in Figure 19, is a component that observes the behavior
of other components and that acts when they appear to misbehave. In general,
a watchdog is implemented as a passive receiver of liveness messages (or
strokes) from the observed components on a periodic or sequence-keyed
basis. Typically, the watchdog must be stroked within a specified period of time
or it will timeout, causing some error-correcting action to occur. In other words,
if an event occurs too late or out of sequence, then the watchdog initiates a
corrective action. Note that to handle the situation of a misbehaving task that
locks up the software, watchdogs are often implemented with hardware
support.

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

4 Quality Attributes and Patterns for Embedded Product Lines

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

Rationale:

The watchdog is a low-cost solution for ensuring the liveness of a component
but does not provide very complete coverage and the normal action to be
taken when the watchdog times out is drastic (e.g., system reset) and may not
be appropriate in some set of circumstances.

4.1.6 Safety Executive Pattern

Problem:

Provide a consistent and centralized point for managing potentially complex
safety processes in the presence of faults. The pattern is particularly useful
when many multiple safety concerns have to be addressed, fault detection is
complex, or the fault recovery mechanisms are elaborate.

Solution:

The Safety Executive Pattern, which is shown in Figure 20, uses a centralized
coordinator – the safety executive – for safety monitoring and control of system
recovery from faults. The safety executive tracks and coordinates all safety
monitoring and ensures the execution of safety actions when appropriate.
Typically, it captures watchdog timeouts, software error assertions, or faults
identified by monitors in the Monitor-Actuation pattern.

Rationale:

Because in the safety executive pattern the safety mechanisms are centralized
and isolated from other system components, complex fault isolation and
recovery can be handled and safety measures can be more easily verified and

Watchdog

Channel

Watchdog

Pattern

Monitored

Channel

Figure 19. Watchdog Pattern

Watchdog

Fail-Safe Processing

Channel

Watchdog

Safety

Executive

Pattern

Safety

Executive

Safety

Executive

Fault Recovery

Channel

Subsystem

Figure 20. Safety Executive Pattern

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

5 Design of Embedded Product Line Architectures

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

validated. However, the inherent complexity and effort required in constructing
an effective safety executive might be a problem for some systems.

5 Design of Embedded Product Line Architectures

This section discusses the design of product line architectures in the area of embedded
systems. The method presented in this section makes use of the information provided in
quality models and patterns described according to the metamodel described in Section 3.2 in
order to help in systematically designing and analysing product line architectures. It is an
extension of the PuLSE-DSSA method developed at the Fraunhofer Institute for Experimental
Software Engineering (IESE). PuLSE-DSSA is an integrated, iterative, and scenario-based
method for the design, evaluation, and maintenance of product line architectures [1]. It is part
of PuLSE™ (Product Line Software Engineering)

, a customisable method developed at

Fraunhofer IESE for building software product lines that covers the whole product line
development life cycle and that can be introduced incrementally [4].

5.1 Overview

The method for the design of embedded product line architectures can be split in three
phases as depicted in Figure 21.

In the preparation phase, the fundament is created on which the product line architecture is
built. This includes the documentation of the functional and quality requirements of the
product line and its members, the determination of the architectural views used to document
the resulting architecture. The preparation phase will be presented in Section 5.2. In the
subsequent phase, which is described in Section 5.3, the product line architecture is built and
analyzed. The third phase (“Learn from Experience”) aims at capturing best practices for
creating product line architectures of high quality and making them available for later use.
This experience-based approach to designing product line architectures is presented in more
detail in Section 5.4.

PuLSE is a registered trademark of the Fraunhofer IESE.

/HDUQIURP

([SHULHQFH

3UHSDUDWLRQ

$UFKLWHFWXUH'HVLJQ

$QDO\VLVDQG0DLQWHQDQFH

/HDUQIURP

([SHULHQFH

3UHSDUDWLRQ

$UFKLWHFWXUH'HVLJQ

$QDO\VLVDQG0DLQWHQDQFH

Figure 21. Architecture Creation Phases

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

5 Design of Embedded Product Line Architectures

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

5.2 Preparation

The goal of the preparation activities is to elicit and document all information that is necessary
to design a high-quality architecture for a given product line and its requirements. The basis
for the design of product line architectures is thereby a quality model documented according
to the metamodel described in Section 3.2. As shown in Figure 22, preparation is comprised
of four activities that will be described in more detail in the following. The results of the
preparation phase are business and goals and constraints, a quality model, and a set of
architectural views.

Figure 22. Preparation Activities

5.2.1 Business Goal Elicitation

The goal of this activity is to document the business goals of an organization in a form so that
they can be used to determine the planned products, the concrete requirements on these
products, and a schedule for developing these products. We additionally capture constraints
when documenting business goals, because they are usually at the same level of granularity
and it is, therefore, natural to capture them together. We continue documenting constraints
when we perform later activities as they arise, but the largest share of constraints are usually
documented in this early stage.

Business goals are usually informal statements. They can be organized hierarchically. We
collect business goals during moderated brainstorming sessions. The initially elicited business
goals are then later consolidated in a number of offline review cycles. Once the set of
business goals is consolidated, they are documented using a template. It has proven to be
beneficial to distinguish between internal and external business goals. Internal business goals
are goals set by the software developing organization. External business goals are goals set
by the customers of the products. The classification into internal and external goals provides
initial information on the criticality and importance of the different goals.

Figure 23 shows an example business goal (“High Service Availability”) documented using the
business goal template. Besides the name and a short description of the business goal, the
template also captures optionally the time frame for realizing the business goal, its priority, as

%XVLQHVV*RDO

(OLFLWDWLRQ

)XQFWLRQDOLW\

(OLFLWDWLRQ

4XDOLW\*RDO

(OLFLWDWLRQ

4XDOLW\

0RGHO

3URGXFW

5HTXLUHPHQWV

%XVLQHVV

*RDOVDQG&RQVWUDLQWV

9LHZ(OLFLWDWLRQ

DQG'HILQLWLRQ

$UFKLWHFWXUDO

9LHZV

%XVLQHVV*RDO

(OLFLWDWLRQ

)XQFWLRQDOLW\

(OLFLWDWLRQ

4XDOLW\*RDO

(OLFLWDWLRQ

4XDOLW\

0RGHO

3URGXFW

5HTXLUHPHQWV

%XVLQHVV

*RDOVDQG&RQVWUDLQWV

9LHZ(OLFLWDWLRQ

DQG'HILQLWLRQ

$UFKLWHFWXUDO

9LHZV

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

5 Design of Embedded Product Line Architectures

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

well as the influenced quality attribute(s).

Business Goal

High Service Availability

Description

The system must provide its service 24 hours a day
and 7 days per week.

Time Frame

Priority

High

Influenced Architecture
Quality

Reliability

Figure 23. Example Business Goal

Constraints are captured informally in lists. For better readability and easier reference, we
usually group them. Example groups are “Resource”, “Organization”, or “Functional”.

5.2.2 Functionality

Elicitation

Functionality elicitation is traditional requirements engineering. There are many methods
proposed for eliciting and managing requirements that can be used to perform this activity
and, therefore, we do not go into much detail here. We only state the expected result of this
activity, which is a software requirements specification that documents the complete set of
functional requirements on the planned products. The relation between functionality and
business goals (expressing that certain functional requirements have their source in certain
business goals) should be documented as well. In the case of a software product line, this is
accompanied by a so-called product map that relates functional requirements with products
and, thereby, expresses which product of the product line satisfies which requirements [19].

5.2.3 Quality Goal Elicitation

The goal of this activity is to document the quality attributes that affect the planned products in
the product line. This is done based on the metamodel presented in Section 3.2. The result is
a quality model that relates a number of quality attributes. Creating a quality model for a
product line at hand, that is to document the quality attributes that are relevant for the product
line and the respective quality requirements on the product line architecture, is done as
follows.

As with business goals, we collect quality goals in moderated brainstorming sessions. The
difference is that for quality goal elicitation we have a number of inputs. These are the
documented business goals as well as the functional product requirements. These are used to
direct the discussions. The relation between functional and quality requirements is usually one
to one, that is a functionality must be provided satisfying certain quality requirements, or one
to many, that is the same holds for groups of functionality (or the complete system).

The quality goal elicitation does usually not start on a clean sheet, but we provide initial quality
models that are adapted and refined in the brainstorming sessions. A good starting point is
the ISO/IEC 9126 standard [13]. This standard provides a breakdown of six quality attributes
(Functionality, Reliability, Usability, Efficiency, Maintainability, and Portability) into their sub-
characteristics, as well as definitions for all of these. Starting from such an existing quality

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

5 Design of Embedded Product Line Architectures

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

model has proven to be much more efficient than starting from scratch.

The brainstorming results are again consolidated offline and the results are finally
documented. The result is a quality model that decomposes the quality attributes that are
important for the planned products hierarchically into sub-characteristics. We do not restrict
the level of decomposition. The positive or negative influence between quality attributes is
captured by documenting the pair-wise influence relationships between two quality attributes.
A quality attribute is associated with a number of metrics that can be used to measure the
degree to which an architecture satisfies a quality requirement based that quality attribute. The
GQM (Goal Question Metric) approach [1] can be used to derive metrics for quality attributes.
The relations between a quality attribute and associated business goals are documented as
well.

At this stage, we usually do not collect means and concrete quality requirements, but extend
the quality model in these directions later. If, however, certain of these realization aspects are
clear already, they are documented as well.

Quality Attribute

Reliability

Description

The capability of the software product to maintain a specified
level of performance when used under specified conditions
(Definition taken from [13])

Sub-Characteristics

Recoverability, Predictability, Fault Tolerance

Influences

Performance (negative)
Maintainability (negative)
Safety (positive)

Means

Recovery, Fault Prevention, Fault Detection, Redundancy,
Separation of Computation

Metrics

Up time (%), Mean Time to Failure (time), Recovery Time (time)

Figure 24. Example Quality Attribute

The business goal example shown in Figure 23 can be refined to a quality model that breaks
down the quality attribute “Reliability” into its sub-characteristics “Fault Tolerance”,
“Predictability”, and “Recoverability”. The example also lists the positive and negative
influences on other quality attributes, means to achieve reliability in an architecture, as well as
metrics that enable the quantitative measurement of the quality attribute “Reliability”.

5.2.4 View Elicitation and Definition

The goal of the view elicitation and definition activity is to define an optimal set of architectural
views that are used to document the architecture of product line. There are cases in which an
existing view set can be used without adaptation. However, often the proposed views are not
sufficient to describe all relevant architectural aspects. Then, a new view set must be defined.
This can be done based on one of the view sets found in literature or from scratch. We use
the IEEE Recommended Standard 1471 for Architecture Description as a basis for doing that
[12]. It defines a metamodel for view-based architecture descriptions. However, it does not
provide concrete views or any process support for defining, creating, and using view-based
software architectures.

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

5 Design of Embedded Product Line Architectures

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

The view sets found in literature (e.g., in [9] and [17]) have in common that their focus is on
the description of functional aspects of a software architecture. Quality attributes can be the
basis for defining additional views that highlight how quality requirements are satisfied in the
architecture. The use of quality attributes as a basis for additional views on software
architectures has a number of effects. Views for certain quality attributes enable a clear
separation of concerns during architecture development. The architects can concentrate on
one important aspect of the software architecture at a time. The concentration on one aspect
per view increases the comprehensibility of the software architecture description. The effect of
the mentioned benefits is the quality of the documentation, that is, of the architecture
description, is increased. This, in turn, supports the creation as well as the maintenance and
evolution of the architecture description. However, there are also challenges that have to be
mastered when using views for quality attributes, the first being to select the views to be used
so that they form an optimal set that is neither too big nor too small. Once the views have
been selected, the consistency among them must be ensured and they must be maintained
properly.

The definition of an optimal set of architectural views is done as follows. We start the view set
definition by creating an initial set of views. Sources for these views are the quality model and
the product requirements, as well as existing view sets as a framework to integrate the
specific views into. The result is a list of views that should be used. Usually, the number of
views is too large. Therefore, the set of views is consolidated in a second step. The initial set
of views is analysed to find the optimal set (in terms of number of views and which views to
select). If certain important aspects of the architectures cannot be covered with the initial
views, view elicitation is revisited. Once the set of views is consolidated, we define its
metamodel that is used as a basis for documenting the software architectures. The
metamodel defines the element types and the relationships that can be used in the different
models, as well as relations among the different views. The metamodel is compliant to the
metamodel of the IEEE 1471 standard (i.e., it is a specialization of it). Based on the
metamodel, the notation for the new elements must be determined. There are three principal
possibilities for representing new architecture elements and relationships when augmenting
an existing set of views. The first is to create new view representations, for example entity
relationship diagrams for data structures. A second possibility is to filter elements from other
views or to highlight certain aspects in other views; for example, patterns can be presented
with combination of structural and behavioural views. A third possibility is to add new elements
to existing views, for example annotations for performance data in behavioural views.

At this point, the preparation phase is finished. The results are explicit business goals,
functional requirements, quality models, and the view set for documenting the software
architectures. This is the basis for architecture design and analysis.

5.3 Design and Analysis

Once the preparation phase has been finished, the design of the product line architecture can
start. The goal of this phase is to define and analyse an architecture for the product line that
fulfils the given quality and business goals. This section outlines an approach for the
integrated design and analysis of product line architectures. The approach guides software
architects in systematically making design decisions based on the identified and documented
business and quality goals and in assessing whether the architecture under design really
satisfies the requirements. It makes use of information provided in quality models and
patterns. The approach presented in this section is based on PuLSE-DSSA, an iterative and
scenario-based method for the design of product line architectures [1].

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

5 Design of Embedded Product Line Architectures

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

The basic idea of the approach is to develop product line architectures incrementally by
applying scenarios in decreasing order of architectural significance and to integrate analysis
into the design of architecture in order to monitor the quality of the product line architecture in
each iteration. During architecture design, functional and quality requirements that have an
effect on the architecture are selected. Then, the principal structure of the system is defined
by selecting means and patterns that satisfy the selected requirements. The architecture is
documented using the defined architectural views. In the following, the existing architecture is
iteratively refined. After each refinement step, the architecture is assessed concerning its non-
functional properties.

The architecture design, analysis, and maintenance phase takes as input a prioritised list of
business goals as well as functional and quality requirements, and produces a product line
architecture that satisfies the specified goals and requirements. As shown in Figure 25, it is
comprised of seven activities that particularly deal with the identification of existing solutions
that fulfil certain quality attributes, the documentation of the resulting architecture using the
selected views, and the evaluation of the software architecture with respect to the quality
requirements. In the following, the various activities will be briefly described.

5.3.1 Select Scenarios and Plan Next Iteration

The purpose of this activity is to delineate the scope of the current iteration step by selecting a
limited number of scenarios from the set of scenarios. As the order in which scenarios are

&KRRVH0HDQV

DQG3DWWHUQV

,QVWDQWLDWH

3DWWHUQV

'RFXPHQW

$UFKLWHFWXUHXVLQJ9LHZV

'HILQH(YDOXDWLRQ

&ULWHULD

$QDO\]H

3UREOHP

(YDOXDWH

$UFKLWHFWXUH

6HOHFW6FHQDULRV

DQG3ODQ1H[W,WHUDWLRQ

Architecture

OK?

yes

6RIWZDUH

$UFKLWHFWXUH

&KRRVH0HDQV

DQG3DWWHUQV

,QVWDQWLDWH

3DWWHUQV

'RFXPHQW

$UFKLWHFWXUHXVLQJ9LHZV

'HILQH(YDOXDWLRQ

&ULWHULD

$QDO\]H

3UREOHP

(YDOXDWH

$UFKLWHFWXUH

6HOHFW6FHQDULRV

DQG3ODQ1H[W,WHUDWLRQ

Architecture

OK?

yes

6RIWZDUH

$UFKLWHFWXUH

&KRRVH0HDQV

DQG3DWWHUQV

,QVWDQWLDWH

3DWWHUQV

'RFXPHQW

$UFKLWHFWXUHXVLQJ9LHZV

'HILQH(YDOXDWLRQ

&ULWHULD

$QDO\]H

3UREOHP

(YDOXDWH

$UFKLWHFWXUH

6HOHFW6FHQDULRV

DQG3ODQ1H[W,WHUDWLRQ

Architecture

OK?

yes

6RIWZDUH

$UFKLWHFWXUH

Figure 25. Architecture Design and Analysis

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

5 Design of Embedded Product Line Architectures

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

addressed is very important, those scenarios that are considered to have the highest
significance for the architecture should be selected for the first iteration. In the next iteration,
the second most important group is selected and so forth.

When the scenarios were created, they are prioritised and grouped to define the architecture
creation plan, which contains a detailed plan for the next iteration and defines the order of
processing the groups with respect to their priority. Prioritising scenarios should follow a
simple, basic rule: the bigger the impact of a scenario on the architecture, the higher the
scenario’s priority. However, simple in theory, evaluating the architectural impact of a scenario
from its description is a difficult, non-trivial task that generally requires much experience.
Below, some criteria that can be used for prioritising scenarios and constructing the
architecture creation plan are summarized. These criteria can be used as an indication of the
expected architectural impact of scenarios.

•

Economic Value. This is the value from an economic point of view that will be added
to the product line in case of realizing a scenario will be realized. The product line
scope can deliver this information. It is clear that a high economic value is a hint for
high scenario priority.

•

Typicality and Criticality. A scenario is of high typicality when it reflects routine
operations whereas critical scenarios occur in a rather sporadic manner and when the
user does not expect them to occur. Typical scenarios should therefore implemented
first.

•

Future-proof. A scenario is future-proof when it considers possible evolution points.
Future-proof scenarios are likely to have a big impact on the architecture and therefore
they should assigned high priorities.

•

Effort. This is an estimation of the effort required for realizing a scenario. Since the
architecture creation plan also assigns responsibilities to personnel, the effort
estimation is surely helpful.

At the end of this process step, it has been defined which group of scenarios will be
processed in the next iteration.

5.3.2 Define Evaluation Criteria

Based on the business and quality goals for the product line and its members and taking into
account the constraints, the criteria to be met by the architecture are defined. These criteria
are later used to evaluate the architecture. As an input for this activity, the architecture
creation plan and the quality scenarios are used. The output is an architecture evaluation plan
consisting of a number of evaluation criteria. Defining evaluation criteria before the actual
design begins has a number of benefits, including a better understanding of the requirements
and avoidance of specifying criteria that, due to a fixed perspective, merely support what has
been developed.

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

5 Design of Embedded Product Line Architectures

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

5.3.3 Choose Means and Patterns

During this activity, mechanisms are elicited that support the satisfaction of the quality
requirements collected in the last step. In a first step, appropriate means are selected. The
selection is done by comparing the scenarios associated with the means with the given
requirements. Once the means are selected, the patterns that specialize the respective
means are selected. This is again done by comparing the scenarios related to the patterns
with the requirements. The patterns can be either taken from published pattern collections
(e.g., [5] and [8]) or have been identified and documented during earlier software architecture
creation projects.

5.3.4 Instantiate

Patterns

The selected patterns are instantiated in this activity in order to address the functional
requirements. During the instantiation, the architect associates the elements of the pattern
with concrete architectural elements.

5.3.5 Document Architecture using Views

Using the architectural views selected and defined during the preparation phase, the
architecture resulting from the previous step is documented. In later iterations, this means that
the architecture documentation is continuously refined.

5.3.6 Evaluate

Architecture

The purpose of this activity is to evaluate the given product line architecture according to the
evaluation criteria defined earlier in the architecture evaluation plan. If the evaluation is
successful, that is all evaluation criteria are satisfied, the architecture creation either continues
with the next iteration or is finished if all scenarios have been applied. In the evaluation of an
architecture, the available quality models are used. The explicit relation between patterns,
scenarios, and quality attributes and the rationale documented for a pattern helps in
evaluating the given architecture. To minimize the effort involved in the evaluation, only the
functionality newly added in the last iteration is evaluated in detail. Nevertheless, it is essential
to ensure that all scenarios from previous iterations are still supported.

5.3.7 Analyse

Problem

If the evaluation of the architecture showed that at least one of the defined evaluation criteria
was not fulfilled, the underlying problem is examined during this activity in order to determine
how the architecture creation process can continue. The analysis focuses on whether the
current set of scenarios could be applied successfully to the architecture that resulted from the
previous iterations and includes an in-depth reasoning about the chosen architectural
approaches and decisions. In the best case, changing just the last iteration may solve the
problem. In the worst case, if a solution supporting all scenarios in all variants even exists it is
necessary to track back to the first iteration. The input is the result from the architecture
evaluation activity. Outputs of the activity are a problem analysis and an assignment of action
items.

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

5 Design of Embedded Product Line Architectures

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

5.4 Learning from Experience

Designing a product line architecture is to sketch a solution for a given problem. A problem
expressed in terms of functional and quality requirements is thereby translated to the software
domain and there it is shown how the problem can be solved. This creative activity is not well
supported by current architecture design approaches. Even though there is a large number of
architecture approaches, the output of the design step is still largely dependent on the
experience of the people that perform it. The design activity involves judgments on the
importance and significance of different requirements and analyses to trade off between
different alternatives. Since an architecture captures the earliest, most far-reaching, and most
difficult to change design decisions, it is crucial to aim for a product line architecture of as high
quality as possible. This can be supported by providing experience in terms of best practices
and guidelines that have been collected in earlier successful projects and that are packaged
and presented to designers to support them in their difficult task. In the following, we briefly
present our approach to experience-based architecture design.

The basis for our experience-based approach to the design of product line architectures is the
Quality Improvement Paradigm (QIP) [1]. The QIP is a method that enables the establishment
of a continuous improvement. It is based on the principles of step-wise controlled
improvement and experimental software engineering. QIP consists of the steps: Characterize,
Set Goals, Choose Process, Execute, Analyse, and Package. The underlying idea of the QIP
is to set measurable goals (Set Goals) to improve a given situation (Characterize) and to
analyse the degree to which the goals have been reached (Analyse) and to which they have
improved the execution (Execute) of the chosen process (Choose Process). Experience that
have been gained by reaching (or missing) the set goals are packaged for later use and can
then influence later iterations (Package). Over time, a body of experience is set up that
supports a continuous improvement. As described above, we want to support the architecture
design activity (cf. steps “Choose Means and Patterns” and “Instantiate Patterns” in Section
5.3) by providing packaged experience to the designers. The following example illustrates how
such a catalogue can be used.

Consider a software architect designing a product or component of a product for which the
architect knows the functional and quality requirements. Let “The system must be available
24/7 even in the case of a hardware fault” be a quality requirement for the product or
component under design. In our experience-based approach, the experience is presented to
the architect in the form of pattern catalogues that contain rationales and guidelines that
enable the architect to decide which pattern will satisfy the given requirements. The starting
point for selecting the right patterns are scenarios that are related to quality attributes. Figure
26 shows stimuli and responses from which reliability scenarios can be constructed.

Reliability Scenarios

Stimuli

Software Fault
Hardware Fault
Unexpected Event
Invalid Input

Responses

High Availability in Presence of Stimulus
Tolerate Stimulus
Detect Stimulus
High Performance in Presence of Stimulus
High Level of Service in Presence of Stimulus

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

6 Summary

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

High Reliability at Low Costs in Presence of Stimulus

Figure 26. Reliability Scenarios

The different scenarios are related to patterns in a way that enables to make decisions and to
select the right patterns. The requirement stated above is covered by the scenario “High
availability in the presence of hardware faults”. This scenario is related to the architectural
means “Redundancy”; this means that redundancy is a principal mechanism to achieve a high
availability. To the means “Redundancy”, a number of patterns are related, two of them being
the “Homogenous Redundancy Pattern” and the “Diverse Redundancy Pattern”. There are a
number of scenarios related to the patterns, which support the architect’s decision making.
For example, the “Homogenous Redundancy Pattern” is related to scenarios with stimulus
“Hardware Fault” only, whereas the “Diverse Redundancy Pattern” is related to patterns with
stimulus “Software Fault” as well. This means that the “Diverse Redundancy Pattern” can deal
with hardware and software faults and the “Homogenous Redundancy Pattern” can deal with
hardware faults only. The “Homogenous Redundancy Pattern”, however, is also related to the
scenario “High Reliability at Low Costs in Presence of Hardware Fault”. Therefore, the
architect can trade off between covering hardware and software faults and providing a solution
that is less expensive.

6 Summary

This document has discussed the pattern-based analysis and design of architectures for
embedded software product lines. In particular, it has presented a method for the integrated
analysis and design of product line architectures that makes use of information provided in
quality models and patterns documented according to a metamodel also presented in this
document.

7 References

[1] Anastasopoulos, M., Bayer, J., Flege, O., and Gacek, C. A Process for Product Line

Architecture Creation and Evaluation – PuLSE-DSSA Version 2.0. Technical Report, No.
038.00/E, Fraunhofer IESE, June 2000.

[2] Barbacci, M., Klein, M., Longstaff, T. A., Weinstock, C. B., “Quality Attributes”, Software

Engineering Institute, Carnegie Mellon University, Technical Report, CMU-SEI-95-TR-021,
1995.

[3] Basili, V. R., Caldera, G., and Rombach, H. D. Goal Question Metric Paradigm, In J. J.

Marciniak (Ed.), Encyclopedia of Software Engineering, Vol. 1, pp. 469–476, John Wiley &
Sons, 1994.

[4] Bayer, J., Flege, O., Knauber, P., Laqua, R., Muthig, D., Schmid, K., Widen, T., and

DeBaud, J.-M. PuLSE: A Methodology to Develop Software Product Lines. In Proceedings
of the Fifth ACM SIGSOFT Symposium on Software Reusability (SSR'99), Los Angeles,
CA, USA, May 1999, 122–131.

[5] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., and Stal, M. Pattern-Oriented

Software Architecture: A System of Patterns, John Wiley & Sons, 1996.

[6] Chung, L., Gross, D., and Yu, E. Architectural Design to Meet Stakeholder Requirements,

In P. Donohoe (Ed.) Software Architecture, 1999, Kluwer Academic Publishing, 545–564.

Pattern-Based Architecture Analysis and Design of Embedded Software
Product Lines

7 References

EMPRESS

Deliverable D.2.1-D2.2 Appendix B

15 December 2003

Version 1.0

Public Version

[7] Clements, P., Kazman, R., and Klein, M., “Evaluating Software Architectures: Methods

and Case Studies”, Addision-Wesley, 2002.

[8] Douglas, B. P. Doing Hard Time: Developing Real-Time Systems with UML, Addison-

Wesley, 1999.

[9] Hofmeister, C., Nord, R., and Soni, D. Applied Software Architecture. Addison-Wesley,

1999.

[10] IEEE Computer Society, IEEE Standard Glossary of Software Engineering Terminology.

IEEE Standard 610.12-1990, 1990.

[11] IEEE Computer Society, IEEE Standard 1061-1998, “IEEE Standard for a Software

Quality Metrics Methodology”, 1998.

[12] IEEE Computer Society, IEEE Recommended Practice for Architectural Descriptions of

Software-Intensive Systems, IEEE Std-1471-2000.

[13] International Organization for Standardization, ”ISO/IEC Standard 9126 – Quality

Characteristics and Guidelines for their Use”, 2001.

[14] Kazman, R., Bass, L., Abowd, G., Webb, M., “SAAM: A Method for Analyzing the

Properties of Software Architectures”, In Proceedings of the 16

International Conference

on Software Engineering, pp. 81–90, May 1994.

[15] Kazman, R., Abowd, G., Bass, L., Clements, P., “Scenario-Based Analysis of Software

Architectures”, IEEE Software, November 1996.

[16] Kazman, R., Klein, M., and Clements, P., “ATAM: Method for Architecture Evaluation”,

Software Engineering Institute, Carnegie Mellon University, Technical Report, CMU/SEI-
2000-TR-004, October 2000.

[17] Kruchten, P. The 4+1 View Model of Architecture. IEEE Software, November 1995

12(6):42–50.

[18] McCall, J., Richards, P., and Walters, G., “Factors in Software Quality”, 3 vol. NTIS AD-

A049-015, 015, 055, Nov. 1977.

[19] Schmid, K. The Product Line Mapping Approach to Defining and Structuring Product

Portfolios. In International Workshop on Requirements Engineering for Product Lines
(REPL'02), Essen, Germany, September 2002.

Wyszukiwarka

Podobne podstrony:
instrukcja v1 0 0 0 public
finanse publiczne Podatki (173 okna)
Zarządzanie w Administracji Publicznej Rzeszów właściwe
ZDROWIE PUBLICZNE I MEDYCYNA SPOŁECZNA
PO wyk07 v1
Demograficzne uwarunkowania rynku pracy i gospodarki publicznej
Typowe gatunki publicystyczne
5a Finanse publiczne
finanse publiczne
Wystapienia publiczne
Zagadnienia ogólne finansów publicznych i prawa finansowego
Public Relations oglne
Wykład 4 Podstawy prawne finansów publicznych
i 14 0 Pojecie administracji publicznej
komunikowanie publiczne
s10 v1
finanse publiczne
Czynniki konkurencyjnosci organizaci publicznych Wyklad V

więcej podobnych podstron