![List of Figures
1.1 MDA pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Model transformation pattern . . . . . . . . . . . . . . . . . . . 5
1.3 MDA practise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Alternative MDA practise . . . . . . . . . . . . . . . . . . . . . 6
1.5 MDA improved . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Integrating platform dependencies . . . . . . . . . . . . . . . . . 8
1.7 Example platform dependency . . . . . . . . . . . . . . . . . . . 10
1.8 Platform model overview . . . . . . . . . . . . . . . . . . . . . . 11
1.9 (a) Software product line configurator and (b) MDA configurator 12
1.10 Software product line generator transformation . . . . . . . . . 13
1.11 Dissertation structure overview . . . . . . . . . . . . . . . . . . 16
2.1 Impact of MDA on the development process (source: [KWB03]). 21
2.2 A screenshot of an instant messaging client running on a PC. . . 23
2.3 A UML Class diagram of the instant messaging client CIM. . . . 24
2.4 A UML Class diagram showing part of the instant messaging
client PIM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5 A UML Class diagram showing part of the instant messaging
client PSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6 The 4-level OMG meta-modelling framework. . . . . . . . . . . 27
2.7 EMOF meta-model part for MOF Classes (source: [OMG06b]). . 28
2.8 Root diagram of the UML Kernel package (source: [OMG05c]). . 29
2.9 A simplified subset of the Ecore meta-model (source: [BSM+
03]). 30
2.10 A screenshot of the Ecore editor. . . . . . . . . . . . . . . . . . 31
2.11 Applet Stereotype applied to a UML Class. . . . . . . . . . . . . 32
2.12 UML meta-model part for Profiles (source: [OMG05c]). . . . . . 32
2.13 The Applet Profile. . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.14 Eclipse UML2 and Ecore share the common notion of EAnno-
tations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
xvii](https://image.slidesharecdn.com/25688255-250514070919-9f7a9fa4/85/Platform-Ontologies-For-The-Modeldriven-Architecture-1st-Edition-Dennis-Wagelaar-23-320.jpg)
![xviii LIST OF FIGURES
2.15 A screenshot of the Eclipse UML2 editor after the Applet profile
was “defined”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.16 Object diagram of the Applet stereotype applied to the Instant-
MessagingClient class. . . . . . . . . . . . . . . . . . . . . . . . 35
2.17 Relationships between QVT meta-models (source: [OMG05a]). . 36
2.18 ATL superimposition example. . . . . . . . . . . . . . . . . . . . 43
3.1 An example classification of wine-related concepts in OWL. . . . 51
3.2 Some example OWL individuals in the wine domain. . . . . . . 51
3.3 An example OWL property in the wine domain. . . . . . . . . . 53
3.4 An example of an OWL subproperty and a transitive property. . 54
3.5 Example of symmetric, functional and inverse properties. . . . . 54
3.6 Example of “allValuesFrom” and “someValuesFrom” property
restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.7 Example of a “hasValue” property restriction. . . . . . . . . . . 57
3.8 Example of equivalence. . . . . . . . . . . . . . . . . . . . . . . 57
3.9 Example of identity. . . . . . . . . . . . . . . . . . . . . . . . . 58
3.10 Example of “intersectionOf”. . . . . . . . . . . . . . . . . . . . 59
3.11 Example of “unionOf”. . . . . . . . . . . . . . . . . . . . . . . . 59
4.1 Partial view of the base platform ontology . . . . . . . . . . . . 64
4.2 Partial view of an ontology for describing Java runtime environ-
ments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3 Partial view of an ontology for describing the J2ME Personal
Profile 1.0 specification . . . . . . . . . . . . . . . . . . . . . . . 69
4.4 Partial platform description for the Sharp Zaurus SL-C1000 PDA 71
5.1 A UML Class diagram showing part of the instant messenger
model for the Jabber feature. . . . . . . . . . . . . . . . . . . . 85
5.2 The feature model of the instant messenger product line. . . . . 86
5.3 The feature model of the instant messenger product line. . . . . 87
5.4 The meta-model of the instant messenger configuration language. 91
5.5 An example instant messenger configuration model as displayed
by the EMF model editor. . . . . . . . . . . . . . . . . . . . . . 92
6.1 The extended feature model of the instant messenger product
line. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.2 The feature model of the TransformationConfig feature. . . . . . 103
6.3 The meta-model of the instant messenger configuration language.104
6.4 The meta-model for PlatformKit models. . . . . . . . . . . . . . 107
6.5 Flowchart of the platform profiling scenario . . . . . . . . . . . 108
6.6 The PlatformKit model for the instant messenger configuration
language. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.7 Flowchart of the deployment scenario . . . . . . . . . . . . . . . 110](https://image.slidesharecdn.com/25688255-250514070919-9f7a9fa4/85/Platform-Ontologies-For-The-Modeldriven-Architecture-1st-Edition-Dennis-Wagelaar-24-320.jpg)
![2 Chapter 1. Introduction
platform differences (“Write Once, Run Anywhere”), we find that multiple
Java versions exist today. Each of these Java versions are tailored towards
specific usage scenarios and computing devices. To name a few: J2SE is the
standard edition that is meant for desktop and laptop computers, J2EE is the
enterprise edition that is meant for running server-side applications and J2ME
is the mobile edition that is meant for resource-constrained and mobile devices.
J2ME in turn is split up in separate versions for mobile phones, called Mobile
Information Device Profile (MIDP)1
, and for PDAs, called Personal Profile
(PP)2
.
The main difference between these Java versions lies in the libraries that
make up the application programming interface (API). The API of J2ME
MIDP for mobile phones is typically a stripped down version of the standard
J2SE API. Functionality that is resource intensive and functionality that is not
provided by the underlying platform is taken out of the API. New API elements
are also added to J2ME MIDP to support functionality that is only relevant
for mobile devices. Java reflection and the TCP/IP networking layer, for ex-
ample, have been stripped from J2ME MIDP; Java reflection is too resource
intensive and the TCP/IP networking layer is not (completely) available in the
underlying operating system. In return, a special J2ME networking layer that
can deal with limited TCP/IP networking has been added.
In addition to this, platform technologies tend to evolve. This evolution
may involve just extending the API, but it can also involve an update of the
programming language itself. In the case of Java, the language specification
has been extended in J2SE 1.4 with assertions [GJJB00] and in J2SE 5 with
generics and annotations [GJJB05]. When developing software for an evolving
platform, software developers have to take into account that the users may use
older versions of the platform. Developers may be confronted with the fact that
their software is no longer compatible with an older version of the platform,
because they do all their development and testing on the latest version of the
platform.
If the current range of platforms can already be considered diverse, the
vision of Ambient Intelligence, put forward by the Information Society Tech-
nologies Advisory Group (ISTAG) [DBS+
01], only amplifies this diversity. Am-
bient Intelligence, or AmI , aims for a user-driven, service-based computing en-
vironment that includes personal devices as well as special-purpose embedded
devices in the environment. The hardware and software combinations in such
devices can vary widely3
. It is also in such personal devices that another limi-
tation of Java becomes apparent: the scope of Java as a platform abstraction
layer is no longer complete. Deployment methods not only vary between dif-
1
http://java.sun.com/products/midp/
2
http://java.sun.com/products/personalprofile/
3
http://www.comp.nus.edu.sg/∼damithch/df/device-fragmentation.htm](https://image.slidesharecdn.com/25688255-250514070919-9f7a9fa4/85/Platform-Ontologies-For-The-Modeldriven-Architecture-1st-Edition-Dennis-Wagelaar-30-320.jpg)
![1.1 Problem Statement 3
ferent PDAs and mobile phones, but also between different network operators
for the same mobile phone.
We have discussed how the Java technology often falls short in solving the
platform diversity problem. Java is an example of a platform abstraction layer
based on a virtual machine, where the software that runs on top of Java doesn’t
know about the details of the underlying platform. Other kinds of platform
abstraction layers are script interpreters, standard libraries and frameworks.
Regardless of the kind of abstraction layer, an abstraction layer solution to
platform diversity will always be limited in the way that we have described
for the Java technology. The causes of these limitations can be summarised as
follows:
• Unreconcilable differences in underlying platform.
• Evolution of the platform abstraction layer.
• Scope of the platform abstraction layer.
In contrast to platform abstraction layers, which form an adapter between
the software and the underlying platform, are solutions that adapt the soft-
ware itself to the target platform. These solutions range from generative ap-
proaches that transform the software beforehand to reflective approaches that
will react to platform differences at run-time. Each of these approaches have
strengths and weaknesses. Generative approaches typically can’t deal with
post-deployment changes in the platform. Reflective approaches inevitably
have some overhead in doing run-time platform checks and providing code
that may never be executed on the target platform. In this dissertation, we
will focus on a generative approach. We will discuss in chapter 8 how our
thesis relates to reflective approaches.
The Object Management Group has acknowledged the problem of platform
diversity by introducing the Model Driven Architecture (MDA). The MDA
allows for “separating the specification of the operation of a system from the
details of the way that system uses the capabilities of its platform.” [MM03]
and is centred around the use of software models. The software models provide
a means to create partial, platform-independent software specifications that
make use of platform abstractions. These abstractions are refined to platform-
specific specifications in a later stage of the development lifecycle. The next
subsection discusses the MDA in more detail.
1.1.1 Model Driven Architecture
The Model Driven Architecture is based on a pattern in which a Platform
Independent Model (PIM) is transformed to a Platform Specific Model (PSM)
(see also Fig. 1.1). The software is initially modelled in a PIM, which only](https://image.slidesharecdn.com/25688255-250514070919-9f7a9fa4/85/Platform-Ontologies-For-The-Modeldriven-Architecture-1st-Edition-Dennis-Wagelaar-31-320.jpg)
![1.1 Problem Statement 5
Model
Transformation
Input Model
Input Meta-Model
Output Model
Output Meta-Model
conforms to conforms to
Figure 1.2: Model transformation pattern
of targeting a single, assumed platform. It is unclear, however, whether a model
transformation can be used for other platforms than the one for which it was
written. The only safe assumption is that each targeted platform requires its
own dedicated set of model transformations.
PIM ?
PSM1
Transformation1
Transformation2
Transformation3
PSM2
PSM3
Figure 1.3: MDA practise
Another approach to MDA that applied often is shown in Fig. 1.4. In this
approach, the PIM is absent and one PSM serves as the input for transforma-
tions that generate other PSMs. This PSM-to-PSM approach occurs mostly
in situations where one has to translate from one language/technology to an-
other, such as translating from Rational Rose to UML2 Tools and from UML
to OWL6
, but also to translate from one Java API to another [CDZ04].
In reality, this means that only a relatively small number of “general”
platforms can be targeted, such as Java. As has been explained before, Java
is actually a family of platforms, ranging from J2ME to J2EE. On top of this
generalisation, specific platform assumptions are often made. In the case of the
6
http://www.eclipse.org/m2m/atl/usecases/](https://image.slidesharecdn.com/25688255-250514070919-9f7a9fa4/85/Platform-Ontologies-For-The-Modeldriven-Architecture-1st-Edition-Dennis-Wagelaar-33-320.jpg)
![6 Chapter 1. Introduction
PSM1
Transformation2
Transformation3
PSM2
PSM3
Figure 1.4: Alternative MDA practise
Java platform family, there is not enough commonality between the different
Java versions to come up with a complete platform to build on. For example,
the API for graphical user interfaces (GUIs) is radically different on the mobile
phone J2ME MIDP than it is on the standard J2SE; there is no common
Java API for GUIs. For the purpose of targeting a “complete” platform, an
assumption for a specific GUI library is made, thereby reducing the number
of supported Java platforms. This way of “streamlining” the PIM-to-PSM
transformations to a single, assumed Java platform is used a lot to escape the
problem of maintaining model transformations for multiple platforms.
When we look at the nature of PIM-to-PSM transformations directly, it
becomes clear that the single Java platform approach is a very bad solution
indeed. Most of these transformations consist of several smaller refinement
steps that, when considered individually, are reusable over multiple platforms.
It is only the combination of refinement steps that limits their applicability to
one specific platform. For example, one refinement step could target all Java
2 platforms by transforming the types of UML Properties [OMG05c] with a
multiplicity greater than one to the Java 2 Collections framework. The Java 2
Collections framework is included in several Java platforms, including J2ME
Personal Profile and J2SE. If this refinement step is applied in combination
with a refinement step that targets the Java Swing graphical user interface
framework, the target platform is already limited to J2SE. In order to reuse
individual refinement steps that occur in a transformation, each refinement
step must be modularised in its own model transformation. One can then reuse
those refinement transformations in different transformation configurations, as
is done in Stepwise Refinement [BSR04].
If the PIM-to-PSM transformations are split up in multiple, step-wise re-
finement transformations, then the bulk of the maintenance problem moves
to the transformation configuration. Software developers must keep track of
which refinement transformations must be applied to target a specific plat-](https://image.slidesharecdn.com/25688255-250514070919-9f7a9fa4/85/Platform-Ontologies-For-The-Modeldriven-Architecture-1st-Edition-Dennis-Wagelaar-34-320.jpg)
![1.1 Problem Statement 7
form, and in which order they must be applied. An increasing number of
MDA practitioners apply workflow scripts to specify which PIM-to-PSM re-
finement transformations they want to apply and in which order78
. Such a
workflow script can take the form of an Ant build script9
, which is a Makefile
equivalent for Java.
The MDA picture then changes to what is shown in Fig. 1.5. Each con-
figuration of refinement transformations is represented by a separate build
script. The execution of the build scripts results in a separate PSM for each of
those build scripts. Refinement transformations can now be reused in multiple
configurations, targeting multiple platforms. While these separate refinement
transformations lay the basis for lifting the platform maintenance burden, they
do not solve our initial problem. It is still unclear whether a refinement trans-
formation can be used for other platforms than the one for which it was written,
since all platform dependencies are still implicit.
PIM
PSM1
UML2Accessors
UML2Observer
UML2Applet
...
Transformations
Refinement
Transformations
executes
selection of
Build script1
___________
_________
_________
___________
PSM2
PSM3
Figure 1.5: MDA improved
As the software developer puts the build script together that executes the
refinement transformations, most of the effort goes into checking that (1) the
refinement transformations work together and that (2) they are executed in the
right order [MTR05]. It is an extra burden to also (3) consider the platform
dependencies that each refinement transformation introduces. One approach
is to test the generated software on the target platform to tell if the software
works on that platform. Testing on each platform is a time-consuming activity,
however, and may even leave certain incompatibilities undetected until after
7
http://www.openarchitectureware.org/
8
http://wiki.eclipse.org/Modeling Workflow Engine (MWE)
9
http://wiki.eclipse.org/index.php/AM3 Ant Tasks](https://image.slidesharecdn.com/25688255-250514070919-9f7a9fa4/85/Platform-Ontologies-For-The-Modeldriven-Architecture-1st-Edition-Dennis-Wagelaar-35-320.jpg)
![10 Chapter 1. Introduction
1.3 Approach
1.3.1 Explicit Platform Models
We propose to use an explicit platform model, which serves as an ontology for
describing platforms. This ontology is used as a basis to express platform in-
stances as well as platform dependencies. By explicitly specifying the platform
dependencies for each reusable model transformation, each transformation can
be guaranteed as valid for a well-defined class of platforms. Because platform
instances use the same platform model as an ontology, the platform model
enables us to determine which platforms satisfy which platform dependencies.
It is expressed in the Web Ontology Language (OWL) [SWM04], which is an
extensible language for describing ontologies. Ontologies are commonly used
to represent domain knowledge and to provide a community of users with a
controlled vocabulary. We use the OWL DL variant, which corresponds to
description logic (DL) [BCM+
03] and allows us to apply automatic reasoning.
We represent platform dependencies in OWL as classes. The representation of
a platform dependency is called a platform dependency constraint. Consider,
for example, the “JavaAWTPlatform” platform dependency constraint shown
in Fig. 1.7.
Platform
JavaAWTPlatform
isa = necessary
≡ ∃ providesSoftware JavaAWTLibrary = necessary-and-sufficient
Figure 1.7: Example platform dependency
“JavaAWTPlatform” is represented as an OWL class with a necessary con-
straint as well as a necessary-and-sufficient constraint. Whereas it is necessary
that each “JavaAWTPlatform” is a “Platform”, being a “Platform” is not suffi-
cient for also being a “JavaAWTPlatform”. Providing the “JavaAWTLibrary”
software, however, is necessary-and-sufficient for being a “JavaAWTPlatform”.
The “JavaAWTPlatform” constraint can be checked against OWL instances
that represent platform instances. Each OWL instance – or individual – that
satisfies the conditions of the “JavaAWTPlatform” class can be considered as
an instance of that class. Each platform instance representation that is an in-
stance of a platform dependency constraint, satisfies that platform dependency
constraint.
Our platform model is not monolithic, but is divided into a hierarchy of
modules. Fig. 1.8 shows how the platform model is organised. The central
part of the platform model is made up of several “vocabulary ontologies”,](https://image.slidesharecdn.com/25688255-250514070919-9f7a9fa4/85/Platform-Ontologies-For-The-Modeldriven-Architecture-1st-Edition-Dennis-Wagelaar-38-320.jpg)
![1.3 Approach 11
where the word “vocabulary” refers to the fact that the domain concepts are
all introduced in these ontologies. The main Platform vocabulary ontology
describes the general concept of Platform and its parts. The Java vocabulary
ontology extends the Platform ontology for the domain of Java platforms. The
Java platform ontology is in turn extended by several vocabulary ontologies
that describe concrete Java variants: JDK 1.1, J2SE 1.2, J2ME PP 1.0, etc.
Platform dependency constraints are expressed in terms of these vocabulary
ontologies, while they are stored in a separate OWL ontology. This separate
OWL ontology is not considered to be a vocabulary, since it expresses only
platform dependency constraints rather than platform domain concepts.
Platform
vocabulary
ontology
Java
vocabulary
ontology
JDK 1.1
vocabulary
ontology
J2SE 1.2
vocabulary
ontology
J2ME PP 1.0
vocabulary
ontology
Platform
constraint
ontology
Platform
instance
ontology
Figure 1.8: Platform model overview
Platform instances are also modelled as a separate OWL ontology and refer
to the same platform vocabulary ontologies as the platform dependency con-
straints. An automatic DL reasoner, such as Racer [MH03], can be used to ver-
ify whether a platform instance satisfies the platform dependency constraints
of a model transformation. In addition, it can determine which platform de-
pendency constraint is most specific and hence forms the closest match to a
platform instance. This allows for optimisation towards a platform instance
by automatically selecting the optimal transformations for a given platform.
The explicit platform dependency constraints for each model transforma-
tion also make it possible to automatically derive the overall platform con-
straints for a configuration of transformations. This allows us to verify which
build script (see Fig. 1.5) is most-specific and valid for a given platform. What
is left is the integration of our platform model with a configuration approach
for the MDA. That way, we can leverage the platform dependency information
during the configuration process.](https://image.slidesharecdn.com/25688255-250514070919-9f7a9fa4/85/Platform-Ontologies-For-The-Modeldriven-Architecture-1st-Edition-Dennis-Wagelaar-39-320.jpg)
![12 Chapter 1. Introduction
1.3.2 Platform-Driven Configuration
Configuration is a complex topic that has already been widely researched.
Within the field of software engineering, most research on configuration has
been conducted by the Software Product Line (SPL) [CN01] community. SPLs
are concerned with leveraging the commonalities between related software
products. They integrate a number of software-intensive products that share
a significant amount of functionality. As such, any software that is developed
using the MDA approach can be considered as an SPL, since each platform-
specific software product shares significant functionality with other platform-
specific versions of that software product. This shared functionality is typically
specified in the PIM. In [Bos06], Bosch also argues that SPLs have been espe-
cially successful in the area of mobile and embedded devices, in which platform
diversity is the rule rather than the exception. This relationship between the
MDA and SPLs allows us to build on the configuration technology used in SPLs
for the configuration of our PIM-to-PSM refinement transformations. When-
ever the MDA and SPL technology are used in combination, we will speak of
MDA-based SPLs.
In contemporary SPL practise, the principles of SPLs have been extrapo-
lated to shift the bulk of the engineering effort to the product line’s reusable
assets [Kru06]. The effort for deriving software products from these assets is
reduced to creating a Product Model that contains all configuration informa-
tion for that product. The product line’s infrastructure includes a generator
(“SPL Configurator”) that generates the product’s implementation from the
Product Model, as shown in Fig. 1.9a. In Generative Programming [CE00],
Product Models are often expressed in terms of a Domain-Specific Language
(DSL) – or a Domain-Specific Modelling Language (DSML) [LBM+
01][TR03].
DSMLs are a specific kind of DSL that use meta-models as a language defi-
nition formalism. We have explained previously how PIMs and PSMs in the
MDA also have meta-models, which are used by the PIM-to-PSM refinement
transformations.
SPL
Configurator
Variation Points
Core Asset N
Variation Points
Core Asset N
Variation Points
Core Asset N
Product Models
Product A
Product B
Product M
MDA
Configurator
Refinement
Transformations
Configuration Models
Build script A
Build script B
Build script M
Figure 1.9: (a) Software product line configurator and (b) MDA configurator](https://image.slidesharecdn.com/25688255-250514070919-9f7a9fa4/85/Platform-Ontologies-For-The-Modeldriven-Architecture-1st-Edition-Dennis-Wagelaar-40-320.jpg)
![14 Chapter 1. Introduction
1.4 Contributions
• A common platform domain model
We present how OWL-DL can be used to define a general plat-
form model that serves as a common ontology for specific plat-
form sub-domains. This work has been presented in [PVW+
04],
[Wag05] and [WJ05]. We also present how the general plat-
form model can be extended for the platform sub-domain of Java
Runtime Environments (JREs). This work has been presented
in [Wag05], [WJ05] and [WV07].
• A method for describing platform dependencies and
platform instances
We present how platform dependency constraints and platform
instances can be described, based on the common platform model
and extensions. The platform dependencies can be compared
against platform instances to check if they are satisfied. In
addition, we can determine which platform dependencies are
more specific than other platform dependencies and form a closer
match to the targeted platform. This work has been presented
in [Wag05], [WJ05] and [WV07].
• A framework for platform dependency management
We present how the platform model can be integrated in a soft-
ware development process based on the MDA and SPLs. The
relationship between the MDA and SPLs is explored as part of
this work and a common configuration approach based on DSMLs
is used. This work has been presented in [WV06] and [WV07].
• A framework for platform-driven optimisation
We present how platform dependencies can be used as the basis
for selecting optimal model transformations (or SPL features).
In addition, we present how this can be extrapolated for the
selection of optimal configurations. This work has been described
in [Wag05], [WJ05] and [WV07].](https://image.slidesharecdn.com/25688255-250514070919-9f7a9fa4/85/Platform-Ontologies-For-The-Modeldriven-Architecture-1st-Edition-Dennis-Wagelaar-42-320.jpg)
![1.5 Dissertation structure 15
• A case study that applies the explicit platform model in
an MDA/SPL setting
We have developed a non-trivial case study of a cross-platform
Instant Messaging client that demonstrates the merits and lim-
itations of our approach. The case study is available at http:
//ssel.vub.ac.be/ssel/research:mdd:casestudies and is used
in [Wag05], [WJ05] and [WV07].
• Tool support
We have developed a tool, named PlatformKit, that implements
platform dependency management and platform-driven optimisa-
tion based on the Eclipse Modeling Framework (EMF) [BSM+
03].
The PlatformKit tool is available at http://ssel.vub.ac.be/
ssel/research:mdd:platformkit and is described in [WV07]. In
addition, we have developed the Jar2UML tool that reverse en-
gineers Java class libaries to UML models. Those UML models
are used by PlatformKit to determine compatibility between dif-
ferent Java platforms. Jar2UML is available at http://ssel.
vub.ac.be/ssel/research:mdd:jar2uml. Finally, we have added
several improvements to the ATLAS Transformation Language
tool for the purpose of our case study. Those improvements have
been integrated back into the main ATL code, which is available
at http://www.eclipse.org/m2m/atl. One of the ATL improve-
ments, module superimposition, is described in [Wag08].
1.5 Dissertation structure
Fig. 1.11 shows an overview of the structure of this dissertation. Following this
chapter, a background chapter on the Model-Driven Architecture and a back-
ground chapter on ontologies provide the basis for our approach to platform
modelling. The next chapter discusses our platform modelling approach itself.
This is followed by a background chapter on Software Product Lines that pro-
vides the basis for our MDA configuration approach. Our MDA configuration
approach itself is discussed in the subsequent chapter. The next chapter dis-
cusses our tool support and the final chapter discusses the conclusions of this
dissertation. We will now give a detailed description of each chapter.
Chapter 2: Model-Driven Architecture This chapter gives an in-depth
explanation of the MDA. The main concepts of the MDA, such as model,](https://image.slidesharecdn.com/25688255-250514070919-9f7a9fa4/85/Platform-Ontologies-For-The-Modeldriven-Architecture-1st-Edition-Dennis-Wagelaar-43-320.jpg)
![Chapter 2
Model-Driven Architecture
2.1 Introduction
The Model-Driven Architecture (MDA) was introduced by the Object Man-
agement Group (OMG) as an approach to use models in software development.
Its goals are portability, interoperability and reusability through architectural
separation of concerns. MDA intends to provide an approach for:
• “specifying a system independently of the platform that supports it,
• specifying platforms,
• choosing a particular platform for the system, and
• transforming the system specification into one for a particular plat-
form.” [MM03]
The terms platform and platform independence are used extensively in
MDA. The MDA Guide defines a platform as follows:
“A platform is a set of subsystems and technologies that provide a
coherent set of functionality through interfaces and specified usage
patterns, which any application supported by that platform can use
without concern for the details of how the functionality provided by
the platform is implemented.” [MM03]
This definition introduces the notion of interfaces and usage patterns. It
also positions a platform as an abstraction layer that can be used without
knowing how platform functionality is provided. We have previously defined
19](https://image.slidesharecdn.com/25688255-250514070919-9f7a9fa4/85/Platform-Ontologies-For-The-Modeldriven-Architecture-1st-Edition-Dennis-Wagelaar-47-320.jpg)
![20 Chapter 2. Model-Driven Architecture
a platform as the hardware and software combination on top of which our
software runs, which is a broader definition of platform.
Platform independence refers to the quality of being independent of the fea-
tures of a platform and is a matter of degree. A common technique for achiev-
ing platform independence is to target a technology-neutral virtual machine. A
virtual machine can also be considered a platform. Any model targeting that
virtual machine is considered specific to that platform, but independent of any
underlying platform. When specifying a system in a platform-independent way,
one already needs to have an idea of which platforms are targeted [TBA04].
The system’s specification is independent of all these platforms if it only de-
pends on features that are common for all platforms – or can be mapped to all
platforms.
MDA contains the word architecture, which is an overloaded term in soft-
ware engineering. The MDA guide uses the following definition to relate the
term architecture to its meaning in MDA:
“The architecture of a system is a specification of the parts and con-
nectors of the system and the rules for the interactions of the parts
using the connectors. The Model-Driven Architecture prescribes cer-
tain kinds of models to be used, how those models may be prepared
and the relationships of the different kinds of models.” [MM03]
The Model-Driven Architecture refers to the architecture of the software
development process, summarised by the MDA pattern. In Chapter 1, we
have already introduced the basic MDA pattern: to use Model Transformation
to map a Platform-Independent Model (PIM) to a Platform-Specific Model
(PSM). Fig. 2.1 shows the envisioned impact of this pattern: the left side
shows the traditional lifecycle of iterative development. In theory, the feedback
loop should go all the way up to the requirements level, keeping all software
artifacts synchronised.
In practise, the fact that process stage transitions are only automated from
the code level downward makes that it is not feasible to feed changes back to
the top level. The feedback effort is normally rewarded by an updated system
that incorporates the feedback. That updated system is our real goal, not
feeding back changes to higher abstraction levels.
If we provide feedback to the top level, this will not result in an updated
system. In fact, we have to manually translate the feedback to the lower
levels of abstraction until we reach code level. Only at code level, automation
picks up and the feedback loop is closed. That’s why currently feedback is
mostly provided directly at code level and all software artifacts at a higher
level gradually become outdated.](https://image.slidesharecdn.com/25688255-250514070919-9f7a9fa4/85/Platform-Ontologies-For-The-Modeldriven-Architecture-1st-Edition-Dennis-Wagelaar-48-320.jpg)
![2.2 Models 21
!""#$!""%&'()*+,-./0&1*)+.,20&3*)440&5,26,+0&
7!
'89,
'89,
Impact of MDA on the Development Process
:,;</*,=,+>6
?+)2@6/6
A,6/B+
'89/+B
C,6>/+B
A,D28@=,+>
E86>2@
>,F>
A/)B*)=6
)+9&>,F>
A/)B*)=6
)+9&>,F>
G>,*)>/H,
D*8-,66
I/+&>J,8*@K
L*8B*)==,*M6
6J8*>-<>
'89,
'89,
:,;</*,=,+>6
?+)2@6/6
A,6/B+
'89/+B
C,6>/+B
A,D28@=,+>
E86>2@
>,F>
LNE
LGE
EA?
D*8-,66
N8<*-,O&P2,DD, ,>&)2&!""#
Traditional lifecycle MDA lifecycle
Figure 2.1: Impact of MDA on the development process (source: [KWB03]).
The right side of Fig. 2.1 shows how the MDA intends to mitigate this
problem. The analysis and design artifacts are made part of the automation
pipeline. It then becomes easier to lift the feedback loop of iterative devel-
opment up to the analysis level, where automation picks up and closes the
feedback loop.
The core concepts in any MDA-based process are:
• Models
• Meta-models
• Model Transformation
The following sections discuss these core concepts, as well as the relation-
ship of MDA to existing research.
2.2 Models
MDA is centred around models and how those models may be used together
to create the resulting software system. The MDA guide defines a model as
follows:
“A model of a system is a description or specification of that system and
its environment for some certain purpose. A model is often presented
as a combination of drawings and text. The text may be in a modeling
language or in a natural language.” [MM03]](https://image.slidesharecdn.com/25688255-250514070919-9f7a9fa4/85/Platform-Ontologies-For-The-Modeldriven-Architecture-1st-Edition-Dennis-Wagelaar-49-320.jpg)
![22 Chapter 2. Model-Driven Architecture
This is a very broad definition of a model, which unfortunately mixes up
the structure of a model with its presentation. The structure of a model is
defined by the abstract syntax of the language that a model is written in. The
presentation of a model is defined by the concrete syntax of the modelling lan-
guage. Even though the definition covers the presentation of models, the focus
lies on the structure of a model in the MDA, as is made clear in section 2.3.
Models can play a number of particular roles in an MDA-based process. Four
kinds of models with a particular role are distinguished in the MDA:
• Computation Independent Model (CIM)
• Platform Independent Model (PIM)
• Platform Specific Model (PSM)
• Platform Model (PM)
The standard language for expressing these models is the Unified Modeling
Language (UML) [OMG05c]. The following sections discuss each of the listed
models.
2.2.1 Computation Independent Models
The Computation Independent Model focuses on the requirements for the sys-
tem and the environment of the system. It is sometimes called a domain model
and serves as a vocabulary that is familiar to the practitioners of the system’s
domain. A CIM is more than a domain model, however, since it also expresses
the system requirements using the domain concepts as a vocabulary. A CIM
does not show details of the structure or processing of the system. The CIM
is intended to help bridge the gap between domain experts and system design
experts.
It is difficult to say exactly when a model is still “computation indepen-
dent”. It may show the structure of the domain, but not the details of that
structure. It also may show the behaviour of the domain, but not any process-
ing details specific to the system we aim to specify. Let’s consider an example
system of an instant messaging client that shows a list of people who are on-
line and that can send messages to those people. Fig. 2.2 shows what such an
instant messaging client can look like.
A CIM of such an instant messaging client describes the domain concepts
for instant messaging, such as “contact”, “contact list” and “message”. For
each of these concepts, a number of behavioural and structural features (op-
erations and attributes) can be described. The CIM does not describe what
steps the system must perform to achieve a certain behaviour. Fig. 2.3 shows
a UML Class diagram of the instant messaging client domain concepts. Note](https://image.slidesharecdn.com/25688255-250514070919-9f7a9fa4/85/Platform-Ontologies-For-The-Modeldriven-Architecture-1st-Edition-Dennis-Wagelaar-50-320.jpg)
![2.2 Models 25
Figure 2.4: A UML Class diagram showing part of the instant messaging client
PIM.
• The observer pattern has been implemented using the java.util.Ob-
server interface and the java.util.Observable class.
• All <<Applet>> classes have been implemented as java.applet.Applet
subclasses.
• All <<Singleton>> classes now include the singleton infrastructure (a
static ‘instance’ property and ‘getInstance()’ operation).
2.2.4 Platform Models
A Platform Model provides the technical concepts that represent the parts
that make up a platform. It also provides concepts for specifying the use of
a platform by a software system, which can be used in a PSM. As an exam-
ple, the CORBA Component Model (CCM) [OMG06a] provides concepts as
EntityComponent, SessionComponent, ProcessComponent, Facet, Receptacle,
EventSource, etc. A software system can use these concepts to specify how it
uses the CCM.
A Platform Model also specifies requirements on how a software system
is connected to the platform. As an example, the UML profile for CORBA
[OMG02] provides a language to use when modelling CORBA systems. The
rules of this language represent the requirements of the connection to the
platform.](https://image.slidesharecdn.com/25688255-250514070919-9f7a9fa4/85/Platform-Ontologies-For-The-Modeldriven-Architecture-1st-Edition-Dennis-Wagelaar-53-320.jpg)
![26 Chapter 2. Model-Driven Architecture
Figure 2.5: A UML Class diagram showing part of the instant messaging client
PSM.
This notion of Platform Model is mostly useful to model abstract plat-
forms [ADvSP04], which represent a common interface to all targeted plat-
forms. In the instant messaging client example, this Platform Model consists
of a simplified representation of some of the Java API that is common to all
targeted Java platforms (e.g. java.lang.Exception) and several UML pro-
files (Applet, Singleton, Observer, . . . ) that abstract from the way a specific
Java platforms implements certain functionality. A Platform Model can also
consist of the API for a specific Java platform, such as J2SE 1.4. The PSM
typically refers to such a Platform Model. Note that the model transforma-
tions that map a PIM to a PSM introduce the references to such a Platform
Model.
Our notion of Platform Model goes further than that: a Platform Model is
meant to drive the mapping from PIM to (lowest level) PSM. This may include
selecting all the appropriate model transformations for a complete mapping to
the targeted platform. This notion of Platform Model is discussed later in this
dissertation.](https://image.slidesharecdn.com/25688255-250514070919-9f7a9fa4/85/Platform-Ontologies-For-The-Modeldriven-Architecture-1st-Edition-Dennis-Wagelaar-54-320.jpg)
![imperceptible difference between that and the Dumfriesshire, I suppose; but
I should not like to have to discriminate where the difference lies.”
As for Lauderdale, he sighed; but without intending it, as it appeared, for
he made a great effort to cover his sigh with a yawn, for which latter
indulgence he had evidently no occasion; and then he tried a faint little
unnecessary laugh. “I’m an awfu’ man for associations,” he said; “I’m no to
be held to account for the things that come into my head. You may say it’s
Cumberland, and I’m no disputing; but for a’ that there’s something in the
sound of the voice——”
“Look here,” said Colin impatiently; “listen to my tract. I want you to
give me your opinion now it is finished; turn this way, with your face to the
hills, and never mind the voice.”
“Oh, ay,” said Lauderdale, with another sigh; “there’s nae voice like his
ain voice to this callant’s ear; it’s an awfu’ thing to be an author, and above
a’ a reformer; for you may be sure it’s for the sake of the cause, and no
because he’s written a’ that himsel’. Let’s hear this grand tract of yours; no
that I’ve any particular faith, in that way of working,” he added impartially.
It was not encouraging perhaps to the young author; but Colin was
sufficiently used by this time to his friend’s predilections, and for his own
part was very well pleased to escape from memories more perplexing and
difficult to manage. It was with this intention that he had taken out No. I. of
the Tracts for the Times. If any of the writers of the original series of these
renowned compositions could but have looked over the shoulder of the
young Scotch minister, and beheld the different fashion of thoughts, the
curious fundamental difference which lay underneath, and yet the apparent
similarity of intention on the face of it! Rome and the Pope were about as
far off as Mecca and the prophet from Colin’s ideas. He was not in the least
urgent for any infallible standard, nor at all concerned to trace a direct line
of descent for himself or his Church; and yet withal his notions were as
high and absolute and arbitrary on some points as if he had been a member
of the most potent of hierarchies. It would, however, be doing Colin
injustice to reproduce here this revolutionary document: to tell the truth,
circumstances occurred very soon after to retard the continuation of the
series, and, so far as his historian is aware, the publication of this
preliminary[4] address was only partial. For, to be sure, the young man had
still abundance of time before him, and the first and most important thing,](https://image.slidesharecdn.com/25688255-250514070919-9f7a9fa4/85/Platform-Ontologies-For-The-Modeldriven-Architecture-1st-Edition-Dennis-Wagelaar-65-320.jpg)
Platform Ontologies For The Modeldriven Architecture 1st Edition Dennis Wagelaar
- 1. Platform Ontologies For The Modeldriven Architecture 1st Edition Dennis Wagelaar download https://ebookbell.com/product/platform-ontologies-for-the- modeldriven-architecture-1st-edition-dennis-wagelaar-51376510 Explore and download more ebooks at ebookbell.com
- 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Platform Labour And Global Logistics A Research Companion Immanuel Ness https://ebookbell.com/product/platform-labour-and-global-logistics-a- research-companion-immanuel-ness-48703640 Platform Strategies A Guidebook For Entrepreneurs In The Platform Economy Paul Belleflamme https://ebookbell.com/product/platform-strategies-a-guidebook-for- entrepreneurs-in-the-platform-economy-paul-belleflamme-49138962 Platform Michel Houellebecq https://ebookbell.com/product/platform-michel-houellebecq-49849980 Platform Based Design And Immersive Technologies For Manufacturing And Assembly In Offsite Construction Applying Extended Reality And Game Applications To Pdfma Lilia Potseluyko https://ebookbell.com/product/platform-based-design-and-immersive- technologies-for-manufacturing-and-assembly-in-offsite-construction- applying-extended-reality-and-game-applications-to-pdfma-lilia- potseluyko-50637518
- 3. Platform Engineering On Kubernetes Meap V09 All 9 Chapters Mauricio Salatino https://ebookbell.com/product/platform-engineering-on-kubernetes- meap-v09-all-9-chapters-mauricio-salatino-50688138 Platform Business Models For Executives 2nd 2nd Edition R Srinivasan https://ebookbell.com/product/platform-business-models-for- executives-2nd-2nd-edition-r-srinivasan-51991676 Platform Capitalism In India 1st Ed Adrian Athique Vibodh Parthasarathi https://ebookbell.com/product/platform-capitalism-in-india-1st-ed- adrian-athique-vibodh-parthasarathi-22456230 Platform Business Models Frameworks Concepts And Design R Srinivasan https://ebookbell.com/product/platform-business-models-frameworks- concepts-and-design-r-srinivasan-33720080 Platform Economics Rhetoric And Reality In The Sharing Economy Cristiano Codagnone https://ebookbell.com/product/platform-economics-rhetoric-and-reality- in-the-sharing-economy-cristiano-codagnone-34785478
- 5. Date: 07/04/2008 Promoters: Prof. Dr. Viviane Jonckers, Dr. Ragnhild Van Der Straeten Platform Ontologies for the Model-Driven Architecture Dennis Wagelaar A dissertation submitted in partial fulfilment of the requirements for the degree of Doctor of Science FACULTY OF SCIENCE Department of Computer Science System and Software Engineering Lab
- 6. Print: Flin Graphic Group, Oostkamp c Dennis Wagelaar c 2008 Uitgeverij VUBPRESS Brussels University Press VUBPRESS is an imprint of ASP nv (Academic and Scientific Publishers nv) Ravensteingalerij 28 B-1000 Brussels Tel. ++32 (0)2 289 26 50 Fax ++32 (0)2 289 26 59 E-mail: [email protected] www.vubpress.be ISBN 978 90 5487 482 9 NUR 992 Legal deposit D/2008/11.161/026 All rights reserved. No parts of this book may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or other wise, without the prior written permission of the author and the publisher. -
- 7. Abstract Software systems not only continue to grow more complex, but they are often required to run on multiple platforms as well. Common personal computer platforms are Microsoft Windows, Linux and Apple Mac OS X on a PowerPC or x86 hardware architecture. Hand-held devices present another range of platforms, such as Microsoft Windows Mobile, Qtopia/Embedix and Symbian running on an ARM or RISC hardware architecture. Each of these platforms look different from a software developer’s point of view and requires the devel- opment of different software versions for each platform. This platform diversity makes it increasingly difficult to maintain software that is portable to multi- ple platforms. Software developers not only have to develop multiple software versions, but they also have to keep these versions synchronised and consistent in their common functionality. In addition to this, platform technologies tend to evolve. When developing software for an evolving platform, software developers have to take into account that the users may use older versions of the platform. Developers may be confronted with the fact that their software is no longer compatible with an older version of the platform, because they do all their development and testing on the latest version of the platform. If the current range of platforms can already be considered diverse, the vi- sion of Ambient Intelligence only amplifies this diversity. Ambient Intelligence aims for a user-driven, service-based computing environment that includes per- sonal devices as well as special-purpose embedded devices in the environment. The hardware and software combinations in such devices can vary widely. The Object Management Group has acknowledged the problem of platform diversity by introducing the Model Driven Architecture (MDA). The MDA is centred around the use of software models. The software models provide a means to create partial, platform-independent software specifications that make use of platform abstractions. These abstractions are refined to platform- specific software models in a later stage of the development life cycle, using i
- 8. ii Abstract model transformations. Currently, these model transformations implicitly as- sume a target platform for the platform-specific models. If other platforms must be targeted, new model transformations have to be created. This intro- duces a considerable maintenance burden for each additional platform we want to support. It is possible to split up a model transformation into multiple refinement transformation steps, each of which introduces some partial platform depen- dencies into the software model. This makes it possible to reuse a refinement transformation for other platforms. It is not clear when we can reuse a refine- ment transformation, however, since the platform dependencies it introduces are still implicit. When combining multiple refinement transformations for a target platform, most of the effort goes into checking that (1) the refinement transformations work together and that (2) they are executed in the right order. It is an extra burden to also (3) consider the platform dependencies that each refinement transformation introduces. One approach is to test the generated software on the target platform to tell if the software works on that platform. Testing on each platform is a time-consuming activity, however, and may even leave certain incompatibilities undetected until after deployment. Another approach is to use an automated configuration process that enforces the satisfaction of constraints, including platform dependency constraints. Such a configuration process does not exist for the MDA today. We propose to use an explicit platform model, which serves as a vocabu- lary for describing platforms. This vocabulary is used as a basis to express platform instances as well as platform dependencies. By explicitly specifying the platform dependencies for each reusable refinement transformation, each transformation can be guaranteed as valid for a well-defined class of platforms. Because platform instances use the same platform model as a vocabulary, the platform model enables us to determine which platforms satisfy which plat- form dependencies. The platform model is expressed in the Web Ontology Language (OWL), which is an extensible language for describing ontologies. Ontologies are commonly used to represent domain knowledge and to provide a community of users with a controlled vocabulary. We use the OWL DL variant, which corresponds to description logic (DL) and allows us to apply automatic reasoning. We also propose a configuration process for the MDA that is based on Software Product Lines (SPLs). Within the field of software engineering, most research on configuration has been conducted by the SPL community. SPLs integrate a number of software-intensive products that share a signifi- cant amount of functionality. As such, any software that is developed using the MDA approach can be considered as an SPL, since each platform-specific software product shares significant functionality with other platform-specific versions of that software product.
- 9. Samenvatting Software systemen worden niet alleen steeds complexer, maar worden ook vaak vereist om op meerdere platformen te werken. Veel voorkomende personal computer platformen zijn Microsoft Windows, Linux en Apple Mac OS X op een PowerPC of x86 hardware architectuur. Draagbare apparaten vormen een bijkomend scala aan platformen, zoals Microsoft Windows Mobile, Qtopie/Em- bedix en Symbian draaiende op een ARM of RISC architectuur. Elk van deze platformen ziet er anders uit voor een software-ontwikkelaar en vereist de on- twikkeling van verschillende software-versies voor ieder platform. Deze diver- siteit in platformen maakt het steeds moeilijker om software te onderhouden die overdraagbaar is naar meerdere platformen. Software-ontwikkelaars dienen niet alleen meerdere software-versies te ontwikkelen, maar zij moeten deze ver- sies ook gesynchroniseerd en consistent houden wat hun gemeenschappelijke functionaliteit betreft. Daarbij komt nog dat platform-technologieën vaak evolueren. Wanneer software-ontwikkelaars software schrijven voor een evoluerend platform, moe- ten zij er rekening mee houden dat de gebruikers weleens oudere versies van dat platform kunnen gebruiken. De ontwikkelaars kunnen hierbij geconfron- teerd worden met het feit dat hun software niet langer compatibel is met een oudere versie van het platform, omdat het ontwikkelen en testen plaatsvindt op de nieuwste versie van het platform. Als we het huidige scala aan platformen al divers vinden, dan wordt deze di- versiteit alleen maar versterkt door de visie van Ambient Intelligence. Ambient Intelligence doelt op een door de gebruiker gedreven en op diensten gebaseerde computeromgeving, welke zowel persoonlijke apparaten als gespecialiseerde in- gebouwde apparaten omvat. De hardware- en softwarecombinaties in zulke apparaten kunnen sterk variëren. De Object Management Group heeft het probleem van platform-diversiteit onderkend door de introductie van de Model Driven Architecture (MDA). De MDA is opgebouwd rond het gebruik van softwaremodellen. De softwaremod- iii
- 10. iv Samenvatting ellen bieden een middel om partiële, platform-onafhankelijke software specifi- caties te maken die gebruik maken van platform-abstracties. Deze abstracties worden verfijnd naar platform-specifieke softwaremodellen in een later stadium van de software-ontwikkelingscyclus met behulp van model transformaties. Op dit moment gaan deze transformaties impliciet uit van een doelplatform voor de platform-specifieke modellen. Als er andere platformen ondersteund dienen te worden, moeten er nieuwe modeltransformaties gemaakt worden. Dit in- troduceert een aanzienlijke onderhoudslast voor ieder extra platform dat we willen ondersteunen. Het is mogelijk om een modeltransformatie op te splitsen in meerdere stap- pen van verfijningstransformaties, waarbij elke stap enkele partiële platform- afhankelijkheden in het softwaremodel introduceert. Dit maakt het mogelijk om een verfijningstransformatie te hergebruiken voor andere platformen. Het is echter niet duidelijk wanneer we een verfijningstransformatie kunnen herge- bruiken, omdat de platform-afhankelijkheden die zij introduceert nog steeds impliciet zijn. Wanneer er meerdere verfijningstransformaties gecombineerd worden voor een doelplatform, gaat de meeste inspanning naar het controleren dat (1) de verfijningstransformaties samenwerken en dat (2) zij in de juiste volgorde wor- den uitgevoerd. Het is een extra last om ook (3) de platform-afhankelijkheden te beschouwen die elke verfijningstransformatie introduceert. Een mogelijke benadering is om de gegenereerde software te testen op het doelplatform om erachter te komen of de software werkt op dat platform. Het testen op elk platform is echter een tijdrovende bezigheid en laat mogelijk zelfs bepaalde incompatibiliteiten onopgemerkt tot na de installatie. Een andere benadering is om een geautomatiseerd configuratieproces te gebruiken dat het voldoen aan bepaalde beperkingen afdwingt, inclusief platform-afhankelijkheidsbeperkingen. Een dergelijk configuratieproces bestaat vandaag de dag nog niet voor de MDA. Wij stellen voor om een expliciet platform-model te gebruiken, welke dient als vocabulaire voor het beschrijven van platformen. Dit vocabulaire wordt gebruikt als een basis voor het beschrijven van zowel platform-instanties als platform-afhankelijkheden. Door het expliciet beschrijven van de platform- afhankelijkheden voor elke herbruikbare verfijningstransformatie kan elke trans- formatie als geldig worden gegarandeerd voor een welgedefiniëerde klasse van platformen. Omdat platform-instanties hetzelfde platform-model gebruiken als vocabulaire, stelt het platform-model ons in staat om te bepalen welke plat- formen aan welke platform-afhankelijkheden voldoen. Het platform-model is uitgedrukt in de Web Ontology Language (OWL), wat een uitbreidbare taal is voor het beschrijven van ontologieën. Wij gebruiken de OWL DL variant, welke overeenkomt met description logic (DL) en ons toestaat om automatische redenering toe te passen. Wij stellen ook een configuratieproces voor de MDA voor dat gebaseerd is op Software Product Lines (SPLs). Binnen het veld van software engineering is
- 11. Samenvatting v het meeste onderzoek naar configuratie uitgevoerd door de SPL-gemeenschap. SPLs integreren een aantal software-intensieve producten die een aanzienlijke hoeveelheid aan functionaliteit gemeen hebben. Als zodanig kan alle software die ontwikkeld is met behulp van de MDA beschouwd worden als een SPL, omdat elk platform-specifiek softwareproduct een aanzienlijke hoeveelheid aan functionaliteit gemeen heeft met andere platform-specifieke versies van dat softwareproduct.
- 13. Acknowledgements This is where I show my gratitude to all the people who made my Ph.D. possi- ble. But before I start, I’d like to sketch some of the context in which I worked on my PhD. In August 2002, I moved from Losser, the Netherlands, to Brus- sels, Belgium to work on my Ph.D. at the System and Software Engineering Lab of the Vrije Universiteit Brussel (VUB). I quickly learnt that the VUB was very different from the University of Twente, where I had studied for my Master’s degree. What I did not learn so quickly was how to integrate in such a different environment. Combined with my efforts to make life in Brussels work out, this took quite a bit of my time and attention. As a result, I’m finishing off this dissertation after almost six years in 2008. The main hallmark of the VUB is that it takes its liberal stance seriously. I was really free in my choices, which also required a lot more independence on my part. Prof. Dr. Viviane Jonckers not only gave me the opportunity and freedom to pursue my own research topic, but she also had the patience for me to find my way through. I’d like to thank her for her confidence and support throughout these years. I hope to reward her confidence by closing off my Ph.D. period with this dissertation. I would also like to thank Dr. Ragnhild Van der Straeten, Dr. Wim Van- derperren and Dr. Dirk Deridder for taking their time to discuss my research topic in detail with me. They have also read drafts of this dissertation in detail and provided me with valuable comments and directions. I owe my gratitude to my Ph.D. committee members, for taking the time to read this dissertation in detail and for providing me with valuable comments. Apart from my advisors Viviane and Ragnhild, the committee members are Prof. Dr. Jean Bézivin, Prof. Dr. Yolande Berbers, Prof. Dr. Theo D’Hondt, Prof. Dr. Wolfgang De Meuter and Prof. Dr. Olga Detroyer. I would also like to thank all of my colleagues and former colleagues, who have made my job more pleasant and were always there for interesting chats: Dr. Bart Wydaeghe, Dr. Wim Vanderperren, Davy Suvée, Dr. Bart Ver- vii
- 14. viii Acknowledgements heecke, Miro Casanova, Dr. Ragnhild Van der Straeten, Dr. Maja D’Hondt, Dr. Marı́a Agustina Cibrán, Bruno De Fraine, Niels Joncheere, Mathieu Braem and my most recent colleagues Dr. Dirk Deridder, Andrés Yie, Mario Sanchez, Oscar González, Eline Philips and Dr. Andy Kellens. Special thanks go to Andres for test-driving my PlatformKit tool support and actually reading the manual. I would also like to thank Bruno De Fraine and Wim Vanderperren for managing the lab’s servers with me. It provides an enormous freedom to be able to manage your own servers, but it is also good to know that I could share the responsibility with them. I really valued the unique situation in which our lab members contributed to our own servers. Many thanks also go to the ATLAS team, with Jean Bézivin, Frédéric Jouault and Freddy Allilaire in particular, for sharing their ideas on model- driven engineering and letting me into the ATL community. Their open stance have allowed me to thoroughly experiment with model transformation and seeing my efforts fed back into the ATL (and AM3) tool. I hope for a fruitful collaboration in the future as well. I’d like to thank my friends, Mark van Benthem, Joost Noppen, Frank Vlaardingerbroek and Tjim Wijering, for staying in touch after I’ve moved to Belgium. Even after not seeing each other for a long time, they have not forgotten about me. I would like to thank Joost in particular for even finding the time to proof-read my dissertation. I would like to thank my parents, André and Paulien, who have always supported my studies from the very beginning. They weren’t happy to see me leave to Belgium, but have never complained about it. They have in fact provided all the support they could for making my life in Belgium easier, so that I could spend more attention on my thesis. I would also like to thank Cynthia’s parents, Philip and Frances, my brother Edwin and his wife Anja, as well as my uncle Gerard, for all their help with our house. If it weren’t for our families, we wouldn’t be living in our new house in Mechelen. Finally, I’d like to thank my girlfriend Cynthia for being with me all this time. We moved to Belgium together in 2002 and we’ve also endured our common hardships here. Together, we’ve managed to find our place in Belgium. Cynthia has always supported me during this time and she kept a close eye on my thesis progress as well. Finishing this dissertation opens up our future to new opportunities, starting in our new home in Mechelen.
- 15. Dankwoord Dit is waar ik mijn dank toon aan alle mensen die mijn doctoraat mogelijk hebben gemaakt. Maar voordat ik van wal steek, zou ik graag de context waarin ik aan mijn doctoraat gewerkt heb schetsen. In augustus 2002 ben ik verhuisd uit Losser, Nederland, naar Brussel, België, om aan mijn doctoraat te werken bij het Systeem en Software Engineering Lab van de Vrije Universiteit Brussel (VUB). Ik leerde al snel dat de VUB sterk verschilde van de Universiteit Twente, waar ik voor mijn ingenieursdiploma heb gestudeerd. Wat ik niet zo snel leerde was hoe te integreren in een zo verschillende omgeving. Samen met mijn inspanningen om mijn leven in Brussel in goede banen te leiden, nam dit een behoorlijk deel van mijn tijd en aandacht in beslag. Als gevolg leg ik de laatste hand aan dit proefschrift na bijna zes jaar in 2008. Het hoofdkenmerk van de VUB is dat zij haar liberale standpunt serieus neemt. Ik was echt vrij in mijn keuzes, wat ook een stuk meer onafhankeli- jkheid van mijn kant vereiste. Prof. Dr. Viviane Jonckers gaf mij niet alleen de kans en vrijheid om mijn eigen onderzoeksonderwerp na te volgen, maar ze had ook het geduld om mij een weg te laten banen. Ik wil haar graag be- danken voor haar vertrouwen en ondersteuning gedurende deze jaren. Ik hoop haar vertrouwen te belonen door mijn doctoraatsperiode af te ronden met dit proefschrift. Ik wil ook graag Dr. Ragnhild Van Der Straeten, Dr. Wim Vanderperren en Dr. Dirk Deridder bedanken voor hun tijd waarin zij mijn onderzoekson- derwerp in detail met mij hebben besproken. Zij hebben ook conceptversies van dit proefschrift in detail doorgelezen en hebben hebben mij voorzien van waardevolle commentaren en mogelijkheden voor verbetering. Ik ben dank verschuldigd aan mijn juryleden die de tijd hebben genomen om dit proefschrift in detail te lezen en mij van waardevolle commentaren voorzien hebben. Naast mijn promotoren, Viviane en Ragnhild, bestaat mijn jury uit Prof. Dr. Jean Bézivin, Prof. Dr. Yolande Berbers, Prof. Dr. Theo D’Hondt, Prof. Dr. Wolfgang De Meuter en Prof. Dr. Olga Detroyer. ix
- 16. x Dankwoord Ik wil ook graag al mijn collega’s en voormalige collega’s bedanken voor het aangenamer maken van mijn werk en het feit dat zij er altijd waren voor interessante gesprekken: Dr. Bart Wydaeghe, Dr. Wim Vanderperren, Davy Suvée, Dr. Bart Verheecke, Miro Casanova, Dr. Ragnhild Van Der Straeten, Dr. Maja D’Hondt, Dr. Marı́a Agustina Cibrán, Bruno De Fraine, Niels Joncheere, Mathieu Braem en mijn meest recente collega’s Dr. Dirk Derid- der, Andrés Yie, Mario Sanchez, Oscar González, Eline Philips en Dr. Andy Kellens. Een speciaal dankwoord gaat naar Andres voor het testen van mijn PlatformKit software en het daadwerkelijk lezen van de handleiding. Ik wil ook graag Bruno De Fraine en Wim Vanderperren bedanken voor het beheren van de servers op het lab samen met mij. Het verschaft een enorme vrijheid om je eigen servers te kunnen beheren, maar het is tegelijkertijd ook goed om te weten dat ik de verantwoordelijkheid kon delen met hen. Ik stelde de unieke situatie waarin de leden van ons lab bijdroegen aan onze eigen servers zeer op prijs. Mijn dankbaarheid gaat ook naar het ATLAS team, met Jean Bézivin, Frédéric Jouault and Freddy Allilaire in het bijzonder, voor het delen van hun ideeën omtrent model-driven engineering en het feit dat zij mij binnengelaten hebben in de ATL gemeenschap. Hun open instelling heeft mij toegelaten om grondig te experimenteren met modeltransformatie en tegelijkertijd mijn inspanningen teruggekoppeld te zien in de ATL (en AM3) software. Ik hoop ook voor de toekomst op een vruchtbare samenwerking. Ik wil graag mijn vrienden, Mark van Benthem, Joost Noppen, Frank Vlaardingerbroek en Tjim Wijering, bedanken voor het feit dat zij contact gehouden hebben nadat ik naar België verhuisd ben. Zelfs na elkaar gedurende lange tijd niet gezien te hebben, ben ik nog niet vergeten. Ik zou graag Joost in het bijzonder bedanken voor het feit dat hij zelfs de tijd heeft gevonden om mijn proefschrift na te lezen. Ik wil graag mijn ouders, André en Paulien, bedanken voor het feit dat zij altijd mijn studie vanaf het begin ondersteund hebben. Zij zagen mij niet graag naar België vertrekken, maar hebben er nooit over geklaagd. Zij hebben daarentegen alle ondersteuning gegeven die zij konden bieden om mijn verblijf in België aangenamer te maken, zodat ik meer aandacht kon besteden aan mijn thesis. Ik wil ook graag Cynthia’s ouders, Philip en Frances, mijn broer Edwin en zijn vrouw Anja, alsook mijn oom Gerard, bedanken voor al hun hulp met ons huis. Als onze familie er niet was, zouden we niet in ons nieuwe huis in Mechelen gewoond hebben.
- 17. Dankwoord xi Tot slot wil ik mijn vriendin Cynthia bedanken dat ze al deze tijd bij me is geweest. We verhuisden samen naar België in 2002 en we hebben hier ook onze gezamenlijke moeilijkheden doorstaan. Samen zijn we erin geslaagd onze plaats in België te vinden. Cynthia heeft mij tijdens deze periode altijd ondersteund en zij hield de vinger aan de pols waar het de voortgang van mijn thesis betrof. Het afronden van dit proefschrift opent onze toekomst voor nieuwe kansen, beginnend in onze nieuwe huis in Mechelen.
- 19. Table of Contents Abstract i Samenvatting iii Acknowledgements vii Dankwoord ix Table of Contents xiii List of Figures xvii List of Tables xxi 1 Introduction 1 1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1.1 Model Driven Architecture . . . . . . . . . . . . . . . . . 3 1.2 Research Objective . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.3.1 Explicit Platform Models . . . . . . . . . . . . . . . . . . 10 1.3.2 Platform-Driven Configuration . . . . . . . . . . . . . . . 12 1.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.5 Dissertation structure . . . . . . . . . . . . . . . . . . . . . . . . 15 2 Model-Driven Architecture 19 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2.1 Computation Independent Models . . . . . . . . . . . . . 22 2.2.2 Platform Independent Models . . . . . . . . . . . . . . . 23 2.2.3 Platform Specific Models . . . . . . . . . . . . . . . . . . 24 xiii
- 20. xiv TABLE OF CONTENTS 2.2.4 Platform Models . . . . . . . . . . . . . . . . . . . . . . 25 2.3 Meta-models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.3.1 Meta Object Facility . . . . . . . . . . . . . . . . . . . . 27 2.3.2 Eclipse Modeling Framework . . . . . . . . . . . . . . . . 30 2.3.3 The role of UML in the MDA . . . . . . . . . . . . . . . 31 2.3.4 Stereotype applications in EMF . . . . . . . . . . . . . . 33 2.4 Model transformation . . . . . . . . . . . . . . . . . . . . . . . . 35 2.4.1 MOF Query/View/Transformation . . . . . . . . . . . . 36 2.4.2 ATLAS Transformation Language . . . . . . . . . . . . . 38 2.4.3 PIM-to-PSM refinements . . . . . . . . . . . . . . . . . . 44 2.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3 Ontologies 49 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.2 Simple named classes . . . . . . . . . . . . . . . . . . . . . . . . 50 3.3 Individuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.4 Simple properties . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.5 Property restrictions . . . . . . . . . . . . . . . . . . . . . . . . 55 3.6 Ontology mapping . . . . . . . . . . . . . . . . . . . . . . . . . 57 3.7 Complex classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4 Platform modelling 61 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.2 Dealing with platform diversity . . . . . . . . . . . . . . . . . . 61 4.3 A platform vocabulary ontology . . . . . . . . . . . . . . . . . . 63 4.4 Extending the platform ontology . . . . . . . . . . . . . . . . . 66 4.4.1 Automatic generation of Java platform ontologies . . . . 70 4.5 Platform instance specifications . . . . . . . . . . . . . . . . . . 71 4.6 Platform dependency constraints . . . . . . . . . . . . . . . . . 71 4.6.1 Classification of platform dependency constraints . . . . 72 4.6.2 Satisfaction of platform dependency constraints . . . . . 74 4.7 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.7.1 Constraint interaction . . . . . . . . . . . . . . . . . . . 75 4.7.2 Performance of determining constraint satisfaction . . . . 76 4.8 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5 Software Product Lines 81 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.2 Commonality and Variability Analysis . . . . . . . . . . . . . . 82 5.3 Feature modelling . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.3.1 Automated analysis . . . . . . . . . . . . . . . . . . . . . 88
- 21. TABLE OF CONTENTS xv 5.4 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.4.1 Configuration language meta-model . . . . . . . . . . . . 90 5.4.2 Configuration models . . . . . . . . . . . . . . . . . . . . 92 5.4.3 Configuration transformation . . . . . . . . . . . . . . . 92 5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 6 Configuration of MDA-based product lines 99 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 6.2 Managing MDA configurations . . . . . . . . . . . . . . . . . . . 100 6.3 Using models for configuration management . . . . . . . . . . . 101 6.3.1 Feature modelling for the MDA . . . . . . . . . . . . . . 101 6.3.2 Configuration DSMLs . . . . . . . . . . . . . . . . . . . 102 6.4 Platform-aware configuration . . . . . . . . . . . . . . . . . . . 105 6.4.1 Profiling against platform instances . . . . . . . . . . . . 107 6.4.2 Platform-driven deployment . . . . . . . . . . . . . . . . 110 6.5 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 6.5.1 Model transformations are not features . . . . . . . . . . 111 6.5.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . 113 6.6 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 6.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 7 Tool support 117 7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 7.2.1 Jar2UML . . . . . . . . . . . . . . . . . . . . . . . . . . 119 7.3 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 7.3.1 Setting up a Model-Driven Software Product Line . . . . 120 7.3.2 Extracting Platform Dependencies of Third-party Com- ponents . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 7.3.3 Modelling Platform Dependencies . . . . . . . . . . . . . 123 7.3.4 Setting up a Platform-Aware Configuration Language . . 131 7.3.5 Platform-Driven Configuration . . . . . . . . . . . . . . . 138 7.3.6 Platform-Driven Deployment . . . . . . . . . . . . . . . . 141 7.4 ATL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 7.4.1 Superimposition . . . . . . . . . . . . . . . . . . . . . . . 149 7.4.2 Modularised meta-models . . . . . . . . . . . . . . . . . 151 7.4.3 Stereotypes as meta-classes . . . . . . . . . . . . . . . . 152 7.4.4 Debugging support for multiple transformation modules/li- braries . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 7.5 Limitations and future work . . . . . . . . . . . . . . . . . . . . 153 7.5.1 Performance and memory usage . . . . . . . . . . . . . . 153 7.5.2 Automatic platform discovery . . . . . . . . . . . . . . . 154 7.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
- 22. xvi TABLE OF CONTENTS 8 Conclusion 157 8.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 8.2 Thesis statement . . . . . . . . . . . . . . . . . . . . . . . . . . 159 8.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 8.3.1 A common platform domain model . . . . . . . . . . . . 159 8.3.2 A method for describing platform dependencies and plat- form instances . . . . . . . . . . . . . . . . . . . . . . . . 160 8.3.3 A framework for platform dependency management . . . 161 8.3.4 A framework for platform-driven optimisation . . . . . . 162 8.3.5 A case study that applies the explicit platform model in an MDA/SPL setting . . . . . . . . . . . . . . . . . . . . 163 8.3.6 Tool support . . . . . . . . . . . . . . . . . . . . . . . . 163 8.4 Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 8.4.1 Generative vs. reflective adaptation . . . . . . . . . . . . 164 8.4.2 Platform modelling language . . . . . . . . . . . . . . . . 166 8.4.3 Scope and reusability of our approach . . . . . . . . . . . 167 8.5 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 8.5.1 Automatic platform discovery . . . . . . . . . . . . . . . 168 8.5.2 Setting up additional platform ontologies . . . . . . . . . 169 8.5.3 In-depth analysis of ATL improvements . . . . . . . . . . 170 8.5.4 Application in other domains . . . . . . . . . . . . . . . 172 A Ontology transformations 175 A.1 UML2ToPackageAPIOntology.atl . . . . . . . . . . . . . . . . . 176 A.2 UML2ToAPIOntology.atl . . . . . . . . . . . . . . . . . . . . . . 177 A.3 UML2Comparison.atl . . . . . . . . . . . . . . . . . . . . . . . . 180 A.4 UML2CompatibilityComparison.atl . . . . . . . . . . . . . . . . 185 A.5 Parallel build script . . . . . . . . . . . . . . . . . . . . . . . . . 186 B ConstraintSet sorting algorithm 191 B.1 TreeSorter.java . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 B.2 HierarchyComparator.java . . . . . . . . . . . . . . . . . . . . . 193 C Example index page for PlatformKit deployment 195 C.1 index.html . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Bibliography 199 Index 208
- 23. List of Figures 1.1 MDA pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Model transformation pattern . . . . . . . . . . . . . . . . . . . 5 1.3 MDA practise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 Alternative MDA practise . . . . . . . . . . . . . . . . . . . . . 6 1.5 MDA improved . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.6 Integrating platform dependencies . . . . . . . . . . . . . . . . . 8 1.7 Example platform dependency . . . . . . . . . . . . . . . . . . . 10 1.8 Platform model overview . . . . . . . . . . . . . . . . . . . . . . 11 1.9 (a) Software product line configurator and (b) MDA configurator 12 1.10 Software product line generator transformation . . . . . . . . . 13 1.11 Dissertation structure overview . . . . . . . . . . . . . . . . . . 16 2.1 Impact of MDA on the development process (source: [KWB03]). 21 2.2 A screenshot of an instant messaging client running on a PC. . . 23 2.3 A UML Class diagram of the instant messaging client CIM. . . . 24 2.4 A UML Class diagram showing part of the instant messaging client PIM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.5 A UML Class diagram showing part of the instant messaging client PSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.6 The 4-level OMG meta-modelling framework. . . . . . . . . . . 27 2.7 EMOF meta-model part for MOF Classes (source: [OMG06b]). . 28 2.8 Root diagram of the UML Kernel package (source: [OMG05c]). . 29 2.9 A simplified subset of the Ecore meta-model (source: [BSM+ 03]). 30 2.10 A screenshot of the Ecore editor. . . . . . . . . . . . . . . . . . 31 2.11 Applet Stereotype applied to a UML Class. . . . . . . . . . . . . 32 2.12 UML meta-model part for Profiles (source: [OMG05c]). . . . . . 32 2.13 The Applet Profile. . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.14 Eclipse UML2 and Ecore share the common notion of EAnno- tations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 xvii
- 24. xviii LIST OF FIGURES 2.15 A screenshot of the Eclipse UML2 editor after the Applet profile was “defined”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.16 Object diagram of the Applet stereotype applied to the Instant- MessagingClient class. . . . . . . . . . . . . . . . . . . . . . . . 35 2.17 Relationships between QVT meta-models (source: [OMG05a]). . 36 2.18 ATL superimposition example. . . . . . . . . . . . . . . . . . . . 43 3.1 An example classification of wine-related concepts in OWL. . . . 51 3.2 Some example OWL individuals in the wine domain. . . . . . . 51 3.3 An example OWL property in the wine domain. . . . . . . . . . 53 3.4 An example of an OWL subproperty and a transitive property. . 54 3.5 Example of symmetric, functional and inverse properties. . . . . 54 3.6 Example of “allValuesFrom” and “someValuesFrom” property restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.7 Example of a “hasValue” property restriction. . . . . . . . . . . 57 3.8 Example of equivalence. . . . . . . . . . . . . . . . . . . . . . . 57 3.9 Example of identity. . . . . . . . . . . . . . . . . . . . . . . . . 58 3.10 Example of “intersectionOf”. . . . . . . . . . . . . . . . . . . . 59 3.11 Example of “unionOf”. . . . . . . . . . . . . . . . . . . . . . . . 59 4.1 Partial view of the base platform ontology . . . . . . . . . . . . 64 4.2 Partial view of an ontology for describing Java runtime environ- ments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.3 Partial view of an ontology for describing the J2ME Personal Profile 1.0 specification . . . . . . . . . . . . . . . . . . . . . . . 69 4.4 Partial platform description for the Sharp Zaurus SL-C1000 PDA 71 5.1 A UML Class diagram showing part of the instant messenger model for the Jabber feature. . . . . . . . . . . . . . . . . . . . 85 5.2 The feature model of the instant messenger product line. . . . . 86 5.3 The feature model of the instant messenger product line. . . . . 87 5.4 The meta-model of the instant messenger configuration language. 91 5.5 An example instant messenger configuration model as displayed by the EMF model editor. . . . . . . . . . . . . . . . . . . . . . 92 6.1 The extended feature model of the instant messenger product line. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 6.2 The feature model of the TransformationConfig feature. . . . . . 103 6.3 The meta-model of the instant messenger configuration language.104 6.4 The meta-model for PlatformKit models. . . . . . . . . . . . . . 107 6.5 Flowchart of the platform profiling scenario . . . . . . . . . . . 108 6.6 The PlatformKit model for the instant messenger configuration language. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 6.7 Flowchart of the deployment scenario . . . . . . . . . . . . . . . 110
- 25. LIST OF FIGURES xix 6.8 The PlatformKit model for the instant messenger product con- figurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 7.1 PlatformKit architectural overview . . . . . . . . . . . . . . . . 118 7.2 Jar2UML architectural overview . . . . . . . . . . . . . . . . . . 120 7.3 Jar2UML Dependency Import . . . . . . . . . . . . . . . . . . . 122 7.4 Importing the MicroJabberWookie.jar file . . . . . . . . . . . . . 123 7.5 Determine compatibility . . . . . . . . . . . . . . . . . . . . . . 124 7.6 Compatibility report . . . . . . . . . . . . . . . . . . . . . . . . 125 7.7 New Protégé project kind . . . . . . . . . . . . . . . . . . . . . 126 7.8 New Protégé project URI . . . . . . . . . . . . . . . . . . . . . 127 7.9 New Protégé project language profile . . . . . . . . . . . . . . . 127 7.10 Importing an ontology into Protégé . . . . . . . . . . . . . . . . 128 7.11 Import an ontology from a repository . . . . . . . . . . . . . . . 129 7.12 Add a new ontology repository . . . . . . . . . . . . . . . . . . . 130 7.13 Select repository type . . . . . . . . . . . . . . . . . . . . . . . . 131 7.14 Create new repository . . . . . . . . . . . . . . . . . . . . . . . 132 7.15 Select ontology to import . . . . . . . . . . . . . . . . . . . . . . 133 7.16 Review the added ontology prefixes . . . . . . . . . . . . . . . . 133 7.17 Adding a restriction to a JRE . . . . . . . . . . . . . . . . . . . 134 7.18 Description of BasicJRE . . . . . . . . . . . . . . . . . . . . . . 135 7.19 Description of InstantMessengerPlatform . . . . . . . . . . . . . 136 7.20 Compatibility report . . . . . . . . . . . . . . . . . . . . . . . . 137 7.21 Adding a product line meta-model . . . . . . . . . . . . . . . . 138 7.22 Selecting product line meta-models . . . . . . . . . . . . . . . . 139 7.23 Classify taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . 140 7.24 Extra URI mappings for EMF plugins . . . . . . . . . . . . . . 141 7.25 New child options for instant messenger configuration . . . . . . 142 7.26 Profile against concrete platform . . . . . . . . . . . . . . . . . . 143 7.27 Select a platform specification to profile against . . . . . . . . . 144 7.28 Profiled new child options for instant messenger configuration . 145 7.29 Validation result of an instant messenger configuration . . . . . 146 7.30 Adding a product configuration model . . . . . . . . . . . . . . 147 7.31 Selecting product line configuration models . . . . . . . . . . . . 148 7.32 The ordered Platformkit Model for instant messenger deployment148 7.33 Classify taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . 149 7.34 Select a platform specification to validate against . . . . . . . . 150 7.35 Validate result . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 7.36 Deployment folder for the instant messenger product line . . . . 151
- 27. List of Tables 2.1 Available model transformations . . . . . . . . . . . . . . . . . . 45 6.1 Configuration language meta-model annotations . . . . . . . . . 106 xxi
- 29. Chapter 1 Introduction 1.1 Problem Statement Today’s software systems not only continue to grow more complex, but they are often required to run on multiple platforms as well. By platform, we re- fer to the hardware and software combination on top of which our software runs. Common personal computer platforms are Microsoft Windows, Linux and Apple Mac OS X on a PowerPC or x86 hardware architecture. Hand-held devices present another range of platforms, such as Microsoft Windows Mobile, Qtopia/Embedix and Symbian running on an ARM or RISC hardware archi- tecture. Each of these platforms looks different from a software developer’s point of view and requires the development of different software versions for each platform. In the face of this platform diversity, it becomes increasingly difficult to maintain software that is portable to multiple platforms. Software developers not only have to develop multiple software versions, but they also have to keep these versions synchronised and consistent in their common functionality. Let’s take Skype as an example, where the software developers have failed at keeping the functionality of their Windows, Mac and Linux versions in sync. The Windows version has all the latest features and, whereas the Mac version at least supports webcam, the Linux version has really fallen behind in the amount of provided features. Skype for Linux comes without webcam support and the developers are still working on a stable audio subsystem. The way that audio is accessed on Windows, Mac and Linux platforms is already so different, that there is no time left to address the differences in webcam access. The Skype developers are still far braver than others, since most software developers take the easy way out: they develop for one platform only. The problem is then simply passed on to the users who have to choose between platform X or Y, after which they are effectively locked into that platform. Even if we look at a technology like Java, which was meant to overcome 1
- 30. 2 Chapter 1. Introduction platform differences (“Write Once, Run Anywhere”), we find that multiple Java versions exist today. Each of these Java versions are tailored towards specific usage scenarios and computing devices. To name a few: J2SE is the standard edition that is meant for desktop and laptop computers, J2EE is the enterprise edition that is meant for running server-side applications and J2ME is the mobile edition that is meant for resource-constrained and mobile devices. J2ME in turn is split up in separate versions for mobile phones, called Mobile Information Device Profile (MIDP)1 , and for PDAs, called Personal Profile (PP)2 . The main difference between these Java versions lies in the libraries that make up the application programming interface (API). The API of J2ME MIDP for mobile phones is typically a stripped down version of the standard J2SE API. Functionality that is resource intensive and functionality that is not provided by the underlying platform is taken out of the API. New API elements are also added to J2ME MIDP to support functionality that is only relevant for mobile devices. Java reflection and the TCP/IP networking layer, for ex- ample, have been stripped from J2ME MIDP; Java reflection is too resource intensive and the TCP/IP networking layer is not (completely) available in the underlying operating system. In return, a special J2ME networking layer that can deal with limited TCP/IP networking has been added. In addition to this, platform technologies tend to evolve. This evolution may involve just extending the API, but it can also involve an update of the programming language itself. In the case of Java, the language specification has been extended in J2SE 1.4 with assertions [GJJB00] and in J2SE 5 with generics and annotations [GJJB05]. When developing software for an evolving platform, software developers have to take into account that the users may use older versions of the platform. Developers may be confronted with the fact that their software is no longer compatible with an older version of the platform, because they do all their development and testing on the latest version of the platform. If the current range of platforms can already be considered diverse, the vision of Ambient Intelligence, put forward by the Information Society Tech- nologies Advisory Group (ISTAG) [DBS+ 01], only amplifies this diversity. Am- bient Intelligence, or AmI , aims for a user-driven, service-based computing en- vironment that includes personal devices as well as special-purpose embedded devices in the environment. The hardware and software combinations in such devices can vary widely3 . It is also in such personal devices that another limi- tation of Java becomes apparent: the scope of Java as a platform abstraction layer is no longer complete. Deployment methods not only vary between dif- 1 http://java.sun.com/products/midp/ 2 http://java.sun.com/products/personalprofile/ 3 http://www.comp.nus.edu.sg/∼damithch/df/device-fragmentation.htm
- 31. 1.1 Problem Statement 3 ferent PDAs and mobile phones, but also between different network operators for the same mobile phone. We have discussed how the Java technology often falls short in solving the platform diversity problem. Java is an example of a platform abstraction layer based on a virtual machine, where the software that runs on top of Java doesn’t know about the details of the underlying platform. Other kinds of platform abstraction layers are script interpreters, standard libraries and frameworks. Regardless of the kind of abstraction layer, an abstraction layer solution to platform diversity will always be limited in the way that we have described for the Java technology. The causes of these limitations can be summarised as follows: • Unreconcilable differences in underlying platform. • Evolution of the platform abstraction layer. • Scope of the platform abstraction layer. In contrast to platform abstraction layers, which form an adapter between the software and the underlying platform, are solutions that adapt the soft- ware itself to the target platform. These solutions range from generative ap- proaches that transform the software beforehand to reflective approaches that will react to platform differences at run-time. Each of these approaches have strengths and weaknesses. Generative approaches typically can’t deal with post-deployment changes in the platform. Reflective approaches inevitably have some overhead in doing run-time platform checks and providing code that may never be executed on the target platform. In this dissertation, we will focus on a generative approach. We will discuss in chapter 8 how our thesis relates to reflective approaches. The Object Management Group has acknowledged the problem of platform diversity by introducing the Model Driven Architecture (MDA). The MDA allows for “separating the specification of the operation of a system from the details of the way that system uses the capabilities of its platform.” [MM03] and is centred around the use of software models. The software models provide a means to create partial, platform-independent software specifications that make use of platform abstractions. These abstractions are refined to platform- specific specifications in a later stage of the development lifecycle. The next subsection discusses the MDA in more detail. 1.1.1 Model Driven Architecture The Model Driven Architecture is based on a pattern in which a Platform Independent Model (PIM) is transformed to a Platform Specific Model (PSM) (see also Fig. 1.1). The software is initially modelled in a PIM, which only
- 32. 4 Chapter 1. Introduction contains elements that are common to all targeted platforms. A PIM often uses high-level abstractions that are later refined to an implementation in the PSM. This PIM-to-PSM refinement takes the form of model transformation in the MDA. This transformation step can take additional input. Fig. 1.1 shows this extra input as a question mark to emphasise that no special requirements exist for this extra input. The MDA suggests that this extra input can be in the form of a Platform Model (PM). In the MDA, there can be multiple PIM- to-PSM transformation steps, as each PSM can serve as a PIM at a lower level of abstraction. The chain of PIM-to-PSM transformations usually terminates with a transformation to executable code. PIM ? PSM Transformation Figure 1.1: MDA pattern Model transformations use meta-models as an additional input, as shown in Fig. 1.2. A meta-model describes the types of elements that can occur in a model through meta-classes. “Class”, “Operation” and “UseCase”, for example, are UML meta-classes. Instances of those meta-classes can occur in UML models. Meta-classes are similar to normal, object-oriented classes in that they can inherit from each other and they can have properties. A model conforms to a meta-model if it correctly uses the meta-classes described by that meta-model. The input meta-model in Fig. 1.2 provides a hierarchy of meta-classes that tells the model transformation when to trigger on a source element. The output meta-model provides the model transformation with the rules that the output model should follow. In current MDA practise, most PIMs are transformed directly to PSMs, without using any extra input such as a platform model (see also Fig. 1.3). Tools like AndroMDA4 and ArcStyler5 , for example, use the notion of car- tridges to represent a particular PIM-to-PSM transformation. The model transformations implicitly assume a platform. This makes it much easier to write model transformations, since one only has to deal with the limited scope 4 http://www.andromda.org/ 5 http://www.arcstyler.com/
- 33. 1.1 Problem Statement 5 Model Transformation Input Model Input Meta-Model Output Model Output Meta-Model conforms to conforms to Figure 1.2: Model transformation pattern of targeting a single, assumed platform. It is unclear, however, whether a model transformation can be used for other platforms than the one for which it was written. The only safe assumption is that each targeted platform requires its own dedicated set of model transformations. PIM ? PSM1 Transformation1 Transformation2 Transformation3 PSM2 PSM3 Figure 1.3: MDA practise Another approach to MDA that applied often is shown in Fig. 1.4. In this approach, the PIM is absent and one PSM serves as the input for transforma- tions that generate other PSMs. This PSM-to-PSM approach occurs mostly in situations where one has to translate from one language/technology to an- other, such as translating from Rational Rose to UML2 Tools and from UML to OWL6 , but also to translate from one Java API to another [CDZ04]. In reality, this means that only a relatively small number of “general” platforms can be targeted, such as Java. As has been explained before, Java is actually a family of platforms, ranging from J2ME to J2EE. On top of this generalisation, specific platform assumptions are often made. In the case of the 6 http://www.eclipse.org/m2m/atl/usecases/
- 34. 6 Chapter 1. Introduction PSM1 Transformation2 Transformation3 PSM2 PSM3 Figure 1.4: Alternative MDA practise Java platform family, there is not enough commonality between the different Java versions to come up with a complete platform to build on. For example, the API for graphical user interfaces (GUIs) is radically different on the mobile phone J2ME MIDP than it is on the standard J2SE; there is no common Java API for GUIs. For the purpose of targeting a “complete” platform, an assumption for a specific GUI library is made, thereby reducing the number of supported Java platforms. This way of “streamlining” the PIM-to-PSM transformations to a single, assumed Java platform is used a lot to escape the problem of maintaining model transformations for multiple platforms. When we look at the nature of PIM-to-PSM transformations directly, it becomes clear that the single Java platform approach is a very bad solution indeed. Most of these transformations consist of several smaller refinement steps that, when considered individually, are reusable over multiple platforms. It is only the combination of refinement steps that limits their applicability to one specific platform. For example, one refinement step could target all Java 2 platforms by transforming the types of UML Properties [OMG05c] with a multiplicity greater than one to the Java 2 Collections framework. The Java 2 Collections framework is included in several Java platforms, including J2ME Personal Profile and J2SE. If this refinement step is applied in combination with a refinement step that targets the Java Swing graphical user interface framework, the target platform is already limited to J2SE. In order to reuse individual refinement steps that occur in a transformation, each refinement step must be modularised in its own model transformation. One can then reuse those refinement transformations in different transformation configurations, as is done in Stepwise Refinement [BSR04]. If the PIM-to-PSM transformations are split up in multiple, step-wise re- finement transformations, then the bulk of the maintenance problem moves to the transformation configuration. Software developers must keep track of which refinement transformations must be applied to target a specific plat-
- 35. 1.1 Problem Statement 7 form, and in which order they must be applied. An increasing number of MDA practitioners apply workflow scripts to specify which PIM-to-PSM re- finement transformations they want to apply and in which order78 . Such a workflow script can take the form of an Ant build script9 , which is a Makefile equivalent for Java. The MDA picture then changes to what is shown in Fig. 1.5. Each con- figuration of refinement transformations is represented by a separate build script. The execution of the build scripts results in a separate PSM for each of those build scripts. Refinement transformations can now be reused in multiple configurations, targeting multiple platforms. While these separate refinement transformations lay the basis for lifting the platform maintenance burden, they do not solve our initial problem. It is still unclear whether a refinement trans- formation can be used for other platforms than the one for which it was written, since all platform dependencies are still implicit. PIM PSM1 UML2Accessors UML2Observer UML2Applet ... Transformations Refinement Transformations executes selection of Build script1 ___________ _________ _________ ___________ PSM2 PSM3 Figure 1.5: MDA improved As the software developer puts the build script together that executes the refinement transformations, most of the effort goes into checking that (1) the refinement transformations work together and that (2) they are executed in the right order [MTR05]. It is an extra burden to also (3) consider the platform dependencies that each refinement transformation introduces. One approach is to test the generated software on the target platform to tell if the software works on that platform. Testing on each platform is a time-consuming activity, however, and may even leave certain incompatibilities undetected until after 7 http://www.openarchitectureware.org/ 8 http://wiki.eclipse.org/Modeling Workflow Engine (MWE) 9 http://wiki.eclipse.org/index.php/AM3 Ant Tasks
- 36. 8 Chapter 1. Introduction deployment. Another approach is to use an automated configuration process that enforces the satisfaction of constraints, including platform dependency constraints. Such a configuration process does not exist for the MDA today. 1.2 Research Objective The problem of platform diversity is a very broad one. Solutions to the problem range from standard libraries that offer a unified API, such as the C standard library10 , to virtual machines that offer a unified binary format, such as the Java virtual machine. As we have previously illustrated, these abstraction layer solutions often fall short of solving the platform diversity problem. The MDA offers solutions for dealing with platform diversity. It achieves this by abstracting from specific platforms in the PIM, followed by – alternative – transformations that refine the PIM into a PSM. The MDA suggests that multiple, step-wise refinement transformations are used to generate a PSM. These refinement transformations are often reusable over multiple platforms. We don’t know, however, when we can – and when we cannot – reuse a PIM-to-PSM refinement transformation for another platform than the one for which it was written. Each refinement transformation typically introduces certain platform dependencies in the PSM, but these platform dependencies remain implicit to this day (see Fig. 1.6). It is our objective to make these platform dependencies explicit, so that we may reason about them. We plan to achieve this objective in several stages: PIM PSM1 UML2Accessors UML2Observer UML2Applet ... Transformations Refinement Transformations executes selection of Build script1 ___________ _________ _________ ___________ PSM2 PSM3 Configures? Platform dependencies? Figure 1.6: Integrating platform dependencies 10 http://en.wikipedia.org/wiki/C standard library
- 37. 1.2 Research Objective 9 • Build a body of explicit domain knowledge that describes what a platform is and extend this domain knowledge for the family of Java platforms. • Develop a method to describe platform instances based on this platform domain knowledge. • Develop a method to describe platform dependencies based on this plat- form domain knowledge. Descriptions of platform dependencies must remain valid even if the targeted platforms evolve. • Develop a method to check whether platform dependencies are satisfied by platform instances. Explicit platform dependencies are only useful if they can be enforced dur- ing the configuration of PIM-to-PSM refinement transformations, as shown in Fig. 1.6. As the MDA offers no process for the configuration of step-wise PIM-to-PSM refinement transformations, our second objective is to introduce a configuration process with automated support for platform dependencies. This must result in a framework for managing platform dependencies for the MDA that: • improves the maintainability of a PIM-to-PSM transformation configu- ration by enabling safe reuse of individual refinement transformations in such a configuration, • assists in finding the most appropriate PIM-to-PSM transformation for a specific platform from a number of alternatives, • integrates with existing software development technologies, in particular the software development technologies that target Java platforms. The thesis statement of this dissertation can be summarised as: In order to deal with platform diversity, we believe that (1) plat- form domain knowledge must be made explicit. By making this knowledge explicit, we can (2) reason about the extent of platform dependencies with regard to platform instances as well as (3) compare appropriateness of alternative refinement transformations and (4) enforce a safe configuration of re- finement transformations via their introduced platform de- pendencies.
- 38. 10 Chapter 1. Introduction 1.3 Approach 1.3.1 Explicit Platform Models We propose to use an explicit platform model, which serves as an ontology for describing platforms. This ontology is used as a basis to express platform in- stances as well as platform dependencies. By explicitly specifying the platform dependencies for each reusable model transformation, each transformation can be guaranteed as valid for a well-defined class of platforms. Because platform instances use the same platform model as an ontology, the platform model enables us to determine which platforms satisfy which platform dependencies. It is expressed in the Web Ontology Language (OWL) [SWM04], which is an extensible language for describing ontologies. Ontologies are commonly used to represent domain knowledge and to provide a community of users with a controlled vocabulary. We use the OWL DL variant, which corresponds to description logic (DL) [BCM+ 03] and allows us to apply automatic reasoning. We represent platform dependencies in OWL as classes. The representation of a platform dependency is called a platform dependency constraint. Consider, for example, the “JavaAWTPlatform” platform dependency constraint shown in Fig. 1.7. Platform JavaAWTPlatform isa = necessary ≡ ∃ providesSoftware JavaAWTLibrary = necessary-and-sufficient Figure 1.7: Example platform dependency “JavaAWTPlatform” is represented as an OWL class with a necessary con- straint as well as a necessary-and-sufficient constraint. Whereas it is necessary that each “JavaAWTPlatform” is a “Platform”, being a “Platform” is not suffi- cient for also being a “JavaAWTPlatform”. Providing the “JavaAWTLibrary” software, however, is necessary-and-sufficient for being a “JavaAWTPlatform”. The “JavaAWTPlatform” constraint can be checked against OWL instances that represent platform instances. Each OWL instance – or individual – that satisfies the conditions of the “JavaAWTPlatform” class can be considered as an instance of that class. Each platform instance representation that is an in- stance of a platform dependency constraint, satisfies that platform dependency constraint. Our platform model is not monolithic, but is divided into a hierarchy of modules. Fig. 1.8 shows how the platform model is organised. The central part of the platform model is made up of several “vocabulary ontologies”,
- 39. 1.3 Approach 11 where the word “vocabulary” refers to the fact that the domain concepts are all introduced in these ontologies. The main Platform vocabulary ontology describes the general concept of Platform and its parts. The Java vocabulary ontology extends the Platform ontology for the domain of Java platforms. The Java platform ontology is in turn extended by several vocabulary ontologies that describe concrete Java variants: JDK 1.1, J2SE 1.2, J2ME PP 1.0, etc. Platform dependency constraints are expressed in terms of these vocabulary ontologies, while they are stored in a separate OWL ontology. This separate OWL ontology is not considered to be a vocabulary, since it expresses only platform dependency constraints rather than platform domain concepts. Platform vocabulary ontology Java vocabulary ontology JDK 1.1 vocabulary ontology J2SE 1.2 vocabulary ontology J2ME PP 1.0 vocabulary ontology Platform constraint ontology Platform instance ontology Figure 1.8: Platform model overview Platform instances are also modelled as a separate OWL ontology and refer to the same platform vocabulary ontologies as the platform dependency con- straints. An automatic DL reasoner, such as Racer [MH03], can be used to ver- ify whether a platform instance satisfies the platform dependency constraints of a model transformation. In addition, it can determine which platform de- pendency constraint is most specific and hence forms the closest match to a platform instance. This allows for optimisation towards a platform instance by automatically selecting the optimal transformations for a given platform. The explicit platform dependency constraints for each model transforma- tion also make it possible to automatically derive the overall platform con- straints for a configuration of transformations. This allows us to verify which build script (see Fig. 1.5) is most-specific and valid for a given platform. What is left is the integration of our platform model with a configuration approach for the MDA. That way, we can leverage the platform dependency information during the configuration process.
- 40. 12 Chapter 1. Introduction 1.3.2 Platform-Driven Configuration Configuration is a complex topic that has already been widely researched. Within the field of software engineering, most research on configuration has been conducted by the Software Product Line (SPL) [CN01] community. SPLs are concerned with leveraging the commonalities between related software products. They integrate a number of software-intensive products that share a significant amount of functionality. As such, any software that is developed using the MDA approach can be considered as an SPL, since each platform- specific software product shares significant functionality with other platform- specific versions of that software product. This shared functionality is typically specified in the PIM. In [Bos06], Bosch also argues that SPLs have been espe- cially successful in the area of mobile and embedded devices, in which platform diversity is the rule rather than the exception. This relationship between the MDA and SPLs allows us to build on the configuration technology used in SPLs for the configuration of our PIM-to-PSM refinement transformations. When- ever the MDA and SPL technology are used in combination, we will speak of MDA-based SPLs. In contemporary SPL practise, the principles of SPLs have been extrapo- lated to shift the bulk of the engineering effort to the product line’s reusable assets [Kru06]. The effort for deriving software products from these assets is reduced to creating a Product Model that contains all configuration informa- tion for that product. The product line’s infrastructure includes a generator (“SPL Configurator”) that generates the product’s implementation from the Product Model, as shown in Fig. 1.9a. In Generative Programming [CE00], Product Models are often expressed in terms of a Domain-Specific Language (DSL) – or a Domain-Specific Modelling Language (DSML) [LBM+ 01][TR03]. DSMLs are a specific kind of DSL that use meta-models as a language defi- nition formalism. We have explained previously how PIMs and PSMs in the MDA also have meta-models, which are used by the PIM-to-PSM refinement transformations. SPL Configurator Variation Points Core Asset N Variation Points Core Asset N Variation Points Core Asset N Product Models Product A Product B Product M MDA Configurator Refinement Transformations Configuration Models Build script A Build script B Build script M Figure 1.9: (a) Software product line configurator and (b) MDA configurator
- 41. 1.3 Approach 13 In the MDA world, the DSML for Product Models can take the form of a configuration language that can express configurations of PIM-to-PSM re- finement transformations. The “SPL Configurator” part of the SPL’s infras- tructure (see Fig. 1.9a) is normally used to generate the SPL’s products, but it can also be used to generate the build script that was shown in Fig. 1.6. The SPL pattern then changes to what is shown in Fig. 1.9b. A number of refinement transformations are selected in a configuration model. The “MDA Configurator” then takes these configuration models as input and generates build scripts that invoke the selected refinement transformations. The “MDA Configurator” itself can be implemented as a model transfor- mation, as shown in Fig. 1.10, provided that we have a meta-model for our configuration language as well as our build script language. We can even use the same model transformation technology for PIM-to-PSM refinement trans- formations and the “configuration-to-build-script” transformation. Model Transformation Configuration Model Configuration Language Meta-Model Script Language Meta-Model conforms to conforms to Build script ___________ _________ _________ ___________ Figure 1.10: Software product line generator transformation In order to integrate our platform models into a software development pro- cess based on MDA and SPL, we propose to represent all product configuration rules – including alternative model transformations – inside a configuration lan- guage meta-model. Several meta-classes in this meta-model are then annotated with references to platform dependency constraints. The annotated configura- tion language meta-model can be used to determine the platform dependency constraints of each configuration model.
- 42. 14 Chapter 1. Introduction 1.4 Contributions • A common platform domain model We present how OWL-DL can be used to define a general plat- form model that serves as a common ontology for specific plat- form sub-domains. This work has been presented in [PVW+ 04], [Wag05] and [WJ05]. We also present how the general plat- form model can be extended for the platform sub-domain of Java Runtime Environments (JREs). This work has been presented in [Wag05], [WJ05] and [WV07]. • A method for describing platform dependencies and platform instances We present how platform dependency constraints and platform instances can be described, based on the common platform model and extensions. The platform dependencies can be compared against platform instances to check if they are satisfied. In addition, we can determine which platform dependencies are more specific than other platform dependencies and form a closer match to the targeted platform. This work has been presented in [Wag05], [WJ05] and [WV07]. • A framework for platform dependency management We present how the platform model can be integrated in a soft- ware development process based on the MDA and SPLs. The relationship between the MDA and SPLs is explored as part of this work and a common configuration approach based on DSMLs is used. This work has been presented in [WV06] and [WV07]. • A framework for platform-driven optimisation We present how platform dependencies can be used as the basis for selecting optimal model transformations (or SPL features). In addition, we present how this can be extrapolated for the selection of optimal configurations. This work has been described in [Wag05], [WJ05] and [WV07].
- 43. 1.5 Dissertation structure 15 • A case study that applies the explicit platform model in an MDA/SPL setting We have developed a non-trivial case study of a cross-platform Instant Messaging client that demonstrates the merits and lim- itations of our approach. The case study is available at http: //ssel.vub.ac.be/ssel/research:mdd:casestudies and is used in [Wag05], [WJ05] and [WV07]. • Tool support We have developed a tool, named PlatformKit, that implements platform dependency management and platform-driven optimisa- tion based on the Eclipse Modeling Framework (EMF) [BSM+ 03]. The PlatformKit tool is available at http://ssel.vub.ac.be/ ssel/research:mdd:platformkit and is described in [WV07]. In addition, we have developed the Jar2UML tool that reverse en- gineers Java class libaries to UML models. Those UML models are used by PlatformKit to determine compatibility between dif- ferent Java platforms. Jar2UML is available at http://ssel. vub.ac.be/ssel/research:mdd:jar2uml. Finally, we have added several improvements to the ATLAS Transformation Language tool for the purpose of our case study. Those improvements have been integrated back into the main ATL code, which is available at http://www.eclipse.org/m2m/atl. One of the ATL improve- ments, module superimposition, is described in [Wag08]. 1.5 Dissertation structure Fig. 1.11 shows an overview of the structure of this dissertation. Following this chapter, a background chapter on the Model-Driven Architecture and a back- ground chapter on ontologies provide the basis for our approach to platform modelling. The next chapter discusses our platform modelling approach itself. This is followed by a background chapter on Software Product Lines that pro- vides the basis for our MDA configuration approach. Our MDA configuration approach itself is discussed in the subsequent chapter. The next chapter dis- cusses our tool support and the final chapter discusses the conclusions of this dissertation. We will now give a detailed description of each chapter. Chapter 2: Model-Driven Architecture This chapter gives an in-depth explanation of the MDA. The main concepts of the MDA, such as model,
- 44. 16 Chapter 1. Introduction Contribution Background Chapter 2: Model-Driven Architecture Chapter 3: Ontologies Chapter 4: Platform modelling Chapter 5: Software Product Lines Chapter 6: Configuration of MDA- based product lines Chapter 7: Tool support Chapter 8: Conclusion Chapter 1: Introduction Figure 1.11: Dissertation structure overview meta-model and model transformation, are discussed in detail. The dif- ferent roles that models play within the MDA framework are discussed: Computation Independent Model (CIM), Platform Independent Model (PIM), Platform Specific Model (PSM) and Platform Model (PM). Meta- models are discussed as a technical grounding for the definition of mod- elling languages. The Meta Object Facility (MOF), which is a standard meta-modelling language, is discussed in particular. In addition, the Eclipse Modeling Framework is discussed, which is a meta-modelling framework that is derived from MOF. The special position of UML stereotypes within the MDA is also discussed, as they are partly situated at the meta-model level. Finally, model transformations are discussed. The standard MOF Query/View/Transformation (QVT) language is dis- cussed, as well as the ATLAS Transformation Language (ATL), which is a QVT predecessor. Examples are given of PIM-to-PSM transformations written in ATL. Chapter 3: Ontologies In this chapter, we explain what ontologies are. The OWL ontology language is discussed in detail, as it forms the technical basis for our platform model. Each relevant OWL language construct is explained in detail. The consequences of using a particular OWL con- struct for logic inference are discussed. Throughout the chapter, several pitfalls of using OWL are identified and their theoretical basis is given. Together with the previous chapter, this chapter forms the background for the first half of this dissertation. Chapter 4: Platform modelling The previous two chapters have discussed
- 45. 1.5 Dissertation structure 17 sufficient background information to explain the workings and use of our platform model. This chapter starts with a motivation of the need for explicit platform models. Platform ontologies are presented as a so- lution for safe PIM-to-PSM transformation reuse as well as a solution for decoupling platform dependency constraints from platform instance descriptions. A common vocabulary for describing platforms is then in- troduced, as well as an extension of this common vocabulary for the domain of Java platforms. As the domain of Java platforms must be described in a rather large and detailed ontology to be of any practical use, an approach is presented for automatic generation of such ontolo- gies. The automatic generation of ontologies ensures that the platform vocabulary can be kept up to date with new Java platforms. The chap- ter then goes on to discuss platform instance specifications as well as platform dependency constraints. The platform dependency constraints can be classified in a hierarchy and constraint satisfaction can be checked against platform instances. Finally, the limitations of our platform mod- elling approach are discussed. This chapter also concludes the first half of this dissertation. Chapter 5: Software Product Lines The second half of this dissertation starts with an in-depth explanation of SPLs – a mode of software develop- ment that includes the MDA. The different stages in SPL development are discussed: Commonality and Variability Analysis (CVA), Feature Modelling (FM) and Configuration. As SPL Configuration is the most interesting part for our purposes, this topic is discussed in most detail. A configuration approach using Domain-Specific Modelling Languages (DSMLs) is presented in particular, as it connects best to MDA-based product lines. Chapter 6: Configuration of MDA-based product lines The previous chapter lays the groundwork for this chapter, in which an integrated configuration approach for MDA-based SPLs is presented. This chap- ter starts with a discussion of interaction problems between PIM-to- PSM transformations. The similarity with feature interactions in SPLs is shown and justifies the application of SPL solutions to the MDA. The difference between interaction constraints and platform dependency con- straints is also discussed, showing the need to integrate platform depen- dency constraints. An integration of platform constraints with domain- specific configuration languages is presented. We then show how this integration can be done in a loosely coupled way by using an intermedi- ate “shadow” model. This “shadow” model can be used in two different scenarios and allows the processes of these scenarios to remain very sim- ilar (reuse of sub-processes). Finally, the limitations of our configuration
- 46. 18 Chapter 1. Introduction approach are discussed. Chapter 7: Tool support This chapter adds practise to our theory by pro- viding an in-depth discussion of our PlatformKit tool and how it can be used to support several platform modelling and configuration scenarios. First, the architecture of PlatformKit is explained. All components on top of which PlatformKit is built are discussed here. Following that, a number of tasks that are supported by PlatformKit are discussed. These tasks range from setting up an MDA-based SPL to platform-driven de- ployment of software products. Finally, the limitations and future direc- tions of PlatformKit are discussed. Chapter 8: Conclusion This chapter concludes this dissertation with an evaluation of the approach we have presented. An overview of our con- tributions is given and future research directions are explored.
- 47. Chapter 2 Model-Driven Architecture 2.1 Introduction The Model-Driven Architecture (MDA) was introduced by the Object Man- agement Group (OMG) as an approach to use models in software development. Its goals are portability, interoperability and reusability through architectural separation of concerns. MDA intends to provide an approach for: • “specifying a system independently of the platform that supports it, • specifying platforms, • choosing a particular platform for the system, and • transforming the system specification into one for a particular plat- form.” [MM03] The terms platform and platform independence are used extensively in MDA. The MDA Guide defines a platform as follows: “A platform is a set of subsystems and technologies that provide a coherent set of functionality through interfaces and specified usage patterns, which any application supported by that platform can use without concern for the details of how the functionality provided by the platform is implemented.” [MM03] This definition introduces the notion of interfaces and usage patterns. It also positions a platform as an abstraction layer that can be used without knowing how platform functionality is provided. We have previously defined 19
- 48. 20 Chapter 2. Model-Driven Architecture a platform as the hardware and software combination on top of which our software runs, which is a broader definition of platform. Platform independence refers to the quality of being independent of the fea- tures of a platform and is a matter of degree. A common technique for achiev- ing platform independence is to target a technology-neutral virtual machine. A virtual machine can also be considered a platform. Any model targeting that virtual machine is considered specific to that platform, but independent of any underlying platform. When specifying a system in a platform-independent way, one already needs to have an idea of which platforms are targeted [TBA04]. The system’s specification is independent of all these platforms if it only de- pends on features that are common for all platforms – or can be mapped to all platforms. MDA contains the word architecture, which is an overloaded term in soft- ware engineering. The MDA guide uses the following definition to relate the term architecture to its meaning in MDA: “The architecture of a system is a specification of the parts and con- nectors of the system and the rules for the interactions of the parts using the connectors. The Model-Driven Architecture prescribes cer- tain kinds of models to be used, how those models may be prepared and the relationships of the different kinds of models.” [MM03] The Model-Driven Architecture refers to the architecture of the software development process, summarised by the MDA pattern. In Chapter 1, we have already introduced the basic MDA pattern: to use Model Transformation to map a Platform-Independent Model (PIM) to a Platform-Specific Model (PSM). Fig. 2.1 shows the envisioned impact of this pattern: the left side shows the traditional lifecycle of iterative development. In theory, the feedback loop should go all the way up to the requirements level, keeping all software artifacts synchronised. In practise, the fact that process stage transitions are only automated from the code level downward makes that it is not feasible to feed changes back to the top level. The feedback effort is normally rewarded by an updated system that incorporates the feedback. That updated system is our real goal, not feeding back changes to higher abstraction levels. If we provide feedback to the top level, this will not result in an updated system. In fact, we have to manually translate the feedback to the lower levels of abstraction until we reach code level. Only at code level, automation picks up and the feedback loop is closed. That’s why currently feedback is mostly provided directly at code level and all software artifacts at a higher level gradually become outdated.
- 49. 2.2 Models 21 !""#$!""%&'()*+,-./0&1*)+.,20&3*)440&5,26,+0& 7! '89, '89, Impact of MDA on the Development Process :,;</*,=,+>6 ?+)2@6/6 A,6/B+ '89/+B C,6>/+B A,D28@=,+> E86>2@ >,F> A/)B*)=6 )+9&>,F> A/)B*)=6 )+9&>,F> G>,*)>/H, D*8-,66 I/+&>J,8*@K L*8B*)==,*M6 6J8*>-<> '89, '89, :,;</*,=,+>6 ?+)2@6/6 A,6/B+ '89/+B C,6>/+B A,D28@=,+> E86>2@ >,F> LNE LGE EA? D*8-,66 N8<*-,O&P2,DD, ,>&)2&!""# Traditional lifecycle MDA lifecycle Figure 2.1: Impact of MDA on the development process (source: [KWB03]). The right side of Fig. 2.1 shows how the MDA intends to mitigate this problem. The analysis and design artifacts are made part of the automation pipeline. It then becomes easier to lift the feedback loop of iterative devel- opment up to the analysis level, where automation picks up and closes the feedback loop. The core concepts in any MDA-based process are: • Models • Meta-models • Model Transformation The following sections discuss these core concepts, as well as the relation- ship of MDA to existing research. 2.2 Models MDA is centred around models and how those models may be used together to create the resulting software system. The MDA guide defines a model as follows: “A model of a system is a description or specification of that system and its environment for some certain purpose. A model is often presented as a combination of drawings and text. The text may be in a modeling language or in a natural language.” [MM03]
- 50. 22 Chapter 2. Model-Driven Architecture This is a very broad definition of a model, which unfortunately mixes up the structure of a model with its presentation. The structure of a model is defined by the abstract syntax of the language that a model is written in. The presentation of a model is defined by the concrete syntax of the modelling lan- guage. Even though the definition covers the presentation of models, the focus lies on the structure of a model in the MDA, as is made clear in section 2.3. Models can play a number of particular roles in an MDA-based process. Four kinds of models with a particular role are distinguished in the MDA: • Computation Independent Model (CIM) • Platform Independent Model (PIM) • Platform Specific Model (PSM) • Platform Model (PM) The standard language for expressing these models is the Unified Modeling Language (UML) [OMG05c]. The following sections discuss each of the listed models. 2.2.1 Computation Independent Models The Computation Independent Model focuses on the requirements for the sys- tem and the environment of the system. It is sometimes called a domain model and serves as a vocabulary that is familiar to the practitioners of the system’s domain. A CIM is more than a domain model, however, since it also expresses the system requirements using the domain concepts as a vocabulary. A CIM does not show details of the structure or processing of the system. The CIM is intended to help bridge the gap between domain experts and system design experts. It is difficult to say exactly when a model is still “computation indepen- dent”. It may show the structure of the domain, but not the details of that structure. It also may show the behaviour of the domain, but not any process- ing details specific to the system we aim to specify. Let’s consider an example system of an instant messaging client that shows a list of people who are on- line and that can send messages to those people. Fig. 2.2 shows what such an instant messaging client can look like. A CIM of such an instant messaging client describes the domain concepts for instant messaging, such as “contact”, “contact list” and “message”. For each of these concepts, a number of behavioural and structural features (op- erations and attributes) can be described. The CIM does not describe what steps the system must perform to achieve a certain behaviour. Fig. 2.3 shows a UML Class diagram of the instant messaging client domain concepts. Note
- 51. 2.2 Models 23 Figure 2.2: A screenshot of an instant messaging client running on a PC. that the example CIM is not a “pure” CIM: it contains “computation depen- dent” stereotype applications, such as Observer and Observable. The cause of this is that a CIM is typically refined manually into a model that includes computation details. The original CIM no longer exists in the end and is actu- ally a part of the Platform Independent Model. Since the CIM typically models the domain concepts up to the extent that the intended system requires, it is often not directly applicable outside the boundaries of the intended system. 2.2.2 Platform Independent Models A Platform Independent Model exhibits a specified degree of platform indepen- dence, such that it is suitable for a number of similar platforms. This implies that the targeted platforms must be known beforehand to a certain degree. It also implies that a PIM is still specific to the chosen group of platforms. In the case of our instant messaging client example, the PIM is meant to target Java-based client platforms. It is independent of any specific Java client platform, such as J2SE 1.4 or J2ME Personal Profile 1.0, but still depends on Java in general (language, object model, execution model, common API, etc.). Fig. 2.4 shows a UML Class diagram of the global instant messaging client architecture. While the CIM is only concerned with instant messag- ing client domain concepts, the PIM also includes computational information, such as the fact that an InstantMessagingClient is an <<Applet>> that sub- scribes to all available Networks as an <<Observer>>. This PIM also intro- duces Java-specific elements: InstantMessagingClient implements the Excep-
- 52. 24 Chapter 2. Model-Driven Architecture Figure 2.3: A UML Class diagram of the instant messaging client CIM. tionReporter interface, which includes a reference to java.lang.Exception. Since java.lang.Exception exists in all our targeted Java platforms, it is considered platform-independent for our purpose. 2.2.3 Platform Specific Models A Platform Specific Model combines the specifications in the PIM with the details that specify how the system uses a particular (kind of) platform. This means that it introduces platform dependencies. The term PSM is relative and only means something when compared to a PIM. There can be multiple levels of PSMs. Consider a PSM that is specific to a (narrowed down) group of platforms. This PSM can be considered a PIM when compared to a PSM that is specific to one concrete platform out of that group. Fig. 2.5 shows the fully refined platform-specific version of the PIM Class diagram shown in Fig. 2.4. Fully refined means that this is the lowest level PSM, just before Java code is generated: • UML properties that have a multiplicity higher than 1 have been trans- formed to use Java collection types: InstantMessagingClient::network has become a java.util.List, while InstantMessagingClient::conversation has become a java.util.Set. • Accessor operations have also been generated for each public property (get. . . , set. . . , add. . . , etc.), while those public properties have been made private.
- 53. 2.2 Models 25 Figure 2.4: A UML Class diagram showing part of the instant messaging client PIM. • The observer pattern has been implemented using the java.util.Ob- server interface and the java.util.Observable class. • All <<Applet>> classes have been implemented as java.applet.Applet subclasses. • All <<Singleton>> classes now include the singleton infrastructure (a static ‘instance’ property and ‘getInstance()’ operation). 2.2.4 Platform Models A Platform Model provides the technical concepts that represent the parts that make up a platform. It also provides concepts for specifying the use of a platform by a software system, which can be used in a PSM. As an exam- ple, the CORBA Component Model (CCM) [OMG06a] provides concepts as EntityComponent, SessionComponent, ProcessComponent, Facet, Receptacle, EventSource, etc. A software system can use these concepts to specify how it uses the CCM. A Platform Model also specifies requirements on how a software system is connected to the platform. As an example, the UML profile for CORBA [OMG02] provides a language to use when modelling CORBA systems. The rules of this language represent the requirements of the connection to the platform.
- 54. 26 Chapter 2. Model-Driven Architecture Figure 2.5: A UML Class diagram showing part of the instant messaging client PSM. This notion of Platform Model is mostly useful to model abstract plat- forms [ADvSP04], which represent a common interface to all targeted plat- forms. In the instant messaging client example, this Platform Model consists of a simplified representation of some of the Java API that is common to all targeted Java platforms (e.g. java.lang.Exception) and several UML pro- files (Applet, Singleton, Observer, . . . ) that abstract from the way a specific Java platforms implements certain functionality. A Platform Model can also consist of the API for a specific Java platform, such as J2SE 1.4. The PSM typically refers to such a Platform Model. Note that the model transforma- tions that map a PIM to a PSM introduce the references to such a Platform Model. Our notion of Platform Model goes further than that: a Platform Model is meant to drive the mapping from PIM to (lowest level) PSM. This may include selecting all the appropriate model transformations for a complete mapping to the targeted platform. This notion of Platform Model is discussed later in this dissertation.
- 55. Random documents with unrelated content Scribd suggests to you:
- 56. Colin had once felt on his neck had worn by this time to such an impalpable thread that he was no longer aware of its existence; and even the woman in the clouds had passed out of his recollection for the moment, so much was he absorbed with the great work he had embarked on. Thus he set out on a pedestrian excursion, meaning to go to the English lakes, and it is hard to say where besides, in his month’s holiday; and nothing in the air or in the skies gave any notice to Colin of the great event that was to befall him before he could return.
- 57. CHAPTER XLVII. It was, as we have said, a lovely summer morning when Colin set out on his excursion, after the fatigues of the winter and spring. His first stage was naturally Ramore, where he arrived the same evening, having picked up Lauderdale at Glasgow on his way. A more beautiful evening had never shone over the Holy Loch; and, as the two friends approached Ramore, all the western sky was flaming behind the dark hills, which stood up in austere shadow, shutting out from the loch and its immediate banks the later glories of the sunset. To leave the eastern shore, where the light still lingered, and steal up under the shadow into the soft beginning of the twilight, with Ramore, that “shines where it stands,” looking out hospitably from the brae, was like leaving the world of noise and commotion for the primitive life, with its silence and its thoughts; and so, indeed, Colin felt it, though his world was but another country parish, primitive enough in its ways. But then it must not be forgotten that there is a difference between the kingdom of Fife, where wheat grows golden on the broad fields, and where the herrings come up to the shore to be salted and packed in barrels, and the sweet Loch half hidden among the hills, where the cornfields are scant and few, and where grouse and heather divide the country with the beasts and the pastures, and where, in short, Gaelic was spoken within the memory of man. Perhaps there was something of the vanity of youth in that look of observation and half amused, half curious criticism which the young man cast upon the peaceful manse, where it did not seem as if anything could ever happen, and where the minister, who had red hair, had painfully begun his career when Colin himself was a boy. The manse of Afton was not nearly so lovely, but—it was different; though perhaps he could not have told how. And the same thought was in his mind as he went on past all the tranquil houses. How did they manage to keep existing, those people for whom life was over, who had ceased to look beyond the day, or to anticipate either good or evil? To be sure all this was very unreasonable; for Colin was aware that things did happen now and then on the Holy Loch. Somebody died occasionally, when it was impossible to help it, and by turns somebody was born, and there even occurred, at rare intervals a marriage, with its suggestion of life beginning; but these domestic incidents
- 58. were not what he was thinking of. Life seemed to be in its quiet evening over all that twilight coast; and then it was the morning with Colin, and it did not seem possible for him to exist without the hopes, and motives, and excitements which made ceaseless movement and commotion in his soul. He was so full of what had to be done, even of what he himself had to do, that the silence seemed to recede before him, and to rustle and murmur round him as he carried into it his conscious and restless life. Colin had even such a wealth of existence to dispose of that it kept flowing on in two or three distinct channels, a thing which amused him when he thought of it. For underneath all this sense of contrast, and Lauderdale’s talk, and his own watch for the Ramore boat, No. 1 of the “Tracts for the Times” was at the same time shaping itself in Colin’s brain; and there are moments when a man can stand apart from himself, and note what is going on in his own mind. He was greeting the old friends who recognised him in the steamboat, and looking out for home, and planning his tract, and making that contrast between the evening and the morning all at the same moment. And at the same time he had taken off the front of his mental habitation, and was looking at all those different processes going on in its different compartments with a curious sense of amusement. Such were the occupations of his mind as he went up to the Loch, to that spot where the Ramore boat lay waiting on the rippled surface. It was a different homecoming from any that he had ever made before. Formerly his prospects were vague, and it never was quite certain what he might make of himself. Now he had fulfilled all the ambitions of his family, as far as his position went. There was nothing more to hope for or to desire in that particular; and, naturally, Colin felt that his influence with his father and brothers at least would be enhanced by the realization of those hopes, which, up to this time, had always been mingled with a little uncertainty. He forgot all about that, it is true, when he grasped the hands of Archie and of the farmer, and dashed up the brae to where the Mistress stood wistful at the door; but, notwithstanding, there was a difference, and it was one which was sufficiently apparent to all. As for his mother, she smoothed down the sleeve of his black coat with her kind hand, and examined with a tender smile the cut of the waistcoat which Colin had brought from Oxford— though, to tell the truth, he had still a stolen inclination for “mufti,” and wore his uniform only when a solemn occasion occurred like this and on grand parade; but, for all her joy and satisfaction at sight of him, the
- 59. Mistress still looked a little shattered and broken, and had never forgotten— though Colin had forgotten it long ago—the “objections” of the parish of Afton, and all that her son had had “to come through,” as she said, “before he was placed.” “I’m awfu’ shaken in my mind about a’ that,” said the Mistress; “there’s the Free Kirk folk—though I’m no for making an example of them— fighting among themselves about their new minister, like thae puir senseless creatures in America. Thamas, at the Millhead, is for the ae candidate, and his brother Dugald for the tither; and they’re like to tear each other’s een out when they meet. That’s ill enough, but Afton’s waur. I’m no for setting up priests, nor making them a sacerdotal caste as some folk say; but will you tell me,” said Mrs. Campbell, indignantly, “that a wheen ignorant weavers and canailye like that can judge my Colin? ay, or even if it was thae Fife farmers driving in their gigs. I would like to ken what he studied for and took a’ thae honours, and gave baith time and siller, if he wasna to ken better than the like of them? I’m no pretending to meddle with politics that are out of my way—but I canna shut my een,” the Mistress said, emphatically. “The awfu’ thing is that we’ve nae respect to speak of for onything but ourselves; we’re so awfu’ fond of our ain bit poor opinions, and the little we ken. If there was ony change in our parish—and the minister’s far from weel, by a’ I can hear—and that man round the point at the English chapel wasna such an awfu’ haveril—I would be tempted to flee away out of their fechts and their objections, and get a quiet Sabbath day there.” “I’m no for buying peace so dear, for my part,” said Lauderdale; “they’re terrible haverils, most of the English ministers in our pairts, as the Mistress says. We’re a’ in a kind of dissenting way now-a-days, the mair’s the pity. Whisht a moment, callant, and let a man speak.—I’m no saying onything against dissent; it’s a wee hard in its ways, and it has an awfu’ opinion of itsel’, and there’s nae beauty in it; but, when your mind’s made up to have popular rights and your ain way in everything, I canna see onything else for it, for my part.” “Weel, we’ll a’ see,” said big Colin, who in his heart could not defend an order of ecclesiastical economy which permitted his son to be assaulted by the parish of Afton, or any other parish, “if it’s the will of God. We’re none of us so awfu’ auld; but the world’s aye near its ending to a woman that sees her son slighted; there’s nae penitence can make up for that—no that he’s
- 60. suffered much that I can see,” the farmer said with a laugh. “There’s enough of the Kirk for one night.” “Eh, Colin, dinna be so worldly,” said his wife; “I think whiles it would be an awfu’ blessing if the world was to end as you say; and a thing be cleared up, and them joined again that had been parted, and the bonnie earth safe through the fire—if it’s to be by fire,” she added with a questioning glance towards her son; “I canna think but it’s ower good to be true. When I mind upon a’ we’ve to go through in this life, and a’ that is so hard to mend; —eh, if He would but take it in His ain hand!” said the Mistress with tears in her eyes. No one was so hard-hearted as to preach to her at that moment, or to enlarge upon the fact that everything was in His hand, as indeed she knew as well as her companions; but it happens sometimes that the prayers and the wishes which are out of reason, are those that come warmest, and touch deepest, to the heart. But, meanwhile, awaiting the end of the world, Colin, when he was settled for the night in his old room, with its shelving roof, took out and elaborated his Tract for the Times. It was discontent as great as that of his mother’s which breathed out of it; but then hers was the discontent of a life which had nothing to do or to look for, and which had found out by experience how little progress can be made in a lifetime, and how difficult it is to change evil into good. Colin’s discontent, on the contrary, was that exhilarating sentiment which stimulates youth, and opens an endless field of combat and conquest. At his end of the road it looked only natural that the obstacles should move of themselves out of the way, and that what was just and best should have the inevitable victory. When he had done, he thought with a tenderness which brought tears to his eyes, yet at the same moment a smile to his lips, of the woman’s impatience that would hasten the wheels of fate, and call upon God to take matters, as she said, in His own hand. That did not, as yet, seem a step necessary to Colin. He thought there was still time to work by the natural means, and that things were not arrived as such a pass that it was needful to appeal to miracle. It could only be when human means had failed that such a resource could be necessary; and the human means had certainly not failed entirely so long as he stood there in the bloom of his young strength, with his weapons in his hand. He preached in his native church on the following Sunday, as was to be expected; and from up the Loch and down the Loch all the world came to hear young Colin of Ramore. And big Colin the farmer sat glorious at the
- 61. end of his pew, and in the pride of his heart listened, and noted, and made inexorable criticisms, and commented on his son’s novel ideas with a severe irony which it was difficult to understand in its true sense. The Duke himself came to hear Colin’s sermon, which was a wonderful honour to the young man, and all the parish criticised him with a zest which it was exhilarating to hear. “I mind when he couldna say his Questions,” said Evan of Barnton; “I wouldna like to come under ony engagement that he kens them noo. He was aye a callant awfu’ fond of his ain opinion, and for my part I’m no for Presbyteries passing ower objections so easy. Either he’s of Heward’s school or he’s no; but I never saw that there was ony right decision come to. There were some awfu’ suspicious expressions under his second head—if you could ca’ yon a head,” said the spiritual ruler, with natural contempt; for indeed Colin’s divisions were not what they ought to have been, and he was perfectly open to criticism so far as that was concerned. “A lot of that was out of Dennistoun,” said another thoughtful spectator. “I’m aye doubtful of thae misty phrases. If it wasna for hurting a’ their feelings, I would be awfu’ tempted to say a word. He’s no’ that auld, and he might mend.” “He’ll never mend,” said Evan. “I’m no’ one that ever approved of the upbringing of thae laddies. They have ower much opinion of themselves. There’s Archie, that thinks he kens the price of cattle better than a man of twice his age. She’s an awfu’ fanciful woman, that mother of theirs—and then they’ve a’ been a wee spoiled with that business about the English callant; but I’ll no say but what he has abilities,” the critic added, with a national sense of clanship. The parish might not approve of the upbringing of the young Campbells, nor of their opinions, but still it had a national share in any reputation that the family or any of its members might attain. Colin continued his course on the Monday with his friend. He had stayed but a few days at home, but it was enough, and all the party were sensible of the fact. Henceforward that home, precious as it was, could not count for much in his life. It was a hard thing to think of, but it was a necessity of nature. Archie and the younger sons greeted with enthusiasm the elder brother, who shared with them his better fortunes and higher place; but, when the greeting was given on both sides, there did not remain very much to say; for, to be sure, seen by Colin’s side, the young Campbells,—still gauche, and shamefaced, and with the pride of a Scotch peasant in arms,
- 62. looked inferior to what they really were, and felt so—and the mother felt it for them, though Colin was her own immediate heir and the pride of her heart. She bade him farewell with suppressed tears, and a sense of loss which was not to be suppressed. “He has his ain hame, and his ain place, and little need of us now, the Lord be praised,” the Mistress said to herself as she watched him going down to the boat; “I think I would be real content if he had but a good wife.” But still it was with a sigh that she went in again and closed the door upon the departing boat that carried her son back to the world.
- 63. CHAPTER XLVIII. As for Colin and his friend, they went upon their way steadily, with that rare sympathy in difference which is the closest bond of friendship. Lauderdale by this time had lost almost all the lingerings of youth which had hung long about him, perhaps by right of his union with the fresh and exuberant youth of his brother-in-arms. His gaunt person was gaunter than ever, though, by an impulse of the tenderest pride—not for himself but for his companion—his dress fitted him better, and was more carefully put on than it had even been during all his life; but his long hair, once so black and wild, was now grey, and hung in thin locks, and his beard, that relic of Italy, which Lauderdale preserved religiously, and had ceased to be ashamed of, was grey also, and added to the somewhat solemn aspect of his long thoughtful face. He was still an inch or two taller than Colin, whose great waves of brown hair, tossed up like clouds upon his forehead, and shining brown eyes, which even now had not quite lost the soft shade of surprise and admiration which had given them such a charm in their earlier years, contrasted strangely with the worn looks of his friend. They were not like father and son; for Lauderdale preserved in his appearance an indefinable air of solitude and of a life apart, which made it impossible to think of him in any such relationship; but perhaps their union was more close and real than even that tie could have made it, since the unwedded childless man was at once young and old, and had kept in his heart a virgin freshness more visionary, and perhaps even more spotless, than that of Colin’s untarnished youth; for, to be sure, the young man not only was conscious of that visionary woman in the clouds, but had already solaced himself with more than one love, and still meant to marry a wife like other men, though that was not at present the foremost idea in his mind; whereas, whatever love Lauderdale might have had in that past from which he never drew the veil, it had never been replaced by another, nor involved any earthly hope. As they crossed the borders, and found themselves among the Cumberland hills, Lauderdale began to make gradual advances to a subject which had been for a long time left in silence between them. Perhaps it required that refinement of ear natural to a born citizen of Glasgow to
- 64. recognise that it was “English” which was being spoken round them as they advanced—but the philosopher supposed himself to have made that discovery. He recurred to it with a certain pathetic meaning as they went upon their way. They had set out on foot from Carlisle, each with his knapsack, to make their leisurely way to the Lakes; and, when they stopped to refresh themselves at the humble roadside inn which was their first resting-place, the plaintive cadence of his friend’s voice struck Colin with a certain amusement. “They’re a’ English here,” Lauderdale said, with a tone of sad recollection, as a man might have said in Norway or Russia, hearing for the first time the foreign tongue, and bethinking himself of all the dreary seas and long tracts of country that lay between him and home. It might have been pathetic under such circumstances, though the chances are that even then Colin, graceless and fearless, would have laughed; but at present, when the absence was only half a day’s march, and the difference of tongue, as we have said, only to be distinguished by an ear fine and native, the sigh was too absurd to be passed over lightly. “I never knew you have the mal du pays before,” Colin said with a burst of laughter:—and the patriot himself did not refuse to smile. “Speak English,” he said, with a quaint self-contradiction; “though I should say speak Scotch if I was consistent;—you needna make your jokes at me. Oh ay, it’s awfu’ easy laughing. It’s no that I’m thinking of; there’s nothing out of the way in the association of ideas this time, though they play bonnie pranks whiles. I’m thinking of the first time I was in England, and how awfu’ queer it sounded to hear the bits of callants on the road, and the poor bodies at the cottage doors.” “The first time you were in England—that was when you came to nurse me,” said Colin; “I should have died that time but for my mother and you.” “I’m not saying that,” said Lauderdale; “you’re one of the kind that’s awfu’ hard to kill—but it’s no that I’m thinking of. There are other things that come to my mind with the sound of the English tongue. Hold your peace, callant, and listen; is there nothing comes back to your ain mind when you hear the like of that?” “I hear a woman talking very broad Cumberland,” said Colin, who notwithstanding began to feel an uncomfortable heat mounting upwards in his face; “you may call it English, if you have a mind. There is some
- 65. imperceptible difference between that and the Dumfriesshire, I suppose; but I should not like to have to discriminate where the difference lies.” As for Lauderdale, he sighed; but without intending it, as it appeared, for he made a great effort to cover his sigh with a yawn, for which latter indulgence he had evidently no occasion; and then he tried a faint little unnecessary laugh. “I’m an awfu’ man for associations,” he said; “I’m no to be held to account for the things that come into my head. You may say it’s Cumberland, and I’m no disputing; but for a’ that there’s something in the sound of the voice——” “Look here,” said Colin impatiently; “listen to my tract. I want you to give me your opinion now it is finished; turn this way, with your face to the hills, and never mind the voice.” “Oh, ay,” said Lauderdale, with another sigh; “there’s nae voice like his ain voice to this callant’s ear; it’s an awfu’ thing to be an author, and above a’ a reformer; for you may be sure it’s for the sake of the cause, and no because he’s written a’ that himsel’. Let’s hear this grand tract of yours; no that I’ve any particular faith, in that way of working,” he added impartially. It was not encouraging perhaps to the young author; but Colin was sufficiently used by this time to his friend’s predilections, and for his own part was very well pleased to escape from memories more perplexing and difficult to manage. It was with this intention that he had taken out No. I. of the Tracts for the Times. If any of the writers of the original series of these renowned compositions could but have looked over the shoulder of the young Scotch minister, and beheld the different fashion of thoughts, the curious fundamental difference which lay underneath, and yet the apparent similarity of intention on the face of it! Rome and the Pope were about as far off as Mecca and the prophet from Colin’s ideas. He was not in the least urgent for any infallible standard, nor at all concerned to trace a direct line of descent for himself or his Church; and yet withal his notions were as high and absolute and arbitrary on some points as if he had been a member of the most potent of hierarchies. It would, however, be doing Colin injustice to reproduce here this revolutionary document: to tell the truth, circumstances occurred very soon after to retard the continuation of the series, and, so far as his historian is aware, the publication of this preliminary[4] address was only partial. For, to be sure, the young man had still abundance of time before him, and the first and most important thing,
- 66. as Lauderdale suggested, was the preparation of an audience—an object which was on the whole better carried out by partial and private circulation than by coming prematurely before the public, and giving the adversary occasion to blaspheme, and perhaps frightening the Kirk herself out of her wits. Having said so much, we may return to the more private and individual aspect of affairs. The two friends were seated, while all this was going on, out of doors, on a stone bench by the grey wall of the cottage inn, in which they had just refreshed themselves with a nondescript meal. The Cumberland hills—at that moment bleaching under the sunshine, showing all their scars and stains in the fulness of the light—stretched far away into the distance, hiding religiously in their depths the sacred woods and waters that were the end of the pilgrimage on which the two friends were bound. Lauderdale sat at leisure and listened, shading the sunshine from his face, and watching the shadows play on the woods and hills; and the same force of imagination which persuaded the unaccustomed traveller that he could detect a difference of tone in the rude talk he heard in the distance, and that that which was only the dialect of Cumberland was English, persuaded him also that the sunshine in which he was sitting was warmer than the sunshine at home, and that he was really, as he himself would have described it, “going south.” He was vaguely following out these ideas, notwithstanding that he also listened to Colin, and gave him the fullest attention. Lauderdale had not travelled much in his life, nor enjoyed many holidays; and, consequently, the very sense of leisure and novelty recalled to him the one great recreation of his life—the spring he had spent in Italy, with all its vicissitudes, prefaced by the mournful days at Wodensbourne. All this came before Lauderdale’s mind more strongly a great deal than it did before that of Colin, because it was to the elder man the one sole and clearly marked escape out of the monotony of a long life—a thing that had occurred but once, and never could occur again. How the Cumberland hills, and the peasant voices in their rude dialect, and the rough stone bench outside the door of a grey lime-stone cottage, could recall to Lauderdale the olive slopes of Frascati, the tall houses shut up and guarded against the sunshine, and the far-off solemn waste of the Campagna, would have been something unintelligible to Colin. But in the meantime these recollections were coming to a climax in his companion’s mind. He gave a great start in the midst of Colin’s most eloquent paragraph, and jumped to his feet, crying,
- 67. “Do you hear that?” with a thrill of excitement utterly inexplicable to the astonished young man: and then Lauderdale grew suddenly ashamed of himself, and took his seat again, abashed, and felt that it was needful to explain. “Do I hear what?” said Colin; and, as this interruption occurred just at the moment when he supposed he had roused his hearer to a certain pitch of excitement and anxiety, by his account of the religious deficiencies of Scotland, which he was on the point of relieving by an able exposition of the possibilities of reform, it may be forgiven to him if he spoke with a little asperity. Such a disappointment is a trying experience to the best of men. “What is it, for Heaven’s sake?” said the young man, forgetting he was a minister; and, to tell the truth, Lauderdale was so much ashamed of himself that he felt almost unable to explain. “She’s singing something, that’s a’,” said the confused philosopher. “I’m an awfu’ haveril, Colin. There’s some things I canna get out of my head. Never you mind; a’ that’s admirable,” said the culprit, with a certain deprecatory eagerness. “I’m awfu’ anxious to see how you get us out of the scrape. Go on.” Colin was angry, but he was human, and he could not but laugh at the discomfiture and conciliatory devices of his disarmed critic. “I am not going to throw away my pearls,” he said; “since your mind is in such a deplorable state you shall hear no more to-day. Oh, no. I understand the extent of your anxiety. And so here’s Lauderdale going the way of all flesh. Who is she? and what is she singing? The best policy is to make a clean breast of it,” said the young man, laughing; “and then, perhaps I may look over the insult you have been guilty of to myself.” But Lauderdale was in no mood for laughing. “It would be the best plan to go on,” he said; “for I’ve been giving my best attention; and maybe if I was to speak out what was in my heart—” “Speak it out,” said Colin. He was a little affronted, but he kept his composure. As he folded up his papers and put them away in his pocket- book, he too heard the song which Lauderdale had been listening to. It was only a countrywoman singing as she went about her work, and there was no marked resemblance in the voice to anything he had heard before. Yet he knew what was coming when he put up his papers in his pocket-book, and it
- 68. occurred to him that perhaps it would be well to have the explanation over and be done with it, for he knew how persistent his companion was. “It’s no that there’s much to say,” said Lauderdale, changing his tone; “a man like me, that’s little used to change, get’s awfu’ like a fool in his associations. There’s naething that ony reasonable creature could see in thae hills, and a’ the sheep on them, that should bring that to my mind; and, as you say, callant, it’s Cumberland they’re a’ speaking, and no English. It’s just a kind of folly that men are subject to that live their lane. I canna but go a’ through again, from the beginning to—— Well, I suppose,” said Lauderdale with a sigh, “what you and me would call the end.” “What any man in his senses would call the end,” said Colin, beginning to cut his pencil with some ferocity, which was the only occupation that presented itself to him for the moment; “I don’t suppose there can be any question as to what you mean. Was it to be expected that I should court rejection over again for the mere pleasure of being rejected?—as you know I have been, both by letter and in person; and then, as if even that was not enough, accused of fortune-hunting; when Heaven knows——” Here Colin stopped short, and cut his pencil so violently that he cut his finger, an act which convicted him of using unnecessary force, and of which accordingly he was ashamed. “It is no that I was thinking of,” said Lauderdale, “I was minding of the time when we a’ met first, and the bit soft English voice—it’s no that I’m fond of the English, or their ways,” continued the philosopher. “We’re maybe no so well in our ain country, and maybe we’re better; I’ll no say. It’s a question awfu’ hard to settle. But, if ever we a’ foregather again, I cannot think there will be that difference. It wasna to say musical that I ken of, but it was aye soft and pleasant—maybe ower soft, Colin, for the like of you—and with a bit yielding tone in it, as if the heart would break sooner than make a stand for its own way. I mind it real weel,” said Lauderdale, with a sigh. “As for the father, no doubt there was little to be said in his favour. But, after a’, it wasna him that you had any intention to marry. And yon Sabbath-day after he was gone, poor man!—when you and me didna ken what to do with ourselves till the soft thing came out of her painted cha’amer, and took the guiding of us into her hands. It’s that I was thinking of,” said Lauderdale, fixing his eyes on a far-off point upon the hills, and ending his musings with a sigh.
- 69. Colin sighed, too, for sympathy—he could not help it. The scene came before him as his friend spoke. He thought he could see Alice, in her pallor and exhaustion, worn to a shadow, in her black dress, coming into the bare Italian room in the glorious summer day, which all the precautions possible could not shut out from the house of mourning—with her prayer-book in her hand; and then he remembered how she had chidden him for reading another lesson than that appointed for the day. It was in the height of his own revolutionary impulses that this thought struck him; and he smiled to himself in the midst of his sigh, with a tender thought for Alice, and a passing wonder for himself, what change might have been wrought upon him if that dutiful little soul had actually become the companion of his life. Colin was not the kind of man who can propose to himself to form his wife’s mind, and rule her thoughts, and influence her without being sensible of her influence in return. That was not the order of domestic affairs in Ramore; and naturally he judged the life that might have been, and even yet might be, by that standard. The Mistress’s son did not understand having a nullity, or a shadow of himself, for a wife; and insensibly he made his way back from the attendrissement into which Lauderdale’s musings had led him, into half-amused speculation as to the effect Alice and her influence might have had upon him by this time. “If that had happened,” he said with a smile, bursting out, as was usual to him when Lauderdale was his companion, at that particular point of his thoughts which required expression, without troubling himself to explain how he came there—“if that had happened,” said Colin, with the conscious smile of old, “I wonder what sort of fellow I should have been by this time? I doubt if I should have had any idea of disturbing the constituted order of affairs. Things are always for the best, you perceive, as everybody says. A man who has any revolutionary work to do must be free and alone. But don’t let us talk any more of this—I don’t like turning back upon the road. But for that feeling I should have settled the business before now about poor Arthur’s ‘Voice from the Grave.’ ” “I was aye against that title,” said Lauderdale, “if he would have paid any attention; but you’re a’ the same, you young callants; it’s nae more a voice from the grave than mine is. It’s a voice from an awfu’ real life, that had nae intention to lose a minute that was permitted. It would be awfu’ agreeable to ken if he was permitted to have any pleasure in his book; but then, so far as I can judge, he maun ken an awfu’ deal better by this time—
- 70. and maybe up there they’re no heeding about a third edition. It’s hard to say; he was so terrible like himself up to the last moment; I canna imagine, in my own mind, that he’s no like himself still. There should be a heap of siller,” said Lauderdale, “by this time; and sooner or later you’ll have to open communication, and let them ken.” “Yes,” said Colin, with a momentary look of sullenness and repugnance; and then he added, in a lighter tone, “heaps of money never came out of a religious publisher’s hands. A third edition does not mean the same thing with them as with other people. Of course, it must be set right some time or other. We had better set off, I can tell you, and not talk idle talk like this, if we mean to get to our journey’s end to-night.” “Oh, ay,” said Lauderdale, “you’re aye in a hurry, you young callants. Is it the father that makes you so unwilling for any correspondence?—but it’s awfu’ easy to settle a thing like that.” “I think you want to try how far my patience can go,” said Colin, who had grown crimson up to the hair. “Do you think a man has no feeling, Lauderdale? Do you think it is possible to be treated as I have been, and yet go back again with humility, hat in hand? I don’t feel myself capable of that.” “If you’re asking me my opinion,” said Lauderdale, calmly, “I’ve nae objection to tell you what I think. You’re no vindictive, and you’ve nae pride to speak of—I’m meaning pride of that kind. It’s no in you to bear a grudge at onybody, beyond, maybe, the hour or the day. So I’m no heeding much about that question, for my part. If you had an awfu’ regard for the man, he might affront you; but no being indifferent. I’m telling you just my opinion, with my partial knowledge of the premises; and for her, I cannot but say what is in my ain mind. I’ve a kind of longing to see her again; we used to be awfu’ good friends, her and me. I had you to take care of, callant, and she had him; and whiles she had a moment of envy, and grudged terrible in her heart to see the air and the sun, that are for baith the good and the evil, so hard upon him, and so sweet to you. There was little in her mind to hide, and her and me were good friends. I’ll never forget our counts and our reckonings. It’s awfu’ hard for the like o’ me to divine wherefore it is that a’ that has come to an end, and her and you dropped out of one another’s life.”
- 71. “Lauderdale,” said Colin, with a little choking in his voice, “I will tell you what I never told you before——” and then the young man stopped short, as if he had received a blow. What was it that came over him like an imperious sudden prohibition, stopping the words upon his lips the first time he had ever dreamt of uttering them to mortal ear? He had a feeling somehow as if one of those flying shadows that kept coming and going over the mountains had taken visible shape and stepped before him, and put a cold hand on his lips. He was about to have confessed that his love had been no more than tender compassion and kindness; he was about to have said what Lauderdale perhaps might have guessed before, what Colin had kept secret and hidden in his breast—that Alice never was nor could be the ideal woman of his thoughts, the true love who waited for him somewhere in the future. But perhaps, after all, it was no shadow nor unseen influence, but only the young man’s magnanimous heart that spared that humiliation to the name of Alice—solely to her name; for, now that all was over between them, it was only that abstract representation of her that was concerned. “Ay,” said Lauderdale, after a moment, “you were going to tell me——” and then he rose as Colin had done, and threw his knapsack on his shoulder, and prepared to resume his march. “We shall have an hour’s walking in the dark, if we don’t make all the better progress,” said Colin; “which is uncomfortable when one does not know the way. And now to return to No I.” he said with a laugh, as they went on along the dusty road. There was not another word said between them of the confession thus abruptly stopped. Perhaps Lauderdale in his heart had a perception of what it meant; but, however that might be, both fell at once with eagerness, as if they had never digressed for a moment, upon the first number of Colin’s Tracts for the Times.
- 72. CHAPTER XLIX. This conversation, however, as was natural, had a certain effect upon both the friends. It threw Colin, who, to be sure, was chiefly concerned, into a world of confused imaginations, which influenced even his dreams, and through his dreams reacted upon himself. When he was alone at night, instead of going to sleep at once, as would have been natural after his day’s journey, he kept falling into absurd little dozes, and waking up suddenly with the idea that Alice was standing by him, that she was calling him, that it was the marriage-day, and that somebody had found him out, and was about to tell his bride that he did not love her; and at last, when he went to sleep in good earnest, the fantastic mélange of recollection and imagination carried him back to Frascati, where he found Arthur and Alice, as of old, in the great salone, with its frescoed walls, and talked to them as in former days. He thought Meredith told him of an important journey upon which he was setting out, and made arrangements in the meantime for his sister with an anxiety which the real Arthur had never dreamt of exhibiting. “She will be safe with you at present,” the visionary Arthur seemed to say, “and by- and-by you can send her to me——” And when Colin woke it was hard for him to convince himself at first that he had not been in actual communication with his friend. He accounted for it, of course, as it is very easy to account for dreams, and made up his mind how it came about, and yet left behind in some crevice of his heart a dumb certainty which hid itself out of sight that it might not be argued with, that after all Arthur and he in the dark had passed by each other, and exchanged a word or thought in passing. Colin took care not to betray even to himself the existence of this conviction; but deep down in the silence it influenced him unawares. As for Lauderdale, his thoughts, as might have been expected, had taken another direction. Perhaps he was past the age of dreaming. Colin’s revelation which he did not make had possibly told his friend more than if it had been said out in words; and the two began their second day’s journey with but little talk, and that of a vague and general kind. They had not gone far upon the white and dusty road when Lauderdale drew aside a little, and
- 73. stepped across the boundary of furze and wild thorn and bramble bushes which separated it from the hillside. “No, I’m no tired at this hour of the morning,” he said, “but I’ve an awfu’ objection to dust, and the road is as powdery as a mill. My intention is to take a seat on this brae and let that carriage pass.” “Wait a little, then; it comes on very slowly; there must be some invalid in it, for the horses look good enough,” said Colin; and he turned his back to the approaching carriage, about which he was altogether indifferent, and faced round to the green slope, covered with trees and brushwood, upon which Lauderdale meant to rest. They were separated a little when the carriage came up, and neither of them paid much attention to it. Lauderdale was already half way up the slope, and Colin was standing by the side of the road, looking after him. Then all at once there was a sudden cry, and the horses made a dash forward, and rolled the equipage along at such a pace that its occupants were quite out of Colin’s sight when he turned round. This he did with a start so violent that the stones under his feet seemed suddenly to get in his way and trip him up: and Lauderdale for his part came down from the brae with a long leap and strange exclamation. “What was that?” they said to each other, in the same breath, and paused for a moment, and looked into each other’s faces, and listened. The carriage went on faster, raising a cloud of dust, and nothing was to be heard except the sound of the horses’ hoofs and the wheels. It was Colin who was the first to break the silence. He detached himself from among the stones and bushes, where he had got entangled in that moment of agitation, and sprang back again to the high road which lay before him, veiled in a cloud of dust. “It is simply absurd,” said Colin. “Lauderdale, I cannot imagine what you mean; you are enough to drive a man mad. Some one gives a chance outcry in passing, and you make up your mind that it is—— Good heavens! I never knew such folly!” cried the young man. He took off his hat without knowing it, and thrust his hair up over his forehead, and made an effort to take courage and regain his composure as he took breath. But it was very clear that Lauderdale had nothing to do with Colin’s excitement. He had himself heard the cry, and felt in his heart that it was no imagination. As he stood there in his pretended indignation the impulse of flight came upon him, mingled with a terror, which he could not explain nor comprehend. There was not a man in existence before whom he would have flown; but that little cry of recognition took away all his courage. He did not feel in
- 74. himself the strength to go forward, to venture upon a possible meeting. The blood which had rushed to his face for the first moment seemed to go back upon his heart and stifle it. He had made a step or two forward without thinking; but then he stopped himself, and wavered, and looked upon the road which lay quite tranquil behind him in the shadow of the hills. It seemed to him for the moment as if his only safety was in flight. As for Lauderdale, it took him all the time which Colin had occupied in these thoughts to get down from his elevation and return to his friend’s side. He for his part was animated and eager. “This is no her country,” said Lauderdale; “she’s a traveller, as we are. The carriage will stop at our next stage, but there’s no time to be lost;” and as he said these words he resumed his march with that long steady step which got over so much ground without remarking the hesitation of Colin, or what he had said. The young man himself felt that saving impulse fail him after the first minute. Afterwards, all the secondary motives came into his mind, and urged him to go on. Had he allowed that he was afraid to meet or to renew his relationships with Alice Meredith, supposing that by any extraordinary chance this should be she, it would be to betray the secret which he had guarded so long, and to betray himself; and he knew no reason that he could give for such a cowardly retreat. He could not say, “If I see her again, and find that she has been thinking of me, I shall be compelled to carry out my original mistake, and give up my brighter hopes,”—for no one knew that he had made any mistake, or that she was not to his eyes the type of all that was dearest in woman. “The chances are that it is all a piece of folly—a deception of the senses,” he said to himself instead—“something like what people have when they think they see ghosts. We have talked of her, and I have dreamed of her, and now, to be sore, necessity requires that I should hear her. It should have been seeing, to make all perfect;” and, after that little piece of self-contempt, he went on again with Lauderdale without making any objection. The dust which had been raised by the carriage came towards them like a moving pillar; but the carriage itself went rapidly on and turned the corner and went out of sight. And then Colin did his best to comfort and strengthen himself by other means. “Don’t put yourself out of breath,” he said to Lauderdale; “the whole thing is quite explainable. That absurd imagination of yours yesterday has got into both our heads. I don’t mind saying I dreamt of it all last night. Anything so wild was never put into a novel. It’s an optical illusion, or,
- 75. rather I should say, it’s an ocular illusion. Things don’t happen in real life in this kind of promiscuous way. Don’t walk so quick and put yourself out of breath.” “Did you no hear?” said Lauderdale. “If you hadna heard I could understand. As for me, I canna say but what I saw as well. I’m no minding at this moment about my breath.” “What did you see?” cried Colin, with a sudden thrill at his heart. “I’ll no say it was her,” said Lauderdale; “no but what I am as sure as I am of life that she was there. I saw something white laid back in the carriage, somebody that was ill; it might be her or it might be another. I’ve an awfu’ strong conviction that it was her. It’s been borne in on my mind that she was ill and wearying. We mightna ken her, but she kent you and me.” “What you say makes it more and more unlikely,” said Colin. “I confess that I was a little excited myself by those dreams and stuff; but nothing could be more improbable than that she should recognise you and me. Bah! it is absurd to be talking of her in this ridiculous way, as if we had the slightest reason to suppose it was she. Any little movement might make a sick lady cry out; and, as for recognising a voice!—All this makes me feel like a fool,” said Colin. “I am more disposed to go back than to go on. I wish you would dismiss this nonsense from your thoughts.” “If I was to do that same, do you think you could join me?” said Lauderdale. “There’s voices I would ken after thirty years instead of after three; and I’m no likely to forget the bit English tone of it. I’m a wee slow about some things, and I’ll no pretend to fathom your meaning; but, whether it’s daftlike or no, this I’m sure of, that if you make up to that carriage that’s away out of our sight at this moment, you’ll find Alice Meredith there.” “I don’t believe anything of the kind. Your imagination has deceived you,” said Colin, and they went on for a long time in silence; but at the bottom of his heart Colin felt that his own imagination had not deceived him. The only thing that had deceived him was that foolish feeling of liberty, that sense that he had escaped fate, and that the rash engagements of his youth were to have no consequences, into which he had deluded himself for some time past. Even while he professed his utter disbelief in this encounter, he was asking himself how in his changed circumstances he
- 76. should bear the old bridle, the rein upon his own proud neck? If it had been a curb upon his freedom, even at the moment when he had formed it—if it had become a painful bondage afterwards while still the impression of Alice’s gentle tenderness had not quite worn off his mind—what would it be now when he had emancipated himself from those soft prejudices of recollection, and when he had acknowledged so fully to himself that his heart never had been really touched? He marched on by Lauderdale’s side, and paid no attention to what his friend said to him; and nothing could be more difficult to describe than the state of Colin’s mind during this walk. Perhaps the only right thing, the only sensible thing he could have done in the circumstances, would have been to turn back and decline altogether this reawakening of the past. But then at six-and-twenty the mind is still so adverse to turning back, and has so much confidence in its own power of surmounting difficulty, and in its good star, and in the favour and assistance of all powers and influences in heaven and earth; and his pride was up in arms against such a mode of extricating himself from the apparent difficulty, and all the delicacy of his nature revolted from the idea of thus throwing the wrong and humiliation upon the woman, upon Alice, a creature who had loved him and trusted him, and whom he had never owned he did not love. Underneath all these complications there was, to be sure, a faint, sustaining hope that an encounter of this kind was incredible—that it might turn out not to be Alice at all, and that all these fears and embarrassments might come to nothing. With all this in his mind he marched on, feeling the sweet air and fresh winds and sunshine to be all so many spectators accompanying him perhaps to the turning-point of his life, where, for all he knew, things might go against him, and his wings be clipped, and his future limited for ever and ever. Perhaps some of Colin’s friends may think that he exhibited great weakness of mind on this occasion—and, indeed, it is certain that there are many people who believe, with great reason, that it is next thing to a sin to put honour in the place of love, or to give to constancy the rights of passion. But then, whatever a man’s principles may be, it is his character in most cases that carries the day. Every man must act according to his own nature, as says the Arabian sage. Sir Bayard, even, thinking it all over, might not approve of himself, and might see a great deal of folly in what he was doing; but, as for a man’s opinion of himself, that counts for
- 77. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com