Composable Objects with Multiple Views and Layering - trese ...

Universiteit Twente
De ondernemende
universiteit
Composable Objects
with Multiple Views
and Layering
Graduation Committee
Dr. ir. M. Aksit
Dr. ir. K.G. van den Berg
Dr. P.M. van den Broek
Ing. R.R. van de Stadt
S.G. de Bruijn, March 1998
MSc. Thesis at the Department of Computer Science
University of Twente, Department of Computer Science, SETI, TRESE

Abstract
When software systems were becoming too complex, people developed the
object-oriented model. It enabled them to build pieces of software more or less
independent from each other. This resulted in better understandable systems
which were easier to maintain.
The use of the object-oriented model has solved a lot of architectural
problems, but the experience in using the model drives us further: We now
want to enrich our software models with more problem-domain properties, by
making these properties explicit. This enables us to represent these properties
more precisely, making software systems even better understandable and
maintainable.
Introducing problem-domain properties in a software model should not
interfere with the already existing elements of this model. This is often not true
however. In this thesis, we presenttwo modelling issues. We give our de nition of
the issues, and try to discuss them using a traditional object-oriented language.
In doing so, we encounter a lot of problems, and nally must conclude that
expressing the presented modelling issues in a language like C ++ cannot be
done in a fully satisfactory way.
Next to a traditional object-oriented language, we also use the modelling
issues in a next-generation object-oriented language called Sina. This language
is based on an enhanced object-oriented model, basically enabling the software
engineer to handle and manipulate message calls between objects explicitly. We
will see that with the Composition Filters Object Model, as the enhanced model
is called, it is perfectly possible to express the presented modelling issues in a
natural way, while preserving all the properties of the object-oriented model.
Next to using modelling issues in software systems, it is also important
to record them for later reuse. A Software Design Pattern has proved to
be an e cient medium for the propagation of modelling knowledge. When we
try to present our modelling issues as design patterns however, we discover
that Gamma, Helm, Johnson and Vlissides's (1995) pattern scheme is not rich
enough to express our modelling issues. In this thesis, we extend this Design
Pattern notation, and represent our design issues using this extended notation.

Samenvatting
Toen softwaresystemen te complex werden, ontstond het object-georienteerde
model. Dit model stelde de softwareontwikkelaars in staat om softwaresystemen
te bouwen die bestonden uit een aantal min of meer onafhankelijke bouwstenen.
Deze opzet resulteerde in systemen die beter te begrijpen en te onderhouden
waren.
Door het gebruik van object-georienteerde technieken zijn veel problemen
in de softwarebouw met betrekking tot de interne architectuur opgelost. Nu
men daar wat meer ervaring mee heeft, is het gewenst om meer voordeel uit
de inzet van deze technieken te halen. We willen de eigenschappen van het
probleemdomein van de software explicieter gaan modelleren. Dit geeft meer
inzicht in de materie dan de \normale" impliciete modellering. Tevens leidt dit
tot beter inzichtelijke softwaresystemen die ook beter te onderhouden zijn.
Wanneer we het probleemdomein expliciet gaan modelleren, mag dit uiteraard
niet in strijd zijn met reeds aanwezige softwaremodellen. Vaak blijkt
echter dat dit juist wel het geval is. In dit afstudeerverslag presenteren we twee
modelleringskwesties. We geven de door ons gebruikte de nities en proberen
de modellen in een normale object-georienteerde taal te realiseren. We komen
hierbij veel problemen tegen die niet eenvoudig oplosbaar blijken en uiteindelijk
moeten we tot de conclusie komen dat het niet mogelijk is om probleemdomeinen
op een acceptabele wijze expliciet in een object-georienteerde taal als C ++
te realiseren.
Naast realisatie in een normale object-georienteerde taal, bouwen we ook
modellen voor dezelfde modelleringskwesties in de moderne object-georienteerde
taal Sina. Deze taal is gebaseerd op een verbeterd objectmodel dat in principe
de software engineer de middelen geeft om methode-aanroepen expliciet af te
handelen en ze te manipuleren. We zullen laten zien dat met dit Compositie
Filters Object Model de gepresenteerde modelleringskwesties uitstekend zijn
te realiseren, zonder de oorspronkelijke voordelen van het object-georienteerde
model te verliezen.
Wanneer modelleringskwesties goed zijn uitgewerkt in afgebakende modellen,
zijn ze in principe geschikt om later opnieuw te worden ingezet in een
ander softwaresysteem. Software Design Patterns blijken tot op heden een e ectieve
notatie voor dergelijke modelleringskennis en -ervaring te zijn. De notatie
van (Gamma et al. 1995) is geent op het normale object model en blijkt tekort
te schieten wanneer we onze oplossingen uitgedrukt in het Compositie
Filters Object Model willen presenteren. Daarom geven we in dit verslag ook
een aanpassing van de Design Pattern notatie en drukken hierin de door ons
aangedragen modellen uit.

Preface
You would not be reading this if I had not received the unlimited patience that
my family, my friends, my graduation committee and, last but not least, my
employer gave me.
Thank you all.
S.G. de Bruijn
March 1998, Laren{NH

Contents
1 Introduction 1
1.1 Project boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Structure of this thesis . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Background and related work 7
2.1 Object models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Conventional Object Model . . . . . . . . . . . . . . . . . 7
2.1.2 Composition Filters Object Model . . . . . . . . . . . . . 8
2.2 Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Position of this work in the TRESE project . . . . . . . . . . . . 10
3 Modelling Issue: Multiple Views 11
3.1 Modelling Multiple Views . . . . . . . . . . . . . . . . . . . . . . 11
3.1.1 What is a View? . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.2 Conceptual View Model . . . . . . . . . . . . . . . . . . . 14
3.1.3 Scenario of Changes . . . . . . . . . . . . . . . . . . . . . 17
3.2 C ++ Implementation . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.1 Simple Mail System . . . . . . . . . . . . . . . . . . . . . 22
3.2.2 Add Views: UserSystemView Mail System . . . . . . . . . 24
3.2.3 View Partitioning: OriginatorReceiverView Mail System . 26
3.2.4 View Extension: Group Mail System . . . . . . . . . . . . 28
3.2.5 Dynamic Behaviour Extension: Secure Mail System . . . 30
3.2.6 Static Meta Behaviour Extension: Warning2 Mail System 31
3.2.7 View Composition: Protected Mail System . . . . . . . . 34
3.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4 Modelling Issue: Layering 39
4.1 Modelling Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.1 What is Layering? . . . . . . . . . . . . . . . . . . . . . . 39
4.1.2 Conceptual Layering Model . . . . . . . . . . . . . . . . . 42
4.1.3 Scenario of Changes . . . . . . . . . . . . . . . . . . . . . 49
4.2 C ++ implementation . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2.1 Add Methods: Heading Mail System . . . . . . . . . . . . 51
4.2.2 Rede ne Methods: Attachment Mail System . . . . . . . . 53
i

ii Contents
4.2.3 Extend Methods: ReadNoti cation Mail System . . . . . 53
4.2.4 Add Object-Orthogonal Behaviour: History Mail System . 55
4.2.5 Dynamic Layering: Dynamic Mail System . . . . . . . . . 56
4.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5 Composition Filters Solutions for the Modelling Issues 61
5.1 The Sina Language . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2 Multiple Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2.1 Simple Mail System . . . . . . . . . . . . . . . . . . . . . 62
5.2.2 Add Views: UserSystemView Mail System . . . . . . . . . 62
5.2.3 View Partitioning: OriginatorReceiverView Mail System . 64
5.2.4 View Extension: Group Mail System . . . . . . . . . . . . 67
5.2.5 Dynamic Behaviour Extension: Secure Mail System . . . 68
5.2.6 Static Meta Behaviour Extension: Warning2 Mail System 68
5.2.7 View Composition: Protected Mail System . . . . . . . . 68
5.3 Layering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.3.1 Add Methods: Heading Mail System . . . . . . . . . . . . 70
5.3.2 Rede ne Methods: Attachment Mail System . . . . . . . . 70
5.3.3 Extend Methods: ReadNoti cation Mail System . . . . . 70
5.3.4 Add Object-Orthogonal Behaviour: History Mail System . 71
5.3.5 Dynamic Layering: Dynamic Mail System . . . . . . . . . 72
5.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6 Composable Models Presented as Design Patterns 75
6.1 Enabling Design Patterns to Present Composable Models . . . . 75
6.2 Design Pattern: Composable Multiple Object Views . . . . . . . 80
6.3 Design Pattern: Composable Object Layering . . . . . . . . . . . 85
6.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7 Conclusions and Future Work 93
7.1 Comparison of the C ++ and the Sina implementations . . . . . . 93
7.1.1 Multiple Views . . . . . . . . . . . . . . . . . . . . . . . . 93
7.1.2 Layering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
A C++ Implementation of Multiple Views 99
A.1 Simple Mail System . . . . . . . . . . . . . . . . . . . . . . . . . 99
A.2 UserSystemView Mail System . . . . . . . . . . . . . . . . . . . . 104
A.3 OriginatorReceiverView Mail System . . . . . . . . . . . . . . . . 113
A.4 Group Mail System . . . . . . . . . . . . . . . . . . . . . . . . . . 116
A.5 Secure Mail System . . . . . . . . . . . . . . . . . . . . . . . . . . 118
A.6 Warning2 Mail System . . . . . . . . . . . . . . . . . . . . . . . . 121
A.7 Protected Mail System . . . . . . . . . . . . . . . . . . . . . . . . 124

Contents iii
B Sina Implementation of Multiple Views 129
B.1 Simple Mail System . . . . . . . . . . . . . . . . . . . . . . . . . 129
B.2 UserSystemView Mail System . . . . . . . . . . . . . . . . . . . . 134
B.3 OriginatorReceiverView Mail System . . . . . . . . . . . . . . . . 135
B.4 Group Mail System . . . . . . . . . . . . . . . . . . . . . . . . . . 137
B.5 Secure Mail System . . . . . . . . . . . . . . . . . . . . . . . . . . 139
B.6 Warning2 Mail System . . . . . . . . . . . . . . . . . . . . . . . . 141
B.7 Protected Mail System . . . . . . . . . . . . . . . . . . . . . . . . 143
C C++ Implementation of Layering 147
C.1 Heading Mail System . . . . . . . . . . . . . . . . . . . . . . . . . 147
C.2 Attachment Mail System . . . . . . . . . . . . . . . . . . . . . . . 149
C.3 ReadNoti cation Mail System . . . . . . . . . . . . . . . . . . . . 151
C.4 History Mail System . . . . . . . . . . . . . . . . . . . . . . . . . 153
C.5 Dynamic Mail System . . . . . . . . . . . . . . . . . . . . . . . . 159
D Sina Implementation of Layering 171
D.1 Heading Mail System . . . . . . . . . . . . . . . . . . . . . . . . . 171
D.2 Attachment Mail System . . . . . . . . . . . . . . . . . . . . . . . 172
D.3 ReadNoti cation Mail System . . . . . . . . . . . . . . . . . . . . 175
D.4 History Mail System . . . . . . . . . . . . . . . . . . . . . . . . . 178
D.5 Dynamic Mail System . . . . . . . . . . . . . . . . . . . . . . . . 180
Bibliography 185

iv Contents

List of Figures
2.1 Conventional Object Model . . . . . . . . . . . . . . . . . . . . . 8
2.2 Composition Filters Object Model . . . . . . . . . . . . . . . . . 8
3.1 Multiple Views in an object-oriented environment . . . . . . . . . 13
3.2 Conceptual Model of Multiple Views . . . . . . . . . . . . . . . . 14
3.3 Many-to-many relationship between methods M o and views V o . 16
3.4 Set Operations on Views . . . . . . . . . . . . . . . . . . . . . . . 17
3.5 Multiple Views Scenario . . . . . . . . . . . . . . . . . . . . . . . 21
3.6 Object Interaction Diagram for the Mail System . . . . . . . . . 23
3.7 Adding Views in C ++ . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.8 Partitioning Views in C ++ . . . . . . . . . . . . . . . . . . . . . . 29
3.9 Dynamic Behaviour Extension in C ++ . . . . . . . . . . . . . . . 32
3.10 Static Meta Behaviour Extension in C ++ . . . . . . . . . . . . . . 33
3.11 View Composition in C ++ . . . . . . . . . . . . . . . . . . . . . . 35
4.1 Object Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2 Role playing modelled with a layer . . . . . . . . . . . . . . . . . 40
4.3 The Unix operating system divided into several layers . . . . . . 41
4.4 Layered Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.5 Conceptual Model of Layering . . . . . . . . . . . . . . . . . . . . 43
4.6 Static layering generates complex class structures . . . . . . . . . 46
4.7 Dynamic layering keeps class structures simple . . . . . . . . . . 47
4.8 Separate Behaviour from Control: History recording of objects
Obj1 and Obj2 is controlled by anOperator . . . . . . . . . . . 48
4.9 Multiple Private Properties assigned to one single object . . . . . 49
4.10 Layering Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.11 Never access \lower level" structures directly . . . . . . . . . . . 52
4.12 Rede ned methods basically extending functionality must call
the original method, and often are conditional in their extension 54
4.13 Separate Mail Read and Send ReadNoti cation functionalities . . 55
4.14 Every method has to be rede ned to implement history information
recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.15 C ++ example of one simple function in a Decorator pattern . . 58
5.1 Deadlock ofsend message in the MailHandler . . . . . . . . . . . 63
v

vi List of Figures
5.2 Implementation of method-view coupling in Sina . . . . . . . . . 65
5.3 Method View Composition . . . . . . . . . . . . . . . . . . . . . 67
5.4 View Extension only rede nes the view . . . . . . . . . . . . . . . 67
5.5 Conditionally redirect messages to specialized versions . . . . . . 68
5.6 Coupling meta behaviour to an object . . . . . . . . . . . . . . . 69
5.7 Composing views is extremely simple using Composition Filters . 69
5.8 Code example of conditional method skipping . . . . . . . . . . . 71
5.9 Orthogonal behaviour is very simple to add to an existing class . 71
5.10 Structure of an object with dynamic layering property . . . . . . 72
5.11 Composing functionalities goes rather well using Composition
Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.1 Graphical message notations from the message's viewpoint. A
message is either not ltered at all, or passes one or more lters
which inspect and/or manipulate its runtime behaviour. . . . . . 77
6.2 Filter Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.3 An example mail system . . . . . . . . . . . . . . . . . . . . . . . 80
6.4 The structure of the Multiple Views pattern . . . . . . . . . . . . 81
6.5 Code template for the Multiple Views Pattern . . . . . . . . . . . 83
6.6 Interface de nition of the Mail class . . . . . . . . . . . . . . . . 83
6.7 Implementation extract of the Mail class . . . . . . . . . . . . . 84
6.8 An example mail system with history recording . . . . . . . . . . 85
6.9 Mail system with a history recorder and a message decoder . . . 86
6.10 Message Diagram of the Basic Dynamic Layer . . . . . . . . . . . 87
6.11 Message Diagram of the Composable Object Layer Pattern . . . 87
6.12 How tomake a generic property a dynamic layer . . . . . . . . . 90
6.13 How tomake a normal class a dynamic layered class . . . . . . . 90
6.14 How to use a dynamic layered object . . . . . . . . . . . . . . . . 91

Chapter 1
Introduction
This thesis is about objects. Objects have proven to have a positive e ect on
the understandability and maintainability of software. This is the result of specifying
individual components of a software architecture with a well-de ned interface,
in such away that these components can be used elsewhere easily.
Sometimes, it is not so easy to de ne these components correctly, and
when some modelling aspects are used, this will eventually result in implementations
that can no longer be easily adapted or integrated with existing
components.
In this thesis, we focus on two di erent modelling issues, and try to
model them in C ++, which is assumed to be familiar to the reader. Because we
expect to encounter problems when using C ++, we also will use the language
Sina for modelling purposes. We then are able to compare the two with respect
to expressive power. The Sina language was developed at TRESE, and is based
on the Composition Filters Object Model, which isintroduced in Section 2.1.
This thesis is also about patterns. The working community is realising that
experience is hard to catch. Every person entering the working community must
learn all the ins and outs of his or her discipline. Unfortunately, this takes a
considerable amount of time. Further, knowledge is present, but has not been
written down.
Christopher Alexander was one of the rst to write down his experiences.
In Alexander (1977), he described the ins and outs of architecture. People starting
to work in this area can speed up their knowledge acquisition signi cantly
by using his work.
The software industry is busy trying to achieve the same with Object Oriented
Software Design Patterns. Gamma et al. (1995) wrote down how software
objects can be arranged and built to achieve certain behaviour and characteristics.
Section 2.2 gives a more complete introduction to this material.
In this thesis, we will present two modelling issues for which the Composition
Filters Object Model, the model on which the Sina language is based, will
1

2 Chapter 1. Introduction
provide adequate implementations. Although the Composition Filters Object
Model solves a lot of problems, they are not all presented in a uniform format.
Further, the current representation format of these solutions prevents the
work that is done in the TRESE group from being spread enough. This is partly
because the TRESE work is relatively theoretical, and \normal" developers
can't clearly see the advantages that the Composition Filters Object Model
has above the Conventional Object Model, on which languages like C ++ and
Smalltalk are based.
To make our work accessible, we will present the addressed modelling
issues in this thesis not only with examples, but also as Software Design Patterns.
To be able to do this, we rst will have to look at the currently most used Design
Pattern Denotation, and how problem solutions using the Composition Filters
Object Model will t in.
1.1 Project boundaries
Terminology
In this thesis several terms are used. These are explained here to avoid misunderstandings.
The word model is the most confusing word in this thesis. We identify
three di erent meanings, which are explained here:
Object model The object model is the foundations on which objects are constructed.
Elements of an object model are for example classes, objects,
attributes and methods. Properties are for example inheritance and encapsulation.
There are di erent object models. The best known are the models of C ++
and Smalltalk. These models are alike, but di er for example in metamodelling.
Classes are implicit in C ++, while they are explicitly available
in Smalltalk.
Problem domain model Software engineering concepts, like distribution or
views for example, are de ned by so-called conceptual models, which
relate participants and other elements of the concepts to eachother. We
will call this kind of model a problem domain model in this thesis. This
is the model of the term \modelling issue".
Software model The software model is also often referred to as the application
model. By software model we mean the model that is constructed
for the individual objects for the application itself. In a mail system for
example, the MailMessage object is a part of the software model of the
mail system.
We will use these speci c terms instead of the generic term \model" as much
as possible.

1.1. Project boundaries 3
Some other terms that we use are:
Conventional Object Model This is the \well-known" object model that is
normally used.
Composition Filters Object Model This is the object model that is used
to show solutions to modelling problems. It is an enhancement of the
Conventional Object Model, and extends the message sending semantics.
Method The implementation of certain behaviour of an object.
Message The \call" of a method of an object.
Message sender The object that sends a message.
Message receiver The object to which the message sender initially sent the
message to.
Access control The ability to block one or more messages, depending on internal
state information, or the sender's class or object identity.
Static vs. dynamic binding Static binding means compile-time binding of
behaviour. Dynamic binding means runtime binding of behaviour.
Message context This is all relevant context information of a message. This
includes the sender, the receiver and the method that is called.
Languages
The examples will be worked out in two di erent implementation languages.
These are C ++ and Sina. These languages are chosen for various reasons:
C++ This language is hybrid. The origins are in the C language, to which OO
extensions are added. When used well, one can get a reasonable implementation
of an OO system. It scores high when it comes to speed, with
the cost of not having context information of message calls. The language
supports static multiple inheritance and uses the Conventional Object
Model. Access control is addressed in a limited way, and it is static. Meta
information about objects, classes and messages is completely absent.
Sina This is the only language known that supports the Composition Filters
Object Model. 1 Sina does not support inheritance at all as a language
construct (as well as the Composition Filters Object Model does not
support this semantics as an explicit feature), but it is capable of implementing
(even dynamic) multiple inheritance semantics. Access control
is completely in the hands of the designer, is dynamic and can be dependent
of the context of the message.
Although we do not work out the implementations in Smalltalk, we will sometimes
use Smalltalk examples for illustrative purposes.
1. Well, there are implementations of lters in Smalltalk (Mordhorst and van Dijk 1996) and
C ++ (Glandrup 1995). An implementation in Java is being examined.

4 Chapter 1. Introduction
1.2 Structure of this thesis
In Chapter 2, a quick introduction is given about object orientation, design
patterns, the Composition Filters Object Model and its relation with the Conventional
Object Model.
Chapter 3 and Chapter 4 both discuss a certain modelling issue in detail.
Both chapters show a model, the various adaptations one can make to the model,
and how it can be implemented in a conventional object oriented language (C ++
in this case, see Section 1.1). Various (dis)advantages of the implementations
are also discussed. Implementations of the examples are included in appendices
A and C.
The implementation of the examples from Chapters 3 and 4 in Sina
is discussed in Chapter 5. It shows the advantage of the Composition Filters
Object Model over the Conventional Object Model of a language like C ++.
Appendices B and D show the full implementations.
The solutions given in Chapter 5 are used as a basis for constructing an
extension to Gamma et al.'s (1995) design pattern denotation, that is capable
of expressing solutions in the Composition Filters Object Model. This format
is described in Chapter 6. To show that the composable design pattern format
works, we provide patterns for Multiple Views and Dynamic Layering.
Chapter 7 summarises the conclusions of this work, and gives suggestions
about future research activities.
How to read this thesis
When the reader is unfamiliar with one or more of the terms Object Orientation,
Design Patterns and the Composition Filters Object Model, it is recommended
to read the appropriate section(s) of Chapter 2 rst.
Both Chapters 3 and 4 introduce and explain a speci c problem in object
oriented modelling. When the reader is interested in these problems, it is
recommended to read the chapters completely. Otherwise, certain sections can
be skipped. The layout of both chapters is the same, and is brie y described
here.
First, in Sections 3.1.1 and 4.1.1, an intuitive de nition will be given
of the problem at hand. When the reader is familiar with the material, these
sections can be skipped. Sections 3.1.2 and 4.1.2 describe a conceptual model,
which re ects our ideas about the subject, and on which the scenarios and the
examples are based. When Chapter 5 is read also, it is strongly recommended
to read these sections, also when the subject is familiar. Also interesting in that
case are Sections 3.1.3 and 4.1.3, which describe the scenarios that are used
in the examples in more detail. The example workouts (Sections 3.2 and 4.2)
and the forthcoming conclusions in Sections 3.3 and 4.3 are only interesting to
readers who want to know which problems can arise when using a language like
C ++. People only interested in Sina solutions can jump directly to Chapter 5.
Chapter 6 addresses the part about Software Design Patterns, and how

1.2. Structure of this thesis 5
implementations using the Composition Filters Object Model can be expressed
as Design Patterns. Basically, Chapter 6 can be read on its own, but it does assume
some familiarity about the Mail System, the example that is used throughout
this thesis, and the modelling issues addressed in Chapters 3 and 4.

6 Chapter 1. Introduction

Chapter 2
Background and related work
Object-orientation has proven to have a positive e ect on the development of
software. The complexity of systems can be reduced by reusing several parts
of other systems that have been built before. Also, the exibility is improved
by separating the interface from the implementation. This enables the software
engineers to `plug in' new or changed components without changing other parts
of the system, as long as the interface of these new parts conform to a certain
pre-de ned interface. There are several object models from whichwe will use two
di erent types. Section 2.1 explains the di erences between the Conventional
Object Model and the Composition Filters Object Model.
Software Quality is improved by reusing parts that have proven to be
correct. If it is not possible to reuse existing object code, it still is very usefull
to reuse modelling knowledge. In Section 2.2 Software Design Patterns are
introduced, which have proven to be an e ective medium for distributing this
knowledge.
Section 2.3 nally positions this work in the TRESE project.
2.1 Object models
In this section, we will describe the two Object Models that we use in this thesis.
These are not full introductions to the models, but merely simple descriptions
which show the fundamental di erences between them. For a full description,
we refer to Bergmans (1994, Chapter 2).
2.1.1 Conventional Object Model
The conventional object model describes objects as a collection of instance
variables, methods and parent classes. The number of allowed parent classes is
language dependent; some languages allow only one parent class (single inheritance)
and others allow more than one parent class (multiple inheritance). A
more or less standard picture for the Conventional Object Model is displayed
in Figure 2.1.
The gure shows an Object, associated with one Parent object. The
Parent object is painted dotted, because it is not a real object (at least not in a
7

8 Chapter 2. Background and related work
00 11
00 11
objMethod
Object Parent
000 111
000 111
parMethod
Figure 2.1: Conventional Object Model
00 11
00 11
objMethod
parAttr
Object Parent
000 111
000 111
000 111
000 111 parAttr
parMethod
Figure 2.2: Composition Filters Object Model
class-based language). All requests coming from the outside world are directly
dispatched to the implementations in the Object itself, or one of its Parent
objects. This is done transparantly, as is shown by using dotted arrows inside
the Object. Also, all instance variables intrinsically are available to the outside
world, although some languages de ne some restrictions on this. 1
2.1.2 Composition Filters Object Model
The Composition Filters Object Model is an extension of the Conventional
Object Model. This Composition Filters Object Model adds semantics to the
object model by placing lters on top of the object interface. These lters are
capable of investigating all incoming and outgoing messages, as well as the
object itself, and it is capable of modifying passing messages, or forward them
to other objects. A picture of the Composition Filters Object Model is found
in Figure 2.2.
1. For example private, protected and public attributes and methods in C ++ (Ellis and
Stroustrup 1990)

2.2. Design Patterns 9
This gure shows the same situation of Figure 2.1, but now with Composition
Filters extensions. All incoming messages from the outside world pass
the input lters of the Object. These lters send one type of message to the
method present in the Object itself, while the other message types are delegated
to the Parent object (which has its own lters of course). In contrast to
the conventional situation, this Parent object is a real object, but its presence is
hidden from the outside world. Also, the internal calls to the implementations
is explicit.
There are three fundamental di erences between the two models:
1. In the Composition Filters Object Model the Parent object is a real
rst-class object, while in the Conventional Object Model it is not;
2. In the Composition Filters Object Model there is one entrypoint for all
incoming messages, 2 while in the Conventional Object Model all methods
have their own individual entry points|this means that no overall
control is possible over incoming messages in the Conventional Object
Model, because message entry is not explicitly modelled in this model.
3. Distribution of the incoming messages over the present implementation(s)
is done by the lters in the Composition Filters Object Model,
while in the Conventional Object Model, this is de ned by the execution
model of the language in question. 3
2.2 Design Patterns
A design pattern is an entity, which gives one or more context-dependent solutions
for a particular problem, or an implementation structure for a particular
design issue. Patterns were rst introduced by Alexander (1977), who de ned
patterns for the architectural world. The software community has borrowed this
idea, and nowadays many patterns are de ned to capture software design.
These software design patterns have proven to be an e ective medium
for documentation and communication about domain knowledge (Gamma et al.
1995, Buschmann, Meunier, Rohnert, Sommerlad and Stal 1996, Pree 1994).
Their description is formalized by Gamma et al. (1995), and most design patterns
de ned today are formatted conform their recipe.
2. There is also one exit point for all outgoing messages. We do not depict this often explicitly
in this thesis, but the reader must know that they exist.
3. There are di erent implementations. In C ++ for example, there are things called virtual
tables, which are in fact pointers to the actual function implementations for the \current"
object. In Smalltalk the runtime engine searches for appropriate implementations in the class
hierarchy.

10 Chapter 2. Background and related work
2.3 Position of this work in the TRESE project
Composition Filters Development
By development of Composition Filters, we mean the development of the model
and the de nition of di erent lter types. At the moment, the model is considered
more or less complete, so there is not much work in this area now.
Composition Filters Implementations
Several implementations of Composition Filters are developed and others are
under development. Implementations in C ++ (Glandrup 1995) and Smalltalk
(Mordhorst and van Dijk 1996) are ready. Another kind of implementation is
the Message Manipulator de ned by Stuurman (1996), who de ned Composition
Filters as rst-class objects in an object-oriented environment. An implementation
in Java is being examined.
Composition Filters Knowledge Distribution
A lot of articles have been written which address several problems that Composition
Filters can solve (Bergmans 1994, Aksit, Bosch, van der Sterren and
Bergmans 1994, Aksit, Wakita, Bosch, Bergmans and Yonezawa 1993, Aksit,
Bergmans and Vural 1992, Aksit and Bergmans 1992, Aksit and Bosch 1994).
With these articles, we try to make the outside world aware of potentional problems
in daily object-oriented designs, and how one can avoid these problems.
Besides the distribution of articles, also courses are lectured in objectoriented
analysis and design. Further, there is an active participation in conferences
and workshops which address object-orientation.
Composition Filters Deployment
There are several framework designs which use the Composition Filters Object
Model. These include Algra (1994), Koehorst (1994), Tekinerdogan (1994) and
Vuijst (1994).
Where does this thesis t in
The work in this thesis is part of the Composition Filters Knowlegde Distribution.
We think the bene ts of this work is twofold. First, we show how certain
design issues can be addressed using Composition Filters. Second, by expressing
our implementations as Design Patterns, we make our knowledge accessible to
the world.

Chapter 3
Modelling Issue: Multiple Views
In our daily lives we often have to deal with relatively complex materials. It is
common practice then to look at the problem from di erent points of view. We
will focus on a certain aspect of the problem, and forget the rest for a moment.
With this simple trick we are able to understand things that are so complex,
that we could never have understood them otherwise.
In this chapter, we will elaborate on the domain of views. This is how we call
\the trick" when applied to software engineering. We will see how software
models can be made better and easier to understand by making views explicit
in the software model.
The goal of this chapter is twofold. First, we will introduce the modelling
issue Multiple Views in Section 3.1. Second, we show how the concept can be
modelled in C ++. In Section 3.2, we give an example implementation where
the change scenario is implemented in C ++. Conclusions are summarised in
Section 3.3.
3.1 Modelling Multiple Views
In Section 3.1.1, we will show what views are, and try to give the reader enough
basics to belief that views can be bene cial for handling complex software engineering
problems. It should also give enough introduction of views to understand
the rest of this chapter.
In Section 3.1.2, we introduce a conceptual model of views. We will use
this model as our reference throughout this chapter. It shows the di erent parts
of the view model, and which changes we expect in implementations that are
based on this model.
These changes are detailed out in Section 3.1.3, in which we de ne a
scenario where the di erent model changes are described in detail.
11

12 Chapter 3. Modelling Issue: Multiple Views
3.1.1 What is a View?
People often look at things around them from di erent viewpoints. This means
that the same things get several di erent interpretations |even from the same
person| dependent on how we look at them. We can see this often in crime
scenes, where many di erent statements come from even so many witnesses.
This is what we call a passive view, because the object is interpreted in several
di erent ways, something this object cannot control.
Also, people react di erently to the signals they receive from their environment.
Some signals are always ignored, some are always accepted, and some
are accepted only under certain conditions. Sometimes we even can react differently
on the same signals in di erent situations. For example, when a total
stranger asks your friend, say Joe,tomake him some co ee, this will probably
have no e ect. It depends on the mood of Joe when some acquaintance asks the
same question. When you ask it, Joe always will make your co ee (unless you
just had an enormous ght of course). He will also always make co ee for his
girlfriend, but he knows she does not want her co ee as strong as you want it.
We will call this kind of views active, because Joe can decide for himself how
he will react on the question of making co ee.
These situations are very normal in our daily lives. When we model software
implementations however, we tend to forget this quickly, and make all behaviour
of the software components general. This does not mean that views don't exist
in software models, we just don't model them explicitly.
Communication happens always between two or more parties. There will
always be at least one sender and one receiver of a communication message.
We cannot model the passive view (i.e. the interpretation of the data that
is returned from the receiver to the sender) of this communication. We can
however model the active view that the receiver provides to the sender.
In normal life, an active view is often dependent of the context of the communication
message | think of Joe who does respond to you or an acquaintance,
while ignoring a total stranger.
We also want this in software models. We want to de ne communication
channels explicitly. Di erent channels require di erent |or at least partly
di erent| interfaces. When we model each communication channel on its own,
an object appears to have an interface that in fact consists of several subinterfaces,
each supporting a di erent communication channel.
This division of the interface of an object is depicted in Figure 3.1. We
call these sub-interfaces views. Our goal is to make views explicit in our implementations.
This helps us understanding the communication channels that
exist between di erent objects, and the respective responsibilities of the communication
participants. Further, with explicit views we are able to test these
views and therefore construct more robust applications, where misuse errors are

3.1. Modelling Multiple Views 13
Channel 1
Object Interface
Chan 1 interf. Common interf. Chan 2 interf.
Channel 2
Figure 3.1: Multiple Views in an object-oriented environment

14 Chapter 3. Modelling Issue: Multiple Views
State
spaces
Relation
S(t)
S(o)
S(c)
Object
functionalities
Real-World
Views
less likely to occur.
Transformation functions
T(v(2))
T(v(1))
T(M)
T(v(3))
T(R)
M(o)
Conceptual
Views
v(1)
v(2)
Methods
v(3)
V(o)
Views
Mapping functions
Figure 3.2: Conceptual Model of Multiple Views
3.1.2 Conceptual View Model
To be able to make a good implementation of views in an object-oriented system,
we must rst supply the conceptual model of views. This model captures the
di erent aspects of views, and gives us a reference model from which we will
explore the whole domain.
In Figure 3.1 we can see that views are de ned at the interface of an
object. If we do not de ne views, they will be present, but we cannot \see" them
in that case. All we have is an object with its state space (see below). The model
is depicted in Figure 3.2. It shows the real world, where views are a natural part
of the system. Views are present implicitly, but they are nowhere referenced
explicitly. We can make views explicit by making the appropriate abstractions
of the state space. We call these abstractions transformation functions.
Model Components
In the real world, there are three di erent elements with respect to views.
1. State spaces;
2. Object functionalities;
3. Some interconnection between these two.
These elements are discussed in detail below. In Figure 3.2, we also see three
di erent kinds of transformation functions:
1. The transformation from object functionalities to methods;
2. The transformation from state spaces to views;
3. The mapping between views and methods.

3.1. Modelling Multiple Views 15
These transformation functions re ect the realisation of speci cations into models.
Conventionally, only the transformation T M is realised. We de ne views
explicitly by realising the other transformations as well.
Methods The methods implement the application semantics, i.e. the functionalities
that the class provides. The set of methods that an object supports, is
denoted as
M o = Object Methods (3.1)
The transformation function T M provides a method for each functionality. This
transformation is rather trivial and common practice to developers, and it is
not further discussed here.
Views The views de ne the abstractions of the State Space we are interested
in. Therefore we make the following de nitions.
The Object StateSpace represents the total state space of the object that
receives the message. This state space is multi-dimensional, and can be seen as
all possible combinations of values of all internal variables.
S o = Object StateSpace (3.2)
The Context StateSpace represents the total multi-dimensional state
space of the context of a message. This context consists of all possible information
about the message, such as the sender of the message, the selector of
the message (the method that is called), the parameters of the message and the
target or server (the object that the message is sent to).
S c = Context StateSpace (3.3)
The Total StateSpace S t represents the cartesian product of S o and S c,
and thus represents the total state space of a message. The actual state of a
message when it is sent is denoted as s m.
S t = S o S c (3.4)
s m 2 S t (3.5)
A view is the abstraction from a certain situation in the real world, so from
all possible states s m 2 S t there are a couple of them that are part of this
abstraction:
v S t (3.6)
Each view v needs its own transformation function T v, because each view can
cover another aspect of the state space S t. Some examples of view aspects are
sender information and message history information.

16 Chapter 3. Modelling Issue: Multiple Views
Methods
Views
Figure 3.3: Many-to-many relationship between methods M o and views V o
The set of views V o now can be de ned as follows. First, we de ne the
powerset P(S t) of the state space, which represents the set of all possible combinations
of states from the state space S t. The set of views V o of an object
then is a subset of this powerset.
V o P(S t) (3.7)
A view v 2P(S t) (see Equation 3.6 and Equation 3.7), so a view is in
e ect when the actual state of the message s m 2 v (See Equation 3.5).
Method-View Coupling The coupling between the methods M o and the views
V o is done by de ning a mapping between V o and M o. This mapping is many-tomany,
as is shown in Figure 3.3. This mapping occurs in the following possible
cardinalities:
V 7! M + (surjection) (3.8)
V + 7! M (injection) (3.9)
The possibilities V 7! M and V + 7! M + are both constructed from the two
mentioned here.
Implementation Requirements
When the concepts of the previous section are implemented, wewant to preserve
the exibility that the object-oriented paradigm has given us. As we have seen
in Equation 3.6, a view is a set of states. When we de ne more views on an
object, we also want to be able to manipulate these views using normal set
operators (see Figure 3.4).
Also, we want to be able to manipulate the transformation functions by
de ning extensions to existing models (i.e. through subclassing) without any
unnecessary rede nitions. We want to be able to make changes, following the
scenario discussed in Section 3.1.3. The changes that we want tocover are:

3.1. Modelling Multiple Views 17
View
Subview 1 Subview 2
(a) View Partitioning
View 1 View 2
Combined View
(b) View Composition
Figure 3.4: Set Operations on Views
Add views;
Partition views;
Extend views;
Add behaviour;
Extend behaviour;
Combine views.
Note that removal of behaviour and views is not listed here. This operation
also is not supported by the inheritance mechanism provided by object-oriented
languages.
3.1.3 Scenario of Changes
In this section we describe a scenario, which covers the possible changes that
can be made to an object model that incorporates views. In Section 3.1.2, we
have described a model for views in an object-oriented environment. When we
implement this model, we have to transform the elements of the view model
to the object model that is used for the implementation. This transformation
is not trivial, as we will see in the next section, and depends heavily on the
implementation language.
The scenario starts with an object model, where views are not present
yet. The interface is assumed public, so all methods are visible to all potential
clients. We will start from that point, and rst add view semantics to the model.
Then we follow a scenario of changes to this model. This scenario will show how
easy (or hard) it is to adjust an object model with views.
Add Views
In order to be able to de ne views on the interface of a class, we have to identify
a mapping between the view model and the object model. The view model has
three types of transformations (see Figure 3.2). The transformation of views
needs special attention, because we have to be able to cover all possible forms
of transformations, like sender and history information.

18 Chapter 3. Modelling Issue: Multiple Views
In the example that we will discuss in Section 3.2, we need the following
categories of transformations (these are all view transformations):
Access Control We need to provide some means of access control to the methods
we have de ned. We want to restrict the interface of a class to one
or more other classes in such a way, that only classes that are granted
access can use the object, and others can not.
Context Information We need a way of determining context information
about a message. For example, if we want to prevent access from some
class to one or more methods, we need to know what object sent the
message.
Meta Information We need to determine the type of an object at runtime. In
other words, we need some meta information about objects and classes.
History Information Sometimes we want to de ne views that are not based
on the actual situation, but on the things that have happened in the
past. In this situation we need to be able to deduce history information
about messages from the objects.
View Partitioning
Sometimes we want to partition a view into two or more views. This is the
consequence of re ning some part(s) of the speci cation. Suppose we have a
view v 2 V o, i.e. the original view that we want to re ne. We de ne the partition
v = 1 [ 2;:::
Note that i 2P(S t), because V o 2P(S t), where P(S t) is the powerset of S t.So
we can conclude that the partitions i are ordinary views on the object! They
only have an extra property, which is that they together form the original view,
thus i 2P(V o).
Partitioning a view into several sub-views, in a way invalidates the original
view. Thus, all references made to this view also must be removed.
View Extension
Extending a view means enlarging the set of possible values under which the
view is active. The requirements only involve changing the view v 2 V o, and
thus the set V o. The identi er of this view remains the same, in contrast with
Section 3.2.3, where we will see a change of the view set V o, the identi ers
inclusive. The encapsulation property of the implementation ensures us that in
this case only the implementation of this view needs to be rewritten.
Add Behaviour
When we add behaviour to an object, we need to extend the method set M o
of the object (see Equation 3.1). Also, the new behaviour probably falls under
one or more views that are de ned on the object, so the set of mappings also
needs to be extended.

3.1. Modelling Multiple Views 19
Behaviour Extension
Behaviour extension can have the following interpretations.
Application Behaviour Extension This form of behaviour extension is the normal
one, for which the inheritance mechanism of object-oriented languages is
used. The original behaviour is \overwritten" with another one, so that all objects
of the new (sub)class have the adapted behaviour. Note that this form of
behaviour extension is static, i.e. it yields for all objects of this class.
In terms of the view model discussed in Section 3.1.2, the extension of
application semantics maps to the extension of the object functionalities, and
the addition of a mapping from this functionality to an object method m 2 M o.
Meta Behaviour Extension Meta behaviour extension is totally di erent, because
it does not really adapt the normal behaviour of the objects. It interprets
the in- and outgoing messages of objects, and according to this information the
behaviour of the object can be changed. So, object behaviour can (but does not
have to) change because of meta behaviour extension, but when it does, it will
be indirectly. Also this form of extension is static.
Meta behaviour extension does not alter the method set M o. It does alter
the view set, where a view is added or extended, that uses not only object state
space information from S o, but also context state space information from S c,
where information about the message is used to check for the validity of the
view.
Dynamic Behaviour Extension Dynamic behaviour extension can be application
as well as meta behaviour extension. The extra property here is dynamicity.
Not all objects of the new class have to get the new behaviour. It is also possible
that not all invocations to the same object result in the same behaviour. This
dynamicity isanimportant property that must be used in an implementation
where close resemblance of the real world is necessary.
We can see this as follows in the model of Section 3.1.2. In Figure 3.2,
we see a mapping between object functionalities and object methods. Normally,
this mapping results in one method per functionality (ignoring the fact that this
method will almost always be divided in several smaller methods). It is possible
however, that two di erent implementations exist for one object functionality.
Depending on some view speci cations, one or the other implementation for the
message will be activated.
Think for example of an object class Collection, where the implementation
of the sort message is dependent of the size of the collection (i.e. the
actual number of elements). The behaviour of the sort message then is dynamic.
The needed implementation can be chosen at runtime, depending on some state
information. When we de ne the needed states in views, we choose and activate
the best implementation depending on the current object state. So in our exam-

20 Chapter 3. Modelling Issue: Multiple Views
ple, the sort functionality has two implementations: quickSort and bubbleSort.
The views for these methods are smallCollection and largeCollection. When we
map, for the message sort, the view smallCollection to the method bubbleSort
and the view largeCollection to the method quickSort, we have implemented a
system where the object itself chooses the best implementation for a speci c
behaviour at runtime, depending on some view speci cation.
View Composition
Views can be partitioned, as is discussed in Section 3.1.3, but they also can be
composed. This means that two or more di erent views together de ne another
view which is used to express some situation. With this mechanism it is possible
to build a hierarchy of views, so that mappings to methods can be performed
at an arbitrary granularity.
Further, when two object classes are combined through inheritance, their
state spaces also will be combined. It is very likely that methods of the rst
object have to be restricted by views of the second object, so that additional
mappings between methods and views have to be de ned. This mapping however
crosses class boundaries, which is not a trivial thing to do.
3.2 C++ Implementation
Now wehave a clear overview of what views are, and what changes we want to
be able to perform on a view implementation. We de ne an example on which
we can test these changes. In the previous section, we listed the changes that
we want to perform. We map these changes directly to our example. We start
with a fresh example without any views, and then, in six di erent stages, we
extend our speci cation following the steps of Section 3.1.3. In Figure 3.5, we
see the Mail class, and all subsequent subclasses that implement the steps of
the scenario. Note that the scenario must be read from top to bottom.
As the legend says, the white coloured classes are classes with application
semantics. They are present because they have direct meaning for the
program. The light-grey coloured classes also implement application semantics,
but this is with a lot of overhead. This means that the implementation is heavy
relative to its functionality. The dark-grey coloured classes are pure overhead.
The . . . User classes mostly only implement a test function. The Object class
implements runtime type information. This is necessary for the meta information
we use in our implementation, and also for declaring \typeless" function
arguments. 1 We can see that the Object class is pure overhead, and it also
requires us to de ne overhead code in all subclasses of it, in order to let the
Object functions return correct values. Finally, the MVMailHandler class
1. C ++ is strictly typed, which means that a function with an argument oftype Object can
only be passed arguments of type Object, or a subtype of this type.

3.2. C ++ Implementation 21
Object
SecureDocument
Legend
User
MVUser
VPUser
GroupUser
PGPUser
Warning2User
ProtectedUser
Normal class
Normal class (with overhead)
Overhead class
Mail
UserSystemViewMail
OriginatorReceiverViewMail
GroupMail
SecureMail
Warning2Mail
ProtectedMail
Figure 3.5: Multiple Views Scenario
MailHandler
MVMailHandler
Add Views
Partition Views
Extend Views
Extend Behaviour (dynamic)
Extend Behaviour (static meta)
Compose Views
Scenario direction

22 Chapter 3. Modelling Issue: Multiple Views
is only present because introducing views means adapting the class interface of
UserSystemViewMail.
Now we will describe the running example. It covers the implementation
of a Mail System. This system is capable of sending and receiving mail messages
from and to users via a so-called mail handler. The idea is that a user creates a
mail message, and sends it to the mail handler. This mail handler then routes
the mail message and delivers it to the recipient. For clarity, we provide a list
of terminology here.
MailMessage The mail message that is to be sent from one user to another.
MailOriginator The user that sends a MailMessage.
MailReceiver The user that receives a MailMessage.
User A user of the mail system, i.e. a MailOriginator or a MailReceiver.
MailHandler The system that receives a MailMessage from a User (the Mail-
Originator) and routes it to the appropriate User (the MailReceiver).
3.2.1 Simple Mail System
In this section we show the implementation of the Simple Mail System. It only
implements the normal expected semantics without views. It provides a real
executable mail system.
To implement this system, we introduce the following classes:
MailHandler This class implements the central post o ce that routes Mail-
Messages from and to Users.
User This class implements the person objects that send and receive MailMessages
from and to each other (the MailOriginator and the MailReceiver
objects).
Mail This class implements the MailMessage itself. The Multiple Views that
this chapter is about will be de ned on this class, so this is the only
real important class of the example. The other two classes are present to
support the example.
Note that we only elaborate on the MailMessage de nition, because the User
and the MailHandler classes only are present to support the example. The
class Mail has the following interface speci cation:
setMailOriginator This method is used to set the originator of the MailMessage.
getMailOriginator This method is used to inspect who sent the MailMessage.
setMailReceiver This method is used to indicate to whom the MailMessage is
to be sent.
getMailReceiver This method is used to inspect the receiver of the MailMessage.
setMailContents This method is for setting the contents of the MailMessage.
getMailContents This method is used to inspect the contents of the MailMessage.
send This method is used to send the MailMessage to the indicated MailReceiver.

3.2. C ++ Implementation 23
MailOriginator MailMessage MailHandler MailReceiver
setMailOriginator
setMailReceiver
setMailContents
send
send
getMailReceiver
getMailContents
approve
setRoute
setDelivered
getMailOriginator
getMailContents
receive
Figure 3.6: Object Interaction Diagram for the Mail System
reply This method is used to send a reply to the MailOriginator.
approve This method is used to tell the MailMessage that it is approved for
delivery by the MailHandler.
isApproved This method is used to inspect if the MailMessage is approved for
delivery.
setDelivered This method is used to set the indication that the MailMessage is
delivered to the MailReceiver.
isDelivered This method is used to inspect if the MailMessage is delivered to
the MailReceiver.
setRoute This method is used to set the routing information of the MailMessage.
getRoute This method is used to inspect the routing information of the Mail-
Message.
In Figure 3.6, the expected runtime behaviour of the system is displayed. Certain
details are omitted here for simplicity. The order of the messages setMailOriginator,
setMailReceiver and setMailContents from the MailOriginator to the
MailMessage is irrelevant. Further, the MailOriginator will be inspecting the
instance variables of the MailMessage via the get. . . methods.
The implementation of this system is rather straightforward. The C ++
implementation is listed in Appendix A.1.
An interesting detail in Figure 3.6 is the call of getMailContents by the Mail-
Handler. This is unauthorised use of the method (we do not want the postman
to read our love letters), and we want to prevent this in the next version of our

24 Chapter 3. Modelling Issue: Multiple Views
Mail System.
setMailOriginator
getMailOriginator
setMailContents
getMailContents
setMailReceiver
getMailReceiver
send
reply
approve
isApproved
setDelivered
isDelivered
setRoute
getRoute
p
p p
p
p
p
p p
p
p
p
p p
p
p p
p
p p
UserView SystemView
Table 3.1: Access rules for the Mail System
3.2.2 Add Views: UserSystemView Mail System
In the Simple Mail System we saw the implementation of a straightforward
mailing system. It was capable of sending MailMessages from one User (the
MailOriginator) to another (the MailReceiver) through the MailHandler. Now
we are going to extend this system with views.
Motivation
We want to divide the interface of Mail into di erent views, that clearly separate
the di erent functionalities that the interface provides.
We saw in Figure 3.6 that the MailHandler was peeking into the Mail-
Message. With the application of views, wewant to prevent such misuse in the
future.
The interface of Mail is rather \big" already. When the number of
methods grows even larger, it is not clear anymore which methods serve what
purpose. Being able to see the sub-interfaces of a relatively large class interface
makes this interface much more readable.
Semantic Structure
As can be seen in Figure 3.6, there are two di erentinterfaces in the class Mail.
These are the UserView and the SystemView. Some methods only apply for
Users, and some other methods only apply for the MailHandler of the system.
There are also methods that have no restrictions. Wewant to divide the interface
of class Mail as follows.
To be able to implement this, we augment the de nition of class Mail.
These changes have the following bases (See also Section 3.1.3).

3.2. C ++ Implementation 25
Access Control We need to provide some means of access control to the methods
we have de ned. We want to restrict the interface of class Mail to
the class User in such away, that User objects have noway in calling
the SystemView methods approve, setDelivered and setRoute in Table 3.1.
Context Information We need a way of determining context information
about a message. For example, if we want to prevent access from a User
to the method setRoute, we need to know which object sent the message.
Meta Information We need to determine the type of an object at runtime
(such asaUser). In other words, we need some meta information about
objects and classes.
Implementation Consequences
In C ++, we do not have the Context state space S c (Equation 3.3), so we cannot
support views that depend on this information without providing it by hand.
We need this information, because we want to restrict access dependent onthe
type of the sender, and the sender is part of S c.
We can only provide context state space information by explicitly passing
the sender of the messages to the receiving object. This is of course not
fool-proof, and error-prone. Furthermore, it needs modi cation of the class interfaces,
which breaks reusability of classes without view implementations in
classes with a view implementation. This means a lot of (unnecessary) recoding
of methods when views are added to a class dictionary. This is seen in the example
in Appendix A.2, where the User and the MailHandler classes have
to be rede ned only because the interface of Mail has changed.
We also have a problem with the mapping between the methods M o and the
views V o. There is no way ofintercepting an incoming message in a central place
in an object, in order to test for the mapping relation. The only way of testing
the mapping relation is in the method de nition itself. But in doing so, we are
integrating the methods M o with the mappings, which is not what we want. To
avoid this, we de ne the methods M o in a private section of the object, so the
outside world cannot use it. These private methods implement the application
semantics, while the public methods implement the method-view mappings.
This approach has one drawback. The overview of the class interface is
lost again (we wanted to approve this with views) because of the enormous
amount of methods that appear. The UserSystemViewMail class from Appendix
A.2 has a lot of methods (33!), while we wanted only the 15 of the
non-view implementation from the Mail class from Appendix A.1.
The origin of this problem lies in the N : M relation between methods
M o and views V o. We can only intercept at the method entrance point. When
we have one method that couples to more than one view, this is no problem.
With views however, we often have a view, which is coupled to a number of
methods. We can only implement this by repeating coupling information for

26 Chapter 3. Modelling Issue: Multiple Views
each method.
The views V o are implemented using Boolean functions. This provides a central
de nition of the views, so they can be reused in the rest of the class speci cation,
and they can also be rede ned easily without recoding other parts of the class
speci cation.
However, we need information we do not have. We need to deduce the
type (class) of the sender object, in order to decide if access is allowed. This type
of meta-information is not present inC ++, and must explicitly be implemented.
The scheme that is used in many commercial class libraries does the job pretty
well.
The implementation in Appendix A.2 uses an internal Mail object in User-
SystemViewMail. One could have expected an inheritance relation here. We
have not done this, because the interface had to be rewritten completely, and it
is impossible to completely hide the interface of the parent class without losing
the inheritance bene ts.
The interface of Mail must be made invisible. If we don't do this, the
application still can call the old versions of the methods (by omitting the sender
parameter). So the Mail class must be made protected or private. But then
we cannot pass the UserSystemViewMail objects to functions that expect
Mail objects as a parameter. We can trick this by explicitly casting the parameter
to be of class Mail, but then the called function can freely access the
old de nitions of the functions. This will not bring us any further, so to avoid
complications, we de ned the Mail object as an internal variable of User-
SystemViewMail.
In Figure 3.7, we see a piece of code de ning views in a C ++ class. This example
is an extract of Appendix A.2, and has all the elements in it that we discussed in
this section. All interface methods have the context parameter sender de ned.
Also, the interfaces are separated from the implementation, which separates
application semantics from method-view mappings. The views are de ned as
Boolean functions, and the class must inherit from some generic class Object
which provides runtime type information.
3.2.3 View Partitioning: OriginatorReceiverView Mail System
In the UserSystemView Mail System we saw a Mail System that separated the
Mail interface in a part for the Users, and a part for the MailHandler. In this
section we re ne the UserView.
Motivation
In this section we are going to divide a view into several sub-views. With this, we
show the (non-) exibility and composability of the implementations of views.

3.2. C ++ Implementation 27
class UserSystemViewMail : public Object
f
public:
virtual classTypes myClass(void)
f return UserSystemViewMailClass; g
virtual void setMailOriginator(Object ,MVUser );
:::;
protected:
virtual int isUserView(Object );
virtual int isSystemView(Object );
private:
virtual void pureSetMailOriginator(MVUser );
:::;
g;
void
UserSystemViewMail::setMailOriginator(Object sender,MVUser u)
f
assert(sender6=(Object )0);
CFilter(this!isUserView(sender), this!pureSetMailOriginator(u));
g
int
UserSystemViewMail::isUserView(Object sender)
f
assert(sender6=(Object )0);
return sender!isKindOf(MVUserClass);
g
void
UserSystemViewMail::pureSetMailOriginator(MVUser u)
f
mail!setMailOriginator(u);
g
Figure 3.7: Adding Views in C ++

28 Chapter 3. Modelling Issue: Multiple Views
Semantic Structure
setMailOriginator
setMailContents
getMailContents
setMailReceiver
send
reply
OriginatorView ReceiverView
p
p
p p
p
p
p
Table 3.2: Separation of UserView methods
In the UserSystemView Mail System, we saw the implementation of a mailing
system which had two views. These views separated the interface of Mail into
a part that was accessible to the Users, and one part for the MailHandler.
The UserView is too broad however. This view allows all Users inthesystem
to manipulate all MailMessages in the system. In the OriginatorReceiverView
Mail System, we are going to restrict this.
Table 3.2 shows the separation of methods from the UserView in the
UserSystemView Mail System into the two views OriginatorView and Receiver-
View. Note that this is not a total partitioning. From all Users in the system,
only the MailOriginator and the MailReceiver will have some access to the
MailMessage. All other Users will have no access at all. Also note that methods
without any access restrictions are not listed here.
We have to de ne the new views, and wehave to attach the methods from
Table 3.2 to the views. Note that we donot rede ne any application semantics
(from the original Mail class).
Implementation Consequences
Implementing this view partitioning in C ++ has the following consequences. The
view set V o has changed, so we need a couple of extra functions to implement
these views. Further, all method-views couplings that refer to the UserView
have to be rewritten. Now the shortcomings of the C ++ solution mentioned in
Section 3.2.2 becomes clear. All methods that de ne a method-view coupling
and refer to the view UserView have to be rewritten. In Figure 3.8 we can see
this. When we had been able to use a central place for this coupling, we could
have avoided this situation.
3.2.4 View Extension: Group Mail System
The OriginatorReceiverView Mail System provided a secure access to the Mail-
Message for only those users that were in any way related to the MailMessage.
In this section we are going to extend the view semantics.

3.2. C ++ Implementation 29
class OriginatorReceiverViewMail : public UserSystemViewMail
f
public:
virtual void setMailOriginator(Object ,MVUser );
virtual void setMailReceiver(Object ,MVUser );
:::;
protected:
virtual int isOriginatorView(Object );
virtual int isReceiverView(Object );
g;
void
OriginatorReceiverViewMail::setMailOriginator(Object
sender,MVUser u)
f
assert(sender6=(Object )0);
CFilter(this!isOriginatorView(sender),
UserSystemViewMail::setMailOriginator(sender,u));
g
int
OriginatorReceiverViewMail::isOriginatorView(Object sender)
f
assert(sender6=(Object )0);
return (this!getMailOriginator(this) (MVUser )0)
jj sender this!getMailOriginator(this);
g
Figure 3.8: Partitioning Views in C ++

30 Chapter 3. Modelling Issue: Multiple Views
Motivation
This section will show the implications of extending the view semantics.
Semantic Structure
The semantics of the OriginatorView is too restrictive for our purpose. When a
User has created a MailMessage, he or she is the only one that can manipulate
the MailMessage until it is sent to the MailReceiver.Wewant to be able to allow
all members of the same group of Users to manipulate MailMessages. In this
way it is possible that a person of some group creates the MailMessage, another
group member reviews it, and nally the secretary archives the MailMessage
and sends it to the MailReceiver.
Implementation Consequences
Because we separated view de nitions from the rest of the class speci cation,
we only have to de ne a new method for the OriginatorView. In Appendix A.4
this is made clear. The only extras implemented besides the view are some test
functions.
3.2.5 Dynamic Behaviour Extension: Secure Mail System
The GroupMail System extended the view semantics. Now we will add some
extra behaviour to the Mail System.
Motivation
This section will show the consequences of extending the behaviour of the Mail
System. We will implement dynamic behaviour here, showing that views are
not only used for access control.
Semantic Structure
The Mail class implemented direct storage and retrieval of the MailContents
until now. In this section we implement a new feature. The contents of the
MailMessage will be encrypted using the PGP protocol automatically, when
the participating Users support this protocol.
This requirement introduces something special: We now have two different
implementations for the same method(s). The setMailContents method
must eventually encode the MailContents, and the getMailContents eventually
must decode the MailContents to make it readable again.
To implement this, we introduce a new view, PGPUserView, which is
active when the User supports the PGP protocol. If this is true, the new encoding
and decoding versions of setMailContents and getMailContents will be used.
Otherwise the system will use the \normal" versions.
This has the impact that only Users that support the protocol will be
able to read messages that are encoded. This re ects the real world situation,

3.2. C ++ Implementation 31
where a person cannot read PGP encoded messages when he does not support
the protocol.
Implementation Consequences
For the implementation, we introduce the new view, PGPUserView, and couple
this view to the methods getMailContents and setMailContents. Figure 3.9 shows
that the new getMailContents now chooses implementation dependent on some
view de nition. There are no further consequences besides those wehave already
seen.
3.2.6 Static Meta Behaviour Extension: Warning2 Mail System
In this section we will extent the behaviour semantics in another way. We reify
the messages and alter our behaviour depending on the obtained information.
Motivation
We want to show how meta information about messages can be used to reason
about these messages.
Semantic Structure
In this section we extent the semantics of the Mail class in such away, that it
may output a warning when one of the methods setMailOriginator, setMailReceiver,
setMailContents or send is called, depending on some conditions.
It adds something new to the system. We had methods M o, views V o
and method-view mappings. Which one is changed when we want to add the
desired behaviour?
We said before in Equation 3.4 that context information about the messages
(S c)was part of the total state space, from which views were abstracted.
We have omitted a precise de nition about this state space. A part of this space
consists of all information about the message that is sent, including the selector
that indicates which method should be executed. Because message information
is part of the state space S c, we can de ne a view that covers this part of the
state space S t.
The implementation of the view will be a problem however, because we
access meta information about the message, something we did not do before.
Implementation Consequences
In C ++, we do not have information about a sent message. In Appendix A.2
we already were confronted with this fact, because we needed the sender of the
message. In this case we want other information about the message, namely
the selector. This information is implicitly available, because we can see this
in the method body itself. But because we have to count the number of times
the message is sent, we need this information explicitly. This is not part of the
language, so we need to implement this ourselves. Figure 3.10 shows us how it

32 Chapter 3. Modelling Issue: Multiple Views
class SecureMail : public GroupMail
f
public:
virtual char getMailContents(Object );
:::;
private:
virtual char purePGPGetMailContents(Object );
g;
char
SecureMail::getMailContents(Object sender)
f
char s (char )0;
if (this!isPGPUserView(sender)) f
s this!purePGPGetMailContents(sender);
g else f
s GroupMail::getMailContents(sender);
g
return s;
g
char
SecureMail::purePGPGetMailContents(Object sender)
f
char l, s strdup(GroupMail::getMailContents(sender));
cout "PGP decoding...nn";
for (l s; l;l++) ( l)--;
return s;
g
Figure 3.9: Dynamic Behaviour Extension in C ++

3.2. C ++ Implementation 33
typedef enum f
W2MailSetMailOriginatorSelector,
:::
lastWarning2MailSelector
g Warning2MailSelector;
class Warning2Mail : public SecureMail
f
public:
virtual void setMailOriginator(Object , MVUser );
:::;
private:
int selectorCount[ lastWarning2MailSelector];
g;
void
Warning2Mail::setMailOriginator(Object sender, MVUser u)
f
if (this!isWarning2View(W2MailSetMailOriginatorSelector)) f
cout "Warning, setMailOriginator sent twicenn";
g
selectorCount[W2MailSetMailOriginatorSelector]++;
SecureMail::setMailOriginator(sender,u);
g
Figure 3.10: Static Meta Behaviour Extension in C ++

34 Chapter 3. Modelling Issue: Multiple Views
can be done in C ++. Appendix A.6 shows the complete solution. The solution is
rather ad-hoc however, and again repeats the method-view coupling more often
than we want.
An alternative implementation can explicitly build a meta object of the
message, and pass it as a parameter to another method which does the counting
and registration of incoming messages. At this point, this alternative would be
too distracting for the example now.
3.2.7 View Composition: Protected Mail System
We have made several enhancements to the Mail System. We even added some
level of security by applying the PGP protocol. But protection using security
levels is still missing from the scene.
Motivation
We add the protection functionality, because we want to test how easily we can
combine di erent views into one object. The existing views of Mail will be
combined with the views of a new class SecureDocument, which acts as the
security wall for the MailMessages.
Semantic Structure
The next version of the Mail System, the Protected Mail System, combines
the existing views of the Warning2 Mail System with views that exist in the
SecureDocument class.
SecureDocument implements a securityClearance view with a security
level attached to it. The view is active when the security level of the calling
object is su cient with respect to the security level of the document.
The implementation of this SecureDocument must conform to the
Multiple Views semantics, because we are going to combine the views on SecureDocument
with those on Warning2Mail.
Because the user who wants to set or read the message contents has
to have security clearance, we need to de ne a new user class that adds this
functionality to Mail users. The class is called ProtectedUser, and has
methods for setting and retrieving the security level of the user.
The semantics of the getMailContents and the setMailContents will be
enhanced, because the view securityClearance must be checked.
Two di erent implementation alternatives are possible here. The SecureDocument
only implements a view. This functionality can be included
in the new ProtectedMail class directly, sothe implementation uses single
inheritance. Another, more illustrative solution uses multiple inheritance, and
de nes SecureDocument as a separate class.
The ProtectedMail class is the combination of the Warning2Mail and the
SecureDocument classes. The view set thus is also the combination of the

3.3. Conclusions 35
class SecureDocument:public Object f
:::;
protected:
int isSecurityClearance(Object );
:::;
g;
class ProtectedMail : public Warning2Mail, public SecureDocument
f
public:
virtual void setMailContents(Object ,char );
:::;
g;
void
ProtectedMail::setMailContents(Object sender, char s)
f
CFilter(this!isSecurityClearance(sender),
Warning2Mail::setMailContents(sender,s));
g
inherited views:
Implementation Consequences
Figure 3.11: View Composition in C ++
[
VprotectedMail = Vwarning2Mail VsecureDocument
(3.10)
In C ++ we use multiple inheritance to combine the classes Warning2Mail and
SecureDocument. In Figure 3.11 we can see that we only have to rewrite
the method-view coupling of getMailContents and setMailContents, where we
directly refer to view de nitions from parent classes (in this case SecureDocument).
3.3 Conclusions
In this chapter we have de ned a model for Multiple Views. Also, we listed the
possible adaptations to the model, and de ned a running example that showed
us how Multiple Views can be implemented in a \conventional" object-oriented
language like C ++.
We have seen that using such a language has several drawbacks when we
want to implement a semantic-rich concept like Multiple Views. It turns out
that C ++ lacks the following properties:

36 Chapter 3. Modelling Issue: Multiple Views
Static meta information, such as the class of an object, or the methods a
certain class has. In short, we cannot ask some class or object questions
about its de nition.
Dynamic meta information, such as the sender and the parameters of a
message, or information about when the message was sent. We have seen
that all this information was to be given by the programmer, something
we could not check and control.
A central entrance point for all incoming and outgoing messages for an
object, where we can guard and control what is going on in the objects.
This has the consequence that we cannot neatly separate the methods
from the views, without making strict coding conventions, which of
course are error-prone. Further, as we have seen already too often, that
a lot of recoding was necessary, which was the consequence of a missing
central entry point.
In short we can say that implementing Multiple Views in a language like C ++
is possible, but that it results in code that is not maintainable very well. One
has to realise that a lot of recoding must be carried out when adaptations to
the software models must be made. Moreover, one has to stick with coding
conventions, because otherwise the scheme will simply not work. This is a very
undesirable situation, because errors can easily occur, and are very di cult to
detect.
A lot of the exposed problems are there, because we wanted the views
to be composable. Ifwe had implemented view semantics in the methods themselves,
we could not have adapted views or method semantics independent from
each other. This means that using views in the wrong way would have broken
the reusability property of object oriented problems, therefore making the
introduction of views in a software model not composable with other future
adaptations of the system.
Smalltalk implementation
We did not give the example code in Smalltalk, but we will give some hints
about it here.
Access control We can not prevent objects from calling any method that is
de ned at the interface of another object. This is a problem, because we separated
the methods from the method-view mappings in our C ++ implementation,
and made the original methods invisible for the outside world. We cannot do
this in Smalltalk.
Context information In Smalltalk, context information is not explicitly available.
There is a possibility however to extract the sender of a message from the

3.3. Conclusions 37
execution context of a message. This is not trivial however, and requires inside
knowledge of the Smalltalk implementation that is used.
Meta information In Smalltalk, every object in the system has a corresponding
class associated with it, which we can access and inspect at runtime. So, meta
information is fully available in Smalltalk.
Central entry point for method execution We also have no special central entry
point for methods in Smalltalk. Just like inC ++, wehave to separate methods
from method-view mappings by renaming the original methods to something
like pure.... We can prevent heavy rede nition of methods like inC ++ however
by taking advantage of the doesNotUnderstand mechanism. If we do not de ne
explicit normal methods, the Smalltalk runtime system cannot nd the method,
and will raise an exception and call the doesNotUnderstand method. Here we
could de ne global mappings for the entire object.

38 Chapter 3. Modelling Issue: Multiple Views

Chapter 4
Modelling Issue: Layering
When we use something that does not completely satisfy our needs, we adapt
it conform our wishes. The best way of doing this, is leaving the original thing
intact, so others can use the original, and you have a clear overview of your
changes.
In this chapter we will cover the domain of layering. When adaptations to things
(objects) are incremental, i.e. without tampering with the original, we will call
this incremental change a layer. When we want yet another change, we create
another layer. In this way, several layers can be built upon one object, re ecting
several successive adaptations.
In Section 4.1 we discuss our layering model. Section 4.2 then covers the
C ++ implementation of the de ned scenario with a running example. Conclusions
are summarised in Section 4.3.
4.1 Modelling Layers
In Section 4.1.1 we introduce layering as a modelling mechanism. A more formal
model will be presented in Section 4.1.2. Here we de ne the model itself, and
which changes we expect to occur in the model. Just as in the previous chapter,
we then de ne a scenario which covers the di erent changes in the model in
Section 4.1.3.
4.1.1 What is Layering?
People have the urge to arrange things. This is also the case with software
components, and also within software components. We already have seen that
object interfaces can be divided into several sections, called views, to achieve
complexity reduction. We call this vertical object division. In this chapter we
will discuss horizontal object division, called layering. 1 Layering emerges from
two activities:
1. Compare Figures 3.1 and 4.4.
39

40 Chapter 4. Modelling Issue: Layering
Messages
Object
(a) Object without layer
Messages
Object
Layer
(b) Object with layer
Figure 4.1: Object Layers
workHarder
gotoSleep
Person
Employee
Figure 4.2: Role playing modelled with a layer
Messages
Object+Layer
(c) Layered Object seen
from the outside world
Extending happens when some object structure exists, and we need a (slightly
modi ed) version of it. In that case, we take the existing structure as our
starting point, and build our enhancements on top of it.
Dividing happens when no object structure exists, and we are creating a new
one. We want this new structure to be understandable, maintainable and
reusable. Therefore we divide the structure into parts, and the individual
objects into layers.
In both ways, we go from the situation in Figure 4.1(a) where we just have an
object, to the situation in Figure 4.1(b) where the object is wrapped in a layer.
Note that the environment is not aware of the presence of the layer, it is
as if one talks to one monolithic object (See Figure 4.1(c)).
A lot of modelling issues can be represented by layers. Role playing for example
can be extremely well modelled with a layered architecture. In Figure 4.2, we
see a Person with a role Employee attached to it. When the role must be
played (during working hours), the Employee layer will be activated. This can

4.1. Modelling Layers 41
Hardware
Drivers
System functions
Additional functions
System utilities
Figure 4.3: The Unix operating system divided into several layers
be done using views.
Layered architectures are found everywhere in software systems. The
most well-known architecture is the OSI communication layered architecture
described in Black (1991). This architecture divides the communication between
software systems in seven di erent layers, each with its own tasks and
responsibilities. Each layer implements some communication protocol, using the
underlying layer(s) as a communication medium.
Layering in software systems is done for several reasons. One of the most important
reasons for applying layering techniques is reduction of complexity. To
achieve this, large software systems are divided into several layers, which can
then be designed, built and maintained more or less independently of each other.
Take for example the architecture of a traditional Unix system. In Figure 4.3
we see that a clean division is made between the functionalities. This categorisation
helps us to understand the implementation of the system. Also in
smaller-scale software systems, such as individual programs (or even program
parts!), layering techniques can be used to reduce complexity.
Another reason for using layering techniques, is separation of concerns.
This separation also enables us to better understand things. One often puts basic
functionalities in the core, and then wraps around this core one or more layers
with special functionalities. This improves the maintainability of the software
system. In the next section we will introduce our model.

42 Chapter 4. Modelling Issue: Layering
Layer 2
Layer 1
Layer 0
Object
(a) Outside world view
4.1.2 Conceptual Layering Model
Figure 4.4: Layered Object
Layer 2
Layer 1
Layer 0
(b) Detail view
Object
Until now, we have seen a layered object only from above, like in Figure 4.1(b).
In Figure 4.4(a) we see another way of showing layers inside an object. This
sideview shows a horizontal division of the object. Note that we donot see from
the outside (from the interface) that the object is divided into several layers.
Figure 4.4(b) shows us the internal structure of the object. It appears to consist
of three individual objects that are related to each other. This relation will be
discussed later in this chapter.
We will describe the model of layering from three di erent viewpoints.
Functionality. Functionalities from the requirement speci cation can be
mapped to object implementations in di erent ways;
Level. Layers can represent direct object functionalities, or functionalities
that lay on a higher (meta) level;
Structure. Layers can be attached to objects in a static (compile-time)
or a dynamic (run-time) way.
These are not independent of each other. We will discuss the viewpoints independently
from each other rst. Thereafter their inter-relationship will be
discussed.

4.1. Modelling Layers 43
Func1
Func3
Func4
Func2
Func5
Requirements
Functionality Mapping
T(F1)
T(F3)
T(F2)
T(F4)
T(F5)
MethodA
MethodB
MethodC
MethodD
Object
Figure 4.5: Conceptual Model of Layering
Object functionalities that are present in the requirements must one way or
the other be represented in the object model. This can be done by mapping
the functionalities to parts of the object model. This divides the layering model
into three di erent parts:
Functionalities
Transformations
Methods
As can be seen in Figure 4.5, these transformations can manifest themselves in
several ways. It is possible that
1. One functionality transforms to one method (T F1 );
2. A functionality transforms to a couple of methods (T F2 );
3. Some functionalities transform to one and the same method (T F3 and T F4 );
4. A functionality does not transform to a method, but instead has some
e ect on the object as a whole (T F5 ).
Here, TF1 is the simplest transformation. It directly maps a functionality
to an object method. Note that functionalities and methods can exist in any
granularity. Therefore, transformation TF2 can occur, where some coarse grained
functionality maps to several ne grained methods. These two cases are the same
for us, so we will use either one.
When two (or more) functionalities map to the same object method, we
have transformations TF3 and TF4 . If this is the case, we cannot use functionality
F3 and F4 independently from each other. Nonetheless, they are (probably)
independent functionalities. In this situation, often one of the two functionalities
maps directly to the method, as in TF1 , while the other maps indirectly to the
method, thus in fact being a side e ect of the normal functionality.

44 Chapter 4. Modelling Issue: Layering
Object versus Meta Level Layering
Functionality can be object level or meta level functionality. We de ne functionality
as object level, when all information necessary for the functionality
is present at the object level. Besides this, the functionality must directly be
mapped to a method representing exactly that functionality, instead of being
some side-e ect of another method representing some functionality. All other
functionalities are de ned to be at the meta level.
Object Level Layering Object level layering is the most commonly used way of
layering. The existing functionality of objects is modi ed or extended by adding
layers to the objects. Object level layering comes in two avours.
Inheritance Normally, when class libraries are designed, the top level
classes are the most abstract, and de ne layers with most of the basic functionality.
The leaf classes of a class tree are very speci c, and de ne operations that
make use of the basic functionalities of the \root" classes. When a class must be
adapted or extended for a certain reason, a subclass is created which overrides
or extends the default behaviour. In layer terms, an extra layer is added to the
objects which implements the wanted behaviour.
Delegation A less-known version of object level layering is delegation.
With delegation, the classes are not connected by sub-superclass relations. An
object encapsulates an internal object, to which some functionalities are delegated.
With this mechanism it is also possible to hide some or all the functionalities
of the encapsulated object. In this case, delegation resembles a part-of
relationship.
Lieberman (1986) evaluates and compares both implementations of object
level layering, and concludes that delegation is a richer mechanism. This
conclusion is based on the fact that inheritance can be simulated with delegation,
while it is impossible to simulate delegation with inheritance.
Meta Level Layering With meta level layering, layers are constructed by reifying
elements of object systems. Object systems are constructed with objects and
messages. Theoretically, both elements can be rei ed, which means that information
about the element itself is made available as a rst class object.
Re ection-based layering, as meta level layering can also be called, is
discussed in detail by Ferber (1989). He identi es three re ection mechanisms.
Class-Based Re ection All objects of a certain class have the common
meta-object, which is the class, attached to it. This meta-object implements
the method dispatch function dependent on the desired behaviour. All objects
of some class have the same behaviour then.

4.1. Modelling Layers 45
Object-Based Re ection In object-based re ection, all objects have a
potential meta-object attached to it. This meta-object is not the class of the
object, neither do objects share meta-objects.
Re ection of the Communication Process When the messages that are
sent in the system are all instances of class Message, we have an explicit
re ection of the communication process. When speci c behaviour is desired
then, a subclass of Message can be de ned, which implements this behaviour.
Static versus Dynamic Layering
Until now, we only discussed layers as being chunks of object speci cations that
can be attached to objects. We did not discuss how they can be attached to
objects.
Static Layering With static layering, one or more layers are bound to classes
at compile time. This means that, after the program is build, it is impossible
to change the layering of the objects in the system.
This is a big problem in software engineering. When a system evolves, the
number of functionalities that objects must support grows steadily. Often, large
parts of objects are only necessary for a short period of time, or are only used
by speci c parts of the system. This is especially the case with role playing. It
is impossible to foresee all future roles for all individual objects. Also, we get a
lot of classes that only exist because of the combination of roles and/or features
of objects. Consider for example a class Person and the roles Employee and
Manager. We must de ne the classes Person, Employee, Manager and
EmployeeAndManager to support all possible combinations.
Now suppose we also de ne a property called Barking, which de nes
that a barking sound is produced with every method invocation. The we must
de ne four new classes: BarkingPerson, BarkingEmployee, Barking-
Manager and BarkingEmployeeAndManager. One can see that this gets
worse with every new role or property we add.
Figure 4.6 shows the described situation. To create a Person who is at the
same time Employee and Manager, and who also must bark, we must create
the appropriate class BarkingEmployeeAndManager which incorporates
all wanted properties.
There is another drawback with this construction. It is not possible to
switch from one role to the other without losing object identity. Note that,
independent of the current role of a Person, he or she will always remain a
Person (Wieringa and Jonge 1991a, Wieringa and Jonge 1991b). With our
example, it is not possible to remove the Barking property, or to replace the
Manager property with something like Director.

46 Chapter 4. Modelling Issue: Layering
Person
Barking
Employee Manager BarkingPerson
EmployeeAndManager
BarkingEmployeeAndManager
aBarkingEmployeeAndManager
Figure 4.6: Static layering generates complex class structures
Dynamic Layering The problems with static layering disappear when we use
dynamic layering. In this case, we de ne the layers more or less independent
from each other, and attach the appropriate layers to the objects at runtime.
So in our example, we de ne an object class Person, and three individual
classes Employee, Manager and Barking. Now, when we have a Person
who becomes a Manager, we attach a Manager layer to the Person object. If
we then want this Manager to start barking, we attach aBarking layer to it.
In Figure 4.7, we see the same situation as in Figure 4.6, but now with
dynamic layering. We can see that the class structure is much simpler now.
Moreover, it is very easy to extend the class structure with additional roles and
properties. This mechanism closely re ects Object Composition.
What Can We Do with Dynamic Layering? Dynamic layering enables us to
manipulate object behaviour and structures at runtime. With this technique,
we can do interesting things.
Dynamic Role Playing We can explicitly distinguish between objects
and the roles they must play. When carefully designed, it is very easy to congure
an object with certain roles, and add others later. It is also possible to
de ne new roles at a later stage, without rede ning other object speci cations.

4.1. Modelling Layers 47
Person EmployeeRole BarkingProperty
ManagerRole
aPerson
anEmployeeRole
aManagerRole
aBarkingProperty
Figure 4.7: Dynamic layering keeps class structures simple
Behaviour Injection We can add new behaviour to, or recon gure existing
behaviour of any object. We can de ne subsystem-speci c behaviour separately
from the original object, clearly distinguishing between the intrinsic
features of an object that is stored in the class itself, and the extrinsic features
of an object that is stored in the layers (Minsky and Pal 1995).
Protocol Injection and Conformance When two or more objects must
communicate, they must conform to some protocol. Normally, when these objects
are not designed that way, their speci cations must be rewritten or extended,
introducing a lot of problems and sources for problems. With dynamic
layering, we can let objects \explain" their own protocol to communication candidates
by injecting their own protocol into these candidate objects. This way,
we prevent enormous object speci cations consisting of many protocols. All protocol
speci cations are de ned separately, which makes using and maintaining
these protocols much easier.
Separate Behaviour from Control Often, a layer can be divided into behaviour
and control of that behaviour. Think for example of a layer that records
history information. Next to the actual recording and displaying of history information,
it is possible to provide control functions like starting, stopping and
clearing of history information. Because we represent layers as rst-class objects
with dynamic layering, it is possible to record history information from one object,
while we control history recording from another object, like in Figure 4.8.

48 Chapter 4. Modelling Issue: Layering
Obj1 Obj2
HistoryRecorder HistoryRecorder
Operator
HistoryControls
Figure 4.8: Separate Behaviour from Control: History recording of objects Obj1
and Obj2 is controlled by anOperator
Coordinated Behaviour Until now we assumed that the dynamic layer
resided somewhere inside the target object. The layer can reside somewhere outside
the object too however. We have already seen this in Figure 4.8. In (Aksit
et al. 1993), this phenomenon is discussed in more detail, although dynamic
attachment is not addressed.
The paper gives an example of coordinated behaviour using a de ned
ReferencePoint class. Objects of this class are constrained by some Figure
object, which ensures that ReferencePoints do not extend the gure's boundaries.
The constraint is hard-coded in the de nition of the ReferencePoint
however, which prevents the class from being reused when other or none of such
constraints apply. In fact the constraint is only valid in the context of a Figure
object. With dynamic layering, we can model this more precisely, resulting in
models that are more exible.
Single Public versus Multiple Private Properties Object properties often
apply to the object in general, which means that the property more or less
is visible to all potential client objects. Sometimes however, object properties
purely exist because client objects assign these properties to the server object.
In the real world, this happens all the time.
A good example are sweet names. When person A assigns a sweet name
to person D, the sweet name belongs to person D, but is only visible to person
A. The sweet name is a property private to person A. Maybe some person C
also has assigned a (di erent) sweet name to person D. This can and may not
a ect the sweet name of person A. Now (lucky guy) person D has two properties
SweetName. Figure 4.9 shows this situation, where Person A and C have private
sweet names for person D, and person B has no sweet name at all for person D.
We can use this feature in software models, where objects often have
some properties especially for some subsystem. With dynamic layering, we can

4.1. Modelling Layers 49
Person A
SweetName
Person B
Person D
SweetName
Person C
Figure 4.9: Multiple Private Properties assigned to one single object
model this simply, without polluting the software model with elements that are
almost never used.
Interrelationship between the Viewpoints of the Model
How do the di erent viewpoints of the model relate to each other? The functionality
view focuses on the semantics of the real world. This results in objectlevel
or meta-level layering, which expresses semantics of the object model. This
model can be implemented in a static or a dynamic way.
In the next section, we will describe a scenario, where functionality changes will
result in object- and/or meta level layers.
4.1.3 Scenario of Changes
In this section, we will focus on the impact of the various transformations on
the software model that represent the requirements. This scenario is based on
the functionality mapping viewpoint. We will see that some functionalities are
at the object level, while others transform to meta level layers.
When manipulating functionalities, the following changes are possible,
where the transformations refer to Figure 4.5:
Add methods (T F1 and T F2 );
Rede ne methods (also T F1 and T F2 );
Extend methods (one of T F3 and T F4 );
Add object-orthogonal behaviour (T F1 ).
These operations can occur inside every layer. We can also de ne operations on
layers themselves:
Add Layer;
Remove Layer;
Compose object with several layers.
These operations are only meaningful when we use dynamic layering. First, this
section only focuses on static layering. After that, we repeat the scenario in one
step using dynamic layering.

50 Chapter 4. Modelling Issue: Layering
Add Methods
When we want to add methods to an object using a layer, we are adding functionality
to the object using transformation TF1 of Figure 4.5. It is also possible
that we complete already existing functionality by providing appropriate definitions
of abstract methods, or de ne new abstract functionalities by de ning
\incomplete" methods (For example Pree's (1994) template and hook methods).
Rede ne Methods
Often, the addition of a functionality required changes to the de nitions of other
functionalities. This means that the appropriate methods have to be rewritten.
This can be done in two di erent ways:
1. rede nition;
2. extension.
Rede nition of the method means that the original de nition is not being used
anymore. This is often seen as an encapsulation violation, because complete
rede nition requires detailed knowledge of the target object.
When the original de nition is used, we in fact extend the original de -
nition. We will see an example of this in the next section. Note that this form of
method extension is not called this way any further, because we de ne method
extension as described next.
Extend Methods
When we add functionalities, but attach them to already existing methods, we
call this method extension. We refer to transformation TF3 and TF4 of Figure 4.5.
One of these functionalities represents the already existing method. The other
one will be added in a new layer. Because this new functionality will be a
side e ect of the method, we discuss this separately from the extended method
rede nition mentioned above.
Add Object-Orthogonal Behaviour
If the functionality that we want to add is not speci c for the target object, we
follow transformation TF5 of Figure 4.5. The functionality will in principle be a
side e ect of all methods of the target object.
Dynamic Layering
We mentioned three operations on layers at the beginning of this section:
Add Layer;
Remove Layer;
Compose object with several layers.
Because removing a layer is in fact the reverse of adding and composing layers,
there is nothing special with it, besides the possibility of invalidating other
layers that depend on the removed layer. We will not discuss the removal of
layers here.

4.2. C ++ implementation 51
Object
Legend
User Mail MailHandler
HUser HeadingMail
AUser AttachmentMail
MVUser UserSystemViewMail
RNUser ReadNotificationMail
HisUser
Normal class
Normal class (with overhead)
Overhead class
HistoryMail
Figure 4.10: Layering Scenario
MVMailHandler
Add Methods
Redefine Methods
Prepare for Extend Methods
Extend Methods
Add Object-Orthogonal Behaviour
The best way of showing how layers can be added to a target object,
and composed through dynamic layering, is de ning the same layers as in the
previous sections, and attach them to the target object at runtime.
4.2 C++ implementation
In this section, we will discuss the C ++ implementation of the scenario discussed
in Section 4.1.3. We will start with a Simple Mail System, as described in
Section 3.2.1. The rest of the scenario is depicted in Figure 4.10.
4.2.1 Add Methods: Heading Mail System
In this section, we extend the MailMessage with a heading. We will use this
heading for textual representation of information about the MailMessage itself,
apart from the body of course.
Scenario direction

52 Chapter 4. Modelling Issue: Layering
char
HeadingMail::getMailAsText(void)
f
:::;
c this!getMailContents();
h this!getMailHeading();
:::;
return r;
g
Motivation
Figure 4.11: Never access \lower level" structures directly
MailMessages are presented to the User with special mail readers. These readers
normally construct a header containing certain information about the MailMessage
itself, like the MailOriginator and the MailReceiver. In this section, we discuss
the implementation of a HeadingMail, which is capable of constructing
such a header.
Semantic Structure
The functionality that this layer provides is, at least in the static implementation,
2 very simple. The transformation of this functionality isoftype T F1 .
We must be prepared to future adaptations however, and never manipulate
nor access internal structures of the target object directly. Ifwe do this,
we can never adapt the \behaviour" of the internal structures in another layer
later. We will show that it is important to use a certain coding convention in
order to achieve maximum exibility.
Implementation Consequences
In the implementation, we have to con rm to certain coding principles to avoid
breaking reusability. Johnson and Foote (1988) give us several guidelines to
create class structures that are reusable. Later, Lieberherr and Holland (1989)
describe the Law of Demeter, which goes further and dictates some independence
rules by law.
To decouple the classes Mail and HeadingMail as much as possible,
all references to the instance variables is implemented by sending messages to
this, which inC ++ stands for the receiver of the message (See Figure 4.11).
In HeadingMail two methods are de ned, called getMailHeading and
getMailAsText. getMailHeading returns a textual presententation of the heading
information, while getMailAsText returns a complete textual representation of
the MailMessage, in fact combining the header with the contents. Appendix C.1
2. See Section 4.2.5 for a discussion about the dynamic implementation

4.2. C ++ implementation 53
lists the complete C ++ implementation. Note the this reference calls in the
methods as in Figure 4.11.
4.2.2 Rede ne Methods: Attachment Mail System
In this section, we extend the mail system by allowing the User to attach les
to the MailMessage.
Motivation
Sometimes, a textual MailMessage should be accompanied by extra documents,
like enclosures with a letter. These are called attachments, and in this section
we are going to de ne class AttachmentMail, which is capable of storing and
sending Attachments accompanied with a MailMessage.
Semantic Structure
By adding this functionality, we have to rede ne the heading de nition provided
in HeadingMail. If there is an Attachment present, we must include
information about it in the mail header. Note that the existing header should
not be touched, we only want toadd something to it.
Implementation Consequences
In this scenario step, we add the functionality of attachments to the Mail-
Message. Therefore we de ne a separate Attachment class to hold the actual
attachment. Besides this, the Attachment must be placed into the MailMessage.
We de ne methods setMailAttachment and getMailAttachment for this task.
For the rede nition of the mail header, we override the getMailHeading
method. It calls the original getMailHeading, and adds a line about the attachment
to it, like in Figure 4.12. Note that if there is no attachment present, the
extra functionality is skipped, as if the method did not exist. We will show a
much neater implementation using dynamic layering in Section 4.2.5. In this dynamic
implementation, the attachment functionality and the rede ned header
are de ned in the separate attachment-layer, which can be connected to the
Mail object at runtime, causing no overhead at all when no attachments are
used.
4.2.3 Extend Methods: ReadNoti cation Mail System
In this section we implement a scheme for transparent noti cation of a Mail-
Message read to the MailOriginator.
Motivation
If important or time-critical MailMessages are sent by mail, the MailOriginator
wants to know when the MailReceiver has read the message. This of course has
to be transparent to the MailReceiver.

54 Chapter 4. Modelling Issue: Layering
char
AttachmentMail::getMailHeading(void)
f
:::;
h HeadingMail::getMailHeading();
if ( attachment NULL) f
== Use original de nition
s h;
g else f
== Extend heading with attachment ref
s h+:::;
g
return s;
g
Figure 4.12: Rede ned methods basically extending functionality must call the
original method, and often are conditional in their extension
Semantic Structure
This functionality has the important property that it is transparent to the user.
This means that it also must not be re ected in the interface of the object. This
functionality should be implemented in such away that the calling environment
does not have to be adapted to enable read noti cation.
This means that the functionality must be implemented in the getMail-
Contents method, which is the only place where we can detect that a MailMessage
is being read. Now we have situation TF3 =TF4 from Figure 4.5, where we
have two functionalities, namely read mail and automatic read noti cation,
combined into one method, namely getMailContents.
In order to make the program adaptable, we must one way or the other
separate the two functionalities in the implementation. Only then will it be
possible to rede ne the two functionalities independently of each other.
Implementation Consequences
In fact, we do not only want the functionality to be invisible in the interface,
we also want ittobeinvisible in the (normal) implementation of the object.
This causes the functionality to result into a meta layer. It \stands
above" the normal execution of the program, more or less extending method
execution semantics for one particular method. This is done by pre xing the
actual method execution by generating a reply containing a read noti cation to
the MailOriginator.
We can only detect the invocation of getMailContents inside the method
itself. We therefore separate invocation and execution into two methods get-
MailContents and pureGetMailContents, using the same mechanism as we did

4.2. C ++ implementation 55
char
ReadNoti cationMail::getMailContents(Object sender)
f
if (this!senderIsReceiverAndMustNotify(sender))
this!notify();
return UserSystemViewMail::getMailContents(sender);
g
Figure 4.13: Separate Mail Read and Send ReadNoti cation functionalities
for implementing multiple views. This way, we separate the two functionalities
into two methods (pureGetMailContents and sendReadNoti cation), and couple
them in the message invocation method getMailContents (See Figure 4.13 for a
coding extract of Appendix C.3). We can see in Figure 4.10, that we reused the
coding scheme we introduced in Section 3.2.2. Therefore we did not de ne the
pureGetMailContents method, and also did not call it from the getMailContents
method from Figure 4.8. If we had done this, we had ignored other method
entry semantics (like the views of UserSystemViewMail.).
4.2.4 Add Object-Orthogonal Behaviour: History Mail System
We now add the recording of historical information about message sends to our
mail system.
Motivation
We want to keep track of what objects sent what methods to which target
objects at what time. Wewant this for debugging our ReadNotificationMail
implementation for example.
Semantic Structure
This scenario step corresponds with transformation TF5 of Figure 4.5. We add
functionality that has an e ect on the complete object. Of course we do not
want to record history information in the methods themselves, because adding
or rede ning methods in subclasses would require new explicit history recording
code. Further, history recording is standing \above" normal method execution,
resulting in a meta layer, just as with the ReadNotificationMail class.
We also want meta-information in our history report, namely the name
of the methods that are invoked. If the computational model does not provide
this information, we must work around this problem.
Implementation Consequences
To implement this functionality in a composable way, wehave to use the same
implementation scheme as in the ReadNotificationMail class. There is one

56 Chapter 4. Modelling Issue: Layering
void
HistoryMail::setMailReceiver(Object sender,MVUser user)
f
this!doMeta("setMailReceiver",sender);
ReadNoti cationMail::setMailReceiver(sender,user);
g
Figure 4.14: Every method has to be rede ned to implement history information
recording
big di erence however. In HistoryMail, we must adapt the behaviour of all
methods, instead of just one. Therefore, we must rede ne all interface methods
of the mail class, and add history information recording code to it.
In Figure 4.14 we can see one of all methods that had to be (re-)de ned
to implement HistoryMail. The problem here is essentially the same as the introduction
of Warning2Mail in Section 3.2.6. There we also had to de ne the
same functionality for a set of methods (although the functionality inWarning2Mail
was limited to four methods). If in some subclass a new method is
introduced, the history recording code must explicitly be de ned for the new
method then.
We can see another analogy between Warning2Mail and History-
Mail. Both need to know which method is currently active. This information
is not explicitly available, and thus we must provide this information ourselves.
4.2.5 Dynamic Layering: Dynamic Mail System
We repeat two scenario steps from the previous sections using dynamic layering
now.
Motivation
Until now, we have enhanced the mail system with several functionalities. The
problem is, that all these enhancements have to be known and speci ed prior
to using the mail system. Therefore, we want to implement a DynamicMail
system, which is capable of including any possible enhancement which we can
think of in the future.
Semantic Structure
The semantic structure of the dynamic mail system is completely di erent from
those we have already seen. The structure must be capable of handling all
possible transformations from Figure 4.5.
This can be done by de ning a generic layer that can be added to the
target object at runtime. Di erent layers with di erent functionalities can be
implemented upon this generic layer, and then be tted to the target object
when appropriate.

4.3. Conclusions 57
Implementation Consequences
The GoF book (Gamma et al. 1995) identi es this structure as the Decorator
pattern. By using this pattern it is possible to add behaviour to an object at
run-time. The pattern has several drawbacks however. The book itself mentions
(amongst others) the object-identity problem. The decorated object has not
the same object-identity as the original object. Of course this is an undesired
situation.
A drawback of using this pattern which is not mentioned in the book
is the following. In the implementation of the DynamicMail, we have the
same problem as in HistoryMail, as we have no way of uniformly modify
the behaviour of all methods. This means, that we have to re-implement all
methods again for meta-level layers.
The interface conformance requirement has important drawbacks on the
exibility of the pattern. For example, meta-level layers can only operate on
the small interface de ned by the abstract Component class. Also, layers are
incapable of adding functionalities to the object, when they need to add methods
to the class for it (which would require us to rewrite class speci cations, which
violates the reusability requirement of an object model).
The Decorator pattern requires us to write a lot of overhead code.
Look for example at Figure 4.15. We can see that one simple function takes
three declarations to work. Also, for each meta-level layer, we have to specify
all methods again. Another drawback here is, that the MailHistory is not
reusable as a generic HistoryReporter.
4.3 Conclusions
In this chapter we de ned a model for object layering. We also showed how
several aspects in this model could change, and how this could be implemented
in a language like C ++.
It appears that static object-level layering is very straightforward in C ++.
Meta-level layering is much more problematic, mainly because this cannot be
done orthogonally. The problem base is the same as Multiple Views. In Section
3.3 we also identi ed problems because of the lack of static as well as
dynamic meta information, and the absence of a single message entry point in
objects, which prevents us to model orthogonal behaviour like inHistoryMail
in a proper way.
Dynamic layering is also very problematic. The Decorator pattern
can be used sometimes, but this pattern has important drawbacks, like identity
problem and interface conformance, which prevents a decorator participant from
being reused.

58 Chapter 4. Modelling Issue: Layering
class MailComponent f
:::;
virtual void send();
:::;
g
class DynamicMail : public MailComponent f
:::;
virtual void send() f printf("The actual method here..."); g
:::;
g
class MailDecorator : public MailComponent f
MailDecoratorfMailComponent pg fcomponent p; g
:::;
virtual void send() f component!send(); g
:::;
private:
MailComponent component;
g
class MailHistory : public MailDecorator f
:::;
virtual void send() f printf("Do some meta work");
MailDecorator::send(); g
:::;
g
Figure 4.15: C ++ example of one simple function in a Decorator pattern

4.3. Conclusions 59
Smalltalk implementation
We did not give the example code in Smalltalk, but we will give some hints
about it here.
For meta-level layering, the same remarks apply here as we have given
for Multiple Views. For dynamic layering, we can address the following issues,
based on the Decorator pattern.
Identity problem Smalltalk has a method called become:, which at runtime
shifts an object to another class. With this mechanism, the identity problem
could be eliminated.
Interface conformance In Smalltalk, we can use the doesNotUnderstand mechanism
to automatically forward incoming methods to next layers (and eventually
to the target object).

60 Chapter 4. Modelling Issue: Layering

Chapter 5
Composition Filters Solutions for the Modelling
Issues
In this chapter we will describe the solutions for the examples from Chapters 3
and 4 in the Composition Filters Object Model. In Section 1.1, we mentioned
the language Sina that supports this model. In Section 2.1 we already discussed
the model. Because we use Sina in this chapter for implementing the examples,
we will rst brie y introduce some features and caveats of the language in
Section 5.1. Then, in Sections 5.2 and 5.3 we discuss the Sina implementation
of Multiple Views and Layering respectively. The corresponding full-text code
listings are in Appendices B and D.
5.1 The Sina Language
This section is based on Koopmans (1996).
In this section, we will brie y discuss the Sina language, with respect to the
Composition Filters Object Model. This chapter implements techniques for
Multiple Views and Object Layering in the Composition Filters Object Model,
using the Sina language. We will discuss some problems with the language in
this section.
Sina is implemented in a multi-threaded environment. This means that a program
can have more than one active object at some point in time. To prevent
problems with this, the Sina compiler defaults to standard single-threaded objects,
which in turn means that within one single object, there will only be
one thread active. When a method is executed in an object, all other incoming
messages are blocked until the executing method has nished. We will see
some problems with this feature, because objects can ask information from each
other, resulting in deadlock situations as in Figure 5.1 on page 63, which will
be explained in the next section.
Another problem is that Sina does not implement a meta object model,
like Smalltalk does. There is some rudimentary implementation available, but
61

62 Chapter 5. Composition Filters Solutions for the Modelling Issues
this is not very usefull now. This is related to some problems with the Composition
Filters Object Model however, because we do not know when to identify
two object as members of the same \class" yet (mainly because objects can
change dramatically during their lifetime, see dynamic layering for example).
5.2 Multiple Views
In this section, we will show the Composition Filters solution of the Multiple
Views problem. We will follow the same scenario we used in Chapter 3, and
compare the Composition Filters solution with the C ++ solution from Chapter 3.
5.2.1 Simple Mail System
In the implementation of the MailHandler class, there is a di erence with
the C ++ implementation. Although we did not mention it in Chapter 3, the C ++
class MailHandler was constructed according to the Singleton pattern. 1
In short, this pattern is used to enforce that only one instance of some class
exists. Because the Composition Filters Object Model lacks an interface to
instance creation primitives, it is not possible to control these primitives with,
for example, views. So, in Sina we cannot implement the Singleton pattern.
There is another problem with the MailHandler class. Note the early
return in the body of send. The default behaviour of a method prevents multiple
execution threads in an object. This statement prevents a deadlock in the
MailHandler, because the MailMessage will print the name of the MailHandler
through the getName method, which will be delayed until the send message
has terminated. See Figure 5.1 how the deadlock situation emerges. The Sina
reference manual (Koopmans 1996, Chapter 10) warns for this situation. The
warning dictates not to send any messages to self or server from a condition.
In this Mail System there is a similar situation, where the MailMessage asks
the MailHandler to deliver it to the MailReceiver.
In the User class, we introduce an early return statement in the receive method
too, for the same reason as mentioned above. Because the Singleton pattern
cannot be implemented in Sina, we access the global MailHandler object in the
Mail class through an external variable.
The rest of the implementation is rather trivial. It closely resembles the
implementation of the C ++ solution.
5.2.2 Add Views: UserSystemView Mail System
In this section we discuss the implementation of views in Sina. We can see how
easy it is to support view semantics in this language, because the properties that
we need to support views are part of the language model. Note that only the
1. The Singleton pattern is discussed in (Gamma et al. 1995)

5.2. Multiple Views 63
MailHandler MailReceiver
receive
DEADLOCK
getName
send receive
Figure 5.1: Deadlock ofsend message in the MailHandler
Mail class needs to be updated to support views. The User class is subclassed
only to implement another test method that uses the new UserSystemView-
Mail class.
The UserSystemViewMail class declares the two views userView and
systemView, and couples the views to the methods with lter expressions. These
lter expressions accept incoming messages when the condition (view) is true
and the method selector matches. When the method selector matches, but the
view is not active, an error is raised (because of the Error lter that is used).
The match between the view model from Section 3.1.2 and the Composition
Filters Object Model is as follows. The method set M o is not changed in the
view model. In this section we only add views, so the method set in the Sina
implementation is not changed either. We can see this in the implementation of
UserSystemViewMail, where we inherit from the Mail class, and therefore
do not have to rede ne any features from the class Mail. We do have to de ne
the views and the method-view mappings here.
View De nitions
Normally, view de nitions are rather trivial. We will see this in the next sections,
where we will de ne some easy-to-implement views. The views userView and
systemView however are not easy to implement, because we want to restrict
access to objects of the classes User and MailHandler and their subclasses
respectively. The Sina language does not support a meta-object or classes as
objects. Therefore it is not simply possible to ask a Sina object for its type. It

64 Chapter 5. Composition Filters Solutions for the Modelling Issues
View Method OK
View Method p
:View Method
View :Method p
:View :Method p
Table 5.1: Possible mappings between methods and views
is even more di cult to determine any type-subtype relations, because of the
dynamic behaviour of Sina class interfaces. In our implementation we used the
isKindOf method, a method which in fact is not available.
Method-View Mapping Semantics
For a better understanding on how a view is implemented with a lter expression,
we will rst elaborate on what lters do with messages.
For simplicity, we restrict to the situation where we need the mapping
between one view and one method. In Table 5.1, we see the four possible actual
situations for a message. The rst means that the view is active, and that the
listed method is called. In Table 5.1 we also see that this is OK, which means
that the method is allowed to be executed. When the method is called, but the
view is not active, we want to raise an error. For the other two situations, we
see that when another method is called, we are not interested in this situation,
so we accept this.
The lter expression that implements this behaviour, thus has to exclude
the \bad" situations from Table 5.1. All other situations have to be accepted.
Because of the semantics of a lter expression, we have to construct a
lter expression that shows what is allowed in a message pattern instead of what
is not allowed. 2 Bergmans (1994) also recognises this problem. So in order to
realise the values from Table 5.1, we list the three OK values from this table.
The remaining situation(s) will not match the lter expression and thus will
raise an error in the error lter. See Figure 5.2 for an example listing of a class
with one view-method coupling.
5.2.3 View Partitioning: OriginatorReceiverView Mail System
In the OriginatorReceiverViewMail class, we re ne the userView of the
UserSystemView Mail System. Therefore we de ne two new views originatorView
and receiverView. Note that both these views have smaller result sets
than the original userView. This is an obliged property, because of the andcomposition
of views on the same method(s) through subclasses. The mappings
2. When a runtime message matches a lter element, the message is allowed to continue.
When it has passed all lter elements, and thus is still not accepted, the lter acts according
to its type (the error lter will raise an exception, for example)

5.2. Multiple Views 65
class UserSystemViewMail interface
:::;
internals
mail : Mail; == Subclass from Mail
conditions
userView;
systemView;
input lters
mv1 : Error = f userView ) setMailOriginator,
true ; setMailOriginator g;
:::;
end;
class UserSystemViewMail implementation
conditions
userView
begin
return message.sender.isKindOf:(User)
end;
:::;
end;
Figure 5.2: Implementation of method-view coupling in Sina

66 Chapter 5. Composition Filters Solutions for the Modelling Issues
View
ViewA
ViewA
:ViewA
^
^
^
ViewB
:ViewB
ViewB
Method
Method
Method
Method
^OK
p
_OK
p
p
p
:ViewA
ViewA
ViewA
:ViewA
:ViewA
^
^
^
^
^
:ViewB
ViewB
:ViewB
ViewB
:ViewB
Method
:Method
:Method
:Method
:Method
p
p
p
p
p
p
p
p
Table 5.2: Possible mappings between methods and multiple views
from the userView to the methods also have to be rede ned to use the new
views.
Again only the Mail class has to be extended. The VPUser subclass
only de nes a test function that uses the OriginatorReceiverViewMail
class. This class shows how view mappings can be composed.
Composing View Mappings
When we want to place one method under more views, we can do this in two
di erent ways:
And-composition This means that the method can only be accepted if both
views are active.
Or-composition This means that the method must be accepted if at least one
view is active.
Which composition is used in a class declaration is totally dependent on the
situation, and the developer has to choose the right one. Both versions can
be expressed with lters. The and-composition is expressed with two di erent
lters, and the or-composition is expressed with one lter. Table 5.2 depicts the
possible situations, and whether the situation is OK or not for AND- as well as
OR-composition. See Figure 5.3 for an implementation of both compositions.
Filter mv1 uses AND-composition, while lter mv4 uses OR-composition.
This mechanism has the property that subclassing of a class with views
only permits and-composition for more views on the same method. This is a
point of discussion in the TRESE group, but intuitively this is OK, because
otherwise you can break integrity rules of superclasses by bypassing existing
view restrictions.
The implementation of class OriginatorReceiverView shows ANDcomposition
through subclassing. Amongst others, the method setMailReceiver
is restricted by both views userView from the parent class and the originatorView
from the owner class. Of course this has no e ect, because
V userView
V originatorView

5.2. Multiple Views 67
class OriginatorReceiverViewMail interface
:::;
internals
mail : UserSystemViewMail; == Inherit
conditions
originatorView;
receiverView;
input lters
mv1 : Error = f originatorView ) setMailOriginator,
true ; setMailOriginator g;
:::;
mv4 : Error = f originatorView ) getMailContents,
receiverView ) getMailContents,
true ; getMailContents g;
:::;
end
Figure 5.3: Method View Composition
class GroupMail interface
:::;
conditions
originatorView; == Rede ned view
:::;
end
Figure 5.4: View Extension only rede nes the view
But this does depend completely on the de nitions of the views that are involved.
The implementation also shows OR-composition. The method getMail-
Contents can be called by both the mailOriginator and the mailReceiver ( lter
mv4 in Figure 5.3).
5.2.4 View Extension: Group Mail System
In the GroupMail class we extend the de nition of the originatorView. We
check if the \real" originator and the sender of the message belong to the same
group. Note that only the view de nition has changed, directly re ecting the
change of the speci cation (Figure 5.4).
To be able to test group membership of a User, we extend the de nition
of the User class. A GroupUser has a groupNumber attribute, so we can
check if groupNumbers of two di erent users match.

68 Chapter 5. Composition Filters Solutions for the Modelling Issues
class SecureMail interface
:::;
conditions
pgpView;
input lters
dis : Dispatch =f
pgpView->[getMailContents]getPGPMailContents,
pgpView->[setMailContents]setPGPMailContents,
inner. , mail. g;
end
Figure 5.5: Conditionally redirect messages to specialized versions
5.2.5 Dynamic Behaviour Extension: Secure Mail System
For the Secure Mail System, we de ne a new view pgpView on the SecureMail
class. This view is active when the sender of the message supports the PGP protocol.
When the PGP protocol is supported, the new get- and setMailContents
methods that support PGP encoding and decoding are used. Otherwise the
\normal" methods are used.
Therefore we only have to declare the view pgpView, and lter expressions
that modify the get- and the setMailContents to their PGP-aware counterparts.
Figure 5.5 shows how the lter expression redirects the incoming messages,
depending on the view.
The User class has to be extended with PGP semantics, otherwise the
SecureMail class is not able to determine if the User supports the protocol,
and to get en- and decoding keys from the User for coding of the mailContents.
5.2.6 Static Meta Behaviour Extension: Warning2 Mail System
In the Warning2Mail class, we introduce nothing else but a counter object
that counts the incoming messages. When a message was sent before, a warning
is issued. Otherwise the message is counted, and execution continues normally.
The counting is done in a separate object MCount. Note that this object
does not know the structure of the Warning2Mail class, or even what methods
it should count. The object structure and the counting (and warning) behaviour
are neatly separated in the classes Warning2Mail and MCount. See
Figure 5.6 how the counting property is added to the appropriate methods.
The Warning2User class only implements a new test routine.
5.2.7 View Composition: Protected Mail System
For the protected mail system, we rst introduce the class SecureDocument.
This class de nes a securityLevel, and a view which checks whether the sending
user has security clearance. This means that the securityLevel of the sending
user has to match at least the securityLevel of the SecureDocument.

5.3. Layering 69
class Warning2Mail interface
internals
mail : SecureMail; == Inherit
messageCounter : MCount; == Counter
input lters
count : Meta = f [setMailContents,setMailOriginator,
setMailReceiver,send]
messageCounter.warning2Message g;
dis : Dispatch =f inner. , mail. g;
end
Figure 5.6: Coupling meta behaviour to an object
class ProtectedMail interface
internals
mail : Warning2Mail; == Inherit
secdoc : SecureDocument; == Inherit
input lters
err : Error = f securityClearance ->
fgetMailContents, setMailContentsg,
true ;fgetMailContents, setMailContentsg g;
dis : Dispatch =f inner. , mail. , secdoc. g;
end
Figure 5.7: Composing views is extremely simple using Composition Filters
For this example, we also need to de ne a SecureUser, which implements
the securityLevel attribute. This SecureUser also implements a new
test method.
The SecureMail class, which is the composition of Mail and Secure-
Document, is extremely simple. As we can see in Figure 5.7, we only declare
the inheritance of the proper classes, and de ne the necessary method-view
mappings for the securityClearance of the Get/Set contents methods.
5.3 Layering
In this section, we will give the Sina solution for the implementation of di erent
perceptions of layering, as discussed in Chapter 4.
Just as with the C ++ solution, the Sina implementation also is based on
the Simple Mail System, so we will start from there.

70 Chapter 5. Composition Filters Solutions for the Modelling Issues
5.3.1 Add Methods: Heading Mail System
In the User class, we constructed a header for textual representation of the
MailMessage by hand. In the HeadingMail, we provide a function that constructs
the header for us. MailMessages with more enhancements then can include
these enhancements in the header automatically.
We de ne the new functionality in the HeadingMail class by de ning
the getMailHeading method. We use this method in the getMailAsText method.
To use the new functionality, we de ne a HUser class, which uses this new
header. This class also de nes a new test function.
Note that all \self" references are denoted as server calls. This is because
Sina is a delegation-based language, where this refers to the implementor of the
current method, instead of the original receiver.
5.3.2 Rede ne Methods: Attachment Mail System
In the AttachmentMail, we will enable the user to attach a document tothe
MailMessage. For this, we de ne (like in the C ++ implementation) a separate
Attachment class, which we will use in the class AttachmentMail.
The AUser class only de nes a new test method.
When an attachment is added to the MailMessage, we want that the
mail header updates accordingly. For this, we only have to rede ne the getMail-
Heading method.
There is one signi cant di erence with the C ++ implementation. In C ++,
there was a conditional statement (if. . . then. . . else), to decide whether or
not the attachment information was to be added to the mail header. There are
three issues involved here:
1. The method;
2. The object state
3. How these are related to each other.
These issues correspond to the method getMailHeading, the condition
noAttachment and the skipMe lter of Figure 5.8. The lter section exactly
states that normally the inner methods are preferable (as in normal inheritance),
but that this must be skipped as long there is no Attachment present.
Note that these issues are the same as in Section 3.1.2. In that section is
explained why separation of these issues is so important.
5.3.3 Extend Methods: ReadNoti cation Mail System
The functionality that we will add in the ReadNotificationMail class is
orthogonal to the \normal" object behaviour, as we have already stated in
Section 4.2.3. Therefore, we de ne the semantics for the noti cation mechanism
in a separate class Notifier.
The new mail class ReadNotificationMail itself is very simple now.
Because we isolated the noti cation semantics, the new ReadNotification-
Mail class only has to attach these semantics to the Mail class, which is done

5.3. Layering 71
class AttachmentMail interface
internals
mail : HeadingMail;
conditions
noAttachment;
methods
:::;
getMailHeading;
input nters
skipMe : Dispatch =f
noAttachment)[getMailHeading]mail.getMailHeading; g
disp : Dispatch =f inner. , mail. g
end
Figure 5.8: Code example of conditional method skipping
class HistoryMail interface
internals
mail : ReadNoti cationMail;
history : HistoryReporter;
input lters
meta : Meta = f [ ]history.saveHistory g;
disp : Dispatch =f history.historyReport, mail. g;
end
Figure 5.9: Orthogonal behaviour is very simple to add to an existing class
in the meta lter. It focuses on when to alarm the noti er, with respect to the
Mail object itself. It is up to the Noti er to provide means for enabling and
disabling noti cation, and to prevent double noti cation sends.
5.3.4 Add Object-Orthogonal Behaviour: History Mail System
Like in the ReadNoti cation Mail System, the History Mail System de nes
a class which de nes behaviour orthogonal to that of the normal object. The
HistoryMail class records all incoming messages and provides a way to display
these recordings.
While the impact of the implementation of this semantics in C ++ was
very big (all existing methods had to be rede ned), the Sina implementation
is simple and straightforward. It resembles the ReadNotificationMail implementation,
because they both implement orthogonal behaviour. The class
interface is shown in Figure 5.9.

72 Chapter 5. Composition Filters Solutions for the Modelling Issues
incoming message
4
1
new meta...
new object...
2
dynamicLayer
basicObject
5
metaLayer
6
objectLayer
Figure 5.10: Structure of an object with dynamic layering property
5.3.5 Dynamic Layering: Dynamic Mail System
All functionalities have been implemented statically so far, which means that
their functionalities are always present, whether they are used or not. We have
seen that implementing dynamic layering in C ++ is rather di cult, introducing
more problems than bene ts. In this section we show how dynamic layering can
be implemented using the Composition Filters approach.
The idea is as follows: we start with a default object implementation, and adapt
it to enable dynamic layering on the object. This way, we will be able to get the
run-time situation of Figure 4.7. We do this by de ning the structure depicted
in Figure 5.10. In this gure, all incoming messages will be routed through all
present meta-level layers, and after that through all object-level layers. After
that, the message will be directed to the object itself as usual. New layers will be
tted in front of the appropriate layer-chain. This way, newly added layers can
use and/or override present functionality, like in normal inheritance situations.
The basics are de ned in class BasicDL, which implements the dynamic
layering principles for both the layered object as well as the layers. 3
In Figure 5.11, we can see that the HistoryProperty combines the
dynamic layering feature from BasicDL and the history recording from our
earlier de ned HistoryReporter just by declaring them as appropriate.
5.4 Conclusions
Apart from some minor problems, we can conclude that views as well as object
layers can very easily be expressed with Composition Filters. We have seen
that we did not have to make adaptions to the Mail class when we introduced
3. See Appendix D.5, where both HistoryProperty and DynamicMail \inherit" from
basicDL
3

5.4. Conclusions 73
class HistoryProperty interface
internals
basics : BasicDL;
oldReporter : HistoryReporter;
methods
process(aMessage : SinaMessage) returns nil;
input lters
disp : Dispatch =f
inner. ,
oldReporter.historyReport,
basics. g;
end
Figure 5.11: Composing functionalities goes rather well using Composition Filters
views. We only de ned the needed views, and coupled them to the appropriate
methods with lter expressions. Also the changes we made to the Mail classes
following the scenario tted directly into our model.
We are not the rst who address views in object oriented software models. Some
other people also have tried to make models that explicitly modelled the views.
Surrogates
Minsky and Pal (1995) address a technique called \surrogates" for implementing
di erent views over objects. For every view, a special surrogate object is created,
which enables or disables speci c features of the original object by the use of
so-called surrogate rules. With this mechanism it is possible to de ne simple
access control over classes or even individual objects, but our model goes much
further.
Surrogates cannot provide access dependent on the actual state of the object,
the message or its context. Therefore the classes GroupMail, SecureMail,
Warning2Mail and ProtectedMail cannot be realised
with surrogates.
It is not possible to de ne views that are composed from other views,
or provide access based on more views than just one. If we had sent a
MailMessage from some User to herself, this User would be the Mail-
Originator as well as the MailReceiver. This cannot be expressed neatly
with surrogates, because this person then has to have two references to
the same MailMessage.
Clients of surrogates are aware of the existence of the views, and must
reference them by name. As a result, the OriginatorReceiverView
example is possible, but it would have triggered a rewrite of the rest of
the code at all places to reference the correct Mail surrogate.

74 Chapter 5. Composition Filters Solutions for the Modelling Issues
Layers normally are referred to as layers from the OSI reference model (Black
1991), where one layer is implemented in terms of another layer.
We have shown layers in another perspective, and also have shown that
implementing these in a traditional language is not that simple. Implementing
layers in a language like Sina is straightforward however. Even dynamic layering
is possible, opening a new world of modelling possibilities for us.

Chapter 6
Composable Models Presented as Design Patterns
Chapter 5 presents adequate solutions for implementing Multiple Views on,
and Layering of objects. However, the solutions are not presented in a way
suitable for knowledge distribution. In this chapter, we will provide the models
for Multiple Views and Dynamic Layering in a more accessible format, using
Design Pattern presentation style.
In Section 2.2, we introduced Design Patterns as a knowledge presentation
and distribution medium. Section 6.1 will evaluate pattern denotations
in more detail, and presents an adapted denotation for Design Patterns, which
is capable of presenting composable models for design problems. Sections 6.2
and 6.3 then present the modelling issues as design patterns.
6.1 Enabling Design Patterns to Present Composable Models
The notations in which patterns appear nowadays are not adequate for the
problems we have solved. The reason for this is the rich semantics of Composition
Filters, which is not present in \standard" models, and thus is not covered
by the well-known pattern denotations.
The Composition Filters Object Model is capable of adapting message
passing semantics in a very exible way. It is possible to \inspect" several
attributes of a message at runtime because these attributes, like the sender of
the message, are made explicit in the model. It is also possible to change these
message attributes, or let the object react in a speci c way to the message by
choosing the appropriate lter type. It is even possible to reify the message as
a rst class object, and pass it to another object for further processing, in fact
enabling us to implement new lter types on the y.
When we want to express Composition Filters Object Model solutions in
a pattern format, we must be able to express all these semantics in a suitable
way. It is possible to give Sina code listings for solutions. This would not be
adequate however, because we then bind the solution to a speci c language. A
Design Pattern should present a solution that is more or less language independent.
75

76 Chapter 6. Composable Models Presented as Design Patterns
The patterns de ned by Gamma et al. (1995) are clearly focusing on
the traditional object model as discussed in 2.1.1. Instead, we want topresent
modelling problems using the Composition Filters Object Model. The graphical
models identi ed and used by Gamma et al. (1995) are not rich enough for this.
They use the following three graphical notations:
1. Class Diagrams. These are used to model class structures, which depict
static structural relations.
2. Object Diagrams. These are used to model object structures, which depict
dynamic structural relations.
3. Interaction Diagrams. These are used to model object interactions and
the order in which they occur.
We will now add a graphical notation to the vocabularies of a Design Pattern,
called a Message Diagram.
Message Diagrams
The model that we provide is focusing almost completely on the messages that
are sent between objects. It is however not important in what order messages
are sent, like in interaction diagrams. It is important what happens when a
message is sent to an object. The focus lies on one (or a group) of messages as
one entity, and not on the relation between these messages, like their execution
order.
We will introduce a model that we need for expressing our solutions.
The diagram we need is called a Message Diagram. Its elements match, not
surprisingly, the Composition Filters Object Model elements.
Initial graphical notation
In Figure 6.1, we see both a normal and a ltered message being sent from the
sending object to the receiving object. The normal message is supposed to look
familiar. With the ltered message, we see that the message's lifetime is divided
by (one or more) lter(s) into a pre- ltered, a being- ltered and a post- ltered
part. With an input lter, this lter is an integral part of the receiving object.
In this case, the nal target of the message is the part of the receiving object
that comes after the lter, and is called the server of the message in Sina.
Elements of a Filter Speci cation
We can identify three di erent elements of a lter speci cation: a condition,
a matching and a substitution part. The condition is optional, and defaults to
True. The substitution part is also optional, and defaults to the matching part,
which isnot optional.
A message is said to be accepted by a lter, if the condition evaluates to
True, and if the message selector equals the matching part of the lter speci -
cation. If a substitution part is speci ed, the message selector and/or it's target
are replaced with the speci ed values.

6.1. Enabling Design Patterns to Present Composable Models 77
anObject
aMessage
(a) Normal message
aTarget
filter
anObject
prefiltered postfiltered
aTarget
aMessage
(b) Filtered message
Figure 6.1: Graphical message notations from the message's viewpoint. A message
is either not ltered at all, or passes one or more lters which inspect
and/or manipulate its runtime behaviour.
We can express this by labelling the pre- ltered message with the matching
part (which can be a wildcard), and the post- ltered message with the
condition and, if present, the substitution part.
If the message is not accepted by the lter, it is said to be rejected. It
depends on the lter type what will happen in that case. It depends on the
situation whether it is illustrative to explicitly denote this case or not.
Semantics of a Filter
So far, the lter only accepts or rejects messages. The lter type dictates what
happens when a message is accepted or rejected by this lter. Until now, six
lter types have been de ned:
1. Error lter. An error is raised when no matching succeeds.
2. Wait lter. Execution will be deferred until the message falls through the
lter.
3. Meta lter. Execution will proceed at a meta-level after the message has
been rei ed into a rst-class object. There the message can be inspected
and even manipulated. After meta-processing, the message will continue
executing back at the object-level.
4. Dispatch lter. Execution is either dispatched to the implementation
which is present in the inner object, or to the rst lter of the object to
which the message is delegated.
5. Send lter. Execution is transferred to the object to which the message
is sent (to its set of input lters).
6. Realtime lter. Execution is assigned realtime constraints such as maximum
execution time.

78 Chapter 6. Composable Models Presented as Design Patterns
Wait Error Meta Dispatch Send RealTime
Figure 6.2: Filter Types
We visualise these types by using speci c drawings for the di erent lter
types, as depicted in Figure 6.2. Note that both the Dispatch and the Send lter
are very simple. They are the placeholders for the dispatch and send mechanisms
of the traditional object model (with the additional features of the Composition
Filters Object Model of course). Often it is not necessary to depict these lters
explicitly, sowe omit them in our Message Diagrams to keep them as simple as
possible.
Message States
When a message is sent from aClient to aServer, it passes several stages. We
already mentioned that a lter in most cases is some kind of wrapper around the
original (core) object. The message then can be between two di erent objects,
or between the core object and the lters (i.e. it has passed the lters). To
make this di erence visible, we denote the message with a normal line when
it resides between the objects, and with a thicker line when it is between the
lters and the receiving object. When the diagram depicts an output lter, the
line between the sending object and the lter will be the thicker line, because in
such a diagram, the sending object is the core object the diagram is all about.
Normal, unimportant and Core Objects
Objects or classes of objects can play di erent roles in a message diagram. To
make this clear, we use di erent displaycharacteristics for di erent object roles.
We identify three kinds of object roles:
Unimportant object An object is called unimportant, if it is present in the
object interaction, but is irrelevant to the communication characteristics.
It is used mostly to identify the context of a communication channel. We
will display an unimportant object grayed. Gamma et al. (1995) uses the
same denotation.
Normal object A normal object is an environmental object which plays a key
role in the communication characteristics. We display normal objects in
black.
Core object The core object is the target of the message. It is displayed in
thick black.
Filter interdependencies
Usually, an object has more than one lter element de ned, in one or more
lters. When the evaluation order of lter elements is important, we must show

6.1. Enabling Design Patterns to Present Composable Models 79
this in our message diagrams. When more than one communication line comes
out of a lter, they must be read top-down. The implementation of the dynamic
mail system from Chapter 4 gives a nice example of this situation. Figure 6.10
on page 87 shows (a part of) the message diagram.

80 Chapter 6. Composable Models Presented as Design Patterns
aMailHandler
getContents getMailReceiver
aUser
getContents
sendMail
getMailReceiver
aMail
Figure 6.3: An example mail system
6.2 Design Pattern: Composable Multiple Object Views
Intent
The pattern makes it possible to explicitly model dynamic interface and behaviour
change, dependent onthe runtime message context, like the sender of
a message.
Also Known As
Multiple Interfaces
When we want to model di erent behaviour or interfaces dependent on the state
of the object itself instead of the sender of a message.
State
The State pattern provides an alternative solution for more or less the same
problem. Further discussion in the Related Patterns section.
Motivation
Consider a mailing system. This system has the participants Mail, User and
MailHandler (see Figure 6.3). When we look at the interface of Mail, we
see two parts there. These are
User part This part provides the interface to the User objects. Typical examples
are getContents and sendMail.
System part This part provides the interface to the MailHandler.Atypical
example is getMailReceiver.
These two parts provide di erent functionalities of the Mail object, which are
more or less independent of each other.
In the implementation of this system, we want to prevent that the Mail objects
receive inappropriate messages from other objects. We want to prevent for
example that Mail receives the getContents method from the MailHandler,
because it violates the rules of the system as a whole. This is seen in Figure 6.3,

6.2. Design Pattern: Composable Multiple Object Views 81
aClient
*
anotherMessage
aView -> aMessage
aServer
Figure 6.4: The structure of the Multiple Views pattern
where the message getContents is blocked when it is sent by the MailHandler,
while it is passed through when it is sent byaUser.
Further, we want to explicitly divide the interface in multiple sections,
more or less explaining the di erent roles Mail can play in di erent activities.
This way the implementation of Mail will be better understood.
In intuitive implementations of the above requirements, the accessibility code
will be mixed with the application code. For example, in the implementation of
getContents, we will check whether the sender of the message is a User object.
The disadvantage is twofold:
1. Adapting access restrictions in subclasses will result in rewriting all restricting
application methods.
2. Adapting application semantics will force you to rewrite all access restriction
code.
The above problem arises from the fact that access control and application
semantics are orthogonal properties, which are combined as application
semantics in the implementation. Our solution will prevent this undesired situation.
Applicability
Apply Composable Multiple Object Views when:
The interface of a class is complex and consists of several `sub-interfaces',
each for a di erent system functionality.
Object misuse must be prevented, and several parts of the interface
should be protected from some clients (message callers).
Application semantics or object access control must be adapted through
subclassing.
Implementation of methods must be adapted dynamically (depending on
message sender or internal object state).
Structure
The structure of the pattern is as depicted in Figure 6.4. Here we showaClient
object, which sends aMessage to the Server, which is accepted under condition
aView. This picture also shows the message anotherMessage, which is blocked
by the server.

82 Chapter 6. Composable Models Presented as Design Patterns
Participants
Server
The Server is responsible for implementing aView, aMessage and the dependency
between these two.
Collaborations
The Server receives aMessage, inspects whether aView is active, and
then processes or rejects the message.
Consequences
Using this pattern has the following bene ts:
Separation of concerns The model consists of two di erent elements (application
and view). We separate these concerns explicitly.
Polymorphic The solution is polymorphic; i.e. it is possible to implement only
di erent application or view semantics in subclasses.
Using this pattern has the following drawback:
Encapsulation The Composition Filters Object Model de nes lters always
at the interface level. In this example this is all-right, because we want to
inform the user (client) about the views and their restrictions. When we
want to adapt behaviour under certain circumstances (see the Gamma
State pattern), we do not want to show this at the interface of the
object. This is not possible with the Composition Filters Object Model.
Implementation
The Server class has three concepts: the method, the view and the connection
between these two elements. This results in the solution template in Figure 6.5
for the Composable Multiple Object Views pattern.
This template shows a view aView. This aView restricts access to aMessage,
while access to method yetAnotherMessage is not restricted. Here can also
be seen that addition of more views is possible, by de ning an additional view
in a subclass, and connecting it to methods using an additional lter expression.
Sample Code
The solution we propose uses the concepts that are built-in in the Composition
Filters Object Model. The view userView is represented by a condition. The
connection between the view and the application semantics is represented by a
message lter. This results in the class de nition shown in Figure 6.6. An extract
from the implementation, in order to show how the userView is implemented
using Composition Filters Object Model primitives, is shown in Figure 6.7.
Known Uses
None.

6.2. Design Pattern: Composable Multiple Object Views 83
class Server interface
conditions
aView;
methods
aMessage;
yetAnotherMessage;
inputFilters
mv: Error = faView ) aMessage, true ; aMessageg;
dis: Dispatch =finner. g;
end
Figure 6.5: Code template for the Multiple Views Pattern
class Mail interface
comment
This class implements the Multiple Views design pattern
internals
contents: Text; == Contains the mail message
conditions
userView; == Implements the view
methods
== Implements the application functionality
getContents returns Text;
inputFilters
== Connect the view with the application semantics
mv: Error = fuserView ) getContents, true ; getContentsg;
dis: Dispatch =finner. g;
end
Figure 6.6: Interface de nition of the Mail class

84 Chapter 6. Composable Models Presented as Design Patterns
class Mail implementation
:::
conditions
userView
begin
return sender.isKindOf(User)
end
:::
end
Related Patterns
Figure 6.7: Implementation extract of the Mail class
State Partitioning This problem is also known as the View Partitioning
Problem. It's basis lies in the fact that it is normally not possible to
divide a view in two distinct subviews, without breaking the inheritance
principle and rewriting parts of the class speci cation.
State The Gamma catalogue provides the State pattern for implementing dynamically
changeable behaviour. This pattern has a big disadvantage:
the pattern is not extensible, and thus implementations of the pattern
are not reusable.
This statement is based on the fact that the State hierarchy and the
Context are not orthogonal (same problem as stated before). This
means that extending the Context is not possible without rewriting at
least a part of the State hierarchy. Furthermore, when a subset of the
Context implementation is valid for more that one particular State,
this results in replication of implementation code. This, of course, is undesirable,
and undoes a part of the positive e ects of using the State
pattern.

6.3. Design Pattern: Composable Object Layering 85
getContents
aMailHandler
getMailReceiver
aUser
getContents
sendMail
aHistory-
Recorder
recordHistory
aMail
Figure 6.8: An example mail system with history recording
6.3 Design Pattern: Composable Object Layering
Intent
Attach additional behaviour to an object dynamically. Composable Dynamic
Object Layers pattern is used to compose an object's behaviour with highly
reusable components, without losing the features of object oriented modelling.
Also Known As
None.
Motivation
In sophisticated software frameworks, some important objects incorporate many
di erent features. These features however are almost never used together. Normally,
only some of these features are used in speci c situations. The di erent
features then can be turned on or o using some calls (like enableFeatureThisOrThat).
The implementation of these objects often becomes heavy loaded with
administrative code for enabling and disabling of features, and checking if features
are enabled. Also, the di erent code sections of di erent features are often
mixed together. This leads to complex, badly readable and non reusable code.
It is also not possible to tailor the di erent features without rewriting other
code parts.
Consider a Mail System, like in Figure 6.8. It resembles the mail system of
Figure 6.3, with the di erence that all incoming messages are recorded in a
HistoryRecorder. Often this functionality is not required, so it should be possible
to enable and disable the history recording service. The disadvantage of this
static structure is twofold:
1. All Mail objects not requiring the history recording service are loaded
with its (disabled) code, which results in unnecessary resource occupation.
2. It is not possible to tailor the history recorder, because it is encapsulated
in the Mail class.

86 Chapter 6. Composable Models Presented as Design Patterns
getContents
aMailHandler
getMailReceiver
aUser
getContents
sendMail
process
aMessage-
Decoder
aHistory-
Recorder
aMail
process
Figure 6.9: Mail system with a history recorder and a message decoder
3. When other services are designed, the Mail class has to be extended
to use this service. When lots of these services are involved, this implies
heavy impact on the implementation of the Mail class, while the intrinsic
implementation of the class does not change at all.
Using the Composable Dynamic Object Layers pattern, we get a more
exible implementation. See for example Figure 6.9, where besides the HistoryRecorder
also a MessageDecoder is active. Both services are activated transparently,
when a message is sent totheMail object.
Applicability
Apply the Composable Dynamic Object Layers when:
Class de nitions consist of many di erent services, which almost never
are used all at the same time.
It must be possible to dynamically add services to an object.
It can not be foreseen which services are necessary in an object. This is
only the case with so-called orthogonal services (like the HistoryReporter
mentioned before).
Many of the de ned services can be combined. When inheritance is used
in this situation, many class de nitions are the result, because all di erent
combinations must be de ned explicitly.
Structure
We divide the structure of the Composable Dynamic Object Layers pattern
in two parts. The rst part is the Basic Dynamic Layer, which is depicted in
Figure 6.10. The second part is the usage of this Basic Dynamic layer in an
object that needs dynamic layering. It is shown in Figure 6.11
Participants
BasicDL The Basic Dynamic Layer implements the protocols for the layered
object and both the object-level and the meta-level layers.

6.3. Design Pattern: Composable Object Layering 87
×
addOL
aClient aBasicDL
addML
(cascaded)
(meta)
process
object_layer
meta_layer
Figure 6.10: Message Diagram of the Basic Dynamic Layer
anObject
*
process
*
*
aBasicDL
aDLObject
Figure 6.11: Message Diagram of the Composable Object Layer Pattern

88 Chapter 6. Composable Models Presented as Design Patterns
ObjectLayer De nes the BasicDL protocol by inheriting from it, and additional
functionality that must be added to the DLObject object at the
object level.
MetaLayer De nes the BasicDL protocol by inheriting from it, and additional
functionality that must be added to the DLObject object at the
meta level.
DLObject De nes the BasicDL protocol by inheriting from it, and the normal
functionality that the object must provide.
Collaborations
The BasicDL de nes a protocol for adding new layers to the DLObject
to which it is attached. The newly added layers are chained in such a
way, that newly added layers are processed rst. In this way, newly added
layers can use functionality present in an earlier added layer.
The BasicDL object also delegates all unknown methods to its internal
object-level and meta-level layer chains.
The ObjectLevel processes requests which it implements, and delegates
all other requests to its BasicDL ancestor.
The MetaLevel implements the process method, and forwards the call
to its BasicDL ancestor afterwards. It can also implement object-level
functionality in appropriate methods. All unknown messages should be
delegated to its BasicDL ancestor.
The DLObject object sends all incoming messages to the meta-level process
method. After that, appropriate messages should be delegated to the
BasicDL ancestor. Finally, messages should be dispatched to the inner
object.
Consequences
The Composable Dynamic Object Layers pattern has several bene ts:
Flexible property composition All possible combinations of properties can
be constructed at run-time. This avoids class trees which de ne a class for
each possible combination of features. Note that when class de nitions
are used, it is not possible to add features to an object during its lifetime
without losing its object identity.
Avoids feature-loaded classes high up in the hierarchy Because the layers
are attached at run-time, the classes do not have to de ne all features
in advance, resulting in large objects from which only parts will be used.
Layers can be reused It is very simple to reuse layer speci cations in other
classes (especially when they are de ned at the meta-level. The HistoryRecorder
we mentioned before can be plugged into any DLObject
class without modi cations. This way, it is also possible to design a hierarchy
oflayers, separate from the layered objects which will use them.
It will make a design very exible and extendible.

6.3. Design Pattern: Composable Object Layering 89
Implementation
The implementation of the Composable Dynamic Object Layers pattern involves
several issues. These include:
The pattern can only be implemented using a language that implements
the Composition Filters Object Model. We have tried to implement it
in a traditional language (C ++, see Appendix C.5), which turned out to
produce more problems than solve them.
The pattern introduces overhead by introducing the BasicDL class.
Don't overuse this pattern, because the implementation overhead we try
to solve with this pattern can be less than the overhead the pattern
introduces.
When de ning dynamic layered objects, consider building them on top
of \normal" objects (like the DynamicMail in Appendix D.5). Consider
this also for orthogonal layers (like the HistoryReporter in Appendix
D.5). This way, it is always possible to use the non-dynamic
version when appropriate.
Sample Code
We show the implementation of a dynamic mail object, using a dynamic layer
for history reporting. We assume there is a class Mail which implements normal
mail functionality. Further, there is the BasicDL class which implements
the default dynamic layering protocol. Finally, we assume there is a history
reporting class called HistoryReporter.
First, we show how the HistoryReporter class is made dynamic. The dynamic
version is called HistoryProperty. The code is in Figure 6.12. The
HistoryProperty forwards the process method to the appropriate method in
the HistoryReporter.
The code in Figure 6.13 shows how to make the normal class Mail
dynamic by \inheriting" from BasicDL. Note the di erence with Figure 6.12;
the order of the lter elements is di erent. The incoming message is diverted to
the process method rst, for meta-level layering. Then the message is delegated
to the object-level layers, if appropriate. Otherwise, the message is dispatched
to the inner object as usual.
Figure 6.14 shows how to use a dynamic layered object.
Known Uses
None.
Related Patterns
Decorator
The Decorator pattern is the Conventional Object Model counterpart of Composable
Dynamic Object Layers. It is a di erent pattern, because the structure

90 Chapter 6. Composable Models Presented as Design Patterns
class HistoryProperty interface
internals
basics : BasicDL;
oldReporter : HistoryReporter;
methods
process(aMessage : SinaMessage) returns nil;
input lters
disp : Dispatch =f inner. ,
oldReporter.historyReport,
basics. g;
end;
class HistoryProperty implementation
instvars
methods
process(aMessage : SinaMessage)
begin
oldReporter.saveHistory(aMessage);
basics.process(aMessage);
end;
end;
Figure 6.12: How tomake a generic property a dynamic layer
class DynamicMail interface
internals
layers : BasicDL;
mail : Mail;
input lters
meta : Meta = f [ ]layers.process g;
dis : Dispatch =f layers. , mail. g;
end;
class DynamicMail implementation
end;
Figure 6.13: How tomake a normal class a dynamic layered class

6.3. Design Pattern: Composable Object Layering 91
main
temps
aMailMessage : DynamicMail;
aHistory : HistoryProperty;
begin
aMailMessage.addML(aHistory);
aMailMessage.setMailOriginator(server);
aMailMessage.setMailReceiver(aUser);
aMailMessage.setMailContents(
'Contents of a Dynamic Mail Message');
aMailMessage.send;
aMailMessage.historyReport;
end
Figure 6.14: How to use a dynamic layered object
is very di erent. The goals are the same however. In our solution, we have addressed
some problems that the Decorator pattern introduced. Amongst them
is the problem of losing object identity when a decorator is added to an object.
Dynamic Slots
Schmidt (n.d.) describes an implementation of dynamic slots in the BETA system.
1 Dynamic slots are de ned as dynamically insertable attributes of arbitrary
objects. The di erence between dynamic slots and dynamic layering is:
Dynamic slots can only be used to insert attributes, while with dynamic
layers, one can insert arbitrary behaviour into any object.
The reference to dynamic slots is not transparant to the user or caller of
the object. One must access these slots in a special way, while dynamic
layers transparantly de ne interface extensions to the object, which can
be accessed as all normal interface elements.
In BETA, dynamic slots are enabled in the root object class, which means
that all objects in the system are dynamic-slot-ready. With dynamic
layering, all objects must explicitly enable this feature before it can be
used. This is the result of enabling the insertion of meta-level layers, and
the de nition of additional object behaviour on top of already existing
behaviour. If only simple attributes were to be added, 2 one could de ne
one simple superclass which enabled dynamic layering, just as in the
dynamic slot implementation.
1. BETA isawell-known Object-Oriented programming environment.
2. Which is not possible in Sina, but we can de ne simple get and put operations which
manipulate some attribute.

92 Chapter 6. Composable Models Presented as Design Patterns
6.4 Conclusions
In this chapter we have transformed our design issues from Chapters 3 and 4
into Design patterns. We conformed to the format of the GoF book (Gamma
et al. 1995), but we had to make some extension to visualize the semantics of
lters. It is made clear that the GoF format is also suitable for our category of
problem solutions, although we used another object model.
The Message Diagrams we introduced in this chapter are capable of
showing the intensions of some lter set in an intuitive way. In Figure 6.9 for
example, it is immediately clear that users can invoke all Mail methods, that
mail handlers are not supposed to read the mail contents, and that all incoming
method calls are processed through a message decoder and a history recorder
at a meta level. This overview picture is much harder to understand when read
directly from the lter speci cations.

Chapter 7
Conclusions and Future Work
We nalise this thesis by summarising the conclusions. We also give some directions
for further research.
7.1 Comparison of the C++ and the Sina implementations
In this thesis we have shown the implementations of two models in two di erent
languages. In this section, we will discuss the results.
7.1.1 Multiple Views
In Table 7.1, we can see the amount ofwork that is necessary to implement the
actions that we have identi ed in the Multiple Views Model (See Section 3.1.3).
It is obvious that the initial number of methods is the same, because both
implementations must provide the same Mail semantics.
When wewant to add views however, it is clear that an enormous amount
of work has to be done in the C ++ implementation. There are two methods that
implement the views (the same two methods that are necessary for the Sina
implementaton) and two times all original interface functions (one time for the
Actions C++ Sina
Initial 14 ? 14 ?
Add Views 30 ? 2
View Partitioning 8 ? 2
View Extension 1 1
Dynamic Behaviour Extension 5 ? 1
Static Meta Behaviour Extension 5 ? 0
View Composition 2 ? 0
Table 7.1: Methods added or changed in . . . Mail class to change View aspects.
Numbers marked with ? are dependent on the number of a ected methods,
which means that increasing the number of a ected methods will increase the
number in the table.
93

94 Chapter 7. Conclusions and Future Work
Actions C++ Sina
Add Methods 2 ? 2 ?
Rede ne Methods 3 ? 4 ?
Extend Methods 5 ? 1
Add Object Orthogonal Behaviour 15 ? 0
Dynamic Layering 63 ? 0
Table 7.2: Methods added or changed in . . . Mail class to change Layer aspects
coupling between the view and the method, and one time for passing the method
to the internal Mail implementation). In Sina, we only provide a simple lter
speci cation.
In all other situations (with View Extension as an exception), we have
to do more work in the C ++ implementation than in the Sina implementation.
This is because all a ected methods have to be rewritten in C ++, while in Sina
only lter speci cations have to be adjusted.
7.1.2 Layering
In Table 7.2, the C ++ implementation is not so bad in the beginning (see Section
4.1.3 for the Layers scenario). When we rede ne methods, the Sina implementation
even has one method more de ned than the C ++ implementation.
This is however because the presence of an attachment is made explicit as a
view in Sina, while in C ++ this is implicitly coded as a NULL check.
When methods are extended, we must de ne ve functions in C ++. These
functions are for the noti cation interface and the rede nition of the a ected
Mail functions and method-view mappings. In Sina, only the view speci cation
has to be written, accompanied by its method-view mappings.
The addition of meta-functionality is clearly a lot of work in C ++. Adding
othogonal behaviour requires us to rewrite all interface methods, while in Sina
zero functions have to be written. When we de ne dynamically extensible models,
the C ++ implementation follows the Decorator patterns of the Gof book
(Gamma et al. 1995), and requires us to write each interface function four(!!)
times: one interface replication for the Mail Component (the Component of the
pattern); one for the DynamicMail interface (the ConcreteComponent of the
pattern); one for the MailDecorator (the Decorator of the pattern); one replication
for the MailHistory (which is a ConcreteDecorator) and nally a couple
of methods for the MailReadNoti er (which is also a ConcreteDecorator). As
can be seen, the interface conformance problem that occurs with this pattern
is a serious problem. In the Sina implementation this is not a problem at all:
the code of the DynamicMail class contain no methods at all!

7.2. Conclusions 95
7.2 Conclusions
In this thesis we have explicitly focused on the two modelling issues Multiple
Object Views and Object Layering. Software models often do not explicitly
express views and layers, therefore these issues are often bypassed during the
object design.
This leads to software which is hard to reuse and maintain, while this
was the reason for using object-oriented modelling techniques in the rst place!
It turns out to be impossible to implement new features without touching or
recoding existing code.
The traditional object-oriented language model lacks some properties,
which are invaluable for expressing modelling issues like those discussed in this
thesis. Amongst them are:
Open message passing semantics.
Meta models for messages.
A delegation mechanism.
We have shown this by implementing a case scenario in C ++, where we
have tried to vary in di erent aspects of the modelling issues.
These properties themselves are not su cient however: Delegation alone
does not solve our problems, because we need to be able to de ne conditions on
the delegation (for Multiple Views for example). We have tried to implement
our Multiple Views model in Smalltalk, which is a delegation-based language.
In this implementation we have seen a lot of problems similar to those in C ++
(see Section 3.3 for a more detailed discussion).
It is possible to implement some issue characteristics by replicating interface
speci cations, and write \call-through" methods (we have seen that in our C ++
implementations), but this has some drawbacks in general:
Interface conformance. Interfaces needed deeply in a hierarchy must be
declared in upper levels, resulting in a lot of code overhead and loss of
overview. See for example our Dynamic Layering pattern compared to
the Decorater pattern of Gamma et al. (1995).
Call-throughs are not optimizable. With Composition Filter speci cations,
we write interface declarations. These declarations eventually can
be optimized into executable code by the compilers. When we write callthroughs,
we write interface implementations, which will be executed in
the way we have de ned them, and thus they are not optimized. This
will lead to slower execution.
We also have shown that the Composition Filters Object Model is capable of
expressing the modelling issues in a natural way, while the normal properties of
object-oriented models are preserved. New issues or features are gracefully integrated
in existing software models, making it easy to compose software models

96 Chapter 7. Conclusions and Future Work
instead of programming them. Take for example Figure 5.9, where history logging
features were added to an existing class in two lter expressions, without
looking at the original class or the history logging class.
Finally, wehave designed a graphical notation, in whichwe can express message
passing semantics in an intuitive way. This notation, called message diagrams,
is added to the pattern notations de ned by Gamma et al. (1995), so we have
away toshow our modelling issues to the world.
7.3 Future Work
During the writing of this thesis, many thoughts have crossed the mind. It is
impossible to work them all out in one thesis. We would like tomention them
here, so others can elaborate on them.
Pattern Implementation
When implementing (applying) Software Design Patterns, we discover the following
problems (Bosch 1995).
Tracability The implementation does not show us explicitly that a pattern has
been applied. We can see this in Appendix A.1, where we implemented
the MailHandler class as a Singleton pattern. In this implementation
there is no trace of this pattern at all; only the documentation refers to
it. The problem gets worse when objects participate in several patterns.
The object implementation gets loaded with di erent sections belonging
to di erent patterns.
Implementation overhead In this same implementation we see a lot of code
for just one pattern. The MailHandler class implements several methods
and de nes a class variable for the pattern. This means that every
time the Singleton pattern is used, these or very similar methods will
have to be written over and over.
The Composition Filters Object Model can probably solve at least a part of
this problem, by de ning patters and pattern roles as stand-alone software
components, which can be attached to objects when appropriate. This might
even be done dynamically using the Dynamic Layering Design Pattern from
Section 6.3.
Another way of pattern implementation has been de ned by Florijn,
Meijers and van Winsen (1997). They de ne a tool which solves (a part of) the
implementation overehead.
Integration of Composition Filters in Java
Java is becoming a very popular programming language. Unfortunately, it is
based on the traditional object model, and thus has (from our point of view)
the same problems as C ++.

7.3. Future Work 97
It would be interesting when the Java language was extended with Composition
Filters. The biggest problem for this is that Java is de ned as a very
type-safe language. The use of Composition Filters introduces delegation, which
intrinsically is not type-safe. It should be investigated how Composition Filters
can be integrated into the Java language without losing (too much) of its typesafety.
An entry point for this can be the use of Java's interface speci cations,
which in fact is an implementation of Contracts (as de ned by Helm, Holland
and Gangopadhyay (1990)).
Design \Improved" Versions of Existing Patterns
Some of the design patterns presented by Gamma et al. (1995) can be improved
by using Composition Filters. We have shown an example in this thesis
already. Itwould bene t our knowledge and insights in object-oriented software
modelling when other design patterns are also discussed in a similar way.
Deployment of Composable Patterns
A pattern is no pattern, unless it has proven itself (Gamma et al. 1995). So
the patterns we have supplied in this thesis are in fact no patterns at all. They
must be deployed rst. When Composition Filters are integrated in a popular
development language, this will eventually happen.

98 Chapter 7. Conclusions and Future Work

Appendix A
C ++ Implementation of Multiple Views
A.1 Simple Mail System
De nitions
#ifndef MAIL H
#define MAIL H
class MailHandler;
class User;
class Mail;
class MailHandler
f
public:
static MailHandler Instance(void);
virtual int send(Mail );
virtual char getName(void) f return name; g
virtual void setName(char s) f name s; g
protected:
MailHandler() fg
virtual MailHandler() fg
char name;
static MailHandler instance;
g;
MailHandler MailHandler:: instance (MailHandler )0;
class User
f
public:
virtual void setName(char s) f name s; g
virtual char getName(void) f return name; g
virtual void receive(Mail );
(mail.hpp)
99

100 Appendix A. C ++ Implementation of Multiple Views
virtual void sendSimpleMailTo(User );
private:
char name;
g;
class Mail
f
public:
Mail();
virtual void setMailOriginator(User );
virtual User getMailOriginator(void);
virtual void setMailReceiver(User );
virtual User getMailReceiver(void);
virtual void setMailContents(char );
virtual char getMailContents(void);
virtual void send(void);
virtual void reply(void);
virtual void approve(void);
virtual int isApproved(void);
virtual void setDelivered(void);
virtual int isDelivered(void);
virtual void setRoute(MailHandler );
virtual MailHandler getRoute(void);
private:
User mailOriginator;
User mailReceiver;
char mailContents;
int approved;
int delivered;
MailHandler route;
g;
#endif
Implementation
#ifndef MAIN DEFINED
#define MAIN DEFINED
int main(void)
f
CALL TEST FUNCTION
g
#endif
(main.inc)

A.1. Simple Mail System 101
#undef CALL TEST FUNCTION
#include
#include "mail.hpp"
MailHandler
MailHandler::Instance(void)
f
if ( instance (MailHandler )0) f
instance new MailHandler();
instance!setName("The Only MailHandler");
g
return instance;
g
int
MailHandler::send(Mail m)
f
if (m!getMailReceiver() 6= (User )0) f
m!approve();
g
cout "=======>>>>>MailHandler is peeking "
"into the MailMessagenn"
"=======>>>>>" m!getMailContents()
"nn";
if (m!isApproved()) f
m!setRoute(this);
m!setDelivered();
m!getMailReceiver()!receive(m);
return 0;
g else f
return -1;
g
g
void
User::receive(Mail m)
f
cout "User " this!getName()
" received mail from "
m!getMailOriginator()!getName()
"nnRoute:ntnt" m!getRoute()!getName()
"nnApproved:nt" (m!isApproved()?"Yes":"No")
(mail.cc)

102 Appendix A. C ++ Implementation of Multiple Views
g
"nnDelivered:nt" (m!isDelivered()?"Yes":"No")
"nnContents:nn----------nn"
m!getMailContents()
"nn----------nn";
void
User::sendSimpleMailTo(User u)
f
Mail mailMessage new Mail();
mailMessage!setMailOriginator(this);
mailMessage!setMailReceiver(u);
mailMessage!setMailContents(
"Contents of a simple mail message");
mailMessage!send();
g
Mail::Mail()
f
mailOriginator (User )0;
mailReceiver (User )0;
mailContents (char )0;
approved 0;
delivered 0;
route (MailHandler )0;
g
void
Mail::setMailOriginator(User u)
f
mailOriginator u;
g
User
Mail::getMailOriginator(void)
f
return mailOriginator;
g
void
Mail::setMailReceiver(User u)
f
mailReceiver u;
g

A.1. Simple Mail System 103
User
Mail::getMailReceiver(void)
f
return mailReceiver;
g
void
Mail::setMailContents(char s)
f
mailContents s;
g
char
Mail::getMailContents(void)
f
return mailContents;
g
void
Mail::send(void)
f
MailHandler::Instance()!send(this);
g
void
Mail::reply(void)
f
g
void
Mail::approve(void)
f
approved 1;
g
int
Mail::isApproved(void)
f
return approved;
g
void
Mail::setDelivered(void)

104 Appendix A. C ++ Implementation of Multiple Views
f
g
delivered 1;
int
Mail::isDelivered(void)
f
return delivered;
g
void
Mail::setRoute(MailHandler mh)
f
route mh;
g
MailHandler
Mail::getRoute(void)
f
return route;
g
#define CALL TEST FUNCTION test simple mail();
void test simple mail(void)
f
cout "SimpleMail testnn";
User u1 new User();
u1!setName("MailOriginator");
User u2 new User();
u2!setName("MailReceiver");
u1!sendSimpleMailTo(u2);
g
#include "main.inc"
A.2 UserSystemView Mail System
De nitions
#ifndef USVMAIL H
#define USVMAIL H
#include "mail.hpp"
(usvmail.hpp)

A.2. UserSystemView Mail System 105
class MVUser;
class MVMailHandler;
class UserSystemViewMail;
#define CFilter(A,B) if (A)fB;gelsefcout "Filter error";g
typedef enum f
ObjectClass,
MVMailHandlerClass,
MVUserClass,
GroupUserClass,
PGPUserClass,
ProtectedUserClass,
UserSystemViewMailClass,
OriginatorReceiverViewMailClass,
GroupMailClass,
SecureMailClass,
Warning2MailClass,
ProtectedMailClass,
lastClass
g classTypes;
class Object
f
public:
virtual classTypes myClass(void) f return ObjectClass; g
virtual int isKindOf(classTypes ct) f return this!myClass() ct; g
virtual char asString(void) f return this!className(); g
virtual char className(void) f return "Object"; g
g;
class MVMailHandler : public MailHandler, public Object
f
public:
virtual classTypes myClass(void) f return MVMailHandlerClass; g
virtual int send(UserSystemViewMail );
static MVMailHandler Instance(void);
virtual char className(void) f return "MVMailHandler"; g
protected:
MVMailHandler() fg
virtual MVMailHandler() fg
static MVMailHandler instance;
g;

106 Appendix A. C ++ Implementation of Multiple Views
MVMailHandler MVMailHandler:: instance (MVMailHandler )0;
class MVUser : public User, public Object
f
public:
virtual classTypes myClass(void) f return MVUserClass; g
virtual void receive(UserSystemViewMail );
virtual void sendUserSystemViewMailTo(MVUser u);
virtual char className(void) f return "MVUser"; g
g;
class UserSystemViewMail : public Object f
public:
UserSystemViewMail();
virtual UserSystemViewMail();
virtual classTypes myClass(void) f return UserSystemViewMailClass;
g
virtual void setMailOriginator(Object ,MVUser );
virtual MVUser getMailOriginator(Object );
virtual void setMailReceiver(Object ,MVUser );
virtual MVUser getMailReceiver(Object );
virtual void setMailContents(Object ,char );
virtual char getMailContents(Object );
virtual void send(Object );
virtual void reply(Object );
virtual void approve(Object );
virtual int isApproved(Object );
virtual void setDelivered(Object );
virtual int isDelivered(Object );
virtual void setRoute(Object ,MVMailHandler );
virtual MVMailHandler getRoute(Object );
virtual char className(void) f return "UserSystemViewMail"; g
protected:
virtual int isUserView(Object );
virtual int isSystemView(Object );
private:
Mail mail;
virtual void pureSetMailOriginator(MVUser );
virtual MVUser pureGetMailOriginator(void);
virtual void pureSetMailReceiver(MVUser );
virtual MVUser pureGetMailReceiver(void);
virtual void pureSetMailContents(char );
virtual char pureGetMailContents(void);
virtual void pureSend(void);

A.2. UserSystemView Mail System 107
g;
#endif
virtual void pureReply(void);
virtual void pureApprove(void);
virtual int pureIsApproved(void);
virtual void pureSetDelivered(void);
virtual int pureIsDelivered(void);
virtual void pureSetRoute(MVMailHandler );
virtual MVMailHandler pureGetRoute(void);
Implementation
#include
#include
#include "usvmail.hpp"
MVMailHandler
MVMailHandler::Instance(void)
f
if ( instance (MVMailHandler )0) f
instance new MVMailHandler();
instance!setName("The Only MVMailHandler");
g
return (MVMailHandler ) instance;
g
int
MVMailHandler::send(UserSystemViewMail m)
f
if (m!getMailReceiver(this) 6= (MVUser )0) f
m!approve(this);
g
cout "=======>>>>>MVMailHandler is peeking "
"into the MailMessagenn"
"=======>>>>>" m!getMailContents(this)
"nn";
if (m!isApproved(this)) f
m!setRoute(this,this);
m!setDelivered(this);
m!getMailReceiver(this)!receive(m);
return 0;
g else f
(usvmail.cc)

108 Appendix A. C ++ Implementation of Multiple Views
g
g
return -1;
void
MVUser::receive(UserSystemViewMail m)
f
cout "User " this!getName()
" received mail from "
m!getMailOriginator(this)!getName()
"nnRoute:ntnt" m!getRoute(this)!getName()
"nnApproved:nt" (m!isApproved(this)?"Yes":"No")
"nnDelivered:nt"
(m!isDelivered(this)?"Yes":"No")
"nnContents:nn----------nn"
m!getMailContents(this)
"nn----------nn";
g
void
MVUser::sendUserSystemViewMailTo(MVUser u)
f
UserSystemViewMail mailMessage new UserSystemViewMail();
mailMessage!setMailOriginator(this,this);
mailMessage!setMailReceiver(this,u);
mailMessage!setMailContents(this,
"Contents of a UserSystemView mail message");
mailMessage!send(this);
g
UserSystemViewMail::UserSystemViewMail()
f
mail new Mail();
assert( mail 6= (Mail )0);
g
UserSystemViewMail:: UserSystemViewMail()
f
delete mail;
g
void
UserSystemViewMail::pureSetMailOriginator(MVUser u)
f

A.2. UserSystemView Mail System 109
g
mail!setMailOriginator(u);
MVUser
UserSystemViewMail::pureGetMailOriginator(void)
f
return (MVUser ) mail!getMailOriginator();
g
void
UserSystemViewMail::pureSetMailReceiver(MVUser u)
f
mail!setMailReceiver(u);
g
MVUser
UserSystemViewMail::pureGetMailReceiver(void)
f
return (MVUser ) mail!getMailReceiver();
g
void
UserSystemViewMail::pureSetMailContents(char s)
f
mail!setMailContents(s);
g
char
UserSystemViewMail::pureGetMailContents(void)
f
return mail!getMailContents();
g
void
UserSystemViewMail::pureSend(void)
f
MVMailHandler::Instance()!send(this);
g
void
UserSystemViewMail::pureReply(void)
f
mail!reply();
g

110 Appendix A. C ++ Implementation of Multiple Views
void
UserSystemViewMail::pureApprove(void)
f
mail!approve();
g
int
UserSystemViewMail::pureIsApproved(void)
f
return mail!isApproved();
g
void
UserSystemViewMail::pureSetDelivered(void)
f
mail!setDelivered();
g
int
UserSystemViewMail::pureIsDelivered(void)
f
return mail!isDelivered();
g
void
UserSystemViewMail::pureSetRoute(MVMailHandler mh)
f
mail!setRoute(mh);
g
MVMailHandler
UserSystemViewMail::pureGetRoute(void)
f
return (MVMailHandler ) mail!getRoute();
g
int
UserSystemViewMail::isUserView(Object sender)
f
assert(sender6=(Object )0);
return sender!isKindOf(MVUserClass);
g

A.2. UserSystemView Mail System 111
int
UserSystemViewMail::isSystemView(Object sender)
f
assert(sender6=(Object )0);
return sender!isKindOf(MVMailHandlerClass);
g
void
UserSystemViewMail::setMailOriginator(Object sender,MVUser u)
f
assert(sender6=(Object )0);
CFilter(this!isUserView(sender),this!pureSetMailOriginator(u));
g
MVUser
UserSystemViewMail::getMailOriginator(Object sender)
f
assert(sender6=(Object )0);
return pureGetMailOriginator();
g
void
UserSystemViewMail::setMailReceiver(Object sender,MVUser u)
f
assert(sender6=(Object )0);
CFilter(this!isUserView(sender),this!pureSetMailReceiver(u));
g
MVUser
UserSystemViewMail::getMailReceiver(Object sender)
f
assert(sender6=(Object )0);
return pureGetMailReceiver();
g
void
UserSystemViewMail::setMailContents(Object sender,char s)
f
assert(sender6=(Object )0);
CFilter(this!isUserView(sender),this!pureSetMailContents(s));
g
char
UserSystemViewMail::getMailContents(Object sender)

112 Appendix A. C ++ Implementation of Multiple Views
f
g
char s (char )0;
assert(sender6=(Object )0);
CFilter(this!isUserView(sender),s this!pureGetMailContents());
return s;
void
UserSystemViewMail::send(Object sender)
f
assert(sender6=(Object )0);
CFilter(this!isUserView(sender),this!pureSend());
g
void
UserSystemViewMail::reply(Object sender)
f
assert(sender6=(Object )0);
CFilter(this!isUserView(sender),this!pureReply());
g
void
UserSystemViewMail::approve(Object sender)
f
assert(sender6=(Object )0);
CFilter(this!isSystemView(sender),this!pureApprove());
g
int
UserSystemViewMail::isApproved(Object sender)
f
assert(sender6=(Object )0);
return this!pureIsApproved();
g
void
UserSystemViewMail::setDelivered(Object sender)
f
assert(sender6=(Object )0);
CFilter(this!isSystemView(sender),this!pureSetDelivered());
g
int
UserSystemViewMail::isDelivered(Object sender)

A.3. OriginatorReceiverView Mail System 113
f
g
assert(sender6=(Object )0);
return this!pureIsDelivered();
void
UserSystemViewMail::setRoute(Object sender,MVMailHandler mh)
f
assert(sender6=(Object )0);
CFilter(this!isSystemView(sender),this!pureSetRoute(mh));
g
MVMailHandler
UserSystemViewMail::getRoute(Object sender)
f
assert(sender6=(Object )0);
return this!pureGetRoute();
g
#define CALL TEST FUNCTION test usersystemview mail();
void test usersystemview mail(void)
f
cout "UserSystemViewMail testnn";
MVUser u1 new MVUser();
u1!setName("MailOriginator");
MVUser u2 new MVUser();
u2!setName("MailReceiver");
u1!sendUserSystemViewMailTo(u2);
g
#include "main.inc"
#include "mail.cc"
A.3 OriginatorReceiverView Mail System
De nitions
#ifndef ORVMAIL H
#define ORVMAIL H
#include "usvmail.hpp"
(orvmail.hpp)

114 Appendix A. C ++ Implementation of Multiple Views
class VPUser : public MVUser
f
public:
virtual void sendOriginatorReceiverViewMailTo(MVUser );
g;
class OriginatorReceiverViewMail : public UserSystemViewMail
f
public:
virtual classTypes myClass(void) f return
OriginatorReceiverViewMailClass; g
virtual void setMailOriginator(Object ,MVUser );
virtual void setMailReceiver(Object ,MVUser );
virtual void setMailContents(Object ,char );
virtual char getMailContents(Object );
virtual void send(Object );
virtual void reply(Object );
protected:
virtual int isOriginatorView(Object );
virtual int isReceiverView(Object );
g;
#endif
Implementation
#include
#include
#include "orvmail.hpp"
(orvmail.cc)
void
VPUser::sendOriginatorReceiverViewMailTo(MVUser u)
f
OriginatorReceiverViewMail mailMessage new
OriginatorReceiverViewMail();
VPUser sneakUser new VPUser();
sneakUser!setName("Sneaky User");
mailMessage!setMailOriginator(this,this);
mailMessage!setMailReceiver(this,u);
mailMessage!setMailContents(this,
"Contents of a OriginatorReceiverView Mail Message");
mailMessage!send(this);
sneakUser!receive(mailMessage);

A.3. OriginatorReceiverView Mail System 115
g
int
OriginatorReceiverViewMail::isOriginatorView(Object sender)
f
assert(sender6=(Object )0);
return (this!getMailOriginator(this) (MVUser )0)
jj sender this!getMailOriginator(this);
g
int
OriginatorReceiverViewMail::isReceiverView(Object sender)
f
assert(sender6=(Object )0);
return sender this!getMailReceiver(this);
g
void
OriginatorReceiverViewMail::setMailOriginator(Object sender,MVUser u)
f
assert(sender6=(Object )0);
CFilter(this!isOriginatorView(sender),
UserSystemViewMail::setMailOriginator(sender,u));
g
void
OriginatorReceiverViewMail::setMailReceiver(Object sender,MVUser u)
f
assert(sender6=(Object )0);
CFilter(this!isOriginatorView(sender),
UserSystemViewMail::setMailReceiver(sender,u));
g
void
OriginatorReceiverViewMail::setMailContents(Object sender,char s)
f
assert(sender6=(Object )0);
CFilter(this!isOriginatorView(sender),
UserSystemViewMail::setMailContents(sender,s));
g
char
OriginatorReceiverViewMail::getMailContents(Object sender)
f

116 Appendix A. C ++ Implementation of Multiple Views
g
char s (char )0;
assert(sender6=(Object )0);
CFilter(this!isOriginatorView(sender)
jj this!isReceiverView(sender),
s UserSystemViewMail::getMailContents(sender));
return s;
void
OriginatorReceiverViewMail::send(Object sender)
f
assert(sender6=(Object )0);
CFilter(this!isOriginatorView(sender),
UserSystemViewMail::send(sender));
g
void
OriginatorReceiverViewMail::reply(Object sender)
f
assert(sender6=(Object )0);
CFilter(this!isReceiverView(sender),
UserSystemViewMail::reply(sender));
g
#define CALL TEST FUNCTION test originatorreceiverview mail();
void test originatorreceiverview mail(void)
f
cout "OriginatorReceiverViewMail testnn";
VPUser u1 new VPUser();
u1!setName("MailOriginator");
VPUser u2 new VPUser();
u2!setName("MailReceiver");
u1!sendOriginatorReceiverViewMailTo(u2);
g
#include "main.inc"
#include "usvmail.cc"
A.4 Group Mail System
De nitions
(gmail.hpp)

A.4. Group Mail System 117
#ifndef GMAIL H
#define GMAIL H
#include "orvmail.hpp"
class GroupUser: public VPUser
f
public:
GroupUser() f groupNumber 0; g
virtual classTypes myClass(void) f return GroupUserClass; g
virtual void sendGroupMailTo(MVUser );
virtual void setGroup(int i) f groupNumber i; g
virtual int getGroup(void) f return groupNumber; g
virtual int isKindOf(classTypes ct) f return ((ct MVUserClass) jj
VPUser::isKindOf(ct)); g
protected:
int groupNumber;
g;
class GroupMail : public OriginatorReceiverViewMail
f
public:
virtual classTypes myClass(void) f return GroupMailClass; g
protected:
virtual int isOriginatorView(Object );
g;
#endif
Implementation
#include
#include
#include "gmail.hpp"
void
GroupUser::sendGroupMailTo(MVUser u)
f
GroupMail mailMessage new GroupMail();
GroupUser groupMember new GroupUser();
groupMember!setName("GroupMember of MailOriginator");
groupMember!setGroup(100);
this!setGroup(100);
(gmail.cc)

118 Appendix A. C ++ Implementation of Multiple Views
g
mailMessage!setMailOriginator(this,this);
mailMessage!setMailReceiver(this,u);
mailMessage!setMailContents(this,
"Contents of a Group Mail Message");
mailMessage!send(this);
groupMember!receive(mailMessage);
int
GroupMail::isOriginatorView(Object sender)
f
MVUser orig this!getMailOriginator(this);
assert(sender6=(Object )0);
return (orig (MVUser )0)
jj sender orig
jj (sender!isKindOf(GroupUserClass) &&
orig!isKindOf(GroupUserClass)
&& ((GroupUser )sender)!getGroup()
((GroupUser )orig)!getGroup());
g
#define CALL TEST FUNCTION test group mail();
void test group mail(void)
f
cout "Group Mail testnn";
GroupUser u1 new GroupUser();
u1!setName("MailOriginator");
GroupUser u2 new GroupUser();
u2!setName("MailReceiver");
u1!sendGroupMailTo(u2);
g
#include "main.inc"
#include "orvmail.cc"
A.5 Secure Mail System
De nitions
#ifndef SMAIL H
#define SMAIL H
(smail.hpp)

A.5. Secure Mail System 119
#include "gmail.hpp"
class PGPUser : public GroupUser
f
public:
virtual classTypes myClass(void) f return PGPUserClass; g
virtual int isKindOf(classTypes ct) f return (ct GroupUserClass jj
GroupUser::isKindOf(ct)); g
virtual void setPGPPubKey(int i) f publicKey i; g
virtual int getPGPPubKey(void) f return publicKey; g
virtual void setPGPPrivKey(int i) f privateKey i; g
virtual int getPGPPrivKey(void) f return privateKey; g
virtual void sendSecureMailTo(MVUser );
private:
int publicKey;
int privateKey;
g;
class SecureMail : public GroupMail
f
public:
virtual classTypes myClass(void) f return SecureMailClass; g
virtual char getMailContents(Object );
virtual void setMailContents(Object , char );
protected:
virtual int isPGPUserView(Object );
private:
virtual char purePGPGetMailContents(Object );
virtual void purePGPSetMailContents(Object , char );
g;
#endif
Implementation
#include
#include
#include "smail.hpp"
void
PGPUser::sendSecureMailTo(MVUser u)
f
SecureMail mailMessage new SecureMail();
(smail.cc)

120 Appendix A. C ++ Implementation of Multiple Views
g
GroupUser nonPGPUser new GroupUser();
nonPGPUser!setName("NON PGP USER");
nonPGPUser!setGroup(100);
this!setGroup(100);
mailMessage!setMailOriginator(this,this);
mailMessage!setMailReceiver(this,u);
mailMessage!setMailContents(this,
"Contents of a Secure Mail Message");
mailMessage!send(this);
nonPGPUser!receive(mailMessage);
int
SecureMail::isPGPUserView(Object sender)
f
return sender!isKindOf(PGPUserClass);
g
char
SecureMail::getMailContents(Object sender)
f
char s (char )0;
if (this!isPGPUserView(sender)) f
s this!purePGPGetMailContents(sender);
g else f
s GroupMail::getMailContents(sender);
g
return s;
g
void
SecureMail::setMailContents(Object sender,char s)
f
if (this!isPGPUserView(sender)) f
this!purePGPSetMailContents(sender,s);
g else f
GroupMail::setMailContents(sender,s);
g
g
char
SecureMail::purePGPGetMailContents(Object sender)
f
char l, s strdup(GroupMail::getMailContents(sender));

A.6. Warning2 Mail System 121
g
cout "PGP decoding...nn";
for (l s; l;l++) ( l)--;
return s;
void
SecureMail::purePGPSetMailContents(Object sender, char s)
f
char l, c strdup(s);
cout "PGP encoding...nn";
for (l c; l;l++) ( l)++;
GroupMail::setMailContents(sender,c);
g
#define CALL TEST FUNCTION test secure mail();
void test secure mail(void)
f
cout "Secure Mail testnn";
PGPUser u1 new PGPUser();
u1!setName("MailOriginator");
PGPUser u2 new PGPUser();
u2!setName("MailReceiver");
u1!sendSecureMailTo(u2);
g
#include "main.inc"
#include "gmail.cc"
A.6 Warning2 Mail System
De nitions
#ifndef W2MAIL H
#define W2MAIL H
#include "smail.hpp"
typedef enum f
W2MailSetMailContentsSelector,
W2MailSetMailOriginatorSelector,
W2MailSetMailReceiverSelector,
W2MailSendSelector,
(w2mail.hpp)

122 Appendix A. C ++ Implementation of Multiple Views
lastWarning2MailSelector
g Warning2MailSelector;
class Warning2User : public PGPUser
f
public:
virtual void sendWarning2MailTo(MVUser );
g;
class Warning2Mail : public SecureMail
f
public:
Warning2Mail();
virtual classTypes myClass(void) f return Warning2MailClass; g
virtual void setMailContents(Object ,char );
virtual void setMailOriginator(Object , MVUser );
virtual void setMailReceiver(Object , MVUser );
virtual void send(Object );
protected:
virtual int isWarning2View(Warning2MailSelector);
private:
int selectorCount[ lastWarning2MailSelector];
g;
#endif
Implementation
#include
#include "w2mail.hpp"
void
Warning2User::sendWarning2MailTo(MVUser u)
f
Warning2Mail mailMessage new Warning2Mail();
mailMessage!setMailOriginator(this,this);
mailMessage!setMailOriginator(this,this);
mailMessage!setMailReceiver(this,u);
mailMessage!setMailReceiver(this,u);
mailMessage!setMailContents(this,
"First contents of a Warning2 Mail Message");
mailMessage!setMailContents(this,
"Second contents of a Warning2 Mail Message");
(w2mail.cc)

A.6. Warning2 Mail System 123
g
mailMessage!send(this);
Warning2Mail::Warning2Mail()
f
int i;
for (i 0;i< lastWarning2MailSelector;i++)
selectorCount[i] 0;
g
int
Warning2Mail::isWarning2View(Warning2MailSelector sel)
f
return selectorCount[sel] > 0;
g
void
Warning2Mail::setMailContents(Object sender, char s)
f
if (this!isWarning2View(W2MailSetMailContentsSelector)) f
cout "Warning, setMailContents sent twicenn";
g
selectorCount[W2MailSetMailContentsSelector]++;
SecureMail::setMailContents(sender,s);
g
void
Warning2Mail::setMailOriginator(Object sender, MVUser u)
f
if (this!isWarning2View(W2MailSetMailOriginatorSelector)) f
cout "Warning, setMailOriginator sent twicenn";
g
selectorCount[W2MailSetMailOriginatorSelector]++;
SecureMail::setMailOriginator(sender,u);
g
void
Warning2Mail::setMailReceiver(Object sender, MVUser u)
f
if (this!isWarning2View(W2MailSetMailReceiverSelector)) f
cout "Warning, setMailReceiver sent twicenn";
g
selectorCount[W2MailSetMailReceiverSelector]++;
SecureMail::setMailReceiver(sender,u);

124 Appendix A. C ++ Implementation of Multiple Views
g
void
Warning2Mail::send(Object sender)
f
if (this!isWarning2View(W2MailSendSelector)) f
cout "Warning, send sent twicenn";
g
selectorCount[W2MailSendSelector]++;
SecureMail::send(sender);
g
#define CALL TEST FUNCTION test w2 mail();
void test w2 mail(void)
f
cout "w2 Mail testnn";
Warning2User u1 new Warning2User();
u1!setName("MailOriginator");
Warning2User u2 new Warning2User();
u2!setName("MailReceiver");
u1!sendWarning2MailTo(u2);
g
#include "main.inc"
#include "smail.cc"
A.7 Protected Mail System
De nitions
#ifndef PMAIL H
#define PMAIL H
#include "w2mail.hpp"
class SecureDocument:public Object f
public:
virtual void setSecurityLevel(int);
virtual int getSecurityLevel(void);
protected:
int isSecurityClearance(Object );
private:
(pmail.hpp)

A.7. Protected Mail System 125
g;
int securityLevel;
class ProtectedUser : public Warning2User
f
public:
virtual classTypes myClass(void) f return ProtectedUserClass; g
virtual int getSecurityLevel(void);
virtual void setSecurityLevel(int);
virtual void sendProtectedMailTo(MVUser );
virtual int isKindOf(classTypes ct) f return ((ct PGPUserClass) jj
Warning2User::isKindOf(ct)); g
private:
int securityLevel;
g;
class ProtectedMail : public Warning2Mail, public SecureDocument
f
public:
virtual classTypes myClass(void) f return ProtectedMailClass; g
virtual void setMailContents(Object ,char );
virtual char getMailContents(Object );
g;
#endif
Implementation
#include
#include "pmail.hpp"
void
SecureDocument::setSecurityLevel(int i) f
securityLevel i;
g
int
SecureDocument::getSecurityLevel(void) f
return securityLevel;
g
int
SecureDocument::isSecurityClearance(Object sender) f
(pmail.cc)

126 Appendix A. C ++ Implementation of Multiple Views
g
return (sender!isKindOf(ProtectedUserClass)) &&
(((ProtectedUser )sender)!getSecurityLevel()
this!getSecurityLevel());
void
ProtectedUser::setSecurityLevel(int i) f
securityLevel i;
g
int
ProtectedUser::getSecurityLevel(void) f
return securityLevel;
g
void
ProtectedUser::sendProtectedMailTo(MVUser u)
f
ProtectedMail mailMessage new ProtectedMail();
mailMessage!setMailOriginator(this,this);
mailMessage!setMailReceiver(this,u);
mailMessage!setSecurityLevel(3);
mailMessage!setMailContents(this,
"Contents of a Protected Mail Message");
mailMessage!send(this);
mailMessage!setSecurityLevel(1);
mailMessage!send(this);
g
void
ProtectedMail::setMailContents(Object sender, char s)
f
CFilter(this!isSecurityClearance(sender),
Warning2Mail::setMailContents(sender,s));
g
char
ProtectedMail::getMailContents(Object sender)
f
char s (char )0;
CFilter(this!isSecurityClearance(sender),s
Warning2Mail::getMailContents(sender));
return s;
g

A.7. Protected Mail System 127
#define CALL TEST FUNCTION test protected mail();
void test protected mail(void)
f
cout "Protected Mail testnn";
ProtectedUser u1 new ProtectedUser();
u1!setName("MailOriginator");
u1!setSecurityLevel(4);
ProtectedUser u2 new ProtectedUser();
u2!setName("MailReceiver");
u2!setSecurityLevel(2);
u1!sendProtectedMailTo(u2);
g
#include "main.inc"
#include "w2mail.cc"

128 Appendix A. C ++ Implementation of Multiple Views

Appendix B
Sina Implementation of Multiple Views
B.1 Simple Mail System
#NoDefSyncFilter;
class MailHandler interface
methods
send (aMailMessage : Mail) returns nil;
getName returns String;
setName (aName : String) returns nil;
input lters
dis : Dispatch =f inner. g;
end;
class MailHandler implementation
instvars
name : String;
initial
begin
name 'NoName'
end;
methods
send (aMailMessage : Mail)
begin
return;
if aMailMessage.getMailReceiver 6= nil
then
aMailMessage.approve
end;
server.printLine('Peeking into the MailMessage');
server.printLine(aMailMessage.getMailContents);
if aMailMessage.isApproved
then
(MailHandler.sina)
129

130 Appendix B. Sina Implementation of Multiple Views
aMailMessage.setRoute(server);
aMailMessage.setDelivered;
aMailMessage.getMailReceiver.receive(aMailMessage)
end
end;
getName
begin
return name
end;
setName (aName : String)
begin
name aName
end;
end;
class User interface
methods
setName (aName : String) returns nil;
getName returns String;
receive (aMailMessage : Mail) returns nil;
sendSimpleMailTo (aUser : User) returns nil;
input lters
dis : Dispatch =f inner. g;
end;
class User implementation
instvars
name : String;
initial
begin
name 'NoName'
end;
methods
setName (aName : String)
begin
name aName
end;
getName
begin
return name
end;
receive (aMailMessage : Mail)
begin
(User.sina)

B.1. Simple Mail System 131
return;
server.print('User ');
server.print(server.getName);
server.print(' received mail from ');
server.printLine(aMailMessage.getMailOriginator.getName);
server.print('Route: ');
server.printLine(aMailMessage.getRoute.getName);
server.print('Approved: ');
server.printLine(aMailMessage.isApproved);
server.print('Delivered: ');
server.printLine(aMailMessage.isDelivered);
server.print('Contents:');
server.printLine(aMailMessage.getMailContents);
end;
sendSimpleMailTo (aUser : User)
temps
aMailMessage : Mail;
begin
aMailMessage.setMailOriginator(server);
aMailMessage.setMailReceiver(aUser);
aMailMessage.setMailContents(
'Contents of a simple mail message');
aMailMessage.send
end;
end;
class Mail interface
externals
MH : MailHandler;
methods
setMailOriginator (aUser : User) returns nil;
getMailOriginator returns User;
setMailReceiver (aUser : User) returns nil;
getMailReceiver returns User;
setMailContents (aString : String) returns nil;
getMailContents returns String;
send returns nil;
reply returns nil;
approve returns nil;
isApproved returns Boolean;
setDelivered returns nil;
isDelivered returns Boolean;
setRoute (aMH : MailHandler) returns nil;
(Mail.sina)

132 Appendix B. Sina Implementation of Multiple Views
getRoute returns MailHandler;
input lters
dis : Dispatch =f inner. g;
end;
class Mail implementation
instvars
mailOriginator : User;
mailReceiver : User;
mailContents : String;
approved : Boolean;
delivered : Boolean;
route : MailHandler;
initial
begin
mailOriginator nil;
mailReceiver nil;
mailContents '';
approved false;
delivered false;
route nil
end;
methods
setMailOriginator (aUser : User)
begin
mailOriginator aUser
end;
getMailOriginator
begin
return mailOriginator
end;
setMailReceiver (aUser : User)
begin
mailReceiver aUser
end;
getMailReceiver
begin
return mailReceiver
end;
setMailContents (aString : String)
begin
mailContents aString
end;
getMailContents

B.1. Simple Mail System 133
begin
return mailContents
end;
send
begin
MH.send(server)
end;
reply
begin
server.print('Not implemented')
end;
approve
begin
approved true
end;
isApproved
begin
return approved
end;
setDelivered
begin
delivered true
end;
isDelivered
begin
return delivered
end;
setRoute (aMH : MailHandler)
begin
route aMH
end;
getRoute
begin
return route
end;
end;
main
temps
u1 : User;
u2 : User;
begin
u1.setName('MailOriginator');
(MailMain.sina)

134 Appendix B. Sina Implementation of Multiple Views
end
u2.setName('MailReceiver');
u1.sendSimpleMailTo(u2);
B.2 UserSystemView Mail System
(UserSystemViewMail.sina)
class UserSystemViewMail interface
externals
User : Class;
MailHandler : Class;
internals
mail : Mail;
conditions
userView;
systemView;
input lters
mv1 : Error = f userView ) setMailOriginator,
true ; setMailOriginator g;
mv2 : Error = f userView ) setMailReceiver, true ; setMailReceiver g;
mv3 : Error = f userView ) setMailContents,
true ; setMailContents g;
mv4 : Error = f userView ) getMailContents,
true ; getMailContents g;
mv5 : Error = f userView ) send, true ; send g;
mv6 : Error = f userView ) reply, true ; reply g;
mv7 : Error = f systemView ) approve, true ; approve g;
mv8 : Error = f systemView ) setDelivered, true ; setDelivered g;
mv9 : Error = f systemView ) setRoute, true ; setRoute g;
disp : Dispatch =f inner. , mail. g;
end;
class UserSystemViewMail implementation
conditions
userView
begin
return message.sender.isKindOf:(User)
end;
systemView
begin
return message.sender.isKindOf:(MailHandler)
end;
end;

B.3. OriginatorReceiverView Mail System 135
class MVUser interface
internals
user : User;
methods
sendUserSystemViewMailTo (aUser : User) returns nil;
input lters
disp : Dispatch =f inner. , user. g;
end;
class MVUser implementation
methods
sendUserSystemViewMailTo (aUser : User)
temps
aMailMessage : UserSystemViewMail;
begin
aMailMessage.setMailOriginator(self);
aMailMessage.setMailReceiver(aUser);
aMailMessage.setMailContents(
'Contents of a UserSystem Mail Message');
aMailMessage.send
end;
end;
main
temps
u1 : MVUser;
u2 : MVUser;
begin
u1.setName('MailOriginator');
u2.setName('MailReceiver');
u1.sendUserSystemViewMailTo(u2);
end
B.3 OriginatorReceiverView Mail System
class OriginatorReceiverViewMail interface
externals
User : Class;
MailHandler : Class;
internals
(MVUser.sina)
(UserSystemViewMailMain.sina)
(OriginatorReceiverViewMail.sina)

136 Appendix B. Sina Implementation of Multiple Views
mail : UserSystemViewMail;
conditions
originatorView;
receiverView;
input lters
mv1 : Error = f originatorView ) setMailOriginator,
true ; setMailOriginator g;
mv2 : Error = f originatorView ) setMailReceiver,
true ; setMailReceiver g;
mv3 : Error = f originatorView ) setMailContents
true ; setMailContents g;
mv4 : Error = f originatorView ) getMailContents,
receiverView ) getMailContents,
true ; getMailContents g;
mv5 : Error = f originatorView ) send, true ; send g;
mv6 : Error = f receiverView ) reply, true ; reply g;
disp : Dispatch =f inner. , mail. g;
end;
class OriginatorReceiverViewMail implementation
conditions
originatorView
begin
return (mail.getMailOriginator nil)
jj (mail.getMailOriginator message.sender);
end;
receiverView
begin
return mail.getMailReceiver message.sender
end;
end;
class VPUser interface
internals
user : MVUser;
methods
sendOriginatorReceiverViewMailTo (aUser : User) returns nil;
input lters
disp : Dispatch =f inner. , user. g;
end;
class VPUser implementation
methods
(VPUser.sina)

B.4. Group Mail System 137
sendOriginatorReceiverViewMailTo (aUser : User)
temps
aMailMessage : OriginatorReceiverViewMail;
sneakUser : User;
begin
aMailMessage.setMailOriginator(self);
aMailMessage.setMailReceiver(aUser);
aMailMessage.setMailContents(
'Contents of a OriginatorReceiver Mail Message');
aMailMessage.send;
sneakUser.receive(aMailMessage)
end;
end;
main
temps
u1 : VPUser;
u2 : VPUser;
begin
u1.setName('MailOriginator');
u2.setName('MailReceiver');
u1.sendOriginatorReceiverViewMailTo(u2);
end
B.4 Group Mail System
class GroupMail interface
externals
GroupUser : Class;
internals
mail : OriginatorReceiverViewMail;
conditions
originatorView;
input lters
dis : Dispatch =f inner. , mail. g;
end;
class GroupMail implementation
conditions
originatorView
temps
orig : User;
(OriginatorReceiverViewMailMain.sina)
(GroupMail.sina)

138 Appendix B. Sina Implementation of Multiple Views
begin
orig mail.getMailOriginator;
return (orig nil)
jj (orig message.sender)
jj ( orig.isKindOf(GroupUser)
message.sender.isKindOf(GroupUser)
orig.getGroup message.sender.getGroup )
end
end;
class GroupUser interface
internals
user : VPUser;
groupNumber : Integer;
methods
getGroup returns Integer;
setGroup (num:Integer) returns nil;
sendGroupMailTo(aUser : User) returns nil;
input lters
dis : Dispatch =f inner. , user. g;
end;
(GroupUser.sina)
class GroupUser implementation
initial
begin
groupNumber 0;
end
methods
getGroup
begin
return groupNumber;
end
setGroup (num:Integer)
begin
groupNumber num;
end
sendGroupMailTo(aUser : User)
temps
aMailMessage : GroupMail;
groupMember : GroupUser;
begin
groupMember.setName('GroupMember of MailOriginator');
groupMember.setGroup(100);

B.5. Secure Mail System 139
self.setGroup(100);
aMailMessage.setMailOriginator(self);
aMailMessage.setMailReceiver(aUser);
aMailMessage.setMailContents(
'Contents of a Group Mail Message');
aMailMessage.send;
groupMember.receive(aMailMessage);
end;
end;
main
temps
u1 : GroupUser;
u2 : GroupUser;
begin
u1.setName('MailOriginator');
u2.setName('MailReceiver');
u1.sendGroupMailTo(u2);
end
B.5 Secure Mail System
(GroupMailMain.sina)
(SecureMail.sina)
class SecureMail interface
externals
PGPUser : Class;
internals
mail : GroupMail;
conditions
pgpView;
input lters
dis : Dispatch =f pgpView->[getMailContents]getPGPMailContents,
pgpView->[setMailContents]setPGPMailContents,
inner. , mail. g;
end;
class SecureMail implementation
conditions
pgpView
begin
return message.sender.isKindOf(PGPUSer);
end
methods

140 Appendix B. Sina Implementation of Multiple Views
getPGPMailContents returns String
begin
self.printLine('PGP decoding...');
return self.getMailContents
end;
setPGPMailContents(s:String) returns nil
begin
self.printLine('PGP encoding...');
self.setMailContents(s);
end;
end;
class PGPUser interface
internals
user : GroupUser;
publicKey : Integer;
privateKey : Integer;
methods
setPGPPubKey(i:Integer) returns nil;
getPGPPubKey returns Integer;
setPGPPrivKey(i:Integer) returns nil;
getPGPPrivKey returns Integer;
sendSecureMailTo(aUser : User) returns nil;
input lters
dis : Dispatch =f inner. , user. g;
end;
class PGPUser implementation
initial
begin
publicKey 0;
privateKey 0;
end
methods
setPGPPubKey(i:Integer)
begin
publicKey i;
end
getPGPPubKey
begin
return publicKey;
end
setPGPPrivKey(i:Integer)
(PGPUser.sina)

B.6. Warning2 Mail System 141
begin
privateKey i;
end
getPGPPrivKey
begin
return privateKey;
end
sendSecureMailTo(aUser : User)
temps
aMailMessage : SecureMail;
nonPGPUser : GroupUser;
begin
nonPGPUser.setName('Non PGP User');
nonPGPUser.setGroup(100);
self.setGroup(100);
aMailMessage.setMailOriginator(self);
aMailMessage.setMailReceiver(aUser);
aMailMessage.setMailContents(
'Contents of a Secure Mail Message');
aMailMessage.send;
nonPGPUser.receive(aMailMessage);
end;
end;
main
temps
u1 : PGPUser;
u2 : PGPUser;
begin
u1.setName('MailOriginator');
u2.setName('MailReceiver');
u1.sendSecureMailTo(u2);
end
B.6 Warning2 Mail System
class Warning2Mail interface
internals
mail : SecureMail;
messageCounter : MCount;
input lters
(SecureMailMain.sina)
(Warning2Mail.sina)

142 Appendix B. Sina Implementation of Multiple Views
count : Meta = f
[setMailContents,setMailOriginator,setMailReceiver,send]
messageCounter.warning2Message g;
dis : Dispatch =f inner. , mail. g;
end;
class Warning2Mail implementation
comment
No implementation, warning mechanism is handled by the meta
object.
end;
class Warning2User interface
internals
user : PGPUser;
methods
sendWarning2MailTo(aUser : User) returns nil;
input lters
dis : Dispatch =f inner. , user. g;
end;
class Warning2User implementation
methods
sendWarning2MailTo(aUser : User)
temps
aMailMessage : Warning2Mail;
begin
aMailMessage.setMailOriginator(self);
aMailMessage.setMailOriginator(self);
aMailMessage.setMailReceiver(aUser);
aMailMessage.setMailReceiver(aUser);
aMailMessage.setMailContents(
'Contents of a Secure Mail Message');
aMailMessage.setMailContents(
'Contents of a Secure Mail Message');
aMailMessage.send;
end;
end;
class MCount interface
internals
counts : Dictionary;
methods
(Warning2User.sina)
(MCount.sina)

B.7. Protected Mail System 143
warning2Message(m:SinaMessage) returns nil;
input lters
dis : Dispatch =f inner. g;
end;
class MCount implementation
methods
warning2Message(m:SinaMessage)
begin
counts.atPut(m.selector,counts.atIfAbsent(m.selector,0) + 1);
if (counts.at(m.selector) > 1)
begin
self.printLine('Warning, message sent more than once');
end;
m.continue;
end;
end;
main
temps
u1 : Warning2User;
u2 : Warning2User;
begin
u1.setName('MailOriginator');
u2.setName('MailReceiver');
u1.sendWarning2MailTo(u2);
end
B.7 Protected Mail System
class ProtectedMail interface
internals
mail : Warning2Mail;
secdoc : SecureDocument;
input lters
err : Error = f securityClearance -> fgetMailContents,
setMailContentsg,
true ;fgetMailContents, setMailContentsg g;
dis : Dispatch =f inner. , mail. , secdoc. g;
end;
class ProtectedMail implementation
(Warning2MailMain.sina)
(ProtectedMail.sina)

144 Appendix B. Sina Implementation of Multiple Views
end;
class ProtectedUser interface
internals
user : Warning2User;
securityLevel : Integer;
methods
getSecurityLevel returns Integer;
setSecurityLevel(i:Integer) returns nil;
sendProtectedMailTo(aUser:User);
inputFilters
disp : Dispatch =f inner. , user. g;
end;
class ProtectedUser implementation
initial
begin
securityLevel 0;
end;
methods
getSecurityLevel
begin
return securityLevel;
end;
setSecurityLevel(i:Integer)
begin
securityLevel i;
end;
sendProtectedMailTo(aUser : User)
temps
aMailMessage : ProtectedMail;
begin
aMailMessage.setMailOriginator(self);
aMailMessage.setMailReceiver(aUser);
aMailMessage.setSecurityLevel(3);
aMailMessage.setMailContents(
'Contents of a Protected Mail Message');
aMailMessage.send;
aMailMessage.setSecurityLevel(1);
aMailMessage.send;
end;
end;
(ProtectedUser.sina)
(ProtectedMailMain.sina)

B.7. Protected Mail System 145
main
temps
u1 : PUser;
u2 : PUser;
begin
u1.setName('MailOriginator');
u1.setSecurityLevel(4);
u2.setName('MailReceiver');
u2.setSecurityLevel(2);
u1.sendProtectedMailTo(u2);
end

146 Appendix B. Sina Implementation of Multiple Views

Appendix C
C ++ Implementation of Layering
C.1 Heading Mail System
De nitions
#ifndef HMAIL H
#define HMAIL H
#include "mail.hpp"
class HUser : public User
f
public:
virtual void receive(Mail );
virtual void sendHeadingMailTo(HUser );
g;
class HeadingMail : public Mail
f
public:
virtual char getMailHeading(void);
virtual char getMailAsText(void);
g;
#endif
Implementation
#include
#include
#include
#include
#include "hmail.hpp"
(hmail.hpp)
(hmail.cc)
147

148 Appendix C. C ++ Implementation of Layering
void
HUser::receive(Mail m)
f
char s ((HeadingMail )m)!getMailAsText();
cout s "nn";
delete s;
g
void
HUser::sendHeadingMailTo(HUser u)
f
HeadingMail mailMessage new HeadingMail();
mailMessage!setMailOriginator(this);
mailMessage!setMailReceiver(u);
mailMessage!setMailContents(
"Contents of a Heading mail message");
mailMessage!send();
g
char
HeadingMail::getMailHeading(void)
f
char o, r, h, s;
o this!getMailOriginator()!getName();
r this!getMailReceiver()!getName();
h this!getRoute()!getName();
s (char )malloc(strlen(o)+strlen(r)+strlen(h)+31);
sprintf(s,"Sender:ntnt%snnReceiver:nt%snnRoute:ntnt%snn",
o,r,h);
return s;
g
char
HeadingMail::getMailAsText(void)
f
char c, h, r;
c this!getMailContents();
h this!getMailHeading();
r (char )malloc(sizeof(char) (strlen(c)+strlen(h)+1));
strcpy(r,h);
strcat(r,c);
delete h;
return r;

C.2. Attachment Mail System 149
g
#define CALL TEST FUNCTION test heading mail();
void test heading mail(void)
f
cout "Heading Mail testnn";
HUser u1 new HUser();
u1!setName("MailOriginator");
HUser u2 new HUser();
u2!setName("MailReceiver");
u1!sendHeadingMailTo(u2);
g
#include "main.inc"
#include "mail.cc"
C.2 Attachment Mail System
De nitions
#ifndef AMAIL H
#define AMAIL H
#include "hmail.hpp"
class AUser : public HUser
f
public:
virtual void sendAttachmentMailTo(AUser );
g;
class Attachment
f
public:
Attachment() f lename NULL; g
virtual char getFilename(void) f return lename; g
virtual void setFilename(char s) f lename s; g
private:
char lename;
g;
class AttachmentMail : public HeadingMail
(amail.hpp)

150 Appendix C. C ++ Implementation of Layering
f
public:
AttachmentMail() f attachment NULL; g
virtual Attachment getMailAttachment(void) f return attachment; g
virtual void setMailAttachment(Attachment a) f attachment a; g
virtual char getMailHeading(void);
private:
Attachment attachment;
g;
#endif
Implementation
#include
#include
#include
#include
#include "amail.hpp"
void
AUser::sendAttachmentMailTo(AUser u)
f
AttachmentMail aMailMessage new AttachmentMail();
Attachment a new Attachment();
a!setFilename(" /attachment.doc");
aMailMessage!setMailOriginator(this);
aMailMessage!setMailReceiver(u);
aMailMessage!setMailContents(
"Contents of an attachment mail message");
aMailMessage!setMailAttachment(a);
aMailMessage!send();
g
char
AttachmentMail::getMailHeading(void)
f
char h, a, s;
h HeadingMail::getMailHeading();
if ( attachment NULL) f
s h;
g else f
a this!getMailAttachment()!getFilename();
(amail.cc)

C.3. ReadNoti cation Mail System 151
g
s (char )malloc(strlen(h)+strlen(a)+14);
sprintf(s,"%sAttachment:nt%snn",h,a);
delete h;
g
return s;
#define CALL TEST FUNCTION test attachment mail();
void test attachment mail(void)
f
cout "Attachment Mail testnn";
AUser u1 new AUser();
u1!setName("MailOriginator");
AUser u2 new AUser();
u2!setName("MailReceiver");
u1!sendAttachmentMailTo(u2);
g
#include "main.inc"
#include "hmail.cc"
C.3 ReadNoti cation Mail System
De nitions
#ifndef RNMAIL H
#define RNMAIL H
#include "usvmail.hpp"
class RNUser : public MVUser
f
public:
virtual void sendReadNoti cationMailTo(RNUser u);
virtual char className(void) f return "RNUser"; g
g;
class ReadNoti cationMail : public UserSystemViewMail
f
public:
ReadNoti cationMail() f mustNotify 0; noti ed 0; g
virtual void setNotify(int i) f mustNotify i; g
(rnmail.hpp)

152 Appendix C. C ++ Implementation of Layering
virtual char getMailContents(Object );
protected:
virtual int senderIsReceiverAndMustNotify(Object sender);
virtual int isUserView(Object sender);
virtual void notify(void);
virtual char className(void) f return "ReadNotificationMail"; g
private:
int mustNotify;
int noti ed;
g;
#endif
Implementation
#include
#include "rnmail.hpp"
(rnmail.cc)
void
RNUser::sendReadNoti cationMailTo(RNUser u)
f
ReadNoti cationMail mailMessage new ReadNoti cationMail();
mailMessage!setMailOriginator(this,this);
mailMessage!setMailReceiver(this,u);
mailMessage!setMailContents(this,
"Contents of a read notification mail message");
mailMessage!setNotify(1);
mailMessage!send(this);
g
char
ReadNoti cationMail::getMailContents(Object sender)
f
if (this!senderIsReceiverAndMustNotify(sender))
this!notify();
return UserSystemViewMail::getMailContents(sender);
g
int
ReadNoti cationMail::senderIsReceiverAndMustNotify(Object sender)
f
return (this!getMailReceiver(this) sender)
&& mustNotify

C.4. History Mail System 153
g
&& !noti ed;
int
ReadNoti cationMail::isUserView(Object sender)
f
return sender!isKindOf(UserSystemViewMailClass)
jj UserSystemViewMail::isUserView(sender);
g
void
ReadNoti cationMail::notify(void)
f
ReadNoti cationMail m new ReadNoti cationMail();
noti ed 1;
m!setMailOriginator(this,this!getMailReceiver(this));
m!setMailReceiver(this,this!getMailOriginator(this));
m!setMailContents(this,"Read Notification");
m!setNotify(0);
m!send(this);
g
#define CALL TEST FUNCTION test readnoti cation mail();
void test readnoti cation mail(void)
f
cout "Read Notification Mail testnn";
RNUser u1 new RNUser();
u1!setName("MailOriginator");
RNUser u2 new RNUser();
u2!setName("MailReceiver");
u1!sendReadNoti cationMailTo(u2);
g
#include "main.inc"
#include "usvmail.cc"
C.4 History Mail System
De nitions
#ifndef HISMAIL H
#define HISMAIL H
(hismail.hpp)

154 Appendix C. C ++ Implementation of Layering
#include "rnmail.hpp"
class HisUser : public RNUser
f
public:
virtual void sendHistoryMailTo(HisUser );
virtual char className(void) f return "HisUser"; g
g;
class HistoryMail : public ReadNoti cationMail
f
public:
HistoryMail() f initMeta(); g
HistoryMail() f closeMeta(); g
virtual void historyReport(void);
virtual void setMailOriginator(Object ,MVUser );
virtual MVUser getMailOriginator(Object );
virtual void setMailReceiver(Object ,MVUser );
virtual MVUser getMailReceiver(Object );
virtual void setMailContents(Object ,char );
virtual char getMailContents(Object );
virtual void send(Object );
virtual void reply(Object );
virtual void approve(Object );
virtual int isApproved(Object );
virtual void setDelivered(Object );
virtual int isDelivered(Object );
virtual void setRoute(Object ,MVMailHandler );
virtual MVMailHandler getRoute(Object );
virtual char className(void) f return "HistoryMail"; g
private:
void initMeta(void) f report NULL; g
void closeMeta(void) f if (report) delete report; g
virtual void doMeta(char selector, Object sender);
char report;
g;
#endif
Implementation
#include
(hismail.cc)

C.4. History Mail System 155
#include
#include
#include
#include "hismail.hpp"
#define MAX(A,B) (A

156 Appendix C. C ++ Implementation of Layering
g
size size = old info = +
strlen(ts) = time info = +
1 = tab = +
MAX(strlen(cs),15) = for sender name = +
1 = tab = +
strlen(selector) +
2 = NL + n0 = ;
s (char )malloc(sizeof(char) size);
sprintf(s,"%s%s %-15s %snn",report,ts,cs,selector);
if (report[0] 6= 0)
delete report;
report s;
void
HistoryMail::setMailOriginator(Object sender,MVUser user)
f
this!doMeta("setMailOriginator",sender);
ReadNoti cationMail::setMailOriginator(sender,user);
g
MVUser
HistoryMail::getMailOriginator(Object sender)
f
this!doMeta("getMailOriginator",sender);
return ReadNoti cationMail::getMailOriginator(sender);
g
void
HistoryMail::setMailReceiver(Object sender,MVUser user)
f
this!doMeta("setMailReceiver",sender);
ReadNoti cationMail::setMailReceiver(sender,user);
g
MVUser
HistoryMail::getMailReceiver(Object sender)
f
this!doMeta("getMailReceiver",sender);
return ReadNoti cationMail::getMailReceiver(sender);
g
void

C.4. History Mail System 157
HistoryMail::setMailContents(Object sender,char s)
f
this!doMeta("setMailContents",sender);
ReadNoti cationMail::setMailContents(sender,s);
g
char
HistoryMail::getMailContents(Object sender)
f
this!doMeta("getMailContents",sender);
return ReadNoti cationMail::getMailContents(sender);
g
void
HistoryMail::send(Object sender)
f
this!doMeta("send",sender);
ReadNoti cationMail::send(sender);
g
void
HistoryMail::reply(Object sender)
f
this!doMeta("reply",sender);
ReadNoti cationMail::reply(sender);
g
void
HistoryMail::approve(Object sender)
f
this!doMeta("approve",sender);
ReadNoti cationMail::approve(sender);
g
int
HistoryMail::isApproved(Object sender)
f
this!doMeta("isApproved",sender);
return ReadNoti cationMail::isApproved(sender);
g
void
HistoryMail::setDelivered(Object sender)
f

158 Appendix C. C ++ Implementation of Layering
g
this!doMeta("setDelivered",sender);
ReadNoti cationMail::setDelivered(sender);
int
HistoryMail::isDelivered(Object sender)
f
this!doMeta("isDelivered",sender);
return ReadNoti cationMail::isDelivered(sender);
g
void
HistoryMail::setRoute(Object sender,MVMailHandler h)
f
this!doMeta("setRoute",sender);
ReadNoti cationMail::setRoute(sender,h);
g
MVMailHandler
HistoryMail::getRoute(Object sender)
f
this!doMeta("getRoute",sender);
return ReadNoti cationMail::getRoute(sender);
g
#define CALL TEST FUNCTION test history mail();
void test history mail(void)
f
cout "History Mail testnn";
HisUser u1 new HisUser();
u1!setName("MailOriginator");
HisUser u2 new HisUser();
u2!setName("MailReceiver");
u1!sendHistoryMailTo(u2);
g
#include "main.inc"
#include "rnmail.cc"

C.5. Dynamic Mail System 159
C.5 Dynamic Mail System
De nitions
#ifndef DMAIL H
#define DMAIL H
#include "usvmail.hpp"
class MailComponent;
class DynamicMail;
class DUser : public MVUser
f
public:
virtual void receive(MailComponent );
virtual void sendDynamicMailTo(DUser );
virtual char className(void) f return "DUser"; g
g;
class DMailHandler : public MailHandler, public Object
f
public:
virtual int send(MailComponent );
static DMailHandler Instance(void);
virtual char className(void) f return "DMailHandler"; g
protected:
DMailHandler() fg
virtual DMailHandler() fg
static DMailHandler instance;
g;
DMailHandler DMailHandler:: instance (DMailHandler )0;
(dmail.hpp)
class MailComponent :public Object f
public:
virtual void setMailOriginator(MailComponent ,Object ,DUser ) 0;
virtual DUser getMailOriginator(MailComponent ,Object ) 0;
virtual void setMailReceiver(MailComponent ,Object ,DUser ) 0;
virtual DUser getMailReceiver(MailComponent ,Object ) 0;
virtual void setMailContents(MailComponent ,Object ,char ) 0;
virtual char getMailContents(MailComponent ,Object ) 0;
virtual void send(MailComponent ,Object ) 0;
virtual void reply(MailComponent ,Object ) 0;
virtual void approve(MailComponent ,Object ) 0;

160 Appendix C. C ++ Implementation of Layering
g;
virtual int isApproved(MailComponent ,Object ) 0;
virtual void setDelivered(MailComponent ,Object ) 0;
virtual int isDelivered(MailComponent ,Object ) 0;
virtual void setRoute(MailComponent ,Object ,DMailHandler ) 0;
virtual DMailHandler getRoute(MailComponent ,Object ) 0;
virtual char className(void) f return "MailComponent"; g
virtual void historyReport(void) fg;
class DynamicMail : public MailComponent f
public:
DynamicMail();
virtual DynamicMail();
virtual void setMailOriginator(MailComponent ,Object ,DUser );
virtual DUser getMailOriginator(MailComponent ,Object );
virtual void setMailReceiver(MailComponent ,Object ,DUser );
virtual DUser getMailReceiver(MailComponent ,Object );
virtual void setMailContents(MailComponent ,Object ,char );
virtual char getMailContents(MailComponent ,Object );
virtual void send(MailComponent ,Object );
virtual void reply(MailComponent ,Object );
virtual void approve(MailComponent ,Object );
virtual int isApproved(MailComponent ,Object );
virtual void setDelivered(MailComponent ,Object );
virtual int isDelivered(MailComponent ,Object );
virtual void setRoute(MailComponent ,Object ,DMailHandler );
virtual DMailHandler getRoute(MailComponent ,Object );
virtual char className(void) f return "DynamicMail"; g
private:
Mail mail;
g;
class MailDecorator : public MailComponent f
public:
MailDecorator(MailComponent p) f component p; g
virtual void setMailOriginator(MailComponent svr,Object o,DUser u)
f
component!setMailOriginator((svr?svr:this),o,u);
g
virtual DUser getMailOriginator(MailComponent svr,Object o) f
return component!getMailOriginator((svr?svr:this),o);
g
virtual void setMailReceiver(MailComponent svr,Object o,DUser u) f
component!setMailReceiver((svr?svr:this),o,u);

C.5. Dynamic Mail System 161
f
g
virtual DUser getMailReceiver(MailComponent svr,Object o) f
return component!getMailReceiver((svr?svr:this),o);
g
virtual void setMailContents(MailComponent svr,Object o,char s) f
component!setMailContents((svr?svr:this),o,s);
g
virtual char getMailContents(MailComponent svr,Object o) f
return component!getMailContents((svr?svr:this),o);
g
virtual void send(MailComponent svr,Object o) f
component!send((svr?svr:this),o);
g
virtual void reply(MailComponent svr,Object o) f
component!reply((svr?svr:this),o);
g
virtual void approve(MailComponent svr,Object o) f
component!approve((svr?svr:this),o);
g
virtual int isApproved(MailComponent svr,Object o) f
return component!isApproved((svr?svr:this),o);
g
virtual void setDelivered(MailComponent svr,Object o) f
component!setDelivered((svr?svr:this),o);
g
virtual int isDelivered(MailComponent svr,Object o) f
return component!isDelivered((svr?svr:this),o);
g
virtual void setRoute(MailComponent svr,Object o,DMailHandler h)
component!setRoute((svr?svr:this),o,h);
g
virtual DMailHandler getRoute(MailComponent svr,Object o) f
return component!getRoute((svr?svr:this),o);
g
virtual void historyReport(void) f
component!historyReport();
g
virtual char className(void) f return "MailDecorator"; g
private:
MailComponent component;
g;
class MailReadNoti er : public MailDecorator f

162 Appendix C. C ++ Implementation of Layering
public:
MailReadNoti er(MailComponent d):MailDecorator(d) f noti ed 0; g
virtual char getMailContents(MailComponent ,Object );
virtual char className(void) f return "MailReadNotifier"; g
protected:
virtual int senderIsReceiverAndMustNotify(
MailComponent ,Object sender);
virtual void notify(MailComponent );
private:
int noti ed;
g;
class MailHistory : public MailDecorator f
public:
MailHistory(MailComponent d):MailDecorator(d) f initMeta(); g
virtual MailHistory() f closeMeta(); g
virtual void historyReport(void);
virtual void setMailOriginator(MailComponent ,Object ,DUser );
virtual DUser getMailOriginator(MailComponent ,Object );
virtual void setMailReceiver(MailComponent ,Object ,DUser );
virtual DUser getMailReceiver(MailComponent ,Object );
virtual void setMailContents(MailComponent ,Object ,char );
virtual char getMailContents(MailComponent ,Object );
virtual void send(MailComponent ,Object );
virtual void reply(MailComponent ,Object );
virtual void approve(MailComponent ,Object );
virtual int isApproved(MailComponent ,Object );
virtual void setDelivered(MailComponent ,Object );
virtual int isDelivered(MailComponent ,Object );
virtual void setRoute(MailComponent ,Object ,DMailHandler );
virtual DMailHandler getRoute(MailComponent ,Object );
virtual char className(void) f return "MailHistory"; g
private:
virtual void initMeta(void) f report NULL; g
virtual void closeMeta(void) f if (report) delete report; g
virtual void doMeta(char selector, Object sender);
char report;
g;
#endif
Implementation
(dmail.cc)

C.5. Dynamic Mail System 163
#include
#include
#include
#include
#include
#include "dmail.hpp"
#define MAX(A,B) (A

164 Appendix C. C ++ Implementation of Layering
g
instance!setName("The Only DMailHandler");
g
return (DMailHandler ) instance;
int
DMailHandler::send(MailComponent m)
f
if (m!getMailReceiver(0,this) 6= (DUser )0) f
m!approve(0,this);
g
if (m!isApproved(0,this)) f
m!setRoute(0,this,this);
m!setDelivered(0,this);
m!getMailReceiver(0,this)!receive(m);
return 0;
g else f
return -1;
g
g
DynamicMail::DynamicMail()
f
mail new Mail();
assert( mail 6= (Mail )0);
g
DynamicMail:: DynamicMail()
f
delete mail;
g
void
DynamicMail::setMailOriginator(MailComponent svr,
Object sender,
DUser u)
f
mail!setMailOriginator(u);
g
DUser
DynamicMail::getMailOriginator(MailComponent svr,Object sender)
f
return (DUser ) mail!getMailOriginator();

C.5. Dynamic Mail System 165
g
void
DynamicMail::setMailReceiver(MailComponent svr,
Object sender,
DUser u)
f
mail!setMailReceiver(u);
g
DUser
DynamicMail::getMailReceiver(MailComponent svr,Object sender)
f
return (DUser ) mail!getMailReceiver();
g
void
DynamicMail::setMailContents(MailComponent svr,Object sender,char s)
f
mail!setMailContents(s);
g
char
DynamicMail::getMailContents(MailComponent svr,Object sender)
f
return mail!getMailContents();
g
void
DynamicMail::send(MailComponent svr,Object sender)
f
DMailHandler::Instance()!send((svr?svr:this));
g
void
DynamicMail::reply(MailComponent svr,Object sender)
f
mail!reply();
g
void
DynamicMail::approve(MailComponent svr,Object sender)
f
mail!approve();

166 Appendix C. C ++ Implementation of Layering
g
int
DynamicMail::isApproved(MailComponent svr,Object sender)
f
return mail!isApproved();
g
void
DynamicMail::setDelivered(MailComponent svr,Object sender)
f
mail!setDelivered();
g
int
DynamicMail::isDelivered(MailComponent svr,Object sender)
f
return mail!isDelivered();
g
void
DynamicMail::setRoute(MailComponent svr,
Object sender,
DMailHandler mh)
f
mail!setRoute(mh);
g
DMailHandler
DynamicMail::getRoute(MailComponent svr,Object sender)
f
return (DMailHandler ) mail!getRoute();
g
char
MailReadNoti er::getMailContents(MailComponent svr,Object sender)
f
if (this!senderIsReceiverAndMustNotify(svr?svr:this,sender))
this!notify(svr?svr:this);
return MailDecorator::getMailContents(svr?svr:this,sender);
g
int
MailReadNoti er::

C.5. Dynamic Mail System 167
senderIsReceiverAndMustNotify(MailComponent svr,
Object sender)
f
return (this!getMailReceiver(svr,this) sender) && !noti ed;
g
void
MailReadNoti er::notify(MailComponent svr)
f
DynamicMail m new DynamicMail();
noti ed 1;
m!setMailOriginator(0,svr,svr!getMailReceiver(0,svr));
m!setMailReceiver(0,svr,svr!getMailOriginator(0,svr));
m!setMailContents(0,svr,"Read Notification");
m!send(0,svr);
g
void
MailHistory::historyReport(void)
f
if (report)
cout report;
else
cout "No report information";
g
void
MailHistory::doMeta(char selector,Object sender)
f
char s, ts, cs;
int size;
time tt;
if (!report)
report "";
size strlen(report);
t time(NULL);
ts ctime(&t);
ts[strlen(ts)-1] 0; = remove NL =
cs sender!asString();
size size = old info = +
strlen(ts) = time info = +

168 Appendix C. C ++ Implementation of Layering
g
1 = tab = +
MAX(strlen(cs),15) = for sender name = +
1 = tab = +
strlen(selector) +
2 = NL + n0 = ;
s (char )malloc(sizeof(char) size);
sprintf(s,"%s%s %-15s %snn",report,ts,cs,selector);
if (report[0] 6= 0)
delete report;
report s;
void
MailHistory::setMailOriginator(MailComponent svr,
Object sender,
DUser user)
f
this!doMeta("setMailOriginator",sender);
MailDecorator::setMailOriginator(svr,sender,user);
g
DUser
MailHistory::getMailOriginator(MailComponent svr,Object sender)
f
this!doMeta("getMailOriginator",sender);
return MailDecorator::getMailOriginator(svr,sender);
g
void
MailHistory::setMailReceiver(MailComponent svr,
Object sender,
DUser user)
f
this!doMeta("setMailReceiver",sender);
MailDecorator::setMailReceiver(svr,sender,user);
g
DUser
MailHistory::getMailReceiver(MailComponent svr,Object sender)
f
this!doMeta("getMailReceiver",sender);
return MailDecorator::getMailReceiver(svr,sender);
g

C.5. Dynamic Mail System 169
void
MailHistory::setMailContents(MailComponent svr,Object sender,char s)
f
this!doMeta("setMailContents",sender);
MailDecorator::setMailContents(svr,sender,s);
g
char
MailHistory::getMailContents(MailComponent svr,Object sender)
f
this!doMeta("getMailContents",sender);
return MailDecorator::getMailContents(svr,sender);
g
void
MailHistory::send(MailComponent svr,Object sender)
f
this!doMeta("send",sender);
MailDecorator::send(svr,sender);
g
void
MailHistory::reply(MailComponent svr,Object sender)
f
this!doMeta("reply",sender);
MailDecorator::reply(svr,sender);
g
void
MailHistory::approve(MailComponent svr,Object sender)
f
this!doMeta("approve",sender);
MailDecorator::approve(svr,sender);
g
int
MailHistory::isApproved(MailComponent svr,Object sender)
f
this!doMeta("isApproved",sender);
return MailDecorator::isApproved(svr,sender);
g
void

170 Appendix C. C ++ Implementation of Layering
MailHistory::setDelivered(MailComponent svr,Object sender)
f
this!doMeta("setDelivered",sender);
MailDecorator::setDelivered(svr,sender);
g
int
MailHistory::isDelivered(MailComponent svr,Object sender)
f
this!doMeta("isDelivered",sender);
return MailDecorator::isDelivered(svr,sender);
g
void
MailHistory::setRoute(MailComponent svr,Object sender,DMailHandler h)
f
this!doMeta("setRoute",sender);
MailDecorator::setRoute(svr,sender,h);
g
DMailHandler
MailHistory::getRoute(MailComponent svr,Object sender)
f
this!doMeta("getRoute",sender);
return MailDecorator::getRoute(svr,sender);
g
#define CALL TEST FUNCTION test dynamic mail();
void test dynamic mail(void)
f
cout "Dynamic Mail testnn";
DUser u1 new DUser();
u1!setName("MailOriginator");
DUser u2 new DUser();
u2!setName("MailReceiver");
u1!sendDynamicMailTo(u2);
g
#include "main.inc"
#include "usvmail.cc"

Appendix D
Sina Implementation of Layering
D.1 Heading Mail System
class HUser interface
internals
user : User;
methods
receive(aMail : Mail) returns nil;
sendHeadingMailTo(aUser : User) returns nil;
input lters
disp : Dispatch =f inner. , user. g;
end;
class HUser implementation
methods
receive(aMail : Mail)
begin
server.printLine(aMail.getMailAsText);
end;
sendHeadingMailTo(aUser : User)
temps
aMailMessage : HeadingMail;
begin
aMailMessage.setMailOriginator(server);
aMailMessage.setMailReceiver(aUser);
aMailMessage.setMailContents(
'Contents of a Heading mail message');
aMailMessage.send;
end;
end;
#NoDefSyncFilter;
(HUser.sina)
(HeadingMail.sina)
171

172 Appendix D. Sina Implementation of Layering
class HeadingMail interface
internals
mail : Mail;
methods
getMailHeading returns String;
getMailAsText returns String;
input lters
disp : Dispatch =f inner. , mail. g;
end;
class HeadingMail implementation
methods
getMailHeading
begin
return 'Sender:
'.copyAppend:(server.getMailOriginator.getName
).copyAppend:('
Receiver: '
).copyAppend:(server.getMailReceiver.getName
).copyAppend:('
Route: '
).copyAppend:(server.getRoute.getName);
end;
getMailAsText
begin
return server.getMailHeading.copyAppend:('
').copyAppend:(server.getMailContents);
end;
end;
main
temps
u1 : HUser;
u2 : HUser;
begin
u1.setName('MailOriginator');
u2.setName('MailReceiver');
u1.sendHeadingMailTo(u2);
end
D.2 Attachment Mail System
(HeadingMailMain.sina)
(Attachment.sina)

D.2. Attachment Mail System 173
class Attachment interface
methods
setFilename(aName : String) returns nil;
getFilename returns String;
input lters
disp : Dispatch =f inner. g;
end;
class Attachment implementation
instvars
lename : String;
initial
begin
lename 'NoName';
end;
methods
setFilename(aName : String)
begin
lename aName;
end;
getFilename
begin
return lename;
end;
end;
class AUser interface
internals
user : HUser;
methods
sendAttachmentMailTo(aUser : User) returns nil;
input lters
disp : Dispatch =f inner. , user. g;
end;
class AUser implementation
methods
sendAttachmentMailTo(aUser : User)
temps
aMailMessage : AttachmentMail;
attachment :Attachment;
begin
attachment.setFilename(' /attachment.doc');
(AUser.sina)

174 Appendix D. Sina Implementation of Layering
aMailMessage.setMailOriginator(server);
aMailMessage.setMailReceiver(aUser);
aMailMessage.setMailContents(
'Contents of an attachment mail message');
aMailMessage.setMailAttachment(attachment);
aMailMessage.send;
end;
end;
(AttachmentMail.sina)
class AttachmentMail interface
internals
mail : HeadingMail;
conditions
noAttachment;
methods
setMailAttachment(anAttachment :Attachment) returns nil;
getMailAttachment returns Attachment;
getMailHeading returns String;
input lters
skip : Dispatch =f
noAttachment)[getMailHeading]mail.getMailHeading g;
disp : Dispatch =f inner. , mail. g;
end;
class AttachmentMail implementation
instvars
attachment :Attachment;
conditions
noAttachment
begin
return attachment =nil;
end;
initial
begin
attachment nil;
end;
methods
setMailAttachment(anAttachment :Attachment)
begin
attachment anAttachment;
end;
getMailAttachment
begin

D.3. ReadNoti cation Mail System 175
return attachment;
end;
getMailHeading
begin
return mail.getMailHeading.copyAppend:('
Attachment: ').copyAppend:(server.getMailAttachment.getFilename);
end;
end;
main
temps
u1 : AUser;
u2 : AUser;
begin
u1.setName('MailOriginator');
u2.setName('MailReceiver');
u1.sendAttachmentMailTo(u2);
end
D.3 ReadNoti cation Mail System
class RNUser interface
internals
user : AUser;
methods
sendReadNoti cationMailTo(aUser : User) returns nil;
input lters
disp : Dispatch =f inner. , user. g;
end;
(AttachmentMailMain.sina)
(RNUser.sina)
class RNUser implementation
methods
sendReadNoti cationMailTo(aUser : User)
temps
aMailMessage : ReadNoti cationMail;
begin
aMailMessage.setMailOriginator(server);
aMailMessage.setMailReceiver(aUser);
aMailMessage.setMailContents(
'Contents of a read notification mail message');
aMailMessage.setNotify(true);
aMailMessage.send;

176 Appendix D. Sina Implementation of Layering
end;
end;
class Noti er interface
conditions
done;
methods
setNotify(aBool : Boolean) returns nil;
notify(aMessage : SinaMessage) returns nil;
skipNotify(aMessage : SinaMessage) returns nil;
input lters
disp : Dispatch =f done)[notify]inner.skipNotify, inner. g;
end;
class Noti er implementation
instvars
mustNotify : Boolean;
noti ed : Boolean;
conditions
done
begin
return (noti ed jj mustNotify.not);
end;
initial
begin
mustNotify false;
noti ed false;
end;
methods
skipNotify(aMessage : SinaMessage)
begin
aMessage.continue;
end;
setNotify(aBool : Boolean)
begin
mustNotify aBool;
end;
notify(aMessage : SinaMessage)
temps
aMailMessage : ReadNoti cationMail;
begin
noti ed true;
aMessage.continue;
(Noti er.sina)

D.3. ReadNoti cation Mail System 177
aMailMessage.setMailOriginator(
aMessage.receiver.getMailReceiver);
aMailMessage.setMailReceiver(
aMessage.receiver.getMailOriginator);
aMailMessage.setMailContents('Read Notification');
aMailMessage.setNotify(false);
aMailMessage.send;
end;
end;
(ReadNoti cationMail.sina)
#NoDefSyncFilter;
class ReadNoti cationMail interface
internals
mail : AttachmentMail;
noti er : Noti er;
conditions
senderIsReceiver;
input lters
meta : Meta = f senderIsReceiver)[getMailContents]noti er.notify g;
disp : Dispatch =f inner. , noti er.setNotify, mail. g;
end;
class ReadNoti cationMail implementation
conditions
senderIsReceiver
begin
return true; == mail.getMailReceiver = message.sender;
== Compiler bug prevents correct evaluation of above
end;
end;
main
temps
u1 : RNUser;
u2 : RNUser;
begin
u1.setName('MailOriginator');
u2.setName('MailReceiver');
u1.sendReadNoti cationMailTo(u2);
end
(ReadNoti cationMailMain.sina)

178 Appendix D. Sina Implementation of Layering
D.4 History Mail System
class HisUser interface
internals
user : RNUser;
methods
sendHistoryMailTo(aUser : User) returns nil;
input lters
disp : Dispatch =f inner. , user. g;
end;
class HisUser implementation
methods
sendHistoryMailTo(aUser : User)
temps
aMailMessage : HistoryMail;
begin
aMailMessage.setMailOriginator(server);
aMailMessage.setMailReceiver(aUser);
aMailMessage.setMailContents(
'Contents of a history mail message');
aMailMessage.send;
aMailMessage.historyReport;
end;
end;
class HistoryReporter interface
externals
Time : Class;
methods
saveHistory(aMessage : SinaMessage) returns nil;
historyReport returns nil;
input lters
disp : Dispatch =f inner. g;
end;
class HistoryReporter implementation
instvars
report : String;
initial
begin
report nil;
end;
(HisUser.sina)
(HistoryReporter.sina)

D.4. History Mail System 179
methods
saveHistory(aMessage : SinaMessage)
begin
if report = nil
then
report '';
end;
report report.copyAppend:(Time.dateAndTimeNow.printString
).copyAppend:(' '
).copyAppend:(aMessage.sender.toString
).copyAppend:(' '
).copyAppend:(aMessage.selector).copyAppend:('
');
aMessage.continue;
end;
historyReport
begin
if report = nil
then
server.print('No report information');
else
server.print(report);
end;
end;
end;
class HistoryMail interface
internals
mail : ReadNoti cationMail;
history : HistoryReporter;
input lters
meta : Meta = f [ ]history.saveHistory g;
disp : Dispatch =f history.historyReport, mail. g;
end;
class HistoryMail implementation
end;
main
temps
u1 : HisUser;
u2 : HisUser;
begin
(HistoryMail.sina)
(HistoryMailMain.sina)

180 Appendix D. Sina Implementation of Layering
end
u1.setName('MailOriginator');
u2.setName('MailReceiver');
u1.sendHistoryMailTo(u2);
D.5 Dynamic Mail System
class DUser interface
internals
user : User;
methods
sendDynamicMailTo(aUser : User) returns nil;
input lters
disp : Dispatch =f inner. , user. g;
end;
class DUser implementation
methods
sendDynamicMailTo(aUser : User)
temps
aMailMessage : DynamicMail;
aHistory : HistoryProperty;
aReadNot : MailReadNoti er;
begin
aMailMessage.addML(aReadNot);
aMailMessage.addML(aHistory);
aMailMessage.setMailOriginator(server);
aMailMessage.setMailReceiver(aUser);
aMailMessage.setMailContents(
'Contents of a Dynamic Mail Message');
aMailMessage.send;
aMailMessage.historyReport;
end;
end;
class BasicDL interface
comment
'This class provides the basic protocol for dynamic
layering';
internals
ol : SinaObject; == For Object level layering
ml : SinaObject; == For Meta level layering
(DUser.sina)
(BasicDL.sina)

D.5. Dynamic Mail System 181
conditions
isCascaded; == OL is lled
isMeta; == ML is lled
methods
addOL(object : BasicDL) returns nil;
addML(object : BasicDL) returns nil;
process(aMessage : SinaMessage) returns nil;
input lters
== addML and addOL must be used in the top-level
== because adding an object layer disables inner.
d : Dispatch =f isMeta)[process]ml.process,
true)f inner.addML, inner.addOL g,
isCascaded)ol. ,
isMeta)ml. ,
true)inner.process g;
end;
class BasicDL implementation
instvars
cascaded : Boolean;
meta : Boolean;
conditions
isCascaded
begin
return cascaded;
end;
isMeta
begin
return meta;
end;
initial
begin
cascaded false;
meta false;
end;
methods
addOL(object : BasicDL)
begin
if cascaded
then
object.addOL(ol);
end;
ol object;
cascaded true;

182 Appendix D. Sina Implementation of Layering
end;
addML(object : BasicDL)
begin
if meta
then
object.addOL(mop);
end;
ml object;
meta true;
end;
process(aMessage : SinaMessage)
begin
aMessage.continue;
end;
end;
class DynamicMail interface
internals
layers : BasicDL;
mail : Mail;
input lters
meta : Meta = f [ ]layers.process g;
dis : Dispatch =f layers. , mail. g;
end;
class DynamicMail implementation
end;
(DynamicMail.sina)
(MailReadNoti er.sina)
class MailReadNoti er interface
internals
basics : BasicDL;
conditions
notYetNoti ed;
methods
process (aMessage : SinaMessage) returns nil;
input lters
disp : Dispatch =f notYetNoti ed)inner. , true)basics. g;
end;
class MailReadNoti er implementation
instvars
noti ed : Boolean;

D.5. Dynamic Mail System 183
conditions
notYetNoti ed
begin
return !noti ed;
end;
initial
begin
noti ed false;
end;
methods
process
temps
aMailMessage : DynamicMail;
begin
if aMessage.sender = aMessage.server.getMailReceiver
&& aMessage.selector = 'getMailContents'
then
noti ed true;
aMailMessage.setMailOriginator(
aMessage.receiver.getMailReceiver);
aMailMessage.setMailReceiver(
aMessage.receiver.getMailOriginator);
aMailMessage.setMailContents('Read Notification');
aMailMessage.send;
end
basics.process(aMessage);
end;
end;
(HistoryProperty.sina)
class HistoryProperty interface
internals
basics : BasicDL;
oldReporter : HistoryReporter;
methods
process(aMessage : SinaMessage) returns nil;
input lters
disp : Dispatch =f inner. , oldReporter.historyReport, basics. g;
end;
class HistoryProperty implementation
instvars
methods
process(aMessage : SinaMessage)

184 Appendix D. Sina Implementation of Layering
begin
oldReporter.saveHistory(aMessage);
basics.process(aMessage);
end;
end;
main
temps
u1 : DUser;
u2 : DUser;
begin
u1.setName('MailOriginator');
u2.setName('MailReceiver');
u1.sendDynamicMailTo(u2);
end
(DynamicMailMain.sina)

Bibliography
Aksit, M. and Bergmans, L.: 1992, Obstacles in object-oriented software development,
in Paepcke (1992), pp. 341{358. ISSN 0362-1340, ISBN 0-201-
53372-3.
Aksit, M., Bergmans, L. and Vural, S.: 1992, An object-oriented languagedatabase
integration model: The composition- lters approach, in Madsen
(1992), pp. 372{395. ISBN 0-387-55668-0 / ISBN 3-540-55668-0.
Aksit, M. and Bosch, J.: 1994, Issues in Object-Oriented Real-Time Language
Design, in Halang and Stoyenko (1994), pp. 510{511. ISBN 3-540-57558-8,
ISBN 0-387-57558-8, Proceedings of the NATO Advanced Study Institute
on Real Time Computing, held in Sint Maarten, Dutch Antilles, October
5{17, 1992.
Aksit, M., Bosch, J., van der Sterren, W. and Bergmans, L.: 1994, Real-time
speci cation inheritance anomalies and real-time lters, in Tokoro and
Pareschi (1994), pp. 386{407. ISBN 0-387-58202-9 / ISBN 3-540-58202-9.
Aksit, M., Wakita, K., Bosch, J., Bergmans, L. and Yonezawa, A.: 1993, Abstracting
object interactions using composition lters, in Guerraoui, Nierstrasz
and Riveill (1993), pp. 152{184. ISBN 0-387-57932-X / ISBN 3-540-
57932-X.
Alexander, C.: 1977, A Pattern Language, Oxford University Press.
Algra, E.: 1994, Process programming and learning domains in object oriented
hermeneutic software development, M.Sc. thesis, University of Twente,
Dept. of Computer Science, P.O. box 217, 7500 AE, Enschede, The Netherlands.
Describes a framework and its specialisation for the HOOSD tool.
Bergmans, L.: 1994, Composing Concurrent Objects, Ph.D. dissertation, University
of Twente, Dept. of Computer Science, P.O. box 217, 7500 AE,
Enschede, The Netherlands. ISBN 90-9007359-0.
Black, U. D.: 1991, OSI: a Model for Computer Communications Standards,
Prentice Hall. ISBN 0-13-637133-7.
Bosch, J.: 1995, Language support for design patterns.
*http://www.pt.hk-r.se/~bosch/despat.ps.Z
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P. and Stal, M.: 1996,
Pattern-Oriented Software Architecture | A System of Patterns, John
Wiley & Sons Ltd., Ba ns Lane, Chichester, West Sussex PO19 1UD,
England. ISBN 0-471-95869-7.
185

186 Bibliography
Ellis, M. A. and Stroustrup, B.: 1990, The Annotated C++ Reference Manual,
Addison-Wesley Publishing Company, Reading, Massachusetts. ISBN 0-
201-51459-1.
Eur: 1997, Proceedings of the ECOOP '97, number 1241 in Lecture Notes in
Computer Science, Springer-Verlag, Berlin Heidelberg.
Ferber, J.: 1989, Computational re ection in class based object oriented languages,
in Meyrowitz (1989), pp. 317{326. ISBN 0-0201-52249-7, ISSN
0362-1340.
Florijn, G., Meijers, M. and van Winsen, P.: 1997, Tool support for object
oriented patterns, in Proceedings of the ECOOP '97 (Eur 1997), pp. 472{
495.
Gamma, E., Helm, R., Johnson, R. and Vlissides, J.: 1995, Design Patterns:
Elements of Reusable Object-Oriented Software, Professional computing
series, Addison-Wesley, Reading, MA. ISBN 0-201-63361-2.
Glandrup, M.: 1995, Extending c++ using the concepts of composition lters,
M.Sc. thesis, University ofTwente, Dept. of Computer Science, P.O. box
217, 7500 AE, Enschede, The Netherlands.
Guerraoui, R., Nierstrasz, O. and Riveill, M. (eds): 1993, ECOOP '93, Workshop
on Object-Based Distributed Programming, number 791 in Lecture
Notes in Computer Science, European Conference on Object-Oriented
Programming, Springer-Verlag, Berlin Heidelberg. ISBN 0-387-57932-X
/ ISBN 3-540-57932-X.
Halang, W. A. and Stoyenko, A. D. (eds): 1994, Real Time Computing, Vol. 127
of NATO ASI Series F: Computer and System Sciences, NATO Advanced
Science Institutes, Springer-Verlag, Berlin, Heidelberg, New York. ISBN
3-540-57558-8, ISBN 0-387-57558-8, Proceedings of the NATO Advanced
Study Institute on Real Time Computing, held in Sint Maarten, Dutch
Antilles, October 5{17, 1992.
Helm, R., Holland, I. M. and Gangopadhyay, D.: 1990, Contracts: Specifying
behavioural compositions in object-oriented systems, Proceedings OOP-
SLA/ECOOP '90, ACM SIGPLAN Notices, pp. 169{180. Published as
Proceedings OOPSLA/ECOOP '90, ACM SIGPLAN Notices, volume 25,
number 10.
Johnson, R. E. and Foote, B.: 1988, Designing reusable classes, Journal of
Object-Oriented Programming pp. 22{35.
Koehorst, H.: 1994, De ning artifacts of prepatory work in hermeneutic objectoriented
software development, M.Sc. thesis, University of Twente, Dept.
of Computer Science, P.O. box 217, 7500 AE, Enschede, The Netherlands.
Describes an aspect of the HOOSD tool.
Koopmans, P.: 1996, Sina/st | User's Guide and Reference Manual for Sina
version 3.1, University of Twente, Dept. of Computer Science, P.O. box
217, 7500 AE, Enschede, The Netherlands.
Lieberherr, K. J. and Holland, I. M.: 1989, Assuring good style for objectoriented
programs, IEEE Software pp. 38{48.

Bibliography 187
Lieberman, H.: 1986, Using prototypical objects to implement shared behavior
in object oriented systems, in Meyrowitz (1986), pp. 214{223. ISBN 0-
89791-204-7.
Madsen, O. L. (ed.): 1992, ECOOP '92, European Conference on Object-
Oriented Programming, number 615 in Lecture Notes in Computer Science,
European Conference on Object-Oriented Programming, Springer-Verlag,
Berlin Heidelberg. ISBN 0-387-55668-0 / ISBN 3-540-55668-0.
Meyrowitz, N. (ed.): 1986, OOPSLA '86 Conference Proceedings, Vol. 21 of
SIGPLAN Notices, Association for Computing Machinery's Special Interest
Group on Programming Languages (ACM/SIGPLAN), Association for
Computing Machinery, Inc., 11 West 42nd Street, New York, New York
10036, USA. ISBN 0-89791-204-7.
Meyrowitz, N. (ed.): 1989, OOPSLA '89, Conference Proceedings, Vol. 24 of
SIGPLAN Notices, Special Interest Group on Programming Languages,
Association for Computing Machinery, Association for Computing Machinery,
Inc., 11 West 42nd Street, New York, NY 10036, USA. ISBN
0-0201-52249-7, ISSN 0362-1340.
Minsky, N.H.andPal, P.: 1995, Providing multiple views for objects by means
of surrogates, Technical report, Rutgers University, New Brunswick, NJ
08903 USA.
*http://www.cs.rutgers.edu/~minsky/papers/surrogates-paper.ps
Mordhorst, J. and van Dijk, W.: 1996, Composition lters in smalltalk, M.Sc.
thesis, University of Twente, Dept. of Computer Science, P.O. box 217,
7500 AE, Enschede, The Netherlands.
Paepcke, A. (ed.): 1992, OOPSLA '92, Conference Proceedings, Vol. 27 of ACM
SIGPLAN Notices, Association for Computing Machinery's Special Interest
Group on Programming Languages (ACM/SIGPLAN), Association for
Computing Machinery, Inc., 151 Broadway, New York, NY 10036. ISSN
0362-1340, ISBN 0-201-53372-3.
Pree, W.: 1994, Design Patterns for Object-Oriented Software Development,
ACM Press Books, Addison-Wesley, Reading, MA. ISBN 0-201-42294-8.
Schmidt, R. W.: n.d., Dynamically extensible objects in a class-based language.
Stuurman, C.: 1996, Techniques for de ning composition lters using message
manipulators, M.Sc. thesis, University ofTwente, Dept. of Computer Science,
P.O. box 217, 7500 AE, Enschede, The Netherlands.
Tekinerdogan, B.: 1994, The design of an object-oriented framework for atomic
transactions, M.Sc. thesis, University of Twente, Dept. of Computer Science,
P.O. box 217, 7500 AE, Enschede, The Netherlands.
Tokoro, M. and Pareschi, R. (eds): 1994, ECOOP '94, Object-Oriented Programming,
number 821 in Lecture Notes in Computer Science, European
Conference on Object-Oriented Programming, Springer-Verlag, Berlin Heidelberg.
ISBN 0-387-58202-9 / ISBN 3-540-58202-9.

188 Bibliography
Vuijst, C.: 1994, Design of an object oriented framework for image algebra,
M.Sc. thesis, University ofTwente, Dept. of Computer Science, P.O. box
217, 7500 AE, Enschede, The Netherlands.
Wieringa, R. and Jonge, W. d.: 1991a, The identi cation of objects and
roles, Technical Report IR-267, Faculty of Mathematics and Computer
Science, Vrije Universiteit, Amsterdam. Available for ftp in le 91-
ObjectsRoles.ps.Z.
Wieringa, R. and Jonge, W. d.: 1991b, The identi cation of objects and roles
{ object identi ers revisited, Technical Report IR-267, Faculty of Mathematics
and Computer Science, Vrije Universiteit, Amsterdam. Abbreviated
and revised version of 91-ObjectsRoles.ps.Z. Available for ftp in le
92-ObjectsRoles.ps.Z..