See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/245346983

An introduction to UML profiles

Article · January 2004

CITATIONS READS

238 5,476

2 authors:

Lidia Fuentes Antonio Vallecillo

University of Malaga University of Malaga
267 PUBLICATIONS 3,208 CITATIONS 269 PUBLICATIONS 4,571 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Antonio Vallecillo on 21 May 2014.

The user has requested enhancement of the downloaded file.

 Vol. V, No. 2, April 2004
UPGRADE is the European Journal for the 2 From the Editors’ Desk
Informatics Professional, published bimonthly at The UPGRADE European Network: N przywitanie / Welcome!
<http://www.upgrade-cepis.org/> The members of the Editorial Team of UPGRADE describe the aims and scope of the network of journals
of CEPIS member societies, whose contents will enrich ours and offer a broader European view of ICT
Publisher to our readership.
UPGRADE is published on behalf of CEPIS (Council of
European Professional Informatics Societies,
<http://www.cepis.org/>) by NOVÁTICA
<http://www.ati.es/novatica/>, journal of the Spanish CEPIS
UML and Model Engineering
society ATI (Asociación de Técnicos de Informática Guest Editors: Jesús García-Molina, Ana Moreira, and Gustavo Rossi
<http://www.ati.es/>).
UPGRADE is also published in Spanish (full issue printed, some
articles online) by NOVÁTICA, and in Italian (abstracts and some Joint issue with NOVÁTICA*
articles online) by the Italian CEPIS society ALSI
<http://www.alsi.it> and the Italian IT portal Tecnoteca 3 Presentation
<http://www.tecnoteca.it/>. UML: The Standard Object Modelling Language – Jesús García-Molina, Ana Moreira,
UPGRADE was created in October 2000 by CEPIS and was first and Gustavo Rossi
published by NOVÁTICA and INFORMATIK/INFORMATIQUE,
bimonthly journal of SVI/FSI (Swiss Federation of Professional The guest editors introduce the monograph, that includes a series of papers that reflect the state of the art
Informatics Societies, <http://www.svifsi.ch/>). of UML (Unified Modeling Language). These papers illustrate different aspects of UML, ranging from
use cases to UML formalization, meta-modelling, profile definition, model quality, model engineering and
Editorial Team MDA (Model Driven Architecture.)
Chief Editor: Rafael Fernández Calvo, Spain, <[email protected]>
Associate Editors: 6 An Introduction to UML Profiles – Lidia Fuentes-Fernández and Antonio Vallecillo-
• François Louis Nicolet, Switzerland, <[email protected]> Moreno
• Roberto Carniel, Italy, <[email protected]>
This paper describes a set of steps to create a profile and argue the importance of profiles in MDA.
Editorial Board
Prof. Wolffried Stucky, CEPIS Past President
14 Aspect-Oriented Design with Theme/UML – Siobhán Clarke
Prof. Nello Scarabottolo, CEPIS Vice President The author describes her approach “Theme” to extending the UML in order to support the
Fernando Piera Gómez and modularisation of a designer’s concerns, including crosscutting ones.
Rafael Fernández Calvo, ATI (Spain)
François Louis Nicolet, SI (Switzerland) 21 In Search of a Basic Principle for Model Driven Engineering – Jean Bézivin
Roberto Carniel, ALSI – Tecnoteca (Italy) This article offers an interesting look at the essential features of this new software development paradigm.
English Editors: Mike Andersson, Richard Butchart, David 25 The Object Constraint Language for UML 2.0 – Overview and Assessment – Heinrich
Cash, Arthur Cook, Tracey Darch, Laura Davies, Nick Dunn, Hussmann and Steffen Zschaler
Rodney Fennemore, Hilary Green, Roger Harris, Michael Hird,
Jim Holder, Alasdair MacLeod, Pat Moody, Adam David Moss, This paper, authored by members of the OCL 2.0 team, gives an overview of the new aspects of the second
Phil Parkin, Brian Robson. version of this language and also provides a critical discussion of a few selected aspects of it.
Cover page designed by Antonio Crespo Foix, © ATI 2003 29 Developing Security-Critical Applications with UMLsec. A Short Walk-Through – Jan
Jürjens
Layout: Pascale Schürmann
The problems of creating high-quality critical systems is analysed in this paper, that shows how using
E-mail addresses for editorial correspondence: UML modelling can help solve them and presents a tool to support the proposed approach.
<[email protected]>, <[email protected]> or
<[email protected]> 36 On the Nature of Use Case-Actor Relationships – Gonzalo Génova-Fuster and Juan
E-mail address for advertising correspondence: Llorens-Morillo
<[email protected]> In this paper some issues are addressed that regard the relationships in which use cases and actors may
Upgrade Newslist available at take part, presently defined in UML as associations.
<http://www.upgrade-cepis.org/pages/editinfo.html#newslist> 43 Metrics for UML Models – Marcela Genero, Mario Piattini-Velthuis, José-Antonio
Copyright Cruz-Lemus, and Luis Reynoso
© NOVÀTICA 2004. All rights reserved. Abstracting is permitted This paper offer a vision of the state of the art of metrics for measuring quality of some basic UML
with credit to the source. For copying, reprint, or republication diagrams (such as class, state and use case diagrams) and OCL expressions.
permission, write to the editors.
49 Using Refactoring and Unification Rules to Assist Framework Evolution – Mariela I.
The opinions expressed by the authors are their exclusive
responsibility.
Cortés, Marcus Fontoura, and Carlos J.P. de Lucena
In their paper the authors use UML-F, a UML designed for describing frameworks, to present two
ISSN 1684-5285
techniques aimed at facilitating framework maintenance and evolution.

Mosaic

UPGRADE European Network

From “Pro Dialog” (Poland):
56 Parallel Programming Support System for Transputers – Educational Software – Mikolaj
Szczepanski and Rafal Walkowiak
The paper presents a method for integrating applications data, aimed at data aggregation and transfer in
software applications when integration of those applications has to be fast and should be done with
minimum source code modifications.
News Sheet
61 ENISA: The European Network and Information Security Agency created
Next issue (June 2004): 61 News from EUCIP and ECDL
“Digital Signature”
* This monograph will be also published in Spanish (full issue printed; summary, abstracts and some articles online) by
(The full schedule of UPGRADE is NOVÁTICA, journal of the Spanish CEPIS society ATI (Asociación de Técnicos de Informática) at <http://www.ati.es/
novatica/>, and in Italian (online edition only, containing summary abstracts and some articles) by the Italian CEPIS society
available at our website) ALSI and the Italian IT portal Tecnoteca at <http://www.tecnoteca.it>.

1
 UML and Model Engineering

An Introduction to UML Profiles

Lidia Fuentes-Fernández and Antonio Vallecillo-Moreno

UML (Unified Modeling Language) has become one of the most widely used standards for specifying and
documenting information systems. However, the fact that UML is a general purpose notation may limit its
suitability for modelling some particular domains, for which specialized languages may be more
appropriate. UML provides a set of extension mechanisms to address this issue, which allow the
customisation and extension of its own syntax and semantics in order to adapt to certain application
domains. In this paper we examine the extension mechanisms which are used to define UML Profiles. We also
discuss the usefulness and relevance of UML Profiles in the context of Model Driven Architecture (MDA®).

Keywords: MDA, UML Modelling, UML Profiles. provided by OMG for defining object-based visual languages
(i.e. the same mechanisms that have been used for defining
1 Introduction UML and its metamodel). In this way, the syntax and semantics
The increasing complexity of information systems is of the elements of the new language are defined to fit the
challenging the way software architects and engineers work. specific characteristics of the domain. The second alternative is
After initially being concerned more about the structure and based on UML specialisation, in which some of the language’s
quality of programming code, software engineers are now elements are specialised, imposing new restrictions on them,
focusing their attention on the modelling aspects of the system while respecting the UML metamodel and leaving the original
development process. Models provide abstractions of systems semantics of the UML elements unchanged (i.e. the properties
which help deal with larger and more complex applications in of the UML classes, associations, attributes etc. will remain the
simpler ways, regardless of how they are implemented and
distributed and whichever the final execution platform or tech-
nology used. Lidia Fuentes-Fernández received her MSc degree in Compu-
ter Science from the Universidad de Málaga, Spain, in 1992 and
A model is a description of (part of) a system written in a
her doctorate in 1998 from the same university. She has been an
well-defined language. A well-defined language is a language
Associate Professor in the Department of Computer Science of the
with well-defined form (syntax) and meaning (semantics), Universidad de Málaga since 1993. Her research interests centre
which is suitable for automated interpretation by a computer around Component-Based Software Development, frameworks,
[1]. aspect orientation, software agents and multimedia applications.
The OMG (Object Management Group) defines several She has also participated in several international conferences as a
modelling languages, among which UML (Unified Modeling speaker, reviewer, and chairperson. Her most significant publica-
Language) [2] is probably the one most widely accepted and tions are to be found in international journals published by ACM
used. UML is a visual language for specifying, constructing and IEEE, such as IEEE Internet Computing, IEEE Transactions
and documenting the artefacts of systems. It is a general on Software Engineering, ACM Computing Surveys or Software
purpose modelling language that can be used with all major Practice and Experience. She has actively participated in several
research projects and she has also done consulting work for tele-
object and component methods and can be applied to all appli-
communication companies such as Telefónica and Retevisión,
cation domains (e.g. health, finance, telecom, aerospace) and
Spain. <[email protected]>
implementation platforms (e.g., CORBA – Common Object Antonio Vallecillo-Moreno holds BSc and MSc degrees in
Request Broker Architecture –, J2EE – Java 2 Enterprise Mathematics, and a PhD degree in Computer Science. Most of his
Edition –, .NET). professional experience has been in the computer industry, where
There are situations, however, in which a language that is so he has worked for many years in various international companies
general and of such a broad scope may not be appropriate for both in Spain and in the UK. He now works at the Universidad de
modelling applications of some specific domains. This is the Málaga, Spain, where he is currently an associate professor, and
case, for instance, when the syntax or semantics of the UML he has also been Head of the University IT Services. His research
elements cannot express specific concepts of particular interests include component-based software development, open
systems, or when we want to restrict or customize some of the distributed processing, and the industrial use of formal methods.
He is the Universidad de Málaga representative for ISO, the
UML elements which are usually too abundant and too general.
OMG, and AENOR (the Spanish National Body for Standardiza-
OMG defines two possible approaches for defining domain-
tion), and a member of several professional organizations, includ-
specific languages. The first one is based on the definition of a ing the ACM and the IEEE. <[email protected]>
new language, an alternative to UML, using the mechanisms

6 UPGRADE Vol. V, No. 2, April 2004 © Novática

 UML and Model Engineering

same; new constraints will simply be added to their original This is an introductory paper and is intended only as a brief
definitions and relationships). Syntactic sugar can also be used presentation of UML Profiles to show something of their poten-
in a Profile in the form of icons and symbols for newly defined tial. We refer interested readers to the UML 2.0 Infrastructure
elements. Specification (OMG document ptc/03-12-01) for more techni-
The first approach is that followed by languages such as cal information and further details on the subject.
CWM (Common Warehouse Metamodel) [3], as the semantics This paper is structured in six sections, this introduction
of some of the language constructs do not match the semantics being the first. Section 2 presents the four-layered conceptual
of the corresponding UML model elements. These new architecture defined by OMG for modelling systems and defin-
languages are defined using the MOF (Meta Object Facility), a ing modelling notations such as UML or CWM. Section 3
language specifically designed for defining object-based mod- introduces UML Profiles, as defined in UML 2.0., and Section
elling languages. As we will discuss later, UML itself is defined 4 provides some brief guidelines for the definition and usage of
using the MOF. UML Profiles. The role of UML Profiles in MDA is discussed
In order to support the second alternative, UML provides a in Section 5. Finally, Section 6 draws some conclusions and
set of extension mechanisms (stereotypes, tagged values, and outlines some of the still unresolved limitations of UML
constraints) for specializing its elements, allowing customized Profiles.
extensions of UML for particular application domains. These
customisations are sets of UML extensions grouped into UML 2 OMG’s Metamodel Architecture
Profiles. In the previous Section, a model was defined as a descrip-
Each alternative has its advantages and disadvantages. Defin- tion of (part of) a system written in a well-defined language.
ing a tailor-made language will produce a notation that will The problem is how to define such a well-defined language.
perfectly match the concepts and nature of the specific applica- The solution to this problem is well known in the case of
tion domain. However, as the new language does not respect textual languages, whose grammar is described using the
UML semantics, it will not allow the use of commercial UML Backus Naur Form (BNF) notation. However, this notation
tools for drawing diagrams, generating code, reverse engineer- does not work for defining graphical languages, for which a
ing, and so forth. Conversely, UML Profiles (which are amena- different mechanism is needed. This mechanism is called
ble to be handled by commercial UML tools) may not provide metamodelling.
such an elegant and perfectly fitting notation as may be As a general rule we can suppose that a model describes the
required for those systems. It is not therefore always easy to elements and types of elements that might exist in a system. For
decide when to create a new language and when to define a set example, if we define “Person” as a class in a model, we can
of extensions to the standard UML metamodel by grouping use instances of that class in our system (such as “John” or
them into a UML Profile. In our experience, unless there is a “Mary”). Following that principle, if the system we want to
real need to deviate from the UML metamodel, the benefits of model is a UML system, then the elements comprising it will
using UML Profiles undoubtedly outweigh their limitations. be “Class”, “Association”, “Package”, etc. But who defines
In this paper we will introduce the extension mechanisms those elements, and how are they defined?
used in the definition of a UML Profile. We will also discuss the The OMG defines a four-layered architecture that separates
usefulness and importance of UML Profiles in the context of the different conceptual levels making up a model: the instanc-
Model Driven Architecture (MDA®) [4]. MDA is an OMG es, the model of the system, the modelling language, and the
initiative that provides an approach to system development metamodel of that language. In OMG terminology these layers
based on model definition and transformations. It is model are called M0, M1, M2, and M3.
driven because it provides a means for using models to direct • Layer M0: Instances. The M0 layer models the running
the course of understanding, design, construction, deployment, system and its elements are the actual instances that exist in
operation, maintenance and modification. As we will see, UML the system. These instances are, for example, customer
Profiles play an important role in MDA. “John” who lives at “1 Oxford St., London” and buys the
UML Profiles were originally defined in version 1 of UML, copy number “123” of the book “Ulysses”.
although their applicability and widespread use by the software • Layer M1: The model of the system. The elements of the
community was limited because they lacked either an unam- M1 layer are models. An example would be a UML model
biguous definition or precise utilization guidelines [5]. The new of a software system. The M1 layer defines the classes
version of UML (2.0) addresses these issues, providing “Customer”, “Address”, “Purchase” and “Book”, each one
substantial improvements over the UML Profiles of UML with its associated attributes (“address”, “copy no.”, “title”,
version 1. For instance, among the improvements introduced, etc.). There is a strong relationship between the M0 and M1
there is a better conceptual alignment with the MOF, and with layers. The elements of the M1 layer are classifications of
the UML metamodel (UML Profiles can extend not only UML elements of the M0 layer. Likewise, each element at the M0
but also any other MOF-defined language, or even other UML layer is always an instance of an element at the M1 layer.
Profiles). Also the UML model elements to be specialized are • Layer M2: The model of the model (the metamodel). The
now more clearly and conveniently specified, and the profile elements of layer M2 are the modelling languages. Layer
notation has been enhanced. M2 defines the concepts that are used to model an element
of layer M1. In the case of UML, layer M2 defines “Class”,

© Novática UPGRADE Vol. V, No. 2, April 2004 7

 UML and Model Engineering

“Attribute”, “Association”, etc. Just as there was a close • To add semantics left unspecified in the metamodel (such as
relationship between layers M0 and M1 so there is a close how to deal with priority when receiving signals in a state
relationship between M1 and M2 layers. Every element at machine).
M1 is an instance of an M2 element, and every element at • To add semantics that do not exist in the metamodel (such as
M2 categorizes M1 elements. The model that resides at the defining a timer, clock, or continuous time)
M2 layer is called a metamodel. • To add constraints that restrict the way you can use the met-
• Layer M3: The model of M2 (the meta-metamodel). amodel and its constructs (such as disallowing actions from
Finally, layer M3 defines the concepts that can be used to being executable in parallel within a single transition, or
define modelling languages. Thus, the concept of UML forcing the existence of certain associations between model
Class (that belongs to M2) can be considered as an instance classes)
of the corresponding element of M3, which precisely defines • To add information that can be used when transforming one
what a Class is and its relationships with the rest of the UML model to another model or to code (such as defining map-
concepts (e.g., a UML Class is a classifier, and therefore has ping rules between a model and Java code).
an associated behaviour, and a set of attributes and methods, A UML Profile is defined as a UML package stereotyped
etc.). “profile”, that can extend either a metamodel or another Profile.
The modelling language defined for describing the M3 UML Profiles are defined in terms of three basic mechanisms:
elements is called MOF (Meta-Object Facility) [6]. MOF is a stereotypes, constraints, and tagged values.
language to define modelling languages, such as UML, CWM, Let’s take a look at an example to define and illustrate all
or even MOF itself. Such languages can be considered as these concepts (see Figure 1). Suppose we want to add two new
instances of MOF. elements to our UML models – say, weights and colours – and
To summarise, a well-defined language (such as UML) can we want to do so in a precise and consistent way. Furthermore,
be described by its metamodel. What MOF provides is a we may want to incorporate some particular properties and
language to describe metamodels. If we wanted to define a new requirements of such elements, such as the actual colour of a
object-based visual language other than UML we would use coloured element, the weight of a weighed element, and a
the MOF to describe its metamodel. restriction that states that coloured associations can only be
defined between classes of the same colour as that of the asso-
3 UML Profiles ciation. For the sake of simplicity, we will assume here that
For when we need to define a new language to model a only classes and associations can be coloured, and that only
system that either restricts the number of UML elements or associations can be weighed.
adds some constraints or syntactic sugar to them while respect- The WeightsAndColours profile defines these two elements:
ing the original semantics, we do not need to create a new (1) First, a stereotype is defined by a name and by the set of
language from scratch using the MOF. Instead, UML can easily metamodel elements it can be attached to. Graphically,
be customized by using a set of extension mechanisms that
UML itself provides. More precisely, the Profiles package
included in UML 2.0 defines a set of UML artefacts that allows
the specification of an MOF model to deal with the specific «profile»
concepts and notation required in particular application WeightsAndColours
domains (e.g., real-time, business process modelling, finance,
etc.) or implementation technologies (such as .NET, J2EE, or
CORBA). It should be noted that UML Profiles allow the «metaclass» «stereotype»
customisation of any MOF defined (not just UML defined) Class Coloured
metamodel. Similarly, a UML Profile can also specify another colour: Colour
UML Profile.UML 2.0 outlines several reasons why a system
developer should want to customize his metamodel: «metaclass» «stereotype»
• To have a terminology that is adapted to a particular Association Weighed
platform or domain (for example, being able to capture EJB
weight: Integer
(Enterprise Java Beans) terminology such as “home inter-
face”, “enterprise java beans”, “archive” etc.). «enumeration»
• To have a syntax for constructs that do not have a notation Colour
(as is the case of actions in UML).
green
• To have a different notation for already existing symbols,
yellow
more appropriate for the target application domain (such as red
being able to use a picture of a computer instead of the ordi- blue
nary UML node symbol to represent a computer in a net-
work). Figure 1: Example of UML Profile.

8 UPGRADE Vol. V, No. 2, April 2004 © Novática

 UML and Model Engineering

stereotypes are defined within boxes, stereotyped «stereo- for CCM (CORBA Component Model), the UML Profile for
type». In the example, the WeightsAndColours UML EDOC (Enterprise Distributed Object Computing), the UML
Profile defines two stereotypes, Colored and Weighed, and Profile for EAI (Enterprise Application Integration), and the
indicates that both UML classes and associations can be UML Profile for Scheduling, Performance, and Time. Some
coloured (i.e, stereotyped «Colored»), but only associa- other UML Profiles have already been defined, and are now in
tions can have an associated weight (i.e, stereotyped the process of being approved by the OMG, so the number of
«Weighed»). Metamodel elements are indicated by classes OMG Profiles is rapidly growing. One of the benefits of UML
stereotyped «metaclass». The notation for an extension is Profiles is that they can be directly reused in any application, as
an arrow pointing from a stereotype to the extended class, we shall see later.
where the arrowhead is shown as a solid triangle. An Other UML Profiles have been defined by private organiza-
Extension may have the same adornments as an ordinary tions and software companies, and are currently being used in
association, but navigability arrows are never shown. many application domains (hence becoming de facto stand-
(2) Constraints can be associated to stereotypes, imposing ards). This is the case, for instance, of the “UML/EJB Mapping
restrictions on the corresponding metamodel elements. In Specification”, a UML Profile for EJB applications that has
this way a designer can define the properties of a “well- been defined by JCP (Java Community Process). UML Profiles
formed” model. For instance, the aforementioned restric- for programming languages such as Java or C# are also availa-
tion on the colours of the classes joined by a coloured ble.
association can be expressed by the following OCL [7] Each of these profiles defines a precise way to use UML in a
constraint: particular context. For instance, the UML Profile for CORBA
context UML::InfrastructureLibrary::Core:: defines a way in which UML can be used to model CORBA
Constructs::Association interfaces and artefacts; and the UML Profile for Java defines a
inv : self.isStereotyped(“Coloured”) implies way of modelling Java constructs and applications using UML.
self.connection->forAll Furthermore, such Profiles can be combined within the MDA
(isStereotyped(“Coloured”)
context to define a chain of model transformations: from a
implies color=self.color)
model of the system independent from the implementation
Constraints can be expressed in any language, including platform, to the corresponding model of the system on a
natural language or the OCL (Object Constraint Lan- CORBA platform; and then from the CORBA model to a
guage). OCL is a language, now part of UML, adopted by model of its implementation using Java (which “almost”
the OMG for expressing constraints and properties of coincides with its implementation).
model elements. Examples of constraints include pre- and
post-conditions of operations, invariants, derivation rules 4 Definition of UML Profiles
for attributes and associations, the body of query opera- In this section we present some brief guidelines for the
tions, etc. The word “Constraint” in the name of the lan- definition and use of UML Profiles. The UML 2.0 specification
guage comes from its first version, where only constraints [8] merely defines the concept of Profile and the elements that
could be expressed. New OCL 2.0 has evolved to a more comprise a Profile definition. However, we consider that users
expressive and powerful query language, whose expres- may also need some hints and recommendations to help them
siveness is similar to that of SQL. define a UML Profile for a given platform or application
(3) Finally, a tagged value is an additional meta-attribute that domain.
is attached to a metaclass of the metamodel extended by a The steps that we propose for defining a UML Profile are the
Profile. Tagged values have a name and a type, and are following:
associated to a specific stereotype. In the example, the 1. First of all, we need to define the set of elements that will
stereotype «Weighed» has an associated tagged value comprise our platform or system, and the relationships
named “weight”, of type Integer, that represents the actual between them, which can be expressed in terms of a meta-
weight of the stereotyped association. Graphically, tagged model. If we do not have such a metamodel, we can easily
values are specified as attributes of the class that defines define it using the standard mechanisms offered by UML
the stereotype. (classes, hierarchy relationships, associations, etc.) in the
A UML Profile is a set of these extension mechanisms, normal way, i.e., as if we did not intend to build a UML
grouped into a UML package stereotyped «profile». As Profile for it. In the metamodel we need to include the
mentioned earlier, note that these mechanisms allow the exten- definition of the domain entities, the relationships between
sion of the syntax and semantics of UML elements but must them, and the constraints that govern both the structure and
respect their original semantics, i.e., UML Profile cannot behaviour of these entities.
change the semantics of UML elements. However they can be 2. Once we have our domain metamodel we are ready to
very useful when customisations of UML are required for define the UML Profile. We will include a stereotype for
particular application domains. each relevant element of the metamodel that we want to
Several UML Profiles currently exist and are available for include in the Profile, inside the «profile» package. In order
public use. Some of them have even been adopted and stand- to clarify the relationship between the metamodel and the
ardized by the OMG, such as the UML Profile for CORBA and Profile, these stereotypes will be named after the corre-

© Novática UPGRADE Vol. V, No. 2, April 2004 9

 UML and Model Engineering

«metamodel» «profile»
MyTopology TopologyProfile

+localnodes «metaclass» «stereotype»

Node Class Node
*
location: String location: String

LocalEdge
«stereotype»
+target MainNode 1 MainNode
*
* +source
«stereotype»
Edge Edge
«metaclass»
Figure 2: Metamodel Describing an Application Domain. Association
«stereotype»
LocalEdge

sponding elements of the metamodel. In fact any element Figure 3: UML Profile Described as a UML Package.
that we might need to define the metamodel can later be
tagged with a stereotype.
3. Note that we will only represent with a stereotype the
elements of the UML metamodel we are extending. Exam- The UML Profile that represents this metamodel will be
ples of these elements are classes, associations, attributes, described as a UML package, with the stereotype «profile» (see
operations, transitions, packages, etc. In this way, each Figure 3.)
stereotype will be applied to the UML metaclass that we This Profile defines four different stereotypes that corre-
have used in the domain metamodel for defining a concept spond to the classes and associations defined in the original
or a relationship. metamodel, as well as the UML metaclasses to which these
4. We should define the attributes that appear in the meta- stereotypes can be applied. These metaclasses are part of the
model as tagged values, and include the corresponding metamodel to be extended, in this case the UML metamodel.
types and initial values. The stereotype Node also has a tagged value (location) of
5. Profile constraints are taken from the domain restrictions. type String.
For example, the association multiplicities that appear in In addition to stereotypes and tagged values, we need to spec-
the domain metamodel or the business rules of the applica- ify the constraints of the Profile. Coming back to our example,
tion are used to define the corresponding OCL constraints. the restrictions of the metamodel result in the following
Let us illustrate the use of these guidelines with another constraint specification.
example. Suppose we need to model the connections between context UML::InfrastructureLibrary::Core::
the elements of an information system with a star topology, in Constructs::Class
which nodes connect to central nodes which can then be inv : – Nodes should be locally
connected between each other. In such a domain we would connected to exactly one MainNode
self.isStereotyped(“Node”)
define nodes (represented by class Node) connected by links
implies
that can be local nodes (LocalEdge) if they connect nodes from
self.connection->select
the same star with its central node, or remote nodes (Main- (isStereotyped(“LocalEdge”))->
Node) if they connect central nodes between each other. Each size = 1 and
node is identified by its position (location). We impose the self.connection->select
constraint that every node of the same star must share the same (isStereotyped(“Edge”))-> isEmpty
geographic location. In Figure 2 the metamodel describing this context UML::Infrastructure
application domain is depicted. Library::Core::Constructs::
As part of this metamodel, we also need to specify the set of Association
constraints that govern its structure – i.e., its “well-formed- inv : self.isStereotyped(“LocalEdge”)
ness” rules. In this case, these constraints can be described in implies
self.connection->select
OCL as follows:
(participant.isStereotyped
context MyTopology::MainNode
(“Node”) or
inv:self.localnodes ->forAll (n : Node |
participant.isStereotyped
n.location = self.location)
(“MainNode”) ) ->
inv:self.target ->forAll (n : MainNode |
forAll(n1, n2 | n1.location =
n.location <> self.location)
n2.location)

10 UPGRADE Vol. V, No. 2, April 2004 © Novática

 UML and Model Engineering

inv : self.isStereotyped(“LocalEdge”)
implies
self.connection-> exists «profile» «profile»
WeightAndColours TopologyProfile
(participant.isStereotyped
(“MainNode”) and
multiplicity.min=1 and «apply»
multiplicity.max=1) «apply»
inv : self.isStereotyped(“Edge”)
implies
self.connection->select(participant. MyApplication
isStereotyped(“Node”))->isEmpty and
self.connection->select
(participant.isStereotyped Figure 4: Application Making Use of UML Profiles.
(“MainNode”) ) ->
forAll(n1, n2 | n1.location <>
n2.location)
Note that the constraint contexts are the UML elements that are now modelling the different aspects of a system and then
we are customizing for our particular model. Customisation is defining transformations from one model to another one in a
therefore achieved by adding semantic constraints to them. One way that allows them to be automated. We will therefore focus
of the most important advantages of using UML Profiles is that on model definition, leaving implementation details until the
these constraints can be checked in the final system model for end, which makes these models more portable, more adaptable
conformity with a given Profile. This means that UML Profiles to new technologies (e.g. .NET, J2EE or Web Services) and
always describe a “well-formed” model for an application more interoperable with other systems regardless of the tech-
domain, and ensures that a given model will always comply nology they use.
with the syntactic or semantic constraints defined by whichever MDA defines three conceptual levels. At the first level,
UML Profile is used. system requirements are modelled in a Computation Independ-
Once we have defined a UML Profile, we use a dependency ent Model (CIM) that defines the system within an operating
relationship (stereotyped as «apply») to show we are using this environment. At the next level we find the Platform Independ-
Profile in a specific application. For example, the diagram in ent Model (PIM). A PIM describes the system functionality, but
Figure 4 shows an application that makes use of the UML Pro- without considering details about where and how this system is
files we have defined before. going to be implemented (e.g. a PIM can be independent from
This application can therefore describe diagrams like the fol- system distribution and the supporting object platform, such as
lowing one which shows two classes linked by an association. CORBA, J2EE, .NET, etc.). The aim is then to transform a PIM
Both classes are stereotyped as nodes of a star topology. One of into a target platform dependent model known as a PSM (Plat-
them is also a central node. Notice how we specify the value of form Specific Model). In this way we obtain a high degree of
tagged values associated to stereotyped elements, by including independency between the description of functionality and the
notes that show the corresponding stereotype, the name of the implementation details of the target platform.
tagged value, and the value assigned to it. The most important advantage of this approach is that it
We can also show tagged values related to different stereo- allows software engineers to define automatic transformations
types in the same UML note as the entity CentralOffice illus- from PIMs to PSMs. By inputting the system PIM, a descrip-
trates in Figure 5. tion of the PSM to be used to implement the system, and a set
of transformation rules, we will be able to implement a system
5 MDA and UML Profiles in the most automated way possible.
MDA (Model Driven Architecture) is a recent initiative UML Profiles can play a particularly important role in
from the OMG that supports the definition of models as first describing the platform model and the transformation rules
class elements for the design and implementation of systems. between models. If we use UML Profiles to specify the model
According to the MDA approach, the most important activities of a specific platform, this will guarantee that the derived

«Node» «Weighed» «MainNode»

location=”uma.es” weight=10 location=”uma.es”

«Coloured»
«Node» 1..10 1 «MainMode, Coloured» colour=red
Branch CentralOffice
«LocalEdge, Weighed»

Figure 5: Tagged Values Related to Different stereotypes in the Same UML Note.

© Novática UPGRADE Vol. V, No. 2, April 2004 11

 UML and Model Engineering

ple we may specify that classes stereotyped as «Node» will be

MyApplication
(PIM) Java classes, but those stereotyped as «MainNode» will be
transformed into a «EJBEntityBean» component. According to
the UML Profile of the EJB model we must include the defini-
UML Profile of
the Platform tion of the «EJBRemoteInterface», the «EJBEntityHomeInter-
Transformation (EJB) face» and the «EJBImplementation» classes within the
«EJBEntityBean» component. On the other hand, our applica-
tion requires that the attributes of this component must be made
persistent using the EJB container model. This can be done
simply by marking the attributes that we want to make persist-
MyApplication
in EJB (PSM) ent, in this case the location attribute, with the «EJBCmpField»
stereotype, by binding the value Container to the EJBPersisten-
ceType tag indicating that the persistence property will be man-
Figure 6: Transformation of a System According to an UML aged by the EJB container.
Profile for EJB.

6 Conclusions
In this paper we have presented UML Profiles as a very
models will be consistent with UML. In fact, the key to a suitable way to extend UML in order to customize it for specif-
successful application of MDA is to use standards whenever ic platforms and application domains. We have also illustrated
possible (standard models and standard UML Profiles for the importance of UML Profiles in the development of Model
implementation languages or platforms). As we mentioned Driven Applications (MDA) which place system modelling,
earlier, UML Profiles for some well known component not coding, at the cornerstone of system development. The role
platforms are currently available, such as CORBA, CCM, EJB, of UML Profiles is crucial in MDA model definition and trans-
etc. formation.
The mechanisms provided by UML Profiles are very well UML 1.5 is currently the version which is standardized and
suited to describing models for any implementation platform. supported by commercial tools. However, the new UML
We need to define the mapping between each element of the version 2.0 is already defined and in the process of being
PIM, and the stereotypes, constraints and tagged values that approved as an OMG standard. This new version is far more
make up the platform Profile. complete than the previous one, offering a great many advan-
The idea is to use the stereotypes of a platform Profile to tages and successfully addressing many of the limitations of
“mark” the elements of a PIM and produce the corresponding version 1.5. For example, this new version has a better meta-
PSM, already expressed in terms of the elements appearing in model structure, a more precise semantic definition of many of
the target platform. A mark represents a concept in the PSM, the UML concepts, better alignment with the MOF metamodel
and is applied to an element of the PIM to indicate how it must and with the rest of the OMG family of languages, extensions
be transformed into the target PSM. Marks can also be used to to manage software architectures and diagram exchange, etc.
specify quality of service or any extra functional requirements Current tools allow the definition and usage of UML Profiles,
applicable to the final implementation. For example, some but only at a diagrammatic level, i.e., only graphically. This
elements of the PIM could be marked as persistent or under means that verification of constraints associated to stereotypes
special security conditions. is not yet supported, and therefore well-formed rules can be
The set of marks and the transformation rules governing the neither checked nor enforced. The user can therefore never be
use of marks must be specified in a structured way and normal- sure whether or not the system being specified using a given
ly they are provided as part of the UML Profile of the target Profile is conformant with Profile rules. It will still be some
platform. If the UML Profile of a platform includes the specifi- time before new tools appear that will support the definition of
cation of operations, then the transformation rules may be spec- UML 2.0 Profiles, manage the definition of new stereotypes
ified using operations. and tags properly and allow constraints defined by the Profiles
Coming back to our example, according to MDA principles to be checked. Once such tools are available UML Profiles will
our system MyApplication, which so far has no details about be recognised as good practice for systems specification and
the target implementation platform, should now be transformed implementation.
into one of the available platforms. In this particular case,
shown in Figure 6, we are going to transform this system Acknowledgements
according to the UML Profile for EJB [9]. To do this, we need CORBA™, CWM™, MDA™, UML™, and MOF™ are either
to decide for each entity of our model whether it is going to be registered trademarks or trademarks of the Object Management
Group, Inc. in the United States and/or other countries.
transformed into a Bean or into a simple Java class. For exam-

12 UPGRADE Vol. V, No. 2, April 2004 © Novática

 UML and Model Engineering

References [5]
[1] L. Fuentes, A. Vallecillo and J.M. Troya. Using UML Profiles for
A. Kleppe, J. Warmer and W. Bast. "MDA Explained: The Model Documenting Web-Based Application Frameworks. Annals of
Driven Architecture™: Practice and Promise", Addisson-Wesley, Software Engineering, 13: pp. 249–264, 2002.
2003. [6]
[2] Object Management Group. Meta Object Facility (MOF) Speci-
ISO/IEC. Unified Modeling Language (UML). Version 1.5. Inter- fication. OMG document: formal/2002-04-03. 2003.
national Standard ISO/IEC 19501. [7]
[3] Object Management Group. Object Constraint Language Specifi-
Object Management Group. Common Warehouse Metamodel cation. OMG document ad/02-05-09, 2002.
(CWM) Specification. OMG document, ad/2001-02-01. 2001. [8]
[4] Object Management Group. UML 2.0 Infrastructure Specifica-
Object Management Group. MDA Guide Version 1.0.1. OMG tion, OMG document ptc/03-09-15, 2003.
document, omg/2003-06-01, 2003. [9]
Sun Java Community Process JSR-26. Public Draft. UML Profile
for EJB, 2001.

© Novática UPGRADE Vol. V, No. 2, April 2004 13

View publication stats