Content uploaded by Tor Erlend Fægri
Author content
All content in this area was uploaded by Tor Erlend Fægri on Dec 15, 2016
Content may be subject to copyright.
Patterns in product family architecture design
Svein Hallsteinsen, Tor Erlend Fægri. Magne Syrstad
SINTEF Telecom and informatics, N-7465 Trondheim, Norway
{svein.hallsteinsen | tor.e.fegri | magne.syrstad}@sintef.no
Abstract. The common architecture is a central asset of a product family. But
in many cases variations in quality requirements between family members make
it difficult to standardise architectural solutions across the family. Therefore the
common architecture has to support variation. In this paper we propose an
approach to product family architecture design, modelling and use based on
architecture patterns and their relationship to quality attributes that supports the
representation of an open architecture and the specialisation of this architecture
to meet product specific quality requirements.
1 Introduction
The common software architecture is a central asset of any software product family
[2,6]. Primarily it is the quality requirements and the anticipated execution
environment that dictate the design of the architecture. In very homogeneous product
families the idea of a common architecture is unproblematic. Although the
functionality may vary considerably between member applications, the applications
have very similar quality requirements and common architectural solutions are viable.
However, in our work with introducing product family engineering in software
companies developing and delivering information systems of various sorts packaged
as standard products, we often see the need for more heterogeneous product families.
Here, the quality requirements and the anticipated execution environment vary
considerably between member applications and the common architecture has to allow
for different architectural choices in different applications.
One way to cope with this is to simply leave the architecture open (i.e.
underspecified) on the points where the variation in requirements makes it impossible
to standardise architectural decisions. This approach has the drawback that it becomes
more difficult to identify and build common components reusable across all family
members while it also complicates the derivation of member products by transferring
difficult architectural decisions to the product derivation process.
In this paper we propose an approach to representing open architectures that seek
to alleviate these drawbacks by encoding more explicitly foreseen variations in
quality requirements and decision support for specialising the architecture for a given
set of specific quality requirements. The approach is based on the following three
main elements:
-
use of patterns as architectural building blocks;
-
use of variation points to make explicit the allowed variation in the
composition of patterns for a given architecture;
-
guidelines for the resolution of variation points based on knowledge of the
effect of using a pattern in an architecture on quality properties of
applications built according to this architecture.
The paper is organised as follows: Section 2 introduces patterns, quality models
and decision models as tools for modelling product family architectures. Section 3
explains how concrete product architectures can be derived. Section 4 gives a
summary of how our approach has been validated in industry, section 5 contains a
discussion of related work and section 6 presents initial conclusions and suggestions
for future work.
2 Modelling open product family architectures
The architecture of a product family has both a prescriptive and a descriptive purpose.
Here we focus on the prescriptive aspect, which is to constrain and alleviate the task
of the application designers by providing a template for application design. It does
this by standardising solutions to design problems recurring across the members of
the product family.
Patterns as building blocks. Defining solutions to recurring problems is exactly
what patterns are about, so therefore patterns form natural building blocks for
architectures1. Moreover, established patterns often have known effects on quality
attributes [7] making it possible to reason about the effect of choosing one pattern
over another. Thus the backbone of our architecture model is a pattern language
encompassing the recommended patterns and relevant relations between them. These
are uses (one pattern uses another pattern in its solution), specialises (one pattern is a
specialisation of another) and conflicts (two patterns cannot be used together).
We are using the tem pattern in a rather broad sense, meaning any problem
solution pair recommended by the architecture either generally or to meet particular
quality requirements. This means that the pattern language may contain both
established patterns widely known an used throughout the software community, and
“local” pattern particular to the product family. In the latter case some may argue that
this is not a proper use of the term pattern, since we are talking about a local
invention. However, as long as we are talking about a recurring problem within the
product family and a solution prescribed by the architecture, and the architect has an
idea about how it influences the quality properties of the derived products, we prefer
to call it a pattern.
Encoding architectural variation. We divide the pattern language into two parts,
the base part and the varying part. The base part contains the enforced patterns, the
1In this paper we do not distinguish patterns and styles. Styles we understand as
high level patterns with a strong overall organising effect on a system.
ones that all applications must use. The varying part contains patterns that an
application may choose to use or not.
The varying part is organised into variation points. There are two kinds of variation
points: optional patterns and alternative patterns. An optional pattern is one that may
be included in an application architecture or not. Alternative patterns is a group of
patterns basically solving the same problem (often they are alternative specialisations
of a more abstract pattern), but in different ways and with different effects on
achievable quality attributes, and where the application programmer can choose the
one that best fits the requirements of the application.
Decision support. The specialisation of the architecture for a given set of quality
attributes is supported by a set of design guidelines. We have adopted the ISO 9126
standard as the basis for modelling quality but with the possibility to break down the
quality attributes defined in the standard into more detailed ones. Scenarios are used
to link quality attributes and patterns in the design guidelines. A scenario describes a
typical requirement related to one or more quality attributes and is also related to one
or more patterns in the pattern language promising to achieve that requirement.
Constructed as stimulus-response pairs, scenarios are effective instruments for
reasoning about the effect of patterns on quality attributes. A pattern may contribute
to satisfy multiple quality attributes, and the same quality attribute may be affected by
multiple patterns. More importantly, quality attributes influence each other through
the choice of patterns used in the architecture. For example, a pattern may have a
positive impact on performance but may affect maintainability negatively.
The design guidelines are organised into variation points in a similar way to the
variable part of the pattern language, with optional scenarios and alternative
scenarios. Table 1 below illustrates a decision guideline dealing with variation in the
handling of changes in the quality in the client-server connection: If the user of the
application requires continued service in the case of communication failures of the
client server connection, the architecture should be based upon the self reliant client
pattern. However, if continuous service is not required, the rich or thin client pattern
may be used.
Variation in client-server connection
availability
Stimulus Responses
Pattern Affects quality
attributes
Denial of service Thin client
Partial service Rich client
Communication
failure between
client and server Continued service Self reliant client
Fault tolerance
Recoverability
Table 1 Example decision guideline
Components. Patterns define roles and collaboration between roles. In a system
designed and implemented according to a set of patterns these roles are filled by
component implementations. Normally a component plays a role in more than one
pattern.
In the architecture we also include component specifications which are defined by
the synthesis of a set of roles from different patterns and possibly also collaboration
models related to the functionality of the system. Consider for instance a business
component in a layered architecture with stateless serverside business components.
The patterns involved are layering with a business component layer, and stateless
components. The business component has a role in the layering pattern, in the
stateless component pattern and in one or more use case related scenarios defining the
business services provided by the component.
Client server pattern
Model View Controller pattern
Component 1
Client Server
Model
View
Controller
Component 2
Figure 1 Components playing different roles
Figure 1 above illustrates how components may play different roles in a given
instantiation of the architecture. One component plays the role of a client in one
pattern and the role of a view in another etc. The controller role in the figure may be
played by either component 1 or component 2.
In summary, Figure 2 below illustrates our open architecture reference model. The
use and applicability of the model will be discussed in the following sections.
Pattern
Component
role
Component
spec
Base
architecture
Component
impl
Collaboration
Architecture
Quality
attribute
Scenario
Variation
point
Decision
model
Quality
req
-concerns*
*
1
*
-chooses between*
*
-defines *
*
-defines
*
*
Architecture
element
-Favours
**
-Use
*
*
1
*
-specialise
0..1
*
-conform *
*
-implement
**
Figure 2 The architecture reference model
3 Deriving family member architectures
Using the open architecture to support application architecture design involves the
following steps:
-
First specialise the quality model by resolving the variation points in light of
the particular quality requirements of the application. For each optional
scenarios decide whether it is relevant or not. For each group of alternative
scenarios select the one that best fits the needs of the application.
-
Then use the decision model to select patterns from the family pattern
language that fits the specialised quality model. The scenarios specified by the
quality model match scenarios labelling design rules in the decision model
which point to patterns promising to contribute to satisfying the scenario.
Together with the base part of the family architecture the selected patterns
form the pattern language of the application.
-
Finally select component specifications that matches the specialised pattern
language.
Since patterns normally affect more than one quality attribute there may be tradeoff
situations. The priorities of the scenarios may help to resolve such situations.
4 Validation
The method to modelling product family architectures that we have described in the
preceding sections is being validated and refined through our long-term collaboration
with Norwegian software companies. Most of them are SMEs, developing products
within the distributed information systems category. The pressure to deliver more
products, at lower costs and within shorter time-frames enforces them maximise the
value of their investments in developing software assets. All of the companies we
have worked with show a strong overall commitment to adopt product family
engineering practices in order to accomplish this. However, the maturity of the
adoption vary.
We have developed a reference architecture for the construction of product family
for information systems with particular requirements in the area of client device
adaptivity. We validated the reference architecture on real-world product family
efforts by performing numerous architecture evaluations at the companies (in form
inspired by the ATAM SM and ARIDSM methods [3]). In summary, we have gained
confidence that our approach is both useful and effective. The obtained results have
been used to refine and validate our quality models, the pattern language and the
decision model. Most importantly, these architecture evaluations have shown that the
different companies’ product families can be captured and modelled by our reference
architecture.
The experience for these architecture evaluation exercises has convinced us that
using patterns or pattern like constructs as building blocks of architectures is a good
idea. During the evaluations we have identified patterns used in the architectures and
related them to quality properties of the product family. This form of architectural
documentation, which normally did not exist on beforehand was generally very well
received both by the architects and the developers.
As an example we consider variation in terms of client device adaptivity. A
recurring variation point observed among the companies is variability in deployment
models. On one hand, the benefits of low-cost client deployment as exemplified by
web-based clients, promote server-centric products architectures. On the other hand,
rich user interfaces that exploit the resources on powerful PCs, are popular among
users that use the software for longer periods of time or are periodically disconnected
from the network. Thus, software architectures that can support this variability are
needed.
These requirements have been incorporated into the quality model, the pattern
language and the decision model (please refer to section 2 for descriptions). The
quality model included with our reference architecture covers these aspects of
variability. The underlying decision model associates these quality attributes with a
set of patterns. Figure 3 below is an example from our pattern language that includes
patterns that are mainly concerned with variability in deployment models. The dotted
arrows denote specialisation relationships. When a pattern specialises multiple other
patterns, we refer to patterns that include and specialise aspects from multiple other
patterns.
Presumably, most of these patterns are well-known to the reader [4,5]. The patterns
that have been identified and added to our pattern language are anyside component
and adapting client. As the name implies, the first pattern denotes components that
are deployable on either the client or the server machine.
«pattern»
Model View Controller
«pattern»
Publish subscribe
«pattern»
Presentation Abstraction Control
«pattern»
Adapting client
«pattern»
Anyside component
«pattern»
Configurator
«pattern»
Command
«pattern»
Workflow
Figure 3 Pattern language example (adaptivity qualities)
The latter denotes a client device that is able to dynamically adapt to context changes
through configuration changes (see e.g. [9] for scenario descriptions). Both patterns
are documented in [1]. The anyside component pattern, likely to be stateless for
scalability at the server side, appear to be a viable solution to some of these
requirements and is already being investigated. The adapting client pattern is more
involved, but promise to address additional adaptivity qualities.
5 Related work
Philips, as one of the early adopters of product family engineering practices in
Europe, has gathered a large amount of knowledge and experience within the area of
platform based software development. Of particular relevance to our work are efforts
related to product populations [12]. Product populations seeks to address the problem
of increasing levels of complexity and scale in software product development by
advocating and controlling reuse of assets between product families. The approach to
architecture design presented in this paper can be used to address variability
management in product populations.
Work done at SEI on ABASs [11] and later within the ADD method [7], is based
on similar assumptions to ours. For example, that certain quality properties can be
associated with architectural patterns. Additionally, we have drawn upon existing
validation techniques from SEI, such as ATAMSM and ARIDSM[3].
The OOram method, developed by T. Reenskaug et.al. [10], advocates the use of
role models and derivation of object specifications by role synthesis. This has inspired
our ideas on component roles and the derivation of component specifications based on
role synthesis.
6 Conclusions and future work
We have argued that in product families significant variation in quality requirements
is often the case, and that this requires variation also in the family architecture. Just
leaving the architecture unspecified on the points where applications must be allowed
to make own architectural decisions is not a satisfactory solution as it leaves too much
to application programming. Using patterns as architectural building blocks, and
encoding the relationship between quality attributes and optional or alternative
patterns in the architecture, we have proposed a way to represent family architectures
that allows for variability while retaining strong design support for application
development.
So far our approach has been used to represent a reference architecture for
information systems intended to provide services over the internet and having to cope
with variations in user context and the capabilities of network connections and client
devices. This exercise has provided promising experience with the quality models,
decision models and patterns as a vehicle to encode architecture design support.
During the development of the reference architecture we evaluated several real life
family architectures to collect requirements and validate our results. The findings of
these evaluations also supported our assumption that family architectures in this
domain must embed variation.
Now we are about to embark on validating the proposed approach on the modelling
of product family architectures where we will also need to model the implementation
framework supporting the architecture. This will give us the opportunity to test also
the derivation of component specifications and their relation to implemented
framework components in the context of a family architecture embedding variation.
Acknowledgements
The work reported here has been carried out in the context of the Café2and DAIM3
projects. The collaboration with both academic and industrial partners in these
projects has provided valuable inspiration and feedback to our work.
References
1. DAIM Software Engineering Handbook. Available through ICT-Norway 2003 (www.ikt-
norge.no).
2. Jan Bosch. Design and Use of Software Architectures - Adopting and Evolving a Product-
Line Approach. Addison-Wesley, 2000.
2 ITEA project ip00004, Café
3Norwegian technology development project led by ICT-Norway and partially funded by the
Norwegian research council.
3. Paul Clements, Rick Kazman, Mark Klein. Evaluating Software Architectures: Methods
and case studies, Addison Wesley, 2002.
4. Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerland, and Michael Stal.
Pattern-Oriented Software Architecture - A system of Patterns, Wiley, 1996.
5. Douglas Schmidt, Michael Stal, Hans Rohnert, and Frank Buschmann. Pattern-Oriented
Software Architecture Volume 2 – Patterns for Concurrent and Networked Objects, Wiley,
2001.
6. Mehdi Jazayeri, Alexander Ran, Frank Van Der Linden. Software Architecture for Product
Families: Principles and Practice. Addison Wesley, 2000.
7. Len Bass, Mark Klein, and Felix Bachmann. Quality Attribute Design Primitives and the
Attribute Driven Design Method. 4th Intl. Workshop on Product Family Engineering,
Bilbao, Spain, 2001.
8. Svein Hallsteinsen, Eric Swane. Handling the diversity of networked devices by means of
a product family approach. 4th Intl. Workshop on Product Family Engineering, Bilbao,
Spain, 2001.
9. Mehul Mehta, Nigel Drew, Chrostoph Nierdermeier. Reconfigurable terminals: An
overview of Architectural Solutions. IEEE Communications Magazine, August 2001.
10. Trygve Reenskaug with Per Wold and Odd Arild Lehne. Working with objects – The
Ooram software engineering method. Manning Publications, 1996.Rob van Ommering.
Building product populations with software components. International Conference on
Software Engineering 2002, Orlando 2002.
11. Mark Klein and Rick Kazman. Attribute-based architectural styles. SEI Technical report
CMU/SEI-99-TR-022, 1999.
12. Rob van Ommering. Building product populations with software components.
International Conference on Software Engineering 2002, Orlando 2002.
