Using Design Patterns
—
An observational study
COT/6-15
Eyðun Eli Jacobsen
The Maersk Institute for Production Technology
University of Southern Denmark/Odense University
Abstract
This report documents a case study in which the communication among software developers who are
using design patterns to develop software is in focus. A conceptual framework describing our view on
the software development process is presented and a set of research questions are posed in terms of
this conceptual framework. The study is carried out as an observational study in which the developers
are observed while designing a software system.
Preface
This report documents a case study in which the focus is on the communication between software
developers who are using design patterns to develop software. The case was a design process carried
out at the Danish Maritime Institute. The study was conducted by the author in the period November
1998 – February 1999.
Acknowledgements
We thank the Danish Maritime Institute for allowing us to study one of their design processes, and we
thank Palle Nowack and Bent Bruun Kristensen at The Maersk Institute for Production Technology at
University of Southern Denmark for reviewing the draft report and providing many fruitful comments.
Odense, Denmark
March, 1999
— E. E. J.
CONTENTS
1
Introduction
1.1 Motivation and Purpose of the Study . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Report outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Planned and actual study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3
3
4
2
Conceptual Framework
2.1 The Software Development Process. . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Analysis Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Design Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5
5
7
3
Research Questions and Study Design
3.1 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 The Design of the Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
10
11
4
Analysis and Interpretation
4.1 The Case Study Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
13
16
5
Conclusion
5.1 Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Method Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Study Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
20
21
22
A OMT diagram of the Winch
24
2
CHAPTER 1
Introduction
The Center for Information Technology (CIT) is a project initiated and funded by the by the Danish
government to increase the collaboration between industry and academia. A subproject of CIT is
Center for Object Technology (COT) which has object technology in focus. One specific part of COT
is the COT/6 project. The COT/6 has the Danish Maritime Institute as the industry part, and it has a
research group at The Maersk Institute for Production Technology at University of Southern Denmark
as the academic part.
1.1
Motivation and Purpose of the Study
The notion of Design Patterns [2] has taken a central position in object-oriented software development.
It is generally accepted that the use of design patterns facilitates the communication among software
developers, but there are no documented characteristics of how software developers communicate
when they design software. The provision of such knowledge is desirable from two perspectives,
namely education and tool support. From an educational perspective it is beneficial to understand how
design patterns affect the communication process among developers since this will enable the educator
to characterize design patterns in a process dimension in addition to a design-artifact dimension. From
a tool support perspective, one of the prerequisites is to understand how object oriented software
developers reason and communicate when using design patterns, because one of the central challenges
in designing tools is to make decisions on the division of labour between the tool and the tool user
(the software developer).
In summary we can say that we are not interested in evaluating a design process, but rather we are
interested in giving a qualitative description and interpretation of it — to highlight its most prominent
characteristics.
1.2
Report outline
The remaining chapters are as follows: In Chapter 2 we present the study’s conceptual framework
which contains a general model of a software development process. The conceptual framework is
used when we interpret the findings of the study. Chapter 3 contains the research questions and
the design of the study. The research questions represent our initial area of interest, but they do
3
not exclude any other interesting areas that might be revealed during the analysis. The findings are
presented in Chapter 4 by first giving a description of the observations and then an interpretation of
the observations. We address the research questions and a number of additional interesting issues.
Finally, in Chapter 5 we summarize our most important points, discuss the research method, and gives
a few remarks on the study as a whole.
1.3
Planned and actual study
As described in Section 1.1 we were at the outset interested in gaining knowledge on how designers
reason and communicate when using design patterns. But it turned out that with the given resources
(people and time) design patterns played a minor part in the design of the system. This of course affect
our findings, which therefore do not contain many observations nor conclusions on how developers
reason and communicate when using design pattern. We return to this issue in Section 5.3.
4
CHAPTER 2
Conceptual Framework
The main purpose of the analysis is to characterize the design process. In order to do this, we need a
conceptual framework in relation to which the design process is described and interpreted. Our conceptual framework is an overall model of the software development process. The model is described
in terms of various roles, domains, and processes.
The conceptual framework presented below is an extract of a more elaborate presentation which
is found in [4]. We have only included the aspects that are necessary in order to understand the
discussions and observations in this report.
2.1
The Software Development Process.
In our abstract, general description of the development process, we have chosen a certain perspective
on the process. The perspective includes the models and the domains which are involved in the overall
understanding of the development process. By the models in the process we refer to the different
kinds of models created during the process. Such a model reflects an understanding of a domain of
which we either conduct analytic or constructive work during the development process — we model
the domain. By domains we mean such domains identified and used during the software development
process. By our perspective we focus of these concepts in our abstract, general description. Modeling
is essential for the software development process — both models that support our understanding of
the logical phases of the process including the domains involved in this process, and models (of some
of these domains) that are produced during the process.
We focus on the analysis and design phases of the development process. The implementation,
testing, documentation and maintenance phases are not discussed in this presentation, although the
phases also are closely related to the models produced during analysis, design and implementation.
2.2
Analysis Phase
In the analysis phase the user and the developer closely cooperate to construct models of the problem
domain and the usage domain. This process is controlled by a system definition and the customer.
5
Object System
Objekt Model
Analysis Phase
Objekt System Usage System
Requirements
System
Definition
User
Developer
Analysis Phase
Customer
System
User
Problem Domain
Usage Model=
Usage System
Usage Domain
(a) Static Model of the Analysis Phase.
(b) Dynamic Model of the Analysis Phase.
Figure 2.1: Models of the Analysis Phase.
Analysis: Static Model. The following elements are involved in the analysis phase (most of these
are similar to those in the analysis model of [6]):
Definition: Problem Domain: The part of the surroundings, that is managed, monitored
or controlled by a system.
Definition: Object System: The user’s understanding of the problem domain —a mental
model.
Definition: Object Model = Model of Object System: The developer’s description of the
object system — developed through some given process, expressed in some given
notation, and seen from some chosen perspective.
Definition: Usage Domain: An organization that manages, monitors and controls a
problem domain, including the users.
Definition: Usage System: The user’s understanding of the usage domain — a mental
model.
Definition: Usage Model = Model of Usage System: The developer’s description of the
usage system — developed through some given process, expressed in some given
notation, and seen from some chosen perspective.
Definition: Analysis Model: Object Model & Usage Model.
Definition: System Definition: A definition and a delimitation of the problem domain
and the usage domain, that is stated and verified by the customer. It describes conditions and constraints for the resulting system, including the functional and the
non-functional requirements as well as the expectations to the execution platform.
Definition: System: A collection of hardware and software components, that realizes
the customer’s system definition.
Definition: Requirements (analysis): A set of requirements concerning the properties
and qualities of a system.
6
Domains, systems and models are involved: the (problem and usage) domains are parts of the
real world (physical or mental), the (problem and usage) systems are the user’s understanding of the
domains, whereas the (problem and usage) models are the developers description of the systems. Figure 2.1(a) illustrates the model of the analysis phase with the problem domain and the usage domain.
The object model forms the user’s understanding of the problem domain during his/her interaction
with the system. The usage model forms the user’s understanding of his/her interaction with the
system (to be) developed.
Analysis: Dynamic Model. Figure 2.1(b) illustrates the analysis process and the resulting models.
The process is controlled by the (static) system definition and the (dynamic) interaction with the
customer. An important part of this control is the perspective applied in the modeling process. The
overall perspective is that of the vision of the resulting system. The process is iterative@ — the dotted
lines indicate the feedback from the descriptions to the mental models. The iteration stops when the
user and the developer agree that the descriptions are usable and express a common understanding.
The dotted relation between the analysis arrows in Figure 2.1(b) symbolizes that the two analysis
parts have influence on each other. The actual contents of the analysis process of the problem domain
influences the analysis of the usage domain, and to a certain extent also vice versa. The results of the
analysis are the object model, the usage model and some additional requirements.
The nature of the work during the analysis phase is not purely analytic, but also constructive. In
object-oriented analysis we build models to represent the understanding of the problem and the usage
domains. This is one example on the fact that some design stimulates the analysis. Another example
is given by the preliminary design of graphical user interfaces, that is included in the analysis phase of
some methodologies. Such constructive elements may be essential for the communication and mutual
understanding between the user and the developer in the iterative cycle of the phase.
2.3
Design Phase
In the design phase the developer refines the object model and introduces an architecture model.
These parts are related, but an explicit and abstract description of the architecture model is essential.
The architecture model gives a supplementary perspective, is typically a partial model, is abstract in
the sense generalized and generic (parameterization), and describes the logical organization of the
system model and the (logical) execution platform. It describes which parts are distributed, which are
concurrent, which are to be persistent etc. to enable the developer to transform the object model into
a model that can support the use of the system, not only the understanding of it.
Design: Static Model.
The following elements are involved in the design phase:
Definition: Architecture Model: An abstract model over over the system model in the
software domain. The model focuses on (the organization of) the structure and
interaction embedded in the system model. The purpose is to understand the system
model given a structure/interaction perspective on that model, to allow us to reason
about and expose the support for the non-functional requirements, and to map the
system model onto the logical platform.
Definition: System Model: A refined, transformed and enriched object model. The system model also supports the usage of the system, and not only the conception of the
problem domain.
7
Objekt Model
Design Phase
System Model
Usage Model
Objekt Model Usage Model
Functional
Requirements
System Model
Non-functional
Requirements
Architecture Model
Developer
Design Phase
System
User
Usage Domain
Software Domain
Logical
Platform
Developer
(a) Static Model of the Design Phase.
Architecture
Model
(b) Dynamic Model of the Design Phase.
Figure 2.2: Models of the Design Phase.
Definition: Design Model: Architecture Model & System Model.
Definition: Software Domain (at the design level): Descriptions, partial or complete, of
some software. Various design notations are used.
Definition: Functional Requirements: A set of requirements concerning the capabilities
of a system—what the system should be able to support.
Definition: Non-Functional Requirements: A set of requirements concerning the nonfunctional qualities of a system—for example usability, understandability, security,
efficiency, reliability, maintainability, testability, flexibility, reusability, portability.
Definition: Logical Platform: A description of the platform on which the system is going to be executed but at a logical level—i.e. requirements in terms of user interface,
distribution, persistence and concurrency.
Definition: Requirements (design): The functional requirements, the non-functional
Requirements, and the logical platform.
The result of the design phase is not a model of some existing domain similar to the problem
domain or the usage domain1 . Rather, it is a unique design, something constructed and created by the
developer based on his skills and knowledge, and from the object model and the usage model. After
its construction the system model and the architecture model both work as models in addition to the
object model, but from a specific design perspective. Figure 2.2(a) illustrates the model of the design
phase with the usage domain and the software domain. The system model forms the developer’s
conception of the integration of the object and usage systems at an abstract level. The architecture
model forms the developer’s conception of the architecture of the system, i.e. the overall structures
and their relations and interactions.
1
It could possibly be seen as a model of a imaginary vision of the developer of the system, that he/she is going to design — assuming that the developer is able to envision such a design domain during his work, and from a chosen perspective
and through his/her understanding of the requirements actually forms the model.
8
Design: Dynamic Model. Figure 2.2(b) illustrates the design process, its inputs in the form of
models and requirements, and its resulting models. The dotted relation between the design arrows in
Figure 2.2(b) symbolizes that the two design parts have influence on each other. The system model
is constructed from the object model. The usage model is used during the design for controlling
the transformation of the object model into the system model. The usage model, together with the
functional requirements, supply the information for adding and distributing the functionality to the
object model to the extent that this information is not already there. The architecture is a constructive
solution for how the non-functional requirements and the organization of the logical platform can be
combined. The architecture model created by the design arrow at the bottom can have crucial effect
on the actual transformation at the top arrow.
9
CHAPTER 3
Research Questions and Study Design
In this chapter we present our research questions and the design of the study. The research questions
were formulated before the design process was started and therefore also before any observations
were made. The research questions represent our initial area of curiosity and also they represent our
preliminary beliefs that it is meaningful to discuss a design process in terms of these areas. The
research questions are used to bring some focus in what to observe during the design process. Our
primary area of interest is how developers communicate and reason with design patterns, but we
believe that it will be difficult to avoid the other areas when observing and analyzing the process, and
therefore they are included as research questions.
Since the research questions represent our initial beliefs about interesting aspects of a design
process, it might be inconvenient to structure our findings strictly according to the research questions,
and therefore we will not commit our selves to give answers directly to these questions, but rather
we will highlight the most prominent characteristics of the design process and in this way indirectly
provide answers to the research questions.
3.1
Research Questions
The research questions will be asked in terms of the conceptual framework described in Chapter 2.
Domains The notion of a domain is central in our conceptual framework. The question is which
domains are explored in the design process and when are they explored. A subquestion here
is concerned with the relation between the problem domain and the use of design patterns: to
which extent is the problem domain explored while the design is discussed in terms of design
patterns.
Interfaces A class’s interface is important since it reflects the designers understanding of the class,
the class’s responsibility and interaction with other classes. How and when are interfaces discussed during the design process.
Architecture One aspect of software design is an overall understanding of a specific software system,
and this is what we think of when using the word architecture here. Such an understanding is
10
relevant in several cases. One case is the maintenance-situation of a system where an overall understanding of the software system helps the developer to be aware of and to understand various
relations among different parts of the system. Another case is that it is believed that an architecture model is better suited for reasoning about Non-Functional-Requirements (NFR) than conventional design models (class diagrams and interaction diagrams). Delta’s ([5]), change-cases
are perhaps easier to assess when an architecture model is the starting point of the discussion.
The question is then how, when, and to which extent these issues (architecture model, NFRs)
are incorporated in then the design process.
Modelling versus technique Which forces lead to a decision to use or not to use a given design
pattern or design alternative? Is it considerations regarding modeling or is it considerations
regarding some technical aspect (e.g. performance), or something else. A part of this question
is whether the question itself makes sense, i.e. does it make sense to separate the forces into
modeling and technical?
How do designers reason with design patterns It is interesting to find out how software designers
communicate when using design patterns. We do not have any subquestion to this question, and
this reflects that our knowledge of this subject is very preliminary.
Below we have pinned out the questions embodied in the text above. Although some of the
questions are formulated in a closed-style manner they are intended to be answered in a nuanced way.
Area
Domains
Interfaces
Architecture
Design forces
Design Patterns
3.2
Table 3.1: Research questions, pinned out
Question
Which domains are explored in the design process
Do we discuss the problem domain while we discuss the
design in terms of design patterns
Are interfaces discussed during the design process
In any kind of architectural vision used as basis when discussing the system’s non-functional requirements.
Which forces influence a decision to use or not to use a
given design alternative
How do designers reason with design patterns
The Design of the Study
We want to investigate a process and to give characteristics of this process. Qualitative Methods are
well suited for this kind of inquiry, since we do not yet know what we are searching for and because
any kind of measurement of design processes, like the ones we are interested in, has to be derived
from qualitative data.
The resources on the research-side consist of one researcher, who plays the role of data-collector,
analyzer, and presenter of the findings. On the industry-side we have 2–3 persons who design a
software artifact.
The only data-collection we perform is direct observation, since there are no documents describing
the process, and since the time-constraints do not permit us to design and conduct open-ended in-depth
interviews with the designers.
11
Figure 3.1: A characterization of the Observation Method (dimensions are from [7]).
Characteristics of the Observation Method. The researcher will be a participant-observer with
most of the participation in the beginning and least participation in towards the end of the study, since
this will allow the researcher to be trusted by the designers, and hence the researchers presence will
not make the process artificial.
The fact that the process will be observed has been made clear to the designers, so everybody
involved knows that the sessions will be observed.
The purpose of the observations has also been explained to the designers, our preliminary theses
about the process have not been revealed to the designers because we do not want them to relate to
these theses in their work — they should work in their usual ways.
The number of observation sessions were four, each one between one half day and one full day.
The observations took place during five weeks. Communication when using design patterns is in
focus, but the designed product is not.
In Figure 3.1 we have illustrated our observation study along five dimensions.
12
CHAPTER 4
Analysis and Interpretation
In this chapter we present our findings of the study. The chapter is split into two parts; the first part
contains the case study narrative (Section 4.1), which is a description of the design process, and the
second part contains our answers to the research questions (Section 3.1) — the answers are on the
form of interpretations of the design process.
4.1
The Case Study Narrative
In this section we present the case study narrative, which is a holistic description of the design process.
The narrative is based on the raw case data, and it is organized chronologically. The narrative is
descriptive rather than interpretative.
Terminology. Three designers, X, Y, and Z, are present. When the word ‘we’ occurs in
the narrative it denotes the designers as a group, and it reflects the fact that the researcher
has made an observation on the group as a whole.
The physical environment. We are sitting in a room with two tables in the middle, the
tables are large enough for two persons on each of four sides of the table. X says that the
room is a small room “... vi skal ind i det lille hummer ...”. On one of the walls there is a
white board approximately 120x80cm.
First meeting. We start the meeting by looking at the preliminary report that is written
by X. The OMT-diagram in the document “Design specifikation” is the starting point for
our discussions. The diagram consists of a set of classes bearing the names of central
concepts in the problem domain. The classes are not equipped with attributes nor methods. Z draws various elements such as a drum, a brake, and engine in order to understand
these. The discussions about drums, brakes, wires, and engines are often explored and
settled by references to Newton’s laws in mechanical physics. Y discusses whether wire
should be a “rich object” that can consist of several materials, or whether wire should
be an attribute somewhere. We agree that wire should be a composite object since it can
consist of several materials, such as chain, shackles, and wire. Z draws a winch object,
which encapsulates drum, wire, brake, and engine — a preliminary interface, which is
based on a few obvious operations such as takeTimeStep and calcState, is assigned to the
13
winch class. A time-step, which is a central notion in simulator software, is discussed by
investigating a call-sequence of the methods on the involved objects: the drum calculates
a time-step, it asks the wire, the brake, and the engine about the forces they enforce on
the drum, and on the basis of this the drum calculates its angular speed.
We now discuss how the wire is placed on the drum. X draws on the white board how
the wire is placed on the drum and how to control the placement of the wire. X points
out that we must know where on the drum the wire enforces its force, but we should not
model that the wire might cut its way through several layers of wire already on the drum
if these layers of wire have not been properly been put on the drum. X continues, and
says that we should prepare for changing the drum system at a later point in time because
we might want a richer and more reality-like simulation. X says that we ought be able
to benefit form using some pattern (“... der må være et mønster, som kan hjælpe os med
det.”)
Y elaborates on how the wire should be represented on the drum, and suggests that the
wire is represented as a number of layers where only the topmost layer is visible. Y
suggests that we introduce a drum history object whose responsibility is to maintain the
information about how much of the wire is on the drum and how much of the drums
diameter the wire occupies.
Z asks whether we have covered all the functionality, on an abstract level, in the winch.
X says that there is also a regulator involved, and that it is similar to a cruise-control in a
car. Z asks if a regulator is a conceptually simple thing or not. X replies that the regulator
is conceptually simple, but that the realization of regulators are not simple.
We discuss how many winches there are going to be present in the simulator, and if
various winches are instances of the same model of if they are instances of different
models.
Y says that we should have a firmer structure in the drawing because otherwise Y doesn’t
feel that there is a proper flow between the parts.
Second meeting. X is not present before noon. The brake is the focal point before noon.
We are discussing how the friction forces are to be modelled. We divide the situation
into two parts. One part is concerned with the case when the drum is spinning and the
other case is concerned with the case when the drum is not spinning. We discuss whether
“getForce” on the brake class should have some kind of state-object as input-parameter.
Specializations of the brake class can then use specializations of the state-object. We have
introduced two parallel inheritance-hierarchies Brake and BrakeEnvir. Y suggest that we
terminate the discussions on the friction forces since we do not know much about how to
model friction forces in brakes. We discussed that the “getForce” method is a templatemethod (design pattern) with two hook-methods. The hook-methods would reflect the
fact that there are two different ways of calculating the brake force.
We are now discussing the engine class. Y says he doesn’t think that flexibility is good
for the sake of flexibility. The context is that we are discussing whether to let some
of the formal parameters in the parameter list of a method be qualified by an abstract
class or to let the parameter list contain more formal parameters covering several not yet
conceived specializations of the abstract class. We choose that the “getForce” method on
the engine class should have a fixed parameter list without the possibility of extending
some of the parameters in subclasses. On the other hand we want getForce to return a
14
composite value, which can be specialized in subclasses of the engine class. X says that
we probably will be using the state-pattern, because we need a stopped engine, a running
engine, and maybe an engine which is hoisting is different from one that is not hoisting.
The discussion shifts toward the integrator. X says that maybe we can have a central integrator, one that solves differential equations for all the parts in the system. Our understanding of an integrator is diffuse and we are misunderstanding each other for a while. X
says that he doesn’t know how the integrator is in relation to the rest of the UML-diagram.
We discuss, on an abstract level, that we might need integrators that have different tradeoffs in performance and precision. Y says that we should not use the strategy-pattern to
realize the various integrators, because the strategy-pattern focuses on run-time flexibility
which we don’t need, instead we should use templates. X says that another reason that
we should not use the strategy-pattern is that the various integrators will need different
parameter lists and hence the strategy-pattern can not be used.
Third meeting. We are discussing how we should accommodate the need for a regulator.
Our first attempt says that the engine object should know the regulator object. The regulator receives the desired speed or force, and then the regulator should adjust the engine
controls. Y draws an inheritance hierarchy containing various regulators. The abstract
regulator has a method “regulate” which has desired speed and measured speed a parameters, and as a result it delivers the position of the speeder handle. We discus what happens
when the operator activates a regulator. One way to do things is to create a regulatorobject which through its constructor receives a constant that specifies the desired speed
or force. X says that we can have one big regulator object that knows of several kinds
of regulator objects for various purposes. Essentially we are designing how a specific
regulator will be chosen and activated. X writes switch-statements on the white board.
The statements express when the safety-regulator should be activated.
Y suggests that we simulate the method-call sequence in order to find out, how the regulator fits in to the already existing design. X and Y are discussing whether a specific
piece of code should be in the winch or in the engine — they also discuss parameter passing. We discuss whether the activation of the safety-regulator should be in the method
“winch.takeTimeStep” or in method “engine.calcstate”. We also discuss how we should
model the engine —from a physical perspective or from a more conceptual perspective?
The discussions end up with two classes: a safety regulator and a speed regulator. The
safety regulator should be activated in the engine.
Fourth meeting.
This meeting was a sum up meeting with a fourth person. During this meeting we did not
design further on the winch-system. A general model of simulating physical system was
presented by the fourth person. This model basically contains a driving mechanism and
a set of devices which do various calculations. The question is how the winch-design fits
into the general model of physical simulations. There are two ways to do this. One way
is to let the winch-design be one device, and in this case the design is probably useful in
its current form. The other way is to model the winch in a set of devices, and in this case
the current design is not useful. The initial knowledge of the winch-simulation obtained
during its design will however be useful as background knowledge.
15
4.2
Interpretation
In this section we try to answer the research questions posed in Section 3.1. We have tried to structure
the paragraphs in such a way that they begin with an observation part first and they end with an
explanation or speculation part.
Domains. The overall impression of the design sessions is that the problem domain was the primary
focus area, while the software domain was not deeply discussed.
The problem domain was explored by drawing classes and discussing the interactions among their
objects. The classes were informally specified, and the interactions among their objects were often
discussed before any decisions regarding specific methods were made. The dynamic aspect of the
problem domain was often expressed with switch-statements and other pseudo code similar to the
programming language (C++). The classes, which represent concepts in the problem domain, were
found by general discussions of how the winch operators (personnel) understand their work. The
relations between the classes were often decided upon by references to Newton’s laws in mechanical
physics. This illustrates that it is crucial to have domain knowledge in order to be able to model the
domain. This sounds obvious, but the example illustrates that the modeling task in the beginning is
not about being a fluent UML-modeler, but rather it is about exploring the problem domain in its own
terms.
For some of the relevant concepts we had not enough information to make a relevant and useful model of the concept; instead the concept was postponed by encapsulating it in a class with no
attributes and not methods; the concept of ‘wire’ is an example of this.
Variations in the problem domain were addressed directly in some cases. We knew that there were
several kinds of brakes and therefore we designed the brake class on a general level with our attention
to later specializations. This resulted in general methods in the classes for doing various calculations;
the methods ended up with being similar to the template method (design pattern). The brake class was
designed, and at some point in time we realized that this was similar to the template method design
pattern, and then we deliberately designed the brake class in accordance to the template method design
pattern. My best guess is that after a while our attention moves away from the physical aspects of the
brake, and then we are able to see the similarity to the template method design pattern.
A part of our modeling of the problem domain was done by writing switch-statements which
express something about the domain, i.e. some construction in the implementation language is used
when exploring the problem domain. Pseudo code1 is also used when we wanted to do a recapitulation
on the design. The following quote, which is taken from the third meeting, illustrates this point.
... skal vi skrive noget pseudokode for at se hvad der er sket siden sidst ...
We make a walk-through the call-sequence through the whole system, including the regulators.
This kind of modeling seems technical at first glance. A method-call is basically a transfer of control,
possibly together with some data, and underlying this is the same conceptual framework that underlies
parts of the notion of use-cases. If, however, all the time is spent on struggling with the syntax of the
notation, then we have lost our original focus (interaction) and instead picked up the detail of the
notation as our focus. Although the terminology (switch-statements and method-calls) might seem
very low-level and technical, it doesn’t mean that it is low-level and technical modelling. In the
case of a switch-statement we note that the notion of selection is underlying the switch-statement,
and selection is fundamental in almost every modeling situation. The notation and terminology are
1
Pseudo code corresponds to the implementation language, but strict syntactical and semantical precision is not required.
16
manifestations of a conceptual framework which has many other manifestations that aren’t perceived
to be technical and low-level.
The only discussions on how to organize some classes were concerned about where to put a
specific piece of code (the code to activate a regulator) — should it be placed in the winch-class or
should it be placed in the engine-class? These issues were discussed as a question of software design
and not as a question of modeling the problem domain. I.e. from the perspective of the problem
domain we were not able to put forward any arguments in favor of either alternative. This is perhaps
not surprising since the the selector code was not easily seen as a natural part of any of the classes
representing concepts from the problem domain.
Interfaces. Interface design was not addressed deeply. Interfaces were designed in an incremental
manner; the method names came first together with informal parameters. Interfaces did not have an
existence in themselves — there were just methods on classes. One reason for this can be the fact that
the software design did not reach a state where it could be used as a specification for an implementation. Generally, the notion of interfaces is, due to the popularity of certain programming languages
(e.g. Java [1] and Smalltalk [3]) and component models (COM and CORBA), getting increasingly
used as a specification for some behaviors — classes/components should support certain interfaces. It
was this circumstance that generated the question about interfaces. Interfaces represent some general
notion of behavior or service, and we believe that the software design has to have reached a certain
level of maturity before interfaces that represent some coherent whole can be identified and defined.
Or, the other way around, we believe that the reason why we did not discuss interfaces was that the
design did not reach a sufficient level of maturity.
Architecture. Only the context of the system was discussed, i.e. we discussed that the system was
going to be a device on an ethernet network and it would communicate via some messages with another system (hardware and display). Dedicated architecture discussions were not present during the
design sessions. We believe that the reason why this did not happen was that the group’s knowledge architecture was insufficient and because we did not design enough software which would have
allowed us to discuss architecture based on some concrete and tangible software.
Design forces On what basis are decisions made on a particular part of the design? From our
observations we did identify only one dimension along which to place a specific part of the design.
Again, we believe the reason to be that the design process did not to a sufficient degree take place in
the software domain. Below we describe the identified dimension.
In many cases we describe concepts from the problem domain as classes in some generalizationspecialization hierarchy. But in some cases, particularly in parameter lists, it seems more natural
to flatten a hierarchy into a sequence of attributes. The situations occurred when we should decide
the parameter list of a virtual method of a class in a generalization hierarchy. The method will be
overridden in subclasses, and in different subclasses we need different parameters. How should we
design this? Should we let the method have formal parameters for every conceivable value it needs in
the various subclasses? Or should we introduce a new class hierarchy, which is parallel to the existing
hierarchy, and let the virtual method have one formal parameter, which is qualified by a class in the
new hierarchy, and let there be co-variance between this parameter and its enclosing class?
We think that the answer to what to do, can partly be found when considering the background of
the developers — it is a question of when and where a developer thinks that a part of the software
17
design is complex. In the case of the parameter list of the virtual method we had the case that one of
the developers claimed that the parallel class hierarchy was flexibility for the sake of flexibility.
... jeg ved ikke om fleksibilitet er godt for fleksibilitetns skyld. hvis getForce(....) giver
mening så er det ikke nødvendigt at have flere hierarkier...
The developer thinks that the virtual method is meaningful with all of its parameters. In the case
of the return value of the virtual method we chose the design alternative with a new class hierarchy —
in this case there was too much variation in return results that we could have one kind of return result
which covered all types of return values.
We believe that this is because of the structured programming background of the developers,
which implies that the developers, who have little experience with inheritance hierarchies, experience
an inheritance hierarchy relatively more complex than a parameter list that contains unrelated sets of
parameters. I.e. if one is trained in structured programming then long parameter lists are not complicated, because it is a standard way of encapsulating many things in one procedure, and likewise several
classes deviating only with respect to a few variables are seen as a complexity-increasing element. On
the other hand, if one is experienced with object-oriented programming then long parameter-lists are
seen as a sign of unclarity (lack of structure) and hence complexity-increasing, and classes addressing
the same problem as the long parameter-lists are not seen as complexity-increasing elements.
Apart from the above discussion on inheritance hierarchies versus long parameter lists there were
no identifiable forces inflicting on the design.
Reasoning with design patterns. There were a few incidents were design patterns were mentioned.
One of these can be characterized as “variation in the problem domain is addressed by a design
pattern.” Two clear examples of this situation were experienced during the design sessions. The
first example, which did not make its way to the design, is the realization of the fact that a part of
problem domain can be can be modeled by using states and therefore the state design pattern is an
obvious pattern for the design solution. The specific example of this was the modeling of the engine
concept.
... jeg tror at vi kommer til at bruge state-mønstret. fx vi har brug for en stoppet motor,
en kørende motor, en motor der hiver ind er måske foskellig fra en motor der giver ud...
The second example, which did not make it to the final design either, was regarding the drumsystem of the design. We realize that there could be several kinds of drums with various characteristics.
... vi skal forberede os på at skifte tromlesystemet ud så det senere kan vise os et mere
nuanceret billede af situationen - der må være et mønster, som kan hjælpe os med det...
The two examples above illustrate that some of the developers associate variation in the problem
domain to the use of design patterns. But none of the relevant design patterns were used in the
design. We believe that the reason is that the designers were doing analysis activities, i.e. they were
exploring the problem domain and at this point in time not seriously addressing the design-side of
the problem. Deep design-considerations, where we investigate the characteristics of the design, were
not conducted, and we regard the progress of the project to be the reason — we did not have enough
insight on the domain and the requirements in order to design the system.
18
Although not explicitly mentioned, there were at least one situation where a certain way to design a part of the system was organized according to a well known design idea (the client-server
pattern/idea2 ). The example is the design of the integration functionality. Simulation systems need
to calculate values for the next time-step for many simulation objects. The question is whether each
simulation object should be capable of calculating its own values or whether it should delegate its calculation to some other object. One of the designers suggested that we should have a central integrator
that could calculate values on requests from simulation objects.
... vi kan have en central integrator som beregner differentialligninger...
This is essentially the idea of client–server, where the simulation objects are the clients and the
integrator is the server. This is an example of a situation where a design idea is used anonymously, i.e.
it is used without reference to its name. We interpret this situation to manifest that some design-ideas
are present in the designers’s minds but its specific form and context has not crystallized into a pattern
(yet).
One situation occurred where we discussed whether we should use a design pattern or not in
terms of its provided flexibility. The example was some initialization of the system and we discussed
whether or not to use the strategy pattern.
... strategy skal ikke bruges fordi en forkuserer på runtime fleksibilitet, men vi har brug
for templates...
In summary we note the following about the use of design patterns. They are at a general level
associated to variation in the problem domain, and therefore the usage of design patterns can be
characterized as being a declaration of potential future use. Some of the design ideas behind a design
pattern are known to the designers, but no name is associated to it, and therefore a pattern can be
applied anonymously.
2
We use the notion of a design idea to indicate that client/server is not a part of the catalog in [2].
19
CHAPTER 5
Conclusion
In this chapter we summarize our most important points (Section 5.1), discuss the study design and
data collection (Section 5.2), and we give a few comments on the study as a whole (Section 5.3).
5.1
Observations
Below we give a short description of our most important findings. They are not meant as direct
answers to the research questions, but rather as prominent characteristics of the process and indirectly
as answers to the research questions.
Exploring the problem domain Newton’s laws in mechanical physics are used. This illustrates that
it is crucial to have domain knowledge in order to be able to model the domain. This sounds
obvious, but the example illustrates that the modeling task in the beginning is not about being a
fluent UML-modeler, but rather it is about exploring the problem domain in its own terms.
Exploring with the programming language The dynamic aspects of the problem domain are often
expressed using pseudo code (switch-statements and method-calls) similar to the programming
language. Although it seems to be a very technical way of exploring the problem domain it isn’t
necessarily so, because the elements of the pseudo code are founded on a general understanding
of dynamics, namely selections and sequences of imperatives. If the pseudo code is used freely
so that the notions of selection and sequence are dominant — as in the design process — then
this kind of modeling is not technical, in the sense that it is dependent on the programming
language.
Origin of rationales We note that some parts of the design can be well argued for in terms of the
problem domain (concepts and interactions), while some parts of the design, such as a specific
piece of code, can not be argued for in terms of the problem domain. The placement of the code
is not really discussed in other terms than those of the problem domain. The placement of a
piece of code is not discussed in terms of the software domain (certain styles or other software
characteristics such as flexibility, performance, modifiability).
Architecture and Interfaces On these issues we have not obtained insights, we can only note that
the issues were not addressed neither explicitly nor implicitly. We believe the reason to be
20
that the group’s knowledge architecture is insufficient and because we did not design enough
software which would have allowed us to discuss architecture based on some concrete and
tangible software.
Design Patterns Patterns are associated to variability in the problem domain. Situations where patterns potentially can be use in the future are identified from the problem domain. We saw one
example of a pattern being used anonymously — meaning that its idea is known, but not its
name. During the design process patterns are not really used — in the sense that their cons and
pros are discussed with offspring in the specific circumstances.
Complexity depends on the developer’s background Developers with different backgrounds tend
to experience complexity differently. The example is the discussion on parameter lists versus
inheritance hierarchies. We propose that the different background (structured programming
and object-oriented) of the developers can be seen as one explanation for this phenomena. But
the suggestion is not well supported, so it should not be considered to be anything else than a
suggestion.
Implementation as a proof of concept The design was implemented to see whether it was a way to
realize the forthcoming simulation system. Implementations are often seen as proofs of concepts. It is, however, important to consider whether an implementation is a proof of analysisconcepts or design-concepts. The difference is that while a proof of analysis-concepts validates
whether or not the model is sufficiently rich with respect to information and services, the proof
of design-concepts validates that a specific design which selects specific trade-off is implementable. The implementation of the simulation system was in our view a proof of analysisconcepts — checking whether the model of the problem domain was sufficiently rich to carry
out a simulation.
5.2
Method Discussion
We make the following remarks about the reliability1 and the validity2 of the study.
The study is characterized by having one researcher who has performed both the data-collection
and the analysis, i.e. the study has no triangulation, not in data-collection, not in analysis, and not
in conceptual frameworks for interpretation. The researcher is not an experienced observer, but the
preparation has been extensive, so we judge this to be a minor weakness in the observational data.
Only one method of data-collection has taken place. We don’t consider this a weakness, since the study
has been a study of verbal communication, i.e. no other source of data could have shed additional light
on the subject. Furthermore none of the participants seems to have any motive for behaving differently
when being an object in this study, so we think that the communication that has taken place is genuine
(and this is also the observer’s impression).
The conceptual framework in terms of which the data have been interpreted is to a large extent
agreed upon by several research communities. Also we believe that the conceptual framework because
of its general nature has not narrowed down the findings from this study.
The major weakness of the study is that only one researcher has performed the analysis, and hence
there is a risk that some findings are undiscovered and that others are given too much confidence.
Altogether we consider the study to have a medium reliability and validity.
1
2
Reliability is regarding the data-collection
Validity is regarding the interpretation of the data
21
5.3
Study Evaluation
The study had as goal the communication of how developers communicate using design patterns. The
profile of the developers is that they are fairly new to advanced object-oriented technology, which
means that the work with design patterns has to be grounded in concrete and tangible software. Unfortunately, the development project did not reach a stage where there was sufficient concrete software
to discuss before the study project had to be carried to completion — in other words the study project
experienced some unfortunate timing.
As a consequence of the timing issue, the focus in this report has been put on other but related
subjects, and from this a number of interesting results or claims have emerged.
22
BIBLIOGRAPHY
[1] Ken Arnold and James Gosling. The JAVA Programming Language. The Java Series. AddisonWesley, Reading, Massachusetts, second edition, 1996.
[2] Erich Gamma, Richard Helm, Ralph E. Johnson, and John Vlissides. Design Patterns Elements
of Reusable Object-Oriented Software. Addison-Wesley, 1995.
[3] Adele Goldberg and David Robson. Smalltalk-80 The Language and its Implementation. Computer Science. Addison-Wesley, Reading, Massachusetts, first edition, 1983. ISBN 0-201-113716.
[4] Eyðun Eli Jacobsen, Bent B. Kristensen, and Palle Nowack. Models, Domains, and Abstraction
in Software Development. In Proceedings of the 27th International Conference on Technology of
Object-Oriented Languages and Systems (TOOLS ASIA ’98). IEEE Computer Society, September
1998.
[5] Eyðun Eli Jacobsen, Bent B. Kristensen, and Palle Nowack. The software evolution process:
Architecture and abstraction. The Maersk Mc-Kinney Moller Institute for Production Technolo
gy, University of Sourthern Denmark., 1999.
[6] Lars Mathiassen, Andreas Munk-Madsen, Peter Axel Nielsen, and Jan Stage. Objektorienteret
Analyse og Design (In Danish). Marko, 1997.
[7] Michael Quinn Patton. Qualitative Evaluation and Research Methods. SAGE Publications, second edition, 1990.
23
APPENDIX A
OMT diagram of the Winch
The class diagram for the Winch is illustrated in Figure A.1.
Figure A.1: The class diagram of the winch system in OMT notation.
24