Patterns, Teams and Domain Engineering
Steven Fraser, Deborah Leis_
Robert McLellan
sdfraser@bnr.c~ leishmam@bnr.c~ robm@bnr.ca
Bell-Northern ResearchLtd.
ottaW~
ontario,
Canada - KIY 4H7
(613) 763-3073, Fax: (613) 763-4222
An important aspect of patterns is that they allow for some
specitlc aspect of variability within a collaborating group of
classesor objects. For example, the Sfxategypattern allows
for atgorithrns to viny, Proxy allows for the location of an
object or how the object is accessedto vary, and Abstmct
Factory allows families of product objects to vary. The
variability contained in patterns is in terms of classesor
concepts rather than a simpler approach (to variability) such
as a parameter Iisl for a single method invocation. In order
to correctly use a pattern and to gain the reusability and
flexibility afforded by it it should be clearly understood
what needsto be varied and whether the context is similar
enough. This forces a requirement on the usability of
existing patterns for the identilcation of variability and
context. Similar requirements exist for the definition of
new patterns for the recognition of variants, invariants and
context within a design problem. Domain engineering
techniques that focus on reusability emphasize the
identification of variants and invariants and thus provide an
initial point for the discovery of new patterns and the
classflcation of existing patterns.
Introduction
The scope of our work is the development of domain
specflc architectures for telephony systems.Telephony
systemsare characterized by product families of large realtime systems. One way of making these systems reusable
is through the use of object-oriented design patterns
~LoP94]. These patterns me becoming an important way
to represent and communicate methods of solving common
design problems. To date, the only method for arriving at
these patterns has been using inductive means. This has
involved the study of several example applications
followed by genemlization of common design problems
and their solutions. If patterns me to be identifkd quickly
(to define the 24 patterns in [Gamma94] required approximately 152 man months of effort), a process must be
defined to identify candidate patterns which overtime are
designated to be true patterns. We hypothesize that this
process should be developed as an extension of current
reuse-oriented domain engineering techniques. As well, it
is hypothesized that these techniques can provide the
requi~d classification mechanism for storing existing
patterns.
Reuse-Oriented
Domain
Engineering
by Teams
Domain engineering is a processfor developing software
assetsand models that encapsulateproject knowledge for
reuseby application engineers, It is characterized by the
explicit identMcation of variants and invariants over several
applications in a product family and/or requirements for a
set of applications. The process of scoping a domain and
developing domain models is called domain analysis
~g90].
Initial application of domain analysis techniques
at BNR (specKlcally the Featme-Oriented Domain Analysis
(FODA) technique based on the work of Kang et. al.
~S provided a necessarysystematic approach
WUI@l)
(Fraser and Saunders ~raser93]), Certain domain analysis
techniques also capture decisions an application developer
should make to identify an application or portion of an
application in a reuse librmy. These techniques also
provide mechanisms for system structuring. Structuring
mechanisms include clustering, abstractio~ class~lcatio~
genemlizatio~ and a feature vocabulary. The classitlcatiou
decisions, features and variability analysis can be used to
organize existing patterns in a libmry or catalogue for use
during design.
Design Patterns
Design patterns are evolving in the Object-Oriented
community as evidenced by the recent PLoP ’94 ~loP94]
conference. The concept of patterns has its roots in the
work of the architect Christopher Alexander [Alexander77].
Very generally, a pattern is a solution to a problem in a
context with a rationale for why the particular solution is
appropriate in the context. Patterns can exist at several
levels of abstraction in system development. Patterns may
abstract an analysis, a design or a process. They capture
existing, well-proven design experience to provide a
common lexicon and a basis for understanding design
principles. For example, the design patterns characterized
by Gamma et. al. [C2unrna94] describe groups of
collaborating objects and classes. These patterns are
customized to solve spectilc design problems. Patterns
have also been descriied by Pree ~ree94].
Permission to copy without fee all or part of this material is
granted provided that the copies are not made or distributed for
direct commercial advantage, the ACM copyright notice and the
title of the publication
and its date appear, and notice is given
that copying is by permission of the Association of Computing
Machinery.To
copy otherwise, or to republish, requires
a fee andlor specific permission.
SSR ’95, Seattle, WA, USA
(3 1995 ACM 0-89791 -739-1 /95/0004 ...$3.50
Implicit in the patterns community is a consensusthat the
process of defining or identifying patterns is a team activity
involving a community of domain expertise. This process
begins with the preliminary proposal of a candidate pattern
based on the observation of a number of instance examples;
peer discussion which refines the pattern or elicits
222
additional examples; and f@y an iteration that results in
the candidate pattern elevated to the status of pattern -or its
rejection.
and what the particular context is surrounding
then this becomes a candidate pattern.
the probleq
In order to be a reusable pattern that is applicable to other
similar design problems, the example must fust be
genemlized. This generalization must be of both the
problem and the solution and describe the general relationship of the classesinvolved. The pattern can again be
classiiled by the variability it exemplifies and stored in a
pattern libraq or catalogue. If over time the solution as
implemented in a running system remains a good solution,
and if several other experts agree to the appropriatenessof
the problemkolution pair, then the candidate pattern can be
moved to the status of true pattern. This process is vexy
similar to what is happening in the patterns community
currently, but there, it is not supported by the domain
engineering process. As well, the importance of
identifying variants and invariants has not been expressed.
The domain engineering methods are important because
they representexisting processesfor identifying and
representing the commonality and variability that will
trigger the identification of patterns both existing and new.
We hypothesize that this is analogous to the domain
engineering approach in which groups of domain experts
with requisite variety are facilitated to develop a model of
the system context and domain structme. The techniques
of elicitation clustering, generalkmtiou and ordering are
mechanisms for the distillation of a sharedview of the
domain These models are both physical and mental. The
application of domain engineering practices, such as those
formulated in FODA, will enhancethe opportunity for
expedient discovery and evaluation of new design patterns.
Discovering New Patterns
by Gamma et.
As discussed above, patterns as exemplitled
al. [Garnrna94] identi@ common design problems, the
context in which the problem is couched, a solution to the
problem and a rationale for why the solution is appropriate.
It was also shown that each of the patterns varied some
class or concept within a group of collaborating classes. In
order to discover new patterns using domain analysis, we
must be able to produce each of these items as outputs.
Reuse-oriented domain engineering techniques currently
support identitlcation of stable and variable characteristics
of systems to be developed and could be used to identi&
most of what is necessary to identify candidate patterns.
But even those methods that reconunend attaching a record
of design decisions to features of systems, subsystems,
architectures or models, do not record the ratiomle for why
these decisions are there. That is, they do not describe why
a design solution is an appropriate solution. This
information is central to the idea of patterns and will need
to be added as an output.
Summary
In this paper we have observed that the process of identi&ing and evaluating patterns of solution variants and
invarirmts is based on experienced domain experts and a
process of induction through exploration of solution
instances. We betieve that a parallel, but hitherto disjoint,
approach in the field of domain engineering provides an
effective mechanism to develop context and domain models
which help achieve reusable and highly functional designs.
We hypothesize that the two approaches (patterns analysis,
domain analysis) aIE synergistic and that a conscious effort
should be made to combine the best of both processes. In
particular, we propose that the techniques of FODA should
facilitate the use of existing design patterns, and should
acceleratethe discovery and evaluation of new design
patterns, This will lead to an approach of “pattems-byintent” rather than by serendipity.
To make the discussion above more concrete, consider an
example of where the output from domain analysis might
help identi@ an existing design pattern to use, In this
example it is identitled that several different entities will be
calculating the same item say breaking a stream of text
into lines, but that each entity will use different algorithms
to do this. The commonality here is an algorithm for line
breaking, but it must vary for each different entity. With
this commonality and variability identile~
the Strategy
pattern becomes applicable as a way of implementing the
required algorithmic variability. The pattern will still need
to be assessed to decide if the context is similar enough
and the rationale is appropriate but the variability provides
a mechanism for finding an applicable pattern and should
be the key classifying item.
Biography
StevenFraser is on staff at Bell-Northern Research’s
Computing Research Laboratory in Ottawa. In 1994 Frasel
was on assignment in Pittsburgh at the Software
Engineering Institute (SEI) collaborating with the
Application of Software Models project on the development of domain engineering techniques. Fraser has
organized several workshops and a panel focusing on topics
related to team approachesto object-oriented design at the
annual ACM OOPSLA conference. Since joining BNR in
1987, Fraser has contributed to the ObjecTime project, an
00-based CASE-Design Tool and to the BNR BCS
software development process. Fraser completed his
doctoral studies at McGill University in Electrical
Engineering. He holds a Master’s degree from Queen’s
University at Kingston in applied Physics and a Bachelor’s
degree from McGill University in Physics and Computer
Science. Fraser is an avid photographer and opera buff.
IdentMcation of new candidate patterns will be triggered for
design problems for which there are no appropriate existing
patterns. In this case, for those items that must be varied in
~eference to some o~er entities as identitled through
domain analysis, a solution is chosen. If the solution is
chosen by an expert who has seen similar problems in the
past and who can explain why the solution is appropriate
223
References
[Alexander77]
DeborA Leishrnan is on staff at Bell-Northern Research in
Ottawa as a reuse specialist. Her current focus is on the
inter-relationships of system architectures, design patterns,
object-oriented technology and reuse in large systems
development. Leishman holds doctoral and masters
degrees in computer science, both from the University of
Calgary in the areas of artitlcial intelligence and design
reuse. Before coming to B~
Leishman held positions at
Hughes Aircrafl and the National Research Council of
Canada whe~ she worked on knowledge based systems and
reuse.
Christopher Alexander, SaraIshikawa,
Murray
Silverstei~
@2ser93]
Steven Fraser and Clifford Saunders.
“Enhanced Reuse with Group Decision
Support Systems”, in Advances in So@are
Reuse, IEEE
Computer
93 TH0495-2,
[Gamrna94]
et. al., A Pattern
Oxford University Press, 1977.
Language.
Erich
Gamma,
March
Society,
1993, pp. 168-175.
Richard
Hehn,
Ralph
Design
Patterns: Elements of ReusabIe ObjectOriented Sojlware, Addison-Wesley
Johnso~
Robert McLelkm is on staff at Bell-Northern Research’s
Computing Reseamh Laboratory in Ottawa. His current
focus is the application of reuse strategies for accelerated
product delivery, and the defiition
of underlying tools and
techniques. Since joining BNR in 1983 he has worked in
the areas of silicon desi~
silicon design automation
systems architecture and distributed object systems.
McLellan holds a Bachelor’s degree and a Master’s degree
from Queen’s University at Kingston.
and John Vlissides.
Professional Computing Series, New York,
1994.
&wwl
Kyo C. Kang, Sholom G. CoheL James A.
Hess, William E. Novak, and A. Spencer
Peterson. Feature-Oriented Domain
Analysis Feasibility
Study.
Software
Engineering Institute, Carnegie Mellon
University, CMU/SEI-90-TR-21, 1990.
~LoP94]
The Proceedings of PLoP’94. Robert
Allerton Park, Monticello, Illinois, August
4-6, 1994.
&94]
Wolfgang Pree. Design Patterns for
Object-Oriented
So~are
Development.
Addison-Wesley, New York, 1994.
224