≪UML≫ 2002 — The Unified Modeling Language: Model Engineering, Concepts, and Tools 5th International Conference Dresden, Germany, September 30 – October 4, 2002 Proceedings [1 ed.] 3540442545, 9783540442547

Citation preview

Lecture Notes in Computer Science Edited by G. Goos, J. Hartmanis, and J. van Leeuwen

2460

3

Berlin Heidelberg New York Barcelona Hong Kong London Milan Paris Tokyo

Jean-Marc Jézéquel Heinrich Hussmann Stephen Cook (Eds.)

«UML» 2002 – The Unified Modeling Language Model Engineering, Concepts, and Tools 5th International Conference Dresden, Germany, September 30 – October 4, 2002 Proceedings

13

Series Editors Gerhard Goos, Karlsruhe University, Germany Juris Hartmanis, Cornell University, NY, USA Jan van Leeuwen, Utrecht University, The Netherlands Volume Editors Jean-Marc Jézéquel Irisa - Univesité de Rennes 1 Campus de Beaulieu, 35042 Rennes cedex, France E-mail: [email protected] Heinrich Hussmann Technische Universität Dresden, Fakultät Informatik Mommsenstr. 13, 01062, Dresden, Germany E-mail: [email protected] Stephen Cook IBM United Kingdom Ltd Sunbury House, 79 Staines Road West Sunbury-on-Thames, Middlesex TW16 7AN, UK E-mail: sj [email protected] Cataloging-in-Publication Data applied for Die Deutsche Bibliothek - CIP-Einheitsaufnahme The unified modeling language : model engineering, concepts, and tools ; 5th international conference ; proceedings / "UML" 2002, Dresden, Germany, September 30 - October 4, 2002. Jean-Marc Jézéquel ... (ed.). - Berlin ; Heidelberg ; New York ; Hong Kong ; London ; Milan ; Paris ; Tokyo : Springer, 2002 (Lecture notes in computer science ; Vol. 2460) ISBN 3-540-44254-5 CR Subject Classification (1998): D.2, D.3, K.6, I.6 ISSN 0302-9743 ISBN 3-540-44254-5 Springer-Verlag Berlin Heidelberg New York This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer-Verlag. Violations are liable for prosecution under the German Copyright Law. Springer-Verlag Berlin Heidelberg New York, a member of BertelsmannSpringer Science+Business Media GmbH http://www.springer.de © Springer-Verlag Berlin Heidelberg 2002 Printed in Germany Typesetting: Camera-ready by author, data conversion by DA-TeX Gerd Blumenstein Printed on acid-free paper SPIN: 10871209 06/3142 543210

Preface

Five years on from its adoption in 1997 by the Object Management Group (OMG), the Unified Modeling Language is the de facto standard for creating diagrammatic models of software systems. More than 100 books have been written about UML, and it is taught to students throughout the world. The definition of UML version 2 is well under way, and should be largely completed within the year. This will not only improve and enhance UML itself, including standard facilities for diagram interchange, but also make it fully integrated with other modeling technologies from the OMG, such as Meta-Object Facility (MOF) and XML Metadata Interchange (XMI). The Object Constraint Language, which has become an important vehicle for communicating detailed insights between UML researchers and practitioners, will have a much expanded specification and be better integrated with the UML. The popularity of UML signifies the possibility of a shift of immense proportions in the practice of software development, at least comparable to the shift from the use of assembly language to “third-generation” or “high-level” programming languages. We dream of describing the behavior of software systems in terms of models, closely related to the needs of the enterprise being served, and being able to routinely translate these models automatically into executing programs on distributed computing systems. The OMG is promoting Model-Driven Architecture (MDA) as a significant step towards this vision, and the MDA concept has received considerable support within the IT industry. But to turn such a dream into reality demands many breakthroughs. We only understand how to transform models into code for some special cases. Numerous practical difficulties such as problem determination, performance, scaleability and change management stand in the way. We can model program designs, but are only beginning to understand how to model other artifacts involved in the end-to-end vision such as architectures, business processes, business rules, software components, and organizations. We have interoperability standards by which computers can communicate world-wide, but these leave vast numbers of questions unanswered in areas such as security, quality of service, and verification. The day-to-day usage of UML, by and large, is still just to draw pictures and to convert them manually or at best semi-automatically into code. For real programmers, code remains king. The ≪UML≫ series of conferences is the leading forum for researchers and practitioners to work together to present, discuss, and develop innovative ideas about UML and related technologies. This conference, the fifth in the series, presented an ideal opportunity to move forward the vision of model-driven development, and to continue to enrich our understanding of how to implement, apply, and develop UML, leading to innovations both in research and in industrial practice.

VI

Preface

In total 127 abstracts and 99 papers were submitted to this year’s conference, of which 25 research papers and 5 experience papers were selected by the program committee for presentation. As in previous years, this year’s conference included a two-day tutorial and workshop session, in which six tutorials and five workshops were scheduled, as well as two panels. The primary purpose of these sessions was to provide a more informal forum for discussing state-of-the-art research in UML. Topics included: Metamodeling, Pattern Oriented Analysis and Design, Dependability Modeling and Evaluation, Establishing Inspection Criteria, Scalable System Designs, Code Generation, Critical Systems Development, Aspect Oriented Modeling, Software Model Engineering, Modeling Non-functional Aspects, Consistency Problems, Model-Driven Architecture, Testing. A short description of the workshops, tutorials, and panels can be found in these proceedings and details at the conference web site: http://www.umlconference.org/. We would like to express our deepest appreciation to the authors of submitted papers, tutorials, workshops, and panels, and to the program committee members who did an outstanding job in selecting the very best papers for presentation. We would also like to thank Jon Whittle who chaired the workshop and tutorial submissions, as well as Michael Jackson, Bran Selic, and David Garlan for agreeing to present invited talks at the conference. Philippe Lecler and Marie-No¨elle Georgeault at INRIA are thanked for their contribution in organizing and handling the electronic submission process. The ConfMan program (http://confman.unik.no/~confman/ConfMan/) was used to gather and organize submitted papers and reviews. Damien Pollet at the University of Rennes organized the preparation of the final version of the conference proceedings. Birgit Demuth, R¨ udiger Liskowksy, Klaus Meißner, Ramona Behling, and Daniel Richter from the Technical University of Dresden did an excellent job of managing all local organization matters. We would also like to thank the ≪UML≫ steering committee for their advice, Jean-Michel Bruel and Robert France for their work as Publicity Chairs, and last year’s program chair, Martin Gogolla, for lots of helpful emails and hints.

July 2002

Jean-Marc J´ez´equel Heinrich Hussmann Stephen Cook

Organization

Executive Committee General Chair: Conference Chair: Program Chair: Tutorial/Workshop Chair:

Stephen Cook (IBM, UK) Heinrich Hussmann (Dresden University of Technology, Germany) Jean-Marc J´ez´equel (University of Rennes 1, France) Jon Whittle (QSS/Nasa Ames, USA)

Organizing Team Publicity Chairs: Program Organization:

Local Organization:

Jean-Michel Bruel (University of Pau, France), Robert France (Colorado State University, USA) Marie-No¨elle Georgeault, Philippe Lecler (INRIA, France) Damien Pollet (University of Rennes 1, France) Birgit Demuth, R¨ udiger Liskowsky, Klaus Meißner, Daniel Richter (Dresden University of Technology, Germany)

Program Committee C. Atkinson, Germany J. B´ezivin, France M. Boger, Germany D. Bustard, UK J. Castro, Brazil B. Cheng, USA S. Cranefield, New Zealand J. Daniels, UK G. Engels, Germany A. Evans, UK R. France, USA S. G´erard, France M. Gogolla, Germany B. Henderson-Sellers, Australia P. Hruby, Denmark S. Kent, UK

H. Kilov, USA C. Kobryn, USA H. Miyazaki, Japan R. Mitchell, USA A. Moreira, Portugal P.-A. Muller, France J. Mylopoulos, Canada G. Oevergaard, Sweden G. Reggio, Italy B. Rumpe, Germany A. Schuerr, Germany K. Siau, USA A. Strohmeier, Switzerland J. Warmer, The Netherlands J. Whittle, USA A. Wills, UK

VIII

Organization

Sponsors ACM Special Interest Group on Software Engineering http://www.acm.org/sigsoft

IEEE Computer Society http://www.computer.org

Corporate Donors ObjectFab GmbH http://www.objectfab.de

International Business Machines http://www.ibm.com

SQL GmbH Dresden http://www.sql-gmbh.de Sybase GmbH http://www.sybase.de

Academic Supporters Technische Universit¨ at Dresden http://www.tu-dresden.de Institut National de Recherche en Informatique et en Automatique http://www.inria.fr Universit´e de Rennes 1 http://www.univ-rennes1.fr

Table of Contents

Invited Talk 1 Descriptions in Software Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Michael Jackson

Metamodelling A Metamodel for the Unified Modeling Language . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Andrey Naumenko and Alain Wegmann Metamodeling Mathematics: A Precise and Visual Framework for Describing Semantics Domains of UML Models . . . . . . . . . . . . . . . . . . . . . . . . . 18 D´ aniel Varr´ o and Andr´ as Pataricza A Radical Reduction of UML’s Core Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Friedrich Steimann and Thomas K¨ uhne

Applying the UML Configuration Knowledge Representation Using UML/OCL . . . . . . . . . . . . . . . . 49 Alexander Felfernig, Gerhard Friedrich, Dietmar Jannach, and Markus Zanker Using UML for Information Modeling in Industrial Systems with Multiple Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Peter Fr¨ ohlich, Zaijun Hu, and Manfred Schoelzke Adapting the UML to Business Modelling’s Needs – Experiences in Situational Method Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Andreas Dietzsch

Digging into the Metamodel Analysis of UML Stereotypes within the UML Metamodel . . . . . . . . . . . . . . . . . 84 Martin Gogolla and Brian Henderson-Sellers Stereotypical Encounters of the Third Kind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Colin Atkinson, Thomas K¨ uhne, and Brian Henderson-Sellers Digging into Use Case Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Gonzalo G´enova, Juan Llorens, and V´ıctor Quintana

X

Table of Contents

Experience with MDA Practical Experiences in the Application of MDA . . . . . . . . . . . . . . . . . . . . . . . . . 128 Miguel de Miguel, Jean Jourdan, and Serge Salicki Executable Design Models for a Pervasive Healthcare Middleware System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Jens Bæk Jørgensen and Søren Christensen Generating Code from UML with Velocity Templates . . . . . . . . . . . . . . . . . . . . . 150 Thorsten Sturm, Jesco von Voss, and Marko Boger Invited Talk 2 Does Your Software Creak as It Runs? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Bran Selic Real-Time & Formal Semantics Integrating the Synchronous Paradigm into UML: Application to Control-Dominated Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Charles Andr´e, Marie-Agn`es Peraldi-Frati, and Jean-Paul Rigault A UML Profile for Real-Time Constraints with the OCL . . . . . . . . . . . . . . . . . . 179 Stephan Flake and Wolfgang Mueller HOL-OCL: Experiences, Consequences and Design Choices . . . . . . . . . . . . . . . . 196 Achim D. Brucker and Burkhart Wolff Model Engineering 1 Consistency-Preserving Model Evolution through Transformations . . . . . . . . 212 Gregor Engels, Reiko Heckel, Jochen M. K¨ uster, and Luuk Groenewegen Transformations and Software Modeling Languages: Automating Transformations in UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Jon Whittle A Relational Approach to Defining Transformations in a Metamodel . . . . . . 243 David Akehurst and Stuart Kent Profiles On Customizing the UML for Modeling Performance-Oriented Applications . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Sabri Pllana and Thomas Fahringer

Table of Contents

XI

Modelling QoS: Towards a UML Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Jan Øyvind Aagedal and Earl F. Ecklund, Jr. Extending the UML for Multidimensional Modeling . . . . . . . . . . . . . . . . . . . . . . . 290 Sergio Luj´ an-Mora, Juan Trujillo, and Il-Yeol Song

Model Engineering 2 A Metamodel for Package Extension with Renaming . . . . . . . . . . . . . . . . . . . . . . 305 Tony Clark, Andy Evans, and Stuart Kent Applying MDA Concepts to Develop a Domain CORBA Facility for E-learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 Luis Anido, Manuel Caeiro, Judith Rodr´ıguez, and Juan Santos Rapid Development of Modular Dynamic Web Sites Using UML . . . . . . . . . . 336 Tim Schattkowsky and Marc Lohmann

Invited Talk 3 Software, Heal Thyself! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 David Garlan

Methodology The Specification of UML Collaborations as Interaction Components . . . . . . 352 Eric Cariou and Antoine Beugnard Measuring OO Design Metrics from UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 Mei-Huei Tang and Mei-Hwa Chen The Cow Suite Approach to Planning and Deriving Test Suites in UML Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 Francesca Basanieri, Antonia Bertolino, and Eda Marchetti

Diagram Interchange & Security Diagram Interchange for UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 Marko Boger, Mario Jeckle, Stefan Mueller, and Jens Fransson UMLsec: Extending UML for Secure Systems Development . . . . . . . . . . . . . . . 412 Jan J¨ urjens SecureUML: A UML-Based Modeling Language for Model-Driven Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 Torsten Lodderstedt, David Basin, and J¨ urgen Doser

XII

Table of Contents

Workshops and Tutorials Workshops and Tutorials at the UML 2002 Conference . . . . . . . . . . . . . . . . . . . . 442 Jon Whittle Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .449

Descriptions in Software Development Michael Jackson

Abstract.
h  ntral activity in software development is the creation and use of descriptions. We make descriptions to capture our understanding of requirements, to describe the properties of the problem domain, to design the behaviour and structure of the software we are building, and for many other purposes too. To work effectively we must make our descriptions as exact as possible, and this is one goal of the designers of formal notations. But we must also be clear-headed about the purpose and subject matter of each description. As John von Neumann observed: “There is no point in using exact methods where there is no clarity in the concepts and issues to which they are to be applied”. Without a clear understanding of the purpose and subject matter of each description we can easily lose much of the benefit of effective notations. This talk presents a view of software development based on the notion of problem frames. Each problem frame is associated with a class of simple problems, and with a set of concerns that arise in the solution of problems of the class. Making and using descriptions are seen as activities aimed at addressing those concerns.

J.-M. J´ ez´ equel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, p. 1, 2002. c Springer-Verlag Berlin Heidelberg 2002


A Metamodel for the Unified Modeling Language Andrey Naumenko and Alain Wegmann Laboratory of Systemic Modeling Swiss Federal Institute of Technology – Lausanne EPFL-IC-LAMS, CH-1015 Lausanne, Switzerland {Andrey.Naumenko,Alain.Wegmann}@epfl.ch

Abstract. Nowadays models, rather than code, become the key artifacts of software development. Consequently, this raises the level of requirements for modeling languages on which modeling practitioners should rely in their work. A minor inconsistency of a modeling language metamodel may cause major problems in the language applications; thus with the model driven systems development the solidness of modeling languages metamodels becomes particularly important. In its current state the UML metamodel leaves a significant area for improvement. We present an alternative metamodel that was inspired by the RM-ODP standard and that solves the problems of UML. RM-ODP was mentioned in UML specifications as a framework that has already influenced UML. Our metamodel was formalized, thus its resulting models can be simulated and checked for consistency. So, our proposed solution with constructive potential towards improvement of the UML metamodel, may have a significant practical impact on the UML specifications.

1

Introduction

Modern practices of software development should successfully manage the progressing complexity of modeling problems. Consequently, this raises the level of requirements for modeling languages on which practitioners, such as software designers and IT system architects, should rely in their everyday modeling work. A minor imperfection of a modeling language metamodel may cause major problems in the language applications. Thus with the model-driven systems development, the solidity of foundations of modeling languages becomes particularly important. These foundations include, for example: -

the overall internal consistency of semantics of a modeling language, the coherency and unambiguity in semantics definitions presenting relations between a model constructed using the modeling language from one side and the subject of modeling that is represented by the model from the other side,

J.-M. Jézéquel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 2-17, 2002.  Springer-Verlag Berlin Heidelberg 2002

A Metamodel for the Unified Modeling Language -

3

the theoretical justifications of the semantics relevance (e.g. the necessity and sufficiency of the semantic constructs for a representation of the modeling scope targeted by the language).

In its current state, the UML metamodel leaves a significant area for improvement with regard to the aforementioned criteria. In addition, the UML metamodel is considered to be quite sophisticated by the modelling community. Thus, in order to allow for more successful practical UML applications, as well as for their facilitation, the current state of the UML metamodel should be improved. In this work, while analyzing the problems of the existing UML metamodel, we present an alternative metamodel that was inspired by the RM-ODP (Reference Model of Open Distributed Processing [1]) ISO/ITU standard. We show how our proposed metamodel successfully resolves some of the existing problems of UML and present literature references supporting our solution. The example of our metamodel that we present in this paper, implements a formalization of RM-ODP conceptual framework. UML specifications mention RM-ODP as a framework that has already influenced UML metamodel architectures ([7] in Preface: Relationships to Other Models). This increases the probability for the constructive potential of our metamodel to influence future evolution of UML specifications. This paper is organized as following. Section 2 will present an analysis of the UML metamodel identifying three of its existing problems. Section 3 will introduce a detailed analysis for each of the three problems. Then Section 4 will define three respective solutions for the identified problems. These solutions will frame the definition of our alternative metamodel. Section 5 will conclude the paper making reference to a concrete example of our metamodel realization and highlighting the most important results of this paper.

2

Problems Identification

When developing any modeling language, the language designer needs to define a scope of the language applications and then to define a set of modeling concepts that would be necessary to represent the defined scope. For the language to be useful in modelers’ community practices, the modeling concepts need to have clear, logically structured and consistent semantics. In other words, the better structured the semantics are, and the less internal inconsistencies they have – the more useful the language for the modelers that are interested in representing the identified modeling scope. Unified Modeling Language (UML) was designed by the Object Management Group (OMG) as “a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems” ([7] section 1.1). This identifies the scope of UML applications. The experience of modeling practices in modern industries shows that UML is found useful by modelers. The amount of modeling projects that use UML, the amount of books written about UML and the number of software tools that support UML are large in relation with the analogous practical achievements of other model-

4

Andrey Naumenko and Alain Wegmann

ing languages. This proves that UML in its current state is more practical then other modeling solutions, although it doesn’t mean that there are no problems with the current state of UML. Consistently with the scenario explained in the first paragraph of this section, the UML specification [7] introduces a set of modeling concepts to represent the identified modeling scope. Section 2 of the specification defines UML semantics for these concepts. The first problem we can identify is that these UML semantics are considered to be complex and difficult to understand by many modelers. OMG itself in its article “Introduction to OMG's Unified Modeling Language (UML™)” [8] confirms this, saying that the UML specification [7] is “highly technical, terse, and very difficult for beginners to understand”. This situation can be improved by analyzing the current state of UML semantics, understanding the reasons that cause its complexity and by proposing a better organization of semantics for modeling concepts. In particular, we will show that our solution, by introducing a logically precise and internally consistent semantics structure that is based on Russell’s theory of types [9], makes a positive difference in relation with the absence of such a structure in the current UML semantics. The explicit presence of such a structure helps to understand how the modeling concepts should be used in practice, whereas its absence creates numerous possibilities for confusions in practical applications of modeling concepts. While performing the analysis of the current UML semantics we can localize the second problem. Specifically that current UML semantics are very ambiguous in presenting relations between models constructed using the language on one side and the subject that is being modeled on the other side. This is an important problem, because even an internally consistent model will not have much of practical sense when its relations with the subject that it is supposed to represent are undefined. This situation with UML is improved in our solution by the introduction of a coherent and unambiguous set of modeling concepts definitions expressing a kind of Tarski’s declarative semantics [10] for the mentioned relations between the model and the subject of modeling. The third problem of the UML semantics, which we will consider in this paper, is the absence of any justifications in the UML specification that would explain why the presented set of UML modeling concepts is necessary and sufficient to represent the UML modeling scope. Without these justifications, the UML theoretical value is significantly diminished, since in this situation the language cannot prove the reasonableness of its ambitions to represent its modeling scope. In our solution, the introduction of the set of modeling concepts is supported by the solid philosophical and natural science foundations providing such kind of justifications.

3

Problems Analysis Based on the Foundations of UML Semantics

As we can see from the previous section, all three identified problems are related to the non-optimal semantics definition. Let us look at foundations of the UML seman-

A Metamodel for the Unified Modeling Language

5

tics in order to localize the chapters in specifications from where the mentioned problems originate. The UML specification [7] in section 2.4 introduces the semantics Foundation package: “The Foundation package is the language infrastructure that specifies the static structure of models. The Foundation package is decomposed into the following subpackages: Core, Extension Mechanisms, and Data Types.” Analyzing the specification further we see for these three packages: -

-

-

Core: “The Core package is the most fundamental of the subpackages that compose the UML Foundation package. It defines the basic abstract and concrete metamodel constructs needed for the development of object models.” [7], section 2.5.1. Extension Mechanisms: “The Extension Mechanisms package is the subpackage that specifies how specific UML model elements are customized and extended with new semantics by using stereotypes, constraints, tag definitions, and tagged values. A coherent set of such extensions, defined for specific purposes, constitutes a UML profile.” [7], section 2.6.1. Data Types: “The Data Types package is the subpackage that specifies the different data types that are used to define UML. This section has a simpler structure than the other packages, since it is assumed that the semantics of these basic concepts are well known.” [7], section 2.7.1.

Thus we can conclude that the three identified problems originate from the Core package of the UML. Consequently it is on this package that we will focus our further consideration. 3.1

Problem 1: Structural Chaos of UML Semantics

Let us now concentrate on the first of the identified problems: the absence of a consistent structural organization of UML metamodel that leads to practical difficulties in understanding semantics for particular modeling concepts, as well as to the difficulties in understanding semantically allowed application contexts for a particular modeling concept. As it is presented in Figure 2-5 from the Core package specification [7], the most general concept in the UML metamodel is called “Element”. It is defined ([7], section 2.5.2.16) as following: “An element is an atomic constituent of a model. In the metamodel, an Element is the top metaclass in the metaclass hierarchy. It has two subclasses: ModelElement and PresentationElement. Element is an abstract metaclass.” Thus any atomic constituent of a UML model can be called as UML element. As it is presented in the diagrams 2-5,6,7,8,9 of the UML specifications [7], all the other modeling concepts are specializations of “Element”. This defines a flat structure for the UML metamodel, where any of the concepts can be used as UML elements. And even if the elements obviously belong to different semantic categories (for example, “Operation” and “Class”), there is no explicit categorization defined to help a modeler to understand which concepts should be used in which context. We may notice an introduction of “abstract” and “concrete” constructs categories in section 2.5.1 of the UML specification: “Abstract constructs are not instantiable and are commonly used to reify key constructs, share structure, and organize the UML

6

Andrey Naumenko and Alain Wegmann

metamodel. Concrete metamodel constructs are instantiable and reflect the modeling constructs used by object modelers (cf. metamodelers). Abstract constructs defined in the Core include ModelElement, GeneralizableElement, and Classifier. Concrete constructs specified in the Core include Class, Attribute, Operation, and Association.” However, this categorization becomes quite confusing if it is compared with the actual terms’ definitions presented in the UML specifications. For example, “Association” is defined ([7], section 2.5.2.3) relative to “Classifier”, which means that “Association” can be considered as both the abstract and the concrete construct. To summarize, the categorization of concepts into the abstract and the concrete constructs does not have a consistent implementation in the current UML specifications and cannot help modelers who would like to understand the possible application context for a particular modeling concept. An approximate sketch of another possible categorization can be found in section 2.5.2 of UML specifications. The section introduces the figures 2-5,6,7,8,9 as following: “Figure 2-5 on page 2-13 shows the model elements that form the structural backbone of the metamodel. Figure 2-6 on page 2-14 shows the model elements that define relationships. Figure 2-7 on page 2-15 shows the model elements that define dependencies. Figure 2-8 on page 2-16 shows the various kinds of classifiers. Figure 2-9 on page 2-17 shows auxiliary elements for template parameters, presentation elements, and comments.” So a reader could guess that “Backbone”, “Relationships”, “Dependencies”, “Classifiers” and “Auxiliary Elements” are probably different categories of the modeling concepts. Unfortunately these pseudo-categories are neither defined in the relations between each other, nor in some other theoretical or practical application context. In addition, if we check the described figures, we see that the same modeling concepts (e.g. “Classifier” or “Relationship”) are present at the same time in several of the diagrams. Thus a potential differentiation between the pseudo-categories is particularly difficult to understand. We can conclude that the current UML specification of the Core fails to introduce a practically useful categorization of concepts that would define different application contexts for different conceptual categories. Unfortunately this problem cannot be solved by a simple adoption of some categorization for the currently existing UML concepts. This is due to the absence of any explicitly mentioned consistent strategy of concepts introduction by UML. In fact, judging from the specification, for us the strategy for the introduction of particular concepts remains obscure even on an implicit level. Surprisingly some concepts seem to appear without a significant justification whereas other conventional object-oriented terms are omitted. For example, let us look at definitions of “ModelElement” and “PresentationElement”, which are the two subclasses of UML element. We see that “PresentationElement” is defined ([7], section 2.5.2.33) as “a textual or graphical presentation of one or more model elements.” Thus essentially a “PresentationElement” is a “ModelElement” presented in a textual or a graphical form. Here we may mention that, in general, a “ModelElement” from inside a model doesn’t make sense to anybody or to anything if it is not presented in some form to somebody or to something who perceives the model in this form of presentation. Thus we may affirm that, in general, a “ModelElement”, as soon as it is of interest to somebody or to something, is necessar-

A Metamodel for the Unified Modeling Language

7

ily a “ModelElement” presented in some form. Thus, in fact, “PresentationElement” is a specialization of “ModelElement” where the forms of a possible presentation are known concretely (namely a textual and a graphical form). This specialization is the only value that is added to the semantics of “ModelElement” to obtain the semantics of “PresentationElement”. Because of this minor significance of the added value, we may consider “PresentationElement” as not important enough (not essential) to be a separate concept inside the UML metamodel. The elimination of “PresentationElement” accompanied by the addition of the descriptions of possible ways of presentation inside the definition of “ModelElement” would simplify the metamodel without diminishing its value. 3.2

Problem 2: Absence of Declarative Semantics in UML

After having studied the complete UML metamodel, we can note that the UML specifications define explicitly only two concepts whose definitions are made by referring (relating) to the subject (system) that is being modeled. The first concept is “ModelElement”, it is defined ([7], section 2.5.2.27) as “an element that is an abstraction drawn from the system being modeled.” The second of the two concepts is “Component”, it is defined ([7], section 2.5.2.12) as following: “A component represents a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces”. All the other concepts that constitute the metamodel are defined as parts of a UML model, only in the relations with each other and with the two mentioned concepts. That is, the definitions of all the UML metamodel concepts, with exception of the two mentioned, do not make reference to the subject that is being modeled. This semantics definition is not optimal. Indeed as we said, only two concepts used in UML models are defined by a reference to the subject being modeled. More than that, the UML metamodel doesn’t define why these two concepts and why only these two (and not some other) were designated for this purpose. This means: a. b.

that this choice of these two concepts does not have a tenable reason defined in the UML specification; that UML specification does not define a tenable relation between a subject that needs to be modeled and its model.

The conclusion ‘b.’ is particularly important, because it means that for the UML concepts the specification does not define any kind of formal declarative semantics that were introduced by Alfred Tarski [10]. Indeed, Tarski’s declarative semantics for concepts used inside models are supposed to introduce mappings between the agreed conceptualizations of a subject that is being modeled and the concepts inside its model. The UML metamodel never presents an agreed conceptualization of the subject of modeling. Thus the specification has no choice but to define modeling concepts exclusively in their interrelations inside the model. In the general case, this approach is not an optimal one for the following two main reasons: 1.

The overall complexity of the relations between concepts in the UML metamodel is greater than it would have been if part of the concepts were defined in the rela-

8

Andrey Naumenko and Alain Wegmann

2.

tions with the subject of modeling. Indeed, the quantity of concepts is the same in both cases, but in the latter case some concepts would be defined in a selfsufficient way, whereas in the former, the corresponding concepts for their definitions will need relations to other concepts from the metamodel. Since there is no tenable relation defined between a subject that needs to be modeled and its model and since there is not any agreed conceptualization of the subject, there cannot be a formal proof (such as in the case of Tarski’s declarative semantics) that a given modeler’s interpretation (that is a model) represents the subject of modeling in a logically consistent way1. In other words, in this case several mutually contradicting models can represent the same subject of modeling and all of them may be confirmed as adequate; or, from the other side, one single model may be related with the same degree of adequateness to different mutually incompatible subjects of modeling.

To illustrate the second point let us take Tarski’s original example [10] for declarative semantics definition: ‘It snows’ is true (in the model) if and only if it snows (in the subject of modeling). So if we decide to take the subject of modeling where it snows, without the declarative semantics, then both ‘It snows’ and ‘It does not snow’ can be considered true in the model if it snows in the subject of modeling. From the other side, without the declarative semantics the model where “‘It snows’ is true” may represent equally well both the subject of modeling where it snows and the subject of modeling where it does not snow. In the case of UML specification, as we said, there are only two concepts that make the direct relation to a subject of modeling: “ModelElement” and “Component”. Parts of their definitions can be considered as introducing the declarative semantics. For example, according with [7], sections 2.5.2.27 and 2.5.2.1 we can write for “ModelElement”: ‘A ModelElement exists’ is true in the model if and only if a subject of modeling (“system being modeled”) is. And for “Component” according with [7], section 2.5.2.12 we can write: ‘A Component exists’ is true in the model if and only if there is a modular, deployable, and replaceable part of the subject of modeling (“of system”). But as we see, these definitions are too abstract: they do not give a possibility for a differentiation of modeling concepts, thus the choice of only these two concepts to be defined using the declarative semantics is not practical. 3.3

Problem 3: Absence of Theoretical Justifications for UML Metamodel to Represent the Targeted Modeling Scope

As we said, the third problem of UML semantics is the absence of any justifications in the UML specification that would explain why the presented set of UML modeling concepts is necessary and sufficient to represent the UML modeling scope. This problem can be considered as natural for the current state of UML because, from its 1

Here we mean the logical consistency in an interpretation of subject of modeling. The internal consistency of a model (the model being a result of the interpretation) is a different subject. The internal consistency of a model can be ensured by the consistency of the UML metamodel, and to ensure the logical consistency of the interpretation, a kind of consistent Tarski’s declarative semantics is necessary.

A Metamodel for the Unified Modeling Language

9

outset, the language was constructed by OMG as a result of the integration of the best existing industrial modeling practices, but these practices were never really linked with the existing scientific theories. Although the “best practices” strategy can be considered as an attempt at practical justification of UML, the theoretical justification was never defined in the language specifications and still needs to be provided. Thus as we can see, this third problem of the UML metamodel is a theoretical problem, compared to the first two identified problems that are practical. So the third problem is important as soon as UML would pretend to be standardized as a modeling technique by some international standardization committee (such as ISO), which would normally assume solid scientific foundations rather then just results of practical experience to support the language.

4

Solutions for the Identified Problems of the UML Metamodel

4.1

Solution to Problem 1: Categorization of Concepts Based on Russell’s Theory of Types

As we explained in Section 3.1, UML doesn’t define any explicit logically consistent strategy for the introduction of modeling concepts. To solve the problem of the structural chaos of UML semantics we needed to define such kind of strategy ourselves. To define the structure of our metamodel, we took the basic conceptual structure of the RM-ODP [1] standard (part 2: Foundations) and reinforced it by means of the strong theoretical foundations of Russell’s theory of types [9], as well as by means of the structural principles of Tarski’s declarative semantics [10]. As it was proposed in RM-ODP part 2 clause 6 that defines “Basic Interpretation Concepts” conceptual category, we call the subject of modeling (which is the subject that has some modeling interest to a modeler) as “Universe of Discourse”. In RMODP, “Universe of Discourse” was constituted by entities (defined in [1] 2-6.1 as “any concrete or abstract thing of interest”) and propositions that can be asserted or denied as being held for entities (defined [1] 2-6.2). This notion of the “Universe of Discourse” organization is compatible with Russell’s theory of types [9] defined by Bertrand Russell in 1908, that introduces individuals and propositions over individuals. Particularly, [9] explains: “We may define an individual as something destitute of complexity; it is then obviously not a proposition, since propositions are essentially complex. Hence in applying the process of generalization to individuals we run no risk of incurring reflexive fallacies. Elementary propositions together with such as contain only individuals as apparent variables we will call first-order propositions. We can thus form new propositions in which first-order propositions occur as apparent variables. These we will call second-order propositions; these form the third logical type. Thus, for example, if Epimenides asserts "all first-order propositions affirmed by me are false," he asserts a second-order proposition; he may assert this truly, without asserting truly any firstorder proposition, and thus no contradiction arises.

10

Andrey Naumenko and Alain Wegmann

The above process can be continued indefinitely. The (n + 1)th logical type will consist of propositions of order n, which will be such as contain propositions of order n - 1, but of no higher order, as apparent variables. ” Analogously, in our case we have “entity” corresponding to Russell’s “something destitute of complexity”. Indeed, the only intrinsic meaning of an entity in the RMODP definition is to be “something” that can be qualified by means of propositions; an entity has no other meaning without the propositions associated with it. Thus, by mapping Russell’s “individual” and “proposition” to our “entity” and “proposition”, respectively, we can use Russell’s suggestion in the context of our universe of discourse. This allows us to differentiate the propositions based on their subject of application: -

if a proposition is applied to an entity it is considered as the first-order proposition; if a proposition is applied to a proposition it is considered as the higher-order proposition.

Of course, in an application of these propositions there may be a situation when a higher-order proposition is applied on another higher-order proposition, which in its turn is applied on yet another higher-order proposition and so on, until the overall structure of the higher-order propositions is finally applied on the first-order proposition. Hence for simplification, we will refer to the combination of several higher-order propositions, which is applied on a first-order proposition, as a single higher-order proposition. So we ordered the entities and propositions that constitute a universe of discourse in agreement with the Russell’s theory of types. Now we can look at models that should represent an arbitrary universe of discourse. A model is the place where modeling language constructs should be applied. Thus it is for the model part of our metamodel that we should provide a useful structure of the categorization of concepts, which would explain the different contexts of practical applications for the concepts from different categories. We suggest organizing the modeling concepts structure in such a way that there would be a straightforward correspondence between the model and the corresponding represented universe of discourse. That is, we suggest constructing a structure of concepts in the model in agreement with Russell’s theory of types, which would correspond directly to the universe of discourse organization we presented earlier. According to our suggestion, within the model we will be able to identify “Model Elements” that will be analogous to the Russell’s “individuals” defined “as something destitute of complexity”. Also, under this assumption, in the model we will have some concepts that are analogous to the Russell’s “first-order propositions” (we will call them “Basic Modeling Concepts”), and some concepts – analogs of the “higher-order propositions” (we will call them “Specification Concepts”). With this approach to the construction of a model it would be necessary to qualify “Model Elements” with the aid of “Basic Modeling Concepts”, which in their turn could be qualified by means of “Specification Concepts”.

A Metamodel for the Unified Modeling Language

11

Thus we are able to define the correspondence between the conceptual categories from within the model and the entities and propositions that form the universe of discourse that should be modeled. The correspondence was defined as follows: -

Entities of the Universe of Discourse are modeled by Model Elements in the Model. First-order Propositions from the Universe of Discourse are modeled by Basic Modeling Concepts in the Model. Higher-order Propositions from the Universe of Discourse are modeled by Specification Concepts in the Model.

So, model elements are defined in the model as one to one counterparts to entities from the universe of discourse. Let us consider more closely the two other conceptual categories from within the model. As we showed, in correspondence with Russell’s definitions, basic modeling concepts (essentially the first-order propositions) contain model elements as “apparent variables”; and specification concepts (the higher-order propositions) contain the basic modeling concepts as “apparent variables”. In fact, these two conceptual categories were introduced by RM-ODP specifications ([1] part 2, clauses 8 and 9); up to this point in our presentation we only reinforced logical justifications for this categorization with the support of Russell’s theory of types and with explicit definitions of the application contexts for concepts from the two categories. For further explanation of the difference between concepts from the two conceptual categories we will use the principal structure of relations between a universe of discourse from one side and its model from the other side; this structure was defined by Alfred Tarski in 1935 for the introduction of his formal declarative semantics [10]. The basic modeling concepts set, as it aims to model the first-order propositions from the universe of discourse, should contain the concepts expressing the qualities that are considered as primary and intrinsic for the universe of discourse entities. This fundamental nature of the primary qualities belonging to the universe of discourse doesn’t allow their modeling representations to be defined exclusively within the model. Hence the only possibility for a definition of the basic modeling concepts is to define them using Tarski’s declarative semantics [10]: the semantics that define equivalence of an agreed conceptualization of the universe of discourse to a concrete concept in the model. The set of basic modeling concepts constructed in this way is the necessary, sufficient and limited set representing a limited amount of intrinsic qualities from the universe of discourse. The set of specification concepts contains all the other concepts that can be found in models. These concepts aim to model the higher-order propositions from the universe of discourse; thus they do not represent the primary qualities of the universe of discourse entities and hence they do not need to have Tarski’s declarative semantics for their definitions. So these concepts will be defined only in the relations between themselves and in the relations with the basic modeling concepts, but not in the relations with the universe of discourse. In a general case, the set of specification concepts is not limited because of the same quality of the higher-order propositions set. As new higher-order propositions can be constructed by applying one higher-order proposition

12

Andrey Naumenko and Alain Wegmann

on another, new specification concepts can similarly be constructed by applying one specification concept on another. So, it becomes clear that there is a significant semantic difference between the two conceptual categories. Basic modeling concepts are defined using Tarski’s declarative semantics, but specification concepts are not. This is the consequence of the differences in their design purposes, which explains the clear difference in their corresponding applications within a model. Additional details on this categorization can be found in [4]. Here let us present a UML diagram explaining the structure of the introduced categorization (see Figure 1). *

*

Higher Order Proposition 1..*

*

First Order Proposition

assocProposition

corresponds

Entity assocProposition

1..* models

1

models Universe of Discourse 1

modeledBy Formal Tarski's declarative semantics modeledBy 0..1

modeledBy 0..1

*

Model

1

higherOrderProposition specifies * specifiedBy

*

modeledBy 0..1

0..1 Specification Concept

models

Basic Modeling Concept

*

firstOrderProposition represents * representedBy

Model Element *

*

*

Fig. 1. Categorization of concepts for the proposed metamodel (UML diagram)2

4.2

Solution to Problem 2: Tarski’s Declarative Semantics Definitions for Basic Modeling Concepts

The complete analysis of definitions for concepts from the basic modeling concepts category that was introduced in the previous section can be found in [3]. Here we will just briefly explain the overall structure of basic modeling concepts, and present this structure in the form of UML diagram. Figure 2 presents the idea of general organization for the basic modeling concepts category. Essentially the set of concepts is determined by the consideration of the spatiotemporal conceptual continuum and the non-spatiotemporal conceptual continuum. The former represents in the model a space-time from the universe of discourse, and the latter represents in the model the non-spatiotemporal conceptual entities that 2

In the diagram in Figure 1, in addition to all the explained particularities of the categorization structure, we also showed that a specification concept can specify any of the basic modeling concepts, and a basic modeling concept can be specified by any of the specification concepts. In fact this is true only for the generic specification concepts – the subcategory of specification concepts whose definition is beyond the scope of this paper and can be found in [3,4].

A Metamodel for the Unified Modeling Language

13

constitute the universe of discourse. In correspondence with their ancestors from the universe of discourse, the former is presented by the Space and the Time dimensions on Figure 2, while the latter by the Model Constitution dimension. Being considered in the same context of a model, the two introduced conceptual continuums necessarily give birth to the third one that is essentially the Information about the Model Constitution within Space-Time. Detailed analysis of this approach can be found in [3].

Time

Time Interval

Time Information Element

Dynamic Information Element (Action)

Static Information Element (State)

Model Constitution

Object Environment Space Interval

Space

Spatial State

Environment Spatial Trace

Space Information Element

Fig. 2. Three-dimensional framework with the dimensions of “Space Continuum”, “Time Continuum” and “Model Constitution Continuum”, which allows for the emergent “Information” continuum

By defining limiting points within Space-Time and Model Constitution dimensions we obtain concepts of Space Interval, Time Interval for the Space and the Time and concept of Object with the concept of its Environment for the Model Constitution. Also, with the definition of these limiting points we are able to consider Object and its Environment: -

at a single moment in Time, and thus to define the concept of Static Information Element (State) within the Information continuum; at an interval between two moments in Time, and thus to define the concept of Dynamic Information Element (Action) within the Information continuum.

Thus we obtain the structure of basic modeling concepts presented in the UML diagram from Figure 3. In correspondence with the explanations from the previous section all the basic modeling concepts have formal definitions in the form of Tarski’s declarative semantics. We recommend to check [3] for all these concrete definitions. The definitions of basic modeling concepts, as well as the definitions for all the other concepts proposed in our metamodel, have much in common (and are even

14

Andrey Naumenko and Alain Wegmann

identical in many cases) with the definitions of corresponding concepts given by RMODP. We formalized the overall RM-ODP foundations framework ([4], [5], [6]), including the basic modeling concepts part, using Alloy [2] formal description technique. Thus the basic modeling concepts semantics introducing a coherent set of Tarski’s declarative semantics for relations between the concepts and the subject that is being modeled (universe of discourse) present a formally justified logical structure. Specification Concept

0..1

1 Model Element firstOrderProposition

Model Constitution Concept

Discontinuity Concept

timeLimit

Basic Modeling Concept

higherOrderProposition

SpaceTime Concept

Information Concept

spaceLimit

Point in Time

Point in Space

Time Interval

Space Interval





associatedPointInTime

associatedPointInSpace

associatedTimeInterval

associatedSpaceInterval

Object

Environment

Action

State





objectAction

objectState

Fig. 3. Basic Modeling Concepts: Conceptual Specialization (UML diagram)

4.3

Solution to Problem 3: Philosophical and Natural Science Foundations of our Proposed Metamodel

As we explained in the analysis of Problem 2, even for the choice of two modeling concepts that were linked in their definitions with the subject of modeling, UML specification does not define any tenable reason. And the set of modeling concepts that are defined using declarative semantics could be the very source of justifications for the ambitions to represent a given modeling scope with the modeling concepts of the language. Indeed, if the declarative semantics concepts cover all the possibilities of the agreed conceptualizations of the modeling scope then, the set of concepts can be considered as sufficient for the modeling purposes. And from the other side, the very set of declarative semantics concepts that would cover all the agreed conceptualizations of the modeling scope can be considered as necessary due to the necessity of the scope representation. As the previous paragraph shows, the approach to the solution of the third indicated problem of UML metamodel is in the scientific justification of an agreed conceptualization of the modeling scope and in a formally defined unambiguous and logically consistent correspondence of the conceptualization to the modeling concepts that are designated to represent the conceptualization in the model.

A Metamodel for the Unified Modeling Language

15

The complete theoretical justifications of the universe of discourse conceptualization (that was introduced in the previous section to support the introduction of basic modeling concepts) can be found in [3]. Here we will just mention that: -

-

-

the possibility to define limiting points and thus discrete concepts within a conceptual continuum is justified by mereology that is a branch of philosophy studying whole-part relationships; the possibility to consider the constitution of models as a conceptual continuum that is independent with regard to the spatiotemporal continuum is an original idea. This idea generalizes fundamental foundations of both classical and relativistic mechanics that study spatiotemporal characteristics of material objects. In our case the scope is generalized to include imaginary conceptual entities. The resulting space-time-constitution framework can be considered as an extension of the traditional Minkowski’s space-time framework; the vision of defining information as a continuum emerging out from the spacetime and the model constitution continuums being considered in the same context is an original idea that however has an analogy found in Taoist philosophy.

The important result was to demonstrate that our conceptualization of the universe of discourse is in agreement with fundamental philosophical and natural science foundations. This demonstration (presented in [3]) allows us to rely on the introduced conceptualization and thus to define the set of Tarski’s declarative semantics for the basic modeling concepts of our metamodel as not only having the logical consistency in the interpretation, but also being justified as a generalization of scientific experience. And as we explained in the beginning of this section, the definition of this Tarski’s declarative semantics set for the limited modeling scope introduced by the conceptualization provided a straightforward logical proof that the resulting limited set of basic modeling concepts is necessary and sufficient for the modeling scope representation.

5

Conclusions

Our metamodeling solution, described in this paper, is an original proposition that doesn’t have direct analogs in any of the modeling frameworks known to us. However, different modeling frameworks can benefit from the presented advantages of our metamodel. This is possible because our metamodel reserves only two things: the structure of its organization and the basic modeling concepts set that consists of six concepts (the concepts presented as gray rectangles in the diagram from Figure 3: Point in Time, Point in Space, Time Interval, Space Interval, Object, Environment, Action and State). At the same time the metamodel allows for an arbitrary construction of the specification concepts set. So, different object-oriented frameworks, as soon as they are destitute of self-contradictions, could fit their terminology in our defined metamodel structure making use of its internal consistency, logical coherency of interpretation, formalized semantics and theoretically justified foundations.

16

Andrey Naumenko and Alain Wegmann

For example, in [3] we show how the RM-ODP conceptual framework (defined in [1]) fits successfully our presented metamodeling structure. In [3] we demonstrate that realizing the appropriate categorization that is implied by the RM-ODP definitions, we can construct the specification concepts structure for our metamodel containing all the defined RM-ODP concepts. This example allowed us to formalize the RM-ODP conceptual structure ([4], [5], [6]), thus now it is possible to verify the RM-ODP models with the aid of computer tools. Let us summarize the most important results of this paper. In the paper we identified and analyzed three important problems of UML metamodel: -

Absence of an explicit structural organization defined for UML metamodel; Absence of a formal declarative semantics in UML metamodel; Absence of theoretical justifications for UML metamodel to represent the modeling scope that is targeted by UML. We solved these problems by defining an alternative metamodel that:

-

-

has an internally consistent structure supported by Russell’s theory of types [9]; defines a kind of Tarski’s declarative semantics [15] for the basic modeling concepts, thus it is coherent and unambiguous in the interpretations of subjects of modeling; is applied on a concrete example of the RM-ODP conceptual framework that is formalized in a computer-interpretable form [5]; provides philosophical and natural science foundations to justify that its proposed modeling concepts set is necessary and sufficient to represent its identified modeling scope.

Our metamodel defines concrete improvements for the current state of UML, and it can have a constructive influence on the evolution of UML specifications by providing the language designers with its logical rigor, its formal presentation and its solid theoretical foundations. The concreteness of our solutions and the fact that we implemented them formally on the example of RM-ODP (the framework that was mentioned by UML specifications as influential for UML metamodel architectures) are two strong points that may attract OMG attention to the results of our research.

References 1. 2.

3.

ISO, ITU.: ISO/IEC 10746-1, 2, 3, 4 | ITU-T Recommendation X.901, X.902, X.903, X.904. “Open Distributed Processing - Reference Model”. 1995-98. Jackson D.: “Alloy: A Lightweight Object Modelling Notation”. Technical Report 797, MIT Laboratory for Computer Science, Cambridge, MA, February 2000. Naumenko, A.: “Triune Continuum Paradigm: a paradigm for General System Modeling and its applications for UML and RM-ODP”. Ph.D thesis 2581, Swiss Federal Institute of Technology - Lausanne, June 2002. http://stella.epfl.ch/tcp/Naumenko-PhD-Thesis.pdf .

A Metamodel for the Unified Modeling Language

4.

17

Naumenko, A., Wegmann, A.: "A Formal Foundation of the RM-ODP Conceptual Framework" EPFL-DSC technical report No. DSC/2001/040, EPFL, Switzerland, July 2001. 5. Naumenko, A., Wegmann, A.: “RM-ODP part 2: Foundations in Alloy”. EPFLDSC Technical report No. DSC/2001/041, EPFL, Switzerland, August 2001. 6. Naumenko, A., Wegmann, A., Genilloud, G., Frank, W. F.: "Proposal for a formal foundation of RM-ODP concepts". Proceedings of ICEIS 2001, WOODPECKER`2001, J. Cordeiro, H. Kilov (Eds.), Setúbal, Portugal, July 2001. 7. OMG: Unified Modeling Language Specification. Version 1.4, September 2001. 1. OMG: Introduction to OMG's Unified Modeling Language (UML™). January 2002, http://www.omg.org/gettingstarted/what_is_uml.htm . 9. Russell, B.: “Mathematical logic as based on the theory of types”. American Journal of Mathematics, 30, 1908, pp. 222-262. 10. Tarski, A.: “Logic, Semantics, Meta-mathematics.” Oxford University Press 1956.

M etamodeling Mathematics: A Precise and Visual Framework for Describing Semantics Domains of UML Models⋆ D´il V   ´ P    B udapest University of Technology and Economics Department of Measurement and Information Systems H-1521 Budapest Magyar tud´ osok k¨ or´ utja 2 {varro,pataric}@mit.bme.hu

Abstract. As UML 2.0 is evolving into a family of languages with individually specified semantics, there is an increasing need for automated and provenly correct model transformations that (i) assure the integration of local views (different diagrams) of the system into a consistent global view, and, (ii) provide a well–founded mapping from UML models to different semantic domains (Petri nets, Kripke automaton, process algebras, etc.) for formal analysis purposes as foreseen, for instance, in submissions for the OMG RFP for Schedulability, Performance and Time. However, such transformations into different semantic domains typically require the deep understanding of the underlying mathematics, which hinders the use of formal specification techniques in industrial applications. In the paper, we propose a UML-based metamodeling technique with precise static and dynamic semantics (based on a refinement calculus and graph transformation) where the structure and operational semantics of mathematical models can be defined in a UML notation without cumbersome mathematical formulae. Keywords: metamodeling, formal semantics, refinement, model transformation, graph transformation

1

Introduction

1.1

Evolution of UML

F r t  t y   1.x  b   d f      j        w "   f ##    I  j r 

 i rigi    f t t t U (i) i standard % rmly  

d by t ⋆

This work was partially carried out during the visit of the first author to Computer Science Laboratory at SRI International (333 Ravenswood Ave., Menlo Park, CA, U.S.A.) and supported by the National Science Foundation Grant (CCR-0086096), the Hungarian Information and Communication Technologies and Applications Grant (IKTA 00065/2000) and the Hungarian National Scientific Foundation Grant (OTKA 038027).

J.-M. J´ ez´ equel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 18–33, 2002. c Springer-Verlag Berlin Heidelberg 2002


Metamodeling Mathematics: A Precise and Visual Framework

19

teams of developers) and visual language (also meaningful not only for system engineers and programmers but even for customers). However, based upon academic and industrial experiences, recent surveys (such as [13]) have pinpointed several shortcomings of the language concerning, especially, its imprecise semantics, and the lack of flexibility in domain specific applications. In principle, due to its in-width nature, UML would supply the user with every construct he needs for modeling software applications. However, this leads to a complex and hard-to-implement UML language, and since everything cannot be included in UML in practice, it also leads to local standards (profiles) for certain domains. Recent initiatives for the UML 2.0 RFP (e.g. MML [7]) aim at an in-depth evolution of UML into a core kernel language, and an extensible family of distinct languages (called profiles). Each profile (UML diagram) has its own semantics, which architecture fundamentally requires an appropriate and precise metamodeling technique. 1.2

Transformations of UML Models

Such a metamodeling-based architecture of UML highly relies on transformations within and between different models and languages. The immense relevance of UML transformations is emphasized, for instance, in submissions to the OMG RFP for a UML sublanguage for Schedulability, Performance and Time [16]. In practice, transformations are necessitated for at least the following purposes: – model transformations within a language should control the correctness of consecutive refinement steps during the evolution of the static structure of a model, or define an operational (rule-based) semantics directly on models; – model transformations between different languages should provide precise means to project the semantic content of a diagram into another one, which is indispensable for a consistent global view of the system under design; – a visual UML diagram (i.e., a sentence of a language in the UML family) should be transformed into its (individually defined) semantic domain, which process is called model interpretation. Concerning model transformation in a UML environment, the main course of research is dominated by two basic approaches: (i) transformations specified in (extensions of) UML and OCL [7, 2], and (ii) transformations defined in UML and captured formally by graph transformations [10, 23, 28]. Up to now, OCL-based approaches typically superseded graph transformation-based approaches when considering multilevel static metamodeling aspects. However, when defining dynamic semantics in a visual and operational (if-then-else like) way — where, in fact, the formal technicalities of the underlying mathematics are hidden — graph transformation has clear advantage over OCL. Our contribution In the paper, we converge the two approaches by providing a precise and multilevel metamodeling framework where transformations are captured visually by a variation of graph transformations systems.

20

1.3

Da ´niel Varr´ o and Andr´ as Pataricza

Metamodeling and Mathematics

Previous research (in project HIDE [5]) demonstrated that automated transformations of UML models into various semantic domains (including Petri nets, Kripke automaton, dataflow networks) allow for an early evaluation and analysis of the system. However, preliminary versions of such transformations were rather ad hoc resulting in error prone implementations with an unacceptably high cost (both in time and workload). In the VIATRA framework [25, 28] (a prototype automated model transformation system), we managed to overcome these problems by providing an automated methodology for designing transformation of UML models. After having implemented more than 10 rather complex transformations in this methodology (including model transformations, for instance, for automated program generation [25], formalizing [26] and model checking [14] UML statecharts), we believe that the crucial step in designing such transformations were to handle uniformly UML and different mathematical domains within the UML framework by metamodeling mathematics. Mathematics of metamodeling When regarding the precise semantics of UML (or metamodeling), one may easily find that there is a huge contradiction between engineering and mathematical preciseness. UML should be simultaneously precise (i) from an engineering point of view to such an extent adequate to engineers who need to implement UML tools but usually lack the proper skills to handle formal mathematics, and, (ii) from a mathematical point of view necessitated by verification tools to reason about the system rigorously. The UML 2.0 RFP requires (votes for) engineering preciseness: “UML should be defined without complicated mathematical formulae.” However, when considering model interpretations of UML sublanguages (i.e., the abstract syntax of a UML model is mapped into a corresponding semantic domain such as Petri nets, finite automaton, etc.), the proper handling of formal mathematics is indispensable for developing automated analysis tools. Metamodeling mathematics Meanwhile, recent standardization initiatives (such as PNML [1], GXL [20], GTXL [24], or MathML [29]) aim at developing XML based description formats for exchanging models of mathematical domains between different tools. Frequently (as e.g. in [24]), such a document design is driven by a corresponding UML-based metamodel of the mathematical domain. However, improper metamodeling of mathematics often results in conceptual flaws in the structure of the XML document (e.g., in PNML, arcs may lead between two places, which is forbidden in the definition of Petri nets). Our contribution Our paper argues that (i) to provide preciseness in UMLbased system design, formal mathematical domains should be integrated with UML by transformations, however, (ii) mathematical models can be understood by engineers if they are presented and specified visually by means of metamodels and graph transformation.

Metamodeling Mathematics: A Precise and Visual Framework

21

7 rest of the paper is structured as follows. We first present a refinement calculus for the static parts of multilevel metamodels based on set-theoretic definitions of mathematical structures in Sec. 2. Afterwards, in Sec. 3, a graph transformation-based framework is presented for the specification of dynamic operational semantics of models, including the hierarchic design and reuse of such semantic rules. Finally, Sec. 4 concludes our paper.

2

Structural Refinement of Metamodels

Below we define a structural refinement calculus on set theoretical basis (i.e., refinement of sets, relations and tuples) for a subset of static UML constructs. Our metamodeling framework is gradually extensible in depth, thus it only contains a very limited number of core elements, which highly decreases the efforts related to implementation. Moreover, in order to avoid replication of concepts and shallow instantiation (well-known problems of metamodeling identified in [4]) we introduce dynamic (or fluid) metalevels where the type–instance relationship is interpreted between models instead of (meta)levels. Our approach has the major advantage that the type–instance relation can be reconfigured dynamically throughout the evolution of models, thus transformations on (traditional) model and metamodel-levels can be handled uniformly. 2.1

Visual Definition of Petri Nets

Before a precise and formal treatment, our goals are summarized informally on a metamodeling example deliberately taken from a well-known mathematical domain, i.e. Petri nets. Petri nets are widely used means to formally capture the dynamic semantics of concurrent systems. However, due to their easy-tounderstand visual notation and the wide range of available tools, Petri net tools are also used for simulation purposes even in industrial projects (reported e.g. in [22]). From an UML point of view, transforming UML models to Petri nets provide dependability [6] and performance analysis [12] for the system model in early stages of design. A possible definition of (the structure of) Petri nets is as follows. Definition 1. A Petri net P N is a bipartite graph with distinct node sets P (places) and T (transitions), edge sets IA (input arcs) and OA (output arcs), where input arcs are leading from places to transitions, and output arcs are leading from transitions to places. Additionally, each place contains an arbitrary (non-negative) number of tokens). Now, if we assign a UML class to each set of this definition (thus introducing the entity of Place, Transition, InArc, OutArc, and Token), and an association for each allowed connections between nodes and edges (connections such as fromPlace, toPlace, fromTrans, toTrans, and tokens), we can easily obtain a metamodel of Petri Nets (see the upper right corner of Fig. 1) that seems to be satisfactory.

22

D´ aniel Varr´ o and Andr´ as Pataricza

Graph

Petri Net from

Node

Edge

Transition

to

Place

refinement

fromPlace

instance of

OutArc Girl

Token

toPlace

from Trans BipartiteGraph

tokens

toTrans

InArc

Boy to1 to2

from1

from2

GBEdge

Node

Entity

Edge Token

BGEdge

Girl

Transition

Boy

Place

GBEdge

OutArc

BGEdge

InArc

t1Token

SimpleNet p1Place

e1

t1Token

from p1Place Relation

from1

fromTrans

from2

fromPlace

to1

toTrans

to2

toPlace

to tokens

e1

Fig. 1. Defining the structure of Petri Nets

However, we have not yet considered a crucial part of the previous definition, which states that a Petri net is, in fact, a bipartite graph. For this reason, after looking up a textbook on graph theory, we may construct with the previous analogy the metamodel of bipartite graphs (depicted in the lower left corner of Fig. 1) with ‘boy’ and ‘girl’ nodes1 , and ‘boy-to-girl’ and ‘girl-to-boy’ edges. Moreover, if we focus on the fact that every bipartite graph is a graph, we may independently obtain a metamodel of graphs (see the upper left corner of Fig. 1). In order to inter-relate somehow these metamodels, we would like to express that, for instance, (i) the class Node is a supertype of class Boy, (ii) the association fromPlace is inherited (indirectly) from the association from, and (iii) the metamodel of bipartite graph is a generalization of the metamodel of Petri nets. In the rest of the paper, we denote these relations uniformly by the term refinement, which simultaneously refers to the refinement of entities, connections, and (meta)models. Our notion of refinement should also handle the instantiations of classes. For instance, in the lower right corner of Fig. 1, a Petri net model SimpleNet consisting of a single place with one token is depicted. This model is regarded as an instance of the Petri net metamodel as indicated by the dashed arrow between the models. 1

Bipartite graphs are often explained as relations between the set of boys and girls.

Metamodeling Mathematics: A Precise and Visual Framework Mapping

23

ModelElem id:Universe

Model

arg

ret

Entity content

arg1

Connection

arg2

Fig. 2. The MOF metamodel of our approach

From a practical point of view, supposing that we have an extensible metamodel library, a new metamodel can be derived from existing ones by refinement. Our main goal is to show that (i) mathematical and metamodel constructs can be handled uniformly and precisely, and (ii) the dynamic operational semantics of models can also be inherited and reused with an appropriate model refinement calculus in addition to the static parts of the models. 2.2

Formal Semantics of Static Model Refinement

Our metamodeling framework VPM uses a minimal subset of MOF constructs (i.e., classes, associations, attributes, and packages) with a slightly re-defined (better to say, precisely defined) semantics, which has a direct analogy with the basic notions of mathematics, i.e., sets, relations, functions, and tuples (tuples are constituted in turn from sets, relations and other tuples). However, in order to avoid clashes between notions of MOF and set theory as much as possible, a different naming convention is used in the paper, which simultaneously refers to UML and mathematical elements. A model element in VPM may be either an entity, a connection, a mapping, or a model (see the MOF metamodel of our approach in Fig. 2). Each of these constructs is indexed by a unique identifier (accessed by a .id postfix in the sequel) and a set including the identifier of the entity and the identifiers of the (intended) refinements of the entity (accessed by a .set postfix).2 – An entity E, which is the most basic element of the model space. Entities are represented visually by UML Classes. – A connection R between two entities is a binary relation between the associated sets. Connections are depicted as (directed) associations. – A mapping F from entity E1 to entity E2 is a function with the domain of (the set of) E1 and range of E2 . Mappings can be denoted visually by an attribute assigned to the entity of its domain. 2

This philosophy is in analogy with the axiomatic foundations of set theory. There we have classes as a notion that remains undefined. An element of a class is by definition a set, while the singleton class that contains this element is also a set.

24

D´ aniel Varr´ o and Andr´ as Pataricza

– A model (or structure) M is a tuple consisting of the corresponding sets, relations, functions and tuples of entities, connections, mappings, and models, respectively. Models will be represented by UML packages. A model that only consist of a single entity is also regarded as an entity. The static semantics of our metamodeling framework is based upon a refinement calculus (depicted by UML generalization relations) that handles the traditionally distinct notions of inheritance and instance-of relations uniformly. def 1. Entity refinement: E1
⇒ E2 = E1 .set ⊆ E2 .set (E1 is a(n entity) refinement of E2 , alternatively, E2 is an abstraction of E1 ). Informally, E2 is a superclass of E1 in the terms of MOF metamodeling. def 2. Connection refinement: R1 (A1 , B1 )
⇒ R2 (A2 , B2 ) = R1 .set ⊆ R2 .set ∧ A1
⇒ A2 ∧ B1
⇒ B2 (where all Ai and Bi are entities). Connection refinement expresses the fact that MOF associations can also be refined during the evolution of metamodels. def 3. Mapping refinement: F1 (A1 ) : B1
⇒ F2 (A2 ) : B2 = F1 .set ⊆ F2 .set ∧ A1
⇒ A2 ∧ B1
⇒ B2 (i.e., functions are treated as special relations). From a practical point of view, MOF attributes are also considered in our metamodeling framework. def 4. Model refinement: M1n
⇒ M2k = M1 .set ⊆ M2 .set∧∀i∃j : M1 [j]
⇒ M2 [i] (M1 is a model refinement of M2 ), where M [i] is the ith argument (component) of tuple M . Informally, there exists a refinement of each argument of M2 in a corresponding argument of M1 . In MOF terms, each class in the super model is refined into an appropriate class of the submodel. However, this latter one may contain additional classes not having origins in the supermodel. def 5. Model instance: M1n → M2k = M1 .set ⊆ M2 .set ∧ ∀i∃j : M1 [i]
⇒ M2 [j] (M1 is a (model) instance of M2 ). Informally, there exists a refinement of each component of M1 in a corresponding component of M2 . In practice, each object in the instance model has a proper class in the metamodel. However, this latter one may contain additional classes without objects in the instance model. 6. Instantiation, typing: a model element X ∈ M1 is an instance of model element Y ∈ M2 (alternatively, Y is the type of X), denoted as , if M1 is a model instance of M2 , and X is a refinement of Y . Formally, M1 .X → def M2 .Y = M1 → M2 ∧ X
⇒ Y . In MOF terms, a class is said to be the type of an object, if the corresponding model of the object is an instance of the (meta)model related to the class. In order to close the refinement calculus from the top, we suppose that there exists a unique top-most model containing a unique top-most entity, connection and function. A main advantage of our approach (in contrast to e.g. [3]) is that type-instance relations can be reconfigured dynamically. On one hand, as a model can take the

Metamodeling Mathematics: A Precise and Visual Framework

25

role of a metamodel (thus being simultaneously a model and a metamodel) by altering only the single instance relation between the models, we avoid the problems of “replication of concepts” and “shallow instantiation”. On the other hand, transformations on different metalevels can be captured uniformly, which is an extremely important feature when considering the evolution of models through different domains [23]. 2.3

Formalizing the Petri Net Metamodel Hierarchy

The theoretic aspects of model refinement (and instantiation) are now demonstrated on the Petri net metamodel hierarchy. Supposing that the refinement relations depicted at the bottom of Fig. 1 hold between the model elements (e.g., Boy is a refinement of Node, e1 is a refinement of tokens; the interested reader can verify that all the connection refinements are valid) we can observe the following. Proposition 1. BipartiteGraph is both a model refinement and instance of Graph. Proof. The proof consist of two steps. 1. Proof of refinement: for each element in the Graph model there exist a refinement in the BipartiteGraph. Girl is refinement of Node; GBEdge is of Edge; from1 is derived from from; and to1 is refined from to. 2. Proof of instantiation: for each element in Bipartite Graph there exist a refinement in Graph. Girl and Boy are refinements of Node; GBEdge and BGEdge are of Edge; from1 and from2 are of from; and to1 and to2 are of to. ⊔ ⊓ By similar course of reasoning, we can prove all the other relations between different models of Fig. 1. Note that Petri Net is not an instance of Bipartite Graph (as Token is a new element), and SimpleNet is not a refinement of Petri Net (since, for instance, there are no transitions).

3

Dynamic Refinement in Operational Semantic Rules

Now we focus our attention to extend the static metamodeling framework by a general and precise means for allowing the user to define the evolution of his models (dynamic operational semantics) in a hierarchical and operational way. Our approach uses model transition systems [28] as the underlying mathematics, which is formally a variant of graph transformation systems enriched with control information. However, from a UML point of view, model transition systems are merely a pattern-based manipulation of models driven by an activity diagram (specified, in fact, by a UML profile in our VIATRA tool), thus the domain engineer only has to learn a framework that is very close to the concepts of UML. After specifying

26

D´ aniel Varr´ o and Andr´ as Pataricza

the semantics of the domain, a single virtual machine of model transition systems may serve a general meta-simulator for arbitrary domains. In the current section, we first demonstrate that model transition systems are rich enough to be a general purpose framework for specifying dynamic operational semantics of modeling languages in engineering and mathematical domains by constructing (an executable) formal semantics for Petri nets. Afterwards, we define the notion of rule refinement, which allows for a controlled reuse of semantic operations of abstract mathematical models (such as graphs, queues, etc.) in engineering domains. 3.1

An Introduction to Model Transition Systems

Graph transformation (see [19] for theoretical foundations) provides a rule-based manipulation of graphs, which is conceptually similar to the well-known Chomsky grammar rules but using graph patterns instead of textual ones. Formally, a graph transformation rule (see e.g. addTokenR in Fig. 3 for demonstration) is a triple Rule = (Lhs, N eg, Rhs), where Lhs is the left-hand side graph, Rhs is the right-hand side graph, while N eg is (an optional) negative application condition (grey areas in figures). The application of a rule to a model (graph) M (e.g., a UML model of the user) alters the model by replacing the pattern defined by Lhs with the pattern of the Rhs. This is performed by 1. finding a match of the Lhs pattern in model M ; 2. checking the negative application conditions N eg which prohibits the presence of certain model elements; 3. removing a part of the model M that can be mapped to the Lhs pattern but not the Rhs pattern yielding an intermediate model IM ; 4. adding new elements to the intermediate model IM which exist in the Rhs but cannot be mapped to the Lhs yielding the derived model M ′ . In a more operational interpretation, Lhs and N eg of a rule defines the precondition while Rhs defines the postcondition for a rule application. In our framework, graph transformation rules serve as elementary operations while the entire operational semantics of a model is defined by a model transition (transformation) system [28], where the allowed transformation sequences are constrained by control flow graph (CFG) applying a transformation rule in a specific rule application mode at each node. A rule can be executed (i) parallelly for all matches as in case forall mode; (ii) on a (nondeterministically selected) single matching as in case of try mode; or (iii) as long as applicable (in loop mode). 3.2

Model Transition System Semantics of Petri Nets

In order to demonstrate the expressiveness of our semantic basis (in addition to the technicalities of graph transformation), we provide a model transition system semantics for Petri nets (in Fig. 3) based on the following definition.

Metamodeling Mathematics: A Precise and Visual Framework

Petri Net Transition enable:Bool fire:Bool

Place tokens toTr fromPl

fromTr

addTokenR

delFireR

outArcsR

enableTrR

delTokenR

InArc

OutArc

fail

del

LHS

RHS

T:Trans

K:Token

toTr

delEnableR

Token

toPl

add

T:Trans enable=T

selectFireR

LHS

RHS

T:Trans enable=T fire=F

T:Trans enable=T fire=T

A:InArc fromPl

RHS

LHS T:Trans enable=T

A:InArc

del

A:InArc

RHS

T:Trans fire=T

K:Token

del

LHS

T:Trans fire=T

fromTr

fromTr

A:OutArc

P:Place

A:InArc fromPl

P:Place

delTokenR

RHS

T:Trans fire=T

T:Trans fire=T

tokens

A:InArc fromPl

inArcsR LHS

RHS T:Trans enable=F

delEnableR

LHS

T:Trans fire=T toTr

T:Trans fire=F

delFireR

enableTransR

toTr

inArcsR

RHS

T:Trans fire=T

selectFireR

P:Place

T:Trans fire=T

succeed

LHS

tokens

LHS

27

add

A:OutArc

outArcsR

RHS

T:Trans fire=T

T:Trans fire=T

K:Token

add A:OutArc

tokens toPl

P:Place

A:OutArc

toPl

P:Place

addTokenR

Fig. 3.  del transition semantics of Petri nets

Definition 2 (Informal semantics of Petri nets). A micro step of a Petri net can be defined as follows.

28

D´ aniel Varr´ o and Andr´ as Pataricza

1. A transition is enabled when all the places with an incoming arc to the transition contain at least one token (we suppose that there is at most one arc between a transition and a place). 2. A single transition is selected at a time from the enabled ones to be fired. 3. When firing a transition, a token is removed from each incoming place, and a token is added to each outgoing place (of a transition). 4. When no transitions are enabled the net is dead. At the initial step of our formalization, we extend the previous metamodel of Petri nets by additional features (such as mappings/attributes enable and fire, or connections add and del) necessitated to capture the dynamic parts. Then the informal interpretation of the rules (given in the order of their application) is as follows. Note that to improve the clarity, the types of each model element are depicted textually instead of the original graphical representation by inheritance relations. Thus, for instance, T:Trans can be interpreted as T is a direct refinement of Trans. 1. The enable and fire attributes are set to false for each transition of the net by applying rules delEnableR and delFireR in forall mode. 2. A transition T becomes enabled (by applying enableTrR) only if for all incoming arc A linked to a place P, this place must contain at least one token K (note the double negation in the negative conditions). 3. A single transition is selected non-deterministically by executing selectFireR in try mode. If no transitions are enabled then the simulation of the net is finished. 4. All the InArcs are marked by a del edge that lead to the transition selected to be fired by the application of rule inArcsR. 5. A token is removed from all places that are connected to an InArc marked by a del edge. The corresponding rule (delTokenR) is applied as long as possible (in loop mode) and a del edge is removed in each turn. 6. A process similar to Step 4 and 5 marks the places connected to the transition to be fired by add edges and generates a token for each of them, and the micro step is completed. 3.3

Rule Refinement

A main goal of multilevel metamodeling is to allow a hierarchical and modular design of domain models and metamodels where the information gained from a specific domain can be reused (or extended) in future applications. Up to now, metamodeling approaches only dealt with the reuse of the static structure while the reuse of dynamic aspects has not been considered. However, it is a natural requirement (and not merely in mathematical domains) that if a domain is modeled as a graph then all the operations defined in a library of graphs (such as node/edge addition/deletion, shortest path algorithms, depth first search, etc.) should be adapted for this specific domain without further modifications.

Metamodeling Mathematics: A Precise and Visual Framework

LHS N:Node ref=0

RHS

LHS P:Place ref=0 tokens

delNodeR

29

RHS K:Token

delPlaceR

Fig. 4. Rule refinement

Moreover, semantic operations are frequently needed to be organized in a hierarchy (and/or executed accordingly). For instance, in feature/service modeling, we would like to express for the user that an operation copying highlighted text from one document to another and another operation that copying a selected file between two directories are conceptually similar in behavior when regarding from a proper level of abstraction. To capture such semantic abstractions, we define rule refinement as a precise extension of metamodeling for dynamic aspects of a domain as follows. A model pattern M1 appearing in a graph transformation rule (either in Lhs, Rhs, or N eg) is a typed subpattern (or typed subgraph) of a model pattern M2 (denoted as M1 ≤ M2 ) if all model elements E1 of M1 can be mapped (isomorphically) to a corresponding element E2 of M2 such that the type of E2 is a refinement of the type of E1 . Informally, pattern M1 is more general than pattern M2 in the sense that whenever the matching of M2 succeeds it immediately implies the successful matching of M1 . Based upon the definition of typed subpatterns, the refinement relation of typed rules is defined as follows: a rule r1 = (Lhs1 , Rhs1 , N eg1 ) is a refinement of rule r2 = (Lhs2 , Rhs2 , N eg2 ) (denoted as r1
⇒ r2 ) if 1. Lhs2 ≤ Lhs1 : the positive preconditions of r2 are weaker than of r1 2. N eg2 ≤ N eg1 : the negative preconditions of r2 are weaker than of Lhs1 . As a result, r2 can be applied whenever r1 is applicable 3. Rhs2 \ Lhs2 ≤ Rhs1 \ Lhs1 : r1 adds at least the elements that are added by the application of r2 4. Lhs2 \ Rhs2 ≤ Lhs1 \ Rhs1 : r1 removes at least the elements that are deleted by the application of r2 . As a result, the postconditions of r1 are stronger than of r2 . The concepts of rule refinement are demonstrated on a brief example (see Fig. 4). Let us suppose that a garbage collector removes a Node from the model space (by applying rule delNodeR) if reference counter of the node has been decremented to 0 (denoted by the attribute condition ref=0). Meanwhile, in case of Petri nets, we may forbid the presence of tokens not assigned to a place. Therefore, even when the reference counter of a Place (which used to be a refinement of Node) reaches 0, an additional test is required for the non-existence of tokens attached. If none of such tokens are found then the place P can be safely removed (cf. rule delPlaceR).

30

D´ aniel Varr´ o and Andr´ as Pataricza

Proposition 2. Rule delPlaceR is a refinement of rule delNodeR. Therefore, in typical applications (visual model editors, etc.) delPlaceR takes precedence of delNodeR. Proof. The three steps of the proof are the following: 1. LhsdelN odeR ≤ LhsdelP laceR since Place (the type of P) is a refinement of Node (the type of N). 2. N egdelN odeR ≤ LhsdelP laceR since rule delNodeR has no negative conditions. 3. Conditions 3 and 4 trivially hold for the empty right-hand sides of rules.

4

C onclusions

We presented a visual, and precise metamodeling (VPM) framework that is capable of uniformly handling arbitrary models from engineering and mathematical domains. Our approach based upon a simple refinement calculus provides a multilevel solution covering the visual definition of both static structure and dynamic behavior. Compared to dominating metamodeling approaches, VPM has the following distinguishing characteristics. – VPM is a multilevel metamodeling framework. The majority of metamodeling approaches (including ones that build upon the MOF standard [17]; GME [15], PROGRES [21] or BOOM [18]) considers only a predefined number of metalevels. While only [3] (a framework for MML) and [4] supports multilevel metamodeling. By the dynamic reconfiguration of type-instance relationship between models, VPM provides such a solution that avoids the problem of replication of concepts (from which [3] suffers as identified in [4]). – VPM has a visual (UML-based) and mathematically precise specification language for dynamic behavior. Like [9, 21] for UML semantics, or [23] for model migration through different domains, VPM uses a variant of graph transformation systems (introduced in [28]) for capturing the dynamic behavior of models, which provides a purely visual specification technique that fits well to a variety of engineering domains. – VPM provides a reusable and hierarchical library of models and operations. Extending existing static and dynamic metamodeling approaches, models and operations on them are arranged in a hierarchical structure based on a simple refinement calculus that allows a controlled reuse of information in different domains. Initiatives for a reusable and hierarchical static metamodeling framework include MML [7] and GME [15], however, none of them provides reusability for rules. – VPM supports model transformations within and between metamodels. The model transformation concepts of VPM is built on results of previous research [28, 27] in the field. Similar applications have been reported recently in [10, 11]. – VPM can precisely handle mathematical domains as demonstrated by the running example of the paper.

Metamodeling Mathematics: A Precise and Visual Framework

31

The theoretical foundations introduced in the paper are supported by a prototype tool called VIATRA (VIsual Automated model TRAnsformations) [28]. VIATRA has been designed and implemented to provide automated transformations from between models defined by a corresponding MOF metamodel (tailored, especially, to transformation from UML to various mathematical domains). Recently, this tool is being extended to support the multilevel aspects of the VPM approach. Further research is aiming at (i) to design a pattern-based constraint language for expressing static requirements, (ii) to provide model checking facilities for specification based on VPM, and (iii) an automated translation of mathematical structures (from formal definitions given in a MathML format) into their corresponding VPM metamodel.

A ck nowledgments We would like to thank Gergely Varr´ o, John Rushby and many of his colleagues at SRI International for their valuable comments.

References [1] Petri Net Markup Language. URL http://www.informatik.hu-berlin.de/ top/pnml. 20 [2] D. Akehurst. Model Translation: A UML-based specification technique and active implementation approach. Ph.D. thesis, University of Kent, Canterbury, 2000. 19 [3] J. Alvarez, A. Evans, and P. Sammut. Mapping between levels in the metamodel architecture. In M. Gogolla and C. Kobryn (eds.), Proc. UML 2001 – The Unified Modeling Language. Modeling Languages, Concepts and Tools, vol. 2185 of LNCS, pp. 34–46. Springer, 2001. 24, 30 [4] C. Atkinson and T. K¨ uhne. The essence of multilevel metamodelling. In M. Gogolla and C. Kobryn (eds.), Proc. UML 2001 – The Unified Modeling Language. Modeling Languages, Concepts and Tools, vol. 2185 of LNCS, pp. 19–33. Springer, 2001. 21, 30 [5] A. Bondavalli, M. D. Cin, D. Latella, I. Majzik, A. Pataricza, and G. Savoia. Dependability analysis in the early phases of UML based system design. International Journal of Computer Systems - Science & Engineering, vol. 16(5):pp. 265–275, 2001. 20 [6] A. Bondavalli, I. Majzik, and I. Mura. Automatic dependability analyses for supporting design decisions in UML. In Proc. HASE’99: The 4th IEEE International Symposium on High Assurance Systems Engineering, pp. 64–71. 1999. 21 [7] T. Clark, A. Evans, and S. Kent. The Metamodelling Language Calculus: Foundation semantics for UML. In H. Hussmann (ed.), Proc. Fundamental Approaches to Software Engineering, FASE 2001 Genova, Italy, vol. 2029 of LNCS, pp. 17–31. Springer, 2001. 19, 30 [8] H. Ehrig, G. Engels, H.-J. Kreowski, and G. Rozenberg (eds.). Handbook on Graph Grammars and Computing by Graph Transformation, vol. 2: Applications, Languages and Tools. World Scientific, 1999. 32

32

D´ aniel Varr´ o and Andr´ as Pataricza

[9] G. Engels, J. H. Hausmann, R. Heckel, and S. Sauer. Dynamic meta modeling: A graphical approach to the operational semantics of behavioral diagrams in UML. In A. Evans, S. Kent, and B. Selic (eds.), UML 2000 - The Unified Modeling Language. Advancing the Standard, vol. 1939 of LNCS, pp. 323–337. Springer, 2000. 30 [10] G. Engels, R. Heckel, and J. M. K¨ uster. Rule-based specification of behavioral consistency based on the UML meta-model. In M. Gogolla and C. Kobryn (eds.), UML 2001: The Unified Modeling Language. Modeling Languages, Concepts and Tools, vol. 2185 of LNCS, pp. 272–286. Springer, 2001. 19, 30 [11] R. Heckel, J. K¨ uster, and G. Taentzer. Towards automatic translation of UML models into semantic domains. In Proc. AGT 2002: Workshop on Applied Graph Transformation, pp. 11–21. Grenoble, France, 2002. 30 [12] G. Huszerl and I. Majzik. Quantitative analysis of dependability critical systems based on UML statechart models. In HASE 2000, Fifth IEEE International Symposium on High Assurance Systems Engineering, pp. 83–92. 2000. 21 [13] C. Kobryn. UML 2001: A standardization Odyssey. Communications of the ACM, vol. 42(10), 1999. 19 [14] D. Latella, I. Majzik, and M. Massink. Automatic verification of UML statechart diagrams using the SPIN model-checker. Formal Aspects of Computing, vol. 11(6):pp. 637–664, 1999. 20 [15] A. Ledeczi., M. Maroti, A. Bakay, G. Karsai, J. Garrett, C. Thomason, G. Nordstrom, J. Sprinkle, and P. Volgyesi. The Generic Modeling Environment. In Proc. Workshop on Intelligent Signal Processing. 2001. 30 [16] Object Management Group. UML Profile for Schedulability, Performance and Time. URL http://www.omg.org. 19 [17] Object Management Group. Meta Object Facility Version 1.3, 1999. URL http://www.omg.org. 30 ¨ [18] G. Overgaard. Formal specification of object-oriented meta-modelling. In T. Maibaum (ed.), Proc. Fundamental Approaches to Software Engineering (FASE 2000), Berlin, Germany, vol. 1783 of LNCS. Springer, 2000. 30 [19] G. Rozenberg (ed.). Handbook of Graph Grammars and Computing by Graph Transformations: Foundations. World Scientific, 1997. 26 [20] A. Sch¨ urr, S. E. Sim, R. Holt, and A. Winter. The GXL Graph eXchange Language. URL http://www.gupro.de/GXL/. 20 [21] A. Sch¨ urr, A. J. Winter, and A. Z¨ undorf. In [8], chap. The PROGRES Approach: Language and Environment, pp. 487–550. World Scientific, 1999. 30 [22] A. Singh and J. Billington. A formal service specification for IIOP based on ISO/IEC 14752. In B. Jacobs and A. Rensink (eds.), Proc. Fifth International Conference on Formal Methods for Open Object-Based Distributed Systems (FMOODS 2002), pp. 111–126. Kluwer, Enschede, The Netherlands, 2002. 21 [23] J. Sprinkle and G. Karsai. Defining a basis for metamodel driven model migration. In Proceedings of 9th Annual IEEE Internation Conference and Workshop on the Engineering of Computer-Based Systems, Lund, Sweden. 2002. 19, 25, 30 [24] G. Taentzer. Towards common exchange formats for graphs and graph transformation systems. In J. Padberg (ed.), UNIGRA 2001: Uniform Approaches to Graphical Process Specification Techniques, vol. 44 of ENTCS. 2001. 20 [25] D. Varr´ o. Automatic program generation for and by model transformation systems. In H.-J. Kreowski and P. Knirsch (eds.), Proc. AGT 2002: Workshop on Applied Graph Transformation, pp. 161–173. Grenoble, France, 2002. 20

Metamodeling Mathematics: A Precise and Visual Framework

33

[26] D. Varr´ o. A formal semantics of UML Statecharts by model transition systems. In H.-J. Kreowski and P. Knirsch (eds.), Proc. ICGT 2002: 1st International Conference on Graph Transformation, LNCS. Springer-Verlag, Barcelona, Spain, 2002. Accepted paper. 20 [27] D. Varr´ o, S. Gyapay, and A. Pataricza. Automatic transformation of UML models for system verification. In J. Whittle et al. (eds.), WTUML’01: Workshop on Transformations in UML, pp. 123–127. Genova, Italy, 2001. 30 [28] D. Varr´ o, G. Varr´ o, and A. Pataricza. Designing the automatic transformation of visual languages. Science of Computer Programming, vol. 44(2), 2002. In print. 19, 20, 25, 26, 30, 31 [29] World Wide Web Consortium. MathML 2.0. URL {http://www.w3c.org/Math}. 20

A Radical Reduction of UML’s Core Semantics Friedrich Steimann and Thomas Kühne Institut fü r Technische Informatik Rechnergestü tzte Wissensverarbeitung Universität Hannover, Appelstraße 4 D-30167 Hannover [email protected]

Praktische Informatik Technische Universität Darmstadt Wilhelminenstraße 7 D-64283 Darmstadt [email protected]

Abstract. UML’s current core semantics suffers both from excessive complexity and from being overly general. Resultant is a language definition that is difficult to master and to repair. This is the more disturbing as the current core and its extensions do very little to integrate statics and dynamics, even though the inseparability of these is a property of software from which many of the modelling difficulties arise. To better this unsatisfactory situation, we suggest a simple modelling core with few concepts that are easy to understand, yet cover most static and dynamic modelling aspects. We present our work, which is founded in elementary set theory, in natural language making it equally accessible for both practitioners and formalists.

1

Introduction

Much has been written about the shortcomings in the current UML specification, which almost paradoxically contrasts the standard’s considerable length. Without adding to the ever expanding list of inaccuracies and inconsistencies, we maintain here that many of the standard’s flaws are rooted in its foundation, particularly in its core package and associated semantics. However, the same unwieldiness that left the faults undiscovered by its designers makes it difficult to evolve the standard into something sound. Therefore, we propose a radically revised language core that builds on a small set of primitive modelling concepts, with new abstract syntax and formal semantics. We demonstrate that this new core is to a large extent compatible with UML’s current concrete syntax and pragmatics. One of the key points of our contribution is that the language we propose is designed right from the bottom up with a strong emphasis on integrating statics and dynamics, so that the same small core can serve as the basis for both the static and the dynamic views on a system. So far, a formulation of such an underlying model has been hinted at only, leaving the various views offered by the language largely disconnected. We are well aware, though, that much remains to be done to cover the whole of current UML syntax and semantics. Therefore, our core language can only be a language core, to be extended wherever deemed necessary. The remainder of this paper is organized as follows. We start by briefly reviewing our choice of core modelling concepts and then define a minimal abstract syntax

J.-M. J´ez´equel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 34-48, 2002. c Springer-Verlag Berlin Heidelberg 2002

A Radical Reduction of UML’s Core Semantics

35

which is based on a blend of order-sorted logic and set theory. The formal semantics of this syntax is heritage from corresponding formal frameworks offered by the logic programming community [1] and hence only touched on. Following, we show the mapping of UML diagram types to this abstract syntax. A brief discussion concludes our paper. Before proceeding with the presentation of the basic concepts on which we build our language definition, we would like to stress one subtlety that often leads to confusion. Generally, we do not speak of a core model, but of a core (modelling) language, since we do not intend to model UML (just like a UML user would model any other subject domain). Rather, we rely on elementary set theory (our metalanguage) to specify a language (our object language) the sentences of which are interpreted as models of software systems. The semantics of standard UML diagrams is defined by providing a set of mapping rules to our object language, which, being based on set theory, has standard semantics. By not following the common metamodelling approach favoured by the OMG we do not only avoid circular definitions, but also the unfortunate situation that every change of the UML concrete syntax entails rewriting of the whole definition, because the metalanguage changes with it.

2

Core Modelling Concepts

2.1 Time Conceptual modelling and its most prominent semantic foundation, formal logic, have a long tradition in ignoring time: even though change and hence time are the very nature of software systems, the ER(= basically predicate logic)-based strain of modelling tends to neglect the ubiquitous duality of static and dynamic viewpoints. For instance, multiplicities (or cardinalities) apply to the contemporaneous number of links between objects (or entities) and hence place constraints on change rather than static structure (see section on extensions below). As a consequence we maintain that statics and dynamics are not as orthogonal as many modelling language specifications (including UML) would like them to appear. We try to do away with this inadequacy by putting time at the core of our modelling language. In particular, we regard time as an index to all modelling expressions at the instance level, albeit mostly only indirectly, through state. Actually, time indices comes in two guises: quantitatively, as absolute or relative points on a linear time scale, and qualitatively, with sequence as the underlying time model. The difference between these two is much bigger than it may seem: specifications of the latter form usually cover a whole lot of alternative evolutions simultaneously (a non-linear or branching time model), whereas specifications based on the former are typically non-branching, showing only a single evolution (usually out of many possible). 2.2 Intension and Extension Intension and extension are properties of concepts. In our setting, the intension of a modelling concept may be equated with its definition or specification. Intensions are usually only changed during the development process of a software system, not while

36

Friedrich Steimann and Thomas K¨uhne

the software is executing. Hence, we regard intension as a static (i.e., atemporal) concept. The reflective capabilities of some OOPLs make an exception to this common assumption, but are not considered here. The extension of a modelling concept is the set of elements that fall under that concept, i.e., that are adequately described by the concept’s intension. Unlike intensions, extensions are inherently dynamic: elements come and leave extensions over time, making them grow and shrink. The static extension of a concept, if at all a useful notion, may be considered the temporal projection of (or union over all) its dynamic extensions.1 It must be understood, then, that certain constraints (e.g. cardinality) expressed for the extension of a concept hold only for its dynamic extensions. 2.3 Types Types are at the heart of modelling. Equipped with intensions and extensions, they serve as specifiers for the properties of sets of objects that can be treated alike, and as constraints expressing objects of which kinds may take which places. In our core language we need two kinds of types: natural types, which we call classes, and role types, which we call roles2. For readers unfamiliar with the role-astype concept, roles as used here may safely be equated with the interfaces of UML and JAVA [6]. UML makes a further difference between object and primitive types (misnamed data types); however, this distinction is of no concern in this discourse and hence ignored. There exists a rather crisp ontological distinction between classes and roles, based on the dynamic extensions of types and associations. Briefly, a type is a class if for an object to belong to that type no engagement in a relationship to other objects is necessary, and changing this type (so-called object migration) means that the object loses its identity. For instance, a person is a person qua being, not per relatedness to any other object, and it cannot stop being a person without losing its identity. A role, on the other hand, is only adopted in the context of an association, and taking on a role or giving it up does not change the object’s identity. For instance, a father is only a father if he has children, but becoming a father does not change the individual’s identity. As an aside, note that unlike classes, roles have no instances of their own; they must recruit them from natural types, i.e., classes. The concept of roles in UML has been thoroughly revised in [4]; its equality to interfaces has been argued for elsewhere [6, 7]. Readers feeling uncomfortable with the prominent role roles play in this treatise may continue by ignoring roles and the associated modelling issues, albeit only at the price of losing some of the coverage of the more advanced UML semantics (interface specifiers, collaboration roles etc.). 2.4 Objects The extensions of types are sets of objects. The sets are dynamic, reflecting the fact that objects come into life (technically referred to as instance creation) and disappear (referred to as destruction). Whereas for classes instance creation and destruction 1

2

We speak of the dynamic extensions of a concept in plural here since our underlying view is that a concept has a (dynamic) extension at each point in time. We have taken special care that there is no danger of confusing the type and the instance level when speaking of roles.

A Radical Reduction of UML’s Core Semantics

37

alone change the extensions, things are different for roles: the dynamic extension of a role at time t is defined as the set of objects occurring — at the same time t — in the dynamic extents of any associations, in the place of that role. Thus, the dynamic extensions of roles depend on those of classes and those of associations. As is commonly understood, in our approach too all objects have identity. Some objects have nothing but their identity, for instance numbers. Objects can be named; in this case, the name serves for referencing the object and may be considered an alias for the identity. 2.5 Type Hierarchies and Inheritance Types are organized in hierarchies, one for each kind of type: a class hierarchy and a role hierarchy. Both are subsumption hierarchies, i.e., each supertype subsumes its subtypes. The connotation of type subsumption here is that the extensions of supertypes include the extensions of all their subtypes. Conversely, the intension of a subtype implies the intensions of all its supertypes, meaning that all properties specified for a supertype also hold for its subtypes. Thus, type subsumption establishes type compatibility; it may be considered equivalent to the generalization relationship of UML and entails what is commonly called inheritance in OOPLs. The class and the role hierarchy are connected through a special relationship extending the type compatibility, by specifying the objects of which classes can appear where which roles are specified. For a quick understanding, this relationship can be equated with the realizes dependency of UML and the implements keyword of the JAVA programming language, specifying the instances of which classes can be assigned to variables of which interface type. The full semantics of this relationship, especially with regard to intensions and extensions, is a little more complicated and detailed in [3, 5]. 2.6 Attributes Each class comes with a set of attributes. Each attribute is modelled as an unary function from the extension of the class to some value domain, namely the extension of another class. Again, we refrain from making a distinction between object and primitive types. Many-valued attributes (i.e., attributes that can have several values at the same time) are modelled as attributes with sets3 as the elements of their value type, corresponding to the container types of OOP. There is a certain degree of freedom as to whether or not a relationship between two objects should be modelled as an attribute or as a structural association (see below). Although there are some theoretical hints on how to decide this question, the issue is of no importance for the further discourse and can safely be ignored.4 We stress here, though, that our focus is on the conceptual side of modelling, not on implementational issues.

3 4

Mathematically, tuples, sequences and bags (multisets) can all be modelled as sets. Just a quick ontological hint: attributes usually model qualities of an object, not relationships; hence classes are preferred over roles as value types.

38

Friedrich Steimann and Thomas K¨uhne

2.7 Associations Objects can engage in relationships with certain other objects. This property is specified on the type level, by declaring the involved types as arguments to associations. The declaration is part of the association’s intension. Other properties usually complement the declaration, but are not considered here. Associations are generally interpreted as relations in the mathematical sense, i.e., as subsets of the Cartesian products of the extensions of the involved types. The dynamic extensions of an association are tuples called links (Section 2.8 below). Note that this definition leaves it open how associations are to be used, i.e., whether they define structure or collaboration (see [7] for a deeper discussion). Because this is an important distinction, we subdivide associations into structural and procedural associations below. It is useful to require that associations are defined on roles only. It has been shown in [4] that this elegantly covers many of the lesser used model elements of UML’s static structure and collaboration diagrams without posing unnecessary restrictions on current UML pragmatics. However, to maintain the independent readability of this paper we continue without insisting on this separation. Structural associations. Structural associations model the knowledge an object may have of its environment. In particular, they represent the possible relationships between objects that exist independently of the execution of some procedure. Procedural associations. A procedural association declares the types of the parameters contributing to a procedure, i.e., to a piece of functionality required for the software system to achieve its purpose. The places of a procedural association are one (the first) for the object responsible for executing the procedure (the receiver), one for each other parameter of the procedure, and optionally one (by convention the last) for the return value or result of the procedure. Note that in OOP the understanding is that messages are sent to a receiver. In our modelling language, the coupling of a procedural association with its receiver type is rather loose (in fact, it is not tighter than that of a structural association with any of its types).5 The underlying design decision for the last point is not to introduce return actions as in standard UML, but to view functions (methods that return values) as special relations in the mathematical sense. Aggregation. The concept of aggregation has been the subject of much debate in both the philosophical and conceptual modelling communities. We argue here that because we have no useful standard semantics for the concept of aggregation that should be captured in the core language, there is no good in introducing it; hence we leave it. A possible realization of aggregation at the modelling level is shown in Figure 2.

5

This has some theoretical impact on the resolution of dynamic binding (method dispatching), which is not treated here. See [1] for a formal treatise.

A Radical Reduction of UML’s Core Semantics

39

2.8 Links Links are the elements of the dynamic extensions of associations. They are basically tuples of objects, complemented by the name of the association to whose extension they belong. As with associations, we distinguish between structural links and procedural links. Structural links. Structural links model the relationships between objects that express the knowledge an object has of others, often independent of any particular functional requirement. In particular, structural associations exist before and after the execution of a procedure, but they are often the result of some procedure. Procedural links. Procedural links express relationships existing solely for the purpose of realizing some functionality or, more technically, for executing some procedure. Procedural links are transient by nature; their creation corresponds to the event of a method call (with objects as actual parameters) and their destruction to the end of execution of the called method. A procedural link may survive the procedure by being transformed into a structural link (see Figure 3 for an example). 2.9 States The state of an object-oriented software system (the system state) is the set of its contemporaneously existing objects together with their attribute value assignments (where some objects are the attribute values of others) and the links (both structural and procedural) between them. Due to practical limitations states will usually only be partially specified, i.e., each given state represents only a small excerpt of some total system state. Even though it is understood that a state is a snapshot, single, isolated states are usually not linked to absolute times since it is the very nature of a software system that its state at any one time depends on past states and events that have occurred since then. Instead, states occur in the definition of state transitions and state/event sequences (see below). The state of an object is the set of its attribute value assignments and the links it shares with other objects. It comprises the knowledge an object has of itself and of its environment. 2.10 Events An event corresponds to the creation or destruction of one or more procedural links. Since procedural links contribute to state, any event partially specifies its own successor state. This makes sense because the information conveyed in a procedural link, namely the objects passed as parameters, should at least be temporarily known to the object responsible for the execution of the procedure. In the absence of classes as first class objects instance creation (i.e., a change to the extension of a class) cannot be triggered by an event as defined above, but must be an event in its own right. However, unlike the creation of a procedural link, the creation of a structural link is not an event; rather, it is a reaction to an event reflected in a change of the dynamic extension of a structural association. Events can be timed, meaning that an absolute time or a time relative to the occurrence of another event can be associated with it.

40

Friedrich Steimann and Thomas K¨uhne

2.11 State Transitions A state transition is a mapping from a state and an event to a successor state. In the context of software modelling, two forms of state transitions are of interest: sets of partial specifications of the transition function of a finite state machine in the form “if in state s1 and event e occurs, change to state s2”, and the listing of state/event-sequences of the form . A (complete) transition function specifies a set of possible sequences of events and thus a formal (regular) language; state/event-sequences specify one concrete sequence of events and resultant state changes. Whereas in the former case no absolute time tags can be attached to events or states, such may be useful in the latter case, for instance for specifying a real-time scenario. Just as a state can be associated with both the whole system and each object, so can state transitions: a state transition defined for an object starts from a state of that object and arrives at a state including the new state of that object, plus possibly the changed states of other objects involved and procedural links newly created. State transitions of this kind are usually associated with the object’s type.

3 Core Language With modelling concepts defined as above at hand, we are now equipped to define our core object-oriented modelling language. We do this by first defining the abstract syntax, i.e., by specifying how a model is textually expressed in our language. In Section 4 we show how standard UML diagrams are mapped to this abstract syntax. It must be understood, though, that our core language was not designed to cover everything offered by the UML standard; however, it is only a core that can easily be extended to cover more meaning. 3.1 Abstract Syntax Expressed in our abstract syntax, a UML model consists of a finite set C of class symbols; a finite set R of role symbols; a transitive, reflexive and antisymmetric overloaded relation ≤ defined on C×C, R×R, and C×R, expressing the combined type hierarchy of classes and roles; for each C∈C a set of attribute declarations of the form a: C → D where a is the name of the attribute and D∈C the value type; a finite set S of structural association declarations of the form s: R1 ... Rn where s is the name of the structural association and R 1, ..., Rn∈R are the types of the association’s places; a finite set P of procedural association declarations of the form p: R1 ... Rn where p is the name of the procedural association and R1, ..., Rn∈R are the types of the association’s places; a finite set Σ of states with each state σ∈Σ Σ comprised of a (possibly empty) set OC of object symbols for each C∈C (the dynamic extension of C in state σ);

A Radical Reduction of UML’s Core Semantics

41

an optional attribute value assignment of the form a(o) = u for each object o∈OC and attribute declaration a: E → F with C ≤ E and u∈OD for some D ≤ F (inheritance and type or assignment compatibility!); a (possibly empty) finite set Ls of links of the form s(o1, ..., on) for each structural association declaration s: R1 ... Rn∈S, where o 1 ∈ O C 1 , ..., o n ∈ O C n and C1 ≤ R1 , ..., Cn ≤ Rn (the dynamic extension of s in state σ); a (possibly empty) finite set Lp of links of the form p(o1, ..., on) for each procedural association declaration p: R1 ... Rn∈P, where o 1 ∈ O C 1 , ..., o n ∈ O Cn and C1 ≤ R1 , ..., Cn ≤ Rn (the dynamic extension of p in state σ); and a finite set of exemplary state transitions of the form δ(σ1, l) = σ2 with σ1, σ2 ∈Σ Σ and l∈Lp for some p∈P. A few comments are in place: One might maintain that roles (i.e. interfaces) should appear only at the target ends of unidirectional associations, presumably because interfaces cannot have attributes in JAVA. We do not support this viewpoint. As indicated above, the alternative form of declarations s: T1 ... Tn and p: T1 ... Tn with T1 , ..., Tn∈C∪R is also possible, but less expressive; see [4]. The state transitions of the given form cover the specification of both state machines and a non-branching sequences of state/event pairs. Quite obviously, much of the complexity of modelling lies in the specification of states and state transitions, and thus in the dynamic (i.e., time-indexed) parts of a model. All attempts to increase the expressiveness at the (atemporal) type level must appear misled investments by comparison. The above definition of a core abstract syntax uses natural language and the formal notation of set theory and order-sorted predicate logic [1, 3]; it could also be depicted graphically, for instance in UML, given that a UML diagram can be drawn that has the same meaning as the above prose. Because UML is intended for software modelling and not for defining a language, we have no interest in doing so and since leave it as an academic exercise. 3.2 Semantics and the Family of Language Issue Since our core modelling language builds on the mathematical primitives set, function, and relation, the definition of its semantics in set theory is straightforward. A short definition for a similar language based on order sorted predicate logic has been given in [3]; lengthier treatments can be found in [1]. It must be noted, though, that certain issues such as overloading and binding (which links are instances of which associations) are not unambiguously defined with the language syntax and must be explicitly stated in its semantics. By offering alternative interpretations the same syntax can serve a whole family of modelling languages. Because of its commitment to types, however, it is illusory to pretend that our language could be equally useful for fundamentally different approaches such as prototype-based modelling.

42

Friedrich Steimann and Thomas K¨uhne

3.3 Shortcomings The presented language core strictly distinguishes between types and objects. In particular, whereas objects can have attribute values (“slots”) and can be involved in links, classes cannot. This inhibits, among other things, “static” declarations and instance creation through sending a class a message. Two solutions are possible: either we introduce a special type Type whose instances act as proxies for the ordinary types, or we introduce a metatype level to our object language and let the non-metatypes be instances of metatypes. The former resembles the type system of JAVA, even though without further measures it can do little more than instance creation6. The latter results in a type model similar to that of SMALLTALK; in particular, if all modelling constructs applying to types also apply to metatypes, types may change dynamically, yielding a fully reflective language. Be it as it may, the shortcoming is not as dramatic as it my appear for many programmers, since static features rarely play a role in OOM. Another shortcoming of our language is that it makes no provisions for capturing technical modelling information such as from which diagram a certain model element originates. This is particularly a problem since our aim is to integrate the information of all diagrams into a single representation, so that some information is necessarily lost. However, separate storage of such information is not a problem technically, so that we leave this subtlety aside. 3.4 Core Extension Since our core language is founded on set theory, possible extensions that are theoretically sound and practically useful abound in the literature. It must be understood, though, that most extensions will not lead to the addition of modelling concepts to our language core, but to some standardized formulation of constraints to be placed on models. For instance, cardinality constraints associated with an association translate to expressions requiring that only a certain number of links exist contemporaneously with the same object involved. It appears that the Object Constraint Language (OCL) [2] would lend itself to expressing such constraints; its relationship to our core modelling language, however, must be the subject of another paper.

4

Mapping of UML Diagram Types

Now we come to the final hurdle of our venture: how do UML’s different diagram types map to the suggested core modelling language? After all, our main intent is to keep UML as a notation intact but redefine what the modelling information expressed by the various diagram types is. This not only gives each diagram type a well defined meaning, but also tightly integrates the diagram types with each other, namely as different views to a common model. Let us see how this works, one by one. 4.1 Use Case Diagram A use case maps to a procedural association declaration between an actor and a system. The actor maps to a role symbol, and the system to a class symbol (Figure 1). 6

because all instances of Type must share the same properties

A Radical Reduction of UML’s Core Semantics

43

Since associations should end at roles, an implicit interface between the association end and the system class may be assumed, declaring the view of the use case on the system by hiding other properties of the system irrelevant to this use case. An alternative mapping is to view the actor as an interface to the system and the use case as an unary procedural association declared on that interface (= role; see Figure 1). Such a mapping is adequate if the actor is not itself involved in the use case. Note that uses case, actor and system are all at a very high level of abstraction (and possibly refined as aggregates of procedural associations, roles and classes). The procedural associations of a use case diagram could be instantiated to procedural links with concrete objects at their places, but the use of doing so is rather limited.

System doIt Actor

classes System roles Actor SystemRole type hierarchy System ≤ SystemRole

classes System roles Actor type hierarchy System ≤ Actor

procedural associations procedural associations doIt: SystemRole Actor doIt: Actor Fig. 1. A use case and two alternative mappings to our abstract syntax. doIt becomes a procedural association, Actor a role and System a class. SystemRole is introduced implicitly

4.2 Class Diagram The class diagram depicts primarily types and the structural associations between them. Not incidentally, it is also called static structure diagram. However, method (or operation in UML jargon) declarations and thus elements pertaining to behaviour are also shown in a class diagram. The name of a class maps to a class symbol and that of an interface to a role symbol. Class stereotypes (other than interface and role, which should be mapped to role symbols) are not considered here7. Attributes map to attribute declarations from the holding class to the attribute value type. The method declarations of a class are translated to the declarations of procedural associations of which the first parameter is the defining class (Figure 2).8 Associations map to structural association declarations (Figure 2). Whether or not an association is an aggregation has no formal implications and is thus ignored here, as are multiplicities (cardinality constraints). UML’s restriction disallowing bi-direc7 8

although they could be addressed by the aforementioned metatype level Since procedural associations should be defined on roles, not classes, they should really be associated with an interface, namely the interface across which the method is called. However, as we said earlier, in order not to complicate matters, we do not insist on this distinction here.

44

Friedrich Steimann and Thomas K¨uhne

tional associations between roles (or interfaces) is lifted, basically because to us it seems to lack a plausible justification. If association ends carry rolenames, they are interpreted as implicit introductions of role types, implemented by the classes placed at the association ends.9 A generalization arrow between two classes or two interfaces, or an implements arrow between a class and an interface is mapped to a pair of the ≤-relation specifying the type hierarchy. If instances and links are shown in a static structure diagram (a mixed class and object diagram), they correspond to object symbols and structural links, respectively. Other static structure diagram elements are not treated here; they may necessitate extensions to the core language.

«interface» «interface» Whole Whole getName() getName() nextPart() nextPart()

aggregation

«interface» «interface» Part Part getName() getName()

Directory Directory

File File name:String name:String

type hierarchy File ≤ Part Directory ≤ Whole Directory ≤ File attributes name: File → String structural associations aggregation: Whole Part procedural associations getName: Whole String getName: Part String nextPart: Whole Part

Fig. 2. A class diagram and its mapping to declarations in our abstract syntax. The diagram models an aggregation pattern (with roles Whole and Part) and a file system structure as a possible application of it

4.3 Collaboration Diagram The collaboration diagram marries two different aspects of an interaction: the types of the collaborators together with their associations (or links, depending on whether the diagram is on the specification or instance level), and the message flow indicating the interaction between objects. The former aspect explicates the links necessary for the communication between objects and could also be shown in an object or class diagram (with one exception listed below), while the latter aspect is also shown in the sequence diagram (see Section 4.4). The mapping of collaboration diagrams to the abstract syntax is straightforward. For the instance level, objects in roles map to objects (possibly anonymous, acting as placeholders and corresponding to variables with the roles as their types), links map to structural links and messages to procedural links (with the receiver as the first 9

For a more thorough treatment of association ends, roles and association generalization, the reader is referred to [4, 5].

A Radical Reduction of UML’s Core Semantics

45

argument). The sequence specified is a linear one and mapped to a state/event sequence, even though not all state changes (only object and procedural link creation and destruction and no structural changes) are actually specified. Figure 3 gives an example of this. For collaboration diagrams at the specification level, classifier roles map to role symbols, classes, if specified, to class symbols (if both are provided for a single classifier, it is understood that the class is subsumed by the role), associations to structural association declarations, and sent messages to procedural association declarations. The message sequence specified maps to a set of state transitions partially specifying a finite state machine. This finite state machine is the rough equivalent of the regular expression specified by the sequence of control structures (i.e., conditionals, repeats, and calls) expressed in the collaboration diagram10. (a)

(b) o1:C o1:C aa==o3 o3

b

1: setA(o3)

o2:C o2:C

b

2: linkWith(o2)

o3:C o3:C

(c) o1:C o1:C aa==o3 o3

o2:C o2:C b

aa==o3 o3

  σ1 =      σ 2 =       σ 2 =    

a(o 1 ) = o 3 b(o 1 , o 2 ) b(o 1 , o 3 ) a(o 1 ) = o 3 b(o 1 , o 2 ) b(o 1 , o 3 ) a(o 2 ) = o 3 a(o 1 ) = o 3 b(o 1 , o 2 ) b(o 2 , o 3 ) a(o 2 ) = o 3

  ;     ;           

l 1 = [setA(o 2 , o 3 )]

l 2 = [linkWith(o 3 , o 2 )]

b o3:C o3:C

Fig. 3. Collaboration diagram and its mapping. (a) shows a collaboration diagram at the instance level. Objects, attribute values and links show the initial state. (b) shows the same expressed in the abstract syntax, with subsequent states as would be expected (but not shown by the diagram). (c) shows the final state as an object diagram

Now where does the structural aspect of a collaboration diagram go beyond that of a static structure diagram? With the procedural link the receiving object gains temporary knowledge of the objects involved in the link11. This knowledge can be used in several ways:

10 11

and which corresponds to the static program text (algorithm) of the procedure including itself of which, of course, it already has knowledge

46

Friedrich Steimann and Thomas K¨uhne

temporarily to construct a new procedural link involving one or more of the received objects and send it to another object known by (or linked to) the receiver; temporarily as a structural link for sending one of the received objects a new procedural link; and permanently as a new (or as a replacement for an existing) structural link to a received object. Thus, the existence of a structural association between two types is not a necessary prerequisite for the exchange of a procedural link (a method call) between two objects of these types; instead, a procedural association suffices. Thus, the structural aspects of a collaboration diagram go beyond what is shown in a static structure diagram — which can also include roles — in that it shows the temporary links resulting from passed parameters.12 It does not, however, show the actual creation of these links as state changes. 4.4 Sequence Diagram A sequence diagram shows objects exchanging messages to achieve a certain purpose. Its primary use is the specification of the sequence of these messages, plus which objects receive them. Because the sequencing is not dependent on a linear numbering of the calls, sequence diagrams are particularly well-suited to express branching by providing state transitions with identical starting states. As with the collaboration diagram, the only state changes that are shown correspond to the creation and destruction of objects, and those of procedural links. The mapping of a sequence diagram is analogous to that of a collaboration diagram. The actor maps to a role symbol, all objects map to object symbols with their properties specified by the corresponding types. A method call corresponds to the creation of a procedural link and thus to the occurrence of an event. Synchronicity of the call places conditions on the state transitions associated with the caller, namely whether or not it waits for the receiver to have completed the state transitions triggered by the call. Timing constraints expressed with the call sequence are either mapped to timed state/event-sequences (linear time model) or to transition times associated with the state transitions. 4.5 Statechart Diagram Statecharts are extensions of finite state machines and thus, basically, a more expressive means of specifying state transition functions. The mapping of a statechart to a finite state machine must reverse the extension, which is not an easy undertaking. Even though the specification of a statechart has the directest mapping to the state transitions of our core language in principle, the states of a statechart are usually abstractions of states as expressed in our abstract syntax, which are basically characterized by attribute values and links of objects. Thus, the mapping of the states of a statechart to the core is not at all clear. A possible workaround would be to implicitly specify state attributes with one value for each possible state of an object; this, how12

In a method implementation these would be the actual parameters plus temporary (i.e. method local) variables.

A Radical Reduction of UML’s Core Semantics

47

ever, undermines our goal to have all diagram types mapped to a single core model, since it leaves the state transitions specified by interaction diagrams and those specified by statecharts largely uncorrelated. Generally, finite state machines tend to become very complex even for fairly moderate modelling problems, which is the reason why statecharts have been introduced in the first place. Although expressive enough in principle, it may be worth considering to replace the definition of events, states and state transitions in our core language by (a subset of) the definition of statecharts. This, however, cannot be dealt with here. 4.6 Activity Diagram Activity diagrams are said to be based on state charts, a statement which should facilitate mapping. However, both authors have surrendered to the unwieldiness of the activity diagram specification and abandoned all attempts to provide an even near plausible mapping. 4.7 Component and Deployment Diagram Component and deployment diagrams show aspects important for the technical design of a software product. Since their relation to (conceptual) modelling is rather weak, they are not treated here. It is a common observation, however, that structuring mechanisms are often orthogonal to the (elements) of the language they structure; i.e., it is very likely that none of the modelling concepts presented in section 2 will be suitable to serve for any of the purposes pursued by the component and the deployment diagram.

5

Discussion

The UML standard’s current (version 1.4) chapter 2 comes with a wealth of additional modelling concepts (even in the core package) which we have not addressed here. However, it is our conviction that the primary goals of a core modelling language should be conciseness (ideally: minimality of concepts) and the ability to serve as a uniform basis for all modelling aspects. Hence, the extension of the core language to cover more meaning must be possible, but is not of paramount importance here. Understanding a collection of UML diagrams as views onto a common underlying model enables us to unambiguously define the meaning of each diagram type in terms of the underlying core modelling language and thus automatically creates strong consistency constraints between the different diagram types. UML’s current efforts to define consistency constraints using natural language and OCL must appear as sporadic ad-hoc attempts when compared to the possibilities opened up by the above described approach. It is illusory to pretend that our core language could be equally useful for typeless languages such as SELF; too much of its expressiveness builds on the declaration of types and the associations between them. Also, its use for languages without type checking (such as SMALLTALK) will make it appear somewhat overequipped, since much of the information introduced by its models (mostly type information) will not be translated into a program. And yet, it is not a language specifically tailored for

48

Friedrich Steimann and Thomas K¨uhne

statically typed languages such as JAVA and C++; it is defined solely on formal grounds and makes no commitments to language specific features (even though we made it one of our design goals that the relationship to the pragmatics of programming is as straightforward as possible).

6

Conclusion

We have presented a replacement for UML’s current core semantics that integrates static and dynamic modelling aspects into a core modelling language, built on a minimal set of concepts. We have specified the abstract syntax of the new core using a semiformal language based on set theory, and provided a set of mapping rules from UML’s current concrete syntax to the abstract. We fully realize that our work can only be a first round towards a new, simplified and consistent language definition, but are optimistic that our approach will prove sustainable.

References [1] [2] [3] [4] [5] [6] [7]

K. H. Bläsius, U. Hedtstü ck, C. R. Rollinger (eds) Sorts and Types in Artificial Intelligence Lecture Notes in Artificial Intelligence 418 (Springer 1989). OMG Unified Modeling Language Specification Version 1.1 (www.omg.org, September 2001). F. Steimann “On the representation of roles in object-oriented and conceptual modelling” Data & Knowledge Engineering 35:1 (2000) 83–106. F. Steimann “A radical revision of UML’s role concept” in: UML 2000 Proceedings of the 3rd International Conference (Springer 2000) 194–209. F. Steimann Formale Modellierung mit Rollen Habilitationsschrift (Universität Hannover, 2000). F. Steimann “Role = Interface: a merger of concepts” Journal of Object-Oriented Programming 14:4 (2001) 23–32. P. Stevens “On Associations in the Unified Modelling Language” in: UML 2001 Proceedings of the 4th International Conference (Springer LNCS 2185, 2001) 361–375.

Configuration Knowledge Representation Using UML/OCL Alexander Felfernig, Gerhard Friedrich, Dietmar Jannach, and Markus Zanker Institut f¨ ur Wirtschaftsinformatik und Anwendungssysteme, Produktionsinformatik Universit¨ atsstrasse 65-67, A-9020 Klagenfurt, Austria {felfernig,friedrich,jannach,zanker}@ifit.uni-klu.ac.at

Abstract. Today’s economy is exhibiting a growing trend towards highly specialized solution providers cooperatively offering configurable products and services to their customers. In this context, knowledge based configurators which support the configuration of complex products and services, must be enhanced with capabilities of knowledge sharing and distributed configuration problem solving. In this paper we demonstrate how UML/OCL can be used as knowledge representation language supporting standardized knowledge interchange thus enabling cooperative problem solving by different configuration environments. We show the representation of configuration domain specific types of constraints in OCL and present an OCL based knowledge acquisition workbench which enables configuration knowledge base development, maintenance and interchange.

1

Introduction

Knowledge based configuration has a long history as a successful application area of Artificial Intelligence [2, 9, 13, 14, 17]. Informally, configuration can be seen as a special kind of design activity [22], where the configured product is built of a predefined set of component types and attributes, which can be composed conform to a set of corresponding constraints. Starting with rulebased systems such as R1/XCON [2], higher level representation formalisms were developed to exploit the advantages of more concise representation, faster application development, higher maintainability, and more flexible reasoning. Although these representations have proven their applicability in various realworld applications, there exist a number of obstacles for a far reaching acceptance of this technology. Integration with industrial software development processes. The integration of development and maintenance of knowledge based systems with industrial software development processes is an important prerequisite for a broader application of AI technologies (such as knowledge based configuration). The so-called knowledge acquisition bottleneck is obvious since configuration knowledge base development and maintenance is only feasible with the support of a knowledge engineer who can handle the formal representation language of the underlying configuration system. In the following we show how to tackle this challenge by J.-M. J´ ez´ equel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 49–62, 2002. c Springer-Verlag Berlin Heidelberg 2002


50

Alexander Felfernig et al.

employing UML/OCL1 [21, 26] as configuration knowledge representation language - the language is widely adopted in industrial software development and provides the necessary expressiveness for building configuration knowledge bases. Knowledge sharing. Available state-of-the-art e-marketplace environments support the integration of configuration knowledge bases by forcing suppliers to provide their product/service descriptions conforming to a given proprietary representation format. A consequence of this is that suppliers offering their products in different e-marketplace environments are forced to provide a separate description of their products and services for each of those environments. In this context UML/OCL can be used as basic mechanism for standardized configuration knowledge representation - products/services provided by different suppliers can be represented as refinements of well-defined domain models based on UML/OCL. Distributed problem solving. The integration into e-marketplaces must be seen as a first step towards a stronger coupling of knowledge based configuration systems. Today’s economy is exhibiting a growing trend towards highly specialized solution providers cooperatively offering configurable products and services to their customers. This paradigm shift requires the provision of distributed configuration problem solving capabilities which are not available in state-of-the-art configuration environments. All the more a standard configuration knowledge representation formalism is needed providing the basis for a clear and common understanding of a given configuration task. Using UML/OCL, configurator components participating in a distributed configuration process are enabled to interchange instance data corresponding to well defined domain models. In this context configurator specific refinements of domain models can be interpreted as service descriptions, i.e. the capabilities of a configurator to configure different kinds of products or services. The Model Driven Architecture (MDA) [19] is the result of ongoing standardization efforts of the Object Management Group (OMG)2 . The goal is to provide an integrated architecture supporting system interoperability on the application level based on the sharing of metadata. The overall strategy for sharing and understanding metadata consists of the automated development, publishing, management, and interpretation of models [19]. The long term vision for MDA includes applications capable of automatic discovering capabilities/properties of other applications. This is a step from metadata based application integration towards a knowledge-based application integration. In the following we show how UML/OCL can be used as basic description mechanisms for configuration knowledge representation thus providing the necessary preconditions for intelligent configurator integration. Figure 1 sketches the integration of different configuration systems, e-marketplaces, and product catalogs using an MDA based channel for intelligent application integration. The task of the integrated solution provider is the integration of different configurators, e-marketplaces, and 1

2

We use a subset of UML/OCL, namely UML class diagrams and OCL expressions of type boolean. For further details see www.omg.org.

Configuration Knowledge Representation Using UML/OCL

51

Fig. 1. UML/OCL based configurator integration

product catalogs in order to coordinate the calculation of a solution for a given configuration problem. Note that the integrated solution provider can also dispose of a configuration system (in most cases in the role of the coordinating main configuration system). The paper is organized as follows. In Section 2 we show the OCL representation of fundamental configuration domain specific constraint patterns. For the presented constraint patterns we show their implementation in our knowledge acquisition workbench (Section 3). In Section 4 we discuss related work and open issues with respect to the application of UML/OCL in the configuration domain.

2

Representing Configuration Knowledge in UML/OCL

Knowledge sharing and distributed configuration problem solving requires that the configurators share a clear common understanding of the problem definition and its solution. Consequently, it is necessary to agree on the definition of a configuration task and its solution3 . D efi nition (configuration task ): In general we assume a configuration task is described by a triple (DD, SRS, CLAN G). DD represents the domain description of the configurable product (i.e. the product structure and additional constraints on the allowed combinations of instances and attribute settings) and SRS specifies the particular system requirements (e.g. customer requirements) defining an individual configuration task instance. CLAN G comprises a set of concepts for the description of configuration solutions. ✷ The Meta-Modelling Language (MML) [4] is a static object-oriented modeling language which serves as a basis for the definition of modeling notations such as 3

For a detailed discussion on the definition of configuration tasks see [6, 17].

52

Alexander Felfernig et al.

UML. MML contains a basic expression language based on OCL. The domain description (DD) of a configurable computer can be defined in MML as follows4 . package computer class Software capacity: Integer end; class DTPSoftware extends computer.Software inv ”capacityDTPSoftware” capacity = 15 end; class Textedit extends computer.Software inv ”capacityTextedit” capacity = 10 end; class HDUnit capacity: Integer end; class IDEUnit extends computer.HDUnit inv ”capacityIDEUnit” capacity=25 end; class SCSIUnit extends computer.HDUnit inv ”capacitySCSIUnit” capacity=35 end; class MB end; class MB1 extends computer.MB end; class MB2 extends computer.MB end; //... further definitions class Screen end; class Computer Software = Set {computer.Software}; HDUnit = Set {computer.HDUnit }; MB = Set {computer.MB }; Screen = Set {computer.Screen} // inv // constraints for DD ... end end 4

The corresponding UML class diagram is shown in Figure 2.

Configuration Knowledge Representation Using UML/OCL

53

Based on a given domain description (DD), additional customer requirements (SRS) complete the definition of a concrete configuration task. Customer requirements represent additional constraints on the generic product structure defined in DD, i.e. restrict the set of possible configuration solutions. An example for SRS could be ”a motherboard of type M B1 and a harddisk unit of type IDEU nit”. Using MML, these requirements can be defined as follows. HDUnit = Set {computer.IDEUnit }; MB = Set {computer.MB1 }; Based on the above definition of a configuration task, a configuration result can be defined as follows. Definition (Consistent configuration): Given a configuration task (DD, SRS, CLAN G), a configuration (result ) CON F is consistent, iff DD ∪ SRS ∪ CON F is satisfiable. ✷ Using MML, a concrete configuration CON F can be represented as follows. Note that the objects sof tware1, hdunit1, mb1, screen1, and computer1 have been created as instances of the corresponding classes T extedit, IDEU nit, M B1, and Computer (e.g. sof tware1 = @computer.T extedit). Those language elements which allow the description of a concrete configuration constitute CLAN G (i.e. MML elements used for the description of a concrete configuration). package result extends computer software1 = @computer.Textedit capacity=10 end; hdunit1 = @computer.IDEUnit capacity=25 end; mb1 = @computer.MB1 end; screen1 = @computer.Screen end; computer1 = @computer.Computer software = Set {result.software1 }; hdunit = Set {result.hdunit1 }; mb = Set {result.mb1 }; screen = Set {result.screen1 } end // ... end Figure 2 shows the product structure of a configurable computer. This configuration model will serve as a working example throughout the following sections. The basic structure is modeled using classes (e.g. the class Screen), associations

54

Alexander Felfernig et al.

Fig. 2. Example PC configuration model (e.g. a motherboard(M B) is part of a Computer), and generalization hierarchies (e.g. a CP U can be either a CP U 1 or a CP U 2). In the following we discuss the OCL representation of three different classes of constraints which are frequently used in the configuration domain5 . 2.1

Requirements Constraints

In some cases, the existence of an instance of a specific type requires the existence of another specific instance in the configuration result. Such a requires constraint imposes restrictions of the form p(R, Ci )∧...∧p(R, Ck ) → p(R, Cl )∧...∧p(R, Cn ), where the expression p(R, Cx ) denotes a navigation path from class R to class Cx . Requirements constraints can be imposed on the attribute level as well, i.e. p(R, Ci .ai ) = vai ∧...∧p(R, Ck .ak ) = vak → p(R, Cl .al ) = val ∧...∧p(R, Cn .an ) = van or using any combination of attribute level and class level representation. The expression p(R, Cx .ax ) = vax denotes a navigation path from class R to class Cx with a corresponding attribute setting Cx .ax = vax . Using OCL, requirements constraints on the class level can be expressed as follows6 : context R inv: ((self.Ai1 .Ai2 . ... .Ci ->size > 0)and ... and(self.Ak1 .Ak2 .Ck ->size > 0)) 5 6

Note that our OCL parser supports a case insensitive formulation of OCL constraints. Note that Aij denotes the j th class in the navigation path to class Ci , where we assume that no names for the associations between the classes are provided, i.e. we use class names to construct a navigation expression.

Configuration Knowledge Representation Using UML/OCL

55

implies ((self.Al1 .Al2 .Cl ->size > 0)and ... and(self.An1 .An2 .Cn ->size > 0)) Requirements constraints on the attribute level can be expressed as follows: context R inv: ((self.Ai1 .Ai2 .Ci .ai = vai )and ... and(self.Ak1 .Ak2 .Ck .ak = vak )) implies ((self.Al1 .Al2 .Cl .al = val )and ... and(self.An1 .An2 .Cn .an = van )) In cases, where a subclass S of C within a generalization hierarchy is accessed via a navigation path, additionally the expression C->select(S) must be added to the navigation path - this additional selection is used in the following examples. Example (IDEUnit requires MB1): context Computer inv: (self.HDU nit->select(oclIsTypeOf(IDEU nit))->size>0) implies (self.M B->select(oclIsTypeOf(M B1))->size>0) When translating this constraint into the representation of a concrete configuration system, the output could be the following7 : oModel.add(oModel.forAll(Computer, oModel.imply( oModel.gt(oModel.cardinality(oModel.setOf( PC.getObjectSetField(”HDUnit”),IDEUnit)),0), oModel.gt(oModel.cardinality(oModel.setOf( PC.getObjectSetField(”MB”),MB1)),0)))); The method imply represents the OCL implies, the method getObjectSetField realizes OCL navigation expressions, the method cardinality corresponds to the OCL size, the method setOf corresponds to the OCL isOclTypeOf, and the method gt corresponds to the OCL operator ”>”. Note that the above translations refer to situations where 0..n associations are concerned (constraints on class level) and 0..1 associations are concerned (constraints on attribute level). As already mentioned, hybrid variants of these basic constellations are possible - for reasons of readability we omit those variants. 2.2

Compatibility Constraints

Certain types of instances must not be part of the same final configuration, they are incompatible. Such an incompatibility constraint imposes restrictions of the 7

This is the JAVA based representation of the ILOG JConfigurator [12].

56

Alexander Felfernig et al.

form (p(R, Ci ) ∧ ... ∧ p(R, Ck )) → f alse. Incompatibility constraints can be imposed on the attribute level as well, i.e. (p(R, Ci .ai ) = vai ∧ ... ∧ p(R, Ck .ak ) = vak ) → f alse, or using any combination of attribute level and class level representation. Using OCL, compatibility constraints on the class level can be expressed as follows: context R inv: (((self.Ai1 .Ai2 .Ci )->size > 0)and ... and((self.Ak1 .Ak2 .Ck )->size > 0))) implies false Compatibility constraints on the attribute level can be expressed as follows: context R inv: ((self.Ai1 .Ai2 .Ci .ai = vai )and ... and(self.Ak1 .Ak2 .Ck .ak = vak )) implies false Example (SCSIUnit incompatible with MB1): context Computer inv: ((self.HDU nit->select(oclIsTypeOf(SCSIU nit))->size>0) and (self.M B->select(oclIsTypeOf(M B1))->size>0)) implies false 2.3

Resource Constraints

Parts of a configuration task can be seen as a resource balancing task, where some of the classes produce some resources and others are consumers (e.g. the hard-disk capacity needed by the installed software must not exceed the provided hard-disk capacity). Using OCL, resource constraints can be expressed as follows assuming that {Ci , ..., Ck } denotes a set of consumers and {Cl , ..., Cn } denotes a set of producers and {ai , ..., ak }, {al , ..., an } denote the resource attributes of those classes. The following constraint represents the case where all the accessed classes are reachable via at least one navigation over an 1..n association8 . context R inv: ((self.Ai1 .Ai2 ...Ci .ai )->sum + (self.Ak1 .Ak2 ...Ck .ak )->sum) ¡= ((self.Al1 .Al2 ...Cl .al )->sum + (self.Al1 .Al2 ...Cl .al )->sum)

Example (Consumed Software capacity ≤ HDUnit capacity): context Computer inv: (self.Sof tware.capacity)->sum ¡= (self.HDU nit.capacity)->sum 8

Note that the sum operator is an additionally introduced aggregation function.

Configuration Knowledge Representation Using UML/OCL

2.4

57

Additional Constraints

The constraints discussed in the previous subsections represent frequently modeled restrictions on configuration models. For these types of constraints we provide a set of constraint schemes with the corresponding input masks (see Section 3). When defining more complex constraints on a configurable product, we also allow a text-based formulation of OCL constraints (see also Section 3).

3

Knowledge Acquisition Workbench

CAWICOMS9 is an EU-funded project which aims at the provision of new technologies allowing the application and integration of available configuration systems in Web-based environments. One of the central parts of the CAWICOMS environment is the knowledge acquisition workbench supporting standardized configuration knowledge acquisition, interchange, and maintenance in distributed environments. The main component of the knowledge acquisition workbench is an Rational Rose add-in especially tailored for modeling the structure of configurable products and services. A constraint editor supports the design of constraints on the product/service structure. Within the knowledge acquisition workbench OCL is used as standard constraint representation language. For frequently used configuration domain specific constraints we provide a set of constraint schemes with a corresponding graphical interface. Figure 3 shows the representation of compatibility constraints between different classes of the configuration model, where the product structure is represented in the left-hand-side window. The user can select classes and corresponding attributes to formulate constraints conform to the structure discussed in Section 2 these constraints are automatically translated into an OCL based representation which is further translated into representation of the underlying configuration system, i.e. a configuration task (see Section 2) is defined by automatically generating a configuration knowledge base from a given UML/OCL specification - satisfiability of the configuration task can now be checked by the underlying configuration system [12]. Figure 4 shows the representation of resource constraints between different producer and consumer classes of the configuration model. In this case the product model is represented in the left-hand-side as well as in the right-hand-side window in order to provide different input areas for producers and consumers. The structure of the input mask for requires constraints is very similar to that for resource constraints - therefore we omit the presentation of the input mask for requires constraints here. Finally, constraints can be directly entered as OCL constraints - for this purpose a simple text editor is provided (see Figure 5). Knowledge interchange between different configuration environments is supported by the exchange of XML representations of product structures and constraints (see Section 2). On the basis of an OCL parser, configuration knowledge 9

CAWICOMS is the acronym for Customer-Adaptive Web Interface for the Configuration of products and services with Multiple Suppliers (EU-funded project IST1999-10688).

58

Alexander Felfernig et al.

Fig. 3. Interface for compatibility constraints bases (e.g. for the ILOG JConfigurator [12]) can be automatically generated using configurator specific translation routines. Based on those knowledge bases, a distributed problem solving process is triggered which is based on state-of-theart distributed constraint satisfaction algorithms [23, 27]. The communication protocol between the systems participating in the problem solving process is realized via SOAP [25], i.e. configuration services are represented as Web services [7]. The CAWICOMS runtime environment provides mechanisms for integrating supplier product catalogs stemming from ERP systems or e-marketplace environments. The integration of product catalogs is supported by the possibility of modeling abstract references (catalog entries) to those catalogs using the Rational Rose add-in - the entries are uploaded by the configurator at runtime.

4

Related Work

Up to now we have presented the basic concepts behind the CAWICOMS knowledge acquisition workbench. The underlying knowledge representation language OCL includes the concepts needed for the construction of configuration knowledge bases, i.e. it is an excellent basis for a common configuration knowledge representation language. The availability of such a standardized language is a crucial success factor for integrating configuration technologies into industrial software development processes and for configuration knowledge base integration. Current implementations based on OCL focus on different facets of model checking (e.g. [5, 20]). In [20] an approach is presented for validating UML models and corresponding OCL constraints, which is based on animation. The user of the system can provide a set of snapshots representing possible states of the considered system. These snapshots can be furthermore validated against the built

Configuration Knowledge Representation Using UML/OCL

59

Fig. 4. Interface for resource constraints UML model and the corresponding OCL constraints. If a snapshot (positive example) does not fulfill the model constraints, there could be constraints in the model which are too restrictive and consequently must be eliminated or relaxed. Constraints on the system may be too weak, i.e. there are inconsistent constellations in the snapshot (negative example), which are not considered by the actually formulated model constraints. The Meta-Modelling Language (MML) [4] is a static object-oriented modeling language which serves as a basis for the definition of modeling notations such as UML. MML contains a basic expression language based on OCL - the underlying implementation (MMT - Meta-Modelling Tool) provides basic model generation facilities (e.g. for generating instances of a given relationship or for instantiating variables in expressions). The work of [4] is the first step towards the provision of model generation mechanisms which are crucial for the effective application of OCL in configuration domain specific problem settings. There is a large spectrum of approaches to model generation already existing in the AI community [9, 14, 16, 17] which are also implemented in state-of-the-art configuration systems. The implementation of model generation mechanisms especially in the context of building a configurator environment on the basis of OCL is the subject of future work. In [1] experiences from the application of OCL in industrial software development processes are discussed. In principle, OCL seems to be quite useful and software engineers and even domain experts with a technical background are able to apply OCL for stating formal constraints on a given object model. Espe-

60

Alexander Felfernig et al.

Fig. 5. Interface for basic OCL constraints cially software engineers accepted OCL because of the similarities of its syntax to object-oriented programming languages. However, [1] point out that additional, more intuitive concepts are needed in order to support effective introduction of OCL constraints. They made the observation that software engineers tried to change an object’s state, what is prohibited by the declarative semantics of OCL. In order to tackle this challenge, [1] introduce the notion of constraint schemes. These schemes represent parameterizable constraints, which can be differently instantiated depending on the actual situation. For example, a constraint schema could restrict the occurrence of objects of a class to an upper bound. In this case the upper bound is represented by a variable which must be instantiated in order to instantiate the corresponding OCL constraint. The input masks for requires, incompatible, and resource constraints provided by the CAWICOMS knowledge acquisition component can be interpreted as a facet of such constraint schemes. OIL [8] and DAML+OIL [24] are ontology representation languages developed within the context of the Semantic Web [3]. These languages should serve as a basis for enabling Web technologies providing access to Web resources not only to humans but as well to applications supporting Web services such as information brokering, information filtering, intelligent search or service synthesis [18]. Triggered by the requirement for more flexibility and expressiveness of those languages there are ongoing efforts to increase the expressiveness of Web ontology languages. DAML-L [15] is a language which builds upon the basic concepts of DAML. XML Rules [11] and CIF (Constraint Interchange Format) [10] are similar approaches with the goal to provide rule languages for the Semantic Web. As a result of our investigations [7], Semantic Web representation languages are suitable for configuration knowledge representation, however an additional language is needed supporting an intuitive formulation of constraints on product/service structures. An interesting question in this context is, how the concepts of OCL

Configuration Knowledge Representation Using UML/OCL

61

can be integrated into languages such as OIL or DAML+OIL in order to exploit the advantages of both paradigms.

5

Conclusions

We have presented the CAWICOMS knowledge acquisition workbench which supports UML/OCL based construction of configuration knowledge bases. Using UML/OCL as standard representation formalism for defining configuration tasks facilitates knowledge sharing and cooperative configuration problem solving. The development of configuration systems is integrated into industrial software development processes which is the major precondition for a broader and more effective application of configuration technologies. Finally, the approach shows how UML/OCL can be applied for knowledge-based application integration which is one the goals of the OMG standardization efforts.

References [1] T. Baar, R. H¨ ahnle, T. Sattler, and T. H. Schmitt. Entwurfsmustergesteuerte Erzeugung von OCL Constraints. In K. Mehrhorn and G. Snelting, editors, Informatik 2000, 30. Jahrestagung der Gesellschaft f¨ ur Informatik, pages 389–404. Springer-Verlag, 2000. 59, 60 [2] V. E. Barker, D. E. O’Connor, J. D. Bachant, and E. Soloway. Expert systems for configuration at Digital: XCON and beyond. Communications of the ACM, 32(3):298–318, 1989. 49 [3] T. Berners-Lee. Weaving the Web. Harper Business, 2000. 60 [4] T. Clark, E. Evans, St. Kent, and P. Sammut. The MMF Approach to Engineering Object-Oriented Design Languages. In Workshop on Language Descriptions, Tools and Applications, 2001. 51, 59 [5] A. Evans. Reasoning with UML class diagrams. In Proceedings of the Workshop on Industrial Strength Formal Methods(WIFT’98), Florida, USA, 1998. IEEE Press. 58 [6] A. Felfernig, G. Friedrich, D. Jannach, and M. Stumptner. Consistency-Based Diagnosis of Configuration Knowledge Bases. In Proceedings of the 14th European Conference on Artificial Intelligence (ECAI 2000), pages 146–150, Berlin, Germany, 2000. 51 [7] A. Felfernig, G. Friedrich, D. Jannach, and M. Zanker. Semantic Configuration Web Services in the CAWICOMS project. Proceedings of 1st International Semantic Web Conference, pages 192–205, 2002. 58, 60 [8] D. Fensel, F. vanHarmelen, I. Horrocks, D. McGuinness, and P. F. Patel-Schneider. OIL: An Ontology Infrastructure for the Semantic Web. IEEE Intelligent Systems, 16(2):38–45, 2001. 60 [9] G. Fleischanderl, G. Friedrich, A. Haselb¨ ock, H. Schreiner, and M. Stumptner. Configuring Large Systems Using Generative Constraint Satisfaction. IEEE Intelligent Systems, 13(4):59–68, 1998. 49, 59 [10] P. Gray, K. Hui, and A. Preece. An Expressive Constraint Language for Semantic Web Applications. In Proceedings of the IJCAI 2001 Workshop on E-Business and the Intelligent Web, pages 46–53, Seattle, WA, 2001. 60

62

Alexander Felfernig et al.

[11] B. N. Grosof. Standardizing XML Rules. In Proceedings of the IJCAI 2001 Workshop on E-Business and the Intelligent Web, pages 2–3, Seattle, WA, 2001. 60 [12] U. Junker. Preference programming for configuration. In Proceedings of Workshop on Configuration (IJCAI’01), Seattle, WA, USA, 2001. 55, 57, 58 [13] E. W. J¨ ungst M. Heinrich. A resource-based paradigm for the configuring of technical systems from modular components. In Proceedings of the 7th IEEE Conference on AI applciations (CAIA), pages 257–264, Miami, FL, USA, 1991. 49 [14] D. Mailharro. A classification and constraint-based framework for configuration. Artificial Intelligence for Engineering, Design, Analysis and Manufacturing Journal, Special Issue: Configuration Design, 12(4):383–397, 1998. 49, 59 [15] Sh. McIlraith, T. C. Son, and H. Zeng. Mobilizing the Semantic Web with DAMLEnabled Web Services. In Proceedings of the IJCAI 2001 Workshop on E-Business and the Intelligent Web, pages 29–39, Seattle, WA, 2001. 60 [16] S. Mittal and B. Falkenhainer. Dynamic Constraint Satisfaction Problems. In Proceedings of the National Conference on Artificial Intelligence (AAAI 90), pages 25–32, Boston, MA, 1990. 59 [17] S. Mittal and F. Frayman. Towards a Generic Model of Configuration Tasks. In Proceedings 11th International Joint Conf. on Artificial Intelligence, pages 1395– 1401, Detroit, MI, 1989. 49, 51, 59 [18] E. Motta, D. Fensel, M. Gaspari, and V. R. Benjamins. Specifications of Knowledge Components for Reuse. In Proceedings of 11th International Conference on Software Engineering and Knowledge Engineering, pages 36–43, Kaiserslautern, Germany, 1999. 60 [19] J. D. Poole. Model-Driven Architecture: Vision, Standards And Emerging Technologies. In Workshop on Metamodeling and Adaptive Object Models, ECOOP 2001, 2001. 50 [20] M. Richters and M. Gogolla. Validating UML Models and OCL Constraints. In Proceedings of the 3rd International Conference on the Unified Modeling Language (UML’2000), volume 1939, pages 265–277, York, UK, 2000. Springer Lecture Notes in Computer Science. 58 [21] J. Rumbaugh, I. Jacobson, and G. Booch. The Unified Modeling Language Reference Manual. Addison-Wesley, 1998. 50 [22] D. Sabin and R. Weigel. Product Configuration Frameworks - A Survey. In B. Faltings and E. Freuder, editors, IEEE Intelligent Systems, Special Issue on Configuration, volume 13,4, pages 50–58. IEEE, 1998. 49 [23] M. C. Silaghi, D. Sam-Haroud, and B. Faltings. Asynchronous search with aggregations. In Proceedings of 17t h National Conference on Artificial Intelligence (AAAI), pages 917–922, Austin, TX, USA, 2000. 58 [24] F. vanHarmelen, P. F. Patel-Schneider, and I. Horrocks. A Model-Theoretic Semantics for DAML+OIL. www.daml.org, March 2001. 60 [25] W3C. Simple Object Access Protocol (SOAP), ver. 1.2. www.w3c.org, 2001. 58 [26] J. Warmer and A. Kleppe. The Object Constraint Language - Precise Modeling with UML. Addison Wesley Object Technology Series, 1999. 50 [27] M. Yokoo, E. H. Durfee, T. Ishida, and K. Kuwabara. The distributed constraint satisfaction problem. IEEE Transactions on Knowledge and Data Engineering, 10(5):673–685, 1998. 58

Using UML for Information Modeling in Industrial Systems with Multiple Hierarchies Peter Fröhlich, Zaijun Hu, and Manfred Schoelzke ABB Forschungszentrum Wallstadter Straße 59 68526 Ladenburg, Germany phone: +49 6203 71 6239 {peter.froehlich,zaijun.hu,manfred.schoelzke}@de.abb.com

Abstract. Traditionally, information models for industrial plants have been formulated based on domain-specific languages and tools satisfying the requirements of given standards like IEC 750, IEC 61346 or the Power Station Designation System (KKS). There is however a trend in the automation industry to use common IT standards like XML and UML. The current paper shows our experiences in applying UML for information modeling of industrial plant applications, which typically consist of multiple structural hierarchies. We introduce a meta-model, which describes, how the information models can be expressed in UML. Further, we discuss a simple case study, which applies this model in the context of ABB` s Industrial IT platform. Finally, we describe our experiences with UML-based modeling in this domain and discuss the differences between a UML-based representation and the concepts of IEC 61346. Keywords. Industrial experience, Metamodelling, Business modelling.

1 Introduction Meanwhile, UML [3] is the leading notation for software analysis and design. It is widely used not only in pure software companies, but also in the software departments of a large automation company like ABB. UML is however not yet the standard for information modeling of industrial plant applications. There are many standards for such information models, describing the structures and dependencies of the different facilities located in a plant. Given the widespread use of UML, and its good integration into the software tool infrastructure of the company, it is an obvious question, if such information models can be expressed in UML. 1.1 Existing Designation / Information Modeling Standards The power station designation system (german: Kraftwerks-Kennzeichen-System KKS) [1] is a multi-dimensional classification system, which defines codes for uniquely identifying equipment installed in a power plant. Three aspects are defined for each object in the plant: 1. the process it performs, 2. at which coordinate, in which rack / cabinet it is installed, 3. in which room in the plant it is installed. Each dimension is structured as a containment hierarchy, for example a component with a designation of LCC is located in the Main Condensate Preheating (LCC), which is part of the condensate system (LC), which is in turn part of the Steam, Water and Gas Cycles (L). The power station designation system is an early standard, which already exhibits the typical structures used in system engineering, namely multiple, (in principle) orthogonal containment / aggregation hierarchies for function and location. J.-M. J´ez´equel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 63-72, 2002. c Springer-Verlag Berlin Heidelberg 2002

64

Peter Fr¨ohlich et al.

A more recent standard, IEC 61346, applies the same principles not only to power plants but also to other industrial systems. Based on the concepts of Objects and Aspects, IEC 61346 describes principles for modeling the structure of information about systems and of the systems themselves. IEC 61346 models systems from different viewpoints, called aspects: function-oriented viewpoint, location-oriented viewpoint, product-oriented viewpoint. Again, each of the viewpoints is structured hierarchically, e.g. in the location-oriented viewpoint, a building consists of floors, which consist of rooms with cabinets, in which objects are located. Since IEC 61346 is more general than the power station designation system, and an extension of the older standard IEC 750, it establishes a good basis for industrial system modelling in general. ABB’s Industrial IT platform is consistent with this standard as well. We will discuss UML-based modelling of information on systems / plants based on IEC 61346 in section 2. Other standards address information modelling of industrial systems with different goals. STEP (ISO 10303) [9], for example, is a standard for exchange of product data. It comes with its own domain-specific modeling language, EXPRESS, which allows to capture structural information as well as constraints. Case tools for modelling plants with EXPRESS exist, like ST-Developer [8]. STEP is a huge set of standards including domain-specific languages and notations. ABB is committed to use open IT standards like UML and XML [4] to be able to connect the companies Industrial IT platform not only to plant-specific systems but also to general IT systems like Enterprise Resource Planning (ERP) or office applications. Therefore, the current paper adopts the basic ideas of modelling information about industrial systems from IEC 61346 and shows how to express this information in UML.

2 A Semantic Model of IEC 61346 In this section, we look closer at the concepts of IEC 61346 and develop a UML model of the concepts in this standard and their relationships. This model is used to explain the standard as it is. Since the standard does not consider application development, but only discusses structures of plant / systems, we refine this model in section 3 to make it suitable for practical application development. The goal of IEC 61346 is to establish principles for describing the structure of information about systems and of the systems themselves. We have mapped the concepts of this standard into the UML diagram shown in figure 1. Key concepts of IEC 61346 are Object and Aspect. An Object is defined as an “Entity treated in the process of design, engineering, realization, operation, maintenance and demolition.” [2] Each object is an instance of a Type. In the context of systems engineering a type typically refers to an article / a part, which can be ordered, e.g. an electrical board from a certain vendor with a unique product code. An Object is then typically an individual part identified by a serial number. A (physical) System is composed of subsystems containing Objects.

2.1 Aspects and Structures Depending on the application it is necessary to consider the object structure of the system from different viewpoints. Product, Function, and Location are viewpoints commonly used in many engineering disciplines. The function viewpoint looks at what an object is doing, whereas the location viewpoint considers, where the object is located,

Using UML for Information Modeling in Industrial Systems

Individual

Type Product Viewpoint

Function Viewpoint

65

serNo

Entity

1

ObjectAsIndividual instanceOf

hasAspect

Aspect

+instance

+used uses 1..n

1 Object

System

1 +user

Location Viewpoint

0..n Reference Designation

objectOccurrence

correspondsTo 0..n 0..1 1 Occurrence

Functionoriented Structure

+referenced 1 Structure

+father 0..n

Productoriented Structure

Node

0..n

+child Locationoriented Structure

NonrootNode

RootNode

Fig. 1. UML-based semantic model describing the concepts of IEC 61346

and the product viewpoint describes, how the system is constructed hierarchically from the objects and subsystems. These viewpoints are called Aspects in IEC 61346. Each of the aspects Function, Location and Product defines an aggregation hierarchy. For example, in the functional aspect the cooling water supply of a plant consists of a water store, different pumps and a control unit. The pump itself contains a control unit, an indication, a motor, and a power supply. From a location point of view the water store and the pump may be located in one room, whereas the control system is located in a different room. For each of these aspects a Structure organizes the aggregation relations among Objects in trees. The Functional and Location Structure of the example just described are given in figure 2. Note, how the structure trees and corresponding hierarchies differ both in the objects, which appear (e.g. room RoomA1 does not contribute to the functionality, so it does not appear in the functional structure) and in the relationships of the objects (Pump1 and Control have the same parent node in the functional structure, but different parent nodes in the location structure). Further, the structures can be broken down to a different level of detail (the location structure does not show the components of the pumps).

66

Peter Fr¨ohlich et al.

Site1

Cooling Water Supply

RoomA1

Control

Control

Water Store

RoomA2

Pump1

Control1

Pump1

Indication1

Pump2

Motor1

Water Store

Power1

...

Pump2

Control2 Indication2

Motor2

Power2

...

Functional Structure

Location Structure

Fig. 2. Example for Functional and Location Structure

2.2 Object Identity Applications often use the structures to access objects based on their purpose in the system. To explain how an application identifies an object, we have to describe the two interpretations of object identity in the engineering world. These interpretations are part of the motivation for the IEC standard used here. The first interpretation of object identity in systems engineering is similar to the one of object-orientation in computer science. In this interpretation, an object is an instance of a type, identified e.g. by a particular serial number. This interpretation is used for example by a maintenance application, which is interested in the lifetime of a certain pump, installed somewhere in the system and purchased at a certain date. In this interpretation we are interested in the Individual, i.e. in the actual piece of equipment, with its age and history of usage and maintenance. In systems engineering, a second view is even more important. Here an object is identified based on its usage or Occurrence in the system. An application is then not interested in the actual instance of the pump installed in the water supply, which might be exchanged by a new one today or at another point in time during the system lifecycle. Instead, the application refers to the pump based on its purpose in the plant. This interpretation is for example assumed by a control system, which monitors and adjusts the flow through the cooling water supply. To identify an occurrence, the structures are used. The occurrence is uniquely identified by the path to the object in one of the struc-

Using UML for Information Modeling in Industrial Systems

67

tures. In the example from figure 2, the object Control1 is uniquely identified by the path Cooling Water Supply.Pump1.Control1 in the functional structure. The path can also mix different structures, i.e. Control1 can also be identified using the path Site1.RoomA2.Pump1 in the location structure, then switching to the functional structure and accessing Control1 via Pump1. Such a unique path (denoted in a special notation) is called Reference Designation.

3 A Meta-Model for System and Application Modeling Based on IEC 61346 In figure 3 we show a UML meta-model of IEC 61346 in an application development environment. Since the IEC just defines the information modeling concepts but not the usage of these models by computer programs, this model reflects our interpretation of and our additions to the standard. The first change in our meta-model compared to the standard is that we distinguish types and instances more thoroughly in our meta-model: An ObjectType has AspectTypes associated with it. The actual instances of the object type, the Objects are related to Aspects, which are themselves instances of AspectTypes.

Application

correspondsTo Property OPC Tag 0..n value

Basic Data AspectType

1

Application AspectType

has-Aspect

AspectType 0..n

bjectType 0..n 1 +concept

+concept 0..n +instance Aspect

has-Aspect

0..n +instance Object

Product Structure Function Structure

Location Structure Control Structure

Occurrence 1

0..1 1

+instance StructuralA spect 0..n 1..n +concept 1 Structural Aspect Type +parent 0..1

0..n

Reference Designation 0..n

0..n +child

Fig. 3. Meta-Model for UML-based descriptions of plant information models.

68

Peter Fr¨ohlich et al.

Room

Cooli ngWaterSuppl y

1

1

1..n

LS_Room

1..n

FS_Cooli ngWa terSupply +Parent0..1

+Parent 1

Motor 1

1..n +Chil d 1..n +Parent +Child FS_Pump FS_Motor 1 1

+Child 1..n

LS_Pump

1..n

1..n

PumpSimulation 1

Pump

Pum pBas icData vendor : String type : String serial : String

1

FlowIn : Double FlowOut : Double TempIn : Double Temp : Double PIn : Double Psuct : Double P : Double

Sim ulato r

PumpMaintenance ins talled : Date upTim e : Date downTime : Date num Failure : integer

Maintenance

Fig. 4. Simplified model of a pump, using the concepts from the meta-model

The aspects and corresponding structures defined in IEC 61346 are used for navigation both by human users and by computer applications. These computer applications constitute further viewpoints of the objects (each application associates different attributes with the object) and are treated as specializations of AspectType. The concept of individual has been replaced by another specialization of AspectType, the Basic Data AspectType. This is in line with the object identity consideration in section 2.2: Since some applications want to know, when the actual object in the system was exchanged, we represent its identity using an instance of the basic data aspect type. In summary, our application-oriented interpretation of the IEC distinguishes three specializations of aspects, as shown in figure 3: • Structural AspectType: This type of aspect covers the function, location and product hierarchies discussed in section 2. Each structural aspect represents a possible node in a structure. The child-parent association between structural aspects allows to define, at which place in the structure an object may be placed. This will be

Using UML for Information Modeling in Industrial Systems

69

shown in the example in section 3.1. The Product, Function, and Location structures are predefined in IEC 61346. However, IEC 61346 suggests, that there may be additional structures. As an example, we have added the Control Structure, which describes the constituency hierarchy of the system from the view of a control system. This extension is typical in ABB applications, since control systems are a major product category of ABB. • Application AspectType: Each object is used by different applications. In the automation industry, applications include control systems, configurators, simulators, asset management applications, CAD systems, etc. Each application has a different view of the object. A CAD system is interested in the shape of a pump, while the control system is interested in the flow through the pump. A maintenance system finally takes a completely different view and is interested in the age and number of failures instead. To reflect these different requirements and views of the applications, each application aspect has a set of properties (attributes). I.e. the set of properties of the object is partitioned into different parts used by the different applications. • Basic Data AspectType: This aspect type contains the basic data (serial number, production date, etc.) of a part. If the part is exchanged this basic data changes. Based on this data a maintenance application can identify the specific part used for a certain function and decide, when it has to be replaced. 3.1 An Example Let us now look at a small example using these concepts. It shows a model for a pump with several aspects. In the model the classes use stereotypes to indicate the concept / meta class they are instantiating. The diagram in figure 4 is part of the description of an ObjectType called Pump. The actual pump currently installed in the plant is characterized by its PumpBasicData, including the serial number of the pump, and its vendor. The Pump is used by two applications. One of them is the Simulator application, which predicts the behaviour of the cooling system under different conditions. This application associates flows, water temperatures and pressures with the pump. These properties are represented as attributes of the PumpSimulation aspect. The second application aspect, PumpMaintenance, serves a Maintenance application. For the maintenance application, the interesting properties of the pump are its past performance (number of failures, uptime vs. downtime) and its age, computed from the date of installation. The remaining aspects are concerned with the position of the pump in the different hierarchies. The class LS_Pump defines the location structure aspect of the pump. There is only one such aspect per pump and it has to be the child of the location structure aspect LS_Room of a Room, which is part of a floor in a building. The functional structure aspect FS_Pump defines that pumps may be (cardinality 0..1) children of cooling water supplies (FS_CoolingWaterSupply) in the functional structure. Further, each pump contains exactly one motor (FS_Motor) in the functional structure. Witness, how the structure aspects define, where (at which parent / child objects) an object can be placed in a structure, and how often it may occur. Thus, the structure aspects define constraints on the structure of the different hierarchies. Obviously, the pumps Pump1 and Pump2 in figure 2 are consistent with the constraints defined in the example: both pumps are located in a room in the location structure and both are children of cooling water supplies and contain motors in the functional structure.

70

Peter Fr¨ohlich et al.

3.2 Implementation Using ABB’s Industrial IT Platform A good example for the realization of a system integrating different applications based on the ideas presented in the previous sections is ABB’s Aspect Integrator Platform (AIP) [5]. The AIP is a framework technology that is part of ABB’s Industrial IT offerings to its customers in the automation and process control business. The AIP supports the complete concept of object and aspect types and multiple hierarchies as described in figure 3. Because of the wide-spread use of the (COM-based) OPC standard [6] in the process control area, AIP is implemented using Microsoft’s component technology COM. On the other hand, different applications for engineering are integrated, e.g. an IEC 1131based control builder and an Excel-based bulk data manager. The integration of the latter one shows that concepts discussed in the current paper are general enough to support integration of a wide range of applications, e.g. Office applications, process engineering, simulators, control and optimization (technical applications), asset management and asset optimization and other business applications.

4 Evaluation 4.1 Differences between Object-Orientation and IEC 61346 In object-orientation, aggregation and composition are used to define, how an object is composed from its parts. There is one containment hierarchy in most models. IEC 61346 acknowledges the fact, that composition is dependent on the view point: For a maintenance worker, a plant site consists of buildings with multiple floors, each of which is divided into rooms, in which the equipment is placed in shelves and cabinets. For a manager, the same site consists of different functional units and subunits. These multiple hierarchies are expressed through the structure aspects in our UML models. In object-oriented modelling, a class defines the attributes of an object as one set. In IEC 61346, many different applications have to be supported by one common information model. To support such a view of the world, the attributes are divided into several partitions, each of which supports one particular application. For a control system for example, the liquid level in a tank is an important attribute, while the age of the tank is not interesting. For a maintenance management tool, which computes the optimal points in time for maintenance, it is the other way round. This partitioning scheme for the attributes is similar to the Slice concept of the language RMM [10]. It should be noted, that the aspects in IEC stem from a different background than the idea of aspect in aspect-oriented programming (AOP). AOP [7] is essentially a programming technique that aggregates crosscutting concerns (ranging from high-level notions like security to low-level features such as buffering) into aspects. Because AOP aspects are a mechanism beyond subroutines and inheritance for localizing the expression of a crosscutting concern, AOP systems must provide a mechanism for weaving aspects and base code into a coherent system. This is not a requirement for the aspects in IEC as we have discussed them in this paper. 4.2 Experiences We have modelled two larger applications in the field of control system engineering successfully with the above models. Each of these applications was easily mapped to our Industrial IT platform. The teams creating these models consisted of engineers as

Using UML for Information Modeling in Industrial Systems

71

well as computer scientists. We found that the usage of our UML models helped both groups. They explained to the computer scientists the idea of multiple hierarchies and helped the engineers to phrase their ideas within the concepts, the Industrial IT platform supports. Earlier attempts to map UML models representing one hierarchy (e.g. only the functional hierarchy) into the platform and merge them with structures for the other hierarchies later were not successful. We therefore believe, that the complexity of the multiple hierarchies can only be addressed in a model, which describes all hierarchies in parallel. In our experience, such a model can only be created at the beginning of the system development or application integration project. This means, at the beginning of the application integration process a set of object types with their relations in the different structures are created in the form of a library of object types. The attributes within one application aspect can then still be adapted to changes during the project, and new applications can be added with little effort. In contrast to our previous work [11], where we used a formal meta-model with a custom semantics for modeling industrial applications, the current work is based on UML stereotypes. Stereotypes are used in the domain models to indicate, which class from the meta model is instantiated. This more informal use of a meta model has been better accepted by the users than our previous logics-based approach. Part of our future work is to compare our use of stereotypes with approaches from other domains (e.g. [12]).

References [1]

VGB-Kraftwerksleittechnik GmbH - Verlag technisch wissenschaftlicher Schriften. KKS - Kraftwerks-Kennzeichen-System, 1978.

[2]

International Electrical Commission (IEC). IEC (6)1346-1. Industrial Systems, installations and equipment and industrial products - Structuring principles and reference designations, First Edition, 1996.

[3]

Object Management Group (OMG). OMG Unified Modelling Language Specification. Version 1.4, September 2001.

[4]

World Wide Web Consortium (W3C), T. Bray, J. Paoli, C.M. Sperberg-McQueen, and Eve Maler (Eds). Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation, 6 October 2000.

[5]

L. Krantz. Industrial IT - The Next Way of Thinking. ABB Review 1/2000.

[6]

http://www.opcfoundation.org

[7]

T. Elrad, R. E. Filman, A. Bader. Aspect Oriented Programming. Communications of the ACM, Volume 44, No. 10, October 2001.

[8]

http://www.steptools.com/products/stdev

[9]

M. Pratt. Introduction to ISO 10303 - The STEP Standard for Product Data Exchange. ASME Journal of Computing and Information Science in Engineering, November 2000.

72

Peter Fr¨ohlich et al.

[10]

Tomas Isakowitz, Edward A. Stohr, and P. Balasubrahmanian. RMM: A methodology for structured hypermedia design. Communications of the ACM, 38(8), August 1995

[11]

Peter Fröhlich, Zaijun Hu und Manfred Schoelzke: Imposing modeling rules on industrial applications through meta-modeling. In DASWIS 2001 - International Workshop on Data Semantics in Web Information Systems, Yokohama, Japan, November 2001.

[12]

Francois Pinet und Ahmed Lbath: Semantics of Stereotypes for Type Specification in UML: Theory and Practice. In Proceedings of the 20th International Conference on Conceptual Modeling (ER' 2001), Springer LNCS 1224, Yokohama, Japan, November 2001.

Adapting the UML to Business Modelling’s Needs - Experiences in Situational Method Engineering Andreas Dietzsch Schweizerische Mobiliar Versicherungsgesellschaft Bundesgasse 35, 3001 Bern, Switzerland [email protected]

Abstract. In 1999 the Swiss Mobiliar Insurance Company (Mobiliar) started a program to transform to a process oriented organization. Based on reengineered business processes, the refocusing of the information system infrastructure was strived. To ensure a unified methodical procedure during this transformation a competence center was founded. It supports project specific needs by situational method engineering. At inception PROMET BPR and the Unified Modeling Language (UML) were chosen. During the first projects, the requirements for method support changed from being purely process engineered, to a focus of supporting process improvement. This paper characterizes the phases and the specific needs they raise. It shows the evolution and integration of the method fragments. Thereby, the main focus is to describe how the concepts of UML would be linked in particular to ratios of process management in the meta-model of this reengineered method. Keywords: linking business and technical requirements, application and extensions of the UML, situational method engineering

1

General Conditions

The Swiss Mobiliar Insurance Company (Mobiliar) provides services for private persons, companies and the public service sector. Within a large program, started in 1999, a process focus was implemented step-by-stepto the existing organizational structure. This includes the build up of adequate support by information systems. The goal was to achieve a process that ensures a systematic, long-range related development of the Mobiliar’s business potential. The basis for this effort was a comprehensive look at the requirements of the reorganization of business processes as well as the reformation of the information system landscape. To support this change the division ”Business Processes” was formed. The complexity of the program required the use of the proper toolset. Through a competence center of the business division ”Business Processes” these tools were provided and a unified methodical procedure was ensured throughout transformation. Among others, the competence center’s tasks included providing J.-M. J´ ez´ equel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 73–83, 2002. c Springer-Verlag Berlin Heidelberg 2002


74

Andreas Dietzsch

the foundations for model based documentation of the transformation through the definition and enforcement of methodical standards and guidelines. The principles, on which this transformation was based, built the general framework for the demands on characteristics of the given method. The key driver of these principles was the need to assure daily business through every phase of the change process. This is essential because customers are highly sensitive to risky undertakings of ”their” insurance company. To reduce risk ”evolutionary changes” and ”problem solving based on models” were constituted as the principles of the transformation. Thus, every change was planned and based on the actual business solution, and its consequences were simultaneously had shown. The consideration of the principle of model based problem solving particularly enables the definition of activities and the assessment of its consequences without affecting the ”real world” [4]. To fulfill requirements resulting from these principles the competence center provides a customized method through situational method engineering. The essence of this discipline is to build project-specific methods by assembling method fragments [1], [2]. 1 The following section shows how different phases of the project influence the requirements on such fragments.

2

Phases in Method Adaptation

The phases in method adaptation are directly linked to the main goals, which were strived during the project program. The initial plan was based on a project specific customization of the Rational Unified Process [9]. Its first three workflows Business Modeling, Requirements Specification and the Analysis & Design composed the first planned steps of the project. During the project, new requirements arose from a changing market situation. The need to reduce costs and increase return caused a shift from focusing on business process engineering to business process improvement. Accordingly, the evolution of requirements split into the phase of method support for 1. process engineering, 2. system requirements specification, and 3. process improvement. To provide a method, which satisfies these requirements, method fragments were needed that either partly or completely covered these domains. Thereby, methods should be characterized by a high degree of standardization, acceptance in practical use and availability of software tools support. The following section describes the specific requirements of each phase and the method fragments which were selected to provide method support. 1

Irrespective of the covered modeling dimension and the level of granularity, any part of an existing method can be considered as method fragment [14].

Adapting the UML to Business Modelling’s Needs

2.1

75

Phase 1: Supporting Process Engineering

The first goal of the project was the change from a functional structure to a process oriented organization. To meet the requirements of process engineering’s activities there was the need to cover the main aspects of business processes [16]. Among these are – – – – –

processes and sub-processes, services consumed and provided by processes, suppliers and consumers of services aggregation associations between processes and strategies, critical success factors and index values.

Besides defining corresponding concepts, the method must define a procedure of usage that describes the business processes at a high level of abstraction as well as, how to derive index values from such a description. The purpose of modeling business processes at this layer is to enable the management of business processes as a whole [5]. The first intention was to use the UML for modeling the business domainbecause UML is a widespread and accepted standard and supporting modeling tools are available. However, UML was not chosen for two reasons: – Incompleteness of concepts concerning to the depicted requirements – Disaffirmation of the process management with the UML notation The lack of concepts for business process modeling manifests when trying to derive index values from a business goal. The UML doesn’t provide stereotypes or meta classes for these concepts. Even the UML Toolkit of Eriksson and Penker doesn’t overcome this deficit [16]. Besides this, it has to be stated that the ”technical” appearance of the UML’s notation was an obstacle for the acceptance on business’ side.2 The decision was made not to use the UML for business modeling at this level of abstraction. So alternatives for business modeling were sought. Comparative methods in this domain PROMET BPR was chosen. The PROMET BPR methodology is a part of the PROMET family [12]. Its focus is on process engineering, especially the design and control of business processes. Adequate concepts, including ratios and index values, are provided through the ”organizational design” view. In addition, PROMET provides ”data architecture” and ”function design” charts for describing the IT support of the business processes. In contrast the data design and functional design concepts of this method were not considered optimal because they conflict to the object-oriented paradigm and thus restrict the reusability of business process modeling’s artifacts in the phase of systems requirements definition. Because of the business process engineering focus in the first project phase, the decision was made to use PROMET BPR and later link the artifacts to the UML. Thus, from the organizational design fragment of PROMET BPR the following concepts were selected: 2

For instance the description of goal/problem-pairs in a diagram as proposed in [16] were considered as much more complicated then a table.

76

Andreas Dietzsch

Critical Success Factor 1..* 1 Business Goal

Strategy

Service

Index Value is provided

is consumed

Process Map

Supplier

1 1..*

Input

1..* 1..*

Management Process

4..11 Business 1 1..* Process

Performing Process

Output

1..* 1..*

Customer

Support Process

Fig. 1. Concepts of the PROMET BPR Method Fragments – The process typology, differentiating managing, performing and supporting processes – The process landscaping concept with process maps as a high aggregated form a process model [3] – Service specification [12], – The concept of the sequence of formulating strategy, goals, critical success factors, and index values The notations as proposed in [12] and [6] were changed according to the requirements of the business division mainly driven by the need to simplify the communication of the models. So, (graphical) formatting options such as colors were used to express semantics such as process types. The meta-model of the fragment selected from PROMET BPR is shown in figure 1. Using this methodology about 50 processes were defined by process landscapes. Because of the changes made to the standard method tool support could not be provided. Aside from this, a diagramming tool was used to model. An example of a process landscape is shown in figure 2. 2.2

Phase 2: Supporting System Requirements Specification

With the structure definition of the business processes and the provided services, the business modeling workflow was almost completed. The next step was to initiate the adoption of the information systems to the resulting new business

Adapting the UML to Business Modelling’s Needs

Management

Strategy

Managing Reviews

Goals

Checklist

Projektantrag

Projects

Architecture Draft

Artefact Management

Artifacts

Develop Enterprise Architecture

77

Ressources Plan

Reports

Assignment

Review Plan

Forecast Request

Review Request

Expertise Request

Creating Forecasts

Cooperative Review

Expertise

Forecast

Cooperative Statement

Experts Statement

Review Criteria Feedback

Projects

Vorgehen Beurteilung

Consolitate Results

Projectplan

Architecture Review

Select Artifacts

Fig. 2. Example of a process landscape needs. For this purpose the system requirements had to be specified based on the newly created business model. Thus, new concepts were needed for the method. Besides covering these concepts an additional method fragment has to be syntactically and semantically linked to the PROMET fragment. The following two steps were performed to (re-)engineer the method: – The new requirements of method support were described and a suitable method fragment was selected. – The PROMET fragment was integrated with the new method fragment to create a new method version. The output of process engineering was influenced by an organizational perspective and can be characterized as building blocks of the business architecture [17]. To formulate requirements on information systems the realization of the new designed business need be described in detail. A method fragment, which support this, has to contain the following concepts: – – – – –

link to business processes consumed and provided services representation of alternatives in realization activities within a business process responsibilities for activities

Because of the strong focus on standardization, acceptance and tool support (see section 2.1) the UML was the first method analyzed. In result, the UML

78

Andreas Dietzsch

was considered as adequate to provide the needed method support. The following artifacts were defined as parts of the UML method fragment: – Business Use Case Model containing Business Use Case Diagram and Business Use Case Specification – Activity Diagrams – Business Object Model In contrast to the definition of the PROMET BPR fragment, the notations of the UML fragment were not changed. However, in linking to the PROMET fragment some semantic constraints were defined. First there has to be a one-to-one association between business processes of the PROMET fragment and the Business Use Cases of the UML fragment. Thus the linkage between a process landscape’s process and a Business Use Case was assured. Furthermore aggregation associations between Business Use Cases were excluded. This is to avoid redundancies between associations of business processes on process landscapes, and association in a Business Use Case Model. The only allowed association is specialization. This is used to express alternatives in realizing a business process, which are modeled as specializations of a so called ”abstract” Business Use Case. The ”abstract” Business Use Case defines the inputs and outputs of a process. Variants of this are differed by the process realization, e. g. the number of activities or decisions. The Business Use Case Specification document summarizes these characteristics of the process’ realization. Other constraints addressed the Activity Diagrams. In contrast to the standard UML semantics, they need to contain two ’swim lanes’ for the input and the output of a business process. Each business object class in these swim lanes has a one-to-one association to a consumed or provided service in a process map. The concepts in the newly created method cover the main aspects of business process architecture as well as its realization. The general meta model of the UML fragments and its links to the PROMET fragment are shown in figure 3. 2.3

Phase 3: Supporting Process Improvement

As described earlier, changing market conditions caused a switch of the project focus to process improvement activities. This leads to the demand of ratios for the analysis of the processes’ performance. After the first work of defining business process and the realization of using models, the idea arose to use these models as a starting point for analysis. Thus leads to the need to define index values and link them to the concepts of the method. As described in section 2.1 goals are derived from the strategy. Thereby, a goal describes the services which will be provided by a business process, and how these services will be produced. Critical success factors are referenced to goals by describing potential obstacles that arise while trying to produce the planned services. Critical success factors are implemented through index values, which are formulated based on measurable phenomenon. These phenomena are

Adapting the UML to Business Modelling’s Needs

1..n

Service

Business Process 1

79

Responsibility

1 Variant

1

1..n Business Use 1 Case 1 Business Object Model

1..n Business Object Class

Use this to show alternative realizations of a business process.

1 Activity Diagram

3..n Activity

Swim Lane

Fig. 3. Linkage of the UML and BPR Fragment’s main concepts the activities, swim lanes and business object classes contained in an Activity Diagram. This relationship is shown in figure 4. By summarizing information about the realization of the business process through ratios, the process management was able to use the process models as indicators for change potential. The analysis of a business process can now be realized by performing three steps: 1. analyze the business processes’ interfaces 2. compare the complexity of the business process realization 3. compare the ”directness” of providing the output For this analysis heuristics were formulated. The analysis of the business processes’ interfaces can be realized using the process maps. Here the process management has to investigate the relation between the quantity of services consumed and those provided by a business process. As a starting point, it was defined that this relation should be between 0.5 and 2.0. Processes, those out of this range should be analyzed further according to the following steps. Assuming that more than one process is identified as a change candidate during the first step, the next step is to compare the complexity of the process realization. Based on the Activity Diagram the following ratios will be analyzed: – – – –

the the the the

quantity quantity quantity quantity

of of of of

activities decisions parallel activities, changes of responsibility within an Activity Diagram

It is assumed that the higher the number of activities or decisions to be made within a business process the higher is the process complexity and this

80

Andreas Dietzsch

Responsibility

Strategy

Business Goal

Critical Success 1 0..* Factor

1..n

Business Process 1

1 Variant

1 1..n Business Use 1 Case 1

Service Business Object Model

1..n Business Object Class

1 Activity Diagram

3..n Activity

Swim Lane

Index Value

Fig. 4. Linkage of ratios to elements of a Activity Diagram consequently forms a higher potential for process improvement. The number of parallel activities and changes in responsibility addresses the expenditure of coordinating the activities. From these ratios the potential for simplifying the process can be derived. The last step in analyzing process realization is to count the number of Business Object Classes in an Activity Diagram; of which they are neither input nor output of the business process. This number expresses the directness of transforming the input into the processes’ output. So activities, which do not directly contribute to the process output can be identified. The general goal of designing a process realization is to minimize the quantity of such Business Object Classes and the activities linked to them. With the described ratios the process management was able to assess the business impact of design decisions originating in the process engineering phase. Therefore, supported by the provided method the potential for process improvement could be analyzed systematically.

Adapting the UML to Business Modelling’s Needs

3

81

The Resulting Method

After the described phases the engineered method now consists of concepts mined out of both PROMET BPR and the UML. The integration of these concepts is realized through mainly semantic constraints. From the phases of the method engineering three views result, in characterizing the method: the business process view, the view on services and the view on ratios (see figure 5). However, the engineered method has two problematic characteristics. On the one hand, the modelling paradigm changes from a business process focus to a system requirements. On the other hand there is no tool support spanning all the views and assuring the consistency over the entire modeling process. This is problematic because the business divisions mainly communicate by using business oriented artifacts such as process maps and service specifications. In contrast to this the IT division focuses on system-oriented artifacts, which could lead to a gap in the flow of information from business divisions to the IT division. Besides this higher requirements on quality management results from the gap in tool support. The competence centre focuses on solving these problems with an organizational solution. Hence, the role of the Business Process Engineer (BPE) was defined. A BPE understands the customized method and is able to apply it to meet the requirements of compensating the method’s deficits. A BPE also has knowledge of business and IT and is aware of the dependencies between them. The authority to issue directives to solve process issues combined with the method and software tools has proven as a way to bridge the gap between business and IT domain.

Fragment PROMET BPR

UML

Aspect Business Process Process Map Strategy Business Goal Critical Success Factor

-

Business Use Case Activity Diagram

Process

-

Services

-

Service

-

Business Object Model

-

Index Value

-

Activity Desicion Business Object Class

Ratios

Fig. 5. Concepts of the Integrated Method Fragments

82

4

Andreas Dietzsch

Conclusions and Outlook

Because of the UML’s weakness in supporting concepts for business process modeling a project specific method was engineered, based on PROMET BPR and the UML. Thereby, the focus of this paper is on the artifacts. The adoption of the process model for modeling is not described. Further work will focus on improving the combination of text documents and graphical representations of business models. Furthermore there will be investigations to improve the tool support for individually engineered methods, i. e. through the use of meta-case tools. The main conclusion is that there is not just one method, which covers all the specific needs that arise with change processes. This paper shows that situational method engineering is an appropriate approach for solving this problem. But engineering project specific methods can be linked up with problems resulting from breaks in the modeling paradigm or the tool support. The competence center’s solution focuses on solving these problems through an organizational solution. In the Mobiliar, this combination of method engineering activities and organizational problem solving has proven as an effective and pragmatic means for future projects.

References [1] Brinkkemper, S.; Saeki, M.; Harmsen, F.: Assembly Techniques for Method Engineering. In: Pernici, B.; Thanos, C. (Eds.): VaiSE’98, LNCS 1413, Springer, Berlin et al., 1998, 381–400 74 [2] Brinkkemper, S.; Saeki, M.; Harmsen, F.: Meta-Modelling Based Assembly Techniques for Situational Method Engineering. In : Information Systems 24 (1999) 3, 209–228 74 [3] Br¨ ucher, H.; Endl, R.: Eine gesch¨ aftsregelbasierte Erweiterung von UML, in: Proceedings of KnowTech 2001, 01.-03. November 2001, Dresden, Springer, appears in spring 2002 76 [4] Esswein, W.: Modellierung der Verteilbarkeit von Daten. In: Fortschrittberichte VDI Reihe 10: Informatik/ Kommunikationstechnik, Nr. 251. D¨ usseldorf: VDIVerlag, 1993, 170–182 74 [5] Gruhn, V.; Wellen, U.: Process Landscaping - eine Methode zur Gesch¨ aftsprozessmodellierung. In: Wirtschaftsinformatik 42 (2000) 4, 297–309 75 ur den Entwurf von Gesch¨ aftsprozessen. [6] o. V.: PROMET Methodenhandbuch f¨ IMG, St. Gallen, 1997 76 [7] Junginger, S.; K¨ uhn, H.; Strobl, R.; Karagiannis, D.: Ein Gesch¨ aftsprozessmanagement-Werkzeug der n¨ achsten Generation - ADONIS: Konzeption und Anwendung. In: Wirtschaftsinformatik 42 (2000) 5, pp. 392 401 [8] Krallmann, H.; Gu, F.; Mitritz, A.: ProVision3D - Eine Virtual Reality Workbench zur Modellierung, Kontrolle und Steuerung von Gesch¨ aftsprozessen im virtuellen Raum. In: Wirtschaftsinformatik 41 (1999) 1, pp. 48 57 [9] Kruchten, P.: Der ”Rational Unified Process”. In: OBJEKTspektrum, 6 (1999) 1, 38–46 74

r

Adapting the UML to Business Modelling’s Needs

83

[10] Kruchten, P.: The Rational Unified Process: An Introduction. 2nd ed., Addison Wesley, Reading, 2000 [11] Opdahl, A. L.; Sindre, G.: Facet Modelling: An Approach to Flexible Conceptual Modelling. In: Information Systems 22 (1997) 5, pp. 291 323 ¨ [12] Osterle, H.: Business Engineering Prozeß- und Systementwicklung, Band 1: Entwurfstechniken. 2nd Edition, Springer, Berlin et al., 1995 75, 76 [13] o. V.: Rational Unified Process: Best Practices for Software Development Teams. White Paper, Download: http://www.rational.com/media/whitepapers/ rup bestpractices.pdf, 07.12.2001 74 [14] Ter Hofstede, A. H. M.; Verhoef, T. F.: On the Feasibility of Situational Method Engineering. In: Information Systems 22 (1997) 6/7, 401–422 74 [15] Versteegen, G.; Salomon, K.; Heinold, R.: Change Management bei Softwareprojekten. Springer, Berlin et al., 2001 [16] Eriksson, H.-E.; Penker, M.: Business Modeling with UML: business patterns at work. John Wiley & Sons, New York et al., 2000 75 [17] Morabito, J.; Sack, I.; Bhate, A.: Organization Modeling: innovative Architectures for the 21st Century. Prentice Hall, Upper Saddle River, 1999 77

Analysis of UML Stereotypes within the UML Metamodel Martin Gogolla1 and Brian Henderson-Sellers2 2

1 University of Bremen University of Technology, Sydney

Abstract. Stereotypes are a powerful and potentially expressive extension mechanism in the Unified Modeling Language (UML). However, it seems that stereotypes are difficult to handle because using stereotypes needs an understanding of the UML metamodel and, in particular, an understanding of OCL constraints. Stereotypes are often applied in a wrong or at least sloppy way without proper declaration. There are also differences between the various versions of UML with respect to subtle details in the stereotype part. A graphical syntax for stereotypes including examples has been introduced only late in UML 1.4. Other difficulties are that constraints are used in the stereotype context in two completely different ways and that no full support of stereotypes is yet offered by tools. The paper points out these difficulties in detail, analyses the UML metamodel part dealing with stereotypes, and makes various suggestions for improving the definition and use of stereotypes.

1

Introduction

The Unified Modeling Language or UML [OMG99, OMG01] allows for three extension mechanisms: tagged values, constraints and stereotypes. This paper concentrates on the latter two. The basic idea of the paper is to study UML stereotypes in detail. We want to point out some difficulties in defining and using stereotypes and employ the Object Constraint Language OCL [WK98, RG01, GR01] to define a precise meaning for the introduced stereotypes. Interestingly, up to now there seems to be little, if any, work on the formal definition and analysis of stereotypes, especially in connection with OCL. Our discussion also reveals that the features of the UML metamodel itself are not sufficient for the comprehensive definition of such stereotypes. One additionally needs a language to define transformations on UML metamodel diagrams in order to deal with situations where generic definitions are needed. Our ideas have connections to other related work. In the context of objectorientation, the name stereotype was first invoked in [WB94] where stereotypes were used to help in thinking about and creating objects. Metamodels of object-oriented languages with stereotypes have not only been studied for UML [OMG01], but also for example for OML [HSFG97]. General considerations and classifications of UML stereotypes have been discussed in [BGJ99, DSB99]. J.-M. J´ ez´ equel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 84–99, 2002. c Springer-Verlag Berlin Heidelberg 2002


Analysis of UML Stereotypes within the UML Metamodel

85

Fig. 1. Abstract Syntax for Stereotypes in UML 1.4

A general criticism of UML stereotypes can be found in [AKHS00, HS02]. UMLrelated questions concerning application-dependent stereotypes have been studied in [SW01]. The use of stereotypes covers a wide range; among the many application areas we only mention web design [Con99], geographical information systems [PL01], multimedia [SE99] and telecommunications [KMP+ 98]. The present paper takes up ideas from [Gog01] where stereotypes have been introduced for relational database design. The structure of the rest of the paper is as follows. Section 2 discusses the stereotype part of the UML metamodel. Section 3 analyses the possibilities of that metamodel by studying selected examples. For each example, the impact on the UML metamodel is discussed and suggestions for improvement are made. The paper closes in Sect. 4 with some final remarks.

2

Notable Technical Details for UML 1.4 Stereotypes

This subsection concentrates on stereotypes in UML 1.4 as shown in Fig. 1, the latest approved version of UML and the one which we use for our forthcoming examples. Readers interested now in an object diagram belonging to the metaclass diagram in Fig. 1 may already have a look at Fig. 5 that will be explained below. 2.1

Attribute baseClass

First, the type of the attribute baseClass is Name, which essentially means that baseClass gives a String value. It would be better if the attribute does not only

86

Martin Gogolla and Brian Henderson-Sellers

hold a name of a metaclass but the metaclass itself. It is, however, not possible to express this with the current UML features. Second, if, as is implicit in the textual semantics in the OMG documents, the attribute baseClass is required to refer to a class name of the UML specification, a metaclass, one could additionally give a constraint requiring this: context Stereotype baseClassRefersToAMetaclass: baseClass="Abstraction" or ... or baseClass="Object" or ... or baseClass="VisibilityKind" This means that this constraint must list exactly the names of the classes in the UML metamodel. Third, the above constraint is merely a restriction for the baseClass attribute. This does not guarantee that the model elements linked to the stereotype belong to the correct class. If one wants to formally assure in an OCL-like way that the model elements belong to the proper class, one can do the following trick: Assume we have a Stereotype object s42 with s42.baseClass being the name of a UML metaclass. Then we can generate an OCL constraint which assures the desired restriction. The constraint looks like: "context Stereotype s42IsLinkedToCorrectModelElements:" + "s42.extendedElement->forAll(e|" + "e.oclIsKindOf(" + s42.baseClass + "))" The expression above constructs a String representing an OCL constraint. It consists of String constants notated between quotation marks " and one string expression s42.baseClass accessing the UML metamodel. The Stereotype object s42 must already exist in order to do that construction. To draw an analogy from progamming languages, this constraint is more like a run-time generated constraint than a design- or compile-time determined one. When a Stereotype object exists, we can and must generate a respective constraint. 2.2

Associations between ModelElement, Constraint and Stereotype

There are two possibilities for links between stereotypes and constraints. One possibility is that the links belong to the association between Stereotype and Constraint. The other possibility for such a link is the association between ModelElement and Constraint, because each stereotype is a model element. Consequences of this construction will be discussed in detail in Sect. 3.3. 2.3

Association between ModelElement and TaggedValue

Tagged values are needed for tag definitions, which, in turn, are relevant for Stereotypes. The textual description in UML 1.4, page 2-80, lines 12–13, states that

Analysis of UML Stereotypes within the UML Metamodel

87

Fig. 2. General Notation of a Stereotype Declaration

Any ta!!$d value must have one or more reference value links or one or more data values, but not both.

This means that an xor constraint is probably missing in the class diagram of Fig. 1 between the association with role names referenceValue and referenceTag and the association with role names modelElement (modelElement is the implicit OCL role name for this side of the second association) and taggedValue. Furthermore, the multiplicities in the class diagram do not match the intended meaning. On the ModelElement side of the association with role name taggedValue there should be a multiplicity 0..1 instead of the multiplicity 1. The wording also suggests that the role name dataValue should be present on the ModelElement side of that association. Summary: The attribute of metaclass Stereotype could be further restricted by a constraint requiring that the attribute refers a UML metaclass. A constraint for the declaration of the stereotype and a match to its use should be generated after the stereotype has been introduced. An xor constraint should be added between the association with role names referenceValue and referenceTag and the association with role names modelElement and taggedValue.

3

U ML Stereoty pe Analysis by Selected Examples

This section gives detailed examples for UML stereotypes in the graphical and tabular notation proposed in the UML notation guide and studies properties of the UML stereotype definition. Examples worked out in detailed form are hard to find in the literature. The section also shows how these stereotypes, in particular their declaration and use, are represented as object diagrams corresponding to the UML 1.4 metamodel as shown in Fig. 1. This approach allows conclusions to be drawn on the technical advantages and drawbacks of the UML metamodel. Figure 2 shows the general notation of a stereotype declaration. The following items must be or can be provided: a mandatory name for the stereo-

88

Martin Gogolla and Brian Henderson-Sellers

Fig. 3. Declaration of the Stereotype ≪persistent≫

type shown as stereotypeName, the mandatory base metaclass of the stereotype shown as baseClass, zero or more optional definitions of stereotype tags shown as tagDefinition, zero or more optional stereotype constraints shown as stereotypeConstraint being constraints that are attached to the model element to which the stereotype is applied, and zero or more optional constraints shown as applicabilityConstraint that restrict the applicability of the stereotype. In addition, optional notes containing comments and a graphical icon may be present. 3.1

UML Stereotype ≪persistent≫

Figure 3 shows the declaration of the stereotype ≪persistent≫ in the way it is proposed in the UML notation guide. Although the UML already knows the stereotype ≪persistent≫ as a standard stereotype, we use a variation of it because it is a good example for a general application- and domain-independent stereotype. The UML metaclass Class and the stereotype ≪persistent≫ are shown within class rectangles. A dependency from stereotype ≪persistent≫ to metaclass Class displays the fact that the base class for stereotype ≪persistent≫ is the UML metaclass Class. The stereotype ≪persistent≫ owns a boolean, single-valued tag indicating the form in which the storage is supposed to be performed. Two comments explain the intended meaning in textual form. Figure 4 gives an example for using the stereotype ≪persistent≫. It shows four classes, where three of them are persistent. Objects of class Order have to be stored in a file, whereas objects of classes Customer and Product are supposed to be stored in a relation. The class UserInterface is not a persistent class.

Analysis of UML Stereotypes within the UML Metamodel

89

Fig. 4. Use of the Stereotype ≪persistent≫

Figure 5 now combines the facts from Fig. 3 and Fig. 4 in the form of an object diagram belonging to the UML 1.4 metamodel as shown in Fig. 1. We show the figure to illustrate an instantiation of the UML metamodel for a particular use. The upper part above the dashed line with the objects belonging to the classes Stereotype, TagDefinition and Comment reflects the declaration of Fig. 3. The lower part below the dashed line with the objects belonging to classes TaggedValue and Class represents the use of the stereotype in Fig. 4. The Class objects with names Order, Customer, Product and UserInterface are of course classes in the class diagram in Fig. 4. Summary: Stereotypes must be declared and can then afterwards be applied. It is not sufficient to simply use the stereotype without a definition. This is analogous to declaring a variable or defining a procedure in a programming language. Without full declaration the item cannot be used properly because its details are unknown. It seems that in the literature stereotypes are frequently applied without a proper declaration (in fact, usually without any declaration). 3.2

UML Stereotype ≪important≫

This section studies an example for a stereotype which is syntactically correct according to the UML metamodel, but where the defined stereotype communicates no real message. The declaration in Fig. 6 introduces the stereotype ≪important≫ in the form proposed in the UML notation guide. The purpose of this stereotype is to mark (or brand or classify) certain elements in a UML model as being important in order to draw special attention to these model elements. The stereotype uses the metaclass ModelElement as its baseClass. It has no constraints and no tag definitions. It only consists of its name and a comment. Summary: The UML metamodel allows the declaration of stereotypes without tag or constraint content. Thus stereotypes can be used for simply marking model elements. Therefore, not every syntactically allowed stereotype involves a constructive and good modelling contribution. If the stereotype has no tag or constraint, the same modelling effect could probably have been achieved by

90

Martin Gogolla and Brian Henderson-Sellers

Fig. 5. Metamodel Representation of the Stereotype ≪persistent≫ and its Use

connecting the stereotyped model elements with a single comment. A more general observation is that stereotypes should be avoided if an equivalent modelling can be achieved by using more modest model elements. Altogether, these considerations lead to some observations and consequences concerning the UML metamodel. The attribute baseClass is not restricted, because it can be set equal to ModelElement (the top of the metahierarchy in UML) meaning that the defined stereotype can be applied to all kinds of model elements. However, it seems hard to decide which metaclasses should be allowed for the baseClass attribute and which not. A simple solution would be to exclude the declaration of stereotypes for general ModelElements and add a well-formedness rule forbidding the metaclass ModelElement as the baseClass Attribute. This guarantees that stereotypes can be only declared for subclasses of ModelElement. context Stereotype forbidModelElementAsBaseClass: baseClass"Foundation::Core::ModelElement"

Analysis of UML Stereotypes within the UML Metamodel

91

Fig. 6. Declaration of Stereotype ≪important≫ Following the UML Notation Guide

3.3

UML Stereotype ≪singleKey≫

Figure 7 shows the declaration of the stereotype ≪singleKey≫ following the UML notation guide. The intention of this stereotype is to mark an attribute in a class as being the key attribute of the class, i.e. to require that two different objects also differ in the value of this key attribute. The constraints in Fig. 7 require that there is exactly one attribute in a class marked by this stereotype and the attribute values identify an object within its class uniquely. The baseClass of the stereotype is the metaclass Attribute. We would like to draw the attention to some subtle points in the notation. First, the note on the left side of the diagram (within the rectangle with the bent corner) contains a constraint (not only a comment) as indicated by the enclosing braces. Second, there is another constraint present in the diagram, namely the one in the rectangle for stereotype ≪singleKey≫. Third, the difference between these two constraints concerns the objects to which these constraints refer. The constraint in the note concerns the stereotype itself and restricts the way the stereotype may be applied. The constraint in the rectangle for stereotype ≪singleKey≫ concerns the model element to which the stereotype is applied, namely the attribute required to be the key. The UML 1.4 description does not explicitly distinguish between these two usages of constraints. Our notation is a proposal rather than the status quo. The following discussion will illustrate these points in more detail. The object diagram in Fig. 8 follows the UML metamodel, takes up the information given in Fig. 7 and extends it with necessary facts. In particular, instead of giving the constraints in textual form, it specifies them formally with OCL. We could have given the OCL description already in Fig. 7, but we prefer to have the informal description there. The diagram links the stereotype ≪singleKey≫ with the two constraints using different associations. The link with the role names

92

Martin Gogolla and Brian Henderson-Sellers

Fig. 7. Declaration of Stereotype ≪singleKey≫ Following the UML Notation Guide

Fig. 8. Declaration of Stereotype ≪singleKey≫ as an Object Diagram

constrainedElement and constraint belongs to the association between ModelElement and Constraint. Thus the stereotype ≪singleKey≫ is regarded here as a ModelElement due to the UML 1.4 metamodel generalizations from Stereotype to GeneralizableElement and from there to ModelElement. The link with roles names constrainedStereotype and stereotypeConstraint belongs to the association between Stereotype and Constraint. The constraint attached through the first link establishes a restriction on the stereotype itself, and the constraint attached through the second link establishes a restriction on the model element (in this case an attribute) to which the stereotype is applied. The first constraint is a conjunction divided into a left part (L) and a right part (R). It restricts the possibilities for applying the stereotype by demanding that (L) the model element to which the stereotype is applied is an attribute (or belongs to a submetaclass of metaclass Attribute), and (R) within a class there is exactly one attribute to which the stereotype is applied. The formal requirement (L) is the realization of the textual requirement given in the UML semantics, i.e. that the model element to which a stereotype is applied matches its

Analysis of UML Stereotypes within the UML Metamodel

93

baseClass. This is necessary, because the UML semantics do not express that textual requirement formally as an OCL constraint. The formal requirement (R) concerns the intended application of the stereotype to attributes identifying objects within a class. It requires that within a single class there is exactly one attribute marked by the stereotype. Formally, the (R) expression navigates from the stereotype to the attribute and to its class, from there to all the features of that class, counts the features which are linked to the stereotype where the navigation started and requires that the number of such features is one. The second constraint, which is the one that will be attached to the model element to which the stereotype is applied (in this case an attribute within a class), embodies the idea that the values of the stereotyped attribute identify the objects within the class. The general idea of the OCL expression is that two object variables having identical key attribute values also represent identical objects, so that the OCL expression would read like className.allInstances->forAll(o1,o2| o1.attrName=o2.attrName implies o1=o2). Alternatively and equivalently, we could write the implication the other way round emphasizing that different objects have different attribute values. className.allInstances->forAll(o1,o2| o1o2 implies o1.attrNameo2.attrName) But the problem in both formulations is that the class name and the attribute name are not known in advance, because one does not know to which attribute in which class the stereotype ≪singleKey≫ will be applied. Therefore, the constraint to be attached to the stereotyped attribute uses a generic formulation in which the name of the class and the name of the attribute are retrieved by the UML 1.4 metamodel expressions self.owner.name and self.name, respectively. These string-valued expressions are navigating through UML 1.4 metamodel object diagrams (like the one to be shown in Fig. 10 for this example) and are concatenated with other appropriate string constants in order to establish the proper OCL constraint. The way this constraint is used will be explained in the following. In Fig. 9, an application of the stereotype ≪singleKey≫ is shown. There is one class Book with three attributes. One of them is stereotyped with stereotype ≪singleKey≫. Figure 10 shows how the situation of Fig. 9 is represented as an object diagram of the UML metamodel. It links the stereotyped attribute to the stereotype object. Before we explain the next step of the stereotype application, let us quote an important part for the current context from the UML 1.4 semantics, section 2.6 Extension Mechanisms, subsection 2.6.4 Detailed Semantics, page 2-83. Any constraints on the stereotype are implicitly attached to the model element.

94

Martin Gogolla and Brian Henderson-Sellers

Fig. 9. Application of Stereotype ≪singleKey≫ to Class Book

Fig. 10. Metamodel Diagram of Applying ≪singleKey≫ before Attachment

Figure 10 displays the situation before this implicit attachment is carried out. Figure 11 displays the situation after this attachment has been done. It shows that in order to attach the constraint to the attribute, the body expression of the constraint is evaluated with variable self being the attribute named isbn. Thus the expression self.name evaluates to "isbn", and the expression self.owner.name evaluates to "Book". Then, the final constraint with the substituted actual class name and actual attribute name shows up. We would like to draw attention to another point illustrating the difference between the two constraints because the expression self occurring in both constraints refers to different objects. The expression self in the first constraint references the Stereotype object, in this example, the object with name singleKey. The expression self in the second constraint references the Attribute object, in this example, the object with name isbn.

Analysis of UML Stereotypes within the UML Metamodel

95

Fig. 11. Metamodel Diagram of Applying ≪singleKey≫ after Attachment

Fig. 12. Incorrect Applications of Stereotype ≪singleKey≫

Figure 12 gives examples for incorrect applications of the stereotype. On the left hand side of Fig. 12, the stereotype ≪singleKey≫ is applied to two attributes within a single class. This implies that the first constraint (the constraint on the stereotype itself) will evaluate to false due to failure of requirement (R) demanding that stereotype ≪singleKey≫ is applied to one attribute only. This is because the expression self.extendedElement->forAll(e|e.oclAsType(Attribute). owner.feature->select(f|f.stereotype=self)->size=1) will evaluate to false, if the extended model element e is equal to the Attribute object named isbn or the Attribute object named year. In particular, in these cases the expression e.oclAsType(Attribute).owner.feature->select(f|f.stereotype=self)

96

Martin Gogolla and Brian Henderson-Sellers

will evaluate to a set containing two stereotyped attributes instead of a set with cardinality 1 as required by the constraint. On the right hand side of Fig. 12, the stereotype ≪singleKey≫ is applied to a class which violates requirement (L) from the first constraint. This is because the expression self.extendedElement->forAll(e|e.oclIsKindOf(Attribute)) evaluates to false as there is an extended model element, namely the Class object named book, whose metaclass is not Attribute or a submetaclass of Attribute. Summary: The description of the stereotype semantics in the UML metamodel should be expanded in order to explicitly explain the distinction between the two possible associations between stereotypes and constraints. The first association is the association between ModelElement and Constraint, the second association being the association between Stereotype and Constraint. The description of the stereotype semantics should discuss the implicit attachment of constraints to stereotyped model elements in more detail. In order to achieve more modelling power, it must be possible to specify constraints for stereotypes that are generic in the sense that these constraints allow parts of itself to refer to the model element to which they are applied. These constraints are not directly attached to the stereotyped model elements without further consideration, but the parts of them referring to the actual stereotyped model element are evaluated before the attachment is carried out. These parts are actualized and substituted with the actual values accordingly. Stereotypes for certain complex but still moderate constraints, like for example key constraints in information systems [Amb99, Gog01], cannot be specified without such a mechanism. 3.4

UML Stereotype ≪statesHaveTransitions≫

Stereotypes can also be used for checking whether the model under development currently has certain properties expressed as application prerequisites for the stereotype. For example, in a state machine, a stereotype could check for unconnected states having no incoming and no outgoing transitions and report on these states. Figure 13 shows the declaration of such a stereotype. In the upper part of Fig. 14 we have given the formal OCL constraint assuring that the states of a stereotyped state machine have transitions. The constraint is based on the abstract syntax for UML 1.4 state machines (UML 1.4 Semantics, page 2-147) and checks for states which have no incoming and no outgoing transition. This stereotype is applied during the modelling process to see whether a developed state machine has this property or not. If the state machine has that property, the application of the stereotype would be OK and the modeller can proceed with the knowledge that the states really have transitions. If the state machine does not have that property, a tool has to report on this. In that case, the lower part of Fig. 14 could be helpful. There, a derived operation for state machines called namesOfUnconnectedStates() is defined. This operation, when applied to a state machine, returns the names of the unconnected states

Analysis of UML Stereotypes within the UML Metamodel

97

Fig. 13. Graphical Representation of Stereotype ≪statesHaveTransitions≫

and, by this mechanism, gives feedback to the modeller on how to improve the model. The OCL constraint for stereotype ≪statesHaveTransitions≫ is a rather simple one, because it only searches for single, isolated states. It is possible to formulate more sophisticated constraints; for example, one could check with an OCL constraint that the state machine has exactly one initial and at least one final state and that all states are connected by a transition path starting in the initial state. Summary: Stereotypes can be used to check whether a certain modelling situation is present or not. If the stereotype itself is equipped with a constraint in order to restrict its application to a special context, the marking of a model element with the stereotype gives feedback on whether that special context is present or not. A tool providing full stereotype support would either report that the application of the stereotype is acceptable, i.e. the proper context is present, or the tool would report that the application of the stereotype is not acceptable, i.e. the proper context is not present and in this case the tool could analyze why the context is not present. Thus, another use of stereotypes is for checking the current state of the model under development with respect to certain criteria.

self.extendedElement->forAll(sm| sm.oclIsKindOf(StateMachine) and sm.oclAsType(StateMachine).top.oclIsKindOf(CompositeState) and sm.oclAsType(StateMachine).top.oclAsType(CompositeState).subvertex-> forAll(sv|sv.incoming->notEmpty or sv.outgoing->notEmpty) context StateMachine namesOfUnconnectedStates():Bag(String) self.top.oclAsType(CompositeState).subvertex-> select(sv|sv.incoming->isEmpty and sv.outgoing->isEmpty)-> collect(sv|sv.name)

Fig. 14. OCL Expressions Handling Unconnected States

98

4

Martin Gogolla and Brian Henderson-Sellers

Conclusion

In this paper, we have analyzed the expressibility of UML stereotypes and made some concrete suggestions for the improvement of the UML metamodel. We have used OCL to define precise stereotypes. Stereotypes can be employed for various tasks in the modelling process: marking elements, declaring formal constraints in a user-friendly way, providing graphical icons of the application domain and checking the model under development for certain criteria. We feel that UML stereotypes should be used with greater care than shown in the literature. In particular, they should be carefully declared and used only when the message to be communicated cannot be expressed in any other UML terms. Necessary conditions in order to achieve a better use of stereotypes are that the UML metamodel should be adjusted and tool support should be provided for the complete part of the UML metamodel dealing with stereotypes. We hope future versions of UML will allow the definition and use of stereotypes in a more elegant way than is currently possible.

References [AKHS00]

Colin Atkinson, Thomas K¨ uhne, and Brian Henderson-Sellers. To Meta or not To Meta – That is the Question. Journal of Object-Oriented Programming, 13(8):32–35, 2000. 85

[Amb99]

Scott Ambler. Persistence Modeling in the UML. Software Development Online, August, 1999. http://www.sdmagazine.com. 96

[BGJ99]

Stefan Berner, Martin Glinz, and Stefan Joos. A classification of stereotypes for object-oriented modeling languages. In Robert France and Bernhard Rumpe, editors, Proc. Int. Conf. Unified Modeling Language (UML’99), pages 249–264. Springer, LNCS 1723, 1999. 84

[Con99]

Jim Conallen. Modeling Web Applications with UML. conallen.com, Conallen Inc., 1999. 85

[DSB99]

Desmond D’Souza, Aamond Sane, and Alan Birchenough. First-class extensibility for UML-profiles, stereotypes, patterns. In Robert France and Bernhard Rumpe, editors, Proc. Int. Conf. Unified Modeling Language (UML’99), pages 265–277. Springer, LNCS 1723, 1999. 84

[Gog01]

Martin Gogolla. Using OCL for Defining Precise, Domain-Specific UML Stereotypes. In Aybuke Aurum and Ross Jeffery, editors, Proc. 6th Australian Workshop on Requirements Engineering (AWRE’2001), pages 51– 60. Centre for Advanced Software Engineering Research (CAESER), University of New South Wales, Sydney, 2001. 85, 96

[GR01]

Martin Gogolla and Mark Richters. Expressing UML Class Diagrams Properties with OCL. In Tony Clark and Jos Warmer, editors, Advances in Object Modelling with the OCL, pages 86–115. Springer, Berlin, LNCS 2263, 2001. 84

http://www.

Analysis of UML Stereotypes within the UML Metamodel

99

[HS02]

Brian Henderson-Sellers. Notes on the Use of Subtypes and Stereotypes in the UML Metamodel. Journal of Database Management, 13(3):44–52, 2002. 85

[HSFG97]

Brian Henderson-Sellers, Donald Firesmith, and Ian M. Graham. OML Metamodel: Relationships and State Modeling. Journal Of ObjectOriented Programming, 10(1):47–51, 1997. 84

[KMP+98] Mohamed Kande, Shahrzade Mazaher, Ognjen Prnjat, Lionel Sacks, and Marcus Wittig. Applying UML to Design of an Inter-Domain Service Management System. In Proc. ISN, 1998. 85 [OMG99]

OMG, editor. OMG Unified Modeling Language Specification, Version 1.3. OMG, June 1999. OMG Document formal/00-03-01, http://www. omg.org. 84

[OMG01]

OMG, editor. OMG Unified Modeling Language Specification, Version 1.4. OMG, September 2001. OMG Document formal/01-09-68 through formal/01-09-80, http://www.omg.org. 84

[PL01]

Francois Pinet and Ahmed Lbath. Semantics of Stereotypes for Type Specification in the UML: Theory and Practice. In H. S. Kunii, S. Jajoda, and A. Solvberg, editors, Proc. Entity-Relationship Conf. (ER’2001), pages 339–353. Springer, LNCS 2224, 2001. 85

[RG01]

Mark Richters and Martin Gogolla. OCL - Syntax, Semantics and Tools. In Tony Clark and Jos Warmer, editors, Advances in Object Modelling with the OCL, pages 43–69. Springer, Berlin, LNCS 2263, 2001. 84

[SE99]

Stefan Sauer and Gregor Engels. UML-based Behavior Specification of Interactive Multimedia Applications. In Proc. IEEE Symposium Visual Languages (VL’1999). IEEE, 1999. 85

[SW01]

Ansgar Schleicher and Bernhard Westfechtel. Beyond stereotyping: Metamodeling approaches for the UML. In Ralph H. Sprague, Jr., editor, Proc. 34th Annual Hawaii Int. Conf. System Sciences (HICSS’34). IEEE Computer Society, 2001. 85

[WB94]

Rebecca Wirfs-Brock. Adding to Your Conceptual Toolkit: What’s Important About Responsibility-Driven Design? ROAD, 1(2):39–41, 1994. 84

[WK98]

Jos Warmer and Anneke Kleppe. The Object Constraint Language: Precise Modeling with UML. Addison-Wesley, 1998. 84

Stereotypical Encounters of the Third Kind Colin Atkinson1 , Thomas K¨ uhne2 , and Brian Henderson-Sellers3 1

University of K aiserslautern Kaiserslautern, Germany [email protected] 2 Darmstadt University of Technology Darmstadt, Germany [email protected] 3 University of Technology Sydney, Australia [email protected]

Abstract. As one of the UML’s main extension mechanisms, stereotypes play a crucial role in the UML’s ability to serve a wide and growing base of users. However, the precise meaning of stereotypes and their intended mode of use has never been entirely clear and has even generated much debate among experts. Two basic ways of using UML stereotypes have been observed in practice: one to support the classification of classes as a means of emulating metamodel extensions, the other to support the classification of objects as a means of assigning them certain properties. In this paper we analyze these two recognized stereotype usage scenarios and explain the rationale for explicitly identifying a third form of usage scenario. We propose some notational concepts which could be used to explicitly distinguish the three usage scenarios and provide heuristics as to when each should be used. Finally, we conclude by proposing enhancements to the UML which could support all three forms cleanly and concisely.

1

Introduction

In the context of object-oriented modeling, the notion of stereotypes was first introduced by Rebecca Wirfs-Brock [1]. She recognized that it is useful to classify objects according to the responsibilities they fulfill within a certain system. In addition to being classified by a natural domain specific type (e.g., ATMKeypad), such an object would also be classified as an “interface object”, others as “coordinator objects” etc. The categories for this secondary classification are drawn from the roles the objects play within the system (see Fig. 1). Names of natural types (i.e., class names) would typically be derived from the problem domain whereas the names of stereotypes would typically be derived from the solution structure. Thus, stereotypes can essentially be understood as a way of “branding” objects of a particular primary (natural) type with additional roles or properties. Since Wirfs-Brock used stereotypes primarily for explanation purposes she did not map the stereotype concept to a mechanism such as multiple inheritance. J.-M. J´ ez´ equel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 100–114, 2002. c Springer-Verlag Berlin Heidelberg 2002


Stereotypical Encounters of the Third Kind

101

primary classification

secondary classification

This ability to add additional classification information to a concept in a concise and straightforward way made Wirfs-Brock’s stereotype mechanism ideal for the designers of the UML who were looking for a way of allowing users to add additional modeling concepts to the UML without having to extend the metamodel directly. Since the introduction of the UML, therefore, stereotypes have primarily become known as the “lightweight” extension mechanism of the UML, allowing users to tailor the language to their own needs without having to directly deal with the UML metamodel. The choice of stereotypes as a (restricted) language extension mechanism was not only motivated by usability concerns, however, but also as a concession to many tool vendors who at the time were unable to support direct metamodel specialization. In the sense that it allows model elements to be “branded” with Account additional classification informatientity on, the stereotype mechanism defined in the UML standard [2] is Person entirely faithful to the original conboundary cept of Wirfs-Brock. However, the “official” UML extension mechaKeypad nism differs from the original usage of stereotypes in one very important way. Whereas Wirfs-Brock used stereotypes to brand objects, Fig.1. Secondary classification the UML standard defines stereotypes as a way of branding classes. In the terminology of the UML’s four level model hierarchy, the original stereotype mechanism was used to brand elements at the M0 level, while the UML standard presents stereotypes as a means for branding M1 level elements. In the previous paragraph, we were very careful to refer to the “official” definition within the UML standard, because in practice many UML users have applied the UML stereotype mechanism in the way intended by Wirfs-Brock, that is, as a way to brand M0 -level elements. Thus, in practice one finds that users of the UML use stereotypes in both styles—to brand M1 -level elements and to brand M0 -level elements. It seems that the the notational economy of stereotypes makes them an attractive alternative to the traditional (M1 -level) inheritance mechanism as a way of branding object, even when the latter captures the realworld scenario more accurately. One can therefore observe in the literature a large number of stereotypes applied in a very loose style. The result has been an intense debate among researchers and experts about how stereotypes should and should not be used, e.g., whether the original Wirfs-Brock usage should be considered valid in the context of UML [3]. It is overly simplistic, however, to assume that the two aforementioned basic usage scenarios span the full space of options. On closer analysis, it turns out that many real world scenarios are not naturally represented by either of these usage styles, but that a third interpretation that simultaneously brands a class

102

Colin Atkinson et al.

and all its objects is the most appropriate. In other words, often, properties of real world concepts naturally imply both forms of classification at the same time. Our goal in this paper is to investigate this phenomenon by fully characterizing the three forms of stereotype usage scenarios and describing a strategy for working out which form should be used for a particular real-world scenario. In the following section, we first analyze and give examples of the two basic usage scenarios and then elaborate on the third kind. We subsequently equip modelers with a litmus test to identify which kind of stereotype they are facing, provide guidelines as to when a certain form should be used, propose notational measures to make the intent of a particular stereotype explicit, and finally outline how the three kinds could be most naturally accommodated in a clean multilevel approach.

2

Generally Recognized Stereotypes Usage Scenarios

In this section we illuminate and discuss the two main types of stereotype usage scenarios which have been recognized and debated in the literature [3]. Then, we introduce the third form which—although not explicitly recognized as such in the literature to date—is possibly one of most common real world modeling scenarios. When discussing how stereotypes are used in practice, particularly when analyzing examples of stereotype applications, it is important to bear in mind that the original intent of the modeler can never be known with absolute certainty. There is always an element of uncertainty in our interpretations of what the modeler originally had in mind. This can be regarded as being both a strength and a weakness of stereotypes in the UML. It is a strength because it means that users are able to exploit stereotypes without getting bogged down in detailed semantic issues, but it is a weakness because if the modeler had a clear meaning in mind this knowledge is lost. Consequently, in this and the following section, when we classify stereotype usage scenarios we do so on the basis of our interpretation of the real world situation that the modeler is trying capture. 2.1

Type Classification

The UML 1.4 specification states that: A stereotype is, in effect, a new class of metamodel element that is introduced at modeling time [2] (page 3-33). Hence, the motivation for the use of stereotypes is essentially to extend the standard modeling vocabulary offered by the UML by facilitating the additional classification of types. The mechanism by which this is achieved within UML 1.4 is described as— . . . a way of defining virtual subtypes of UML metaclasses with new metaattributes and additional semantics [2] (page 2-79).

Stereotypical Encounters of the Third Kind

103

In other words, a new type of modeling element becomes available that users can make use of at the M1 level. According to this definition, with the exception of “redefining stereotypes” [4], stereotyped elements behave as if they were instances of the base modeling element. Thus, stereotyping of this kind provides a way of branding types so that they can be associated with special semantics. If one attaches a stereotype (e.g., ≪commented≫) to a class (e.g., Worker), (see Fig. 2) for example, the effect is the creation of a (virtual) subclass of the M2 level metaclass Class. The stereotyped class (Worker) is then considered to be an instance of this virtual subclass. Thus in our example the stereotype ≪commented≫ brands Worker not its instances. This becomes most evident when con«commented» Worker sidering stereotypes such as ≪abstract≫ or ≪interface≫ which {commenter = Bob} unambiguously refer to the classes they stereotype, since there are no direct instances of abstract classes or interfaces. Even when the stereotyped model elements have instances, e.g., objects of a framework instantiation, the stereotypes ≪applicati- Fig.2. Stereoon≫ and ≪framework≫ [5] clearly document the nature of the typed type classes and have no bearing whatsoever on their instances. Tagged Values Tagged values are intended to be used in tandem with stereotypes as a means of assigning values to user types. They are a way to supply additional information along with the branding (see Fig. 2, specifying the commenter). Tagged definitions correspond to (meta-)attributes, defining what type of value can be assigned to a type, and tagged values actually define the value. Thus, tagged definitions essentially correspond to attributes of (virtual) metaclasses, while tagged values correspond to slots of user types. Tagged definitions and tagged values do not have to be used in tandem with stereotypes but, when they are, they reinforce the model of a stereotype as defining a virtual metaclass, and a stereotyped element as representing an M1 -level type. 2.2

Instance Classification

The previous section described the “official” purpose of stereotypes as defined in the UML standard. As such, this has been characterized by some authors as the “correct” way of using stereotypes. However, there are many practical examples of stereotype usage in the UML literature that can only reasonably be interpreted as serving to classify objects at the M0 level. For example, Conallen uses ≪Applet≫ to stereotype a class OnLineGame [6] (page 169). It seems obvious that instances of OnLimeGame should be considered to be applets, whereas OnLineGame itself is simply an ordinary class. An alternative way to obtain the assumed modeling scenario would therefore have been to make OnLineGame a subclass of an M1 -level superclass Applet. Note that the Java AWT library does exactly this and provides Applet as a class from which to inherit. Likewise, in Fig. 3 the song (i.e, instance) “Bohemian Rhapsody” can be regarded as a “soundStream” while this cannot be said of the type Music. Again, the

104

Colin Atkinson et al.

appropriate way of expressing that instances of Music are sound streams would be to define SoundStream as the superclass of Music. A shorthand way of expressing such a modeling scenario which uses angled brackets (e.g., < SoundStream>) instead of guillemets (≪soundStream≫) in the class compartment is proposed in [7]. Even within the UML specification it appears that one can find stereotype usages that do not conform precisely to «soundStream» Music the definition of the stereotype mechanism. The stereotype ≪parameter≫, which is applicable to associations, has the intended meaning of flagging the stereotyped association as «instanceOf» being of temporary nature. However, this property applies primarily to the instances of associations—the links—rather bohemianRhapsody than to the associations themselves. Whether the association itself is affected by this stereotype is a matter of debate and will be revisited in the subsequent section. The aforementioned examples reflect the original intent Fig.3. Stereotyof Wirfs-Brock in using stereotypes, where she observed “I ped instance find it useful to classify objects according to their primary purpose as well as their modus operandi.” [1]. The specific examples given by Wirfs-Brock for such modus operandi—Controller, Coordinator, Structurer, Information Holder, Interfacer— all refer to the roles of objects within the system. Theoretically it is possible, given the current wording of the UML specification1 , to achieve this form of classification by applying stereotypes directly to objects. For example, bohemianRhapsody could be stereotyped with ≪informationHolder≫ or ≪soundStream≫ to document the object’s role in addition to its type. However, there are few if any examples of this style of usage in practice. End users of the UML normally attempt to achieve this form of classification (i.e., instance classification) by applying stereotypes to the type, as illustrated in Fig. 3. Without literally interpreting the UML standard they merely assume that they can use stereotypes in this way. However, attempts to capture the nature of instances, such as bohemianRhapsody, through the use of class stereotypes simply cannot work [8], since instantiation is not transitive. To illustrate this, let’s assume that the stereotype ≪soundStream≫ defines a tagged value “format” to be associated with stereotyped elements with values “mp3”, “wav”, “au”, etc. In our example, the tagged value (e.g., “{format = mp3}”) would be attached to Music and not to bohemianRhapsody. This obviously does not make any sense unless the stereotype ≪soundStream≫ was actually meant to introduce new soundStream types. In the latter case, all instances of Music would be “soundStream” objects conforming to the format specified at Music. In this case, however, the stereotype name should have been ≪soundStreamType≫. Whatever special quality is to be expressed by the stereotype, it always refers first and foremost to the stereotyped element (Music) and not to its instances. Consequently, if one actually aims to obtain “soundStream” instances then one needs to ste1

The question is whether the term “model elements” includes both M1 -level types and M0 -level instances.

Stereotypical Encounters of the Third Kind

105

reotype their class as a “soundStream type”. Yet, there are clear cut examples where the intent of class stereotypes is to brand objects instead of classes. For instance, Sauer and Engels explicitly state that— Other stereotypes are used to distinguish different types of (semantic) application objects [9] (page 249). Although stereotyping to achieve instance classification (as depicted in Fig. 3) seems to be used by many UML modelers it is described by some authors as the “wrong” way of using stereotypes in the UML, since it contradicts the stated purpose of stereotypes in the standard and is essentially redundant2 because classification of M0 -level elements is covered by the traditional M1 -level specialization (inheritance) mechanism. It is sometimes argued that traditional M0 -level element classification by using inheritance is not powerful enough to express certain advanced semantic properties [10]. For instance, the quality of being a clock (e.g., an active notion of ticking) could be captured with a stereotype so that a tool could generate appropriate code accordingly. This special instance behavior cannot be achieved by using a superclass Clock. However, this is an artificial result of the different levels of support given to stereotypes and subtyping by UML tools. Stereotypes do not inherently provide any better support for capturing such semantics. If a tool can exploit the existence of a certain stereotype to attach special semantics to modeling elements it could just as well exploit the fact that the model element is a subtype of a certain special supertype (e.g., Clock). 2.3

Transitive Classification

In the previous two sections we identified two commonly seen ways of using stereotypes in practice: one “official” way that conforms to the UML standard (i.e., type classification, such as ≪interface≫) and one “unofficial” way that does not conform to the standard way (i.e., instance classification, such as ≪soundStream≫) and is thus strictly speaking incorrect. In line with the current literature we have until now implied that these are the only two options. However, the discussion in the previous section already pointed to the fact that this is an over simplification. In describing the ≪parameter≫ stereotype we pointed out that it is primarily intended as a way of branding instances, but also left open the question as to whether its also makes sense to think of the type (the association itself) as being branded by this stereotype. In general, we make the following observations about the problem of mapping real world scenarios to the classification forms identified in the previous sections: – There is no published systematic procedure to work out whether type classification or instance classification is the best match. 2

When one actually wants to create new kinds of objects which possess features over and above slots and links, one indeed needs to resort to a (virtual or non-virtual) extension of the M2 -level. This, however, is almost never the case.

106

Colin Atkinson et al.

– Often both forms of classification apply. The ≪parameter≫ example is a good case in point. Clearly, this scenario includes instance classification, since it is ultimately the links which exhibit a temporal property. But it is also the case that an association stereotyped with ≪parameter≫ is distinguished from other associations. The ≪parameter≫ label is essential information for a reader of the class diagram to understand that this particular association is not motivated by structural considerations but only indicates a temporal communication path. Such a scenario clearly constitutes a third form of usage scenario, which we refer to as transitive classification. This usage scenario refers to situations in which the intent of the user is to brand both the type and the instances of the type. In other words, the user intends the branding of the type to transitively apply to its instances as well. Thus, in a sense this scenario represents a combination of the type and instance classification scenarios described in the previous sections. In fact, when a modeler wishes to add a new natural type (i.e., add to the set of primary classifiers), the intent is usually to apply this third transitive form. When one removes secondary classification (such as ≪controller≫ or ≪commented≫) from a formerly decorated element the element will essentially remain unchanged. When, however, one removes a stereotype whose purpose is to extend the set of modeling element types (such as ≪parameter≫) the natural type of the model element will change from a special kind to a standard type, involving significant changes in semantics, including completely changing the nature of the instances. Whether their type is said to be ≪commented≫ or not is not relevant for instances, but whether their type is said to be, e.g., ≪active≫ certainly heavily influences their behavior. As a typical example of “transitive classification” consider the situati«persistent» «interface» Account on in Fig. 4. It is obvious that instanSerializable {storageModes = XML} ces of Account should be persistent writeObject() and not the class Account itself. However, as well as requiring the instan«instanceOf» ces to support a writeObject() operation, for the persistence mechanisms myAccount to work one must also require certain properties of class Account itself. Here, Account is required to realize the Fig.4. Transitive sterotype Serializable interface and also specify a format according to which its instances are to be serialized. The ≪persistent≫ stereotype as used in Fig. 4 therefore affects both type (M1 level) and instances (M0 level). Unlike in pure type classification (e.g., stereotype ≪commented≫) the intent is that distinct type properties transitively apply to instances as well. As a second example, consider the use of design pattern role names as stereotypes. Sometimes such a role name represents type classification only but

Stereotypical Encounters of the Third Kind

«taxed» Video {taxRate = 16%}

«instanceOf»

2001

(a) Type only

Video taxRate : Integer

«instanceOf»

«taxed» Video {taxRate = 16%} «instanceOf»

2001

2001

taxRate = 16%

taxRate = 16%

(b) Instance only

107

(c) Transitive

Fig.5. Classification forms often its intent is best described by transitive classification. For instance, a class carrying the stereotype ≪composite≫ is most naturally interpreted as having instances who play the role of a composite3 supporting this role by the presence of certain slots (e.g., components) and being able to respond to certain messages (e.g., addComponent) and at the same time exposing certain class properties, such as realizing a Component interface. It is important to reiterate that we are referring to the modeler’s intent when identifying this (and the other) stereotype usage scenarios. With the current definition of stereotypes and instantiation in the UML it is not possible to syntactically distinguish transitive classification from pure type classification.

3

Classification of Stereotype Usage Scenarios

Having motivated and introduced the different kinds of stereotypes usage scenarios, we now present a systematic classification of the different scenarios and describe concrete criteria for choosing between them. This classification is orthogonal to other classification approaches, such as that of Glinz et al. [4] that concentrate on categorizing usages conforming to the UML standard. Fig. 5 shows a practical example of the three different cases side-by-side. In Fig. 5(a) the modeler intends to brand class Video only, adding the information that this product type has a tax rate of 16% associated with it. The tax rate information is not accessible from instances of Video. Fig. 5(b) shows the opposite extreme in which the modeler wants to classify Video objects and give them each a separate tax slot. Without any additional constraints there is nothing to control the values assigned to the tax slots of individual instances of Video. These values may or may not be the same. Fig. 5(c) shows the intermediate situation in which the modeler wants a tax rate to be visible at the level of individual 3

Pattern role names are a good example for secondary classification. Typical primary types of objects playing the role of a composite would be Group, Assembly, etc. The classification as a composite object is secondary only and orthogonal to the primary type hierarchy.

108

Colin Atkinson et al.

Table 1. Classification scenarios Type Classification e.g., ≪abstract≫ affects types only

Instance Classification e.g., ≪applet≫ affects instances only

Transitive Classification e.g., ≪persistent≫ affects types & instances

objects, but wants to fix the value of the tax rate for each object at the value of the type. Thus, the intent in Fig. 5(c) is to brand instances as well as the type. Notice that with current stereotype notation it is impossible to distinguish the situations shown in Fig. 5(a) and Fig. 5(c) from the stereotyped class alone. Table 1 summarizes the three different scenarios in tabular form. The left hand column represents type classification, in which the intent is to brand the type only, and not the instances. The middle column represents regular instance classification in which the intent in using a stereotype is only to brand the instances of a type, not the type itself. As has already been pointed out, this situation should be handled more appropriately with regular inheritance (i.e., the classifier of the instances is defined to be a subtype of a supertype corresponding to the stereotype). Finally, the right hand column of Table 1 represents the transitive classification usage scenario in which the intent is to brand the instances of the type and the type itself. The difference between these three forms can also be explained in terms of their effects on the type and/or instance facets of the model element to which they are applied. As explained in [11], model elements representing types generally have two facets—a type facet which describes the properties of their instances (e.g., attributes and methods), and an instance facet which describes the element’s properties as an object (e.g., tagged values). In terms of these facets: 1. type classification purely affects the instance facet of types, 2. instance classification affects the type facet of types only, and 3. transitive classification affects both facets of types. With this terminology we have an easy way to find out which category a certain stereotype belongs to. By checking which facets of a model element at the M1 level are influenced by the stereotype, one can immediately tell which kind of stereotype one is dealing with. The systematic view just established is perhaps also helpful in explaining why modelers use stereotypes for instance classification even though the UML definition explains them to have the effect of type classification. As we already mentioned, in such cases the use of inheritance at the M1 level would be more appropriate, since inheritance is the most natural way to influence the type facet of a type. The type facet of a subtype is simply extended with that of the supertype, which is exactly what is needed when one wishes to make sure that a set of instances carry certain properties. However, it is the case that a

Stereotypical Encounters of the Third Kind

109

generalization relationship is a link between two types at the M1 level, i.e., such a link must be regarded as belonging to the instance facet of a type. Therefore, the use of a stereotype—which can only affect the instance facet of a type in the non-transitive case—seems understandable, since one can imagine that the modeler associates a designated type facet with a designated instance facet. One way to make this assumption true, i.e., truly make the stereotype have the effect of transitive classification, is to use a constraint which demands any type equipped with this stereotype to inherit from a particular class (e.g., SoundStream). Another, more cumbersome way is to use a much more complex constraint which spells out the full type facet required for “SoundStream” types. While we have just established a way to actually make a stereotype realize transitive classification using plain UML only, we still need to be aware of the difference between a stereotype whose sole purpose is to classify instances and a stereotype which affects both type and instances, i.e., transitive classification. How to make the choice between the two cases and subsequently how to notationally distinguish them is the subject of the following two sections. 3.1

Usage Guidelines

As conceptual modeling mechanisms, with clearly distinct semantics (captured in Ta[property not [property visible at visible at ble 1), the difference between the three type level] type level] usage scenarios is easy to understand. What is much more challenging, however, is working out which scenario best fits a parinstance ticular real world situation. A systematic classification process for making this decision is given in [property not [property visible at visible at Fig. 6. instance level] instance level] Instance classification is the most easy to match to real world situations, since it actually corresponds to an ordinary classitype transitive classification classification fication of instances, where one uses a type to describe the common properties of a set of objects. Thus, in scenarios where there is no type level information (i.e., no proper- Fig.6. Supporting the decision ties of instances are fixed at the type level process nor does the type need to be distinguished from other types), instance classification is the obvious choice. In terms of the Video example, the property “price” is a good illustration (see Fig. 7), assuming the price can vary from video to video, this would be represented as an attribute at the type level, and be given different values for each instance. No information is required at the type level. When there is some property that could reasonably be applied to the type, the situation becomes more difficult. The existence of a type-level property implies transitive or type classification. As specified in Fig. 6, one now needs to decide whether instances are affected or not. The difficulty in doing this arises because there is virtually no form of type-level information which cannot, in

110

Colin Atkinson et al.

some form or another, be regarded as relevant to the instance level as well. Take the ≪commented≫ stereotype, for example. Normally, one would think that software objects do not care about whether their classes are commented. But on the other hand, one cannot exclude a situation in which someone wants to reject all objects from being dynamically added to his system unless they can testify that their classes have been developed with the use of comments. Also, in the case of the video example, should the property of the tax rate be associated with the class «taxed» only, with the objects only or with both (see Fig. 5)? Video {taxRate = 16%} Assuming that the tax rate is fixed for all videos, it is reasonable to view the tax value as belonging to the price : Integer type only. However, from the perspective of clients of video objects, the tax rate is just a normal property «instanceOf» that they might be interested in (like price). The fact that it is constant for all video instances might be 2001 irrelevant at the instance level. Since there is a case price = 9.95 for viewing it as either a type-level property or an instance-level property, there is also a case for viewing it as both (i.e., transitive property). Fig.7. Priced Object Thus, from these examples it can be seen that a decision for one of the classification scenarios purely based on the nature of concepts in a real world scenario cannot be made. The choice heavily depends on the needs and intent of the modeler. In the case of the video example, we are assuming that the real world scenario dictates that taxes are constant for videos of a particular kind. This, therefore, implies that “taxRate” is at least a type-level property—ruling out the pure instance classification scenario. The question then is whether or not “taxRate” should also be viewed as an instance-level property. This is where the purpose of the model and the needs of the modeler come in. The fundamental question at this point is whether the modeler wants tax rates to be visible to clients of the instances. In other words, should a client of a video instance be able to directly determine (i.e., see) its tax rate? If the answer is yes, the tax property is best thought of as transitive (i.e., belonging to the type and the instances) and the transitive classification approach should be chosen. If no, the tax property is best regarded as merely a type-level property, and the type classifications scenario should be chosen. What remains to be discussed is how to make sure one uses a proper name for the stereotype. In section 2.2 we suggested ≪soundStreamType≫ instead of ≪soundStream≫ as the name for a stereotype so that the intent is better reflected. We now provide a litmus test for determining whether a stereotype name is appropriate or not. Assuming that the correct kind of stereotype has already been determined, and has been called “S”, the question to ask is: Do I under any circumstance want instances to be understood as “S”instances? If the answer is yes, then the stereotype name is wrong. For example, if it is the case that OnLineGame instances ought to be regarded as “applet” instances

Stereotypical Encounters of the Third Kind

111

then “Applet” is a good candidate for an Applet superclass name, but not for the stereotype. Just as class names spell out what their instances (i.e., objects) are (e.g., applets) stereotype names ought to spell out what their instances (i.e., types) are (e.g., AppletType). A stereotype name does not necessarily need to have the “-type” suffix, though. A stereotype name ≪component≫ makes sense since types branded with this stereotype are particular components, whereas their instances are usually referred to as component instances. It cannot be overemphasized that if one wants instances to be regarded as “S”-instances then one is not really dealing with a proper stereotype name but with the name of an M1 -level supertype. What can be achieved by a stereotype ≪AppletType≫, however, is that classes like OnLineGame inherit from a superclass Applet. In this way—exploiting the terribly imprecise meaning of “is-a” [8]—not only an Applet is-an applet (is-a → instance-of) but Applet is-an applet (is-a → kind-of) as well, which seems to be the primary motivation for (incorrectly) using an ≪Applet≫ stereotype in such cases.

4

Notational Support

Having identified the primary stereotype usage models and discussed the heuristics that can be used to choose between them, we now discuss how the scenarios could be distinguished notationally. Modelers not only need a systematic way of obtaining the kind of stereotype most appropriately fitting the situation in hand, they also need a way to unambiguously document their decision. In the first subsection we discuss strategies for distinguishing them using the current version of the UML and then, in the following subsection, we discuss possible approaches that might be employed in future versions. 4.1

Current UML

Fig. 5 illustrates that, by considering class Video alone, it is not possible to deduce which of the two stereotype kinds was intended. We therefore propose slight notational enhancements to the current version of the UML so that all three kinds of stereotypes can be distinguished. Figure 8 depicts our suggestions for all three cases.

«commented» Worker {commenter = Bob}

Music

«persistent» Account {storageModes = XML}

(a) Type level

(b) Instance level

(c) Transitive case

Fig.8. Notational support

112

Colin Atkinson et al.

N ote the use of an adjectival stereotype name in Fig. 8(c). It is equally valid to think of both Account itself and an Account instance as supporting persistence. Also, note the underlined tagged values which indicate that this information is meant to be useful for the type level only. Whenever a tagged value needs to be visible to instances as well (as in “taxRate = 16%”) it should not be underlined. Note, however, that while underlining tagged values works for conveying intent, i.e., restricting the visibility of a class feature (e.g., commenter) to be visible to the class only as opposed to all of its instances as well, is not suitable to control whether a class feature (such as taxRate) shall be a part of an object’s feature list (as in Fig. 5(c)). In order to achieve the level of expressiveness to independently control visibility and feature extent it is best to assume a true multi-level modeling approach for UML modeling. 4.2

Advanced Support

In [12] it is suggested that the traditional two level (M1 and M0 ) modeling assumption be abandoned and UML modeling be based on a multi-level approach involving user metatypes in addition to user types and user instances. With the availability of a user modeling level above the normal M1 type level and in the presence of “deep instantiation” [12] it becomes almost trivial to control where the features involved in the scenario of Fig. 7 become visible and where not. Figure 9 illustrates how one can control the visibility of “taxRate”. In Fig. 9(a) “taxRate” is just an ordinary (meta-)attribute, giving rise to a slot at type Video only. This is analogous to a tagged definition/tagged value pair in the UML. In contrast, Fig. 9(b) specifies “taxRate” to be of potency two, i.e., makes it appear as an attribute (rather than a slot) at type Video. Therefore, this attribute gives rise to a corresponding slot at instance 2001. Note the underlining of “taxRate” in Fig. 9(b), meaning that “taxRate” is a so-called dual field rather than a simple field. In contrast to simple fields, dual fields may already be assigned a value before they become a slot. This allows the value of “16%” to already be assigned a value at the type level. Furthermore, we used “16%1 ” to indicate that this value is constant for the level below. Had we used “16%” instead, it would have meant that the type Video is associated with a tax rate of 16% but that any Video has a “taxRate” slot which may be assigned any individual value (analogue to the price slot). Such a multi-level modeling approach not only makes stereotyping and tagged values redundant as mechanisms in their own right4 but furthermore makes it trivial to control the scope of properties independently of the level where they are introduced. The modeler’s intent can be captured in a concise and intuitive manner without ever requiring constraints enforcing certain type facets to be present. 4

Notational shortcuts as presented in Fig. 8 are still valuable and should be made available.

Stereotypical Encounters of the Third Kind

113

ProductType ProductType

taxRate2 : Integer

taxRate : Integer «instanceOf» «instanceOf» Video Video taxRate = 16% price : Integer

taxRate1 = 16%1 price : Integer

«instanceOf» «instanceOf» 2001 2001 price = 9.95

(a) Tax as a type property

taxRate = 16% price = 9.95

(b) Tax as a transitive property

Fig.9. Choosing the desired tax scope

5

Conclusion

Thanks to their notational conciseness and convenience of use, stereotypes have earned a permanent place in the affections of UML users and have become an indispensable part of the UML’s extensibility mechanisms. However, as explained in this paper and many others, they are often deployed by users in ways that do not strictly conform to the UML standard and can therefore be ambiguous or misleading to readers of the model. Our goal in this paper has been to first identify and understand the different de facto ways in which stereotypes are used by UML modelers (whether they be “official” or “unofficial”) and then to consolidate practical guidelines for working out which scenario makes sense under which circumstances. We then elaborated on how the different stereotype usage scenarios could be distinguished notationally, both in terms of existing UML notation and in terms of possible future notations. We observed that a suitable interpretation of the UML standard would actually allow both type and instance classification usages for stereotypes but beyond that established that a simplistic reduction to two basic modes is insufficient. We identified that many real world scenarios are actually best thought of as combining these two forms so that they simultaneously classify the type as well as its instances. For this form of usage scenarios we introduce the term “transitive classification”. In fact, one of the possible reasons for the extensive debate on what stereotypes mean and how they should be used has been that the three forms have never hitherto been made fully explicit. It turns out that many examples of stereotype applications in the literature are best understood as transitive classification, rather than simply type (“official”) or instance (“unofficial”) classification. Since

114

Colin Atkinson et al.

transitive classification best matches the properties of many real-world situations, it will continue to be used in the future regardless of the intended “official” stereotype semantics and regardless of how well this case can be expressed with standard stereotypes. However, in the spirit of providing a language which is as expressive and accurate as possible we believe that it is important for future versions of the UML to take all three stereotype usage scenarios into account, and to provide users with explicit notation for specifying which scenario they are intending to use.

References [1] Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener. Responsibility-driven design: Adding to your conceptual toolkit. ROAD, 1(2):27–34, July–August 1994. 100, 104 [2] OMG. Unified Modeling Language Specification, 2000. Version 1.4, OMG document ad00-11-01. 101, 102 [3] Brian Henderson-Sellers. Notes on the use of subtypes and stereotypes in the UML metamodel. Journal of Database Management, 13(2):44–52, 2002. 101, 102 [4] Stefan Berner, Martin Glinz, and Stefan Joos. A classification of stereotypes for object-oriented modeling languages. In Robert France and Bernhard Rumpe, editors, Proceedings of the 22 International Conference on the Unified Modeling Language, LNCS 1723, pages 249–264, Berlin, October 1999. Springer Verlag. 103, 107 [5] Marcus Fontoura, Wolfgang Pree, and Bernhard Rumpe. The UML Profile for Framework Architectures. Addison-Wesley, 2002. 103 [6] Jim Conallen. Building Web Applications with UML. Addison-Wesley, Reading, MA, 2000. 103 [7] Colin Atkinson and Thomas K¨ uhne. Strict profiles: Why and how. In Andy Evans, Stuart Kent, and Bran Selic, editors, Proceedings of the 3rd International Conference on the UML 2000, York, UK, pages 309–323, LNCS 1939, October 2000. Springer Verlag. 104 [8] Colin Atkinson, Thomas K¨ uhne, and Brian Henderson-Sellers. To meta or not to meta – that is the question. Journal of Object-Oriented Programming, 13(8):32– 35, December 2000. 104, 111 [9] Stefan Sauer and Gregor Engels. UML-based behavior specification of interactive multimedia applications. In Proceedings of the IEEE Symposium on HumanCentric Computing Languages and Environments, pages 248–255. IEEE, September 2001. 105 [10] Bran Selic. Re: Ask about UML. email communication 10:15:56 -0400, September 2001. email to third author and others. 105 [11] Colin Atkinson and Thomas K¨ uhne. Meta-level independent modeling. In International Workshop Model Engineering (in Conjunction with ECOOP’2000). Cannes, France, June 2000. 108 [12] Colin Atkinson and Thomas K¨ uhne. The essence of multilevel metamodeling. In Martin Gogolla and Cris Kobryn, editors, Proceedings of the 4th International Conference on the UML 2000, Toronto, Canada, LNCS 2185, pages 19–33. Springer Verlag, October 2001. 112

Digging into Use Case Relationships Gonzalo Génova, Juan Llorens, and Víctor Quintana Computer Science Department, Carlos III University of Madrid Avda. Universidad 30, 28911 Leganés (Madrid), Spain {ggenova,llorens}@inf.uc3m.es, [email protected] http://www.inf.uc3m.es/

Abstract. Use case diagrams are one of the key concepts in the Unified Modeling Language, but their semantics and notation have some gaps that lead to frequent misunderstandings among practitioners, even about very basic questions. In this paper we address some issues regarding the relationships in which use cases may take part. The Include and Extend relationships between two use cases have presently an inconsistent definition, since they are represented as stereotyped dependencies, but they are not true dependencies in the metamodel. Besides, the direction of the dependency arrow in the Extend relationship can be misleading, unnatural and difficult to understand for the common practitioner. Finally, we show also some conceptual problems regarding the included or extending use cases, which in our opinion are not true use cases.

1

Introduction

There are two kinds of relationships in which use cases may take part in a use case diagram: relationships between two use cases, and relationships between a use case and an actor1. They are always binary relationships. There is something strange about relationships between two use cases, which are directed relationships from a source use case to a target use case. In the first versions of UML, up to version 1.1, they were modeled as stereotyped generalizations, named "uses" and "extends", following Jacobson’s original ideas [5]. After adoption by the OMG (Object Management Group) UML went through two revisions, and the old stereotyped «uses» and «extends» generalizations were quietly replaced in version 1.3 by the new stereotyped «include» and «extend» dependencies2, which have survived without change in version 1.4. Both the names and the semantics of the relationships were deliberately changed by the UML authors, but the whys and the hows were never widely explained to the general public [13, 15]. In fact, this change has introduced a conflict between the notation and the metamodel. The new relationships are graphically represented as stereotyped 1

A previous version of this paper contained a Section on the relationships between use cases and actors, but it had to be supressed due to space problems. 2 Whether they are dependencies, or not, is one of the main subjects of this paper. J.-M. Jézéquel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 115-127, 2002.  Springer-Verlag Berlin Heidelberg 2002

116

Gonzalo Génova et al.

dependencies but, as we will show, they are not true dependencies in the metamodel, but direct subclasses of the Relationship metaclass. This is in itself a source of confusion about the true nature of these relationships. What kind of relationships are really «include» and «extend»? Should the metamodel or the notation prevail, or neither? There are other common misunderstandings about use case models that are induced by a lack of definition and a misleading notation in use case relationships. Even though some authors suggest that use case relationships should be confirmed as usage-dependencies [7], we think that dependency in itself is not a clear concept, used in UML rather as a supertype for everything that is neither generalization nor association [UML 2-33]. Practitioners very often complain about the perplexing direction of the «extend» dependency. Besides, we have observed a general tendency towards misinterpreting use case dependencies as control flow relationships between processes, leading to a confusion between use case diagrams and activity diagrams. Our rather drastic proposal is to avoid at all the decomposition of use cases by means of use case relationships, allowing only self-contained use cases that are directly connected with actors. The remainder of this paper is organized as follows. Section 2 explains in detail the conflict between notation and metamodel for use case relationships in the current version of UML. Section 3 examines the directionality of use case relationships, exposing some conceptual problems about the nature of these relationships. Finally, Section 4 proceeds by showing the risks of use case relationships for a correct understanding of a use case model. Since this is a conceptual research about the nature of use case relationships and their official definition, our main source has been The OMG Unified Modeling Language Specification [9], more briefly referred to as "The Standard". This document is properly the only one which is truly "official", but there are many semantic questions that are poorly explained in it, so that we have turned to the works of the original authors of the UML in search for a clarification: The Unified Modeling Language Reference Manual [12], which seemed an obvious choice, and The Unified Modeling Language User Guide [2]3. On the other side, we cite the User Guide not because we consider it a particularly reliable source, but because it is probably the main source for many modelers, so that we think it is important to show its virtues and deficiencies. We quote version 1.4 of the Standard, and we have checked that there have been no significant changes from version 1.3 regarding these topics.

2

A Misleading Notation for Use Case Relationships

2.1

In UML Version 1.1

In UML (up to version 1.1 [10, 11], before adoption by the OMG) there were two kinds of relationships between use cases: "extends" and "uses". They were both 3

In the remaining of this paper, these three references will be cited as "UML" for the UML Specification, "RM" for the UML Reference Manual, and "UG" for the UML User Guide, followed by page numbers.

Digging into Use Case Relationships

117

represented by generalization arrows, respectively labeled with the stereotypes «extends» or «uses» (see Figure 1). The metamodel for use cases (see Figure 2) was not very developed in version 1.1, so that these two relationships had not any prominent place in it: there didn’t exist any special metaclasses for them. Therefore, we must conclude that they were true stereotyped generalizations, available to the UseCase metaclass because it is a subclass of Classifier, which is a subclass of GeneralizableElement. The third wellformedness rule for use cases imposed that these were the only relationships allowed between use cases [10] (p. 92). 2.2

In UML Version 1.4

Because of the conceptual problems caused by the definition of relationships between use cases as generalizations, and the fact that developers completely disregarded the generalization semantics in the way they employed them [13, 14], UML later abandoned this approach in version 1.3 in favor of a more plausible definition, based on a notion of dependency which has survived without change in version 1.4. Nevertheless, this definition has not been made at all clear in the current version, as we are going to show: use case relationships are shown as dependencies, but they are not true dependencies. Place Order

« extends»

extension points additional requests

« uses»

« uses»

« uses»

Supply Customer Data

Order Product

Request Catalog

Arrange Payment

Fig. 1. An example of use case relationships as stereotyped generalizations, extracted from UML Notation v1.1 [11] (p. 79)

realization

* Classifier (From Core)

1..* classifier

*

Instance (From Common Behavior)

specification *

Actor

UseCase extensionPoint: list of String

UseCaseInstance

Fig. 2. Metamodel of use cases, extracted from UML Semantics v1.1 [10] (p. 90)

118

Gonzalo Génova et al.

The former «uses» and «extends» stereotyped generalizations have supposedly evolved into «include» and «extend» stereotyped dependencies, whereas a new plain generalization is also allowed. In Figure 3 we can see the equivalent of Figure 1 in the new notation. Solid lines with hollow arrowheads (generalization) have been substituted by dashed lines with open arrowheads (dependency). Indeed, this notation states that we are dealing now with some kind of dependency, as we were dealing before with some kind of inheritance. The User Guide defines these use case relationships as stereotypes of dependencies [UG 227, 228]. The Reference Manual also says that "an extend relationship is a kind of dependency" [RM 490], that an include relationship "is a dependency, not a generalization" [RM 491], and that "an extend relationship or an include relationship is shown by a dependency arrow" [RM 493]. Everything seems clear. What is the problem, then? Let’s have a closer look at the definitions in the Standard. Remarkably, the description of the notation for these two relationships carefully avoids either the word "dependency" or defining them as dependencies [UML 3-98]: ! "An extend relationship between use cases is shown by a dashed arrow with an open arrow-head from the use case providing the extension to the base use case. The arrow is labeled with the keyword «extend»." ! "An include relationship between use cases is shown by a dashed arrow with an open arrow-head from the base use case to the included use case. The arrow is labeled with the keyword «include»."

Supply Customer Data

Order Product

« include»

« include»

Arrange Payment

« include»

Place Order Extension Points 1 Salesperson

*

additional requests : after creation of the order

« extend» the salesperson asks for the catalog

Request Catalog

Fig. 3. An example of use case relationships as stereotyped dependencies, extracted from UML Specification v1.4, p. 3-99. Compare with Figure 1. We have respected the original layouts in both diagrams, even though they are upside down and this could mislead the eye of the reader. Notice the differences in the descriptions of extensions and in the addition of an actor to the diagram

Digging into Use Case Relationships

1..* Classifier (From Core)

*

classifier

Instance (From Common Behavior)

UseCaseInstance

1

UseCase

Actor addition 1

1 base

* extensionPoint

extension 1

119

ModelElement (From Core)

ExtensionPoint location: LocationReference 1..*

1 base

extensionPoint {ordered}

*

* include

extend *

*

Extend * condition: BooleanExpression

Include

Relationship (From Core)

Fig. 4. Metamodel of use cases, extracted from UML Specification v1.4, p. 2-135

ModelElement

Flow

Generalization

Relationship

Association

Binding

Dependency

Abstraction

Usage

Include

Extend

Permission

Fig. 5. The Relationship metaclass and its subtypes, extracted from UML Specification v1.4, pp. 2-14, 2-15, 2-135

A similar caution is not observed when describing the other possible relationship between use cases plainly as a generalization [UML 3-98]. These remarks could be disdained as non-significant subtleties, and a pragmatic position could be assumed: "they are represented as dependencies, so they are

120

Gonzalo Génova et al.

dependencies", but the point is that the metamodel itself does not define the use case relationships as dependencies. In fact, the metaclasses Extend and Include are direct subtypes of the metaclass Relationship (see Figure 4 and compare with Figure 2). The Relationship metaclass did not yet exist in v1.1, it was introduced later as a supertype of all kinds of relationships (Flow, Generalization, Association, Dependency, etc.). The Dependency metaclass has its own subtypes; Include and Extend are not subtypes of Dependency, but direct subtypes of Relationship (see Figure 5). Aside from the graphical presentation of the metamodel, the Standard does not say that Include and Extend are dependencies, neither in the Abstract Syntax section [UML 2-136, 2-137], nor in the Detailed Semantics section [UML 2-143, 2-144], and the list of kinds of Dependency does not include them [UML 2-33, 3-91]. A stereotype is used in UML to extend the language with new modeling elements, which are derived from existing ones [UML 2-78] [8]. Predefined stereotypes are equivalent to subclasses in the metamodel [16] that inherit, among others, the notation of the parent class. For example, a «use» dependency in a model is possible because Usage is a subclass of Dependency in the metamodel, and it is represented with the same notation, a dashed arrow with open arrowhead, adding the stereotype’s keyword. In the case of Include and Extend, they are direct subtypes of Relationship, but they use the notation of Dependency instead, creating a conflict. From this scrutiny we can conclude that: ! According to the Standard, Include and Extend are intentionally not dependencies, but relationships on their own (direct subtypes of Relationship). ! The Standard is contradicted by the User Guide and the Reference Manual, where Include and Extend are defined as stereotyped dependencies. ! The Standard proposes a misleading notation, since it represents Include and Extend graphically as stereotyped dependencies; this is in itself a source of confusion. This conflict could be easily solved by changing the metamodel and making Include and Extend subtypes of Dependency. But, before taking this step, the true nature and convenience of these relationships must be enlightened. Besides, if Include and Extend are finally not dependencies, then the direction of the arrow should be established with a criterion that is not that of a dependency.

3

A Misleading Direction of Dependency in the Extend Relationship

Include and Extend are said to be directed relationships [UML 2-136, 2-137], which is conveniently represented by an arrowhead on the corresponding end of the relationship. "The include relationship points at the use case to be included; the extend relationship points at the use case to be extended" [RM 66]. In other words, UML tells us to draw the arrow from the base to the inclusion (or addition, in terms of the metamodel, see Figure 4), and from the extension to the base (see Figure 7). Thus, in the «extend» relationship, the base of the relationship is not the base of the arrow.

Digging into Use Case Relationships

121

Perhaps not surprisingly, most people think intuitively that the «extend» arrow should go the same way round as the «include» arrow [17], that is, both arrows should point from the base case towards the inclusion or the extension. This is probably due to a poor understanding of the difference between these relationships by practitioners, a problem which has been denounced long ago, and about which even the experts disagree [4]. This difficulty is not completely solved by assuming that Include means reuse while Extend means insertion, or alternative, or exception, since these concepts are not that clearly independent: if B is reused by A, then in some way B is being inserted into A; if C is inserted into A, or is an alternative to A, or an exception, then in some way C is being reused by A (or, at least, "used"). We understand practitioners when they find difficulties in deciding whether they should use Include or Extend in their models. The difference between Include and Extend is understood by some authors as conditional versus unconditional insertion: a use case is inserted into another use case, in analogy with subroutine call semantics [1, 7]. In this way, the inserted use case is easily seen as an independent reusable, encapsulated module, while the base use case in which the insertion is made is seen as dependent on the insertion. With this notion in mind, practitioners are perplexed when they are told that they must draw the «extend» arrow in reverse direction: they do not see a true dependency in it. As a rule of thumb, one can think that the arrow goes from the "grammatical subject" to the "grammatical object" of the corresponding verb "include" or "extend". For example, in Figure 3 the Request Catalog use case extends the Place Order use case, which in turn includes the Order Product use case. But this "grammatical rule" that helps in drawing the arrows does not seem adequate to understand the true underlying dependencies between use cases. In fact, the same authors mentioned above [1, 7] think that there is not any fundamental difference between the Include and Extend relationships: they would be semantically equivalent. Extend would be considered "if (condition) then ...", whereas Include would be considered "if (TRUE) then ..." [7]; this would be consistent with the original idea of an extension being a guarded block of functionality that could be inserted into a main use case upon fulfillment of a certain condition [13], although Jacobson viewed the extensions as interrupts rather than branches [5]. If they were truly equivalent, both relationships could be collapsed into a single relationship analogous to what the OPEN/OML approach calls the "invokes" relationship [3], and of course they should be drawn in the same direction. addition B

base « include»

A base

« extend»

C

extension

Fig. 7. Include and Extend relationship arrows confronted with the underlying metamodel

122

Gonzalo Génova et al.

In order to establish the rightness of this approach, the true dependencies underlying Include and Extend must be exposed, which will lead to a better understanding of these relationships, their similarities, and their differences. ! Include. According to the Reference Manual, "the base use case can see the inclusion and can depend on the effects of performing the inclusion, but neither the base nor the inclusion may access each other’s attributes" [RM 297]. This indicates a dependency from the base to the inclusion, as the arrow accordingly states4. ! Extend. On the other side, "an extension use case in an extend relationship may access or modify attributes defined by the base use case. The base use case, however, cannot see the extensions and may not access their attributes or operations. The base use case defines a modular framework into which extensions can be added, but the base does not have visibility of the extensions" [RM 273]. That is, the base use case defines the extension points in which it would accept extensions, but it knows nothing more about these extensions. This indicates a dependency from the extension to the base, as the UML authors advocate. In consequence with these definitions, the dependencies seem to be rightly expressed in UML: the base use case sees the inclusion and is seen by the extension. We can compare Include to a go-to instruction (Place Order performs a go-to Order Product), whereas Extend is to be compared rather with a come-from instruction (Request Catalog performs a come-from Place Order). Even if we accepted that the dependencies are right, the whole scheme is rather unnatural and difficult to understand for the common practitioner. Nevertheless, in the Extend dependency the base use case must define the extension points, which makes it not completely independent of the extending use cases. In addition, other authors [13, 14] think that making the variant or exceptional behavior depend on the normal behavior is not a logical dependency, but an artifact of the order followed in the analysis procedure (first write the normal cases, then write the extensions on separate sheets and state where in the normal cases they should be inserted): this is like saying that all branches of a multi-branch statement depend logically on one distinguished branch. In this view the «extend» arrow points in the wrong direction (from the extensions to the base) but the right direction would not be the reverse one (from the base to the extensions). Instead, a radically different scheme must be followed: from a superordinate selection node to the base and all the extensions equally. Unfortunately, this scheme is adequate for modeling alternatives, but it is less adequate for insertions, and it is not adequate for exceptions. Strangely, the current version of the metamodel does not provide an InclusionPoint metaclass for the Include relationship, to represent the place where the inclusion takes 4

Unfortunately, some lines below in the same page, we read: "The inclusion use case may access attributes or operations of the base use case", which contradicts the previous statement and would induce a dependency from the inclusion to the base. We think this is a weird error in the text, since it prevents the desired encapsulation and reuse semantics, as stated right after: "The inclusion represents encapsulated behavior that potentially can be reused in multiple base use cases".

Digging into Use Case Relationships

123

place, equivalent to the ExtensionPoint for the Extend relationship (see Figure 4), even though this is a natural concept and it is even mentioned in the Reference Manual [RM 297, 491]. There is another more fundamental difference between the inclusion and the extension that prevents a true equivalence among them. In the «include» relationship, the included use case is inserted at one location in the base use case and represents encapsulated behavior [UML 2-143]; it follows a subroutine call semantics [6]. Conversely, in an «extend» relationship, upon fulfillment of a single condition, the different fragments of behavior defined in the extension are inserted simultaneously and coordinatedly at different locations in the base use case [UML 2144]; therefore, it follows interleaving semantics [6], and consequently the extension does not define any encapsulated behavior. The problems of interleaving semantics have already been exposed [6]: interleaving violates encapsulation and other fundamental principles of object-orientation, a fault that should be more than enough to discard interleaving and promote subroutine call semantics (that is, encapsulation) also for extend relationships. In the kingdom of encapsulation, interleaving semantics is not easy to understand.

4

The Risks of Use Case Relationships

A use case execution is commonly considered a use case instance [5, 6, 13, 14], that is, "the performance of a sequence of actions specified in a use case" [UML 2-138]. In earlier works on use cases [5], inclusions and extensions were called "abstract" use cases, because they were not instantiable (that is, they were not full and independent external software services), in contrast with "concrete" use cases, which were directly connected with actors and represented a complete service offered to an actor. That is, when an actor requires a service from a concrete use case that has an abstract use case included in it or extending it, there is only one running instance, that of the concrete use case. The concrete use case completes its description with that of the included or extending abstract use case; this "usage dependency" exists only at the classifier level, there isn’t any relationship between use case instances. The term "abstract use case" is reminiscent of the time in which use case relationships were stereotyped generalizations, and it has been abandoned in the current version of UML5. Therefore, in order to avoid this term, which is particularly misleading, we are going to use the terms "primary use case" and "secondary use case". Primary use cases are directly connected to actors, whereas secondary use cases are inclusions and extensions. In this section we are going to challenge the notion of "use case relationship". The noble intention behind inclusions and extensions is removing redundancy from the documentation: "Organizing your use cases by extracting common behavior (through include relationships) and distinguishing variants (through extend relationships) is an 5

That is, the term "abstract use case" does not mean any more an included or extending use case. Of course, since use cases are classifiers, there may exist "abstract" use cases in the general sense applied to any classifier, but these abstract use cases must not be confounded with included or extending use cases. A true abstract use case would be indirectly instantiable via its subclasses, but this is not the pretended meaning for inclusions or extensions.

124

Gonzalo Génova et al.

important part of creating a simple, balanced, and understandable set of use cases for your system" [UG 228]. However, this intention fails due to several reasons. First of all, secondary use cases are not true use cases. Let's have a look at some definitions. A use case is "a description of a set of sequences of actions, including variants, that a system performs to yield an observable result of value to an actor" [UG 222], "the specification of sequences of actions, including variant sequences and error sequences, that a system, subsystem, or class can perform by interacting with outside actors" [RM 488]. "Each use case specifies a service the entity provides to its users; that is, a specific way of using the entity. The service, which is initiated by a user, is a complete sequence" [UML 2-141]. "A pragmatic rule of use when defining use cases is that each use case should yield some kind of observable result of value to (at least) one of its actors. This ensures that the use cases are complete specifications and not just fragments" [UML 2-145]. Let's see why these definitions are not satisfied by "secondary use cases": ! Included use case. Its purpose is to factor out and reuse common behavior among use cases. As a description of encapsulated behavior [UML 2-143], it could be designed to be a complete sequence that yields an observable result to the actor. However, it is more probable that it is an incomplete sequence that yields only a partial result, more easily reused by several primary use cases: "A use case can simply incorporate the behavior of other use cases as fragments of its own behavior. This is called an include relationship" [RM 66]. It is not that easy that a fragment of behavior can be at the same time a complete behavior. Typically, an included use case is not directly connected to an actor, but only indirectly through a primary use case6. An included use case does not interact with the actor, it does not specify a full service (a complete sequence of interactions), and it does not yield an observable result, therefore it is not a true use case. ! Extending use case. Its purpose is to distinguish variant behavior from the primary use case. Originally, the extend relationship was intended to represent insertions as well as alternatives and exceptions, but it has been shown that insertion semantics is inadequate to model exceptions and alternatives [13, 14]. In addition to the arguments given for the included use case, which are valid here too, an extending use case may contain different fragments of behavior to be inserted into different locations (interleaving semantics), what makes it even harder to consider the extending use case as an independent external service. Summing up, secondary use cases are not true use cases simply because they do not specify a service that a system gives to an actor. If, having observed "commonalities between use cases" [UML 2-143] or variant behaviors, we want to 6

However, the Reference Manual contains an example [RM 27] of an included use case "make charges" that is simultaneously connected to an actor "credit card service", that is, a use case that is both primary and secondary, being therefore instantiable and non-instantiable at the same time. We doubt that this example is realistic. We think rather that this actor should be connected to a different primary use case, which would include the "make charges" secondary use case.

Digging into Use Case Relationships

125

organize and simplify the set of use cases, a different concept must be defined in the metamodel, such as "common functionality" or "variant functionality"; otherwise, the definition of "use case" as "a coherent unit of functionality" [UML 3-96] must be changed to admit services or functions that are incomplete or that are not directly related to the actors. Finally, the representation of secondary use cases in a model, or "common functionalities", has other, maybe worse, risks. In our opinion, the use of dependencylike use case relationships and, consequently, use cases that are not complete and selfcontained, convey a dangerous twist towards the expression of sequential processing, or flow of control, in a use case diagram. We think that the goal of use cases is to express self-contained functionality, without expressing any sequence between those functionalities. Otherwise, these functionalities become processes that invoke one another. We have observed this phenomenon in many practitioners: they fail to understand a use case diagram because they see rather an activity diagram, or a process decomposition diagram.

5

Conclusions

In our experience in using and teaching UML we have learned that, against what it would seem at first sight, it is not that easy to represent a system's functionality by means of use case diagrams. There are some very basic questions about the meaning of the symbols in the diagram that do not have an easy answer, such as what is the meaning of a use case that is not directly connected to an actor, what is the meaning of the arrows between use cases, why is the arrow for the Extend relationship "in the reverse" direction, and so on. After the last revisions of UML (currently 1.4), use case relationships have been put in an inconsistent state: they have the notation of stereotyped dependencies, but the semantics defined in the metamodel is not that of a dependency. It seems that a simple change in the metamodel would amend this contradiction, but before taking this step the true nature and convenience of use case relationships must be examined. The direction of the dependency in the Extend relationship is misleading. Even if it were shown to be correct, it is nevertheless unnatural and difficult to understand for the common practitioner. Some authors propose a fundamental equivalence between Extend and Include, understood as conditional versus unconditional insertion. But this cannot be true in the present state of the language, since Extend's direction is opposite to Include's, and more fundamentaly because of the interleaving semantics of the Extend relationship. An InclusionPoint metaclass should be added to the metamodel to complete the equivalence, too. Moreover, we have challenged the utility of these relationships. We have shown that included or extending use cases are not true use cases, because they are not complete and coherent units of functionality that yield an observable result to the actor. Besides, there is a danger to take the intended dependencies for control-flow relationships, leading to the confusion between use case diagrams and activity diagrams.

126

Gonzalo Génova et al.

Acknowledgements The authors would like to give thanks to Anthony Simons and especially to Pierre Metz for the interesting personal communications that have served as food for thought in conceiving and writing this paper. The anonymous reviewers have also provided valuable ideas and suggestions.

References 1.

2. 3. 4.

5. 6.

7. 8. 9. 10. 11. 12. 13.

14.

Klaas van der Berg, Anthony J.H. Simons. "Control-Flow Semantics of Use Cases in UML". Information and Software Technology, 41(10):651-659, July 1999. Grady Booch, James Rumbaugh, Ivar Jacobson. The Unified Modeling Language User Guide. Addison-Wesley, 1998. Donald Firesmith, Brian Henderson-Sellers, Ian Graham. The OPEN Modeling Language (OML) Reference Manual. Cambridge University Press, 1998. Martin Fowler, Alistair Cockburn, Ivan Jacobson, Bruce Anderson, Ian Graham. "Question Time! Abount Use Cases", Proceeding of the 13th ACM Conference on Object-Oriented Programming, Systems, Languages and ApplicationsOOPSLA'98, October 18-22, 1998, Vancouver, British Columbia, Canada. ACM SIGPLAN Notices, 33(10):226-229. Ivar Jacobson, M. Christerson, P. Jonsson, G. Övergaard, Object-Oriented Software Engineering: a Use Case Driven Approach, Addison Wesley, 1992. Pierre Metz. "Against Use Case Interleaving", The Fourth International Conference on the Unified Modeling Language-UML'2001, October 1-5, 2001, Toronto, Ontario, Canada. Springer Verlag, Lecture Notes in Computer Science 2185, pp. 472-486. Pierre Metz. Personal communications to the authors, October 28th and December 16th, 2001. Joaquin Miller. Post to the Precise UML Group Mailing List (http://www.cs.york.ac.uk/puml/), January 12th, 2002. Object Management Group. Unified Modeling Language Specification, Version 1.4, September 2001 (Version 1.3, June 1999). Rational Software Corporation, Unified Modeling Language Semantics, Version 1.1, September 1997. Rational Software Corporation, Unified Modeling Language Notation Guide, Version 1.1, September 1997. James Rumbaugh, Ivar Jacobson, Grady Booch. The Unified Modeling Language Reference Manual. Addison-Wesley, 1998. Anthony J. H. Simons. "Use cases considered harmful", Proceedings of the 29th Conference on Technology of Object-Oriented Languages and Systems-TOOLS Europe'99, June 7-10, 1999, Nancy, France. IEEE Computer Society Press, 1999, pp. 194-203. Anthony J. H. Simons, Ian Graham: "30 Things that go wrong in object modelling with UML 1.3", chapter 17 in Kilov, H., Rumpe, B., Simmonds, I. (eds.): Behavioral Specifications of Businesses and Systems. Kluwer Academic Publishers, 1999, 237-257.

Digging into Use Case Relationships

127

15. Anthony J. H. Simons. Personal communication to the authors, December 5th, 2001. 16. Anthony J. H. Simons. Post to the Precise UML Group Mailing List (http://www.cs.york.ac.uk/puml/), January 31st, 2002. 17. Perdita Stevens, Rob Pooley. Using UML: Software Engineering with Objects and Components. Addison-Wesley, 2000.

Practical Experiences in the Application of MDA Miguel de Miguel2, Jean Jourdan1, and Serge Salicki1 1 Thales-TRT Domaine de Corbeville 91404 Orsay, France {Jean.Jourdan,Serge.Salicki}@thalesgroup.com 2 E.T.S.I. Telecomaunicación, Ciudad Universitaria 28040 Madrid Spain [email protected]

Abstract. During the last ten years a lot of concepts have emerged from software engineering. Most of them try to formalize and organize software engineering knowledge at a higher level of abstraction, giving code a secondary role. Model Driven Architecture (MDA), putting the concept of the model on the critical path of software development, is about to change this situation, turning the role of models from contemplative to productive. This paper introduces some problems detected in the process of adoption of MDA methods. The application of MDA for a specific domain, technique, or technology requires the Description of Specialized Modeling Language. Two main techniques provide support for the description of UML extensions, MOF meta-models and UML profiles. The Process of Mapping Description requires good support to identify the elements of the source modeling language that are mapped and the model elements of the destination modeling language that correspond to the source elements. This process require specific solutions.

1

Introduction

During the last ten years a lot of concepts have emerged from software engineering. Most of them try to formalize and organize software engineering knowledge at a higher level of abstraction, giving code a secondary role. Among others, the concept of software architecture, architectural patterns, design patterns, idioms appear to formally and explicitly support the different knowledge of development know-how. They are mostly used as guidelines and guidebook to help the development of new applications. MDA [2], putting the concept of model on the critical path of the software development, is about to change this situation, turning the role of models from contemplative to productive. The goal of model driven engineering is to define a full life cycle method based on the use of various models automating a seamless process from analysis to code generation. This discipline puts in the right place all the software artifacts (e.g. business models, architectural models and design patterns) and uses them actively in order to produce and deploy an application. J.-M. Jézéquel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 128-139, 2002.  Springer-Verlag Berlin Heidelberg 2002

Practical Experiences in the Application of MDA

129

MDA pays special attention to the separation of technology dependent concepts from independent concepts. This solution limits the problems of platform dependencies and portability of the software. The separation is supported at model level to avoid platform dependencies in all phases of the life cycle. The Platform-Independent Model (PIM) to Platform-Specific Model (PSM) mappings provide support to reduce the cost of adaptation of the subsystems to different platforms. Sometimes the allocation of subsystems in a specific platform cannot be decided in early phases, and this mapping reduces the problems of reallocation of subsystems in other platforms. During last year, middleware platforms (i.e. CORBA, DCOM, and Java RMI), component platforms (i.e. CCM, EJB, and .NET) and object-oriented programming languages have appeared and none of them prevails over the others. MDA proposes solutions to automate the software development process. The main objective is the reduction of the time to market based on tool support for the refinement of models and code generation. This approach reduces development errors because it reduces the manual development process and provides support to reuse the best-known solutions. In this development process, the tools can provide support for the integration of different software development phases based on the transformation of models of different phases. The tool support provides a constructive method based on models with the combination of concerns at modeling level. Models provide support for different types of problems: i) description of concepts, ii) validation of these concepts based on checking and analysis techniques, iii) transformation of models and generation of code, configurations, and documentation. Separation of concerns avoids confusion because of the combination of different types of concepts. MDA introduces solutions for the specialization of the models for specific concerns and for the interconnection of concerns based on models. This approach reduces the complexity of models by the specialization of modeling activities. It improves communication between stakeholders using the models to support the interchange of information. This paper introduces some problems detected in the process of adoption of MDA methods. During last years, Thales has started some actions for the adoption of model driven engineering techniques. Two pilot programs have UML and modeling engineering as main references in the software development process. These pilot programs include the application and evaluation of these techniques in four real projects, and other actions develop supports for the adoption of these techniques and for their practical application in the near future. The real projects use current solutions for the transformation of models and code generation and evaluate the cost of their application. And the innovation actions include the development of UML extensions to support specific domains modeling languages, techniques, and technologies, and the models transformations [25]. This paper presents the results of the evaluation of current solutions for the application of MDA solutions, and the subjects that we have identified as critical in their adoption. The rest of this paper introduces some related work (Section 2). Section 3 describes basic concepts of MDA. Sections 4 and 5 present some problems and solutions for the adoption of MDA, and Section 6 presents some conclusions.

130

Miguel de Miguel et al.

2

Related Work

In March 2001, the Platform and Domain Technical Committees of OMG endorsed MDA [22][21][6]. [2] defines a model as "a formal specification of the function, structure, and/or behavior of a system." Within the MDA, an interface standard – for example, a standard for the interface to a manufacturing execution system – would include a PIM and at least one PSM. The PIM captures the conceptual design of the standard, untainted by the special features or limitations of a particular software technology. Some of the motivations of the MDA approach: i) reduce the time of adoption of new platforms and middleware, ii) primacy of conceptual design, and iii) interoperability. The MDA approach makes it possible to save the conceptual design, and the MDA helps to avoid duplication of effort and other needless waste [7][19]. The MOF (Meta-Object Facility)[12] modeling stack, the model transformation process based on meta-model specifications and model serialization is a solution for the support of model-based development process [3]. The transformation of the UML model is specified by a set of rules defined in terms of the corresponding metamodels. Nordmoen in [11] introduces the application of Model Driven Development by applying formal models on all levels of system-analysis, which are reused at different levels of abstraction. This makes it easier to remodel a system to fit changes in business needs. They separate platform independent concepts from specific concepts and improve the potential for faster development by supporting code generation and communication middleware independence. Some approach proposes a language for object-oriented modeling [4]. The language provides support to describe well-structured modeling languages and integrates the semantic of OCL. USE is a tool for the validation of UML models and OCL constraints [20]. But in this approach, the validation of constraints is supported by the execution of models. Some tool providers [23][9][10] propose different solutions for the adoption of MDA. Each solution proposes specific solutions for the implementation of model transformations (i.e. JPython, Action Semantic [17] and J languages), and different solutions for the specification of modeling elements of transformation processes (i.e. proprietary modeling languages, meta-models and UML profiles).

3

MDA Overview

MDA provides a solution for the software development process based on models. The models can be looked at from different points of view (e.g. problem domains, architectural solutions), studied for different purposes (e.g. analysis of problems, evaluation of architectural solutions), and their evolution and transformation can address different objectives (e.g. integration of technical concepts, transformations between different programming language domains). UML is the modeling language reference of MDA, but it is a general purpose modeling language that must be extended and adapted for specific purposes.

Practical Experiences in the Application of MDA

131

Fig. 1. MDA basic concepts

Figure 1 introduces the most important concepts of MDA technology. PIM concepts are based on three different types of UML modeling points of view: i) Domain Modeling, ii) Architectural Modeling, and iii) Technical modeling based on specific types of services. These types of models pay attention to some specific concepts and provide extensions and specializations of UML to support these concepts. PSM models are based on technological models that provide support to model in UML platform specific concepts. The specific PSM modeling notations are based on semantics and concepts of execution infrastructures. Mapping facilities provide the support for the transformation of models, and they support the evolution of models.

3.1

MDA Models and Viewpoints

MDA identifies three main areas of UML meta-model extension and specialization: 1.

2.

Domain extensions. Examples of domains for the application of UML modeling are: telecom, e-commerce and healthcare. These domains use specific modeling structures and methods and require specialized modeling elements to improve description domain dependent concepts. Technical and architectural extensions. Some common techniques are used in different domains. Some examples are: real-time, fault-tolerance, transactions and security. These techniques require UML extensions to represent technical concepts not supported in UML (e.g., specific temporal properties [15] and complex

132

3.

4

Miguel de Miguel et al.

identification methods). The technical concepts have associated specific types of architectural concepts (i.e., distributed executions [13]). Technological extensions. These extensions provide support to express in UML specific programming language and middleware concepts. Some examples are the profiles to express in UML, EJB [24] and CORBA [14] concepts.

Implications in the Adoption of MDA

The application of MDA requires the description of domain, technical and technological modeling extensions, and the specification of mappings between modeling extensions. 4.1

Description of Specialized Modeling Languages

The definition of new UML extensions can be a complex process for two main reasons: we must explicitly state the extension concepts and their specific properties, and we must identify what the relations are between these concepts and UML meta-model elements. In general, the concepts of domain and technical extensions are well known in these environments but do not have a precise specification. Technological extensions (e.g., middleware and programming languages) have a formal specification in terms of grammar, but the integration of their detailed concepts in UML notations is a complex process. Two main techniques provide support for the description of UML extensions: •

MOF meta-models. The definition of a new extension based on MOF requires: i) the definition of the extension meta-model based on MOF meta-meta-model notations (static diagrams and well-formed OCL rules), ii) the definition of the subset of UML meta-model (which may be the entire UML meta-model), where we will apply the extensions, iii) then we must integrate the extension meta-model with the UML meta-model. The integration defines the relations (e.g., associations and inheritances) between extensions meta-classes and UML meta-classes, and iv) definition of new well-formed rules in OCL related with the new relations and the combination of both meta-models. The result is a new meta-model that includes and integrates both meta-models. Some infrastructures for the adoption of this approach include: i) capabilities for the definition of meta-model (tool support for the specification of MOF models), ii) specification and evaluation of well-formed rules (the validation of meta-model constraints), and iii) extension of UML meta-model (the new metamodels include associations with UML meta-model elements).

Practical Experiences in the Application of MDA

133

Fig. 2. Extension based on meta-models

•

UML profiles. An extension based on profiles requires: i) the definition of the extension meta-model, when the extension concepts do not have a formal definition (in general, domain and technical extensions). This meta-model, like in the previous case, will provide the reference of the extension concepts. When the extension is based on a formal defined terminology (e.g., the subset of a programming language specification or middleware standard), we must specify the subset of the extension space. ii) The definition of the subset of UML meta-model (which may be the entire UML meta-model), where we will apply the extensions, iii) the specification of UML extension elements (stereotypes, tagged values and types of constraints) that will support the extension meta-model, iv) for each stereotype and tagged values or constraints not associated with stereotypes, we must define the UML meta-model elements that can have associations with these extension elements. And v) the definition of the well-formed rules for the UML elements that can have the extension elements associated. The result is an UML profile that provides support to extend UML models with standard extension techniques. Some tools provide profile support based on profile builders, and facilities to reuse the profiles in the construction of new profiles.

Both extension techniques have advantages and disadvantages. MOF metametamodel language provides considerable support for the description of relations (i.e., associations and generalizations) and conceptual elements (i.e., classifiers, features and packets). UML extension mechanisms are limited to stereotypes, tagged values and constraints and their relations are limited to stereotype inheritance and aggregation of tagged values in stereotypes. Because MOF meta-metamodel language includes different types of relations, these relations can be used in the combination of

134

Miguel de Miguel et al.

two meta-models (i.e., inheritances and associations). The integration of UML extension mechanisms is based on the association between UML meta-classes and the new stereotypes and tagged values, this does not allow describing new associations and inheritances in UML meta-classes. Currently, in general, UML tools provide the support of UML extension mechanisms (stereotypes, tagged values, and constraints). New extension based on them can be integrated rapidly in these tools. OMG and other organizations have developed some UML profile standards and some standards are in progress. The standardization of general extensions is required to make the models tool independent and to interchange models among different tools. Sometimes we require applying different extensions to the same business model. Two different profiles can be applied to the same model. But the application of two MOF meta-models require their combination to create a third meta-model, and then the integration of this with UML meta-model.

Fig. 3. Extension based on profiles

4.2

Description of Model Transformations and Mappings

The methods for the description of modeling languages and extensions are a basic support for the description of model mappings and their semantic. The mappings provide the support for the MDA model-based development process. Supports for the mapping description identify the elements of the source modeling language that are mapped and the equivalent of destination, and the guards that the model must fulfill to apply this type of transformation. Currently the mapping process is put into practice in different ways:

Practical Experiences in the Application of MDA

1.

2.

3.

135

Script languages. Some UML tools include imperative script languages with meta-model navigation facilities similar to OCL navigation expressions. These languages are the support to implement the mapping scripts. These languages are flexible but often are tool dependent, and a mapping implementation is not portable. Some tools provide support to process and generate XML and XMI files. These files include the meta-data of UML models and mapping is supported by transformation of XMI files. The mapping is independent of the UML tool. Some tools include MOF transformation facilities based on rules. These rules provide facilities to identify the elements in the source model, where we apply the rule and the destination elements that we generate with the rule.

Some infrastructures include facilities for the automatic generation of new models, these facilities include the creation new modeling elements and diagrams and their integration in the repository. MDA requires model transformation, which is a basic tool for the evolution, specific analysis, and connection with implementation platforms of models. Two main concepts are involved in model transformation: the source and destination modeling languages and the mapping between languages. UML transformations are used for three general purposes: 1.

2.

3.

UML Model transformations and refinements. MDA proposes the refinement and transformation of models as a basic technique to extend or specialize a model. PIM models are transformed into PSM to introduce platform specific concepts not included yet in the platform independent model. Some specific concepts are introduced in the generated model automatically and others are updated manually. PSM to PSM and PIM to PIM refinements provide support to improve a model in the same modeling language space. UML model evaluations. Some UML technical profile standards and RFP [15][16] provide UML extensions and support for the transformation of UML extended models into other types of modeling techniques (e.g. analysis methods like Rate Monotonic Analysis and Failure Mode Effects Analyses) to apply specific analysis methods. Some UML tools make the transformation of UML models into simulation models to do the evaluation of the original models. Generation of implementations. Generators that provide as a result platform specific implementations can support the implementation of a PSM model. These generators translate the UML model into programming language and middleware constructors (e.g., Java and CORBA interfaces and EJB component descriptors).

The transformation and refinement process include the problem of traceability. It is generally recognized that UML’s facilities for relating models at different levels of abstraction are rudimentary and need expansion. The UML 2.0 includes this as a basic problem. Another problem is the capacity to reuse the mappings and the combination of different mappings to create more complex mapping. This is especially interesting in MDA because it describes a sequence of mappings applied at different levels of abstraction.

136

Miguel de Miguel et al.

5

Solutions for the Adoption of MDA

In Section 2 we have introduced some approaches to support MDA. In this section, we are going to give five different solutions based on these approaches and describe how they support different facilities introduced throughout the paper. The five approaches are: •

•

•

•

Integration of Generators [9][8]. proposes some pragmatic solutions for the application of MDA. ArcStyler includes support for the development of component-based architectures implemented on EJB platforms. Business and platform independent concepts are expressed on business models. Business modeling comprises the first stage in the full cycle development of componentbased software systems. These models are transformed automatically into component models, which are EJB specific models. Business models are expressed in a proprietary modeling language, and component models are based on a UML profile. ArcStyler provides support for the automatic generation of EJB components, from component models. ArcStyler supports customization of the transformation process. Customization is based on the cartridge configuration files and templates. JPython is used as the transformation language, some scripts are generated automatically, and others are specific to the generation process. Profiling [23][5]. Objecteering provides support for the description of UML profiles (Profile Builder). The profile description includes the specification of Stereotypes and Tagged Values and the UML meta-classes associated with these extensions. The profiles are supported and handled with modules. A module can include commands applied to model elements. These commands implement the transformation of models. They are scripts in a proprietary language (J language). J provides support for the creation of new diagrams and model elements. The commands support transformations from model to model, or from model to code or documents. Objecteering provides traceability support to avoid inconsistency between the model source and the model or code destination. Execution of Models [10]. iUML comprises a modeler and simulator. The iUML simulator provides an execution environment in which models can be executed and supports Action Specification Language (ASL). iUML supports pre-defined mappings to platform specific implementations, and the definition of user configurable mappings from PIM to specific implementations. The mappings are specified using executable UML models that represent the source and destination meta-models. In this approach, meta-models and ASL support the mappings, and the execution of UML models at meta-model level implements the transformations. Languages for Modeling [1][4]. The 2U group proposes a meta-modeling framework. The facility comprises a language for defining modeling notations, a tool that checks and executes those definitions, and a method consisting of a model based approach to language definition. Mappings between language

Practical Experiences in the Application of MDA

•

137

components are defined in terms of OCL constraints on associations between model elements. Currently, there is no tool support available for this solution. OCL Evaluators [26][20]. USE is a tool for the validation of UML models and OCL constraints. This tool does not address the problems of model mappings and UML extensions but proposes solutions for the validations of OCL constraints. This approach is a solution for the validation of OCL constraints in mappings and meta-models.

In Table 1, we present a simple qualitative comparison of the solutions. We use the support facilities we have identified in Section 4, to do the comparison. The legend for included is as follows: -- “not addressed” AD ”addressed in detail” (A)/(D) “mentioned only in the tool board” NF “To be addressed in next future” PS “Proprietary solution/language” SS “Standard solution/language”

PM “Support of Profiles Multiples” MMM “Mappings guided by meta-models” MSL “Mappings guided by script languages” RT “Reuse of mappings based on templates” RA “Reuse based on annotations”

Table 1. Comparison of solutions for the adoption of MDA

Integra- Protion Gen- filing erators

Models Execution

Description of Modeling Languages

Profile (A)/(D) AD -Support PM PS Profiles Reuse of -AD PS -Profiles Specification ---Well-formed Rules Meta-AD Models Definition of (A)/(D) Meta-Models -AD PS AD Extension UML Meta-Model Mappings MSL MSL MMM Support PS SS Models AD PS AD PS (A)/(D) Mappings Generation Portability of --AD SS Mappings Traceability (A)/(D) A/D -Reuse of Mappings

AD RT RA

AD PS (A)/(D)

OCL Languages for EvaluatModeling ors (A)/(D)

--

--

--

AD

AD SS

AD

--

AD

--

AD

(A)/(D)

--

(A)/(D)

(A)/(D)

--

--

--

(A)/(D) RT

--

138

Miguel de Miguel et al.

6

Conclusions

MDA proposes solutions to separate technology dependent concepts and independent concepts. The separation reduces the complexity of software portability and specializes the modeling process. This approach make easier the application of tool supported solutions. The adoption of MDA require to take some decisions about the technologies to be used, and the tools and methods that can support MDA. Currently there are different solutions to support the definition of modeling language extensions and there is not a standard available for the specification of mappings. These problems can create problems equal or more complex than the problems that MDA try to solve. MDA proposes solutions to limit the dependencies of software from the platforms, but the alternative solutions for the specification of extensions and mappings can create dependencies with the specific mapping implementations. If there is not a precise description of mappings, two different implementation of mappings can generate very different code or models and this can create the dependencies between the software and the mapping solution used. OMG has started to address this problem [18].

References 1. 2.

3. 4. 5. 6.

2U Consortium. http://www.2uworks.org Architecture Board ORMSC “Model Driven Architecture”, OMG document number ormsc/2001-07-01. (July 2001) ftp://ftp.omg.org/pub/docs/ormsc/01-0701.pdf J. Bézivin. “From Object Composition to Model Transformation with the MDA”. In Proceedings of TOOLS´2001. IEEE. (August 2001). T. Clark, A. Evans and S. Kent. “Engineering Modelling Languages: A Precise Meta-Modelling Approach”. http://www.2uworks.org/documents.html P. Desfray “MDA-When a major software industry trend meets our toolset, implemented since 1994”. (October 2001) http://www.softeam.org/fr/pdf/mda.pdf D. DSouza. “Model-Driven Architecture and Integration: Opportunities, and Challenges”, version 1.1, http://www.catalysis.org/publications/papers/2001-mda-reqsdesmond-6.pdf

7.

D. Flater. “Impact of Model-Driven Architecture”. In Proceedings of the 35th Hawaii International Conference on System Sciences, (January 2002) 8. R. Hubert. “Convergent Architecture: Building Model-Driven J2EE Systems with UML” J. Wiley (November 2001) 9. IO-software: ArcStyler. http://www.io-software.com/products/as_mda_main.html 10. Kennedy Carter: “iUML - The executable UML modelling environment”. http://www.kc.com/products/iuml

11. B.

Nordmoen

“Beyond

CORBA

Model

Driven

Development”.

http://www.omg.org/mda/mda_files/SSSummit_nordmoen_OMG.pdf

12. Object Management Group. “MOF 1.3 Specification”, OMG document number formal00-04-03, (March 2000) ftp://ftp.omg.org/pub/docs/formal/00-04-03.pdf

Practical Experiences in the Application of MDA

139

13. Object Management Group. “UML Profile for EDOC”. OMG document number ptc01-12-04 (December 2002) ftp://ftp.omg.org/pub/docs/ptc/01-12-04.pdf 14. Object Management Group. “UML Profile for CORBA 1.1 Specification”, OMG document number ad/99-03-11 (March 1999) ftp://ftp.omg.org/pub/docs/ad/9903-11.pdf 15. Object Management Group. “UML Profile for Schedulability, Performance, and Time”, OMG document number ptc02-03-02 (March 2002) ftp://ftp.omg.org/pub/docs/ptc/02-03-02.pdf 16. Object Management Group. “UML Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms”, (Request for Proposal). OMG document number ad02-01-07 (January 2002) ftp://ftp.omg.org/pub/docs/ad/0201-07.pdf 17. Object Management Group. “Actions Semantic for the UML”, OMG document number ptc02-01-09 (January 2002) ftp://ftp.omg.org/pub/docs/ptc/02-01-09.pdf 18. Object Management Group. “MOF 2.0 Query / views / transformation”, (Request for Proposal). OMG document number ad02-04-10 (April 2002) http://cgi.omg.org/docs/ad/02-04-10.pdf 19. D. Poole. “Model-Driven Architecture: Vision, Standards And Emerging Technologies”. Workshop on Metamodeling and Adaptive Object Models. ECOOP 2001. 20. M. Richters and M. Gogolla. “Validating UML Models and OCL Constraints” In Proceedings of UML 2000. Springer. (October 2000) 21. J. Siegel and the OMG Staff Strategy Group. “Developing in OMG’s ModelDriven Architecture”. Object Management Group White Paper (November, 2001) ftp://ftp.omg.org/pub/docs/omg/01-12-01.pdf

22. R. Soley and OMG Staff Strategy Group. “Model Driven Architecture”, Object Management Group White paper, (November 2000) ftp://ftp.omg.org/pub/docs/omg/00-11-05.pdf

23. Softeam. “Objecteering/UML CASE tool”. http://www.objecteering.com 24. Sun Java Community Process JSR-26. “UML/EJB Mapping Specification”. http://jcp.org/jsr/detail/26.jsp

25. Thales-TRT. “Model Based Engineering of Software Products”. In proceedings of OCM 2002 (March 2002) 26. “USE: A UML-based Specification Environment”. http://dustbin.informatik.unibremen.de/projects/USE/

Executable Design Models for a Pervasive Healthcare Middleware System Jens Bæk Jørgensen and Søren Christensen Centre for Pervasive Computing Department of Computer Science, University of Aarhus IT-parken, Aabogade 34, DK-8200 Aarhus N, Denmark {jbj,schristensen}@daimi.au.dk

Abstract. UML is applied in the design of a pervasive healthcare middleware system for the hospitals in Aarhus County, Denmark. It works well for the modelling of static aspects of the system, but with respect to describing the behaviour, UML is not sufficient. This paper explains why and, as a remedy, suggests to supplement the UML models with behaviour descriptions in the modelling language Coloured Petri Nets, CPN. CPN models are executable and fine-grained, and a combined use of UML and CPN thus supports design-time investigation of the detailed behaviour of system components. In this way, the behavioural consequences of alternative design proposals may be evaluated and compared, based on models and prior to implementation. Keywords: Executable models, detailed behaviour, Petri nets, CPN, system design, middleware, pervasive and mobile computing, supplementing UML.

1

Introduction

This paper considers design of a system to support pervasive and mobile computing [3, 5] at hospitals, the pervasive healthcare middleware system, PHM [1]. The system is being developed in a joint project by the hospitals in Aarhus County, Denmark, the software company Systematic Software Engineering [21], and the Centre for Pervasive Computing [16] at the University of Aarhus. PHM will be part of Aarhus County’s new electronic patient record, EPR [15], a comprehensive, general-purpose hospital IT system with a budget of approximately 15 million US dollars. EPR will be initially fielded later this year and put into full operation in 2004. The first version of EPR is made available from desktop PCs placed in hospital offices. However, the EPR users, i.e., the nurses and doctors, are away from their offices and on the move a lot of the time, e.g., seeing patients in the wards. Therefore, stationary desktop PCs in hospital offices are insufficient to support the hospital work processes in the best way, and taking advantage of the emerging possibilities for pervasive and mobile computing is crucial for the next version of EPR.

J.-M. J´ ez´ equel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 140–149, 2002. c Springer-Verlag Berlin Heidelberg 2002


Executable Design Models for a Pervasive Healthcare Middleware System

141

In the design of PHM, U ML [11, 13] is applied, primarily to model static aspects. However, the PHM design must also address a number of behavioural and dynamic aspects applicable to distributed systems in general, and to pervasive and mobile systems in particular. UML, as it is currently standardised, has some shortcomings that prevent us from expressing key behavioural aspects in terms of UML models only. To overcome these shortcomings, Coloured Petri Nets, CPN [8, 9, 17], is used as a supplement to UML. CPN is a mature and wellproven modelling language suitable to describe the behaviour of systems with characteristics like concurrency, resource sharing, and synchronisation. The perspectives offered by UML state machines and activity diagrams are combined in CPN, in the sense that focus is equally balanced on states and activities, and their interrelations, in the same model. The main contribution of this paper is to describe and justify a combined use of UML and CPN for the design of PHM. The paper is structured as follows: Section 2 introduces the session manager component of PHM, whose design will be the focus of discussion in this paper. Section 3 pinpoints a number of shortcomings in UML behavioural modelling. A CPN model of the behaviour of the session manager, together with an introduction to the CPN modelling language itself, is presented in Sect. 4. Section 5 justifies the combined use of UML and CPN, and the conclusions are drawn in Sect. 6.

2

The Session Manager

PHM is a distributed system consisting of a number of components running in parallel on various mobile and stationary computing devices, and communicating over a wireless network. Some components run on a central background server, while others are deployed on the mobile devices. The scope of this paper is restricted to discussing design of the session manager component, which we present now. For a description of the other main components of PHM, please refer to [1]. Sessions In PHM, a session comprises a number of devices that are joined together, sharing data, and communicating in support of some specific work process. A session is appropriate, e.g., if a nurse wants to use her personal digital assistant, PDA, to control a TV set in a ward in order to show an X-ray picture to a patient. In this case, the TV and the PDA must be joined in a session. Another example is a nurse who wishes to discuss some data, e.g., electronic patient record data, or audio and video in a conference setting, with doctors who are in remote locations. Here, the relevant data must be shown simultaneously on a number of devices joined in a session, one device for the nurse and one device for each doctor. In general, session data is viewed and possibly edited by the users through their devices. The PHM architecture is based on the Model-View-Controller pattern [4]. The model part administers the actual data being shared and manipulated in a session. Each participating device has both a viewer and a controller

142

Jens Bæk Jørgensen and Søren Christensen

inactive

1 SessionManager

1

* managed

Session

1

1..* active

*

Device

Fig. 1. Session management class diagram component which are used as, respectively, interface to and manipulator of the session data. Model, viewer, and controller components communicate over the wireless network. Session Management Sessions are managed by a session manager, which is one of the most central and most complex components of PHM. The main classes and relationships of concern for session management are shown in Fig. 1. A session manager manages zero to any number of sessions, and a session comprises one or more devices. Seen from the point of view of a session manager, a device is either inactive, i.e., not currently participating in any session, or active, i.e., participating in some session. A device participates in at most one session at a time. The operations that a session manager must provide can be grouped into three main functional areas: 1. Configuration management: Initiation, reconfiguration (i.e., supporting devices dynamically joining and leaving), and termination of sessions. 2. Lock management: Locking of session data. Session data is shared and must be locked by a device, which wants to edit it. 3. Viewer/controller management: Change of viewers and controllers for active devices, e.g., if a nurse enters a room containing a TV, she may wish to view something on the large TV screen instead of on her small PDA display. In this case, viewer and controller replacement on the PDA and the TV is needed. Devices interact with a session manager by invoking its operations. One interaction scenario is shown in Fig. 2, which illustrates the communication between a SessionManager object and two Device objects, d1 and d2. First, d2 creates a session, which gets the session identifier 1. The session manager responds to the creation request by providing d2 with a default viewer and a default controller for the new session. Then, d1 joins the session, and also gets a default viewer and a default controller from the session manager. At some point, d1 locks the session, probably does some editing, commits, and later releases the lock. Finally, d2 and then d1 leave the session.

3

Shortcomings in UML Behavioural Modelling

Figure 2 is an example illustrating one single possible sequence of interactions between a session manager and some devices. In the session manager design, of

Executable Design Models for a Pervasive Healthcare Middleware System

:SessionManager

d1:Device

143

d2:Device

createSession (1) defaultViewer defaultController joinSession (1) defaultViewer defaultController setLock (1) releaseLock (1) leaveSession (1) leaveSession (1)

Fig. 2. Session manager / device communication sequence diagram

course much more is needed. It is crucial to be able to specify and investigate the general behavioural properties of session management. This requires specification of both the individual behaviour of device and session manager objects, and the combined behaviour when these objects interact. Therefore, it was attempted to create communicating state machines for the SessionManager and Device classes, and subsequently investigate their individual and combined behaviour. In this process, a number of severe problems were encountered. The problems that will be discussed in this paper are described below, and are all instances of more general shortcomings in UML behavioural modelling. Execution The first shortcoming is lack of executable models. Without executable models, it is in practice impossible to investigate behavioural consequences of various design proposals for session management, prior to implementation. Executable models presume a well-defined formal execution semantics, which UML is currently lacking – no kind of UML diagram as defined in the current standard [11] is executable. We are well aware that if this problem was the only one, it might be alleviated by using UML tools from, e.g., I-Logix’s Rhapsody suite [19] or Rational’s Rose RealTime [20] that do offer execution of UML behavioural diagrams – with execution algorithms which are, by necessity, based on proprietary semantic decisions. We are also aware that a formal execution semantics will most likely sooner or later be part of the UML standard (but we need it now for the PHM project). State machines already have an informal, textually described semantics in the current standard [11], and many proposals to define a formal semantics for state machines have been published, e.g., [2, 10].

144

Jens Bæk Jørgensen and Søren Christensen

Dependencies The state machines for the SessionManager and Device classes are closely interrelated. For both classes, all state changes of concern are consequences of devices invoking operations in a session manager. We have had difficulties in describing individual state machines for the two classes, while at the same time properly capturing their communicating behaviour. The difficulties are caused by a number of dependencies between the three main functional areas of the session manager, e.g., there is a dependency between lock management and configuration management, because a device in the process of editing session data is not allowed to abruptly leave the session. We require that the lock is explicitly released before permission to leave can be granted. It is difficult to capture the dependencies in a proper way with state machines. Undesired interferences between the three main functional areas must be precluded, e.g., that a device loses its lock on session data during viewer/controller replacement – replacements are not atomic operations; a device first detaches the old and then attaches a new viewer/controller, and is temporarily suspended in between. We have tried to use both concurrent and-states and the history mechanism of state machines (the latter is controversial [14]), but have not been able to describe the dependencies between the three main functional areas in a satisfactory way. In theory, it is possible to create state machines that capture all dependencies, simply by introducing a sufficient number of states, e.g., instead of two individual states like Has lock and Is replacing controller, introduce states with more complex interpretations like Has lock and is replacing controller. However, the approach does not scale well – the size of the state machines grows quickly with the number of dependencies to be modelled. As an example, state machines are not feasible to describe a more fine-grained locking scheme than the current coarse-grained one. Allowing locking of subsets of session data requires simultaneous management of several locks and introduces many dependencies. Bookkeeping A key task of session management is bookkeeping by tracking which devices are currently joined in sessions. Bookkeeping records must be updated each time a device creates, joins, or leaves a session. Proper investigation of session bookkeeping requires container-like data structure such as sets or lists to be supported in the session management behavioural models, e.g., to describe that in the current state, there are two sessions, one with devices { d1,d2,d3} and one with devices { d4,d5} . The state notion offered by state machines does not allow us to express this in a feasible way.

4

Session Manager Behaviour in CPN

Because of shortcomings such as the ones discussed above, instead of restricting ourselves to UML diagrams only, we also use the modelling language of Coloured Petri Nets, CPN [8, 9, 17] for the design of PHM. In this section, we present a CPN model describing the session manager behaviour and at the same time give an informal primer to CPN.

Executable Design Models for a Pervasive Healthcare Middleware System

145

Inactive DEVICE ConfigurationManager

Sessions

LockManager

SESSION Active

ViewCtrManager

DEVICExVIEWERxCONTROLLER

Fig. 3. SessionManager module CPN Background CPN is one dialect of a broader category of graphical modelling languages known as Petri nets [12]. Harel’s original paper on statecharts [6] recognises Petri nets as a powerful means to describe behaviour, but notes as a main problem that Petri nets cannot be hierarchically decomposed. Since the publication of [6] in 1987, this problem (and many others) has been solved [8]. A CPN model resembles a board game, with strict rules that define the possible executions of the model. The CPN modeller’s task is to specify an appropriate board, tokens, etc. to reflect the domain being modelled. A CPN model is a graphical structure, supplemented with inscriptions and declarations of data types, variables, and functions. The tokens may carry complex data values (“colours”), which is one of the main virtues of CPN. Use of functions and expressions to manipulate data values allows the complexity of a model to be appropriately split between graphics, and declarations and inscriptions. CPN gives a modelling convenience corresponding to a high-level programming language with support for data types, modules, and, indeed, hierarchical decomposition. Model Overview A CPN model is structured as a set of modules that have well-defined relations between them. The CPN model of the session manager consists of four modules, a top-level module SessionManager, shown in Fig. 3, and a module for each main functional area, ConfigurationManager, LockManager, and ViewCtrManager. The boxes in the figure are substitution transitions, corresponding to other modules of the model. Substitution transitions are the CPN mechanism to describe hierarchical decomposition, and a CPN counterpart of composite states of UML state machines. The CPN model describes the behaviour of the session manager by tracking the states of devices and sessions. Thus, the CPN model represents the combined behaviour of interacting objects instantiated from the class diagram of Fig. 1 (and additional objects like viewers, controllers, and locks). Space does not allow us to present the entire model. Instead, we will describe one selected, representative module, the ConfigurationManager, shown in Fig. 4, and introduce the basic CPN concepts as we proceed.

146

Jens Bæk Jørgensen and Søren Christensen {d1,d2,d3,d4,d5} Inactive DEVICE d

1 Next id

s s+1

SESSION_ID

Create session

d

d

(s,(remove d dl),l) (s,d::dl,l)

(s,[d],nolock)

Sessions SESSION

(s,dl,l)

Join session [joinOK d (s,dl,l)]

Leave session [leaveOK d (s,dl,l)]

(s,dl,l) Active (d, defaultViewer d, defaultController d) DEVICExVIEWERxCONTROLLER

(d, defaultViewer d, defaultController d)

(d,v,c)

Fig. 4. ConfigurationManager module Modelling of States A CPN model describes both the states and the actions of a system. The state of a CPN model is a distribution of tokens on the places. Each place is drawn as an ellipse and has a data type, written in italic capital letters, which determines the kinds of tokens the place is allowed to contain. In Fig. 4, the session manager’s tracking of devices as being inactive or active is modelled by the places Inactive and Active. Inactive has data type DEVICE, whose elements are interpreted as devices, i.e., a DEVICE token on Inactive corresponds to an inactive device. Similarly, a token on Active models an active device, and its association with a viewer and a controller as catered for by the data type DEVICExVIEWERxCONTROLLER. The Sessions place is used to keep track of the ongoing sessions by containing tokens comprising lists of devices. The elements of data type SESSION are triples (s,dl,l), where s is a session identifier, dl is a list of devices, and l is a lock indicator. The Next id place contains an integer, used to assign a unique identifier to each session – the integer is incremented each time a new session is created. The figure shows the initial state of the model, where Inactive contains five device tokens, Active and Sessions are both empty, and Next id is marked with the integer 1. Modelling of Actions The actions of a CPN model are represented using transitions, drawn as rectangles. In Fig. 4, the transitions correspond to session manager operations. A transition and a place may be connected by an arc. Solid arcs show the flow of DEVICE tokens, and dashed arcs the flow of SESSION tokens (different graphical appearances are used only to enhance readability, and have no formal meaning). The actions of a CPN model consist of transitions removing tokens from input places and adding tokens to output places, often referred to as the token game. Input/output relationship between a place and a transition is determined by the direction of the connecting arc. The tokens removed and added are determined by arc expressions, e.g., the expression on the arc from the Inactive place to the Join session transition is d, where d is a variable that can be assigned data values.

Executable Design Models for a Pervasive Healthcare Middleware System

147

Execution Semantics A transition which is ready to remove and add tokens is said to be enabled. One condition for enabling is that appropriate tokens are present on the input places. More precisely, it must be possible to assign data values to the variables appearing on input arcs such that the arc expressions evaluate to tokens available on the input places. In Fig. 4, enabling of the transition Join session requires that the place Inactive contains some DEVICE token that can be bound to the variable d appearing in the expression of the arc going from Inactive to Join session. Moreover, the other input place, Sessions, must contain a token that can match the arc expression (s,dl,l), which designates a triple consisting of a session identifier s, a device list dl, and a lock indicator l. An additional condition for enabling comes from the guard, which is a boolean expression optionally assigned to a transition, and which must evaluate to true for the transition to be enabled. The guard of the transition Join session is the expression [joinOK d (s,dl,l)], which tests whether it is allowed for the device d to join the session identified by (s,dl,l) – joinOK is a function enforcing the rules for joining. An enabled transition may occur. The occurrence of the transition Join session models that a previously inactive device d joins a session. When d joins a session with session id s, the token (s,dl,l) residing on the Sessions place is updated as described by the arc expression (s,d::dl,l), which adds d to the list dl. Moreover, d is removed from the Inactive place, augmented with a default viewer and controller, and added to the Active place. The individual modules of a CPN model interact when the model is executed. In the modules of Figs. 3 and 4, places with the same name (e.g., the two Inactive places) are conceptually glued together, thus allowing exchange of tokens between the modules, when the token game is played. Model Perspective The perspective of the CPN model is the communication between, and thus combined behaviour of, the objects of concern, i.e., a session manager, devices, sessions, etc. Occurrence of any transition corresponds to invocation of an operation of a session manager by some device. The result of the occurrence reflects the corresponding state change for the invoking device and involved session, e.g., a device changes from inactive to active, and a session is extended with an additional device – or, in the modules not shown, a lock is set on session data, or a device changes from active to suspended.

5

Justification of CPN Use

Using CPN as a supplement to UML for modelling the session manager behaviour is a deviation from an established standard, and therefore should be well justified. We do this now by revisiting the UML shortcomings of Sect. 3, and arguing that they are all alleviated by the use of CPN. Execution CPN offers executable models, ensured by a well-defined, formal execution semantics in terms of the enabling and occurrence rules. In the PHM

148

Jens Bæk Jørgensen and Søren Christensen

project, the behavioural consequences of alternative design alternatives are investigated via execution of CPN models. Changing a decision, e.g., the rules governing joining and leaving of sessions, can be captured and investigated quickly by modification and execution of the session manager CPN model. In the PHM project, the implementation of the executable CPN design models involves manual coding. This is a general drawback of CPN, whose elaborated data type concept often is an advantage when creating models, but on the other hand makes automatic code generation from CPN models more complicated than, e.g., code generation from various versions of statecharts and state machines. Therefore, when use of CPN is considered in a project, a trade-off must be made between the desire to have strong, executable design models on one side, and ease of implementation on the other. The formal semantics of CPN is the cornerstone for executable models. An additional gain of the formal semantics is that CPN models may be formally verified [8]. There exists industrial-strength tools supporting both execution and verification of CPN models. The model of this paper is made with Design/CPN [18], which is used by many companies and research institutions world-wide. Dependencies Functional area dependencies can be properly described in CPN because of the fine-grained nature of CPN models, in particular the support for tokens carrying data values. In the CPN model of the session manager, e.g., lock management and viewer/controller management cannot interfere with each other in an undesired way. Whether a session is locked or not is captured by a value in the SESSION token on the Sessions place. As can be seen from Fig. 3, replacement of viewers and controllers (modelled by the substitution transition ViewCtrManager) does not involve the Sessions place at all. CPN models scale well, e.g., a more fine-grained locking scheme, which as noted in Sect. 3 results in many dependencies, can be modelled based on letting SESSION tokens comprise lists of locks, instead of just one single lock. Bookkeeping CPN allows use of container data types. In the session manager model, the place Sessions has a data type defined and used with the purpose to do the desired bookkeeping, i.e., tracking which devices are in sessions together.

6

Conclusion

The proposal to combine UML with CPN is not new, e.g., in [7] the ambitious aim is formal verification via automatic generation of CPN models from UML models. In the PHM project, the immediate advantages of CPN are used to obtain executable and fine-grained design models, focusing on the communication between, and thus combined behaviour of, the objects of concern. In this way, CPN is a means to gain valuable insight early in the development project. The scope of this paper has been a specific project, and even the design of a specific component, but the encountered UML shortcomings and proposed

Executable Design Models for a Pervasive Healthcare Middleware System

149

alleviation are of a general nature. Thus, in a number of projects, the early design decisions may be improved by supplementing UML models with behaviour models in CPN, e.g., when designing pervasive and mobile systems. However, more work is required in order to assess the feasibility of a theoretically wellfounded and more general integration of the UML and CPN modelling languages.

References [1] J. Bardram and H. B. Christensen. Middleware for Pervasive Healthcare, A White Paper. In Workshop on Middleware for Mobile Computing, Heidelberg, Germany, 2001. 140, 141 [2] M.v.d. Beeck. Formalization of UML-Statecharts. 143 [3] J. Burkhardt, H. Henn, S. Hepper, K. Rintdorff, and T. Sch¨ ack. Pervasive Computing – Technology and Architecture of Mobile Internet Applications. AddisonWesley, 2002. 140 [4] F. Buschmann, R. Meunier, H. Rohnert, and P. Sommerlad. Pattern-Oriented Software Architecture. John Wiley and Sons, 1996. 141 [5] U. Hansmann, L. Merk, M. S. Nicklous, and T. Stober. Pervasive Computing Handbook. Springer Verlag, 2001. 140 [6] D. Harel. Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, 8, 1987. 145 [7] R. G. Pettit IV and H. Gomaa. Validation of Dynamic Behaviour in UML Using Colored Petri Nets. In Workshop on Dynamic Behaviour in UML Models: Semantic Questions, ≪UML≫ 2000, York, England, 2000. 148 [8] K. Jensen. Coloured Petri Nets — Basic Concepts, Analysis Methods and Practical Use. Volume 1-3. Monographs in Theoretical Computer Science. An EATCS Series. Springer-Verlag, 1992-97. 141, 144, 145, 148 [9] L. M. Kristensen, S. Christensen, and K. Jensen. The Practitioner’s Guide to Coloured Petri Nets. International Journal on Software Tools for Technology Transfer, 2(2), 1998. 141, 144 [10] S. Kuske. A Formal Semantics of UML State Machines Based on Structured Graph Transformations. 143 [11] OMG Unified Modeling Language Specification, Version 1.4. Object Management Group (OMG); UML Revision Taskforce, 2001. 141, 143 [12] W. Reisig. Petri Nets, an Introduction. Springer-Verlag, 1985. 145 [13] J. Rumbaugh, I. Jacobson, and G. Booch. The Unified Modeling Language Reference Manual. Addison Wesley, 1999. 141 [14] A. J. H. Simons and I. Graham. 30 Things That Go Wrong in Object Modelling with UML 1.3. In H. Kilov, B. Rumpe, and I. Simmonds, editors, Behavioral Specifications of Businesses and Systems. Kluwer Academic Publishers, 1999. 144 [15] Aarhus Amt Electronic Patient Record. www.epj.aaa.dk. 140 [16] Centre for Pervasive Computing. www.pervasive.dk. 140 [17] Coloured Petri Nets at the University of Aarhus. www.daimi.au.dk/CPnets. 141, 144 [18] Design/CPN. www.daimi.au.dk/designCPN. 148 [19] I-Logix. www.ilogix.com. 143 [20] Rational Software Corporation. www.rational.com. 143 [21] Systematic Software Engineering A/S. www.systematic.dk. 140

Generating Code from UML with Velocity Templates Thorsten Sturm, Jesco von Voss, and Marko Boger Gentleware AG, Vogt-K¨ olln-Str. 30, 22527 Hamburg {Thorsten.Sturm,Jesco.von.Voss,Marko.Boger}@gentleware.de

Abstract. The value of automated code generation is increasingly recognized, and the application model becomes the central artefact in the software development process. Model-driven development requires a rapid and flexible code generation mechanism. This paper discusses code generation based on templates that actively access UML model information to fill an implementation skeleton. Different templates result in different generated code, providing a highly flexible generation mechanism. Along with a discussion on the potential of such a code generation, an existing framework for code generation with templates is presented.

1

Introduction

The Unified Modeling Language can not only be used for the modeling phase of software projects. When code can be generated from the UML model, it also has the potential to be applied in the implementation and testing stages, and even for the deployment of a final software product. Generating code based on the platform-independent application model reduces coding errors, enforces the conformity to coding standards and specifications, and increases speed and quality of the development process while raising the abstraction level for the software architects. If the applicability of modeling tools is to be extended from simple documentation work to a vital role in the development process, a code generation framework has to meet the following demands. – Liveness: Changes to the model should immediately be reflected in the generated code, so that the product can be tested. Also, changes to the generation process should be possible on the fly. Customization might range from changing indentations over performance tuning to the creation of new code for UML expressions that are not covered by the vendor’s standard product. A generated application can successfully replace hand-coded applications only if the code generation is sufficiently adaptive to special requirements, so that the quality of the result is comparable. – Extensibility: The introduction of new generation targets should be painless and simple. Modifications of the modeling tool should not be necessary. The customer should be able to adjust the code generation in order to satisfy individual, platform-specific needs (such as hand-tailoring to an application server or to a legacy database). J.-M. J´ ez´ equel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 150–161, 2002. c Springer-Verlag Berlin Heidelberg 2002


Generating Code from UML with Velocity Templates

151

– &'intainability: The generation process itself should give a good impression on how the resulting code will look like. This simplifies the development of new generation targets (languages, architectures) and raises the maintainability and liveness of existing ones. – Encapsulated implementation: The Model-Driven Architecture (MDA) approach proposes the creation of a platform-independent application model in conjunction with a mechanical transformation of the platform-independent model to one or several platform-specific models. This way, analytical and modeling know-how can be separated from implementation know-how. Tools are required for the maintenance of the application model and for the transformation to the platform-specific model. Casting a brief glance at the diagram types of UML and how they can play a part in generating the code for the final software product shows how code generation from UML models can be applied. – Class diagrams are widely used to create the static skeletons of the software product. The translation from static structure to code skeletons is straightforward. Even mappings for special purposes, like Enterprise Java Beans, are possible and simplify their use. Therefore, this kind of code generation is accepted and used throughout the community, although the complete behavioral code has to be filled in manually. – State diagrams describe the behavior that is implemented via the method bodies of classes. Some tools already support code generation from state diagrams, but this practice is not yet prevalent. Implementations are usually based on the GOF State pattern [4] and enable the modeling of stateful classes. The quality and usability of the resulting code heavily depend on the quality and completeness of the state diagrams themselves. – Deployment diagrams specify the physical architecture and can thus model distribution. Usage of this information for automatic code generation is experimental, especially as the implementation of distributed applications is technically demanding. Several languages support distribution inherently (e. g., DeJay [2]), but most of them are used in scientific environments only. – Sequence and collaboration diagrams can be utilized to generate unit tests, and the first tools appear that support this approach. They might also be used to model the method bodies. – Use case and activity diagrams specify the needs of the users and are therefore the blueprint for integration and acceptance tests. Grouping of test cases to functional or unit tests is also possible here. A system that supports code generation from UML models should be flexible enough to allow for simple inclusion of new target languages or language specifications. On the other hand, with new standards for UML, the existing know-how (and coding labor) on target languages and specifications should be re-usable. A loose coupling of source (UML) and target (language) is therefore required.

152

Thorsten Sturm et al.

In the next sections, we will outline different architectural approaches for code generation frameworks and discuss their benefits and how they can fulfill the quality demands outlined above. Subsequently, an architecture that supports the transformation from the model to platform-specific code is described.

2

Code Generation Concepts

Three ways of bridging the gap between a model and the running code can be distinguished [1]. Each subsequent one is more powerful in the amount and quality of the generated code. – The simplest way is the structural code generation that renders the static structure of the model. In practice, this refers to code generation from class diagrams. To some degree, information from deployment diagrams could be utilized, but this is hardly ever done. Code and model can easily run out of sync during the implementation phase. Automated synchronization mechanisms between model and code are therefore required to make this approach usable. – The behavioral approach models objects as state machines. From the model, the static structure and the state diagrams of classes are utilized to generate most of the dynamic logic. Analysis and implementation phase are unified. Code generation produces a prototype that is evaluated and tested but not changed manually. The evaluation results become part of the model in the following cycle. No additional mechanism to ensure synchronization between code and model is required. – The translative approach decouples source and target. A separate subsystem encapsulates the generation of the implementation logic. Modeling can thus be independent of the target language and architecture, fulfilling the MDA requirement that the application model be completely oblivious to the actual implementation(s). The platform-independent model is maintained in the modeling application, and the transformation process can be modified independently. The introduction of a new language or specification amounts to enhancing/replacing the translator, not the model, and not even of the tool that maintains the model. As long as the generation logic has access to the model, all implementation logic and know-how can be encapsulated in the generation subsystem. Increasing the code generation potential is possible, e. g., by using information of more UML element types. The translative approach has the potential for generating the system code as well as unit and integration test suites. The fact that the abstract system (the software architecture) makes no assumptions about the concrete implementation allows for easy customization of the implementation. Therefore, a framework that supports this approach will be the best foundation for future extensions. In the next paragraphs, we will therefore examine three ways of pursuing the translative approach.

Generating Code from UML with Velocity Templates

2.1

153

Translation b y Ap p lication Code

The translation of the model to code can be done in any programming language that can manipulate strings and gain access to the model information. Especially object-oriented languages can be used here, as the object-oriented model information can be encapsulated in a straight-forward fashion. The translation is either part of the modeling tool itself, or a standalone tool that receives the model information as input. This approach has some major drawbacks. The development of the translation rules and the attached string manipulation suffers from long development cycles. Interpreted languages – especially those that offer special features for simple string manipulation – could shorten them. A translation framework as part of an application or as stand-alone translator limits the liveness of the code generation process. Customization is limited to the degrees of freedom that the tool offers explicitly – changes cannot be made quickly without modifying the modeling application. Also, from the look of the translating code (if available), it is hardly possible to gain an impression of the appearance of the resulting code. An example from a different domain are WYSIWYG HTML editors. The graphically created page is rendered as HTML code, influenced by some parameters that the user can set. The resulting HTML is typically very bloated, complicated to read, much longer, and therefore slower in production. The code that generates the HTML is usually compiled (except for open source products) and can therefore not be modified by the user. The quality of the end product is worse than that of manually edited HTML pages, so that for high load web servers, these programs cannot compete with hand-crafted pages. The limitations in liveness and maintainability reduce the usability of translation by application code. To some degree, configurable code generation subsystems can handle this problem, but they will always have the shortcoming that any construct the vendor does not support will not be accessible. Code generation environments targeting short development cycles and thorough customization of the translation should therefore be based on a different approach. 2.2

Translation by XSLT

Along with the growing number of tasks and applications using XML, a dialect called XSLT has recently gained attention. The primary goal of XSLT was to provide a translation feature from one XML dialect into another. The variety of translations from XML into anything else grows quickly. Although XSLT was originally targeted to translate to XML, it is not limited to that. Stylesheets that translate from a UML model to code separate the translation rules from the model and the translation process from the modeling tool. As the translation with XSLT is based on navigation through node trees, the stylesheets are very hard to read and maintain. They give no impression on what the resulting code looks like. Additionally, XSLT suffers from a major performance drawback. An XML document has to be generated as the input of

154

Thorsten Sturm et al.

Fig. 1. XSLT Processor [5]. The Source XML is generated from the UML model. The Stylesheet XSL contains language and formatting knowledge. The output is HTML (for documentation purposes) or any programming language

every generation run. The content of that document as well as the content of the stylesheet have to be mapped to internal tree structures within the translator. Partitioning the model into smaller chunks might be a solution to performance problems, but the partitioning algorithm is dependent on the targeted language. E. g., C code can ignore types if pointers are used, whereas Java code requires the referenced types. This fact violates the requirement that the modeling application be independent of any platform specifics (or else, the partitioning must be over-inclusive, relinquishing the performance advantage). Also, every single model element type requires its own stylesheet, which is a large performance overhead and distributes the generation logic over many places. 2.3

Translation by Templates

Dynamic web pages have become common practice in the web development world. Instead of integrating code directly into HTML pages (as PHP does), template-based approaches offer dynamic creation of web pages which in turn are static. The generation code is completely separated from the HTML code (except for special tags relevant to the generation). The creation process uses the generation code to retrieve the model information just-in-time and fills templates of HTML code (header and footer HTML snippets for the page, news, advertisements, etc.) with it. The resulting files represent the final web pages. This concept is not limited to dynamic web pages. The generation code can retrieve information from almost any source, and the templates can hold the skeletons for any kind of structure. In the context of code generation, the UML model is the information source. The templates hold the skeletons for the tar-

Generating Code from UML with Velocity Templates

155

get language. Applying the model information to the templates would return a number of files containing the source code for the UML model. As the templates can easily be changed without affecting the model and the modeling tool, this approach offers fast development cycles for the translation itself. The way of creating the platform-specific model for the code generation can be modified quickly as requirements change, without any consequences to the application model. Most template engines use interpreted, imperative scripting languages for their templates. The languages are usually optimized for fast string manipulation and access to simple data structures. Directly accessing model information from such a scripting language is possible but complicated. The resulting template is hard to read and to maintain and gives only a vague impression on how the resulting code would look like. To illustrate this point, note that the traversal of a UML model typically requires accessing model elements that connect one element with another. As an example, consider rendering a reference from one class A to another class B. For every association end connected to A, you have to get the connecting association, then that association’s list of association ends, and look for an association end that is of type B. If you find one, you need to retrieve the association end’s name, and you are done; otherwise, continue with the next association end at class A. We believe that encapsulating this process in the modeling application is sensible: The result of this retrieval process (the name of the opposite end) is required by most, if not all, platform-specific models, and is therefore re-usable by all templates that create them. 2.4

Templates vs. XSLT

The presented translation concepts do not fully satisfy all characteristics of a code generation framework suitable for model-driven development. While the application code approach suffers from too many drawbacks to be used directly, using either templates or XSLT seems to have the potential of fulfilling the requirements. Liveness seems to be the most important characteristic for everyday work. The template-based approach is the only one that complies to it. Easy on-the-fly generation along with the separation of model information and generation logic are the major advantages. Problems in partitioning and performance let XSLT fall behind. A composition of templates and application code can help to reduce the complexity of the templates themselves. The templates are trimmed to retrieving simple model information and rendering the implementation specifics, while application code is used to do the complex model navigation and some languageindependent preparation work. Stripping the navigation part from the templates makes them a fairly good impression of the structure of the resulting code and thus increase maintainability. The XSLT code generation has to do all the navigation on its own. It iterates over the elements contained in the input XML document, which makes the stylesheet code even more unreadable. Even when

156

Thorsten Sturm et al.

(pplication code is used to aid navigation, the stylesheet code will not reflect the structure of the resulting code: XSLTs manipulate trees, not strings. Initialization of the application code for model access takes place before the templates are used. This is quite similar to the generation of an XML document when XSLTs are used. But there are also major differences. The application code consists of objects living in memory, while the XML document has to be created as character stream to be parsed by the XSLT processor. Partitioning is not necessary for the application code, because every single object knows how to retrieve the needed information from the model at any time. The XML document has to be created from scratch and includes all needed model elements. Although it is possible to use application objects from the XSLT processor, this would mean two copies of the navigation logic, in the XSLT and in the application object. At some point, the conversion of abstract UML model information to the structure and identifiers of a concrete programming language has to take place. The use of application code in the modeling application on the one hand and of templates that access this code on the other hand allows us to shift the boundary according to our needs. This flexibility and how we use it is outlined in the next section, giving an overview of the architecture and of the ways that users of the modeling tool P)*ei+), f)- UM. can modify the code generation to fit it to their development process and their platform-specific models.

3

A Framework Using Templates

As outlined in the last section, a code generation suitable for model-driven software development should use a template-based approach that is able to access application code objects. This section describes the code generation framework created for P)*ei+), f)- UM.. The framework consists of classes for several UML model elements, referred to as p-ep/-ed elements in the following sections, and a number of templates for generating code in Java and HTML. The template engine and language is a popular one. The open source project Velocity [3], which is part of the Apache project, offers a simple template language and allows access to Java objects from within the templates. The template engine merges a template and a context, which consists of a set of name-value pairs. Values can be either simple strings or references to Java objects. The complete public interface of referenced Java objects can be used in the template engine using reflection mechanisms. The referenced objects are the mentioned prepared elements. Reading Model Data. The templates are written in the Velocity Template Language (VTL) and interpreted by the Velocity Template Engine. In order to make use of a template, the engine parses and merges it with the given context. Part of the context is the prepared element for the model element that the code will be generated for. The prepared elements offer interfaces for easy access to preprocessed model information. Especially the navigation logic for retrieving the model information is encapsulated there.

Generating Code from UML with Velocity Templates

157

Fig. 2. Template-based code generation with prepared elements (partial). First, the prepared elements are initialized. Then, the template is interpreted, and references to the prepared elements are used to retrieve model information Instead of the object representing the model element, the matching prepared element is accessed from the template. As an example, the method PreparedClassifier.getImplementationsAsString() does its job (of retrieving the list of implemented interfaces) in roughly the following way: 1. Get the represented classifier from the tool’s model repository, and from that, the list of the classifier’s client dependencies. 2. If the list is not empty, get the first dependency. 3. If the dependency is an abstraction AND has a stereotype AND the stereotype is called realize: 4. Get the dependency’s suppliers. If there are suppliers, take the first one’s name and add it to the return list. 5. Repeat at step 3 with the next client dependency. This algorithm is more readable in application code and encapsulates the model navigation. This way, it is possible to modify the model repository without influencing the templates. If the application chose to move from UML 1.3 to 1.4, retrieving the stereotypes would mean the retrieval of a list instead of a single stereotype. The templates would still be valid, as it would be the application’s responsibility to distinguish between the model types, and to hand over the implementationsAsString. A line of a VTL template for Class, rendering Java code, might then (simplified) look like: $preparedClass.getVisibilityAsString()

158

Thorsten Sturm et al.

class $preparedClass.getNameAsString() extends $preparedClass.getSuperclassAsString() implements $preparedClass.getImplementationsAsString() { The $ signs are used for object references, while everything else is rendered directly. A possible result for a class ”Order Request” might be: public class Order Request extends Request { Comparing the template code line with the resulting code line shows that the template code gives a fairly good impression of what the resulting code will look like. The intent of the template code line (the class signature) is instantly recognizable. At every run of the code generation, the prepared elements providing the needed model information are initialized, and the Velocity context is filled with them. Initializing the prepared elements and applying the template is fast enough to enable on-the-fly code generation, which is used within the application to show a code preview of every selected model element. This demonstrates the liveness of the chosen approach. In addition, the prepared elements can check if their model elements are fit for code generation or whether, e. g., a class has no name. Influencing the Transformation. Changes to the code generation are either modifications of the resulting code or modifications of the information preparation. Changing the resulting code format means editing the template (examples follow in the next section). The template language is simple to read but powerful enough with conditional branches, loops, and string variables. More complex tasks can be exported to macros, which can be shared between templates through macro libraries. As the template language is interpreted, changes to the template are immediately visible in the next generation run. The modeling application itself remains unchanged. Changing the information preparation is a little more work, but is required when more information from the model is needed for the code generation (and one decides to retrieve it in the modeling application, not in the template). The shipped set of prepared elements can either be subclassed, or the mapping from a model element class to a prepared element class can be altered. Either modification needs implementation work in the programming language of the modeling application, in this case, Java. In order to reduce the dependency on the modeling application, these changes can be implemented as plug-ins. A public API provides the functionality to integrate new plug-ins as well as for modifications to the setup of the code generation process. Benefits. The availability of a template-based code generation to the application developer using a modeling tool has several benefits. Users of the tool can weigh the cost-benefit relation and decide to what extent they are interested in modifying the generation process itself, or if they rather stick closely to the provided templates. The developer can modify the style of the resulting code, can add more generated code (like information from state diagrams or

Generating Code from UML with Velocity Templates

159

test code from use cases), and can even set up entirely new target languages by creating a new set of templates and possibly of prepared elements. The application developer has no need to contact the modeling tool vendor in order to have a change in the code generation implemented. Individual preferences for the platform-specific model can be reflected in the code generation process directly. Already, enhancements that generate Java code for stateful classes and for OCL constraints, and also for HTML documentation of the UML 1.x vocabulary, have been implemented using the presented framework. 3.1

Examples

Two short examples demonstrate the ease of using templates combined with prepared elements in order to customize the code generation. The examples are taken from and use the code generation build into 01234516 819 :; 10) // This class has many attributes. If it is not a data

160

Thorsten Sturm et al.

// container, you might want to refactor. #end #if ($preparedAttributes.size() = 0) // This class has no attributes. Consider making // it a singleton. #end #if ($preparedOperations.size() > 10) // This class has many operations. Consider a refactoring. #end The next code generation run will show statistics and suggest these modifications, if necessary. The shortcoming of these simple examples is that the method bodies have to be written in a platform-specific way. If the decision for a programming language has been made, round-trip features help the synchronization of code and model. Many projects follow this approach successfully, although it is not quite what was intended. For a true MDA development process, the behavioral features of the model also have to be created in UML and transformed into a platform-specific version. An existing implementation of this concept is the generation of Java code from state diagrams that uses enhanced templates and special prepared elements to traverse the UML elements for state machines.

4

Conclusion

Automated code generation guides the way for model-driven development with UML models as the central artifact throughout the software development process. Automated transformation from the abstract application model to different platform-specific implementations is a precondition to this approach. Liveness, maintainability and extensibility are the key characteristics of the transformation process to make it actually usable in daily work for different users and platform requirements. Only highly customizable generation processes can be a real competition in quality to applications that were hand-made to fit special platform requirements. Amongst the different concepts and approaches for generating code, the translative approach using templates meets most of the demands and shows most promise. Combining templates with application code that handles the navigation logic and language-independent preprocessing of the model information enables a code generation framework to be fast, flexible and easy to customize to platform specifics. The modeling tool =>?@BC>D E>F GHI offers such a code generation architecture. Based on the open source project Velocity, the code generation framework implemented there shows the flexibility and speed that the template-based approach promises. Compared to code generation using XSLT, the template-based approach allows for shorter development cycles and better customization. Combined with powerful round-trip mechanisms, template-based code generation has the potential to make the vision of Model-Driven Architecture come true.

Generating Code from UML with Velocity Templates

161

Acknowledgments The authors would like to thank the developers of Velocity for their work and for donating their efforts to the open source community.

References [1] Rodney Bell. Code Generation from Object Models. http://www.embedded.com/98/9803fe3.htm . 152 [2] Marko Boger. dejay.org – Bringing Distribution and Concurrency Together. http://www.dejay.org. 151 [3] Apache Software Foundation. Velocity. http://jakarta.apache.org/velocity/. 156 [4] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns - Elements of Reusable Object-Oriented Software. Addison-Wesley Publishing Company, Reading, Massachusetts, 1995. 151 [5] Michael Kay. XSLT Programmer’s Reference. Wrox Press, 2000. 154 [6] Stephen J. Mellor. Automatic Code Generation from UML. C++ Report, June, 1999. [7] Stephen J. Mellor and Neil Lang. Developing Shlaer-Mellor Models Using UML. Technical report, Project Technology, Inc., San Leandro, California, 1997. [8] W3C. XSL Transformations (XSLT) Version 2.0. http://www.w3.org/TR/xslt20/.

Does Your Software Creak as It Runs? Bran Selic Rational Software Canada

Abstract. We are often so overwhelmed with the difficulty of writing logically correct software that we tend to underplay or even ignore the influence of the underlying computing platform. In some cases, this negligence has been raised to the level of a design principle, based on a dangerously naive interpretation of the idea of “platform independence”. After all, it is the platform that gives life to our logic and, as we demonstrate, its effect on software can be profound. We argue that software is not as far removed from physics as many imagine (or hope), that quantity can affect quality, and that, paradoxically, true platform independence cannot be achieved unless the platform is properly factored into design. We then outline a general approach that addresses this issue and show how it can be realized with UML.

J.-M. J´ ez´ equel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, p. 162, 2002. c Springer-Verlag Berlin Heidelberg 2002


Integrating the Synchronous Paradigm into UML: Application to Control-Dominated Systems Charles Andr´e, Marie-Agn`es Peraldi-Frati, and Jean-Paul Rigault Laboratoire Informatique Signaux et Syst`emes (I3S) Universit´e de Nice Sophia Antipolis CNRS UMR 6070 {andre,map,jpr}@i3s.unice.fr http://www.i3s.unice.fr

Abstract. The Synchronous Paradigm proposes an abstract model integrating concurrency and communication, deterministic thus simple, semantically well-founded thus suitable to formal analysis, producing safe and efficient code. However combining this model with the objectoriented approach is still challenging. This paper explores how an UMLbased methodology can be set up, making it possible to use the Synchronous Paradigm in combination with other (more classical) techniques to develop control-dominated systems. It addresses the issue of representing behavior in a semantically sound way using the synchronous models, of relating behavior and structure, and of mixing synchronous and asynchronous behavior though an extended notion of (ROOM-like) “capsules”, the synchronous islets. We also briefly mention the extensions and modifications in the UML meta-model necessary to support this methodology.

1 Control-Dominated Systems Control-dominated systems are frequent in real time applications, especially in embedded ones (automobile, air and space, process control, integrated manufacturing, robotics...). These systems display a unique combination of characteristics. They are usually multi-modal, alternating their functioning between several operating modes. They are reactive which implies to deal with concurrency, communication, and pre-emption. They have to satisfy stringent constraints (correctness, response time) thus they have better be deterministic. Finally they may be life or mission critical and consequently they should be submitted to formal verification and validation. The reactive nature and its consequences are the major reasons why the behavior of these systems is delicate to handle. A way of reducing the behavioral complexity is to have them evolve through successive phases. During one phase, only the external events which were present at the beginning of the phase and the internal events that occurred as a consequence of the first ones are considered. The phase ends when some stability (fixed-point) has been achieved (or when some external “clock” decides that it is over). J.-M. J´ ez´ equel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 163–178, 2002. c Springer-Verlag Berlin Heidelberg 2002


164

Charles Andr´e et al.

WJ call such a phase an instant. Indeed, during such an instant, the time seems to be suspended (the external events are frozen). An instant-based system will be called a synchronized system. The so-called synchronous models are among these instant-based schemes. Atomicity of reactions is often necessary in reactive systems. The UML “runto-completion” is a way to satisfy such a requirement. The synchronous models satisfy it, “by construction”. These dominated control systems are not only delicate behavior-wise. The complexity of modern systems makes it even more necessary to analyze, design, implement, and verify these systems in a structured (hierarchical) way, hence the need for enforcing the relationship between their structure and their behavior. Thus we need to represent the architecture of the system as well as its behavior, in an integrated way. Combining powerful and semantically sound models of behavior with the object-oriented approach is certainly a path worth considering. The UML de facto standard, which proposes both behavioral and architectural points of view, is certainly the notation of choice. This paper is about extensions and modifications to UML to integrate the power of the Synchronous models. The following section (2) describes the common concepts of synchronized models and presents the definition of their ideal (limit) instance: the Strictly Synchronous Model. Section 3 is the core of the paper; it deals with extending UML to support the synchronous paradigm. The next section (4) illustrates the approach on an example. We finally conclude and propose some forthcoming developments.

2 “Synchronized” Behavioral Models 2.1

Common Concepts

Signals and Events Our systems react to input events by producing output events. An event corresponds to the occurrence of a signal, and a signal may carry a value. Instant A synchronized system evolution concentrates into successive instants which are defined system-wide1 . An instant is characterized by a Begin Of Instant (BoI) and an End Of Instant (EoI). BoI and EoI are in monotonic order and stricly alternating (instants cannot intersect). The input events are frozen at BoI; the output events are available at EoI. Between two instants (more specifically, between EoIi and BoIi+1 ) nothing happens. The notion of an instant gives a clear meaning to simultaneity (everything which happens during the same instant), and to past and future. “Strict future” designates the next instant(s). Broadcast and Combine During an instant, the various (concurrent) parts of the system can produce and absorb events. The events (external as well as 1

Well, in fact for this part of the real system that is to be considered synchronized.

Integrating the Synchronous Paradigm into UML

165

internal) are broadcast (that is their target is not explicitly designated and an event is available for any process waiting for it in the same instant). In contrast with most of non-synchronous approaches, the same signal may be emitted several times within a given instant. To cope with this situation, a signal with possible simultaneous emissions must be associated with a commutative and associative combination function (usually part of the signal declaration). This function returns the unique value of the signal in the corresponding instant, in accordance with the synchronous semantics. Of course, not all signals are capable of combining their values. Multiple simultaneous emissions of some signals may be forbidden. Note that broadcast and combine are model level features, not runtime ones. As such, synchronous language compilers can resolve they at compile-time. Semantics The semantics relies on the search for a (unique) fixed-point during each instant. For the imperative synchronous languages and models, the semantics can be constructive: it is established by propagating positive facts (e.g., the effective presence of a signal) and possibly negative ones (e.g., the certainty of the absence of a signal) during an instant. 2.2

Variants

Strict Synchronous The strict synchronous model is the limit case for synchronized systems. It corresponds to BoI = EoI. Thus an instant has a null duration, the reaction is instantaneous, the instant-wise simultaneity is true simultaneity. It is supported by both imperative languages like Esterel [7] and data flow ones like Lustre and Signal [17]. The strict synchronous model proposes both a model of concurrency and a model of communication. The concurrency model is deterministic, hence simple, and yet powerful; it is abstract (no need for extra mechanisms like semaphores, monitors...); and it is semantically well-founded. Signals abstract communication: broadcast and combine make it simple to communicate, efficient instantaneous protocol dialogs are easy to set up (if not to understand). As a consequence, a synchronous program may be viewed as a set of (very) lightweight processes, composed in parallel and communicating through broadcast signals. The simplicity and well-foundedness make it possible to consider formal analysis. Tools can produce safe, efficient and compact code. However there are a number of drawbacks. First the semantic fixed-point does not always exist; thus some programs are (semantically) incorrect. This is due to “temporal paradoxes” also known as “causality cycles”. These can be detected at compile-time but are not easy to avoid. They are indeed a programmer’s nuisance. Second, strict synchronous languages are good at expressing control, but less at ease for general data manipulation; the formal analysis methods do not handle values very well either. Last, since they imply a sort of centralized coordination (centralized clock), the strict synchronous systems are difficult to distribute.

166

Charles Andr´e et al.

Relaxed Synchronous Models Fo K practical reasons as well as to cope with the drawbacks of strict synchrony, several works have proposed to relax the synchronous model hypotheses. Execution Machines: A first and compelling practical reason to relax arises when trying to put the synchronous model into practice. Indeed the “real world” is not synchronous, our processors are not infinitely fast, and reactions cannot be absolutely instantaneous. So we need to define execution machines that adapt the inherently asynchronous application events to their ideal pure synchronous counterparts. The responsibility of an execution machine is to collect the external input events, to impose BoI and EoI, to decide which external input events will be available for the synchronous program during an instant, and to propagate the output events to other parts of the system. When designing synchronous execution machines, two important questions must be answered: is the strict synchronous model a reasonable approximation of the reality? is the machine fast enough (compared to the flow of input events) so that its reaction may be considered of null duration? This is a performance analysis issue, related to “real” time2 . Discussion about this is out of the scope of this paper. Interested readers may refer to papers presenting software implementations [4] or hardware solutions [6]. Note that there is no need for a schedulability analysis, at least within the synchronous program itself. In fact, the control generated by the compiler is a static scheduler of the actions to be performed by the reactive system. By a simple analysis of the generated code, given a target architecture, it is possible to compute the best and the worst case execution time for each reaction [5]. Another reason to relax the model is to cope with the two main drawbacks of pure synchrony: existence of “causality cycles” and difficulty to apply to distributed systems. When relaxing, BoI and EoI are no longer equal (BoIk < EoIk of course), and the fixed point semantics has to be revisited. Since the construction of the fixed-point semantics is based on propagating facts (section 2) one can obtain several ways of relaxing the model by choosing which facts to propagate, and when they are propagated. These relaxed models demonstrate that the strong hypotheses of the Strict Synchronous Model can be weakened without losing the notions of instant, signal, and broadcast/combine communication. Besides being more realistic, these models avoid the unpleasant temporal paradoxes due to instantaneity. Thanks to their instant-based semantics, they remain relatively tracktable and mostly deterministic, even for complex systems. This point of view has been adopted for long in hardware: synchronous circuits are far easier to design than their asynchronous counterparts. We mention here some of these extensions. Synchronous Objects: This was one of the first attempts to mix the objectoriented paradigm with the synchronous approach [10, 2]. Synchronous modules 2

As opposed to the logical time defined by the event flow in the synchronous model

Integrating the Synchronous Paradigm into UML

167

are used to define the behavior of reactive sub-systems. Each sub-system is abstracted as a class whose methods are related to signals (receiving or emitting), and whose behavior is expressed by the synchronous code. Instances of these classes (synchronous objects) can be inter-connected to realize more complex reactive systems. The behavior of the whole system can be still a synchronous behavior, provided some assembly rules are respected. F. Boulanger developed a technique to schedule the different objects to ensure an instant-based behavior. This scheduling can be either static (a very efficient solution) or dynamic (a convenient solution for rapid prototyping). Weak Synchronous Systems: F. Boniol [9] defined a process algebra called C o R e A (COmmunicating REactive Automata) based on a synchonous semantics of concurrency and a weak synchonous semantics for communication between concurrent processes. Communications take one time unit of a global clock. Boniol’s weak synchrony have been successfully applied to distributed applications built on a RTLAN (Real-Time Local Area Network). For instance, L. Blanc in his thesis [8] considers strict synchrony for local communication and weak synchrony for communication over the network. Such characteristics guarantee deterministic behavior for the distributed system from a logical and a temporal perspective. The quasi synchronous approach: It has been introduced by P. Capsi and R. Salem [12]. The system is considered as a set of sub-systems locally synchronous that exchange information via a shared memory. Exchanges are periodic. There is no “global clock” in this system as the authors consider that clocks are “quasi equivalent”. They have an abstract view of the asynchronism by modeling the “clock drift”. They propose an algorithm for the distribution of Lustre code that guarantees disjoint acquisition phase and transitions executions. Reactive Objects: They have been introduced by F. Boussinot et al. [11]. The reactive object model is an object-based formalism matching the reactive paradigm. Methods can be invoked using instantaneous non-blocking send orders, which are immediately processed (that is, processed during the current instant); moreover, a method cannot execute more than once at each instant. In this model, a process3 is executed until it blocks, waiting for some event which is not yet known to be present in the current instant. Only the positive fact are propagated during an instant, possibly unblocking a waiting process. The instant terminates when all processes are blocked. In this paper we shall not deal with integrating the relaxed models into UML. We shall only concentrate on the integration of the strict synchronous model. Indeed the latter should be considered as a foundation model. All relaxed models should exhibit the following suitable property: if there is a strict synchronous 3

Remember these are very lightweight processes, with a granularity of possibly a few basic statements.

168

Charles Andr´e et al.

solution4 , there should be (at least) one relaxed solution. Thus it is important to first consider the impact of integrating the ideal model into UML, before looking at its variants.

3 Integrating the Synchronous Paradigm into UML 3.1

Relating Behavior and Structure

The strict synchronous model is well-adapted to structuring the control aspect of a system, but fails at expressing architectural issues. The modules, or processes, or parallel branches that are found in the synchronous languages are not objects, nor are they associated with objects. There have been several early attempts to add object-oriented capabilities to the synchronous model [10, 2]. Besides the gain in expressing the architecture and the relationship between architecture and behavior, they make it possible to represent systems that are still control-dominated but that exhibit a significant data processing activity. 3.2

UML and Control Systems

The Unified Modeling Language (UML) is now the lingua franca of (objectoriented) software engineering and, in the real-time domain as well as in all the other domains of the software industry, using the UML is becoming a key issue. UML offers multiple points of view on the system, and some of these points of view are rather universal. However, when it comes to modeling specific properties of real-time systems, in particular their behavior, the models proposed by UML are too general to fit the requirements. Of course several real-time extensions to UML (or “profiles”) have been proposed or are underway (see for instance [19] for a (non) exhaustive list). Let us mention two of these, among the most influential ones. Real-Time UML (RT-UML) [14] demonstrates how UML can be used to model real-time systems. Although a complete method is described, almost no extensions to UML are introduced (except the notion of Timing Diagrams which is perfectly orthogonal to the UML models). The models are simulable and executable. RTUML is implemented in the Rhapsody commercial tool (from I-Logix). UML for Real-Time (UML-RT) [23] goes somewhat further. It is an UML adaptation of the ROOM method [22]. It introduces class stereotypes (capsule, protocols, ports, connectors) corresponding to frequent real-time entities and extends the UML collaboration diagrams to represent the structural view of the system (structure diagrams). Here again the models are simulable and executable and UML-RT is implemented in the Rose Real Time tool (from Rational). ACCORD/UML [16] proposes another interesting approach where a system is a collection of active and passive real-time objects. The messages exchanged 4

Which is unique by definition.

Integrating the Synchronous Paradigm into UML

169

among the objects may be temporally constrained. They correspond to method call or signal sending. All these extensions and adaptations of UML do not rely on the Synchronous Model. To represent the behavior of the system, they use the classical UML means: state machines (a variant of StateCharts [18]) and interaction diagrams. These models have a non deterministic semantics and thus they are not convenient for representing stringent constraints and, even worse, not adapted to formal property analysis. 3.3

Adapting UML to Comply with the Synchronous Model Hypotheses

In a recent work, a team from Dassault Aviation [20] proposed a close integration between the Strict Synchronous Model and the UML. They defined object-oriented extensions to the Esterel language (Esterel++, a pre-processor to pure Esterel). They used SyncCharts, a graphical companion to Esterel [1], for modeling the behavior of objects and they borrowed from ROOM/UMLRT the notions of capsules, protocols... as special kinds of classes but with a somewhat different semantics, more suited to the synchronous world. They also adopted the ROOM/UML-RT notion of a structure diagram and they adapted Rational Rose to represent these concepts and to generate Esterel++ code. The SyncCharts, which cannot be represented or edited within Rational Rose, are drawn, simulated, and verified using the Esterel Studio commercial tool [15]. The corresponding combination of tools is now routinely used within the Dassault company. Dassault’s approach is indeed a first and promising attempt, but more work needs to be done to have a smooth integration of the synchronous paradigm into UML. The rest of this subsection proposes some tracks for this. We consider here the architectural representations of UML (class and structure diagrams) and the behavioral ones. The other points of view of UML (use case, component, deployment) are either usable unchanged or their semantics is not precise enough to be impacted by the real-time and synchrony issues. Class Diagram As far as the description of classes is concerned, the UML diagrams can be adapted easily to the Synchronous model. We need classes for reactive objects and at this end we borrowed the notion of a “capsule” from ROOM/UML-RT [23]. It is a very convenient model for representing objects with complex communication. A port is typed by a “pluget”5 , a special kind of “interface” consisting of a list of signals. All these extensions are well known, they are not specific to the synchronous model, and they can be realized using UML stereotypes. To go further, we specialize these concepts for the synchronous case: 5

UML-RT/ROOM denotes the same notion by the term “protocol”; we avoided it since, first, it appears confuse-wise to us and, second, there are some differences between “pluget” and UML-RT protocols. One of these differences is that our “pluget” are hierarchical: they can contain other plugets, not simply signals.

170

Charles Andr´e et al.

– “S signal” (Synchronous signal) is a stereotype denoting a class of synchronous signals that can be broadcast and combined. UML does not seem to support broadcast per se: UML signals can be sent to several targets at the same time, but apparently either the targets have to be designated or computed (diffusion list as opposed to general broadcast) or, if the targets are implicit, the semantics is yet undefined in UML. And when it comes to signal combination, this is a notion UML is oblivious of. Yet, combination is a primitive feature for the synchronous semantics of signals and should be taken into account at the topmost level (the Signal meta-class). Therefore “S signal” is not a specialization of the Signal meta-class. This might change due to the evolution towards UML 2.0. – “S capsule” (Synchronous capsule) is a stereotype denoting a “capsule” which has a specific port (its “clockPort”); through the clockPort, an “S capsule” object will receive its begin and end of instant signals. – “Islet” is a stereotype designating a collection of “S capsule”s sharing the same “clockPort” generator; thus the islet provides the (synchronous) context; all its “S capsule”s have the same notion of an instant and the “Islet” has the responsibility to provide BoI and EoI. Note that an “Islet” is a regular “capsule”, but not an “S capsule” in general6 ; thus the “Islet”s communicate asynchronously; only within an “Islet” is the communication synchronous. Figure 1 shows a simplification of extended UML meta-model to support the previously described stereotypes (our work is currently based on the UML 1.4 meta-model). In particular we do not show or detail the hierarchy of “port”s and “S signal”s. For sake of brevity, neither we do not show either the wellformedness rules (expressed in OCL) on these meta-model diagrams. Structure Diagram Since an “Islet” is composed of “S capsule”s communicating through their “ports”s, the connections and renaming of signals must be represented by a specific diagram. Such diagrams already exist in ROOM and UML-RT, and there is a proposal to introduce them in UML 2.0. They are called structure diagrams. General broadcast/combine does not require any special notation. However it is sometimes useful to restrict the partners of the communication and to designate them explicitly, still committing to the many-to-many simultaneous communication paradigm. Structure diagrams are the right place to express such constraints. We achieve this by introducing one extension to the ROOM-like structure diagrams: a kind of bus links all the communication partners (see figure 6 in next section for an example). Note that structure diagrams may be used either to represent the instances constituting a (sub-)system (an extended object diagram, showing the interconnections) or the internal organization of the elements constituting an aggregate. 6

Although it can be an “S capsule”, but with a LNOQRQST clock reference

Integrating the Synchronous Paradigm into UML

171

Fig. 1. A UML meta-model for the class stereotypes to support the strict synchronous model In the latter case the components represent roles more than instances. They may be subject to substitution (according to some UML generalization). Another useful extension would be to represent template capsules, with type parameters as well as integer constants. There should also be a way to represent duplicated elements. We are currently working on such extensions. Behavioral Models Of course the main impact of the synchronous model is onto the UML behavioral points of view. The latter are of two kinds: the first one describes the internal behavior of (the instances) of a class. The second represents the exchange of messages between class instances. Intra-objects: UML uses state machines, a variant of Harel’s StateCharts [18] to describe the internal state behavior of a class. For our purpose, there are at least two main drawbacks with this state-machine model. The first drawback defeats UML state-machine use in the strict synchrony hypothesis: these state machines are inherently asynchronous and consequently non deterministic. Their semantics is given in term of waiting queues, without any indication on how and when the events in the queue are handled. The notion of instant and simultaneity are not defined. Relying on such a non-deterministic feature would clobber all the advantages of the synchronous model (simplicity, determinism, suitability to formal analysis).

172

Charles Andr´e et al.

VWX second drawback is that UML state machines do not enforce a strict hierarchical organization: the macro-states are not encapsulated since transitions may freely cross their borders. Of course this feature has a strong power of expression, but it makes the behavior harder to understand (like goto’s in a program!), harder to compose, and harder to prove. Indeed the strict compositionality is the key to handle proofs on complex systems. Thus we use the SyncCharts [1], a graphical companion of synchronous languages. It proposes a purely synchronous vision of the behavior with a strictly encapsulated hierarchy of states. SyncCharts translate directly into Esterel code and thus may take advantage of the simulation and model checking tools that were developed for this language (SyncCharts has been chosen as the main way of describing behavior in the EsterelStudio commercial tool [15]). However, the SyncCharts model cannot be obtained as a simple specialization of the UML state machines (mostly because of state encapsulation). The corresponding meta-model, which is given on figure 2, corresponds to a heavyweight extension. Actions associated with states and transitions, and triggering events and guards associated with transitions are not detailed. They have been adapted to support “S signal”. Stg stands for State Transition Graph, a connected graph made of states and transitions. Figure 7 in the next section shows an example of a syncChart.

Inter-objects: The communication between objects is usually expressed using UML interaction diagrams. We are mainly interested here in a time- and eventbased representation (even though our time is only logical), thus our focus is more on the sequence diagrams than on collaboration ones. There has been much discussion about sequence diagrams. Obviously the inventors of UML wanted to keep the model of interaction simple, so that it may be used by non computer specialists. This is certainly a point worth considering. However, the model is really too simple, even simplistic, when it comes to represent complex interactions (scenarios): no loops, weak representation of conditions, no structure... Moreover a sequence diagram presents an ordering of events exchanged between the objects participating to a scenario. But is this order chronological or causal7 ? Are the flows of events universal (a mandatory behavior) or existential (an optional behavior)? Sequence diagrams as they are defined in current UML are definitely inadequate for expressing synchronous communication and its underlying causality. Message Sequence Charts (MSC [21]) have existed before UML sequence diagrams and have a greater power of expression. The recent Life Sequence Charts (LSC) [13] adds to MSC several features, especially the notion of existential and universal behavior. These models are going to find their way into new versions of UML, at least partially. 7

Chronology is not causality. YZ[\ ho]^ _`bZ c`Zc\_` ho] (“after this, hence because of it”) is a sophism that Francis Bacon denounced a long time ago.

Integrating the Synchronous Paradigm into UML

173

Fig. 2. A UML meta-model for SyncCharts Our own model, Synchronous Interface Behavior (SIB [3]), is much inspired by MSC. It is even closer to LSC: the two models have been developed independently, and yet they introduce similar notions (structure, existential and universal behavior. . . ). SIB adds features to represent simultaneity and the notion of instant to scenarios. Any SIB can be automatically translated into a semantically equivalent Esterel module. This module is then composed (synchronous parallel composition) with the controller to be validated. This module is an observer [17], which can emit a failure or a success signal, according to the observed behavior. A SIB represents either a history the system should perform at least once (existential form) or a safety property (invariant). We do not insist on SIB here, since it is a work underway. If we can easily represent the trace of the events at the interface of an individual object (and perform formal analysis on it), we still have to decide (among several solutions) how to represent (graphically) the notion of an instant, when several objects communicate (in a scenario). Indeed, proposing a meta-model for SIB is premature; it seems wiser to wait for the precise integration of MSC-like diagrams into forthcoming UML versions.

174

Charles Andr´e et al.

4 Example 4.1

Presentation of the Seat Controller

(a) Environment panel

(b) Control panel

Fig. 3. The seat simulation environment

We illustrate our approach with some diagrams extracted from the example of a (luxury) car seat8 . The seat is composed of 6 motors which allow to modify the position of its different parts (distance to the steering wheel, inclination of the back, height of the bottom. . . ). Each motor has three states: stopped, forward, and backward. When running, a motor emits a “tick” signal at each revolution. The seat adjustments are limited in their magnitude and characterized by a number of ticks. The motors are gathered into 2 groups of 3 motors with activation priority within a group (that is a motor has to be stopped if a motor with an higher priority in the same group gets activated). The motor activation may be manual, through a control panel. It may also be automatic with several modes: calibration phases, courtesy (e.g., putting the seat backwards when the door is opened), and memorization (e.g., reaching a previously memorized seat position). Finally there are some constraints that some seat functions (heating, displacement) have to obey and that depend on the environment of the car. Figure 3 describes the simulation environment of the car that we have designed using Tcl/Tk. 4.2

Class and Structure Diagrams for the Seat Controller

Figure 4 presents a snapshot of the main classes of the application. The details of the MotorController “Islet” and the “plugets” that it uses are described on 8

The example is inspired by a competiton initiated by Daimler Chrysler.

Integrating the Synchronous Paradigm into UML

175

Fig. 4. Top level class diagram for the seat controller figure 5. The stereotypes “input” and “output” correspond to simple ports, composed of a single signal whereas “i port” and “o port” denote compound ports with several signals. The ports are typed with “pluget”s: for instance, this figure shows that Cmd stands for a combination of three signals: M, P, and Z; the Esterel relation (in the note) expresses that these signals are mutually exclusive (in the same instant). G Cmd itself is composed of 3 “i port”s of type Cmd. The ˜ character corresponds to the “conjugated” pluget (obtained by reversing inputs and outputs). The structure diagram of figure 6 describes the internal organization and connections of the components of a (motor) Group, composed of 3 MotorDrivers. Note the bus-like notation to represent the broadcast/combine of signals, and also the template-like notation which expresses that it is more a role diagram than an instance one. 4.3

Behavioral Aspects of the Seat Controller

As already mentionned we concentrate on the state representation (inter-objects). Each “S capsule” is associated with a syncChart to express its internal state model. As a matter of example, figure 7 presents the syncChart of the MotorDriver capsule (see figure 4). Note the use of the dot notation to refer to the constituents of a port (e.g., logicalState.M).

5 Perspectives In this paper we described some tracks to integrate the Synchronous Model as smoothly as possible into UML. We try to use, whenever applicable, lightweight extensions. However, the representation of synchronous behavior is still on the heavyweight side. We strive to “alleviate” them, and there might be hope to succeed (at least partially) with some forthcoming UML 2.0 proposals.

176

Charles Andr´e et al.

(a) Details of the MotorController “Islet”

(b) The “plugets” used by the MotorController

Fig. 5. The MotorController “Islet” and its “pluget”s cmdIn:G_Cmd M1,M2,M3:MotorDrive

Group

S

ack S

always

logicalState:G_Cm d

M1

S

M2

S

M3

cmdOut:G_Cmd

Fig. 6. Structure diagram for a group of three motors The work presented here is still in progress and will follow three main axes. The first is to provide tools to manipulate the synchronous islets, the structure diagrams, and especially the Synchronous Interface Behavior notation. There is still work to do so that SIB may cope with the synchronous hypotheses, in a graphically convincing way. It is mostly a matter of notation and layout, but this is an important issue in modeling. Second, we wish to extend the model of “synchronous” islets to cope with the relaxed synchronized models. This would open the way to a wider range of applications, including distributed ones. Third, we need to define a methodology mixing the classical UML notation and the synchronous models (be they strict or relaxed). Indeed, the modeling entities we proposed here are not supposed to replace the classical UML classes, state machines, sequence diagrams, etc., nor are they to supersede well-known

Integrating the Synchronous Paradigm into UML

177

Fig. 7. SyncChart for “S capsule” Motordriver extensions such as capsules. We plan to use all of them together, having recurse to the synchronous model only for those parts of the system that are controldominated and that have to face stringent constraints and formal analysis. Being able to model such a system composed of collaborating synchronous and asynchronous parts is still a challenge.

References [1] Charles Andr´e. Representation and Analysis of Reactive Behavior: a Synchronous Approach. In dghjklalmgoaq rosmouuwmos mo xyzluhz {ppqm|almgoz }drx{~. IEEESMC, 1996. 169, 172 [2] Charles Andr´e, Fr´ed´eric Boulanger, Marie-Agn`es Peraldi, Jean-Paul Rigault, and Guy. Vidal-Naquet. Objects and Synchronous Programming. {€‚Aƒ€€‚ „rx{, 31(3), 1997. 166, 168 [3] Charles Andr´e, Marie-Agn`es Peraldi-Frati, and Jean-Paul Rigault. Scenario and Property Checking of Real-Time Systems Using a Synchronous Approach. In …l† €oluwo‡lmoo‡q xympozmkh go ˆ‰uct-Oriented Real-Time Distributed Computing (ISORC 2001), Magdeburg, Germany, May 2001. IEEE. 173 [4] C. Andr´e, F. Boulanger, and A. Girault. Software Implementation of Synchronous Programs. In Proceedings of the Second International Conference on Application of Concurrency to System Design, Newcastle upon Tyne, UK, June 25–29, 2001, pages 133–142. IEEE Computer Society, 2001. IEEE Computer Society Press Order Number PR01071 Library of Congress Number 2001090878 ISBN 0-76951071-X. 166 [5] C. Andr´e and M.-A. P´eraldi. Predictability of a r t x 2 0 0 0 -based Implementation. In Real-Time System, volume 10, pages 223–244, May 1996. 166

178

Charles Andr´e et al.

[6] G. Berry. A Hardware Implementation of Pure esterel. Miami, January 1991. ACM Workshop on Formal Methods in VLSI Design. 166 [7] G´erard Berry. Essay in Honor of Robin Milner, chapter The Foundations of Esterel. MIT Press, 2000. 165 [8] L. Blanc. R´epartition de syst`emes temps r´eel ` a contrˆ ole pr´edominant. PhD thesis, Universit´e de Nice-Sophia Antipolis, October 1999. 167 [9] F. Boniol. Etude d’une s´emantique de la r´eactivit´e : variations autour du mod` ele synchrone et application aux syst`emes embarqu´es. PhD thesis, ONERA-CERT (Toulouse), December 1997. 167 [10] Fr´ederic Boulanger. Int´egration de modules synchrone dans la programmation par objets. PhD thesis, Supelec, universit´e de Paris Sud, December 1993. 166, 168 [11] F. Boussinot, G. Doumenc, and J-B. Stefani. Reactive Objects. Ann. Telecommunication, 51(9–10):459–473, 1996. 167 [12] P. Caspi and R. Salem. The Quasi-Synchronous Approach to Distributed Control Systems. In F.Cassez, C.Jard, B.Rozoy, and M.Ryan, editors, Proceedings of the Summer School ”Modelling and Verification of Parallel Processes” (MOVEP’2k), pages 253–262, 2000. 167 [13] W. Damm and D. Harel. LSCs: Breathing Life into Message Sequence Charts. In 3rd IFIP Int. Conf. on Formal Methods for Open Object-based Distributed Systems (FMOODS’99), pages 293–312. Kluwer Academic Publisher, 1999. 172 [14] Bruce Powell Douglass. Doing Hard Time: Developping Real Time Systems with UML, Objects, Frameworks, and Patterns. Addison-Wesley, 1999. 168 [15] Esterel Technologies. http://www.esterel-technologies.com. 169, 172 [16] S. G´erard. Mod´elisation UML ex´ecutable pour les syst`emes embarqu´es de ´ l’automobile. PhD thesis, Universit´e d’Evry, October 2001. 168 [17] Nicolas Halbwachs. Synchronous Programming of Real Time Systems. Kluwer Academic Publisher, 1993. 165, 173 [18] David Harel. StateCharts: a Visual Formalism for Complex Systems. Science of Computer programming, 8, 1987. 169, 171 [19] L. Kabous and W. Nebel. Modeling Hard Real-Time Systems with UML: the OOHARTS Approach. In Proceedings “UML”’99, number 1723 in LNCS, Fort Collins, CO, USA, October 1999. Springer Verlag. 168 [20] Yann le Biannic, Eric Nassor, Emmanuel Ledinot, and Sylvan Dissoubray. Sp´ecifications objets UML de logiciels temps r´eel. In RTS, March 2000. 169 [21] E. Rudolph, P. Graubmann, and J. Grabowski. Tutorial on Message Sequence Charts. Computer Networks and ISDN Systems, 28, December 1996. 172 [22] Bran Selic, G. Gullerkson, and Paul T. Ward. Real-time Object-Oriented modeling. John Wiley and Sons, 1994. 168 [23] Bran Selic and James Rumbaugh. Using UML for Modeling Complex Real Time Systems. Technical report, ObjecTime, 1998. http://www.objectime.com. 168, 169

A UML Profile for Real-Time Constraints with the OCL Stephan Flake and Wolfgang Mueller C-LAB, Paderborn University, Fuerstenallee 11, 33102 Paderborn, Germany {flake,wolfgang}@c-lab.de

Abstract. This article presents a UML profile for an OCL extension that enables modelers to specify behavioral, state-oriented real-time constraints in OCL. In order to perform a seamless integration into the upcoming UML2.0 standard, we take the latest OCL2.0 metamodel proposal by Warmer et al. [22] as a basis. A formal semantics of our temporal OCL extension is given by a mapping to time-annotated temporal logics formulae. To give an example of the applicability of our extension, we consider a modeling approach for manufacturing systems called MFERT. We present a corresponding UML profile for that approach and combine both profiles for formal verification by real-time model checking.

1

Introduction

The Object Constraint Language (OCL) is part of the UML since version 1.3. It is an expression language that enables modelers to formulate constraints in the context of a given UML model. OCL is used to specify invariants attached to classes, pre- and postconditions of operations, and guards for state transitions [13, Chapter 6]. But currently, OCL misses means to specify constraints over the dynamic behavior of a UML model, i.e., consecutiveness of states and state transitions as well as time-bounded constraints. However, it is essential to specify such constraints to guarantee correct system behavior, e.g., for modeling realtime systems. In previous works, we have presented an OCL extension that enables modelers to specify state-oriented real-time constraints [10, 9]. Due to a missing OCL metamodel in the current official UML1.4 specification [13], we took an OCL type metamodel presented in [1] and performed a rather heavyweight extension by directly extending that metamodel. More recently, in reply to the OMG’s OCL 2.0 Request for Proposals, an extensive OCL metamodel proposal has been published by Warmer et al. [22] that addresses a better integration of OCL with other parts of UML. Though that proposal has not been adopted by the OMG yet, we apply that metamodel since it comprises the work of several significant contributions concerning the development of OCL in recent years. Based on that metamodel, we present a ’lightweight’ approach by defining a UML profile for our temporal OCL extension. For semantics, we present a mapping of (futureoriented) temporal OCL expressions to time-annotated formulae, expressed in a discrete temporal logics called Clocked CTL [18]. J.-M. J´ ez´ equel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 179–195, 2002. c Springer-Verlag Berlin Heidelberg 2002


180

Stephan Flake and Wolfgang Mueller

As an application example, we consider a manufacturing system. We take an existing notation called MFERT [20] which is dedicated to analysis and design of manufacturing systems, present a UML profile for that notation, and define the semantics for a UML subset by a mapping to time-annotated Kripke structures, so-called I/O-Interval Structures [19]. The two profiles are integrated by the relation of Clocked CTL formulae and I/O-Interval Structures. It is then possible to apply real-time model checking, i.e., a given model in the MFERT profile notation is checked if it satisfies required real-time properties specified by state-oriented temporal OCL expressions.

2

Related Work

This section gives an overview of approaches that (a) extend OCL for temporal constraints specification or (b) investigate alternative means to express behavioral real-time constraints for UML diagrams. Ramakrishnan et al. [15] extend OCL by additional rules with unary and binary future-oriented temporal operators (e.g., always and never) to specify safety and liveness properties. A very similar approach in the area of business modeling that additionally considers past-temporal operators is published by Conrad and Turowski [4]. Kleppe and Warmer [12] introduce a so-called action clause to OCL. Action clauses enable modelers to specify required (synchronous or asynchronous) executions of operations or dispatching of events. Similarly, the latest OCL2.0 metamodel proposal introduces message expressions [22]. Distefano et al. [6] define Object-Based TemporŠ‹ Logic (BOTL) in order to facilitate the specification of static and dynamic properties. BOTL is not directly an extension of OCL; it rather maps a subset of OCL into object-oriented Computational Tree Logic (CTL). Bradfield et al. [3] extend OCL by useful causality-based templates for dynamic constraints. Basically, a template consists of two clauses, i.e., the cause and the consequence. The cause clause starts with the keyword after followed by a boolean expression, while the consequence is an OCL expression prefaced by eventuŠ‹ ly, immediately, infinitely, etc. The templates are formally defined by a mapping to observationa‹ Œu-ca‹c‹us, a two-level temporal logic, using OCL on the lower level. In the domain of real-time specification, there exist two approaches. Roubtsova et al. [16] define a UML profile with stereotyped classes for dense time as well as parameterized specification templates for deadlines, counters, and state sequences. Each of these templates has a structural-equivalent densetime temporal logics formula in Timed Computation Tree Logic (TCTL). Sendall and Strohmeier [21] introduce timing constraints on state transitions in the context of a restricted form of UML protocol state machines called System Interface ProtocŽ‹ (SIP). A SIP defines the temporal ordering between operations. Five time-based attributes on state transitions are proposed, e.g., (absolute) completion time, duration time, or frequency of state transitions. All approaches that provide a formal semantics are due to formal verification by model checking. Roubtsova et al., though, do not use OCL for constraint specification in their formal approach, as they argue that ”Any extension of

A U M L Profile for Real-Time Constraints with the OCL

181

OCL to present properties of computation paths breaks the idea of the ‘guage and makes it eclectic”. In contrast to this, we think that the notion of execution paths can very well be introduced to OCL, as shown in our previous work and this article.

3

UML Profile for Real-Time Constraints with OCL

Due to space limitations, we cannot give a detailed description of OCL in this article. We presume that the reader has basic knowledge of OCL and refer to the Response to the UML2.0 OCL Request for Proposal, Version 1.5 by Warmer et al. [22] for further information about the language and the metamodel we apply. In the following, we refer to that metamodel as the OCL2.0 metamodel proposal. In contrast to current OCL1.4, nested collections are now supported in the OCL2.0 metamodel proposal, and our approach significantly relies on this new language feature. The remainder of this section is organized as follows. In 3.1, we extend the abstract OCL syntax. In particular, new elements are introduced to the OCL2.0 metamodel proposal using the common UML extension mechanisms, i.e., stereotypes, tagged values, and constraints. To support modeling, a concrete syntax and operations have to be defined for this extension on the M1 (Domain Model) layer in the UML 4-layer architecture. The grammar of the concrete syntax of [22] is introduced in 3.2 and some new production rules are added, keeping the compliance with existing concrete OCL syntax. Note that we cannot avoid the overlap with the M1 layer in an OCL profile, since OCL pre-defines types and operations on that level. As the concrete OCL syntax only partly provides the operations that are defined in OCL expressions, a standard library of pre-defined OCL operations is specified in [22, Chapter 6]. Correspondingly, we define operations in the context of temporal expressions in 3.3. The semantics of our temporal OCL extension is finally described in Subsection 3.4. 3.1

OCL Metamodel Extensions

The OCL2.0 metamodel proposal distinguishes two packages. The OCL type metamodel describes the pre-defined OCL types and affiliated UML types, while the OCL expression metamodel describes the structure of OCL expressions. In the next paragraphs, we further investigate states, state configurations, and sequences of state configurations and introduce respective stereotypes for these concepts. States. OCL already supports retrieval of states from Statechart diagrams that are attached to user-defined classes. In the OCL type metamodel on layer M2, the respective metaclass is OclModelElementType. Generally, OclModelElementType represents the types of elements that are ModelElements in the UML metamodel. In that case, the model elements are states (or more precisely, instances of a concrete subclass of the abstract metaclass State), and the corresponding instance of OclModelElementType on layer M1 is OclState.

182

Stephan Flake and Wolfgang Mueller

S X A J

K

L Y

B M

N

List of States: S S::X S::Y S::X::A S::X::B S::X::A::J S::X::A::K S::X::A::L S::X::B::M S::X::B::N

List of Basic Configurations: Set{S::X::A::J, S::X::B::M} Set{S::X::A::J, S::X::B::N} Set{S::X::A::K, S::X::B::M} Set{S::X::A::K, S::X::B::N} Set{S::X::A::L, S::X::B::M} Set{S::X::A::L, S::X::B::N} Set{S::Y}

Fig. 1. Statechart Example with Lists of States and Basic Configurations For each state, there implicitly exists a corresponding enumeration literal accessible in OclState, i.e., OclState is seen as an enumeration type on the M1 layer, accumulating the state names of all Statechart diagrams attached to user-defined classes. The only operation in OCL to access states is of form obj.oclInState(s), with obj being an object and s being a state name of type OclState. The operation returns a Boolean value that indicates whether s is currently active in the Statechart for obj. Configurations. The building blocks of Statecharts are hierarchically ordered states. Note that we do not regard pseudo states (like synch, stub, or history states) in this context. A composite state is known as a state that has a set of sub-states. A composite state can be a concurrent state, consisting of orthogonal regions, which in turn are (composite) states. Simple states are non-pseudo, noncomposite states. In a Statechart with composite and concurrent states, a ’current state’ cannot be exactly identified, as more than one state can be active at the same time. Consequently, UML1.4 provides the notion of active state configurations [13, Section 2.12.4.3] as follows. If a Statechart is in a simple state which is part of a composite state, then all the composite states that (transitively) contain that simple state are also active. As composite states in the state hierarchy may be concurrent, currently active states are represented by a tree of states starting with a unique root state and with individual simple states at the leaves. However, to uniquely identify an active state configuration, it is sufficient to list the comprising simple states, which we denote as a basic configuration or valid configuration. Figure 1 gives a Statechart example with corresponding basic configurations. For valid configurations, we introduce the new collection type ConfigurationType in the context of the OCL type metamodel, as illustrated in Figure 2a1 . Instances of ConfigurationType are restricted sets on the M1 layer. Such sets are restricted to have elements that are enumeration literals of type OclState. A possible corresponding formula to express this property in OCL is 1

For our stereotype definitions, we make use of the graphical notation suggested in the official UML 1.4 specification [13, Sections 3.17, 3.18, 3.35 and 4.3].

A UML Profile for Real-Time Constraints with the OCL

183

context ConfigurationType inv: self.oclIsKindOf(SetType) and self.elementType.name = ’OclState’

Execution Paths. E x ecution paths of Statecharts can be represented by sequences of valid configurations. To model execution paths, we introduce PathType in Figure 2a, whose instances are sequences on the M1 level that are restricted to have a certain element type. In that case, the element type must be an instance of ConfigurationType. Written as an OCL formula, we require: context PathType inv: self.oclIsKindOf(SequenceType) and self.elementType.name =’Set(OclState)’

Temporal Expressions. Concerning the OCL expression metamodel, we introduce a new kind of operation call (cf. Figure 2b): TemporalExp represents a temporal expression that refers to execution paths. It is the abstract superclass of PastTemporalExp and FutureTemporalExp for past- and future-oriented temporal expressions. We need these two stereotypes in order to define a semantics for according temporal operations (see Section 3.4). Execution Path Literals. As we want to reason about execution paths by means of states and configurations, we also need a mechanism to explicitly specify execution paths with annotated timing intervals by literals. We therefore define the stereotype PathLiteralExp, as illustrated in Figure 3. The following restrictions apply here, leaving out the corresponding OCL formulae for the matter of brevity.

Classifier (from Core)

+elementType

PropertyCallExp

+appliedProperty 0..1

1 0..1 +source 0..n {ordered} OclModelElementType

OclExpression

+arguments

DataType (from Core)

Operation (from Core) CollectionType

Primitive (from Core)

0..4

OperationCallExp

1

+referredOperation

+collectionTypes

SetType

ConfigurationType

SequenceType

TemporalExp

PathType

(a) Parts of the OCL Type Metamodel with Stereotypes for Configurations and Execution Paths

PastTemporalExp

FutureTemporalExp

(b) Parts of the OCL Expression Metamodel with Stereotypes for Temporal Expressions

Fig. 2. New OCL Types and Expressions – Gray boxes are taken from the metamodel in [22]

184

1. 2. 3. 4.

3.2

Stephan Flake and Wolfgang Mueller

The collection kind of PathLiteralExp is CollectionKinds::Sequence. Each sequence element has a lower bound and an upper bound. Lower bounds must evaluate to non-negative Integer values. Upper bounds must evaluate to non-negative Integer values or to the String ’inf’ (for infinity). In the first case, the upper bound must be greater or equal to the corresponding lower bound.

Concrete Syntax Changes

Having defined new classes for temporal expressions on the abstract syntax level, modelers are not yet able to use these extensions, as they specify OCL expressions by means of a concrete syntax. In Chapter 4 of the OCL2.0 metamodel proposal, a concrete syntax is given that is compliant with the current OCL1.4 standard. The new concrete syntax is defined by an attributed grammar with production rules in EBNF that are annotated with synthesised and inherited attributes as well as disambiguating rules. Inherited attributes are defined for elements on the right hand side of production rules. Their values are derived from attributes defined for the left hand side of the according production rule. For instance, each production rule has an inherited attribute env (environment) that represents the rule’s namespace. Synthesised attributes are used to keep results from evaluating the right hand sides of production rules. For instance, each production rule has a synthesised attribute ast (abstract syntax tree) that constitutes the formal mapping from concrete to abstract syntax. Disambiguating rules allow to uniquely determine a production rule if there are syntactically ambiguous production rules to choose from. In the following, we present some additional production rules for the concrete syntax of the OCL2.0 metamodel proposal. A mapping to the extended abstract OCL syntax is provided for each new production rule.

CollectionLiteralExp

PathLiteralExp

kind : CollectionKind

+parts 0..n {ordered} Classifier (from Core)

CollectionKind Collection Set Bag Sequence

+type

CollectionLiteralPart

1

CollectionRange

+first 1

CollectionItem

PathLiteralPart

+last 1

OclExpression

+item 1

upperBound[1] lowerBound[1]

Fig. 3. Parts of the OCL Expression Metamodel with Stereotypes for Execution Paths

A UML Profile for Real-Time Constraints with the OCL

185

OperationCallExpCS2 Eight different forms of operation calls are already defined in the OCL2.0 concrete syntax. In particular, it is distinguished between infix and unary operations, operation calls on collections, and operation calls on objects (with or without ’@pre’ annotation) or whole classes. We additionally introduce rule [J] for temporal operation calls. [A] OperationCallExpCS ::= OclExpressionCS[1]

simpleNameCS OclExpressionCS[2] [B] OperationCallExpCS ::= OclExpressionCS ’->’ simpleNameCS ’(’ argumentsCS? ’)’ [C] OperationCallExpCS ::= OclExpressionCS ’.’ simpleNameCS ’(’ argumentsCS? ’)’ ... [J] OperationCallExpCS ::= TemporalExpCS

We here only list the synthesised and inherited attributes for syntax [J]. Disambiguating rules are defined in the particular rules for temporal expressions. Abstract Syntax Mapping: -- (Re)type the abstract syntax tree ast to the according metaclass. OperationCallExpCS.ast : OperationCallExp Synthesised Attributes: -- Build the abstract syntax tree (in this case a simple assignment). [J] OperationCallExpCS.ast = TemporalExpCS.ast Inherited Attributes: -- Derive the namespace stored in env from left hand side of the rule [J] TemporalExpCS.env = OperationCallExpCS.env

TemporalExpCS A temporal expression is either a past- or future-oriented temporal expression. [A] TemporalExpCS ::= PastTemporalExpCS [B] TemporalExpCS ::= FutureTemporalExpCS

We here omit the rather simple attribute definitions. Basically, the abstract syntax mapping defines TemporalExpCS.ast to be of type TemporalExp, the synthesised attribute ast is built from the right hand sides, and the inherited attribute env is derived from TemporalExpCS. FutureTemporalExpCS A future-oriented temporal expression is a kind of operation call. We additionally introduce the symbol ’@’ to indicate a subsequent temporal operation. Note that an operation call in the abstract syntax has a source, a referred operation, and operation arguments (cf. Figure 2b), so the abstract syntax tree ast must be built with corresponding synthesised attributes. 2

All non-terminals are postfixed by ’CS’ (short for Concrete Syntax) to better distinguish between concrete syntax elements and their abstract syntax counterparts.

186

Stephan Flake and Wolfgang Mueller

FutureTemporalExpCS ::= OclExpressionCS ’@’ simpleNameCS ’(’ argumentsCS? ’)’ Abstract Syntax Mapping: FutureTemporalExpCS.ast : FutureTemporalExp Synthesised Attributes: FutureTemporalExpCS.ast.source = OclExpressionCS.ast FutureTemporalExpCS.ast.arguments = argumentsCS.ast FutureTemporalExpCS.ast.referredOperation = OclExpressionCS.ast.type.lookupOperation (simpleNameCS.ast, if argumentsCS->notEmpty() then argumentsCS.ast->collect(type) else Sequence{} endif ) Inherited Attributes: OclExpressionCS.env = FutureTemporalExpCS.env argumentsCS.env = FutureTemporalExpCS.env Disambiguating Rules: -- The operation name must be a (future-oriented) temporal operator. [1] Set{’post’}->includes(simpleNameCS.ast) -- The operation signature must be valid. [2] not FutureTemporalExpCS.ast.referredOperation.oclIsUndefined()

If other temporal operations than @post() need to be introduced at a later point of time, only disambiguating rule [1] has to be modified accordingly. For instance, @next() might be introduced as a shortcut for @post(1,1). A corresponding extension to past temporal operations can be easily introduced, e.g., by means of the operation name pre(). In the remainder of this article, we only focus on FutureTemporalExpCS. Note that pre and post as operation names cannot be mixed up with pre- and postcondition labels or the @pre time marker, because operations require subsequent brackets. PathLiteralExpCS Path literal expressions are a special form of collection literal expressions, as they represent sequences of explicitly specified configurations. In order to allow interval definitions in sequences of configurations, some new production rules have to be formulated. As these are quite similar to the existing production rules for collection literals, definitions of ast and env are left out for brevity reasons. [A] CollectionLiteralExpCS ::= CollectionTypeIdentifierCS ’{’ CollectionLiteralPartsCS? ’}’ [B] CollectionLiteralExpCS ::= PathLiteralExpCS

In syntax [A], CollectionTypeIdentifierCS simply distinguishes between literals for collections (e.g., ’Set’, ’Bag’) and CollectionLiteralPartsCS is an enumeration of OCL expressions. Option [B] is added to provide a notation for sequences of configurations. For each configuration in a PathLiteralExpCS, a timing interval may be associated which specifies how long a configuration is active. If no interval is specified, the bounds are implicitly set to [0,’inf’].

A UML Profile for Real-Time Constraints with the OCL

187

PathLiteralExpCS ::= ’Sequence’ ’{’ PathLiteralPartsCS ’}’ ... PathLiteralPartsCS[1] ::= PathLiteralPartCS (’,’ PathLiteralPartsCS[2] )? ... PathLiteralPartCS ::= OclExpressionCS IntervalCS? Abstract Syntax Mapping: PathLiteralPartCS.ast : PathLiteralPart Synthesised Attributes: PathLiteralPartCS.ast.item = OclExpressionCS.ast PathLiteralPartCS.ast.lowerBound = if IntervalCS->notEmpty() then IntervalCS.ast.lowerBound else ’0’ endif PathLiteralPartCS.ast.upperBound = if IntervalCS->notEmpty() then IntervalCS.ast.upperBound else ’inf’ endif Inherited Attributes: OclExpressionCS.env = PathLiteralPartCS.env IntervalCS.env = PathLiteralPartCS.env Disambiguating Rules: [1] OclExpressionCS.ast.type.oclIsKindOf(ConfigurationType)

Basically, intervals are of the syntactical form [a,b], with a as a non-negative Integer, and b either an Integer with b ≥ a or the String literal ’inf’. 3.3

Standard Library Operations

In our previous work [10], we introduced two new built-in types called OclConfiguration and OclPath on the M1 layer to handle temporal expressions. We present an alternative approach that avoids to introduce new types and instead operates on the already existing OCL collection types. Configuration Operations. For configurations as a special form of sets of states, we have to elaborate on operations applicable to sets that return collections, since the resulting collection can be an invalid configuration with an arbitrary set of states. Nevertheless, general collection operations [22, Section 6.5.1] can be directly applied to configurations. These are =, , size(), count(), isEmpty(), notEmpty(), includes(), includesAll(), excludes(), and excludesAll(). In addition, iterator operations exists(), forAll(), any(), one() are applicable as well [22, Section 6.6.1]. Other OCL set operations on valid configurations, e.g., union() and intersection(), generally result in arbitrary sets of states rather than in valid configurations. We generally allow such operations, but explicitly mention that they have to be used with care. Execution Path Operations. Similar to configurations, many of the existing OCL sequence operations can immediately be applied to execution paths. These operations are =, , size(), isEmpty(), notEmpty(), exists(), forAll(), includes(), includesAll(), excludes(), excludesAll(), at(), first(), last(), append(), prepend(), subSequence(), asSet(), asBag(), and asSequence(). Correspondingly, some sequence operations may evaluate to invalid execution paths, e.g., select() and collect().

188

Stephan Flake and Wolfgang Mueller

Temporal Operations for OclAny. We introduce post(a,b) as a new temporal operation of OclAny and allow the @-operator to be used only for such temporal operations. @post(a,b) returns a set of possible future execution paths in the interval [a,b]. First, all possible execution paths that start with the current configuration are regarded, and then the timing interval [a,b] determines the subpaths that have to be returned by the operation. The result has to be a set of paths, as there are typically different orders of executions possible in the future steps of a Statechart. Note that in an actual execution of a Statechart there is of course only exactly one of the possible execution paths selected. An informal semantics of post(a,b) is given as follows. Let obj be an object in the context of OCL. obj@post(a:Integer,b:OclAny) : Set(Sequence(Set(OclState))) pre: a >= 0 and ( (b.oclIsTypeOf(Integer) and b >= a) or (b.oclIsTypeOf(String) and b = ’inf’) ) The operation returns a set of possible future execution paths in the interval [a,b], including the configurations of time points a and b.

Further operations, such as @next() or @post(a:Integer) can be easily added [10]. These are operations basically derived from @post(a,b). 3.4

Semantics of Temporal Expressions

To define the semantics for the future-oriented temporal extension, we provide a mapping from instances of FutureTemporalExpCS to Clocked Computational Tree Logic (CCTL) formulae [18]. CCTL is an extension of classical CTL and introduces timing intervals to temporal logic operators. By definition, OCL invariants for a given type must be true for all its instances at any time [22, Section 2.3.3]. Consequently, corresponding CCTL formulae have to start with the AG operator (’On All paths Globally’), i.e., the expression following AG must be true on all possible future execution paths at all times. Table 1 lists OCL operations that directly match to CCTL expressions. In that table, expr denotes a Boolean OCL expression. cctlExpr is the equivalent Boolean expression in CCTL syntax. cfg denotes a valid configuration and cctlCfg is the corresponding set of states in CCTL syntax. p and c are iterator variables for execution paths and configurations, respectively. Consider as an example the last row of Table 1. When taking the particular interval [1,100] and a configuration from Figure 1 for cfg, the resulting OCL expression is: inv: obj@post(1,100)->forAll(p | p->includes(Set{S::X::A::K,S::X::B::M}))

We read that formula as: At any time, given the current configuration of the Statechart associated to object obj, all future execution paths p starting from the current configuration reach – at a certain point of time within the timing interval [a,b] – the configuration represented by Set{S::X::A::K,S::X::B::M}.3 3

This kind of formula is often categorized as liveness property.

A UML Profile for Real-Time Constraints with the OCL

189

Table 1. Mapping Temporal OCL Expressions to CCTL Formulae TemporalOCL Expression

CCTL Formula

inv: obj@post(a,b)→exists( p | p→forAll(c | expr))

AG EG[a,b](cctlExpr)

inv: obj@post(a,b)→exists( p | p→exists(c | expr))

AG EF[a,b](cctlExpr)

inv: obj@post(a,b)→exists( p | p→includes(cfg))

AG EF[a,b](cctlCfg)

inv: obj@post(a,b)→forAll( p | p→forAll(c | expr))

AG AG[a,b](cctlExpr)

inv: obj@post(a,b)→forAll( p | p→exists(c | expr))

AG AF[a,b](cctlExpr)

inv: obj@post(a,b)→forAll( p | p→includes(cfg))

AG AF[a,b](cctlCfg)

For mapping path literal expressions, let e 1, e 2, . . . , e n be the path literal parts of PathLiteralExpCS with timing intervals [a i, b i ]. The temporal OCL expression inv: obj@post(a,b)→includes( Sequence{e 1 [a 1 , b 1 ], e 2 [a 2 , b 2 ], . . . , e

n}

)

maps to CCTL applying the strong until temporal operator (i.e., e x p r 1 U[a,b] e x p r 2 requires that e x p r 1 must be true between a and b time units until e x p r 2 becomes true) as follows. AG[a,b] EF( E(e

1

U[a1 ,b1 ] E(e

2

U[a2 ,b2 ] E(... E(e

n−1

U[an−1 ,bn−1 ] e n )...))))

Though we have given only simplified examples here, more complex should be easily derived from the above.

AGVs

Workers Legs

Tops

Assembling

Tables

Items

Supplying

Transporting ItemsBuffered

ItemsBeforeMill

Screws

(a) Table Production

(b) Transporting Items between Machine Buffers with Automated Guided Vehicles (AGVs)

Fig. 4. Sample MFERT Graphs

4

MFERT

MFERT4 provides means for specification and implementation of planning and control assignments in manufacturing processes [20]. In MFERT, nodes represent either storages for production elements or production processes. Production 4

MFERT stands for ”Modell der FERTigung” (German for: Model of Manufacturing).

190

Stephan Flake and Wolfgang Mueller

Element Nodes (PENs) are used to model logical storages of material and resources and are drawn as annotated shaded triangles. Production Process Nodes (PPNs) represent logical locations where material is transformed and are drawn as annotated rectangles. PENs and PPNs are composed to a bipartite graph connected by directed edges which define the flow of production elements. MFERT graphs establish both a static and a dynamic view of a manufacturing system. On the one hand, the nodes are statically representing the participating production processes and element storages. On the other hand, edges represent the dynamic flow of production elements (i.e., material and resources) within the manufacturing system. Two examples for MFERT graphs are shown in Figure 4. On the left hand side, a production of tables is illustrated, and on the right hand side, transportation of items between processing steps is modeled. The latter is a small outtake of a model that is composed of different manufacturing stations and transport vehicles (AGVs) that transport items between stations. In MFERT, the processing is specified by finite state machines (FSMs) that are associated with PPNs. Although several variations to formally define the behavior of MFERT PPNs are presented in literature5 , we focus in our work on FSMs and their hierarchical variants like Harel’s Statecharts [11]. For instance, an FSM assigned to the node Assembling in Figure 4a may specify that the production of a table requires 4 legs, 1 table top, 16 screws, and 1 worker for mounting the table. 4.1

UML Profile for MFERT

Modeling the static and dynamic aspects of manufacturing systems can be done by UML class diagrams. For that, we introduce stereotypes that represent production processes, storages, and element flow by the virtual metamodel shown in Figure 5, where 1. A ProductionDataType defines a tuple of data types. Only query and constructor operations are allowed for production data types, which may only aggregate or be composed of DataTypes or ProductionDataTypes. 2. The ElementList stereotype represents a parameterized interface that provides certain operations to manage lists with elements of a certain ProductionDataType. We assume that appropriate operations for lists are specified. 3. MFERTNode is the abstract superclass of ProductionProcessNode and ProductionElementNode. MFERT nodes may only inherit from other MFERT nodes of the same kind. Associations between two MFERT nodes have to be modeled using ElementFlow associations. There is at most one relationship between each pair of MFERT nodes, which is either a generalization or an ElementFlow association. 4. ProductionProcessNodes (PPNs) consume from and send production elements to ProductionElementNodes. Each PPN has its own thread of control, i.e., the instances are active objects. 5

E.g., Quintanilla uses a graphical representation called interaction diagrams and formally defines them in [14].

A UML Profile for Real-Time Constraints with the OCL

191

5. ProductionElementNodes (PENs) store production elements for further processing by subsequent PPNs. Two lists with production elements (ElementLists) are managed by a PEN; one for incoming, one for outgoing production elements. The two lists are storing elements of a certain ProductionDataType that is specified by the tagged value elementType. 6. ElementFlow represents a restricted association between MFERT nodes. Tagged values source and target refer to the two classifiers that are determined by the association ends of ElementFlow. We restrict multiplicity of these association ends to 1, as an ElementFlow association shall indicate a relationship between two instances of MFERT nodes. Though it is allowed to navigate on ElementFlow associations in both ways, we graphically represent these associations as directed edges towards the target end to indicate the direction of element flow. Due to space limitations, it is only a summary of the model-inherent restrictions defined by the profile. For a complete outline we refer to [8], where a complete definition of the MFERT profile is given including OCL constraints, the formal MFERT model, and a mapping to I/O-Interval Structures. Validation/Verification Constraints. For validation and verification of MFERT designs, we have to restrict UML class diagrams as follows. 1. We require that each concrete MFERT node is complete in the sense that its behavior description is given in form of a single Statechart diagram. 2. An MFERT node may communicate with a non MFERT node by operation call, signal or attribute modification, which is not considered for verification.

Relationship

Class



ElementFlow

source [1]



MfertNode

Interface



ProductionDataType

Comment



ElementList

Declaration Tags expr : Expression [1]

target [1]

inputSequence [1]

elementType [1]

ProductionProcessNode

outputSequence [1] declaration [1]

ProductionElementNode Tags time : Integer [1]

Fig. 5. MFERT Stereotypes

192

Stephan Flake and Wolfgang Mueller

3. Variables must have a finite value range to be applicable for verification by means of model checking, i.e., attributes can only be enumerations or finite subsets of type Integer. 4.2

Dynamic Semantics of MFERT

We have identified different execution semantics of MFERT for different purposes, e.g., for analysis, control, or planning [8]. Here, we take the so-called synchronous semantics that allows a direct mapping to I/O-Interval Structures. The term synchronous in this context refers to immediate receiving of signals without timing delay between different I/O-Interval Structures. The dynamic semantics for production process nodes is defined by an abstract interpreter cycle that controls the execution of the according FSMs. We assume that each PPN has its own thread of control and runs independently of a global signal. Each interpreter cycle starts with selection of a transition with a true condition. After the selection phase, some checks on adjacent PENs are necessary; some actions associated with the selected transition can have an effect on adjacent PENs, e.g., by consuming production elements from preceding nodes. In the final phase, the selected transition fires, a new state is entered and the interpretation cycle starts from the beginning. For production element nodes, cyclic shifting of elements from the input sequence to the output sequence is controlled by an additional interpretation cycle. Queries and manipulations on the sequences are handled independently of the interpretation and are performed with mutual exclusive access to avoid conflicts. As we restrict all data types to be finite, we can directly map MFERT models as defined by the UML profile in Section 4.1 to the formal MFERT model. PPNs and PENs are directly mapped to I/O-Interval Structures. For I/O-Interval Structures derived from PENs, mainly data types have to be mapped. Transition rules are only necessary for cyclic shifting of elements from the input to the output sequences. For I/O-Interval Structures derived from PPNs, we get the transition rules from the required Statechart diagrams. 4.3

Example

As an example, we take the model of Figure 4b and require that each item that is loaded at buffer ItemsBuffered must be transported within 120 time units to the next buffer ItemsBeforeMill. In the context of PPN Transporting, with its internal states Loading and Unloading, the corresponding temporal OCL invariant may be context Transporting inv: self.oclInState(Loading) implies self@post(1,120)->includes(Unloading)

For further readings, more examples can be found in [8, 9].

A UML Profile for Real-Time Constraints with the OCL

5

193

Summary and Conclusion

We have presented a UML profile for specification of real-time constraints on the basis of the latest OCL2.0 metamodel proposal. The approach demonstrates that an OCL extension by means of a UML profile towards temporal real-time constraints can be seamlessly applied on the M2 layer. Nevertheless, some extensions have to be made on the M1 layer in order to enable modelers to use our temporal OCL extensions. The presented extensions are based on a future-oriented temporal logic. However, current work additionally investigates the extension to past-oriented and additional logics. As an example, we applied our temporal OCL extensions to MFERT. A semantics is given to both, MFERT profile and temporal OCL expressions, by a mapping to synchronous time-annotated finite state machines (I/O-Interval Structures) and temporal logics formulae (CCTL), respectively. This provides a sound basis for formal verification by real-time model checking with RAVEN [17]. We have implemented an editor for MFERT [5]. Code generation for I/OInterval Structures is currently under implementation. The temporal OCL extensions as presented here are integrated into our OCL parser and type checker [10]. The type checker can translate constraints with temporal operations to CCTL formulae. Our temporal OCL extension has also been used as a specification means for railway systems requirements [2]. In order to investigate the potential for domainindependent application of our approach, we currently map the general property patterns identified by Dwyer et al. [7] to according temporal OCL expressions.

Acknowledgements We thank Henning Zabel for his work on the MFERT editor and the code generator. The work described in this article receives funding by the DFG project GRASP within the DFG Priority Programme 1064 ”Integration von Techniken der Softwarespezifikation f¨ ur ingenieurwissenschaftliche Anwendungen”.

References [1] Thomas Baar and Reiner H¨ ahnle. An Integrated Metamodel for OCL Types. In OOPSLA 2000, Workshop Refactoring the UML: In Search of the Core, Minneapolis, MN, USA, 2000. 179 [2] F. Bitsch. Requirements on Methods and Techniques in Perspective to Approval Process for Railway Systems. In 2nd International Workshop on Integration of Specification Techniques for Applications in Engineering (INT’02), Grenoble, France, April 2002. 193 [3] J. Bradfield, J. Kuester Filipe, and P. Stevens. Enriching OCL Using Observational mu-Calculus. In FASE 2002, Grenoble, France, volume 2306 of LNCS. Springer, April 2002. 180

194

Stephan Flake and Wolfgang Mueller

[4] S. Conrad and K. Turowski. Temporal OCL: Meeting Specifications Demands for Business Components. In Unified Modeling Language: Systems Analysis, Design, and Development Issues. IDEA Group Publishing, 2001. 180 [5] W. Dangelmaier, C. Darnedde, S. Flake, W. Mueller, U. Pape, and H. Zabel. Graphische Spezifikation und Echtzeitverifikation von Produktionsautomatisierungssystemen. In 4. Paderborner Fr¨ uhlingstagung 2002, Paderborn, Germany, April 2002. (in German). 193 [6] Dino Distefano, Joost-Pieter Katoen, and Arend Rensink. On a Temporal Logic for Object-Based Systems. In FMOODS’2000, Stanford, CA, USA, September 2000. 180 [7] Matthew B. Dwyer, George S. Avrunin, and James C. Corbett. Patterns in Property Specifications for Finite-State Verification. In ICSE’99, Los Angeles, CA, USA, May 1999. 193 [8] S. Flake and W. Mueller. A UML Profile for MFERT. Technical report, C-LAB, Paderborn, Germany, March 2002. URL: http://www.c-lab.de/vis/flake/publications/index.html. 191, 192 [9] S. Flake and W. Mueller. Specification of Real-Time Properties for UML Models. In Proc. of the 35th Hawaii Internat. Conf. on System Sciences (HICSS-35), Hawaii, USA, 2002. 179, 192 [10] Stephan Flake and Wolfgang Mueller. An OCL Extension for Real-Time Constraints. In Object Modeling with the OCL, volume 2263 of LNCS, pages 150–171. Springer, February 2002. 179, 187, 188, 193 [11] David Harel. Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, 8(3):231–274, June 1987. 190 [12] Anneke Kleppe and Jos Warmer. Extending OCL to include Actions. In UML 2000 - The Unified Modeling Language. Advancing the Standard, volume 1939 of LNCS, pages 440–450. Springer, 2000. 180 [13] OMG. Unified Modeling Language 1.4 Specification. OMG Document formal/2001-09-67, September 2001. URL: http://www.omg.org/technology/documents/formal/uml.htm. 179, 182 [14] Julia Quintanilla de Simsek. Ein Verifikationsansatz f¨ ur eine netzbasierte Modellierungsmethode f¨ ur Fertigungssysteme. PhD thesis, Heinz Nixdorf Institute, HNI-Verlagsschriftenreihe, Band 87, Paderborn, Germany, 2001. (in German). 190 [15] Sita Ramakrishnan and John McGregor. Extending OCL to Support Temporal Operators. In ICSE’99, Workshop on Testing Distributed Component-Based Systems, Los Angeles, CA, USA, May 1999. 180 [16] E. E. Roubtsova, J. van Katwijk, W. J. Toetenel, and R. C. M. de Rooij. RealTime Systems: Specification of Properties in UML. In ASCI 2001 Conference, pages 188–195, Het Heijderbos, Heijen, The Netherlands, May 2001. 180 [17] J. Ruf. RAVEN: Real-Time Analyzing and Verification Environment. Journal on Universal Computer Science (J.UCS), Springer, 7(1):89–104, February 2001. 193 [18] J¨ urgen Ruf and Thomas Kropf. Symbolic Model Checking for a Discrete Clocked Temporal Logic with Intervals. In Conference on Correct Hardware Design and Verification Methods (CHARME’97), pages 146–166, Montreal, Canada, October 1997. 179, 188 [19] J¨ urgen Ruf and Thomas Kropf. Modeling and Checking Networks of Communicating Real-Time Systems. In CHARME’99, pages 265–279. Springer, September 1999. 180 [20] Uta Schneider. Ein formales Modell und eine Klassifikation f¨ ur die Fertigungssteuerung - Ein Beitrag zur Systematisierung der Fertigungssteuerung. PhD the-

A UML Profile for Real-Time Constraints with the OCL

195

sis, Heinz Nixdorf Institute, HNI-Verlagsschriftenreihe, Band 16, Paderborn, Germany, 1996. (in German). 180, 189 [21] Shane Sendall and Alfred Strohmeier. Specifying Concurrent System Behavior and Timing Constraints Using OCL and UML. In UML 2001 – The Unified Modeling Language: Modeling Languages, Concepts, and Tools, volume 2185 of LNCS, pages 391–405. Springer, 2001. 180 [22] J. Warmer et al. Response to the UML2.0 OCL RfP, Version 1.5 (Submitters: Boldsoft, Rational, IONA, Adaptive Ltd., et al.). OMG Document ad/02-05-09, June 2002. 179, 180, 181, 183, 187, 188

HOL-OCL:Experiences,Consequences and Design Choices Achim D. Brucker and Burkhart Wolff Institut f¨ ur Informatik, Albert-Ludwigs-Universit¨ at Freiburg Georges-K¨ ohler-Allee 52, D-79110 Freiburg, Germany {brucker,wolff}@informatik.uni-freiburg.de http://www.informatik.uni-freiburg.de/~{brucker,wolff}

Abstract. Based on experiences gained from an embedding of the Object Constraint Language (OCL) in higher-order logic [3], we explore several key issues of the design of a formal semantics of the OCL. These issues comprise the question of the interpretation of invariants, pre- and postconditions, an executable sub-language and the possibilities of refinement notions. A particular emphasize is put on the issue of mechanized deduction in UML/OCL specification. Keywords: OCL, formal semantics, constraint languages, refinement

1

Introduction

The Object Constraint Language (OCL) [16, 21, 22] is part of the UML, the de-facto standard of object-oriented modeling. Being in the tradition of dataoriented formal specification languages like Z [19] or VDM [10], OCL is designed to make UML diagrams more expressive. In short, OCL is a three-valued Kleene logic with equality that allows for specifying constraints on graphs of object instances. There is a need for both researchers and CASE tool developers1 to clarify the concepts of OCL formally and to put them into perspective of more standard semantic terminology. In order to meet this need, we started to provide a formal semantics in form of a conservative embedding of OCL into Isabelle/HOL which is described in [3]. In contrast to traditional paper-and-pencil-work in defining the semantics of a language, a theorem prover based formalization inside a powerful logical language such as higher-order logic (HOL) [4, 2] offers a number of advantages: First of all, the consistency of an embedded logic, if based on conservative extensions, can be guaranteed. Second, as already pointed out in [15], the use of a theorem prover works as Occam’s razor in a formalization since machine-checked proofs enforce “a no-frills approach and often leads to unexpected simplifications”. Third, incremental changes of a semantic theory can be facilitated since re-running the proof-scripts immediately reveal new problems in previous proofs, “thus freeing you from the tedium of having to go through all 1

This work was partially funded by the OMG member Interactive Objects Software GmbH (www.io-software.com).

J.-M. J´ ez´ equel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 196–211, 2002. c Springer-Verlag Berlin Heidelberg 2002


HOL-OCL: E xperiences, Consequences and Design Choices

197

t ’“ details again”. Further, programmable theorem provers such as Isabelle can be used to study symbolic evaluation and thus prototypical tool development. For all these reasons, the embedding approach has been successfully applied for a number of “real” languages such as Java [14, 15], ML [7], CSP [20],or Z [11]. In this document, we summarize experiences and consequences of our formalization, including answers on questions raised in previous research on the precise meaning of OCL [12, 18, 22]: the issue of partial and total correctness, the role of exceptions, the precise meaning of invariants, the option for recursive query methods and executability of OCL, and its potential for formal refinement. We proceed as follows: First, we will outline the underlying logical, methodological and technical framework. Second, we will present an abstraction of the key-concepts of our embedding [3]. On this basis, we enter in a discussion on the “research issues on OCL” as listed above and their answer in the light of our semantic model of OCL. Finally, we discuss our first experiences with mechanized deduction in UML/OCL specifications.

2

Formaland Technical Background

In this section we will outline the underlying logical, methodological and technical framework of our embedding of OCL into Isabelle/HOL. 2.1

Higher-Order Logic — HOL

H igher-order logic (HOL) [4, 2] is a classical logic with equality enriched by total polymorphic2 higher-order functions. It is more expressive than first-order logic, since e.g. induction schemes can be expressed inside the logic. Pragmatically, HOL can be viewed as a combination of a typed functional programming language like Standard ML or Haskell extended by logical quantifiers. Thus, it often allows a very natural way of specification. When extending logics, two approaches can be distinguished: the axiomatic method on the one hand and conservative extensions on the other. Extending the HOL core via axioms, i.e. introducing new, unproven laws seems to be the easier approach but it usually leads easily to inconsistency; given the fact that in any major theorem proving system the core theories and libraries contain several thousand theorems and lemmas, the axiomatic approach is worthless in practice. In contrast, a conservative extension introduces new constants (via constant definitions) and types (type definitions) only via a particular schema of axioms; the (meta-level) proof that axioms of this schema preserve consistency can be found in [6]. For example, a constant definition introduces a “fresh” constant symbol and a non-recursive equality axiom with the new constant at the left hand side, while the right-hand side is a closed expression. Thus, the new constant can be viewed as an abbreviation of previously defined constructs. The HOL library provides conservative theories for the HOL-core based on type bool, for the numbers such as nat and int, for typed set theory based on 2

To be more specific: parametric polymorphism

198

Achim D. Brucker and Burkhart Wolff

τ set and a list theory based on τ list. In this sense, the HOL type system is quite similar to the OCL type system, but offers no subtyping. Moreover, there are products, maps, and even a theory on real numbers and non-standard analysis. 2.2

Isabelle

Isabelle [17] is a generic theorem prover. New object logic’s can be introduced by specifying their syntax and inference rules. Among other logics, Isabelle supports first order logic (constructive and classical), Zermelo-Fr¨ ankel set theory and HOL, which we choose as framework for HOL-OCL. Isabelle consists of a logical engine encapsulated in an abstract data type thm in Standard ML; any thm object has been constructed by trusted elementary rules in the kernel. Thus Isabelle supports user-programmable extensions in a logically safe way. A number of generic proof procedures (tactics) have been developed; namely a simplifier based on higher-order rewriting and proof-search procedures based on higher-order resolution. 2.3

Shallow Embeddings vs. Deep Embeddings

We are now concerned with the question how a language is represented in a logic. In general, two techniques are distinguished: shallow and deep embeddings. Deep Embeddings represent the abstract syntax as a datatype and define a semantic function I from syntax to semantics. Shallow Embeddings define the semantics directly; each construct is represented by some function on a semantic domain. Assume we want to embed the boolean OCLlight operators3 and and or into HOL. Note, that the semantics I : expr → env → bool is a function that maps OCL expressions and environments to bool , where environments env = var → bool maps variables to bool values. Using a shallow embedding, we define directly: x and y ≡ λ e • x e ∧ y e

x or y ≡ λ e • x e ∨ y e

Shallow embedding allows for direct definitions in terms of semantic domains and operations on them. In contrast, in a deep embedding, we have to define the syntax of OCLlight as recursive datatype: expr = var var | expr and expr | expr or expr and the explicit semantic function I : I [[var x ]] = λ e • e(x ) I [[x and y]] = λ e • I [[x ]] e ∧ I [[y]] e I [[x or y]] = λ e • I [[x ]] e ∨ I [[y]] e 3

Here we simplify the OCL semantics, by ignoring undefinedness and states.

HOL-OCL: Experiences, Consequences and Design Choices

199

This example reveals the main drawback of deep embeddings: the language is more distant to the underlying meta language HOL, i.e. semantic functions represent obstacles for deduction. The explicit syntax of deep embeddings enables induction proofs, however; for some meta-theoretic analysis, this may have advantages. Since we are interested in a concise semantic description of OCL and prototypical proof support, but not meta-theory, we chose a shallow embedding.

3

An Abstract Model of HOL-OCL

In this section, we will motivate some design goals of HOL-OCL (as described in [3]), namely extendibility and modular organization. Here, we are less concerned with an integrated solution of the technical problems, but with the underlying concepts of our approach. 3.1

Design Goals of HOL-OCL

A conservative shallow embedding enforces any entity of the language to have a type in HOL. This seems to be tedious at first sight, but has the foundational advantage that statements such as x ∈ S never run into Russel’s paradox; in a typed set theory, well-typedness assures consistency. The set theoretic foundation makes the treatment of what we call a general semantics of OCL quite difficult; such a semantics should interpret an OCL-expression not only in one class diagram, but also “the set of all possible extensions”. Unfortunately, the semantic domain of general semantics requires concepts such as “the set of all universes over all class diagrams” (where a universe U is the set of all objects of a class diagram). Such a set is too large to be represented in a typed set theory and a critical construction in Zermelo-Fr¨ ankel set theory. Therefore, previous formal semantics to OCL ([12, 18, 22]) has been based on a “parameterized semantics” approach, i.e. the semantic function is parameterized by an arbitrary, but fixed diagram C, and its definition is based on naive set theoretic reasoning [8]. Even if one is not too much concerned about the foundational problems with this approach, we argue that parametric semantics does not cover the most important aspect of object-orientation: reuseability. In principle, if one extends a class diagram C by a diagram extension E (containing new classes and inheritance relations) to a class diagram C ⊕ E, one wants to reuse “everything” done for C. In a theorem prover, the reuse of derived rules and theorems from the library or a user model is pragmatically vital. However, in the parameterized semantics approach, values in the two semantic functions IC [[e]] and IC⊕E [[e]] are unrelated, and, thus, theorems proven over the first do not carry over to the latter. In order to obtain proof-reuseability, we based HOL-OCL on the extendible semantics approach, that lies in between the parameterized and the general semantics. The idea is to introduce extension variables X and to represent diagrams by C ⊕ X, such that diagram C ⊕ E ⊕ X′ becomes an instance of C ⊕ X. Since extension variables can be represented via type variables in HOL, values within a family of “diagrams extensions” become semantically related.

200

Achim D. Brucker and Burkhart Wolff

Representing a language that is still under construction (as OCL) is risky: if the various key features were changed, a lot of work may be lost. Keeping a semantic theory flexible is therefore a major challenge for the theorem-prover based analysis of language designs. We answered the problem by organizing the semantic definition for any type and any operator of OCL into layers, whose “semantical essence” is captured by certain combinators (i.e. type constructors for types and higher-order functions for operators). When embedding the types from HOL-library theories like bool , string, set etc, they all have to be “lifted” by adding a ⊥ -element denoting undefinedness: Bool = bool ⊎ {⊥} = bool⊥ where ⊎ denotes the disjoint sum. When embedding operations, fundamental semantic principles like “all operations are strict” can be incorporated “once and for all” by defining a combinator “strictify”, that is used in all definitions of OCL-operators (with some exceptions listed in the OCL standard). For instance, the strictified logical not can be defined as follows: not ′ ≡ ⌊ ⌋ ◦ (strictify(¬ )) where ⌊ ⌋ takes a value and embeds it into its disjoint sum with ⊥, ◦ is the function composition, and ¬ the logical not in HOL on bool . The combinator is defined by:
⊥ if x = ⊥ strictify(f )(x ) ≡ f z if x = ⌊z ⌋. Similarly, we define combinators that realize uniformly the semantic construction for state transitions (the actual definition for not is lift1 (not ′ ), see below), for the “smashing” of collection types (see below) or for the treatment of late binding or static binding in recursive query methods. The purpose of the following subsections is to introduce an “abstract version” of HOL-OCL that covers the most essential concepts but abstracts away the quite involved details with respect to the construction of objects in a state, with respect to types and with respect to parametric polymorphism, that implements these concepts. The details can be found in [3]. 3.2

Foundation

In the following, we assume the base types Boolean, String, Int , etc. as lifted versions bool⊥ , string⊥ , etc. of the HOL library types, and C, C′ ,C′′ are denoting UML class diagrams. Further we assume an operation ⊕ and the class diagram extensions E, E′ ,E′′ , universes UC of objects over a class diagram C (the universe also contains all values of the base types, states4 State(UC ) containing objects of UC ), and STC ≡ State(UC ) × State(UC ). 4

Also called object configurations or snapshots in the literature

HOL-OCL: Experiences, Consequences and Design Choices

3.3

201

Methods in OCL

One vital motivation for OCL is its possibility to specify methods of class diagrams with pre- and postconditions: c o n t ex t C.op ( x : T1 ) : T2 pre : PRE p o st : POST where PRE and POST may be OCL expressions of type Boolean. PRE may contain at most the free variables self and x and accesses via path-expressions to an underlying “old” state σ : State(UC ), while POST may additionally contain the free variable result and accesses to the “new” state σ ′ : State(UC ). The definition in the OCL 2.0 proposal is similar to Z operation schemas: op ∆ State x ? : T1 result ! : T2 PRE (x ?, σ) POST (x ?, result !, σ, σ ′ ) where State : Exp is a schema over state variables σ containing the system invariant. The schema notation is just a notational variant of the (typed) set:   x ? : T1 , result ! : T2 , σ : State(UC ), σ ′ : State(UC )

 PRE (x ?, σ) ∧ POST (x ?, result !, σ, σ ′ )

Here, we propose a slight deviation from the OCL 2.0 proposal and allow PRE and POST to be undefined. Since sets {x | P (x )} are just isomorphic to characteristic functions P : τ → bool , it is natural to view the semantics of an operation op as a function IC [[op]] : T1 → T2 → STC → Boolean where T1 → T2 → STC → Boolean is just a curried (isomorphic) version of T1 × T2 × STC → Boolean. When turning the semantics into a shallow embedding, one more massaging step is necessary: ICS [[op]] : (STC → T1 ) → (STC → T2 ) → STC → Boolean or just: ICS [[op]] : VC (T1 ) → VC (T2 ) → VC (Boolean) where the type constructor VC (T1 ) is an abbreviation for STC → T1 . Note that this semantic function interprets a specification of op and thus constructs a kind of “three valued relation” between input and output state, i.e. a state may be clearly related to its successor, or may be clearly unrelated,

202

Achim D. Brucker and Burkhart Wolff

o” the relationship may be undefined (see discussion below). Our solution is very similar to the OCL 2.0 proposal; however, we allow the distinction between unrelated states and an unspecified relation between the states (see Sec. 4.4). Hence, when semantically interpreting a concrete operation op : T1 → T1 , the resulting type will be: ICS [[op]] : V C (T1 ) → V C (T2 ). Thus, there is a clear conversion scheme from OCL-types to HOL-OCL types, which corresponds to a semantic construction we call lifting that we support by appropriate combinators. The combinator lift1 (for “lift 1-ary HOL-function to shallow OCL interpretation”; see also previous section) is designed to hide the “plumbing” with respect to the state transitions. It is defined by: lift1 (f )(x )(σ, σ ′ ) ≡ f (x (σ, σ ′ )) (the combinators for the 2-ary and 3-ary case are analogous). 3.4

Logic

We define the Boolean constants true, false and ⊥L (undefined) as constant functions, that yield the lifted HOL-value for undefinedness, truth or falsehood: ⊥L : V C (Boolean) true : V C (Boolean) false : VC (Boolean)

⊥L ≡ λ(σ, σ ′ ) • ⌊⊥⌋ true ≡ λ(σ, σ ′ ) • ⌊True⌋ false ≡ λ(σ, σ ′ ) • ⌊False⌋

Following the previous section, the types for the logical operators are as follows: not : VC (Boolean) → VC (Boolean) and : VC (Boolean) → VC (Boolean) → VC (Boolean) or : VC (Boolean) → VC (Boolean) → VC (Boolean)

The logical operators and the “if then else endif” are the only exception from the rule that the OCL operators have to be strict. They must be defined individually. The definitions following the OCL 2.0 proposal are straight-forward, e.g.:  ⌊S ∧ T ⌋ if S (σ, σ ′ ) = ⊥ ∧ T (σ, σ ′ ) = ⊥    false if S (σ, σ ′ ) = ⊥ ∧ S (σ, σ ′ ) = false (S and T )(σ, σ ′ ) ≡ false if T (σ, σ ′ ) = ⊥ ∧ T (σ, σ ′ ) = false    ⊥L otherwise Note that due to extensionality of the HOL equality: ∀ x • f (x ) = g(x ) ⇒ f = g

HOL-OCL: Experiences, Consequences and Design Choices

203

the states can be “hidden away”. For example, instead of: (true and false)(σ, σ ′ ) = false(σ, σ ′ ) we can write equivalently: true and false = false The proof in Isabelle is easily done by applying extensionality and Isabelle’s proof procedure. The usual truth tables for Kleene logics were derived similarly: a true false ⊥L

not a false true ⊥L

a b a and b false false false false true false false ⊥L false

a b a and b true false false true true true ⊥L true ⊥L

a b a and b ⊥L false false ⊥L true ⊥L ⊥L ⊥L ⊥L

It is not difficult to derive with Isabelle the laws of the surprisingly rich algebraic structure of Kleene logics: Both and and or enjoy not only the usual associativity, commutativity and idempotency laws, but also both distributives and de Morgan laws. The main drawback of a three-valued Kleene logic is that the axiom of the excluded middle (a ∨ ¬ a = true) and the usual laws on implication do not hold, which makes their handling in proof procedures non-standard. Based on the logic, we define as suggested in the OCL 2.0 proposal ([22], satisfaction of operation specifications (see definition 5.34)) two notions of validity of an OCL formula: a formula P may be valid for all state transitions (
P ) or valid for some transition (σ, σ ′ ) ((σ, σ ′ )
P ). We define validity by:
P ≡ P = true

or (σ, σ ′ )
P ≡ P (σ, σ ′ ) = true(σ, σ ′ )

respectively. Note that P = false is equivalent to
not P and P = ⊥L is equivalent to
is undef P where is undef P ≡ λ st .⌊P st = ⊥⌋. This also extends to the validity for some transition. 3.5

Layered Semantics for the Library

A great advantage of shallow embeddings consists in the possibility to define the bulk of library operations via a theory morphism from HOL library theories: all OCL operators were defined uniformly in layers via combinators over HOL-operations, enabling theorems like e.g. “’concatenation is associative” (several thousand of these folk-theorems exist in the HOL-library and represent the basis for effective machine assisted reasoning) to be synthesized from their HOLcounterparts automatically; this extends to the operations for Integer, Real and Strings. For the parametric collection types (Sets, Bags, Sequences, and Tuples (as proposed in [22]), two further layers have to be considered: flattening and smashing. While the OCL standard 1.4 requires an automated flattening (whose semantics is not formally defined), the proposal for OCL 2.0 introduces a “manual” flattening operator which is also our preference. Further, for collections the

204

Achim D. Brucker and Burkhart Wolff

question arises how to handle the case of undefined values inserted into a collection. There are essentially two different possibilities for their treatment: Tuples, for instance, may be defined as follows: (⊥, X ) = (Y , ⊥) = ⊥ with the consequence: first(X , ⊥) = ⊥ and

second(⊥, Y ) = ⊥

Alternatively, tuples may be defined as: (⊥, X ) = (Y , ⊥) = ⊥ with the natural consequence: first(X , ⊥) = X

and

second(⊥, Y ) = Y

In [13, 23], the former is called “smashed product”, while the latter is the standard product. We also apply this terminology for sets, bags and sequences and suggest the use of smashed collection types and strict access operations (the OCL 2.0 proposal suggests a non-strict, even non-executable includes operation). Smashed collections mirror the operational behavior of programming languages such as Java and, hence, pave the way for an executable OCL subset (see also Sec. 4.6).

4

Consequences

It is worth noting that OCL semantics is traditionally considered as a denotational semantics (see also [23, chapter 5]) or state transition semantics for imperative languages. We will discuss the consequences for the notion of invariant, method specifications, their refinement and the connection to Hoare-logics and to programming languages implementing method specifications. 4.1

On Invariants in OCL

In the light of HOL-OCL, we have no problem with the explanation: O b j e c t

C o n s t r a i n t

L a n g u a g e

S p e c i f i c a t i o n [ 16] (version 1.4), page 6-52

An OCL expression is an invariant of the type and must be true for all instances of that type at any time. that raised some criticism by some researchers (e.g. [9]). Since OCL semantics describes “state transitions”, at any time means at any state that is reachable by the state transition relation. The issue of “intermediate states” that may violate invariants is a problem of a refinement notion or the combination with an axiomatic semantics (see Sec. 4.4). Even general recursion based on fixed-points for query operations does not change the picture since query operations may not have side-effects.

HOL-OCL: Experiences, Consequences and Design Choices

4.2

205

On Method Speci•–—˜™ons

In [9] it was asked what the precise nature of pre-and postconditions of a method is, and what happens if a precondition of a method m is not fulfilled. As possible behaviors, four cases are listed: the implementation of m might raise an exception, or may diverge, or may terminate without changing the state, or may produce a more or less arbitrary state. The authors argue that a pragmatically useful notion of specification should at least exclude the last case. In our formalization (following OCL 2.0), both conditions are conjoint and form a method specification. Thus, a false precondition simply says that there is “no transition” from a state to its successor; this corresponds to the operational behavior of an exception, a divergence or a deadlock. Moreover, an undefined precondition may either result in an undefined or false method specification; in the former case, no statement on the implementation is made, i.e. it may behave arbitrarily. Thus, when writing a specification, there is the possibility to explicitly distinguish these possibilities: a precondition a.c > 5 makes no statement for the case that a is an undefined object in a particular state (provided the postcondition is valid), in not is undef(a) and a.c > 5, however, it is explicitly specified that there is no successor state, if a is not defined in the previous state. We believe that this distinction is sensible and useful in connection with requirement collection and with refinement, albeit we foresee that these subtleties will not always be easy to swallow by practitioners. Further, [9] argues that there is the necessity for distinguishing total and partial correctness for OCL, and develop a formal machinery based on four correctness notions. Here is a confusion about the type of semantics: a precondition (or postcondition respectively) in the sense of Hoare-logics [23] is a “predicate over admissible states” (thus a set of states), that were related over a command. Hoare-logics describes the annotation of command sequences with predicates. In contrast, denotational OCL semantics just describes the relation on states (the keyword pre resp. post are purely syntactical). The difference can be seen best at one feature: in OCL, any variable that should remain invariant must be stated explicitly by x = x @pre (here, the semantics should be changed in order to limit this effect, say, to the attributes of a class), otherwise arbitrary transitions are possible; in contrast, in Hoare-logics, not occurring variables remain constant as a result of the consequence rule [23, p. 89]. Therefore, these correctness notions simply do not apply for OCL, they apply for a refinement of OCL to code. In [9], two “semantic styles” for method specifications were distinguished: the PRE ∧ POST -style and the PRE ⇒ POST style. While we adhere to the former (following the OCL 2.0 proposal), the authors of [9] advocate the latter. The PRE ∧ POST -style based on Kleene logics allows for two types of independent requirement collections that correspond to conjunction and disjunction (similar to the usual pragmatics in the Z schema calculus [24]). Both types profit from a style of specifications that uses undefinedness whenever possible in order to avoid over-specification. Conversely, conjunctions and disjunctions of method specifications allow for straight-forward splitting transformations of method specifications along the usual distributivity and de Morgan laws.

206

4.3

Achim D. Brucker and Burkhart Wolff

On Uš›œšœ›šœžž and the OCL Logics

The current OCL 2.0 proposal explicitly requires an explicit value for undefinedness and forces the logics to be a Kleene logic, prescribing algebraic laws like ⊥L and false = false etc. This particular choice has raised criticism [9], both for methodological and tool-technological reasons (the latter will be discussed in Sec. 5). In particular, another implication is proposed: A implies B ≡ not A or(A and B ) instead of the version prescribed in the standard: A implies B ≡ not A or B A routine analysis with Isabelle reveals that both definitions enjoy the same laws for a Hilbert-Style calculus: A implies B implies C = A and B implies C A implies(B or C ) = A implies B or A implies C A implies A = A (provided A = ⊥L ) However, the first definition fulfills ⊥L implies A = ⊥L , while the second fulfills ⊥L implies true = true. While we found the first version slightly more intuitive, we do not see any fundamental reasons for preferring one definition to the other. Also, we investigated both implication versions in the context of a natural deduction calculus for OCL; here, the differences were also minimal. 4.4

On RœšœŸent in OCL

Based on denotational method semantics and based on the validity notion introduced in Sec. 3.4, it is now an easy exercise to adopt, for example, the standard data refinement notion of Z ([19, p. 138], c.f. [24], where it is called “forward simulation”). As a prerequisite, we introduce an abstraction predicate R that relates two states which may even be of two different data universes, i.e. we may have an abstract operation based on STC , while the implementing operation is based on STC′ . Further, we define the usual predicate transformer pres,in (P ) which decides if for a state s and an input in there exists a successor state and output that makes the method specification valid. Recall that this “semantic” precondition construction is necessary since the PRE and POST part of a specification are a purely syntactical separation. Our first refinement notion — called validity refinement — is defined in HOL for the abstract method specification Mabs and the concete method specification Mconc of type VC (Tin ) → VC (Tout ) → VC (Boolean) as follows: Mabs ⊑R V Mconc = ∀ sa sc in • presa ,in (Mabs ) ∧ (sa , sc ) ∈ R ⇒ presc ,in (Mconc ) ∧ ∀ sa sc sc′ in out • presa ,in (Mabs ) ∧ (sa , sc ) ∈ R ∧ (sc , sc′ )
Mconc in out ⇒ (∃ sa′ • (sa′ , sc′ ) ∈ R ∧ (sa , sa′ )
Mabs in out )

HOL-OCL: Experiences, Consequences and Design Choices

207

Validity refinement is based on the idea, that whenever a transition is possible in Mabs , then it must be possible in a corresponding implementation transition in Mconc to find a successor state sa′ which is related to a possible successor state of Mabs . This refinement notion is only based on valid transitions. In the presence of Kleene logic, we can distinguish undefined transitions from impossible ones by replacing validity by invalidity. We define “failure refinement” as follows: Mabs ⊑

R F

Mconc = Mabs ⊑

R V

Mconc ∧ F (Mabs ) ⊑R V F (Mconc )

where F M in out = not(M in out ) (Recall that M in out = false is equivalent to
not(M in out ). Thus, the implementation notions describe in different degrees of precision that the underlying transition systems were refined to “more deterministic and more defined ones”. Of course, other refinement notions may be transferred to OCL along the lines presented above; e.g. backward simulation [24]. Further, it is possible to link method specifications to implementations in concrete code of a programming language like Java. Technically, this is an integration of a denotational semantics with a Hoare logic (c.f. [23], see also the corresponding formal proofs in Isabelle [1]); meanwhile, it is feasible to combine HOL-OCL with a Hoare logic for NanoJava [15]. Of course, such a combination will inherently be programming language specific. An in-depth discussion of these alternatives, however, is out of the scope of this paper. 4.5

On Recursive Methods

Both the OCL standard 1.4 and the standard draft 2.0 allow recursive methods “as long as the recursion is not infinite”. The documents make no clear statement what the nature of non-terminating recursive definitions might be. Essentially two possibilities come to mind: – It could be illegal OCL. However, since non-termination is undecidable, this would imply a notion of well-formedness, that is not machine-checkable. A variant of this approach is the restriction to well-founded recursion; however, this would require new syntactic and semantic concepts for OCL (wellfounded orderings, measure-statements, etc.). – It could be “undefined”, i.e. ⊥L . This is consistent with the least fixpoint in the theory of complete partial orderings (cpo; c.f. [23]). This idea has already been proposed by [5]. The theory of cpo’s is a strict extension of semantic domains with undefinedness and yields a least-fixpoint operator, which gives semantics on recursive equations of methods. This enables method implementations that can be handled as an add-on to the OCL standard (see [3] for more details). Since recursive methods are executable and increase the expressive power of OCL, we encourage their use. However, this extension does not come for free: first, the semantics of a method invocation (static binding vs. late binding) must be clarified; Moreover, with respect to code generation, a particular treatment of undefinedness in the logical connectors is necessary.

208

4.6

Achim D. Brucker and Burkhart Wolff

On Executability of OCL

OCL is based on a design rationale behind the semantics: OCL is still viewed as an object-oriented assertion language and has thus more similarities with an object-oriented programming language than a conventional specification language. For example, operations are defined as strict, only bounded quantifiers are admitted, and there is a tendency to define infinite sets away wherever they occur. As a result, OCL has a particularly executable flavor which comes in handy when generating code for assertions or when animating specifications. However, seen from meta-language such as HOL, many of these restriction seem to be ad hoc add complexity, while excluding expressiveness. For example, states must be finite — this is a restriction never needed in the semantics; allInstances of basic types like Int is defined as ⊥L , etc. Moreover, these restrictions tend to make the language “not self-contained”, i.e. some side-conditions like “the operation must be associative” (see the definition of collection-¿sum():T in [16]) of OCL can not be treated inside OCL and make a meta-language such as HOL necessary for a complete formal treatment). Further, these restrictions represent an obstacle for defining a library of mathematical definitions and theorems comparable to the Mathematical Toolkit in Z, which turned out to be vital for its success. We suggest to omit all these restrictions and to define an executable sub-language of OCL, which could comprise recursive methods, strict versions of the logical operators, smashed collections, etc. Admitting infinite sets paves the way for lazy evaluation code schemes and their animation.

5

Mechanization

HOL-OCL provides a natural deduction calculus and a Hilbert-style calculus which builds together with powerful OCL rewriting rules the foundation for automated proof techniques for OCL. The basis of our deduction calculus are the notions for validity introduced in Sec. 3.4. Since they are in itself two-valued judgments in HOL, there is no fundamental problem to reason about these in Isabelle’s (two-valued) proof engine, let it be the tableaux-prover or the rewrite engine. In particular the latter can be used to compute normal forms of OCL specifications, i.e. disjunctive normal forms suitable to generate test cases out of a method specification (see [3] for more details). Information about definedness is often “hidden” in the context of OCL formulae, e.g. when rewriting B in the context
A and B , we can assume
A and therefore the definedness of A. This kind of context rewriting can be used in Isabelle’s rewriting procedure, that can therefore simplify: c o n t ex t A pre : s e l f . x A(s1) else if (state == s2) then send_c -> ackn_A -> A(s1) else STOP

217

A_Port_in = A_p_in ? x -> if ( x == B_b) then queue_b -> A_Port_in else A_Port_in A_Port_out = send_c -> A_p_out ! A_c -> A_Port_out

Fig. 3. The statechart process and the port processes For each port pi , a process CSP (pi ) = Portiin ||| Portiout is composed by interleaving two unidirectional port processes for in- and outgoing messages which synchronize over events piin ?m and piout !n with the attached connector process and over events sendn and  ¡euem with the statechart process. In Figure 3, the statechart process derived from the statechart SA in Figure 1 and the two port processes, one for incoming and one for outgoing messages, is shown (the process associated to the event queue is not shown in the figure). Since explicit specification of connector behavior is not supported by UMLRT, we use connector stereotypes for selecting specific, pre-defined connector behavior. For example, one can thus select blocking or non-blocking behavior, or the restriction to a certain buffer capacity, etc. For each connector of stereotype c between two ports pi and pj , we construct a connector process CSP (c) = CSPpi ,pj (c) ||| CSPpj ,pi (c) by interleaving two unidirectional connector processes which formalize the intended behavior associated with the stereotype. They synchronize with the port processes over events piin ?m, piout !n and pjin ?n, pjout !m. Composing all statechart, port and connector processes P1 , . . . , Pn in parallel, we obtain a process CSP (M ) =  (Pi , αPi ) which represents the complete i= 1..n behavior of the model M . Here, αPi denotes the synchronization alphabet of process Pi as described above. Sometimes we are specifically interested in the communication of two capsules over a connector as shown in Fig. 1. In this case, we construct the capsule-connector-capsule process CCC (A, p1 , c, p2 , B ) = 

i= 1..5

(Pi , αPi )

where P1 = V p1 (SA ) and P2 = V p2 (SB ) represent the views of port p1 and p2 on SA and SB , respectively, obtained by hiding from the statechart processes all events not relevant to the ports. Moreover, P3 = CSP (p1 ) and P4 = CSP (p2 ) are the port processes while P5 = CSP (c) models the connector. The two consistency issues identified above can be formalized as follows. 1. Deadlock freedom. The model M is deadlock free if the process CSP (M ) is deadlock free, that is, DF ⊑F CSP (M ). 2. Protocol consistency. A capsule-connector-capsule combination as shown in Fig. 1 is consistent with a protocol statechart SProt if CSP (SProt ) ⊑T CCC (A, p1 , c, p2 , B ). The model M is protocol consistent if all capsulesconnector-capsule combinations are consistent with their protocols.

218

Gregor Engels et al.

Protocol consistency requires that all traces of the process CCC (A, p1, c, p2, B ) are contained in the traces of the process CSP (SProt ). Referring to the example in Figure 1, protocol consistency holds because all traces generated by the execution of the statecharts conform to the specified protocol. By translating UML-RT models to CSP we have therefore gained a precise formal definition for protocol consistency and deadlock freedom. Automating the translation process [2] enables automated checking of consistency using tools such as the FDR model checker [4]. Within model evolution, the UML-RT model changes and therefore also its CSP counterpart. The UML-RT model remains consistent if its CSP translation remains consistent. As a consequence, it is necessary to understand the effects that CSP refinement relations induce on the UML-RT level. In other words, we need to discuss what it means for a statechart to refine another one, more precisely, how can we change a statechart such that it remains a refinement in the terms of the CSP translation? Concerning trace refinement, a statechart SB ′ trace refines another statechart SB if CSP (SB ) ⊑ T CSP (SB′ ). That means that all traces generated by SB′ must be contained in the set of traces of SB . Intuitively, for a statechart that means that every sequence of events and actions possible for SB′ must also be possible for SB . As a consequence, in the process of refinement, we are allowed to delete transitions in the statechart SB to get SB′ . However, we cannot introduce new transitions with new events. As an example, consider the protocol statechart in Figure 1. If we construct a new protocol statechart by deleting an arbitrary transition (e. g. the B.send b transition), then the new protocol statechart is a trace refinement of the old protocol statechart. Concerning failures refinement, first of all the condition of trace refinement must hold (note that failures refinement is stronger than trace refinement). Additionally, the set of failures of CSP (SB′ ) must be included in the set of failures of CSP (SB ). Recalling failures calculations for CSP processes, we can also annotate a statechart with a refusal set. We note that in general we are not allowed to delete transitions in the process of failures refinement because this introduces additional failures. Referring to the properties of CSP, we are only allowed to make the statechart more deterministic.

5

Consistency-Preserving Model Evolution through Transformations

One of the main advantages of the component-based approach to software development over the classical paradigm of object-oriented programming is the possibility to keep the effect of changes local. This is achieved by strict encapsulation using interfaces (ports) which do not only specify the messages that a component is able to receive, but also the messages it is able to send. However, despite these advantages, we still face the problem of ensuring consistency after the model has evolved. Consider as an example the evolution of the traffic lights described in Figure 4. A new car sensor capsule is added to the

Consistency-Preserving Model Evolution through Transformations

219

Fig. 4. Evolution of the traffic lights model in UML-RT system and connected to one of the traffic lights. In order to ensure the correct functioning of the system, deadlock freedom and protocol consistency must be ensured. One way would be to reiterate all consistency checks which is obviously very time-consuming. Therefore, we shall try to exploit the locality principle. That means to formalize evolution by means of local transformations, like the creation or deletion of a capsule or connector, the update of a capsule or protocol statechart, etc., and to study the effects of these transformations on various consistency properties. The aim is to establish the consistency of the new model in an incremental way rather than to verify again the complete model. In fact, we believe that any approach to consistency that cannot deal with evolution locally must fail in realistic development scenarios with frequent re-iterations of modeling, implementation, and testing. Our approach consists of the following steps. First, model transformations are specified by means of transformation rules representing elementary evolution steps that may be combined in various ways to achieve more complex changes. Second, for each transformation rule local application conditions are specified which, when satisfied, ensure the preservation of a certain more global consistency property. The specification of rules and conditions happens once and for all at the language level, although the experience from concrete examples is required to validate their practicability. In order to manipulate a given model we have to determine the kind of change we want to achieve as well as its location in the model. This corresponds to the selection of a rule and its application area. Then, the rule may be applied provided that all those application conditions are satisfied that are required for the consistency properties to be preserved. If there is no consistency-preserving transformation for the change we intend to do, we have to resort to ad-hoc evolution with a complete consistency check of the new model.

220

Gregor Engels et al.

SB‘ r1

B

r2

r3

B

B

p2

A

B p1

A

p2

p1 p2

B

SProt r4

A p1

p2

B

A

p1 p2

B

Fig. 5. Transformation rules for creation and deletion Notice that we do not deal with dynamic (i.e., run-time) evolution. This would require, in addition, to take into account the states of capsules and protocols in order not to disturb ongoing interactions. 5.1

Rule-Based Model Transformations

We provide creation/deletion rules for model elements like capsules, connectors, and protocol statecharts (cf. Fig. 5) as well as update rules for capsule and protocol statecharts and connectors (cf. Fig. 6). Each rule consists of two patterns representing the situation before and after the change. For example, the rule r3 assumes two capsules A and B with an unconnected port each and creates a connector between them. When read from right to left, the inverse rule r3¢1 removes an existing connector from its ports. The possibility to use a rule in both ways is represented by a double arrow. Rules r1 , r2 , r4 and their inverses work analogously. In the case of r1 the empty pattern on the left means that the rule can be applied anywhere. For the inverse r1¢1 it is important to note that the deletion of a capsule is only allowed if there is no port attached to it. This is no real limitation since we may use r3¢1 first to remove all connectors, then removing all ports with r2¢1 . Removing connectors, in turn, we have to take care to delete any attached protocol statecharts first using rule r4¢1 , etc. Formally, our rules can be interpreted as graph transformation rules on instances of the meta model defining the syntax of the language UML-RT. The restriction of applicability described above are typical of the so called algebraic approach [1] to graph transformation which takes a conservative approach, disallowing the deletion of vertices if this would cause “dangling links”. The rules in Fig. 6 specify the update of model elements, by exchanging a capsule statechart (rule r5 ), replacing a protocol statechart (rule r6 ) and modifying the type of a connector (rule r7 ), e.g., to increase its buffer size. Often,

Consistency-Preserving Model Evolution through Transformations

r5

SB

SB‘

B

B

SProt r6

r7

A

p1 p2

SA A

p1 p2

221

SProt‘ B

A

SB

SA

B

A

p1 p2

B

SB p1 p2

B

Fig. 6. Transformation rules for update a similar effect can be achieved by first deleting a model element and then creating a new one using the rules of Fig. 5. However, to combine these two steps in one rule allows us to relate the semantics of the original and its replacement, e.g. by requiring that the second is a refinement or extension of the first. This idea can be generalized by constructing more powerful, but less generic rules dedicated to handle evolution scenarios which occur frequently in a certain class of applications. For example, the change to the traffic light model in Fig. 4 could be either obtained by a sequence of elementary transformation steps or by a single complex step. 5.2

Preservation of Consistency

After identifying possible evolution steps by means of model transformation rules, we now consider the question how the application of these rules has to be constrained if a certain consistency property shall be preserved. That means, we shall assume that the original model has a certain property, like deadlock freedom or protocol consistency, and we shall formulate conditions for the application of transformation rules which ensure that the transformed model enjoys a similar property. Formally, we will exploit the mapping of UML-RT models to CSP processes to prove that the stated conditions are indeed sufficient to ensure the preservation of the property. Here, the choice of CSP as a semantic domain is most important: Beside the fact that properties can be formulated and automatically verified, this semantic domain provides useful theoretical results about refinement and composition of processes that we shall use in the proofs. First, we state some simple preservation properties of creation/deletion rules. Theorem 1 (simple preservation properties). 1. The rules r1 , r2 and r3 , as well as their inverses, preserve protocol consistency.

222

Gregor Engels et al.

2. Rule r1 , r2 , r4 , r1£1 , r2£1 , r4£1 preserve deadlock freedom. 3. Rule r4£1 preserves protocol consistency, while rule r4 does so under the condition that the communication of A and B over the connector refines SProt . Proof. We only give a formal proof for r2 : Recall that CSP (M ) = 

(Pi , αPi )

i=1..n

and CSP (M ′) =  (Pi , αPi ) where Pn+1 is the new port process. As the i=1..n+1 capsule statechart is not changed by this rule, it does not reference any signals associated to the protocol of the new port. Therefore, αPn+1 is disjoint from all other alphabets and thus the port process does not synchronize on any event with any other process. By prerequisite, CSP (M ) is deadlock free and therefore also CSP (M ′) because the behavior of all other processes remains the same. The properties of r1 /r1£1 are based on the fact that there is no connection whatsoever between the the newly created or deleted capsule and the rest of the model. For rules r2 /r2£1 we have to observe that the capsule behavior does not change when introducing a port because the capsule statechart remains the same. In the case of creation, the capsule statechart before the transformation could not refer to events related to the port because the port did not yet exist. In the case of deletion, the application of the rule is prohibited as long as there is any reference to the port. This is, again, a consequence of the conservative approach which does not allow for dangling references thus maintaining syntactic well-formedness of the model. Therefore, rule r2 /r2£1 is only meaningful in combination with r4 which changes the behavior of the capsules to exploit/ignore the port. More interesting is the rule r4 introducing a new protocol statechart because it requires to check the consistency of the capsule-connector-capsule construct with the new protocol. Rule r4£1 , instead, is just removing this requirement. For r3 /r3£1 , it is crucial to observe that, although there is no change to the capsule statecharts, the overall behavior may change dramatically if the capsule statecharts specify send or receive operations via the newly connected/ disconnected ports, which become activated/blocked by the change in the communication structure. We first note that that creation and deletion of connectors preserves protocol consistency because protocol consistency considers only local behavior of the capsules involved in the communication over the connector the protocol statechart is associated with. However, in general deadlock freedom is not preserved when creating or deleting a connector. As simple example, consider Figure 7. The system before application of r3 is deadlock free because A and B continuously exchange messages. After plugging in the connector, C sends an a to B causing B to end its activities. After that, A is blocked because it does not receive any messages from B anymore, B has terminated and so has C . As a consequence, the system deadlocks. Concerning the evolution of the capsule statechart itself, we can establish the following theorem.

Consistency-Preserving Model Evolution through Transformations

223

Fig. 7. Rule r3 does not preserve deadlock freedom Theorem 2 (capsule statechart evolution). 1. Rule r5 preserves the protocol consistency of all capsule-connector-capsule constructs (X , p1 , c, p2 , Y ) where X = B implies that V p1 (SB¤ ) is a trace refinement of V p1 (SB ) and, analogously, Y = B implies that V p2 (SB¤ ) is a trace refinement of V p2 (SB ) 2. If the new capsule statechart SB¤ is a failures refinement of SB , then r5 preserves deadlock freedom. Proof. 1. Let X=B. We know that CSP (SProt ) ⊑T CCC (B , p1, c, p2, Y ). By prerequisite, V p1 (CSP (SB )) ⊑T V p1 (CSP (SB ′ )) and thus, by closure of traces refinement under context, CCC (B , p1, c, p2, Y ) ⊑T CCC (B ′, p1, c, p2, Y ) and by transitivity the result follows. 2. If CSP (SB ) ⊑F CSP (SB ′ ) then CSP (M ) ⊑F CSP (M ′) by properties of refinement. As DF ⊑F CSP (M ), deadlock freedom of CSP (M ′) follows by transitivity. With respect to preserving protocol consistency, we have to ensure that the view of a port on the statechart remains the same. For a statechart that means that we can change it as long as we do not affect the traces concerned with the exchange of messages via the port. As an example, recall Figure 1 and statechart SA . In order to keep the view on the port the same, we could for example add a concurrent substate to the statechart exchanging messages via a new port. We could also expand the state s1 or s2 and do some additional transitions, but not any sending or receiving messages via the port: We are in general not allowed to add a transition sending or receiving a message via the old port, thereby introducing a new trace and violating the trace refinement property. Concerning the evolution of the protocol statechart using rule r6 we can show that, if the original model is protocol consistent and the new protocol statechart is an extension (an inverse refinement) of the old one, then the new model is also protocol consistent. That means, we may weaken the protocol statechart to allow more sequences of message as long as we keep the original sequences.

224

Gregor Engels et al.

Theorem 3 (protocol statechart evolution). Rule r6 preserves protocol consistency if SProt is a trace refinement of SProt ¥ . Proof. Let SProt be associated to CCC (A, p1, c, p2, B ). If CSP (SProt ¥ ) ⊑T CSP (SProt ) then all traces contained in the old protocol are also contained in the new protocol. As CSP (SProt ) ⊑T CCC (A, p1, c, p2, B ), by transitivity of trace refinement it follows that CSP (SProt′ ) ⊑T CCC (A, p1, c, p2, B ). Concerning the exchange of a connector depicted in r7 , we can show that if the new connector (process) is a trace refinement of the old one, then r7 preserves protocol consistency and if the new connector (process) is a failures refinement of the old one, then r7 preserves deadlock freedom. Providing predefined connector stereotypes, each of it associated to a specific connector process, we can check connector processes for refinement properties once and for all. In principle, refinement properties of connectors depend very much on their underlying behavior (i. e. whether a connector is non-blocking or blocking and how large its capacity is). After discussing the evolution according to minimal evolution steps, one can also establish theorems for consistency-preserving complex evolution steps combining the application of a number of the rules discussed. For example, the introduction of a new connector (r3 ) often leads to a change of capsule behavior (r5 ). In the following, we give an exemplary theorem for such a combined evolution. We assume here, that the left hand sides of rules are identified (i. e. that capsule B is the same capsule in both rule applications) which need not be the case in general. Theorem 4 (combined evolution). An evolution according to r3 and r5 preserves deadlock freedom under the condition that V p2 (CSP (SB ′)) ||| CSP (SB ) is failures e¦uivalent to CSP (SB ′). Proof. If CSP (SB ′) is failures equivalent to V p2 (CSP (SB ′)) ||| CSP (SB ), then in CSP (M ′) the complete deadlock free behavior of CSP (M ) is contained and this is not influenced by the addition of the new connector and new behavior. As a consequence, CSP (M ′) is deadlock free. In practice, this means that we can add a new capsule together with a capsule statechart and a connector attached to an old capsule and the complete model remains deadlock free, if we extend for example the existing statechart with a concurrent substate. Returning to our motivating example of the traffic lights (see Figure 4), we can now study the evolution in detail. We first identify the individual transformation rules that might have been used to change the model. In our case, we may apply rules r1 for adding capsule instance c of type c arSensor, twice r2 for adding two new ports for traffic light TLA and carSensor, r3 adding a new connector and r5 changing the behavior of the statechart for TLA for example for counting the cars crossing the intersection at a traffic light.

Consistency-Preserving Model Evolution through Transformations

225

Using the theorems above, one can verify in an incremental way that the model remains protocol consistent. In fact, this preservation holds unconditionally for all but the last step, while for r5 according to Theorem 2.1 we have to check if SA§ refines SA with respect to the two original ports. In the present example, this might well be the case if the new interaction with the car sensor is transparent for the other components. However, even under this assumption, we cannot automatically conclude that the evolution preserves deadlock freedom because of the application of r3 to add the new connector. Using the theorem for combined evolution, deadlock freedom can be established if the change from SA to SA ′ consists of adding a new concurrent substate capturing the new behavior via the new port.

6

Conclusion

Model-level evolution is important because it allows to deal with a key problem of software development at high level of abstraction. However, in order to be of any use, the consistency of models must be maintained as a key prerequisite for a successful mapping to an implementation. In this paper, we have shown how consistency of UML-RT models can be formalized by mapping important aspects of the model into a semantic domain, specifying the consistency requirements as relations between semantic objects and performing static analysis to verify these relations. We have introduced rule-based transformations of UML-RT models to describe both structural and behavioral evolution steps. For each rule, we have formally shown which conditions are required to preserve certain consistency properties, and discussed examples where consistency properties are, in general, not preserved. We have learned that consistency is a semantic issue which should be dealt with by formal methods (in our case CSP) providing a specification language and tool support for analysis and, last but not least, an established theory for verifying models and transformation rules. In our specific example, we have largely exploited the fact that CSP refinements are transitive and closed under substitution of processes. This allowed us to show that a local relation between the replaced submodels is sufficient to preserve global consistency. Here, the choice of the semantic domain is crucial because, e.g., in a model checking approach not supporting such compositionality results, local analysis is not sufficient. Future work includes the establishment of more powerful combined evolution theorems as well as the extension of this approach to support further aspects of UML-RT such as hierarchy of capsules. Furthermore, the approach shall be applied to other consistency problems in other semantic domains, thereby enabling consistency-preserving evolution also for other UML dialects.

226

Gregor Engels et al.

References [1] H. Ehrig, M. Pfender, and H. Schneider. Graph grammars: an algebraic approach. In 14th Annual IEEE Symposium on Switching and Automata Theory, pages 167– 180. IEEE, 1973. 220 [2] G. Engels, R. Heckel, and J. M. K¨ uster. Rule-based specification of behavioral consistency based on the UML meta-model. In M. Gogolla and C. Kobryn, editors, UML 2001 - The Unified Modeling Language. Modeling Languages, Concepts, and Tools., 4th International Conference, Toronto, Canada, October 1-5, 2001, Proceedings, volume 2185 of LNCS, pages 272–287. Springer, 2001. 213, 218 [3] G. Engels, J. M. K¨ uster, L. Groenewegen, and R. Heckel. A methodology for specifying and analyzing consistency of object-oriented behavioral models. In V. Gruhn, editor, Proceedings of the 8th European Software Engineering Conference (ESEC), pages 186–195. ACM Press, 2001. 213, 216 [4] Formal Systems Europe (Ltd). Failures-Divergence-Refinement: FDR2 User Manual, 1997. 218 [5] J.-J. Hiemer. Statecharts in CSP: Ein Prozessmodell in CSP zur Analyse von STATEMATE-Statecharts. DrKovac Verlag, 1999. 216 [6] C. A. R. Hoare. Communicating Sequential Processes. Prentice Hall, 1985. 213, 215, 216 [7] J. Jahnke and A. Z¨ undorf. Using graph grammars for building the VARLET database reverse engineering environment. In G. Engels, H.-J. Kreowski, and G. Rozenberg, editors, Handbook of Graph Grammars and Computing by Graph Transformation, Volume 2: Applications, Languages, and Tools. World Scientific, 1999. 213 [8] M. L¨ owe. Evolution patterns. Postdoctoral thesis, Technical University of Berlin. Tech. Report 98-4, Dept. of Comp. Sci, 1997. 213 [9] W. McUmber and B. Cheng. A General Framework for Formalizing UML with Formal Languages. In Proceedings 23rd International Conference on Software Engineering. IEEE Computer Society, May 2001. 213 [10] T. Mens, S. Demeyer, and D. Janssens. Object-oriented refactoring using graph rewriting. Technical Report vub-prog-tr-02-01, Vrije Universiteit Brussel, 2001. 213 [11] Object Management Group. Model driven architecture, 2001. http://www.omg.org/mda. 212 [12] A. W. Roscoe. The Theory and Practice of Concurrency. Prentice Hall, 1998. 216 [13] B. Rumpe, M. Schoenmakers, A. Radermacher, and A. Sch¨ urr. UML + ROOM as a standard ADL? In Proc. ICECCS’99 Fifth IEEE International Conference on Engineering of Complex Computer Systems, Las Vegas, USA. IEEE Computer Society Press, 1999. 214 [14] B. Selic. Using UML for modeling complex real-time systems. In F. Mueller and A. Bestavros, editors, Languages, Compilers, and Tools for Embedded Systems, volume 1474 of Lecture Notes in Computer Science, pages 250–262. Springer Verlag, 1998. 213, 214 [15] G. Suny´e, D. Pollet, Y. LeTraon, and J.-M. J´ez´equel. Refactoring UML models. In M. Gogolla and C. Kobryn, editors, UML 2001 - The Unified Modeling Language. Modeling Languages, Concepts, and Tools., 4th International Conference, Toronto, Canada, October 1-5, 2001, Proceedings, volume 2185 of LNCS, pages 134–148. Springer, 2001. 213

Consistency-Preserving Model Evolution through Transformations

227

[16] M. Wermelinger and J. Fiadero. A graph transformation approach to software architecture reconfiguration. In H. Ehrig and G. Taentzer, editors, Joint APPLIGRAPH/GETGRATS Workshop on Graph Transformation Systems (GraTra’2000), Berlin, Germany, March 2000. 213

Transformations and Software Modeling Languages: Automating Transformations in UML Jon Whittle QSS Group Inc., NASA Ames Research Center Moffett Field, CA 94035 [email protected]

Abstract. This paper investigates the role of transformations in the Unified Modeling Language, specifically UML class diagrams with OCL constraints. To date, the use of transformations in software modeling and design has not been fully explored. A framework for expressing transformations is presented along with concrete examples that, for example, infer new inheritance links, or transform constraints. In particular, a technique for checking that two UML class diagrams are refactorings of each other is described.

1

Introduction

Transformations play a central role in software engineering. They have found widespread use in traditional applications such as optimizing compilers, as well as in contemporary activities such as the use of XML and XSLT to translate between different data formats. To date, however, the use of transformations in practical software ¨©dªling has been limited (cf. [3, 9, 1] for the state of the art). This paper begins to redress this imbalance by presenting a framework for representing transformations of modeling notations along with examples of transformations and their applications. There are a number of potential starring roles for transformations. In particular, the widespread use of the Unified Modeling Language (UML) [10] provides an immediate user base for model transformation techniques. This paper focuses on applications of transformations within UML (as opposed to transformations from UML to another language). Possible roles for transformations include the following: 1. model optimizations (transforming a given model to an equivalent one that is optimized, in the sense that a given metric or design rule is respected); 2. consistency checks (transforming different viewpoints of the same model into a common notation for purposes of comparison — cf. [12] for an example of consistency between UML sequence diagrams and UML’s constraint language OCL); 3. automation of parts of the design process (cf. [2] for recent work in this field) using transformations. J.-M. J´ ez´ equel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 227–242, 2002. c Springer-Verlag Berlin Heidelberg 2002


228

Jon Whittle

The paper will give an extended example of the use of transformations in an application of type (3) above. The example concerns the use of transformations to show that two class diagrams (with additional constraints) are refactorings of each other. Refactoring is the process of redesigning the structure of a software artifact without changing its behavior. It is usually applied to code to make it more readable or reusable, but can just as usefully be applied to models of the code. Indeed, it could be argued that refactoring is more important at the modeling level since restructurings are very common at this stage of the development process. This paper presents a technique for checking refactorings, along with an empirical example that demonstrates its use in practice. Initial implementation of the transformation framework was done in the logicbased programming language Maude [5]. Maude code consists of a set of equations and rewrite rules. The Maude execution engine applies these rules to transform a given term and can be tailored to particular execution strategies using Maude’s meta-level. Maude provides a suitable environment for experimenting with and automating the application of transformation rules in UML. An implementation of the abstract syntax of UML already exists as a set of Maude theories [11]. This implementation faithfully mirrors the UML meta-model and is a suitable basis for implementing UML-based transformations. Maude proved to be a suitable environment for experimenting with transformation rules. There have only been a small number of papers that directly deal with modellevel transformations in UML, and most of these have been concerned with the formal semantics of the transformations and proofs that they maintain correctness. [6] presents a set-theoretic formalization of what it means for one class diagram to be a logical consequence of another: a well-formed diagram D ′ follows from a well-formed diagram D if and only if every set assignment that satisfies D also satisfies D ′ . A well-formed class diagram is one that conforms to the UML specification [10]. A set assignment is the assignment to each class a set of object instances, and to each association a set of links between object instances. Informally, a set assignment then satisfies a class diagram, D , if the assignments of objects and links respects the semantics (according to the UML specification) of each of the class and association specifications in D . Although the issue of correctness of transformations is an important one, it is not considered in this paper. Instead, the emphasis is on automation of transformation applications. Automation means both implementing the transformation rules so that they can be executed and automating the application of sequences of transformation rules, which can be carried out by grouping rules together into strategies and searching through the possible applications of the strategies to achieve some goal. Although other work (e.g., [1, 9, 6]) has given examples of transformations, no attempt has yet been made to automate the construction of sequences of transformations that carry out a particular task.

Transformations and Software Modeling Languages

2

229

Transformations in UML

«¬­

®¯°±²³²´±µ

This paper will limit discussion to UML class diagrams annotated with OCL constraints. In addition, advanced features of class diagrams (such as interfaces, parameterized classes, etc.) will be ignored. In principle, many of these advanced features can be described in terms of the more basic notions given (see [8]). A UML class diagram is represented by a ternary mixfix operator: C l asses # Associations with Constraints where Classes may represent either a UML class or type1 and constraints are general restrictions on the class diagram that will be given as OCL constraints in this paper. Classes, Associations and Constraints are each sets whose elements are formed from the following constructors: ¶·¸µµ(classN ame, Attributes, Operations) ¸µµ´¶²¸³²´±(assocN ame, assocEnd1 , assocEnd2 )

o ¶·¹´±µ³º¸²±³(expression, modelElement, stereotype) where classN ame and assocN ame are drawn from the set of class names and association names, ClassN ames and AssocN ames, respectively. There are similar sets, AttrN ames and OpN ames, to hold the names of attributes and operations. Sets will be denoted using identifiers with upper case initial letters. Where necessary, elements of sets will be written down separated by whitespace. Each class has a set of attributes and a set of operations. Each constraint is formed from an OCL expression, a model element that is the context of the constraint, and a stereotype that denotes the kind of constraint (e.g., invariant, pre-condition). Each association has two association ends, assocEnd1 and assocEnd2 , represented as follows2 : ¸µµ´¶»±¼(classN ame, M ultiplicity, assocT ype, navigable)

The association end is attached to the classifier classN ame. M ultiplicity is a set of (possibly unbounded) integers denoting the possible number of instances of classN ame associated with each instance of the classifier at the opposite end of the association. assocT ype is either gen, agg, comp or assoc depending on whether the association end is a generalization, aggregation, composition or regular association, respectively. navigable is a boolean value denoting whether or not the association is navigable towards this association end. Note that generalization relations are only navigable in one direction (from child to parent) and so such associations will always have false navigability from parent to child. 1 2

Throughout, class will be used to mean either class or type Association ends may also have orderings, qualifiers, rolenames, interface specifiers, changeabilities and visibilities (see [10], page 3-71) but these are omitted in this paper.

230

Jon Whittle

This formalization has been implemented in the logic-based programming language Maude by researchers at the University of Murcia [11]. The transformation rules presented in the next section were also implemented in Maude using this formalization as a basis. 2½ 2

¾¿ÀÁÂÃÄ¿ÅÀÆÇoÁ ÈÉÊËÂ

This section presents a number of examples of transformation rules on UML class diagrams with constraints. ¾¿ÀÁÂÇÆÇvity Äà ÌÂÂÄÍÇÀÆÇÄÁ The same model structure can be represented in many different ways using a class diagram. Transformations that derive new model elements (called enhancement transformations in [9]) augment a given diagram with additional classes, associations or constraints that can be logically inferred from the current structure. Enhancement transformations can be used to make explicit design documentation that may have been left hidden by the designer. Figure 1 shows an example of an enhancement transformation that infers new associations in a class diagram using the transitivity property of associations. Transformation rules should be interpreted such that if any part of a class diagram is able to match with the LHS of the rule, then the rule is available to fire. On firing, the sub-diagram matching with the LHS is replaced by the RHS with the appropriate instantiations of variables. A rule that derives new associations must infer the classes to which the association is attached as well as the multiplicities and association types at each end of the association. The rule in Figure 1 says that given an association between c 1 and c 2 and an association between c 2 and c 3 , an association can be derived between c 1 and c 3 . m u l t 1 and m u l t 2 calculate the appropriate multiplicities at each end of the new association. ass1 and ass2 determine the association types at each new association end. nav1 and nav2 calculate the navigabilities. Figure 2(a) shows an example of a rule application

association(assocN ame1 , assocEnd(c1 , M1 , a1 , v1 ), assocEnd(c2 , M1′ , a′1 , v1′ )) association(assocN ame2 , assocEnd(c2 , M2 , a2 , v2 ), assocEnd(c3 , M2′ , a′2 , v2′ )) =⇒ association(newAssocN ame, assocEnd(c1 , mult1 (M1 , M1′ , M2 , M2′ ), ass1 (a1 , a′1 , a2 , a′2 ), nav1 (v1 , v1′ , v2 , v2′ )), assocEnd(c3 , mult2 (M1 , M1′ , M2 , M2′ ), ass2 (a1 , a′1 , a2 , a′2 ), nav2 (v1 , v1′ , v2 , v2′ ))) association(assocN ame1 , assocEnd(c1 , M1 , a1 , v1 ), assocEnd(c2 , M1′ , a′1 , v1′ )) association(assocN ame2 , assocEnd(c2 , M2 , a2 , v2 ), assocEnd(c3 , M2′ , a′2 , v2′ ))

ÎÇϽ н Transitivity of Associations: ÑÒaÓÔÕÑÕÖÕtyAssocs

Transformations and Software Modeling Languages

231

(a)

(b) ×ØÙÚ ÛÚ (a) An application of transitivity of associations with bi-directional navigability (b) An application of transitivity of associations with uni-directional navigability

where the association in bold is a derived association. Since each instance of C2 has an association to instances of C1 and each instance of C3 is part of instances of C2 , then each instance of C3 must be related to instances of C1 . Hence, an association can be derived between C1 and C3 . The appropriate multiplicities on this derived association are calculated using an algorithm in [1]. The algorithm presented there computes new multiplicities for a derived association between classes c and c′ based on a traversal of an existing path from c to c′ that collects and merges multiplicity information along the way. The algorithm from [1] is called as a subroutine by the transformation rule in Figure 1.

ass1 (a1 , a2 , a3 , a4 ) = a1 ×

a3

ass2 (a1 , a2 , a3 , a4 ) = a2 ×

a4

× gen agg comp assoc

gen gen agg comp assoc

agg agg agg comp assoc

comp comp agg comp assoc

assoc assoc assoc assoc assoc

×ØÙÚ ÜÚ Composing association types

232

Jon Whittle

Figure 3 shows how to derive association types for a newly inferred association. In Figure 2(a), ass1 (a1 , a′1 , a2 , a′2 ) = ass1 (assoc, assoc, comp, assoc) = assoc × comp = assoc and ass2 (a1 , a′1 , a2 , a′2 ) = assoc × assoc = assoc. Note that for some combinations of adjacent associations, only uni-directional associations can be inferred. As an example, in Figure 2(b), given the associations between C1 , C2 and C2 , C3 , an association between C1 and C3 can be inferred as shown, but this association is not navigable from C3 to C1 . Navigability from C1 to C3 is legal because each instance of C1 is part of an instance of C2 , and hence is part of an instance of C3 . In the opposite direction, however, an instance of C3 need not also be an instance of C2 and hence may not have an association to C1 . Navigability is calculated in a similar fashion to association types except that the × operator is replaced by boolean ∧: nav1 (v1 , v2 , v3 , v4 ) = v1 ∧ v3 nav2 (v1 , v2 , v3 , v4 ) = v2 ∧ v4 In Figure 2(b), nav1 (v1 , v1′ , v2 , v2′ ) = true∧f alse = f alse and nav2 (v1 , v1′ , v2 , v2′ ) = true ∧ true = true, hence the derived association (in bold) has navigability only towards C3 . The transitivity rule is similar to an example transformation given in [7] except that it generalizes the notion of transitivity to all association types. ÝÞßàáâãäåÞg æãçäèéêêëê A much simpler transformation rule is given in Figure 4. This rule introduces a new subclass, child, of parent that satisfies additional constraints Ψ . Note that Ψ need bear no relation to Φ since they are new (possibly empty) constraints that characterize the new subclass. The new subclass child inherits the attributes, operations and constraints of its parent (an alternative would be for another rule to take care of propagating the parent constraints to the child). ìëèéßåÞí îáÞêßàéåÞßê éÞâ ïêêáäåéßåoÞê Transformations on class diagrams with constraints must relate class diagram elements and constraint expressions. Constraints may express information that could otherwise have been (partially) expressed using classes and associations. Transformations that translate between these alternative viewpoints would be useful in model optimization. As an example, OCL constraints on the number of instances of a particular class could also be expressed using association multiplicities. If, in fact, both are used, it is possible either that the two are in conflict with each other or that one is subsumed by the other. In the latter case, eliminating the subsumed constraint or association will lead to generation of more efficient code since the redundancy is removed. Figure 5 gives an example transformation rule for relating constraints and UML associations by updating an association according to the constraints. The rule is conditional, in the sense that the rule only fires if the two conditions associated with it hold. The rule shows how a conditional OCL constraint can

Transformations and Software Modeling Languages

233

class(parent, Attrs, Ops) # Associations with oclConstraint(Φ, parent, ≪ invariant ≫) =⇒ class(parent, Attrs, Ops) class(child, Attrs, Ops) # association(newAssocN ame, assocEnd(parent, {1}, gen, true), assocEnd(child, {0, 1}, assoc, f alse)) Associations with oclConstraint(Φ, parent, ≪ invariant ≫) oclConstraint(Φ, child, ≪ invariant ≫) oclConstraint(Ψ, child, ≪ invariant ≫)

ðñòó ôó Introduction of Constrained Subclasses: õö÷øodùúûüùýúlass

Classes # assoc Associations with oclConstraint(if cond th e n exp1 e lse exp2 e n d if , class, st) Constraints =⇒ Classes # assoc′ Associations with Constraints if cond holds in class and exp can be eliminated by replacing assoc with assoc′

ðñòó þó Inferring associations from constraints: inv2assoc

be eliminated by updating the appropriate association. The idea is that if the condition cond holds in the class which owns the constraint, then exp1 must be true, and, in some cases, the truth of exp1 can be used to modify the association assoc into assoc′ . In the form of the rule given here, the rule only fires if the conditional constraint can be completely rewritten as an association assoc′ . In general, however, only part of a constraint may be eliminated. As a concrete example of a rule application, in Figure 6, each instance of class C1 can be related to either zero or two instances of C2 . Suppose that there is an additional OCL constraint on class C1 : ÿ  # C1 ñv: if Cond  itsElements->size=2 
 itsElements->size=0 ñ

If it can be shown that Cond holds as an invariant in C1 (e.g., if it is satisfied by some other constraint of C1 ), then it can be deduced that each instance

234

Jon Whittle

C1

C2

itsElements 1

0,2

 & Updating Multiplicities according to Constraints of C1 must associate with exactly two instances of C2 and so, the multiplicity of itsElements can be updated to read 2 rather than 0, 2. Similarly, there is another transformation rule that applies in the case that cond does not hold. In this case, the multiplicity could be updated to read 0. Note, however, that the latter case relies on the closed world assumption — i.e., failure to show cond is an assumption that cond is false. Clearly, relating constraints to model elements requires some non-trivial inferences in general. In particular, in this example, it needs to be shown that cond holds in class and more generally, it may be useful to make non-trivial inferences about how exp1 relates to the association being updated. The level of sophistication required depends on the application. For a model optimization tool, the approach followed in optimizing compilers of making many simple inferences but not attempting more complex ones will work well. For some applications, however, more complex inferences may be required. Further work will investigate the use of “off-the-shelf” decision procedures for fragments of first-order logic, such as the Stanford Validity Checker [4], which could be useful for dealing with a range of complex subproblems expressed in OCL. Inferring New Generalizations Previously, it was shown how new associations (including generalizations) can be inferred by composing existing associations. Another way of deriving new generalizations is to compare the constraints, associations, attributes and operations of two existing classes (see Figure 7). Given classes parent and child, if it can be shown that all the constraints of parent hold in child and similarly, for the associations, operations and attributes of parent, then a new generalization association can be inferred from child to parent. In Figure 7, constraints is an operation that, for a given set of constraints (indicated by its argument), returns the subset of those constraints that apply to the class to which the operation is attached. Similarly for the operation associations. Comparison of constraints and associations is syntactical comparison of sets. Hence, the rule is rather weak in the sense that a constraint of parent may actually hold in child but may not be in the same syntactical form. In this case, for the rule to apply, the constraint must first be transformed into the same form. In general, this may involve non-trivial reasoning. Three other transformation rules will be mentioned because they will be used as part of the example in the following section.   , h  tAttr and inheritp are transformations that propagate constraints, attributes and operations, respectively, from a parent class to its children classes. They are simple transformations that impose the class diagram restrictions that a child

Transformations and Software Modeling Languages

235

class(parent, Attrs1 , Ops1 ) class(child, Attrs2 , Ops2 ) # Associations with Constraints =⇒ class(parent, Attrs1 , Ops1 ) class(child, Attrs2 , Ops2 ) # association(newAssocN ame, assocEnd(parent, {1}, gen), assocEnd(child, {0, 1}, assoc)) Associations with Constraints if parent.constraints(Constraints) ⊆ child.constraints(Constraints) and parent.associations(Associations) ⊆ child.associations(Associations) and Attrs1 ⊆ Attrs2 and Ops1 ⊆ Ops2

 + Inferring generalizations: G class must have (at least) the same constraints, attributes and operations as its parent.

3

Checking Model Refactorings

Refactoring is the process of restructuring an existing software artifact whilst maintaining its behavior. Refactoring has usually been considered only at the code level, but, in fact, refactoring is just as important during the design phase. Early design work typically involves iterative updates of the design at hand and restructurings are often a necessary prerequisite for these updates to take place. The main problem with refactorings is that it is easy to introduce design bugs. This section shows how transformations can be used to check that a modified design is a refactoring of an existing one, and hence show that no unforeseen errors have been introduced. A technique will be presented for automatically checking that two UML class diagrams are refactorings of each other. The technique is illustrated using the example class diagrams of Figures 9 and 10 and the transformations from the preceding section.

1 !%"$k'g P()$"*,(" A procedure for checking if two class diagrams D1 and D2 are refactorings of each other is now presented. This procedure is based on -./ 012/34, i.e., looking for differences between D1 and D2 and applying transformation rules so as to eliminate them. Some transformation rules (e.g., 325672 and 38 2Attr ) can be applied exhaustively to a class diagram as they do not involve

236

Jon Whittle

choice points that would lead to a large search space. Rules such as 9:;?@ first order logic proof systems in that, when applied to a single class diagram, they require a “eureka step” to instantiate an unbound variable. Difference matching provides the means to avoid these eureka steps. There are three main definitions that form the checking procedure: the definition of a mapping, φ , to map the elements of D1 into those of D2 , the definition of difference matching to translate φ(D1 ) into D2 and the definition of strategies for automating the rule applications involved in difference matching. Defining strategies involves the development of heuristics to reduce the search space. This is not dealt with in this paper.

A=B>lass, however, are akin to the cut rule in

Mapping Model Elements During a restructuring operation, the names of model elements may be changed. Since this should not effect the validity of the refactoring, however, the model element names (i.e., the association, class, attribute and operation names) of D1 are first mapped into those of D2 . For the example presented in this paper, it is assumed that there have been no renamings and so the mapping, φ, is just the identity mapping. More generally, however, φ could be explicitly given by the user by specifying relationships between model elements using UML’s ≪ trace ≫ stereotype. The ≪ trace ≫ stereotype denotes a historical connection between two model elements that represent the same concept at different levels of meaning. Hence, a ≪ trace ≫ stereotype could be used to connect concepts that have been renamed. The construction of φ could also be (partially) automated by a tool that keeps track of renaming of model elements and inserts the appropriate ≪ trace ≫ relationships. Difference Matching A distinction shall be made between transformation rules that can be applied exhaustively without fear of search space explosion (normal rules) and those rules whose application must be controlled through the use of heuristics (no:@:Class from Section 2.2. In order for this rule to apply, the variable child on the RHS of the rule must be instantiated with the name of a new subclass and Ψ must be instantiated with a set of constraints which hold over this new subclass. Clearly, exhaustive application of this rule introduces an infinite search space. Difference matching can be used, however, to choose the instantiations for child and Ψ , by comparing the source and target class diagrams and introducing new child subclasses to make the source and target match. Another rule for which difference matching is required is transitivityAssocs. Exhaustive application of this rule does not result in an infinite search space but does introduce up to n2 + n new associations for a class diagram with n classes. This is because, by definition of a class diagram, each class has at least

Transformations and Software Modeling Languages

237

Input. Class diagrams D1 and D2 • Apply all normal rules to φ(D1 ) and D2 • Match the class structure of φ(D1 ) and D2 : for each class c ∈ φ(D1 )\ D2 find a set of rules R that introduces c into D2 (similarly, for c ∈ D2 \ φ(D1 )) Apply the rules in R to D2 Apply all normal rules exhaustively to D2 • Match the associations in φ(D1 ) and D2 : find and apply R as above and apply all normal rules exhaustively • Match the constraints in φ(D1 ) and D2 : find and apply R as above and apply all normal rules exhaustively • rep eat

GHIJ 8. Difference matching class diagrams one association to some other class, c, and hence, by transitivity, there is an association to all classes that can be reached from c. For large class diagrams, the number of derived associations can become unmanageable and so difference matching is used to only introduce new associations as necessary. An outline of difference matching is given in Figure 8. Matching classes amounts to transforming the source class into a new class with the same attributes, operations and constraints as the target class. Matching associations amounts to transforming the source association into a new one with the same association end class names, multiplicities, navigabilities and association types as the target association. Note that R may contain both normal and non-normal rules, but after application of the rules in R, all normal rules are applied (which can be done efficiently) to propagate as much information as possible given the new model elements that have been introduced. For example, if a new subclass has been introduced, normal rules will be applied to make the subclass inherit attributes and operations from its parent. Clearly, the procedure in Figure 8 requires a judicious control of applications of the rules in R. The optimal control in the case of the refactoring application is the subject of current research and in the example which is about to be presented, the key choice points were decided manually. However, the split of rules into normal and non-normal rules already provides a good amount of control. Normal rules can be applied without user interaction. It is sometimes necessary, however, to impose an ordering on multiple applications of the same normal rule. As an example, the inheritAttr rule must be applied in the order of the inheritance graph — i.e., the top-level parent class is first chosen to be the root of this graph and the child is its first subclass, so that the first application of the rule propagates attributes from the root parent to its first child. Subsequent

238

Jon Whittle

instantiations of parent and child are chosen by following a depth-first search over the inheritance structure. This ordering ensures that all attributes are included in all appropriate subclasses.

KLM NOPQRST An example of checking refactorings will now be presented. The example comes from design documentation for a research prototype under development at NASA Ames Research Center for generating code for avionics applications. The design subset considered in this paper is part of a domain model for matrix factorizations. Matrix factorizations are important for avoiding round-off errors in geometric state estimation algorithms (i.e., algorithms that estimate the state – position, velocity, etc. – of a vehicle given noisy sensor measurements). Various standard factorization tricks can be used to ensure a numerically stable implementation of a state estimation algorithm. Two examples are decomposition of a matrix into cholesky factors or rank one factors. A cholesky factor of a symmetric nonnegative definite (SND) matrix M is a matrix C such that CC T = M , where C is triangular. A rank one factor is a cholesky factor of the rank one modified matrix M + vv T where v is a vector. Cholesky factors only exist for SND matrices and rank one factors only exist for symmetric positive definite (SPD) matrices. These restrictions are captured by constraints Φ1 and Φ2 in Figure 11. Figure 9 (along with constraints in Figure 11) shows the initial attempt at a domain model for matrix factorizations. As part of a refinement, it was decided that Figure 10 (constraints in Figure 12) would serve as a better model for the domain. Additional matrix classes have been added and given appropriate OCL constraints. The addition of classes for SND and SNP matrices allows Φ1 and Φ2 to be represented directly as multiplicity constraints on the relevant associations and so Φ1 and Φ2 do not apply to Figure 10 (note, however, that Φ3 does still apply). The other main point of interest is that a new subclass TriangularMatrix has been introduced. Since cholesky factors are triangular, CholeskyFactor has been subclassed to TriangularMatrix in Figure 10. Figures 9 and 10 represent the same information but are structurally different. This section will show how to use transformations to show that Figure 10 is a refactoring of Figure 9, or equivalently to transform Figure 9 into Figure 10. Renaming has not taken place in this example, so the mapping φ is the identity. Difference matching proceeds as follows.

UVTR I: Match Class Structures

After applying all normal rules (inheritAttr, inheritOp and inheritConstr) to both class diagrams under consideration (which makes explicit all the attributes and constraints in the diagrams), according to the difference matching procedure, the first step should be to match the class structures of the two class diagrams. By applying WXYZod[\]^[_\lass repeatedly, each of the matrix subclasses from Figure 10 that do not appear

Transformations and Software Modeling Languages

239

in Figure 9 can be introduced into Figure 9 along with their appropriate constraints. Normal rules can then be applied so that each of these new subclasses in Figure 9 inherit the attributes, operations and constraints from class Matrix.

`abc II: Match Associations (1)

The new subclasses, SymmetricDefiniteNonNegMatrix (SND) and SymmetricDefinitePositiveMatrix (SPD), introduced into Figure 9 in Step I do not have the same associations as the corresponding classes in Figure 10. Since the subclasses were introduced by the introduceSubclass rule, they currently have only a single association — a generalization from themselves to Matrix. Associations belonging to Matrix can be introduced, however, using transitivityAssocs to propagate the choleskyFactors and rankOneFactors associations resulting in the model fragment in Figure 13. Note that the multiplicities in Figures 10 and 13 do not quite match. However, since inheritConstr was applied exhaustively in Step I, SND and SPD both have the constraints Φ1 and Φ2 . Using the rule defgahhij, Φ1 and Φ2 can be replaced by updating the multiplicities on these associations. This results in the multiplicities at the CholeskyFactor end of SND becoming 2 rather than 0, 2, and similarly at the RankOneFactor end of SPD. On the other hand, the closed world assumption (see section 2.2) allows for the removal of the choleskyFactors association from SPD and the rankOneFactors association from SND (since they are uni-directional associations with a zero multiplicity at their navigable end). In a similar way, the choleskyFactors and rankOneFactors associations and constraints Φ1 and Φ2 can be propagated to all other subclasses of Matrix. In each of these cases, both associations are eliminated. Step III: Match Associations (2) The final step is to introduce the inheritance link from CholeskyFactor to TriangularMatrix in the transformed version of Figure 9. This can be done using the rule deklmGen, since the matrices have the same operations and attributes, all constraints of TriangularMatrix hold in CholeskyFactor, and all associations of TriangularMatrix are also associations of CholeskyFactor. The transformed version of 9 and 10 now look the same, and hence it has been shown that the two matrix models are refactorings of each other.

4

Conclusions and Further Work

This paper has presented a number of concrete examples of transformations over the Unified Modeling Language. This is the first paper (of which the author is aware) that has considered how to automate such transformations and has done so in the context of checking that two class diagrams (with constraints) are refactorings of each other. Although full automation is still the subject of research, a semi-automated procedure has been presented, and demonstrated on a real example. The notion of correctness of UML transformations used in this research is based on that given in [6] but it has not been shown here that each

240

Jon Whittle

Matrix -definite : boolean -elementary : boolean -nonnegative : boolean -positive : boolean -symmetric : boolean -triangular : boolean

1

Matrix -definite : boolean -elementary : boolean -nonnegative : boolean -positive : boolean -symmetric : boolean -triangular : boolean

1 choleskyFactors 0,2

SymmetricMatrix

TriangularMatrix

SymmetricElementaryMatrix

CholeskyFactor

CholeskyFactor 2 +choleskyFactors SymmetricDefiniteMatrix

1

SymmetricDefiniteNonNegMatrix

rankOneFactors RankOneFactor

RankOneFactor

Vector 1

0,2

1

1

2

SymmetricDefinitePositiveMatrix

1

+rankOneFactors

Vector

1

nopq rq

Matrix Domain Model Before Refactoring

nopq 10. Matrix Domain Model

Af-

ter Refactoring

Φ3 as before Φ4 context TriangularMatrix inv: triangular=true Φ5 context SymmetricMatrix inv: symmetric=true Φ1 context Matrix inv: if symmetric=true and nonnegative=true and definite=true then choleskyFactors->size=2 else choleskyFactors->size=0 endif Φ2 context Matrix inv: if symmetric=true and positive=true and definite=true then rankOneFactors->size=2 else choleskyFactors->size=0 endif Φ3 context CholeskyFactor inv: triangular=true

Fig. 11. Constraints for Figure 9

Φ6 context SymmetricDefiniteMatrix inv: symmetric=true and definite=true Φ7 context SymmetricElementaryMatrix inv: symmetric=true and elementary=true Φ8 context SymmetricDefiniteNonNegMatrix inv: symmetric=true and definite=true and nonnegative=true Φ9 context SymmetricDefinitePositiveMatrix inv: symmetric=true and definite=true and positive=true

Fig. 12. Constraints for Figure 10

Transformations and Software Modeling Languages

241

CholeskyFactor 0,2 choleskyFactors

1 SymmetricDefiniteNonNegMatrix RankOneFactor

0,2

SymmetricDefinitePositiveMatrix

rankOneFactors 1

stuv wxv Partially refactored matrix model individual transformation is correct in this sense. Rather, the focus is on moving towards automation of the application of transformations for a suitable domain. Other authors are also considering the notion of transformation correctness (e.g., [7]) and it is likely that their techniques will be useful in this instance.

References [1] J. Alem¨ an, A. Toval, and J. Hoyos. Rigorously transforming UML class diagrams. In Proceedings of the V Workshop MENHIR (Models, Environments and Tools for Requirements Engineering), Universidad de Granada, Spain, 2000. 227, 228, 231 [2] Workshop on Automating Object Oriented Software Development Methods, June 2001. http://trese.cs.utwente.nl/ecoopOl-aoom/. 227 [3] J. Ara¨ ujo, R. France, A. Toval, and J. Whittle. Workshop on Integration and Transformation of UML Models, June 2002. http://www-ctp.di.fct.unl.pt/ ja/witum102.htm. 227 [4] C. Barrett, D. Dill, and J. Levitt. Validity checking for combinations of theories with equality. In Proceedings of FMCAD’96, November 1996. 234 [5] M. Clavel, F. Dur¨ an, S. Eker, P. Lincoln, N. Marti-Oliet, J. Meseguer, and J. F. Quesada. Maude: Specification and programming in rewriting logic. Theoretical Computer Science, 2001. To appear. 228 [6] A. Evans. Reasoning with UML class diagrams. In Workshop on Industrial Strength Formal Methods (WIFT98). IEEE Press, 1998. 228, 239 [7] R. France. A problem-oriented analysis of basic UML static requirements modeling concepts. ACM SIGPLAN Notices, 34(10):57-69, 1999. 232, 241 [8] M. Gogolla and M. Richters. Equivalence rules for UML class diagrams. In J. Bezivin and P.-A. Muller, editors, The Unified Modeling Language, UML’98 - Beyond the Notation. First International Workshop, Mulhouse, France, June 1998, pages 87-96, 1998. 229 [9] K. Lano and A. Evans. Rigorous development in UML. In Fundamental Approaches to Software Engineering, FASE’99. Springer-Verlag, 1999. 227, 228, 230

242

Jon Whittle

[10] Unified Modeling Language specification version 1.4, September 2001. Available from The Object Management Group (http://www.omg.org). 227, 228, 229 [11] A. Toval and J. Alem¨ an. Formally modeling UML and its evolution: a holistic approach. In S. Smith and C. Talcott, editors, Formal Methods for Open Objectbased Distributed Systems IV, pages 183-206, 2000. 228, 230 [12] J. Whittle and J. Schumann. Generating Statechart Designs From Scenarios. In Proceedings of International Conference on Software Engineering (ICSE 2000), pages 314-323, Limerick, Ireland, June 2000. 227

A Relational Approach to Defining Transformations in a Metamodel David Akehurst and Stuart Kent Computing Laboratory, University of Kent, Canterbury, UK {dha,sjhk}@ukc.ac.uk

Abstract. Metamodelling is becoming a standard way of defining languages such as the UML. A language definition distinguishes between concrete syntax, abstract syntax and semantics domain. It is possible to define all three using a metamodelling approach, but it is less clear how to define the transformations between them. This paper proposes an approach which uses metamodelling patterns that capture the essence of mathematical relations. It shows how these patterns can be used to define both the relationship between concrete syntax and abstract syntax, and between abstract syntax and semantics domain, for a fragment of UML. A goal of the approach is to provide a complete specification of a language from which intelligent tools can be generated. The extent to which the approach meets this goal is discussed in the paper.

1

Introduction

In this paper we use the term ‘metamodel’ to mean the rendering of a language definition as an object model. Metamodelling is perhaps best know in its application to the UML where a subset of UML is used to define (the abstract syntax of) itself [12] – hence the use of ‘meta’. Recently, it has been demonstrated that metamodelling can be used to define concrete syntax and semantics, as well as abstract syntax [5][7][1][4][14]. This involves defining a model of concrete syntax and a model of the semantics domain, in addition to a model of abstract syntax, and then modelling, somehow, the transformation relationship between these three components. So far, this has been done in a rather ad-hoc way, using associations that directly connect elements in one component with elements in another, and then writing constraints on one or other side of the association. This paper takes a more systematic approach that has the following two advantages: (a) It locates all aspects of the relationship in a separate part of the metamodel, thereby achieving a better separation of concerns and avoiding clutter in the metamodel for the components being mapped. (b) A relationship model need not be biased towards one or other direction in the relationship. This facilitates the construction of bidirectional mapping tools.

J.-M. Jézéquel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 243-258, 2002.  Springer-Verlag Berlin Heidelberg 2002

244

David Akehurst and Stuart Kent

With regard to (b), we are particularly interested in automatically generating tools to support modelling with a language from the metamodel of that language. We give two examples, both of which require bidirectional mappings. The first example is a model editor, where a model is input and viewed through one or more concrete syntaxes (e.g. a textual and diagrammatic syntax), and where the (abstract syntax of the) model can be directly manipulated, e.g. through property panes in a GUI. For such a tool, it must be possible to change the model using one medium (e.g. property panes) and generate or update views of the model in other mediums (e.g. diagrams). Here, bidirectional mappings between concrete and abstract syntax (AS and CS) are required, so changes in one can easily be propagated to the other. The second example would be a tool that supports the exploration of a model by allowing one to build examples and counter-examples, that could, for example, be shown to domain experts to validate the model. These examples could be generated from a model, or constructed directly by hand, which requires the mapping from model to example to be precisely specified. There is also the possibility of checking given examples against a model and (partially) generating the model from examples, requiring the mapping to be bidirectional. Our approach is based on a very simple idea: take the mathematical model of relations, and encode it as an object model. This leads to a particular style or pattern of modelling, which, amongst other benefits, can guide the metamodeller in what they need to consider when defining a mapping. The paper is structured as follows. Section 2 gives the metamodel for the components to be related – concrete syntax, abstract syntax and semantics domain – for a fragment of UML. Section 3 describes the general approach to expressing transformation relationships, by adopting a modelling style inspired by mathematical relations. Section 4 shows the application of the approach to defining the relationships between concrete and abstract syntax, and between abstract syntax and semantics domain. Finally, Section 5 points to ongoing and future work, including the use of a package template mechanism, which can be automated, to encode the modelling styles described here, the development of specialised notation for describing such mappings, the generation of mapping tools from the definitions and the application of the techniques to modelling relationships or transformations in general.

2

Metamodels for AS, CS and Semantics Domain

Metamodels in this paper are expressed using a subset of UML comprising class diagrams and OCL for writing constraints. This subset corresponds closely with the language used by MOF [11] to define metamodels, and is similar to that implemented (and formalised) by the USE tool [15]. In this section we define the metamodels for three components of the language fragment, between which we will then model relationships. The language fragment contains packages, classes and associations, which map down onto a semantics domain of snapshots, objects and links. A simple model of generalisation between classes is included.

A Relational Approach to Defining Transformations in a Metamodel

2.1

245

Abstract Syntax

The abstract syntax is given by Fig. 1. A package may contain classes, associations and other packages. An association contains two association ends (we consider binary associations only). The diagram would be accompanied by a series of OCL constraints which we’ll summarise here for brevity: – A package may not be contained in itself (not a member of allNested). – upper >= lower for association ends. – A class can not be a direct or indirect parent of itself (in allParent). – The names of association ends of which the same class is the source must be unique. – The names of classes in a package must be unique. – The names of associations in a package must be unique. – The names of packages in a package must be unique. – For an association, associationEnd.otherEnd results in the same set. – For an associationEnd, source = otherEnd.target and target = otherEnd.source. – For an association, the package that minimally contains the source and target of the association ends is the package that contains the association. The last two constraints avoid situations, for example, where a package A contains a package B which contains classes X and Y, and also contains an association between X and Y. In these situations it would make more sense for the association to be contained in B rather than A. owner

parent * source 1 otherEnd

package

Class * class

name : String

* *

1

Association End name : String upper : Int lower : Int

sourceOf

allParent

0..1

*

Package

1

owner

name : String 1 owner 1 *

target

allNested

* targetOf

Association * 1 name : String association

owner

2 associationEnd

Fig. 1. Abstract Syntax

0..1 owner

snapshot * source 1 otherEnd *

1

Link End label : String

sourceOf

Object

*

id : String class : String 1

owner

Snapshot

id : String 1 package : String

object

1 owner

target

targetOf * 2

owner

linkEnd

Link

1 label : String

Fig. 2. Semantics Domain

* link

246

David Akehurst and Stuart Kent

2.2

Semantics Domain

The semantics domain is given by Fig. 2. Instances of packages are snapshots (configurations of objects and links) which contain objects, links and other snapshots. A link contains two linked ends. There are fewer constraints this time: – – – –

A snapshot may not be contained in itself, directly or indirectly The snapshot which minimally contains a link must be the snapshot itself. Id’s of objects in a snapshot are unique; similarly for snapshots in a snapshot. For a link, linkEnd.otherEnd results in the same set.

This time there are no constraints on labels of links or link ends, because it is quite possible, indeed desirable, for there to be more than one link end with the same label of which the same object is the source, and more than one link with the same label in the same snapshot. This is because labels here are used to identify which association end / association the link end / link is an instance of. content 0..1

owner

Diagram

1

1 owner *

0..1 container

Box

line

LineEnd

Line

* box

1 lineEnd arrowhead : String 2 hasArrow : Bool label : String owner label : String

hasTab : Bool 0..1 label : String box

lineEnd

*

Fig. 3. Concrete Syntax

2.3

Concrete Syntax

The metamodel for the concrete syntax is given by Fig. 3. This loses absolute positioning information, but retains relative positioning information: whether or not a line is connected to a box, by virtue of one of its ends being connected to a box, and whether or not a box/line is contained in another box, by virtue of it being part of a diagram that represents the content of a box. Again, we summarise the additional constraints required: – –

3

Lines are contained in the diagram that minimally contains the two ends. A box must not contain itself.

Patterns for Modelling Transformations

The main inspiration for the technique described here is mathematical relations. The technique is quite simple: adopt a pattern which models a transformation relationship as a (binary) relation (or collection of relations), and encode this as an object model. With this in mind, pairs are modelled as objects, and relations as objects that are associated with a set of pairs. Pairs in a relation may themselves be associated with

A Relational Approach to Defining Transformations in a Metamodel

247

other relations, and so on recursively. This allows relationships between structures with many levels to expressed, as required in language definition. Each of these aspects is now explained in detail. 3.1

Pairs

Pairs are encoded as objects which are associated with an object from the domain and range, respectively. If domain objects come from the class X and range objects from the class Y, one can define a class XY representing pairs of X’s and Y’s as given by Fig. 4. Directed associations ensure that X and Y require no knowledge that they are being “paired up”.1 X

1

XY

x

1

Y

y

Fig. 4. Pairs

When applying this pattern one substitutes classes for X and Y, and relabels XY and its associations as expected. If domain and range objects come from the same class (say X), then xDomain and xRange can be used as labels on the association ends, instead of x and y. Or some other appropriate naming scheme can be used instead. 3.2

Relations

A (binary) relation is then an object associated with a set of pairs. A relation has a domain and range. All domain objects associated with the pairs that constitute the relation must be selected from the domain, and all range objects from the range. This leads to the class diagram in Fig. 5. XRelY 1 relation * domain X

* range

* elements 1

XY

x

1

Y

y

Fig. 5. Relations

Again, associations are only navigable from XrelY so that X and Y remain untouched by the definition of the relation. Contrary to what might be expected at first sight, the domain and range are not the classes (e.g. X and Y) from which domain and range objects are selected, they are subsets of these classes. This is an important insight whose full explanation is deferred to Section 3.3, which considers how to model transformations between 1

This may be important in a situation where one wishes to define a mapping between models that are already populated in some repository.

248

David Akehurst and Stuart Kent

nested structures. The implication is that an association between X and Y is not sufficient for modelling a relation between X’s and Y’s because it requires the domain and range to be the classes X and Y. Fig. 5 must be accompanied by an invariant which ensures that the elements of pairs in the relation are selected from the domain and range. context XrelY inv: domain->includesAll(elements.x->asSet) and range->includesAll(elements.y->asSet)

And a further constraint is required to ensure that no two pairs in the relation refer to exactly the same domain and range elements. This avoids redundancy, and simplifies the definition of queries in the sequel. context XrelY inv: elements->forAll( e, f | (e.x = f.x and e.y = f.y) implies e = f )

It is also useful to define a number of auxiliary query operations (functions) on the class XrelY: (i)

The image is the set of elements from the range actually mapped onto, under the relation. context XrelY::image() : Set(Y) post: result = elements.y->asSet

(ii)

The inverse image is the set of elements from the domain actually mapped from, under the relation. context XrelY::inverse_image() : Set(X) post: result = elements.x->asSet

(iii)

The relation is onto, if the image is the range. context XrelY::is_onto() : Boolean post: result = ( image = range )

(iv)

The relation is total, if the inverse image is the domain. context XrelY::is_total() : Boolean post: result = ( inverse_image = domain )

(v)

The relation is functional, if and only if an element of the domain maps to at most one element in the range. context XrelY::is_functional() : Boolean post: result = elements->forAll( p,q | p.x = q.x implies p = q )

(vi)

The relation is inverse functional, if and only if an element of the range is mapped to from at most one element in the domain. context XrelY::is_inverse_functional() : Boolean post: result = elements->forAll( p,q | p.y = q.y implies p = q )

(vii)

The relation is an injection if it is both functional and inverse functional. context XrelY::is_injection() : Boolean post: result = is_functional and is_inverse_functional

(viii)

The relation is a bijection if it is both an injection, onto and total.

A Relational Approach to Defining Transformations in a Metamodel

249

context XrelY::is_bijection() : Boolean post: result = is_injection and is_onto and is_total

(ix)

Looking up an element from the domain returns the pairs in the relation which mention that element. context XrelY::domainLookup(X:x) : Set(XY) post: result = elements->select( p | p.x = x)

(x)

Looking up an element from the range returns the pairs in the relation which mention that element. context XrelY::rangeLookup(Y:y) : Set(XY) post: result = elements->select( p | p.y = y)

When applying this pattern, one substitutes for classes X and Y, relabelling things as appropriate, remembering that variables etc. used in the invariants and definitions of the queries on XrelY will also need to be relabelled. These patterns could be captured as package templates, as originally described in the Catalysis method [8], which would effectively systemise and automate the substitution process. Templates have been already been used to encode patterns like this for metamodelling [1][5]. When applying the pattern, it is usually necessary to add additional constraints stipulating the specific properties of the relation under consideration. These constraints fall into three categories: – – –

Definition of the properties of the relation – bijective, functional, total, etc. Definition of the domain and range. Relation specific constraints, with respect to the elements forming the relation content.

The first of these is the simplest to define; it is of the form: context Rel inv: f() context MyClass inv: myRel.f()

where ‘f’ is a combination of one or more of the queries – injection, bijection, total, etc. For example, one may define a class ArelB according to the pattern described here, than add the additional constraint: context ArelB inv: is_bijection()

which will ensure that all relations of the class will be bijections. If it is the case that only some relations of this class should be bijections, then one should apply the constraint directly and only to the object representing that relation. So, for example, if myRel:ArelB is declared in a class MyClass, one might write: context MyClass inv: myRel.is_bijection()

The second kind of constraint defines the domain and range of the relation. The constraints must be formed to involve the ‘domain’ and ‘range’ navigable features from the relation and are generally of the form: domain = range =

where ‘set expression’ is an OCL expression resulting in a collection of objects of the appropriate class. These definitions will nearly always appear as part of the definition

250

David Akehurst and Stuart Kent

of a class which uses a relation. For example, if MyClass also has declared myAs:Set(A) and myBs:Set(B), one could write: context MyClass inv: myRel.domain = myAs and myRel.range = myBs

to define the domain and range for myRel. The final kind of constraint is often the most complex. It is often of the form: elements->forAll( e | )

where ‘expression’ puts constraints on the elements that form the relation content. The detail of the expression is dependent on the overall application and purpose of the specified transformation. Examples of these constraints can be found in section 4. 3.3

Relating Structures

For most practical modelling, it is necessary to combine different relations. The core pattern here is the idea that an element of a relation can itself be associated with other relations. A typical example of this is the specification of a relationship between two corresponding containers, as illustrated in Fig. 6. AContainer

1 aContainer

AContainerBContainer

1

BContainer

bContainer 1 scope

1 aRelB ARelB relation 1 contents

contents * domain

* A

elements *

range *

AB a

* B

b

Fig. 6. Relating Structures

This shows the definition of a relationship between a container of A objects and a container of B objects. Given a specific pair of an AContainer and a BContainer, it is necessary to state how the contents of the AContainer map into the contents of the BContainer. This is modelled as a relation between A’s and B’s. Thus the class AContainerBContainer is associated with the class ARelB. Additional constraints can be added to determine the properties of the relationship between the contents of the containers. First, the domain of the relation should be the contents of the AContainer and the range should be the contents of the BContainer, as follows:

A Relational Approach to Defining Transformations in a Metamodel

251

context AContainerBContainer inv: aRelB.domain = aContainer.contents and aRelB.range = bContainer.contents

This illustrates why the domain and range of a relation can not be the classes from which the domain and range elements are selected, respectively. If they were we would lose the opportunity to distinguish between the case when the mapping of contents of an AContainer or BContainer covers all the contents or only some of them. As it stands which can choose to force the mapping to cover all the contents of the AContainer by making it total, and to cover all the contents of the BContainer by making it onto: context AContainerBContainer inv: aRelB.total() and aRelB.onto() AContainer Container

aContainer Container

AContainerContainer BContainerContainer 1 scope

BContainer Container

BContainer Container

1 aRelB AContainerRelBContainer relation 1

contents

contents * domain

*

AContainer

aContainer

elements * AContainerBContainer

range * bContainer

*

BContainer

1 scope

1 aRelB ARelB relation 1

contents * domain

* A

contents

elements *

range *

AB a

* B

b

Fig. 7. Transformation between Nested Structures

If the domain and range were set to be the classes A and B, respectively, then the above constraint would only be desirable if the aContainer.contents was the set of all instances of the class A; similarly for bContainer.contents. This will rarely be the case. If we did not model the relation as a class, but instead chose to represent it as an association between classes A and B, it would be impossible to express the behaviour

252

David Akehurst and Stuart Kent

captured by the invariant above. It would be possible to use an association with a corresponding association class to replace the class AB, however that would begin to interfere with classes A and B, assuming an implementation of a bidirectional association which requires each role end to require a feature (attribute or query) to be added to the class at the opposite end. Additional constraints may be added to AContainerBContainer to impose further properties on the mapping between contents. For example, to require the relation to be functional, so that every element in aContainer.contents maps to at most one element in bContainer.contents, the following constraint can be used: context AContainerBContainer inv: aRelB.isFunctional()

The pattern may be repeated to map nested structures, as illustrated by Fig. 7. 3.4

Separation of Concerns

A mapping can be made easier to understand and managed in a modelling tool, for example, by wrapping the two sides of the relationship and the relationship itself in separate packages. An example of using packages in this way is provided by Fig. 8.

4

Application of the Patterns

4.1

Abstract Syntax to Semantics Domain Semantics

AS

SD

Package

Snapshot

Package Snapshot

scope

name : String

scope

relation

id : String package : String

scope elements

Package Rel Snapshot

Class Rel Object relation

Association Rel Link

elements

Class name : String

Association name : String

relation

Object

Class Object

elements

id : String class : String

Link

Association scope Link

label : String

AssociationEnd Rel LinkEnd relation

Association End name : String upper : Int lower : Int

elements

AssociationEnd LinkEnd

Fig. 8. Semantics Relation

Link End label : String

A Relational Approach to Defining Transformations in a Metamodel

253

Fig. 8 shows the basic structure of the mapping. We have omitted the details of the abstract syntax (AS) and semantics domain (SD) packages as they are provided in Section 2. We have also omitted cardinalities on associations, where they match the patterns described in Section 3 (which is all of them), and labels on association ends where the label matches the name of the target class. We have omitted domain and range associations (see Section 3 for details). All queries introduced in Section 3 are assumed to be replicated according to the application of the pattern. So, for example, on the class ClassRelObject we have, amongst other queries: context ClassRelObject::image() : Set(Object) post: result = elements.object->asSet

What remains, is to provide the various constraints according to the guidelines set out in Section 3. First, we define the domains and ranges of the various relations. context PackageSnapshot inv: packageRelSnapshot.domain = package.package and packageRelSnapshot.range = snapshot.snapshot and classRelObject.domain = package.class and classRelObject.range = snapshot.object and associationRelLink.domain = package.association and associationRelLink.range = snapshot.link context AssociationLink inv: associationEndRelLinkEnd.domain = association.associationEnd and associationEndRelLinkEnd.range = link.linkEnd

Next, come the properties of the relations: context PackageSnapshot inv: classRelObject.is_onto() and classRelObject.is_inverse_functional() and associationRelLink.is_onto() and associationRelLink.is_inverse_functional() and packageRelSnapshot.is_injection() and packageRelSnapshot.is_onto() context AssociationLink inv: associationEndRelLinkEnd.is_bijection()

The reasoning behind these decisions runs as follows. All objects must be related to exactly one class (inverse_functional and onto), but some classes may not be represented by objects in a snapshot, and there may be many objects per class (so not total and not functional). Similarly for links of associations. On the other hand, a snapshot of a package which contains other packages may contain snapshots for the latter, but only one of each (functional). A contained snapshot must always be related to exactly one contained package (inverse_functional and onto). This reflects the observation that, at least for in this language, contained packages just allow the namespace of a package to be further partitioned, and this should be replicated in snapshots. Although there may be many links per association, each link must have exactly two link ends which correspond directly with the association ends of the association associated with the link. Thus associationEndRelLinkEnd is a bijection. Finally, we deal with the constraints specific to this metamodel. First some simple constraints which ensure names tie up correctly: context PackageSnapshot inv: package.name = snapshot.package

254

David Akehurst and Stuart Kent

context ClassObject inv: class.name = object.class context AssociationLink inv: association.name = link.label context AssociationEndLinkEnd inv: associationEnd.name = linkEnd.label and

Second, a constraint is required to ensure that cardinality of associations is preserved in snapshots. context PackageSnapshot inv: package.association.associationEnd->forAll(ae | snapshot.allObject()->select(o | classRelObject.rangeLookup(o).class = {ae.source}) ->forAll(o | let n = o.sourceOf->select(le | associationRelLink.domainLookup(ae.owner).linkEnd ->includes(le))->size in n = ae.lower))

The constraint works by taking each association end ae accessible to the package, then taking each object o accessible to the snapshot of the class at the source of ae, counting all the link ends of ae sourced on o, and checking that this falls within the upper and lower bounds declared in ae. Note the use of range and domain lookups to find pairs in a relation. This allows one to find the elements related in the domain (range) to the range (domain) element in question. Third, a constraint is required to ensure that a linkEnd is targeted on an object of a class conformant with the class at the target of the corresponding associationEnd: context PackageSnapshot inv: associationRelLink.elements->forAll(el | el.link.linkEnd->forAll(le | let classOfObject = classRelObject.rangeLookup(le.target).class in classOfObject->union(classOfObject.allParents) ->includes(el.association.associationEndRelLinkEnd ->rangeLookup(le).associationEnd.target))

4.2

Concrete to Abstract Syntax

Fig. 9 shows the basic structure of the mapping. The diagram is subject to the same conventions and omissions as Fig. 8. Again, we provide the various constraints according to the guidelines set out in Section 3. First, we define the domains and ranges of the various relations. context BoxPackage inv: boxRelPackage.domain = box.content.box->select(hasTab) and boxRelPackage.range = package.package and boxRelClass.domain = box.content.box->select(not hasTab) and boxRelClass.range = package.class and boxRelPackage.domain->union(boxRelClass.domain)= box.content.box and lineRelAssociation.domain = box.content.line and lineRelAssociation.range = package.association context LineAssociation inv: LineEndRelAssociationEnd.domain = line.lineEnd and LineEndRelAssociationEnd.range = association.associationEnd

A Relational Approach to Defining Transformations in a Metamodel

255

That is, classes are the boxes in the contained diagram that do not have tabs and packages are the ones that do (and these are the only boxes allowed); associations are the lines in the diagram. Next, come the properties of the relations. At this point we can determine the relationship between the symbols in the diagram and the defined model; for instance, do we allow partial diagrams, and/or model elements to be represented multiple times in a diagram. The following constraints define complete diagrams, with one element mapping to one symbol: context LineAssociation inv: LineEndRelAssociationEnd.is_bijection() context BoxPackage inv: boxRelPackage.is_bijection() and boxRelClass.is_bijection() and lineRelAssociation.is_bijection() and CSAS

CS

AS

Box

Package

Box Package

scope hasTab : Bool label : String

name : String scope

relation scope elements

Box Rel Package

Box Rel Class relation

Line Rel Association relation

elements

Class

Box Class Line scope

elements

Line Association

name : String

Association name : String

LineEnd Rel AssociationEnd relation

LineEnd arrowhead : String hasArrow : Bool label : String

elements

LineEnd AssociationEnd

Association End name : String upper : Int lower : Int

Fig. 9. CS-AS transformation

An alternative, allowing diagrams to be partial views, would be to weaken these properties, by making them total injections, but not onto. To enable elements to be represented multiple times on a diagram, the relations no longer be inverse functional. Associations always have two ends and so must Lines, hence the relationship between LineEnds and AssociationEnds is always a bijection.

256

David Akehurst and Stuart Kent

Finally, we deal with the constraints specific to this metamodel. First some simple constraints that ensure element names correspond to labels in boxes. The first of these also ensures that the diagram owning the box representing a top level package only contains that box and is not contained in any other box. context BoxPackage inv: box.label=package.name and package.owner=null implies (box.diagram.box={self} and box.diagram.line->isEmpty and box.diagram.container=null) context BoxClass inv: box.label = class.name context LineAssociation inv: line.label = association.name context LineEndAssociationEnd inv: lineEnd.label = associationEnd.name

Second, we must ensure that the boxes at the ends of the lines are mapped to the classes at the ends of the association represented by the line: context BoxPackage inv: lineRelAssociation.elements->forAll(el | el.line.lineEnd->forAll(le | boxRelClass.domainLookup(el.association.associationEnd ->one(ae | ae.label = le.label).target).box = le.box)))

The constraint works by running through all line-association relationships, and for each one checking that each line-end of the line in the relationship connects to the box that corresponds to the class at the target of the association end that corresponds to that line-end.

5

Conclusions

We have introduced a novel approach to defining transformation relationships between different components of a language definition rendered as a metamodel. This uses a particular style or pattern of modelling that takes its inspiration from mathematical relations. We have demonstrated the approach through the definition of a small, UML-like language. There are a number of possible developments to explore. –

–

–

Application of the approach to a more sophisticated language. Although we expect the approach will scale up, we are conscious that other patterns of combining relations will probably be required (e.g. relation composition), and are nervous about the size of the metamodel that might be required. Encoding the patterns as package templates [5][6]. This will provide one approach to taming the complexity of large definitions, not least by allowing whole chunks of metamodel to be generated simply through the substitution of template parameters (templates just provide a formal encoding of the systematic rules we have been using when applying the patterns of section 3). Development of specialised notation for describing such relationships. This would be an alternative to using templates. It is recognised that metamodelling is missing language constructs for describing relationships between models,

A Relational Approach to Defining Transformations in a Metamodel

–

–

–

257

including metamodels and their component parts. For example, an OMG RFP to add such a facility to the MOF is soon to be issued. An approach which provides some specialised syntax for the modelling patterns presented here would be a candidate solution. Application of the techniques to the OMG’s Model Driven Architecture (MDA) [13]. MDA requires transformations between different modelling languages and different models in the same language. It would be a good test of the approach to see how amenable it is to defining such relationships. Automated generation / configuration of tools. The idea here is to use a metamodel definition as direct input to a (meta)tool that can then execute and / or monitor the relationship in one or other direction, or generate a tool that can do this. A prototype (meta)tool that generates relationship management tools is described in [2]. This was used to build the diagrammatic language editor for an automaton model checker [3]. This was based on a less flexible method for modelling relationships [2]. Work is in progress to update the metatool based on the approach described in this paper. Alignment with other approaches to language definition. We are particularly keen to explore the relationship between metamodelling and graph grammars [9][10]. In particular, triple graph grammars [16] provide the basis of a rule based approach to expressing mappings that would complement well the metamodelling approach described here.

References [1] [2]

[3]

[4]

[5]

[6] [7]

[8]

2U Submitters. Submission to UML 2.0 Infrastructure RFP, available from www.2uworks.org. Akehurst D. H. Model Translation: A UML-based specification technique and active implementation technique. PhD Thesis, University of Kent, UK. December 2000. Akehurst D., Bowman H., Bryans J. and Derrick J. A Manual for a ModelChecker for Stochastic Automata. Technical Report 9-00, Computing Laboratory, University of Kent, December 2000. Alvarez J.M., Clark A., Evans A. and Sammut P. An action semantics for MML. In C. Kobryn and M. Gogolla, editors, Proceedings of The Fourth International Conference on the Unified Modeling Language (UML’2001), LNCS. Springer, 2000. Clark A., Evans A. and Kent S. Engineering modelling languages: A precise meta-modelling approach. In Proceedings of ETAPS 02 FASE Conference, LNCS. Springer, April 2002. Clark A., Evans A. and Kent S. Package Extension. Submitted to UML’02, March 2002. Clark A., Evans A., Kent S., Brodsky S., and Cook S. A feasibility study in rearchitecting UML as a family of languages using a precise OO metamodeling approach. Available from www.puml.org, September 2000. D’Souza D. and Wills A. Objects, Components and Frameworks With UML: The Catalysis Approach. Addison-Wesley, 1998.

258

David Akehurst and Stuart Kent

[9]

Ehrig H., Engels G., Kreowski H-J., and Rozenberg G., editors. Handbook Of Graph Grammars And Computing By Graph Transformation. Volume 2: Applications, Languages and Tools. World Scientific, October 1999. Fischer T., Niere J., Torunski L. and Zündorf A. Story Diagrams: A new Graph Transformation Language based on UML and Java in 6th Int. Workshop on Theory and Applications of Graph Transformation, TAGT'98 Selected Papers (Ehrig, Engels, Kreowski, Rozenberg Eds.) Springer LNCS 1764 (2000). Object Management Group. The Meta Object Facility (MOF) Version 1.3.1. OMG document number formal/2001-11-02. Object Management Group. The Unified Modeling Language Version 1.4. OMG document number formal/01-09-67. OMG Architecture Board ORMSC. Model driven architecture (MDA). OMG document number ormsc/2001-07-01, available from www.omg.org, July 2001. Reggio G. and Astesiano E. A proposal of a dynamic core for UML metamodelling with MML. Technical Report DISI-TR-01-17, DISI, Universit di Genova, Italy, 2001. Richters M. and Gogolla M. Validating UML models and OCL constraints. In A. Evans, S. Kent and B. Selic, editors, The Third International Conference on the Unified Modeling Language (UML’2000), York, UK, October 2-6. 2000, Proceedings, LNCS. Springer, 2000. Schürr A. Specification of Graph Translators with Triple Graph Grammars, in Tinhofer G. (ed.) Proc. WG'94 20th Int. Workshop on Graph-Theoretic Concepts in Computer Science, Herrsching, Germany, LNCS 903, Springer Verlag, 151-163, June 1994.

[10]

[11] [12] [13]

[14]

[15]

[16]

On Customizing the UML for Modeling Performance-Oriented Applications⋆ Sabri Pllana and Thomas Fahringer Institute for Software Science, University of Vienna Liechtensteinstraße 22, 1090 Vienna, Austria {pllana,tf}@par.univie.ac.at

Abstract. Modeling of parallel and distributed applications was a preoccupation of numerous research groups in the past. The increasing importance of applications that mix shared memory parallelism with message passing has complicated the modeling effort. Despite the fact that UML represents the de-facto standard modeling language, little work has been done to investigate whether UML can be employed to model performance-oriented parallel and distributed applications. This paper provides a critical look at the utility of UML to model shared memory and message passing applications by employing the UML extension mechanisms. The basic idea is to develop UML building blocks for the most important sequential, shared memory, and message passing constructs. These building blocks can be enriched with additional information, for instance, performance and control flow data. Subsequently, building blocks are combined to represent basically arbitrary complex applications. We will further describe how to model the mapping of applications onto process topologies.

1

Introduction

Effective performance-oriented program development requires the programmer to understand the intricate details of the programming model, the parallel/ distributed architecture, and the mapping of applications onto architectures. Numerous approaches [5, 1, 2] have been introduced to graphically model applications, and their mapping onto parallel and distributed architectures. These approaches, however, have only been moderately successful due to modeling languages that have not been based on standards, restrictions to specific program paradigms (e.g. message passing only), and limited modeling capabilities. With the appearance of the Unified Modeling Language (UML) [7], however, things have changed. UML is the de-facto standard visual modeling language which is a general purpose, broadly applicable, tool supported, industry standardized modeling language. Although UML has been extensively studied and tested in the domain of distributed computing, in particular for client server and ⋆

The work described in this paper is supported by the Austrian Science Fund as part of Aurora Project under contract SFBF1104.

J.-M. J´ ez´ equel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 259–274, 2002. c Springer-Verlag Berlin Heidelberg 2002


260

S abri Pllana and Thomas Fahringer

w eb applications, hardly any effort has been undertaken to examine its practicability and effectiveness for performance-oriented scientific applications that exploit message passing, shared memory, data parallelism, and mixed forms of parallelism (e.g. shared memory combined with message passing). Even though the majority of scientific applications have been developed based on procedural languages (Fortran and C), UML is a promising alternative to model non-object oriented parallel and distributed applications as well. In this paper, we provide a critical look at the utility of UML to model shared memory and message passing applications. We describe how to use the UML extension mechanisms to customize UML for the domain of parallel and distributed computing by using a subset of UML, namely class, activity, and collaboration diagrams. Class diagrams are employed to build the structural model of distributed and parallel architectures; activity diagrams for representing computational, communication, and synchronization operations; collaboration diagrams for describing process topologies and the mapping of applications to process topologies. We describe a set of UML building blocks that model some of the most important constructs of message passing and shared memory parallel paradigms. The building blocks have been largely motivated by the Open Multi Processing (OpenMP) [3] and the Message Passing Interface (MPI) [12] standards. Based on the pre-defined UML building blocks we can develop models for large and complex applications. We will further describe how to model the mapping of distributed/parallel applications to process topologies. Based on our work we observed that the core UML does not sufficiently support modeling of performance-oriented parallel and distributed applications. However, the UML extension mechanisms in particular stereotypes appear to be very useful to customize UML for the domain of performance-oriented distributed and parallel computing. Furthermore, we believe that the definition of a UML profile for the domain of performance oriented computing would be very helpful. The paper is organized as follows. Section 2 briefly describes the UML extension mechanism. Section 3 shows how to describe computer architectures and process topologies by using UML. In Section 4, we demonstrate how to model some of the most important sequential, distributed memory and shared memory concepts. The mapping of applications to process topologies is described in Section 5. Section 6 discusses related work. Finally, some concluding remarks are made and future work is outlined in Section 7.

2

Background

The UML defines nine diagram types, which allow to describe different aspects of a system: use case diagram, class diagram, object diagram, statechart diagram, seyzence diagram, collaboration diagram, activity diagram, component diagram, and deployment diagram. Each diagram type describes a system or parts of it from a certain point of view. For the purpose of modeling performance-oriented distributed and parallel applications we concentrate on a subset of the UML that consists of class, activity and collaboration diagrams. In this section we present

O n Customizing the UML for Modeling Performance-Oriented Applications

261

some background information that will be helpful to understand the remainder of this paper. A comprehensive discussion on UML can be found in [11]. Our approach relies on the UML extension mechanisms to customize UML for the domain of performance oriented parallel and distributed computing. The UML extension mechanisms [7] describe how to customize specific UML model elements and how to extend them with new semantics by using stereotypes, constraints, tag definitions, and tagged values. Stereotypes are used to define specialized model elements based on a core UML model element. A stereotype refers to a base class in the UML metamodel (see Fig. 1.a), which indicates the element to be stereotyped. A stereotype may introduce additional values, additional constraints, and a new graphical representation. Stereotypes are notated by the stereotype name enclosed in guillemets > or by a graphic icon. We are employing stereotypes to define modeling elements for constructs such as SEND, RECEIVE, PARALLEL, CRITICAL, etc. UML properties – in form of a list of tag-value pairs – are introduced to attach additional information to modeling elements. A tag represents the name of an arbitrary property with a given value and may appear at most once in a property list of any modeling element. It is recommended to define tags within the context of a stereotype. The notation of tags follows a specific syntax: {tag = value}, for instance, {time=10}. A constraint allows to linguistically specify new semantics for a model element by using expressions in a designated constraint language. Constraints are specified as a text string enclosed in braces { }, for instance, {WaitUntilCompleted = True}. The usage of the UML extension mechanisms is illustrated in Fig. 1. Figure 1.a depicts the definition of the modeling element action+ by stereotyping the base class ActionState. An ActionState is used to model a step in the execution of an algorithm. The compartment of the stereotype action+ named Tags specifies a list of tag definitions which includes id, type, and time. Tag id can be used to uniquely identify the modeling element action+; tag type specifies the type of action+, and tag time the time spent to complete action+. We are using

«metaclass» ActionState «stereotype» «stereotype» action+ Tags id : Integer type : String time : double a)

«action+»

SampleAction

{id=1, type=Sample, time=10}

b)

Fig. 1. Definition of stereotype action+

262

Sabri Pllana and Thomas Fahringer

action+ (see example in Fig. 1.b) to model various types of single-entry singleexit code regions, whereas tags are employed to describe performance relevant information, such as estimated or measured execution times (cf. Fig. 1.b). The set of the tag definitions is not limited to those shown in Fig. 1.a but can be arbitrarily extended to suffice a modeling objective. In the remainder of this paper, programming language constructs will be denoted with capital letters (e.g., non-blocking SEND) and UML modeling elements with small letters (e.g., nbsend ). For the sake of simplicity, in some examples the properties of a modeling element are suppressed.

3

Modeling Computer Architectures and Process Topologies

A distributed/parallel machine can be described as a set of computational nodes, such as single processor nodes (for example, PC or workstation), symmetric multiprocessing systems (SMP - consists of multiple processors that share a common memory), etc. These computational nodes are interconnected by one or several specific networks (see Fig. 2). Distributed and parallel architectures can be represented straightforwardly by a UML deployment diagram (see Section 5). Commonly in parallel processing programs are not directly mapped onto a physical architecture but first onto a virtual architecture (process topology) that can be of arbitrary size. The mapping of virtual to physical architectures is done at runtime which commonly distributes several processes of the virtual architecture onto a single physical processor in order to honor the actual size of a physical architecture. In the following section we outline how to model process topologies with UML collaboration diagrams. A process topology may be defined as a group of processes that have a predefined regular interconnection topology such as a farm, ring, 2D mesh or tree which is described in [10]. The description of a process topology assumes a virtual architecture of arbitrary size (number of processing units). The virtual ar-

0..1 Architecture

Network

0..* 0..* 1..*

1 1..* 2..* 0..*

Node

PC

Workstation

Connection

SMP

...

Fig. 2. UML class diagram of distributed and parallel architectures

O n Customizing the UML for Modeling Performance-Oriented Applications

263

chitecture can be mapped on a physical architecture lateron, e.g. for the sake of simulating the performance behavior of a program on a specific target architecture. In the remainder of this paper we will use the term processing unit for process or thread when is appropriate.

4

Modeling Distributed and Parallel Applications

In this section we describe our approach of modeling performance-oriented distributed and parallel applications by using activity diagrams. The basic idea is to specify a set of building blocks (see Fig. 3) that represent key concepts of sequential, shared memory, and message passing constructs and thus allow to model basically arbitrary large and complex applications when grouped together. The building blocks have been largely motivated by OpenMP [3] and MPI [12] standards. OpenMP is a specification for a set of compiler directives, library routines, and environment variables that is used to specify shared memory parallelism in Fortran and C/C++ programs. MPI is a library of routines that supports message passing programming in Fortran and C. For each building block we will describe how it can be captured using fragments of activity diagrams and discuss problems or open issues that emerged during our work. Because of limited space we will focus on some of the most interesting building blocks in this paper. For additional building blocks (Fig. 3) the reader may refer to [10, 9]. The majority of performance-oriented scientific applications are implemented using procedural languages. In contrast to object oriented languages, procedural programs are control flow oriented. For this reason, we have selected the UML activity diagram in order to model computational, communication, and synchronization operations of an application. We discovered several problems during our effort to model parallel and distributed applications with activity diagrams. The current UML 1.4 standard

DistributedAndParallel Application

Sequential

DistributedMemory

SharedMemory

CodeRegion

PointToPoint

ProcedureCall

CollectiveData Movement

ParallelRegion WorkSharing

Branch

CollectiveGlobal Computation

CombinedParallel WorkSharing

Loop

Barrier

Synchronization

...

...

...

Fig. 3. The overview of concepts

264

Sabri Pllana and Thomas Fahringer

describes activity diagrams as a variation of a statechart diagram. Several constructs of activity diagrams lack a precise syntax and semantics. For instance, the well-formedness rules linking forks with joins are not fully defined, nor are the concepts of dynamic invocation and deferred events, among others. For our modeling purpose, we require to associate additional information (e.g. performance and scheduling data) with activities. The UML 1.4 specification [7] recommends that tag definitions should be defined in the context of a stereotype. As a consequence, we introduced stereotypes for many building blocks in order to associate additional information to activities. The usage of stereotypes also alleviated or avoided complex representation of some parallel and distributed program patterns (e.g. BROADCAST). 4.1

Sequential Concepts

A sequential construct is used to model the unit of work that is executed by a single processing unit (process or thread). In what follows, we describe a few sequential concepts in order to outline our modeling approach. The stereotypes action+ and subactivity+ are used to model various types of single-entry single-exit code regions. The UML modeling elements ActionState (see Fig. 1.a) and SubactivityState (see Fig. 4.b.1) have been stereotyped in order to add properties that are relevant, for performance modeling. Figure 4.a illustrates how to model SEQUENTIAL code regions. The property type of the stereotype action+ indicates that the modeled code region is executed in sequential mode. In Fig. 4.b.1 we introduce the stereotype subactivity+ whose purpose in this case is to represent a PROCEDURE CALL. The property type of the stereotype subactivity+ indicates that the modeled code region is a procedure call.

«metaclass» SubctivityState «stereotype» «stereotype» subactivity+ Tags

«action+»

SampleAction

{id=1, type=Sequential, time=15}

(a) SEQUENTIAL code region

id : Integer type : String time : double 1)

{id=1, «subactivity+» SampleSubactivity type=Procedure call, time=20} 2)

(b) PROCEDURE CALL

Fig. 4. Modeling a SEQUENTIAL code region and a PROCEDURE CALL

On Customizing the UML for Modeling Performance-Oriented Applications

4.2

265

Distributed Memory Concepts

The most commonly used programming method for distributed memory architectures is dominated by the message passing model. Multiple processing units are created each of which is identified by an unique name. Processing units can employ point-to-point communication operations to send messages from a named processing unit to another. A group of processing units can use collective communication operations to perform global communication. In our modeling approach the communication event holds the information about the pattern of communication (for example point-to-point), the communication size (number of processes), and the communication domain (process group). A communication event is associated with a transition in an activity diagram. For instance, a communication event RECEIVE triggers a transition into an action state. Point-To-Point Communication (P2P) is commonly implemented by using SEND and RECEIVE operations. P2P operations can be classified into blocking and non-blocking operations. A non-blocking SEND initiates the send operation without being blocked at the sender. As soon as the send of a message is initiated, the sender can proceed with the execution of the program. For the definition of the signal event P2P we use the predefined UML stereotype signal (see Fig. 5.a.1) and its parameters (source, destination, messageSize, etc.). A non-blocking SEND is modeled by the stereotype nbsend. Figure 5.a.2 illustrates the definition of the stereotype nbsend based on the base class Transition. An example usage of nbsend is presented in Fig. 5.a.3 where a signal P2P is sent to the processing unit b:Process. A blocking RECEIVE waits until the receive buffer contains the message received which is modeled as a new stereotype denoted as brecv. Figure 5.b.1

«metaclass» Transition

«signal» P2P source : Integer destination : Integer messageSize : Integer messageID : Integer comDomain : String 1)

«stereotype» «stereotype» nbsend Tags id : Integer time : double 2)

«nbsend»

P2P

«processingunit» b : Process

3)

(a) Non-blocking SEND

«metaclass» Transition «stereotype» «stereotype» brecv Tags id : Integer time : double

«brecv»

1)

2)

P2P

«processingunit» a : Process

(b) Blocking RECEIVE

Fig. 5. Modeling non-blocking SEND and blocking RECEIVE

266

Sabri Pllana and Thomas Fahringer

presents the definition of the stereotype brecv based on the base class Transition. Figure 5.b.2 depicts the receiving of a signal P2P from the processing unit a:Process. For representing non-blocking SEND and blocking RECEIVE operations we have used the adequate UML control icons. Although it should be mentioned, that using these icons is not necessary, because non-blocking SEND and blocking RECEIVE operations can be specified on transitions. However, we prefer to employ these icons because they improve the readability of UML models. On the other hand, application developers for parallel and distributed systems extensively use blocking SEND and non-blocking RECEIVE operations, for which UML does not provide a specific notation. In order to alleviate this drawback, we propose to use the same SEND and RECEIVE control icons provided by the UML standard but with appropriate stereotypes in order to define their exact meaning. A blocking SEND is not completed until the message has been sent such that the sender can access and overwrite the send buffer without side effects. A blocking SEND is modeled by the stereotype bsend. Figure 6.a.1 illustrates the definition of the stereotype bsend based on the base class Transition. The constraint {WaitUntilCompleted=True} specifies that transition to the next state is deferred until the SEND operation is completed. An example usage of bsend is presented in Fig. 6.a.2 where a signal P2P is sent to the processing unit b:Process. Note that a blocking SEND can be modeled by using the stereotype nbsend (see Fig. 6.a.3) and a Wait state. After the SEND operation – modeled by the stereotype nbsend – is initiated, the transition to the next action state is deferred until the SEND is completed. Waiting for completion of the SEND can be modeled by the Wait state and the event when(SendCompleted). However, in order to improve the readability of the resulting UML model, we prefer to represent a blocking send by an icon as depicted in Fig. 6.a.2.

«bsend»

P2P «metaclass» Transition «stereotype» «stereotype» bsend Tags id : Integer time : double Constraints {WaitUntilCompleted =True}

«processingunit» b: Process

2)

«metaclass» Transition

«nbsend»

P2P

«processingunit» b: Process

Wait

1) when(SendCompleted) 3)

(a) Blocking SEND

«stereotype» «stereotype» nbrecv Tags id : Integer time : double Constraints

«nbrecv»

P2P

«processingunit» a: Process

{WaitUntilCompleted =False}

1)

2)

(b) Non-Blocking RECEIVE

Fig. 6. Modeling blocking SEND and non-blocking RECEIVE

On Customizing the UML for Modeling Performance-Oriented Applications

267

A non-blocking RECEIVE initiates the receive operation without waiting for completion. We introduce the stereotype nbrecv (see Fig. 6.b.1) which is defined based on base class Transition, to model non-blocking RECEIVE operations. The constraint {WaitUntilCompleted=False} indicates that the transition to the next state is not deferred until the RECEIVE operation is completed. An example usage of nbrecv is presented in Fig. 6.b.2 where a signal P2P is received from the processing unit a:Process. Collective Communication involves communication among a group of processing units to move data or to conduct global computation. In order to represent collective communication operations we encountered difficulties to model and visualize a processing unit that sends/receives several messages to/from a set of processing units. Our goal is to find a notation that improves the understanding of the model and still expresses the concept in a compact form. One possible option to model collective communication could involve a loop that includes multiple send/receive operations. This approach results in implementation dependent and rather complex models (see Fig. 7.a.1). In our opinion a better solution to model collective operations is to use stereotypes that hide

«metaclass» Transition [ELSE]

«stereotype» [MYID = ROOT] «bsend»

A(MYID)

«stereotype» gather Tags id : Integer time : double 2)

«brecv»

A(I)

I=I+1

[I < NP]

«signal» GATHER root : Integer messageSize : Integer comDomain : String comSize : Integer

«signal» BCAST root : Integer messageSize : Integer comDomain : String comSize : Integer

3)

[ELSE]

«stereotype»

«stereotype» broadcast Tags id : Integer time : double 2)

«bsend»

«gather»

A(MYID)

1)

1)

«metaclass» Transition

GATHER {id=3, time= 10}

4)

(a) Modeling GATHER

«broadcast»

BCAST

«porcessingunit» : Process

3)

(b) Modeling BROADCAST

Fig. 7. Modeling collective communication concepts

268

Sabri Pllana and Thomas Fahringer

the implementation of collective communications. For the sake of illustration, we employ the BROADCAST collective communication construct that sends a message to all processing units of a group. A new stereotype denoted as broadcast is introduced to model the BROADCAST collective communication. Figure 7.b.1 shows the definition of the event BCAST which is based on the predefined UML stereotype signal. Figure 7.b.2 presents the definition of the stereotype broadcast based on the base class Transition. An example of stereotype broadcast is depicted in Fig. 7.b.3 where a signal BCAST is sent to a group of processing units. Commonly message passing paradigms also support a GATHER collective communication construct where every processing unit involved in the GATHER operation (see Fig. 7.a.1), sends a message to a single receiver processing unit (called root). Every processing unit is identified by a unique identification (MYID). The root, for which the condition MYID=ROOT is true, sends the message A(MYID) and receives one message A(I) from every SENDER processing unit. NP is the number of processing units involved. Note that the root is also sending a message to itself. The UML model of the GATHER collective communication construct can be used to present specific implementations of a GATHER operation as shown in Fig. 7.a.1. But in many cases, it is sufficient to specify that a GATHER operation is conducted without including a detailed implementation model. For this purpose, we introduce a new stereotype named gather to model GATHER operation in a more compact form (see Fig. 7.a.2). Figure 7.a.3 shows the definition of the event GATHER. An example of stereotype gather is depicted in Fig. 7.a.4 where GATHER denotes an event whose occurrence invokes the transition, and {id=3, time=10} indicate example tag values of the stereotype gather. 4.3

Shared Memory Concepts

In the shared memory programming model processing units share a common address space which they read and write asynchronously. Various mechanisms such as locks and semaphores are used to control access to the shared memory. {ork sharing constructs are provided to divide the execution of a code region among the processing units. To illustrate our approach, in the sequel we will show how to model some of the most important shared memory constructs by using fragments of activity diagrams. Parallel Region A PARALLEL region is a code region that is executed by multiple threads in parallel. The code enclosed within the PARALLEL region is duplicated and all threads will execute it. A new stereotype named parallelregion is introduced in order to model PARALLEL regions. Figure 8.a depicts the definition of the stereotype parallelregion based on the base class SubactivityState. An example usage of this stereotype is illustrated in Fig. 8.b. The ’*’ symbol in the upper right corner of a state denotes dynamic concurrency, which means that the actions of an action state

On Customizing the UML for Modeling Performance-Oriented Applications

269

«metaclass» SubactivityState «stereotype» «stereotype» parallelregion Tags id : Integer nrThreads : Integer time : double a)

«parallelregion»

* SampleSubactivity

{id=1, nrThreads=4, time=3}

b)

Fig. 8. Modeling the PARALLEL region or the activity graph of a subactivity state may be executed more than once concurrently, for instance, by multiple threads. Wo|}~€|‚ƒ„ A work-sharing construct – must be enclosed within a parallel region – divides the execution of the enclosed code region among the members of the set of threads that encounter it. There is no implied barrier upon entry to a work-sharing construct. …ork-sharing constructs must be encountered by all threads in a set or by none at all. Successive work-sharing constructs must be encountered in the same order by all members of a set. Work-sharing constructs do not invoke new threads. The SECTIONS work-sharing construct specifies that the enclosed sections of code are to be divided among threads in the team. An example with two sections is illustrated in Fig. 9.a. The value of tag type specifies that the stereotype action+ refers to a section.

«action+»

ActionState1 {id=1, type=Section, time=5}

«action+»

«action+»

ActionState1

ActionState2

{id=2, type=Section, time=6}

«action+»

ActionState2

Wait done

/send done

/send done

«action+»

ActionState3

«action+»

ActionState3

(a) SECTIONS work-sharing

(b) In case that NOWAIT is specified

Fig. 9. Modeling SECTIONS work-sharing

270

Sabri Pllana and Thomas Fahringer

«metaclass» SubactivityState «stereotype» «stereotype» critical Tags id : Integer name : String time : double

SampleSubactivity

a)

b)

«critical»

{id=1, name=Block1, time=2}

Fig. 10. Modeling the CRITICAL construct In case that NOWAIT is specified threads that finish early may proceed to instructions following the SECTIONS work-sharing construct without synchronization at the end of the work-sharing construct. The UML model for this case is depicted in Fig. 9.b. As soon as ActionState1 or ActionState2 – each of which represent a section – is completed, a signal is produced which causes the †‡it state to be exited and a transition to ActionState3 to be triggered. Note that ActionState3 represents a set of instructions following the work-sharing construct SECTIONS. However, we consider this solution to be too complex. Moreover, it is not general, because it cannot be applied when a work-sharing construct SECTIONS is placed in a loop. It is unclear what UML mechanism could be used to tackle this problem. One solution would be to introduce a new modeling element in UML with appropriate syntax and semantics by using the so-called ’heavyweight’ extensibility mechanism as defined by the MOF specification [6]. Synchronization The shared memory synchronization construct controls how the execution of each thread proceeds relative to other threads in a team of threads. The CRITICAL construct restricts access to the enclosed code to only one thread at any given time. A thread waits at the beginning of a critical section until no other thread is executing a critical section with the same name. Figure 10.a depicts the definition of the stereotype critical based on the base class SubactivityState which is used to model the CRITICAL construct. The tag name specifies the name of the critical region. An example usage of stereotype critical is given in Fig. 10.b. The ATOMIC construct ensures that a specific memory location is updated atomically, rather than exposing it to the possibility of multiple, simultaneous writing threads. Figure 11 shows an example of modeling the atomic construct.

«action+»

SampleAction

{id=1, type=Atomic, time=1}

Fig. 11. Modeling the ATOMIC construct.

On Customizing the UML for Modeling Performance-Oriented Applications

271

The value of the tag type specifies that the stereotype action+ represents an atomic ActionState.

5

Mapping

In this section we elaborate how to map an activity diagram to a collaboration diagram in order to reflect the mapping of programs to process topologies. For this purpose we use UML swimlanes to define responsibilities of actions and subactivities. An activity diagram may be divided visually into swimlanes, each separated from neighboring swimlanes by vertical solid lines on both sides. The relative ordering of the swimlanes has no semantic significance. Each action is assigned to one swimlane. Figure 12 illustrates how a single processor multiple data (SPMD) application is mapped onto a process topology. The activity diagram that represents the program is located within the swimlane named Process (see Fig. 12.a.1) which is responsible for all activities of the program. The application associated with the swimlane Process is mapped to each processing unit of the ring process topology (see Fig. 12.a.2). Figure 12.b illustrates the mapping of a multiple instruction multiple data (MIMD) application. The swimlane Process0 processes SampleAction1, SampleAction2, and SampleAction5. Swimlanes Process1 and Process2 are, respectively,

Process0

Process1

Process2

«action+»

SampleAction1

Process

«action+»

SampleAction1

«action+»

«action+»

«action+»

SampleAction2

SampleAction3

SampleAction4

«action+»

SampleAction2

[Condition]

«nbsend»

P2P

«action+»

SampleAction5 «brecv»

P2P

«action+»

SampleAction3

1) «processingunit» p0 : Process

1)

«processingunit» p1 : Process

2)

(a) SPMD based mapping

«processingunit» p2 : Process

«processingunit» : Process0

«processingunit» : Process1

«processingunit» : Process2

2)

(b) MIMD based mapping

Fig. 12. Mapping for SPMD and MIMD applications

272

Sabri Pllana and Thomas Fahringer

responsible for SampleAction3 and SampleAction4 (see Fig. 12.b.1). The mapping of swimlanes to a ring process topology is depicted in Fig. 12.b.2. The mapping of process topologies to the physical topology of a parallel and distributed computer architecture is straightforward. It can be accomplished by using the UML deployment diagram to represent the physical topology of the computer architecture. Deployment diagrams visualize the configuration of physical processing elements and the software components that execute on the processing elements [7]. The nodes in a deployment diagram represent processing resources and are are visualized as cubes. Connections between the nodes are shown as arcs joining the nodes. A unit of a software in source, binary, or executable form is represented by a component. A component is denoted as a rectangle with two small rectangles protruding from its side. Figure 13 shows three nodes interconnected by a network. The component that resides at a node is displayed within a node. The component is used to represent the process and its associated form (source, binary, or executable) mapped to the node. In this example the network is represented by a node. This kind of notation is used when more than two computer nodes are connected by a network.

6

Related Work

In this section we provide an overview of related work, focusing on application representation issues for performance-oriented parallel and distributed applications. The POEMS [1] project introduced a graphical representation which captures the parallel structure, communication, synchronization, and sequential behavior of the application. No standards are used to model parallel applications and we have not found any document that describes a graphical representation of process topologies or computer architectures. The PlusPyr project [2] introduced a parameterized task graph which is a representation of some commonly used directed acyclic graphs. This representation is automatically generated based on an existing annotated sequential program to support program parallelization for the message passing paradigm.

Node1

Node2

p0:Process

Node3

p1:Process

p2:Process

«network»

Fig. 13. Mapping of a process topology to a physical topology by the UML deployment diagram

On Customizing the UML for Modeling Performance-Oriented Applications

273

In contrast, our representation does not assume the existence of a code and goes beyond message passing applications. Again, there is no support for a graphical representation of process topologies. In [8] is presented an automatic transformation of UML models annotated with performance information into layered queuing network (LQN) performance descriptions. Their method has been validated for client server applications, whereas our research targets mostly performance-oriented scientific applications that exploit message passing, shared memory, data parallelism, and mixed forms of parallelism.

7

Conclusion

In this paper we have used the UML extension mechanisms to customize UML for the domain of performance oriented computing. We have presented a set of UML building blocks that model some of the most important concepts of message passing and shared memory parallel paradigms. A flexible mechanism has been described for mapping application models onto process topologies. For space reasons we have not presented all building blocks. Additional building blocks are presented in [10, 9]. We conclude that UML provides a rich set of modeling concepts, notations, and mechanisms to substantially alleviate the understanding, documentation, and visualization of the structure and dynamic behavior of distributed and parallel applications including the mapping of applications onto multiprocessor architectures. UML is a widely used standard and, therefore, offers a substantial advantage compared to approaches that use ad-hoc or self-defined graphical representations. Application developers that rely on procedural languages are inherently focused on the control flow of a program which is very well supported by UML activity diagrams. Moreover, mapping of applications onto process topologies can be easily expressed through UML collaboration diagrams. We determined that by using the core UML, a substantial number of important shared memory and message passing concepts can not be modeled at all or results in complex diagrams. Combining several UML modeling elements with a complex control flow can easily disconcert and conceal the essence of a higher level concept to be represented. For this reason we use a rather large number of stereotypes to describe individual but important concepts of parallel and distributed programming paradigms. Stereotypes enable the definition of higher level concepts (e.g. parallel or critical code regions) with simple notations. Tags can be used to associate arbitrary information. However, it remains an open issue how to describe the parallel SECTION work sharing construct under UML which is a key concept in OpenMP (industry standard for shared memory programming). For this specific concept we tend to propose a new modeling element by incorporating the so-called ’heavyweight’ UML extensibility mechanism as defined by the MOF specification. In summary, we observe that the core UML does not sufficiently support modeling of performance-oriented parallel and distributed applications. There-

274

Sabri Pllana and Thomas Fahringer

fore, we believe that the definition of a UML profile for the domain of performance oriented computing is very much desirable and can avoid development of various UML extensions for this domain used by different groups. Currently, we are in the progress to develop a performance estimation tool that uses UML to model parallel and distributed applications [10]. We are building a simulator that determines the performance behavior for UML models enriched with performance information for a range of cluster architectures [4]. The objective is to provide the user with performance information at an early development stage of an application.

References [1] V. Adve, R. Bagrodia, J. Browne, E. Deelman, A. Dube, E. Houstis, J. Rice, R. Sakellariou, D. Sundaram-Stukel, P. Teller, and M. Vernon. POEMS: Endto-End Performance Design of Large Parallel Adaptive Computational Systems. IEEE Transactions on Software Engineering, 26:1027–1048, November 2000. 259, 272 [2] M. Cosnard and M. Loi. Automatic task graph generation techniques. In Hesham El-Rewini and Bruce D. Shriver, editors, Proceedings of the 28th Annual Hawaii International Conference on System Sciences. Volume 2: Software Technology, pages 113–122, Los Alamitos, CA, USA, January 1995. IEEE Computer Society Press. 259, 272 [3] L Dagum and R Menon. OpenMP: An industry-standard API for shared-memory programming. IEEE Computational Science and Engineering, 5(1):46–55, January/March 1998. 260, 263 [4] T. Fahringer and S. Pllana. Performance Prophet, Institute for Software Science, University of Vienna, 2002. http://www.par.univie.ac.at/project/prophet. 274 [5] P. Kacsuk, G. D’ozsa, and T. Fadgyas. Designing Parallel Programs by the Graphical Language GRAPNEL. Microprocessing and Microprogramming, 41:625–643, 1996. 259 [6] OMG. Meta Object Facility (MOF) Specification. http://www.omg.org, November 2001. 270 [7] OMG. Unified Modeling Language Specification. http://www.omg.org, September 2001. 259, 261, 264, 272 [8] D. Petriu and H. Shen. Applying the UML Performance Profile: Graph Grammarbased Derivation of LQN Models from UML Specifications. In Performance TOOLS 2002, LNCS 2324, Springer-Verlag, London, UK, April 2002. 273 [9] S. Pllana and T. Fahringer. Modeling Parallel Applications with UML. In 15th International Conference on Parallel and Distributed Computing Systems (PDCS 2002), The Galt House, Louisville, KY USA, September 19 - 21 2002. 263, 273 [10] S. Pllana and T. Fahringer. UML Based Modeling of Performance Oriented Parallel and Distributed Applications. In Proceedings of the 2002 Winter Simulation Conference, E. Y¨ ucesan, C.-H. Chen, J. L. Snowdon, and J. M. Charnes, eds., San Diego, California, USA, December 8-11 2002. 262, 263, 273, 274 [11] J. Rumbaugh, I. Jacobson, and G. Booch. The Unified Modeling Language User Guide. Addison-Wesley, 1999. 261 [12] M. Snir, S. W. Otto, S. Huss-Lederman, D. W. Walker, and J. Dongarra. MPI: the complete reference. MIT Press, Cambridge, MA, USA, 1996. 260, 263

Modelling QoS: Towards a UML Profile Jan Øyvind Aagedal1 and Earl F. Ecklund, Jr.2 1

SINTEF Telecom and Informatics P.O.Box 124, Blindern, N-0314 Oslo, Norway [email protected] 2 Department of Informatics, University of Oslo P.O. Box 1080 Blindern, N-0314 Oslo, Norway [email protected]

Abstract. In this paper, we present a conceptual object model for specifying Quality of Service (QoS) that forms a basis for a UML profile for QoS. The conceptual model is based on CQML, a lexical language for QoS specification. A QoS characteristic represents some aspect of the QoS of a system, service or resource that can be identified and quantified. A QoS statement expresses some QoS by constraining values of QoS characteristics. A QoS relation specifies the mutual obligation of an object and its environment with respect to QoS. These concepts are related to the UML meta-model in order to define a UML profile for QoS. An example from a Lecture on Demand (LoD) case study depicts how these concepts can be used during enterprise modelling and system design.

1

Introduction

The development of software that requires guarantees of Quality of Service (QoS) is an emerging area of object-oriented software engineering, due to the confluent current interest in QoS from networking, multimedia, distributed systems, and real-time systems perspectives. Quality of Service generally covers system performance, as opposed to system functionality. QoS requirements specify not what the system does, but how the system satisfies its clients while doing what it does. Support to manage QoS is emerging in infrastructure components (e.g., networks, operating systems), but apart from real-time methodologies that address issues of timeliness, most software development methodologies focus on system operation, ignoring system performance. However, QoS is crucial for instance in multimedia applications, and methodological support for QoS is needed when developing applications in this domain. It is important to note that it must be possible to associate multiple models of QoS with the same functionality, for example, playing a video over either 56Kbps (modem), 1Mbps (DSL or cablemodem), or 100Mbps (ethernet) internet connections. J.-M. Jézéquel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 275-289, 2002.  Springer-Verlag Berlin Heidelberg 2002

276

Jan Øyvind Aagedal and Earl F. Ecklund, Jr.

Our goal in this paper is to present a conceptual model for QoS that will contribute to developing a standard UML profile for QoS as requested in [1]. Such a profile will enable the definition of standard QoS modelling elements (e.g., delay or reliability) and standard QoS-aware functional modelling elements (e.g., video streams). In discussing a QoS profile, we also lay a foundation for QoS-aware software development processes. In order to develop QoS-aware software, support for the specification of QoS (at the level of UML), and support for the implementation of dynamic QoS runtime environments (at programming language, framework, and patterns levels) are needed. In this paper, we present a consistent set of concepts for modelling QoS through all phases of the software development process, and give an example of how these concepts can be used. The paper is based on [2] and structured as follows. Section 2 provides background information on QoS, UML profiles and orthogonality. Section 3 proposes a UML profile for QoS. Section 4 illustrates how the UML profile can be used as part of the software development of a Lecture-on-Demand application. Finally, section 5 points to related work while section 6 summarises our results and identifies future work.

2

Background

In this section, we present QoS terminology, UML profiles and the concept of orthogonality. 2.1

Quality of Service

The functional properties of a system relate to the specification of what the system should do. However, systems have additional properties that characterise the systems’ ability to exist in an environment and adapt as its environment varies. The extrafunctional properties, also called qualities, address how well the system's functionality, if it is realised, can be performed. In other words, if an observable effect of the system doing something can be quantified (implying that there is more than ‘done’/‘not-done’ effect of the behaviour), one can describe the quality of that behaviour. Numerous specific definitions of the term quality of service exist (see [3-6]). We characterise QoS as follows: Quality of Service quantitatively relates the degree of satisfaction of clients of a service to the work performed by a server. By the management of characteristics that affect its QoS, a server (system or component) can predictably and repeatably deliver satisfactory performance to its users. Despite the different definitions, quality of service is a general term that covers system performance, rather than system operation (i.e., functionality). According to the ISO QoS Framework [5], QoS characteristic is the most fundamental term to express QoS. A QoS characteristic represents some aspect of the QoS of a system, service or resource that can be identified and quantified, for instance time delay or availability. In the ISO QoS Framework, a number of QoS characteristics are defined. However, there is no exhaustive list of QoS characteristics,

Modelling QoS: Towards a UML Profile

277

the characteristics defined in the ISO QoS Framework reflect only an agreed set of common characteristics focussing on communication. QoS characteristics are quantified within a domain of values. A specification of a QoS characteristic is a constraint over its domain. Some characteristics are quantified over a numeric domain (e.g., the non-negative integers) while others are quantified over an enumerated or a set domain. Expressing all QoS in terms of a set of QoS characteristics facilitates reasoning about QoS. A QoS relation specifies the mutual obligation of an object and its environment with respect to QoS. The QoS relation concept is the most primitive concept for specifying QoS aspects in ODP (Open Distributed Processing) systems. This concept is introduced to model the fact that, in general, QoS provided by an object can be a function of how the environment performs (i.e., of the QoS provided by the environment). QoS relations are similar to assumption/guarantee specifications as known from formal methods. In [2], the Component Quality Modelling Language (CQML) is defined. CQML is based on the work on QoS in ODP and defines lexical constructs for QoS characteristics, for QoS statements that combine and restrict QoS characteristics, and for QoS profiles that relate QoS statements to QoS Components (functional modelling elements subject to QoS). The conceptual model presented in section 3 models QoS concepts as expressible in CQML. 2.2

UML Profiles

UML is defined by its meta-model. In [7], it is discussed how specific domains that require a specialisation of the general UML meta-model can define a UML profile to focus UML to more precisely describe the domain. Even as concrete UML profiles have started to emerge, use of the profiling mechanism is still discussed [8, 9]. [10] is the recently adopted UML profile for schedulability, performance, and time. In this work we use the approach described in [10] in which a dual viewpoint approach is used where the profile is first modelled from a domain viewpoint and then from a UML viewpoint. The domain viewpoint is to capture, in a generic way, the common structural and behavioural concepts and patterns that characterise the application domain (in our case, QoS). To ensure that this conceptual model accurately reflects the QoS domain and is not influenced unduly by meta-modelling concerns, this model is to a great extent defined independently of the UML meta-model. Although the conceptual model is modelled in UML, „care must be taken not to confuse elements of the domain viewpoint with elements of the UML meta-model.“ [10]. The UML viewpoint is a specification of how the elements of the domain model are realised in UML. This consists of a set of UML extensions (stereotypes, tagged values, constraints) and is supplemented by specifications of the mappings of the domain concepts to those extensions, and specifies additional well-formedness rules (expressed in OCL or in natural language). Addressing both the domain and the UML viewpoints, we propose a UML profile for QoS based on the concepts defined in CQML. This UML profile precisely defines the concepts needed to model QoS using UML version 1.4.

278

Jan Øyvind Aagedal and Earl F. Ecklund, Jr.

2.3

Orthogonality

We believe the QoS offered by a QoS component should be specified separately from the specification of its functional properties. This is appropriate since: (i) the QoS of a QoS component instance is dependent on its environment, (ii) there may be multiple QoS specifications for the component, and (iii) the functional specifications of the component are independent of the particular QoS specification that will be enforced at any point in time. This is an orthogonal separation of concerns between behaviour (functional properties) and constraints (the QoS it offers). This orthogonality can be reflected in a UML model by requiring that QoS model elements depend on the functional model elements, but not the other way around. This unidirectional dependency reinforces that the QoS elements associated with a QoS component can be changed without affecting the functionality of the component.

3

UML Profile for QoS

In this section, a UML profile for QoS is presented. From the domain viewpoint, we define the QoS modelling elements needed to specify the QoS of a component (or object) that provides a service subject to QoS constraints, and to associate its QoS specifications with the component. We shall refer to the component subject to QoS as a QoS component (to be distinguished from the UML Component defined in the MetaModel Core). From the UML viewpoint, we define the extensions needed to define a UML profile for QoS. 3.1

Orthogonality and Packages

Orthogonality is reflected in the UML profile for QoS by defining a separate package for QoS concepts, which depend on functional elements in the standard UML metamodel. Fig. 1 reflects this; the QoS concepts in the Quality Elements package depend on the standard UML concepts in the Foundation package. Notation: In the figures, UML meta-model elements and UML functional elements are shown as shaded, and QoS model elements are shown as white-filled.

Fig. 1. QoS concepts are orthogonal to standard UML concepts

Modelling QoS: Towards a UML Profile

279

QoSComponent 1 for 0..* QoSProfile

provides 1..* uses QoSStatement 1..*

QoSConstraint

QoSCharacteristic

1..*

Fig. 2. QoS conceptual model

3.2

Domain Viewpoint: Conceptual Model for QoS

A conceptual model describes the fundamental abstractions related to the domain of the profile. This model is independent of the UML meta-model, but it defines the concepts that are to be related to the standard UML elements and is often included as an informative part of a UML profile. Next we present the conceptual model for QoS. The conceptual model is a model of the concepts defined in CQML. The model in Fig. 2 shows the overall structure of the CQML concepts that are detailed further in the following subsections. A QoS Component offers services with certain qualities as described by QoS profiles. A QoS profile (to be distinguished from the UML profile for QoS presented in this paper) is a QoS relation specifying the qualities the QoS component provides, if the environment provides the qualities it assumes (uses). These qualities are specified as QoS statements. A QoS statement consists of a number of QoS constraints, i.e., restrictions of the values of the QoS characteristics. For most purposes, the conceptual model is of more interest than a mapping of those concepts into the UML meta-model. For instance, whereas a QoS statement in CQML essentially is an association between a QoS characteristic and a value, it would in the UML meta-model typically be represented as a stereotyped Association (i.e., virtual subclass of meta-class Association) with appropriate well-formedness rules (e.g., constraining the types of the AssociationEnds). 3.2.1 Conceptual Model Element: QoS Component { Abstraction } A QoS component represents the role of a UML model element that is the target of a QoS specification (a QoS profile for a functional model element). The functional model elements that can assume the role of QoS component are: actor, class, component, interface, node, object, subsystem, use case, and use case instance. We use QoSComponent to stand for these kinds of targets of the for-association. Note that a Component in UML denotes a physical piece of implementation of a system and does not fit the notion of QoS component used in CQML and in Fig. 2. 3.2.2 Conceptual Model Element: QoS Profile A QoS profile relates specifications of QoS for a QoS component to other UML modelling elements that specify the functionality of the component. Fig. 3 shows a conceptual model of the CQML QoS profile (termed QoSProfile in the model) and shows how a QoSProfile can be related to functional elements in a UML model.

280

Jan Øyvind Aagedal and Earl F. Ecklund, Jr.

Fig. 3. Conceptual model of QoS profile

A QoS profile represents the terms under which a QoS component (in the functional model) is willing to contract for a QoS relation. Each QoS profile is for one QoS component, while a QoS component may advertise many QoS profiles, with varying terms (levels of QoS or levels of cost) for offered services. The QoS profile is a conditional contract stating that if the QoS component's environment provides the expected QoSCharacteristics that it "uses", then the component can deliver the advertised QoSCharacteristics that it "provides". The offer and the expectation are each expressed as a QoS statement. A QoS profile may be simple or compound, as explained next. A simple QoS profile specifies one QoS offer (the advertised QoS) accompanied with one QoS expectation (the conditions under which the QoS offer is valid). A compound QoS profile offers two or more sets of terms (as simple QoS profiles) that use differing QoS from the QoS component's environment. A compound QoS profile can adapt to changes in the run-time environment by transitioning among its sets of terms (presumably providing the best currently supportable level of QoS). A transition between two simple QoS profiles could for instance occur when the QoS expectation of the current simple QoS profile is invalidated and there exists another that has a weaker assumption on the environment. When such a transition occurs, the QoS profile uses a profileTransition function to make a call-back to an operation on the QoS component, in order for the component to adapt as needed for the transition. The profileTransition functions must be operations on the QoS component. Associations for

The for association associates a QoS profile with a QoS component (in the functional model) that offers the QoS declared in the QoS profile. provides A simple QoS profile "provides" a QoS statement to specify what QoS it can support, assuming its expectation from its environment are met. uses A simple QoS profile "uses" a QoS statement to specify what QoS it must have from its environment in order to support the QoS profile.

3.2.3 Conceptual Model Element: QoS Statement A CQML QoS profile specifies QoS offers (provides) and QoS expectations (uses) as QoS statements. Fig. 4 shows the conceptual model of QoS statement.

Modelling QoS: Towards a UML Profile

281

relation

QoSStatement 2..* +parameter Parameter (from Core)

0..* {ordered}

SingleQoSStatement

CompoundQoSSt atement

1 QoSCharacteristic

QoSConst raint qualification : QualificationKind

Fig. 4. Conceptual model of a QoS statement

A QoSStatement may be single or compound. A compound QoS statement is composed of two or more QoS statements, and relates these by the relationassociation. A compound QoS statement can relate other QoS statements by and- or or-relations. A SingleQoSStatement contains a QoSConstraint. A QoS statement may have parameters that relate to properties of the QoSComponent to which the QoSStatement pertains (via its containing QoSProfile, see Fig. 3). Associations relation A compound QoS statement relates other QoS statements (recursively, either simple or compound) with "and" or "or" relations to yield a Boolean expression involving the QoS characteristics constrained in the simple QoS statements' associated constraints. 3.2.4 Conceptual Model Element: QoS Constraint A QoSConstraint is a Constraint that restricts a QoS characteristic and contains an attribute that specifies the qualification of the constraint (i.e., best-effort, guaranteed, threshold best-effort, compulsory best-effort). 3.2.5 Conceptual Model Element: QoS Characteristic A CQML QoS characteristic defines an aspect or dimension in which QoS can be specified and measured. Fig. 5 shows the conceptual model of QoS characteristic. A QoSCharacteristic contains three composition attributes, a values attribute, and an invariant attribute. It also has an associated Domain with a direction. The values of the QoSCharacteristic belong to its Domain, and the direction declares whether high or low values denote better quality. The three composition-attributes and the values-attribute are MappingExpressions, i.e., expressions that evaluate to mappings between modelling elements. The composition-attributes denote the effect with respect to this QoS characteristic of different kinds of compositions (and-aggregate, or-aggregate, and composite). The values-attribute denotes how the values of the QoS characteristic can be derived during run-time. An invariant-attribute is used to specify invariant properties of the QoS characteristic. Different kinds of statistical derivations are defined as StatisticalAttributeKind. A QoS characteristic may have parameters that are bound to the parameters of its constraining QoS statement (see Fig. 4).

282

Jan Øyvind Aagedal and Earl F. Ecklund, Jr.

DataType

Parameter

(from Core)

(from Core)

+parameter QoSCharacteristic invariant : BooleanExpression parallel_and_composition : MappingExpression parallel_or_composition : MappingExpression sequential_composition : MappingExpression values : MappingExpression

Domain direction : DirectionKind

Numeric

Set

1

0..*

Enumeration

Statist icalAttribut eKind {ordered} 1..* StringS et

1..* String (from Data T ypes)

Fig. 5. Conceptual model of QoS characteristic

Associations domain

The Domain identifies the values that can be taken on by the QoS characteristic. Its direction (increasing or decreasing) indicates whether high values or low values of the characteristic are preferred.

Note that QoSCharacteristic can be sub-classed in order to define a specialised UML Profile for QoS. Examples might include performance- or availability-related specialisations with specialised QoSCharacteristics such as responseTime or uptime. 3.2.6 Conceptual Model Elements: QoS Data Types The data types used are the following: QualificationKind is an enumeration whose values are guaranteed, best-effort, threshold best-effort, compulsory best-effort. DirectionKind is an enumeration whose values are undefined, increasing, decreasing. StatisticalAttributeKind is an enumeration whose values are maximum, minimum, range, mean, variance, standard_deviation, percentile, frequency, moment, distribution. 3.3

UML Viewpoint: A UML Profile for QoS

In this section we give definitions of the UML extensions: stereotypes, tagged values, and constraints, that pertain specifically to modelling Quality of Service, based on the conceptual model of QoS (section 3.2). Constraints are only specified textually herein; OCL versions of most of these are available in [2]. The stereotypes for modelling QoS are all defined in the Quality Elements package. All extension element names of the QoS profile are prefixed with „QoS."

Modelling QoS: Towards a UML Profile

283

3.3.1 «QoSProfile» Stereotype «QoSProfile» «QoSAssociation» «QoSSimpleProfile»

Base Class Classifier Association «QoSProfile»

«QoSCompoundProfile» «QoSProfileTransition»

«QoSProfile» Classifier

Tags QoSfor QoSprovides QoSuses QoStransition QoSfrom QoSto QoStransitionOperation

QoSAssociation is a special kind of Association used for relating Quality Elements to Functional Elements. Tag definitions. Tag QoSfor QoSprovides QoSuses QoStransition QoSfrom QoSto QoStransitionOperation

Type «QoSAssociation» «QoSStatement» «QoSStatement» «QoSProfileTransition» «QoSSimpleProfile» «QoSSimpleProfile» Operation

Multiplicity [1..1] [1..1] [1..1] [0..*] [1..1] [1..1] [0..*]

The following constraints are defined for these stereotypes: • • • • • • • • •

A QoSProfile must have exactly one QoSAssociation. A QoSAssociation is a binary association, with profile- and for-roles. The type of QoSAssociation.profile is «QoSProfile». The type of QoSAssociation.for is one of actor, class, component, interface, node, object, subsystem, use case, or use case instance. The cardinality of QoSAssociation.profile is 0..*. The cardinality of QoSAssociation.for is 1. The QoSAssociation.profile end is not navigable. The QoSAssociation.for end is navigable. Each QoStransitionOperation must be an operation of the containing QoSCompoundProfile's associated QoSfor.for model element.

3.3.2 «QoSStatement» Stereotype «QoSStatement» «QoSSingleStatement» «QoSCompoundStatement» «QoSConstraint»

Base Class Classifier «QoSStatement» «QoSStatement» Constraint

Tags QoSparameters QoSconstraint QoSrelation

284

Jan Øyvind Aagedal and Earl F. Ecklund, Jr.

Tag definitions. Tag QoSparameters QoSconstraint QoSrelation

Type Parameter «QoSConstraint» «QoSStatement»

Multiplicity [0..*] [1..1] [2..*]

The following constraints are defined for these stereotypes: • • •

Each QoSConstraint constrains a single QoSCharacteristic. The values of the QoSparameters depend only on features of the containing QoSProfile's associated QoSfor.for model element, or parts thereof. The parameters of the constrained QoSCharacteristics of a QoSStatement are a subset of its QoSparameters.

3.3.3 «QoSCharacteristic» Stereotype «QoSCharacteristic»

Base Class Classifier

«Domain» «Enumeration» «Numeric» «Set»

DataType «Domain» «Domain» «Domain»

Tags QoSinvariant QoSparallel_and_composition QoSparallel_or_composition QoSsequential_composition QoSvalues QoSparameters QoSstatisticalAttributeKind QoSdomain QoSdirection

QoSStringSet

Tag definitions. Tag QoSinvariant QoSparallel_and_composition QoSparallel_or_composition QoSsequential_composition QoSvalues QoSparameters QoSstatisticalAttributeKind QoSdomain QoSdirection QoSStringSet

Type BooleanExpression MappingExpression MappingExpression MappingExpression MappingExpression Parameter StatisticalAttributeKind «Domain» DirectionKind String

Multiplicity [0..1] [0..1] [0..1] [0..1] [1..1] [0..*] [0..*] [1..1] [1..*]

The following constraints are defined for these stereotypes: •

The QoSparameters of a QoSCharacteristic must be a subset of the QoSparameters in the QoSStatement that constrains the QoSCharacteristic.

Modelling QoS: Towards a UML Profile

• • • • • •

4

285

The three composition-expressions map pairs of values of Domain into a value of Domain. The values-expression maps values of the QoSparameters into a value of Domain. The invariant-expression only refers to the QoSparameters, values of the Domain, and the QoSstatisticalAttributeKind. The QoSparallel_and_composition mapping is used when the two values are parts of an aggregate. The QoSsequential_composition mapping is used when the two values are parts of a composite. The QoSparallel_or_composition mapping is used when the two values are parts of an aggregate and an or-constraint exists between the two aggregate associations.

Example from a Lecture on Demand Case

We have performed a case study to design a Lecture on Demand (LoD) system. We give one specific example to illustrate use of the proposed UML profile for QoS in our LoD models. Fig. 6 shows the functional model for a LectureConsumer class that is designed to receive (consume) flows containing lecture data on the viewing station. The LectureConsumer has multiple Buffers into which an information source can putData(), and an IncreaseBufferSize() operation that can be used for adaptation. For instance, if jitter is a problem, the buffer size can be increased so that more information can be stored in the buffers, ready for consumption by the LectureConsumer. L e c tu r e C o n s u m e r 1 ..*

out in c re as eB u ffe rS iz e ()

D is p la ye r

+ in

B u ffe r

s iz e : In te g e r 1 ..* flo w : F lo w

D a ta R e c e iv e r

s ho w D a ta U n it(un it : D at aU n it)

pu tD a ta U n it (u nit : D a ta U n it)

Fig. 6. LectureConsumer’s reception of multimedia flows

for

Lecture Consumer

Acceptable

increaseBufferSize()

Good

Ok

+from increaseBufferSize

+to

Good->Ok

Fig. 7. Acceptable QoS profile for LectureConsumer

286

Jan Øyvind Aagedal and Earl F. Ecklund, Jr.

In Fig. 7 we show the QoSAssociation (for) from a QoS profile (Acceptable) to a classifier (LectureConsumer). Acceptable is a compound profile that uses IncreaseBufferSize() to perform its profile transition behaviour when transitioning from the Good to the OK simple profile. This is shown by an association from a Profile Transition (Good->OK) to the same classifier, where the association is labelled by the transition operation (IncreaseBufferSize()).

5

Related Work

[10] is the adopted UML profile for schedulability, performance, and time. Although this profile does not cover QoS in a broad sense, defining only QoScharacteristic and QoSvalue classes in their conceptual model, our UML profile for QoS is aligned with their approach. We also follow their lightweight approach to specifying a QoS profile. The OMG Analysis and Design platform task force has differentiated between lightweight and heavyweight extension mechanisms for UML. Lightweight extensions use only the mechanism of stereotypes, tagged values and constraints, and are fully supported by UML 1.3. Heavyweight extensions modify the UML meta-model, may require the full power of the Meta-Object Facility (MOF) to implement, and are not currently supported by UML [7]. It is considered preferable to define a UML profile using only lightweight extension mechanisms. The schedulability profile [10] succeeds in defining several profiles using only lightweight mechanisms, as does the UML profile for QoS described in this paper. QoS specification languages other than CQML may be used as a starting point for a UML profile for QoS. Such languages include QIDL, defined as part of the QoS management architecture MAQS (Management for Adaptive QoS-enabled Services) [11], the Quality Description Language (QDL) suite, defined as part of the Quality of Service for Objects (QuO) architecture [12], and QML as presented in [13]. In [14], the authors discuss how QML can be combined with UML. As discussed in more detail in [2], none of the QoS specification languages mentioned above support all features of CQML. In particular, the ability to specify compound QoS Profiles and relate QoS specifications to the functional model are CQML features that are essential for a complete UML profile for QoS. There are two recent papers that propose related extensions to UML. [15] proposes a „UML Meta-model for Contract Aware Components“ and [16] proposes „A UML Profile for QoS Management Information Specification in Distributed Object-based Applications.“ [15] states that relationships between required and ensured contracts can become quite complex, especially when QoS contracts are involved. To assist this, „an appropriate UML notation is needed“. Further, [15] states that there currently is no need to derive a QoSContract from the NonFunctionalContract, but „once there is a UML standard to describe QoSContracts and the like in UML directly it might make sense to introduce a QoSContract subclass.“ [15] uses heavyweight meta-model modifications to extend UML, for example defining a meta-class Contract as a superclass of the standard UML meta-class Interface. It also defines a dependency

Modelling QoS: Towards a UML Profile

287

relationship from a component to a contract to indicate that „the contract is required by this component.“ We feel that orthogonality dictates the QoSAssociation between a QoSProfile and a component in the functional model should be only navigable in one direction, namely from the QoSProfile to the component. This is the reverse direction to that used in [15]. The approach used in [15] begs the question of how to use a component that is not QoS-aware or that does not have any QoS constraints. [16] proposes an extension of UML called UML-Q. This work was strongly influenced by the ISO Reference Model of Open Distributed Processing work on QoS, as were we. They recognise the need to make QoS specification independent of the definition of computational objects (orthogonality), which they model with a QoSAssignment meta-class. Unfortunately, the way they model QoSAssignment might require heavyweight extension mechanisms. Furthermore, UML-Q introduces at least 20 virtual meta-classes, including, for example, QoSValue, QoSContract, QoSCharacterizedFeature, QoSCharacteristic, QoSCharacteristicType and QoSType. This leads to a virtual meta-model that seems unnecessarily complex.

6

Conclusions and Future Work

This paper has described a conceptual meta-model for Quality of Service, based on the semantics of CQML. Then, based on this conceptual meta-model, we have described a UML profile for QoS. We have discussed aspects of modelling QoS for an LoD application. The LoD example demonstrates the definition of QoS profiles for objects, including compound profiles with transition behaviour. Based on the UML profile defined in section 3, standard QoS modelling elements can be defined that capture commonly used semantics for reuse in many models. For instance, QoS characteristics such as delay, throughput, reliability, etc. could be defined related to a generic model of component interaction. Common design patterns can be used as starting points for such generic models, and the proposed QoS characteristics of general importance in the ISO QoS Framework [5] can be a useful starting point for standard QoS modelling elements. To specify such standard QoS modelling elements and argue their generality is an area for future work. In addition to standard QoS modelling elements, standard QoS-aware functional modelling elements can also be defined. For instance, a stream-stereotype could include a number of QoS characteristics such as delay, throughput and jitter. Such a modelling element could possibly be defined with some standard values to indicate capacity constraints. For instance, an ISDN-stream modelling element could include QoS characteristics such as delay and jitter, and a capacity constraint on throughput of 128kbit/s. Also, one could define QoS parameter exchange formats for such standard modelling elements. For instance, to develop an XML DTD suited for conveyance of QoS parameters is a possible topic for future work. Finally, the UML profile presented does not propose any graphical notation. One possibility is to define QoS characteristics as tags that can be exploited in tagged values on the relevant modelling elements, but further investigation is needed to define a graphical notation for QoS profiles.

288

Jan Øyvind Aagedal and Earl F. Ecklund, Jr.

Specification of QoS is especially useful if there exists computational support that is able to provide run-time QoS management to maintain the specified QoS. Implementation of the QoS framework architecture presented in [2] is being addressed as part of several master thesis projects. Our QoS framework will perform QoS management using a run-time representation that is obtained by parsing QoS specifications, consistent with the UML profile for QoS presented in this work, expressed in CQML.

Acknowledgements The work reported in this paper is carried out in the context of OMODIS, a five-year project funded by the Norwegian Research Council (NFR) Distributed IT Systems (DITS) program.

References [1]

OMG, „UML Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms,“ Request for Proposal, ad/02-01-07, January, 2002. [2] J. Ø. Aagedal, „Quality of Service Support in Development of Distributed Systems,“ PhD thesis, Department of Informatics, Faculty of Mathematics and Natural Sciences. Oslo: University of Oslo, 2001, pp. 250. [3] ISO, „Quality Vocabulary,“ ISO, ISO 8402, 1986. [4] Miriam-Webster, „Miriam-Webster Online“, http://www.m-w.com/, accessed: 2000. [5] ISO/IEC JTC1/SC21, „QoS - Basic Framework,“ ISO, ISO/IEC JTC1/SC 21 N9309, January, 1995. [6] ISO/IEC JTC1/SC7, „Information Technology - Software product quality – Part 1: Quality model,“ ISO/IEC, 9126-1, 1999. [7] OMG, „White Paper on the Profile mechanism,“ ad/99-04-07, April, 1999. [8] D. F. D'Souza, A. Sane, and A. Birchenough, „First Class Extensibility for UML - Packaging of Profiles, Stereotypes, Patterns,“ presented at 2nd Int. Conf. on the Unified Modeling Language: UML'99, Fort Collins, CO, USA, 1999. [9] C. Atkinson and T. Kühne, „Strict Profiles: Why and How,“ presented at 3rd Int. Conf. on the Unified Modeling Language (UML2000), University of York, UK, 2000. [10] OMG, „UML Profile for Schedulability, Performance, and Time Specification,“ Final Adopted Specification, ptc/02-03-02, March, 2002. [11] C. Becker and K. Geihs, „MAQS - Management for Adaptive QoS-enabled Services,“ presented at IEEE Workshop on Middleware for Distributed RealTime Systems and Services, San Fransisco, USA, 1997.

Modelling QoS: Towards a UML Profile

289

[12] J. P. Loyall, R. E. Schantz, J. A. Zinky, and D. E. Bakken, „Specifying and Measuring Quality of Service in Distributed Object Systems,“ presented at 1st Int. Symposium on Object-Oriented Real-time Distributed Computing (ISORC 98), 1998. [13] S. Frølund and J. Koistinen, „QML: A Language for Quality of Service Specification,“ Software Technology Laboratory, Hewlett-Packard Company, HPL-98-10, February, 1998. [14] S. Frølund and J. Koistinen, „Quality-of-Service Specification in Distributed Object Systems,“ Distributed Systems Engineering Journal, vol. 5, pp. 179-202, 1998. [15] T. Weis, C. Becker, K. Geihs, and N. Plouzeau, „A UML Meta-Model for Contract Aware Components,“ presented at 4th Int. Conf. on The Unified Modeling Language ( 2001), Toronto, Canada, 2001. [16] J. J. Asensio and V. A. Villagrá, „A UML Profile for QoS Management Information Specification in Distributed Object-based Applications,“ presented at HP OpenView University Association 7th Plenary Workshop (HPOVUA 2000), Santorini, Greece.

❊①t❡♥❞✐♥❣ t❤❡ ❯▼▲ ❢♦r ▼✉❧t✐❞✐♠❡♥s✐♦♥❛❧ ▼♦❞❡❧✐♥❣⋆ ❙❡r❣✐♦ ▲✉❥á♥✲▼♦r❛1 ✱ ❏✉❛♥ ❚r✉❥✐❧❧♦1 ✱ ❛♥❞ ■❧✲❨❡♦❧ ❙♦♥❣2 1

2

❉❡♣t✳ ❞❡ ▲❡♥❣✉❛❥❡s ② ❙✐st❡♠❛s ■♥❢♦r♠át✐❝♦s ❯♥✐✈❡rs✐❞❛❞ ❞❡ ❆❧✐❝❛♥t❡ ✭❙♣❛✐♥✮ ④s❧✉❥❛♥✱❥tr✉❥✐❧❧♦⑥❅❞❧s✐✳✉❛✳❡s

❈♦❧❧❡❣❡ ♦❢ ■♥❢♦r♠❛t✐♦♥ ❙❝✐❡♥❝❡ ❛♥❞ ❚❡❝❤♥♦❧♦❣② ❉r❡①❡❧ ❯♥✐✈❡rs✐t② ✭❯❙❆✮ s♦♥❣✐②❅❞r❡①❡❧✳❡❞✉

▼✉❧t✐❞✐♠❡♥s✐♦♥❛❧ ✭▼❉✮ ♠♦❞❡❧✐♥❣ ✐s t❤❡ ❢♦✉♥❞❛t✐♦♥ ♦❢ ❞❛t❛ ✇❛r❡❤♦✉s❡s✱ ▼❉ ❞❛t❛❜❛s❡s✱ ❛♥❞ ❖♥✲▲✐♥❡ ❆♥❛❧②t✐❝❛❧ Pr♦❝❡ss✐♥❣ ✭❖▲❆P✮ ❛♣♣❧✐❝❛t✐♦♥s✳ ■♥ t❤❡ ♣❛st ❢❡✇ ②❡❛rs✱ t❤❡r❡ ❤❛✈❡ ❜❡❡♥ s♦♠❡ ♣r♦♣♦s❛❧s ❢♦r r❡♣r❡s❡♥t✐♥❣ t❤❡ ♠❛✐♥ ▼❉ ♣r♦♣❡rt✐❡s ❛t t❤❡ ❝♦♥❝❡♣t✉❛❧ ❧❡✈❡❧ ♣r♦✈✐❞✐♥❣ t❤❡✐r ♦✇♥ ♥♦t❛t✐♦♥s✳ ■♥ t❤✐s ♣❛♣❡r✱ ✇❡ ♣r❡s❡♥t ❛♥ ❡①t❡♥s✐♦♥ ♦❢ t❤❡ ❯♥✐✲ ✜❡❞ ▼♦❞❡❧✐♥❣ ▲❛♥❣✉❛❣❡ ✭❯▼▲✮✱ ❜② ♠❡❛♥s ♦❢ st❡r❡♦t②♣❡s✱ t♦ ❡❧❡❣❛♥t❧② r❡♣r❡s❡♥t ♠❛✐♥ str✉❝t✉r❛❧ ❛♥❞ ❞②♥❛♠✐❝ ▼❉ ♣r♦♣❡rt✐❡s ❛t t❤❡ ❝♦♥❝❡♣t✉❛❧ ❧❡✈❡❧✳ ❲❡ ♠❛❦❡ ✉s❡ ♦❢ t❤❡ ❖❜❥❡❝t ❈♦♥str❛✐♥t ▲❛♥❣✉❛❣❡ ✭❖❈▲✮ t♦ s♣❡❝✐❢② t❤❡ ❝♦♥str❛✐♥ts ❛tt❛❝❤❡❞ t♦ t❤❡ ❞❡✜♥❡❞ st❡r❡♦t②♣❡s✱ t❤❡r❡❜② ❛✈♦✐❞✐♥❣ ❛♥ ❛r❜✐tr❛r② ✉s❡ ♦❢ t❤❡s❡ st❡r❡♦t②♣❡s✳ ❚❤❡ ♠❛✐♥ ❛❞✈❛♥t❛❣❡ ♦❢ ♦✉r ♣r♦♣♦s❛❧ ✐s t❤❛t ✐t ✐s ❜❛s❡❞ ♦♥ ❛ ✇❡❧❧✲❦♥♦✇♥ st❛♥❞❛r❞ ♠♦❞❡❧✐♥❣ ❧❛♥❣✉❛❣❡✱ t❤❡r❡❜② ❞❡s✐❣♥❡rs ❝❛♥ ❛✈♦✐❞ ❧❡❛r♥✐♥❣ ❛ ♥❡✇ s♣❡❝✐✜❝ ♥♦t❛t✐♦♥ ♦r ❧❛♥❣✉❛❣❡ ❢♦r ▼❉ s②st❡♠s✳ ❋✐♥❛❧❧②✱ ✇❡ s❤♦✇ ❤♦✇ t♦ ✉s❡ t❤❡s❡ st❡r❡♦t②♣❡s ✐♥ ❘❛t✐♦♥❛❧ ❘♦s❡ ✷✵✵✵ ❢♦r ▼❉ ♠♦❞❡❧✐♥❣✳ ❆❜str❛❝t✳

❑❡②✇♦r❞s✿ ❯▼▲✱ ❯▼▲ ❡①t❡♥s✐♦♥s✱ ♠✉❧t✐❞✐♠❡♥s✐♦♥❛❧ ♠♦❞❡❧✐♥❣✱ ❖❈▲✱ ❘❛✲

t✐♦♥❛❧ ❘♦s❡

✶

■♥tr♦❞✉❝t✐♦♥

▼✉❧t✐❞✐♠❡♥s✐♦♥❛❧ ✭▼❉✮ ♠♦❞❡❧✐♥❣ ✐s t❤❡ ❢♦✉♥❞❛t✐♦♥ ♦❢ ❞❛t❛ ✇❛r❡❤♦✉s❡s ✭❉❲✮✱ ▼❉ ❞❛t❛❜❛s❡s✱ ❛♥❞ ❖♥✲▲✐♥❡ ❆♥❛❧②t✐❝❛❧ Pr♦❝❡ss✐♥❣ ✭❖▲❆P✮ ❛♣♣❧✐❝❛t✐♦♥s✳ ❚❤❡s❡ s②st❡♠s ♣r♦✈✐❞❡ ❝♦♠♣❛♥✐❡s ✇✐t❤ ♠❛♥② ②❡❛rs ♦❢ ❤✐st♦r✐❝❛❧ ✐♥❢♦r♠❛t✐♦♥ ❢♦r t❤❡ ❞❡❝✐s✐♦♥ ♠❛❦✐♥❣ ♣r♦❝❡ss✳ ❱❛r✐♦✉s ❛♣♣r♦❛❝❤❡s ❢♦r t❤❡ ❝♦♥❝❡♣t✉❛❧ ❞❡s✐❣♥ ♦❢ ▼❉ s②st❡♠s ❤❛✈❡ ❜❡❡♥ ♣r♦♣♦s❡❞ ✐♥ t❤❡ ❧❛st ❢❡✇ ②❡❛rs s✉❝❤ ❛s ❬✶❪❬✷❪❬✸❪❬✹❪❬✺❪ t♦ r❡♣r❡s❡♥t ♠❛✐♥ ▼❉ str✉❝t✉r❛❧ ❛♥❞ ❞②♥❛♠✐❝ ♣r♦♣❡rt✐❡s✳ ❚❤❡s❡ ❛♣♣r♦❛❝❤❡s ♣r♦✈✐❞❡ t❤❡✐r ♦✇♥ ❣r❛♣❤✐❝❛❧ ♥♦t❛t✐♦♥s✱ ✇❤✐❝❤ ❢♦r❝❡s ❞❡s✐❣♥❡rs t♦ ❧❡❛r♥ ❛ ♥❡✇ s♣❡❝✐✜❝ ♠♦❞❡❧ t♦❣❡t❤❡r ✇✐t❤ ✐ts ❝♦rr❡s♣♦♥❞✐♥❣ ▼❉ ♠♦❞❡❧✐♥❣ ♥♦t❛t✐♦♥✳ ❋✉rt❤❡r♠♦r❡✱ ♥♦♥❡ ♦❢ t❤❡s❡ ❛♣♣r♦❛❝❤❡s ❤❛s ❜❡❡♥ ✇✐❞❡❧② ❛❝❝❡♣t❡❞ ❛s ❛ st❛♥❞❛r❞ ❝♦♥❝❡♣t✉❛❧ ♠♦❞❡❧ ❢♦r ⋆

❚❤✐s ♣❛♣❡r ❤❛s ❜❡❡♥ ♣❛rt✐❛❧❧② s✉♣♣♦rt❡❞ ❜② t❤❡ ❙♣❛♥✐s❤ ▼✐♥✐st❡r② ♦❢ ❙❝✐❡♥❝❡ ❛♥❞ ❚❡❝❤♥♦❧♦❣②✱ ♣r♦❥❡❝t ♥✉♠❜❡r ❚■❈✷✵✵✶✲✸✺✸✵✲❈✵✷✲✵✷✳

J.-M. J´ez´equel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 290-304, 2002. c Springer-Verlag Berlin Heidelberg 2002

Extending the UML for Multidimensional Modeling

291

▼❉ ♠♦❞❡❧✐♥❣✳ ❉✉❡ t♦ s♣❛❝❡ ❝♦♥str❛✐♥ts✱ ✇❡ r❡❢❡r t❤❡ r❡❛❞❡r t♦ ❬✻❪ ❢♦r ❛ ❞❡t❛✐❧❡❞ ❝♦♠♣❛r✐s♦♥ ❛♥❞ ❞✐s❝✉ss✐♦♥ ❛❜♦✉t ♠♦st ♦❢ t❤❡s❡ ♠♦❞❡❧s✳ ❖♥ t❤❡ ♦t❤❡r ❤❛♥❞✱ t❤❡ ❯♥✐✜❡❞ ▼♦❞❡❧✐♥❣ ▲❛♥❣✉❛❣❡ ✭❯▼▲✮ ❬✼❪❬✽❪ ❤❛s ❜❡❡♥ ✇✐❞❡❧② ❛❝❝❡♣t❡❞ ❛s t❤❡ st❛♥❞❛r❞ ♦❜❥❡❝t✲♦r✐❡♥t❡❞ ✭❖❖✮ ♠♦❞❡❧✐♥❣ ❧❛♥❣✉❛❣❡ ❢♦r ♠♦❞❡❧✐♥❣ ✈❛r✐♦✉s ❛s♣❡❝ts ♦❢ s♦❢t✇❛r❡ s②st❡♠s✳ ❚❤❡r❡❢♦r❡✱ ❛♥② ❛♣♣r♦❛❝❤ ✉s✐♥❣ t❤❡ ❯▼▲ ✇✐❧❧ ♠✐♥✐♠✐③❡ t❤❡ ❡✛♦rt ♦❢ ❞❡✈❡❧♦♣❡rs t♦ ❧❡❛r♥ ♥❡✇ ♥♦t❛t✐♦♥s ♦r ♠❡t❤♦❞✲ ♦❧♦❣✐❡s ❢♦r ❡✈❡r② s✉❜s②st❡♠ t♦ ❜❡ ♠♦❞❡❧❡❞✳ ❋♦❧❧♦✇✐♥❣ t❤✐s ❝♦♥s✐❞❡r❛t✐♦♥✱ ✇❡ ❤❛✈❡ ♣r❡✈✐♦✉s❧② ♣r♦♣♦s❡❞ ✐♥ ❬✺❪ ❛♥ ❖❖ ❝♦♥❝❡♣t✉❛❧ ▼❉ ♠♦❞❡❧✐♥❣ ❛♣♣r♦❛❝❤✱ ❜❛s❡❞ ♦♥ t❤❡ ❯▼▲ ❢♦r ❛ ♣♦✇❡r❢✉❧ ❝♦♥❝❡♣t✉❛❧ ▼❉ ♠♦❞❡❧✐♥❣✳ ❚❤✐s ♣r♦♣♦s❛❧ ❝♦♥s✐❞❡rs ♠❛✲ ❥♦r r❡❧❡✈❛♥t str✉❝t✉r❛❧ ❛♥❞ ❞②♥❛♠✐❝ ▼❉ ♣r♦♣❡rt✐❡s ❛t t❤❡ ❝♦♥❝❡♣t✉❛❧ ❧❡✈❡❧ ✐♥ ❛♥ ❡❧❡❣❛♥t ❛♥❞ ❡❛s② ✇❛②✳ ❚❤❡ ❯▼▲ ✐s ❛♥ ❡①t❡♥s✐❜❧❡ ❧❛♥❣✉❛❣❡✱ ✐♥ t❤❡ s❡♥s❡ t❤❛t ✐t ♣r♦✈✐❞❡s ♠❡❝❤❛✲ ♥✐s♠s ✭st❡r❡♦t②♣❡s✱ t❛❣❣❡❞ ✈❛❧✉❡s✱ ❛♥❞ ❝♦♥str❛✐♥ts✮ t♦ ✐♥tr♦❞✉❝❡ ♥❡✇ ❡❧❡♠❡♥ts ❢♦r s♣❡❝✐✜❝ ❞♦♠❛✐♥s ✐❢ ♥❡❝❡ss❛r②✱ s✉❝❤ ❛s ✇❡❜ ❛♣♣❧✐❝❛t✐♦♥s✱ ❞❛t❛❜❛s❡ ❛♣♣❧✐❝❛t✐♦♥s✱ ❜✉s✐♥❡ss ♠♦❞❡❧✐♥❣✱ s♦❢t✇❛r❡ ❞❡✈❡❧♦♣♠❡♥t ♣r♦❝❡ss❡s✱ ❡t❝✳ ❬✾✱✶✵❪✳ ❆ ❝♦❧❧❡❝t✐♦♥ ♦❢ ❡♥❤❛♥❝❡♠❡♥ts t❤❛t ❡①t❡♥❞ ❛♥ ❡①✐st✐♥❣ ❞✐❛❣r❛♠ t②♣❡ t♦ s✉♣♣♦rt ❛ ♥❡✇ ♣✉r♣♦s❡ ✐s ❝❛❧❧❡❞ ❛

♣r♦✜❧❡✳

■♥ t❤✐s ♣❛♣❡r✱ ✇❡ ♣r❡s❡♥t ❛ ❯▼▲ ♣r♦✜❧❡ ❢♦r ▼❉ ♠♦❞❡❧✐♥❣ ❜❛s❡❞ ♦♥ ♦✉r ♣r❡✈✐✲ ♦✉s❧② ♣r♦♣♦s❡❞ ❛♣♣r♦❛❝❤ ❬✺❪✱ ✇❤✐❝❤ ❡❛s✐❧② ❛♥❞ ❡❧❡❣❛♥t❧② ❝♦♥s✐❞❡rs ♠❛✐♥ ▼❉ ♣r♦♣✲ ❡rt✐❡s ❛t t❤❡ ❝♦♥❝❡♣t✉❛❧ ❧❡✈❡❧✱ s✉❝❤ ❛s t❤❡ ♠❛♥②✲t♦✲♠❛♥② r❡❧❛t✐♦♥s❤✐♣s ❜❡t✇❡❡♥ ❢❛❝ts ❛♥❞ ❞✐♠❡♥s✐♦♥s✱ ❞❡❣❡♥❡r❛t❡ ❞✐♠❡♥s✐♦♥s✱ ♠✉❧t✐♣❧❡ ❛♥❞ ❛❧t❡r♥❛t✐✈❡ ♣❛t❤ ❝❧❛s✲ s✐✜❝❛t✐♦♥ ❤✐❡r❛r❝❤✐❡s✱ ❛♥❞ ♥♦♥✲str✐❝t ❛♥❞ ❝♦♠♣❧❡t❡ ❤✐❡r❛r❝❤✐❡s✳ ❖✉r ❡①t❡♥s✐♦♥ ✉s❡s t❤❡ ❖❜❥❡❝t ❈♦♥str❛✐♥t ▲❛♥❣✉❛❣❡ ✭❖❈▲✮ ❬✽❪ ❢♦r ❡①♣r❡ss✐♥❣ ✇❡❧❧✲❢♦r♠❡❞♥❡ss r✉❧❡s ♦❢ t❤❡ ♥❡✇ ❞❡✜♥❡❞ ❡❧❡♠❡♥ts✱ t❤❡r❡❜② ❛✈♦✐❞✐♥❣ ❛♥ ❛r❜✐tr❛r② ✉s❡ ♦❢ t❤✐s ❡①t❡♥s✐♦♥✳ ▼♦r❡♦✈❡r✱ ✇❡ ♣r♦❣r❛♠ t❤✐s ❡①t❡♥s✐♦♥ ✐♥ ❛ ✇❡❧❧✲❦♥♦✇♥ ♠♦❞❡❧✲❞r✐✈❡♥ ❞❡✈❡❧♦♣♠❡♥t t♦♦❧ s✉❝❤ ❛s ❘❛t✐♦♥❛❧ ❘♦s❡ t♦ s❤♦✇ ✐ts ❛♣♣❧✐❝❛❜✐❧✐t②✳ ❚❤❡ r❡♠❛✐♥❞❡r ♦❢ t❤✐s ♣❛♣❡r ✐s str✉❝t✉r❡❞ ❛s ❢♦❧❧♦✇s✿ ❙❡❝t✐♦♥ ✷ ❜r✐❡✢② ♣r❡s❡♥ts ♦t❤❡r ✇♦r❦s r❡❧❛t❡❞ t♦ ❡①t❡♥❞✐♥❣ t❤❡ ❯▼▲ ❢♦r ❞❛t❛❜❛s❡ ❞❡s✐❣♥✳ ❙❡❝t✐♦♥ ✸ ✐♥tr♦✲ ❞✉❝❡s t❤❡ ♠❛✐♥ ▼❉ ❝♦♥❝❡♣ts s✉❝❤ ❛s ❢❛❝t✱ ❞✐♠❡♥s✐♦♥✱ ❛♥❞ ❤✐❡r❛r❝❤② ❧❡✈❡❧ t❤❛t ♦✉r ❛♣♣r♦❛❝❤ ❝♦♠♣r✐s❡s✳ ❙❡❝t✐♦♥ ✹ s✉♠♠❛r✐③❡s t❤❡ ❯▼▲ ❊①t❡♥s✐❜✐❧✐t② ▼❡❝❤❛✲ ♥✐s♠✳ ❙❡❝t✐♦♥ ✺ ♣r♦♣♦s❡s t❤❡ ♥❡✇ ❯▼▲ ❡①t❡♥s✐♦♥ ❢♦r ▼❉ ♠♦❞❡❧✐♥❣✳ ❙❡❝t✐♦♥ ✻ s❤♦✇s ❤♦✇ t♦ ✉s❡ ♦✉r ▼❉ ❡①t❡♥s✐♦♥ ✐♥ ❘❛t✐♦♥❛❧ ❘♦s❡✳ ❋✐♥❛❧❧②✱ ❙❡❝t✐♦♥ ✼ ♣r❡s❡♥ts t❤❡ ♠❛✐♥ ❝♦♥❝❧✉s✐♦♥s ❛♥❞ ✐♥tr♦❞✉❝❡s ♦✉r ❢✉t✉r❡ ✇♦r❦✳

✷

❘❡❧❛t❡❞ ❲♦r❦

■♥ t❤❡ ♣❛st ❢❡✇ ②❡❛rs✱ s♦♠❡ ♣r♦♣♦s❛❧s t♦ ❡①t❡♥❞ t❤❡ ❯▼▲ ❢♦r ❞❛t❛❜❛s❡ ❞❡s✐❣♥ ❤❛✈❡ ❜❡❡♥ ♣r❡s❡♥t❡❞✱ s✐♥❝❡ t❤❡ ❯▼▲ ❞♦❡s ♥♦t ❡①♣❧✐❝✐t❧② ✐♥❝❧✉❞❡ ❛ ❞❛t❛ ♠♦❞❡❧✳ ■♥ ❬✶✶❪✱ ✏✳✳✳❛ ♣r♦✜❧❡ t❤❛t ❡①t❡♥❞s t❤❡ ❡①✐st✐♥❣ ❝❧❛ss ❞✐❛❣r❛♠ ❞❡✜♥✐t✐♦♥ t♦ s✉♣♣♦rt ♣❡r✲ s✐st❡♥❝❡ ♠♦❞❡❧✐♥❣✑ ✐s ♣r❡s❡♥t❡❞✳ ❚❤✐s ♣r♦✜❧❡ ✐s ✐♥t❡♥❞❡❞ t♦ ♠❛❦❡ ♦❜❥❡❝ts ♣❡rs✐s✲ t❡♥t ✐♥ ❞✐✛❡r❡♥t st♦r❛❣❡s✿ ✜❧❡s✱ r❡❧❛t✐♦♥❛❧ ❞❛t❛❜❛s❡s✱ ♦❜❥❡❝t✲r❡❧❛t✐♦♥❛❧ ❞❛t❛❜❛s❡s✱ ❡t❝✳ ■♥ ❬✶✷❪✱ t❤❡ ❉❛t❛ ▼♦❞❡❧✐♥❣ ♣r♦✜❧❡ ❢♦r t❤❡ ❯▼▲ ✐s ❞❡s❝r✐❜❡❞✱ ✏✳✳✳✐♥❝❧✉❞✐♥❣ ❞❡✲ s❝r✐♣t✐♦♥s ❛♥❞ ❡①❛♠♣❧❡s ❢♦r ❡❛❝❤ ❝♦♥❝❡♣t ✐♥❝❧✉❞✐♥❣ ❞❛t❛❜❛s❡✱ s❝❤❡♠❛✱ t❛❜❧❡✱ ❦❡②✱ ✐♥❞❡①✱ r❡❧❛t✐♦♥s❤✐♣✱ ❝♦❧✉♠♥✱ ❝♦♥str❛✐♥t ❛♥❞ tr✐❣❣❡r✑✳ ■♥ ❬✶✵❪✱ t❤❡ ♣r♦❝❡ss ♦❢ ❯▼▲✲ ❜❛s❡❞ ❞❛t❛❜❛s❡ ♠♦❞❡❧✐♥❣ ❛♥❞ ❞❡s✐❣♥ ✐s ❡①♣❧❛✐♥❡❞✿ ✐t ♣r❡s❡♥ts t❤❡ ❯▼▲ Pr♦✜❧❡

292

Sergio Luj´an-Mora et al.

❢♦r ❉❛t❛❜❛s❡ ❉❡s✐❣♥ ❝r❡❛t❡❞ ❜② ❘❛t✐♦♥❛❧ ❙♦❢t✇❛r❡ ❈♦r♣♦r❛t✐♦♥✳ ❋✐♥❛❧❧②✱ ✐♥ ❬✶✸❪ ❛♥ ❖❜❥❡❝t✲❘❡❧❛t✐♦♥❛❧ ❉❛t❛❜❛s❡ ❉❡s✐❣♥ ▼❡t❤♦❞♦❧♦❣② ✐s ♣r❡s❡♥t❡❞✳ ❚❤❡ ♠❡t❤♦❞✲ ♦❧♦❣② ❞❡✜♥❡s ♥❡✇ ❯▼▲ st❡r❡♦t②♣❡s ❢♦r ❖❜❥❡❝t✲❘❡❧❛t✐♦♥❛❧ ❉❛t❛❜❛s❡ ❉❡s✐❣♥ ❛♥❞ ♣r♦♣♦s❡s s♦♠❡ ❣✉✐❞❡❧✐♥❡s t♦ tr❛♥s❧❛t❡ ❛ ❯▼▲ s❝❤❡♠❛ ✐♥t♦ ❛♥ ♦❜❥❡❝t✲r❡❧❛t✐♦♥❛❧ s❝❤❡♠❛✳ ❍♦✇❡✈❡r✱ t❤❡s❡ ♣r♦♣♦s❛❧s ❞♦ ♥♦t r❡✢❡❝t t❤❡ ♣❡❝✉❧✐❛r✐t✐❡s ♦❢ ▼❉ ♠♦❞❡❧✲ ✐♥❣✳ ❚❤❡r❡❢♦r❡✱ ✐♥ t❤✐s ♣❛♣❡r ✇❡ ♣r❡s❡♥t ❛ ♣r♦♣♦s❛❧ t♦ ❡①t❡♥❞ t❤❡ ❯▼▲ ❢♦r ▼❉ ♠♦❞❡❧✐♥❣✳ ✸

❖❜❥❡❝t✲❖r✐❡♥t❡❞ ▼✉❧t✐❞✐♠❡♥s✐♦♥❛❧ ▼♦❞❡❧✐♥❣

■♥ t❤✐s s❡❝t✐♦♥✱ ✇❡ s✉♠♠❛r✐③❡✸ ❤♦✇ ❛♥ ❖❖ ▼❉ ♠♦❞❡❧✱ ❜❛s❡❞ ♦♥ t❤❡ ❯▼▲✱ ❝❛♥ r❡♣r❡s❡♥t ♠❛✐♥ str✉❝t✉r❛❧ ❛♥❞ ❞②♥❛♠✐❝ ▼❉ ♣r♦♣❡rt✐❡s ❛t t❤❡ ❝♦♥❝❡♣t✉❛❧ ❧❡✈❡❧✳ ▼♦st ♦❢ t❤❡ ▼❉ ❢❡❛t✉r❡s ❝♦♥s✐❞❡r❡❞ ❜② t❤✐s ❛♣♣r♦❛❝❤ s✉❝❤ ❛s t❤❡ ♠❛♥②✲t♦✲ ♠❛♥② r❡❧❛t✐♦♥s❤✐♣s ❜❡t✇❡❡♥ ❢❛❝ts ❛♥❞ ❞✐♠❡♥s✐♦♥s✱ ❞❡❣❡♥❡r❛t❡ ❞✐♠❡♥s✐♦♥s✱ ♠✉❧✲ t✐♣❧❡ ❛♥❞ ❛❧t❡r♥❛t✐✈❡ ♣❛t❤ ❝❧❛ss✐✜❝❛t✐♦♥ ❤✐❡r❛r❝❤✐❡s✱ ❛♥❞ ♥♦♥✲str✐❝t ❛♥❞ ❝♦♠♣❧❡t❡ ❤✐❡r❛r❝❤✐❡s ❛r❡ ♠✐s✐♥t❡r♣r❡t❡❞ ❜② ♠♦st ♦❢ t❤❡ ❝♦♥❝❡♣t✉❛❧ ▼❉ ♠♦❞❡❧s✳ ■♥ t❤❡ ❛♣♣r♦❛❝❤ ♣r♦♣♦s❡❞ ✐♥ t❤✐s ♣❛♣❡r✱ t❤❡ ♠❛✐♥ str✉❝t✉r❛❧ ♣r♦♣❡rt✐❡s ♦❢ ▼❉ ♠♦❞❡❧✲ ✐♥❣ ❛r❡ s♣❡❝✐✜❡❞ ❜② ♠❡❛♥s ♦❢ ❛ ❯▼▲ ❝❧❛ss ❞✐❛❣r❛♠ ✐♥ ✇❤✐❝❤ t❤❡ ✐♥❢♦r♠❛t✐♦♥ ✐s ❝❧❡❛r❧② s❡♣❛r❛t❡❞ ✐♥t♦ ❢❛❝ts ❛♥❞ ❞✐♠❡♥s✐♦♥s✹ ✳ ❋❛❝ts ❛♥❞ ❞✐♠❡♥s✐♦♥s ❛r❡ r❡♣r❡s❡♥t❡❞ ❜② ❢❛❝t ❝❧❛ss❡s ❛♥❞ ❞✐♠❡♥s✐♦♥ ❝❧❛ss❡s✱ r❡s♣❡❝t✐✈❡❧②✳ ❚❤❡♥✱ ❢❛❝t ❝❧❛ss❡s ❛r❡ s♣❡❝✐✜❡❞ ❛s ❝♦♠♣♦s✐t❡ ❝❧❛ss❡s ✐♥ s❤❛r❡❞ ❛❣❣r❡✲ ❣❛t✐♦♥ r❡❧❛t✐♦♥s❤✐♣s ♦❢ ♥ ❞✐♠❡♥s✐♦♥ ❝❧❛ss❡s✳ ❚❤❡ ✢❡①✐❜✐❧✐t② ♦❢ s❤❛r❡❞ ❛❣❣r❡❣❛t✐♦♥ ✐♥ t❤❡ ❯▼▲ ❛❧❧♦✇s ✉s t♦ r❡♣r❡s❡♥t ♠❛♥②✲t♦✲♠❛♥② r❡❧❛t✐♦♥s❤✐♣s ❜❡t✇❡❡♥ ❢❛❝ts ❛♥❞ ♣❛rt✐❝✉❧❛r ❞✐♠❡♥s✐♦♥s ❜② ✐♥❞✐❝❛t✐♥❣ t❤❡ ✶✳✳✯ ❝❛r❞✐♥❛❧✐t② ♦♥ t❤❡ ❞✐♠❡♥s✐♦♥ ❝❧❛ss r♦❧❡✳ ❋♦r ❡①❛♠♣❧❡✱ ✐♥ ❋✐❣✳ ✶ ✭❛✮✱ ✇❡ ❝❛♥ s❡❡ ❤♦✇ t❤❡ ❢❛❝t ❝❧❛ss ❙❛❧❡s ❤❛s ❛ ♠❛♥②✲t♦✲♠❛♥② r❡❧❛t✐♦♥s❤✐♣ ✇✐t❤ t❤❡ ❞✐♠❡♥s✐♦♥ ❝❧❛ss Pr♦❞✉❝t ❛♥❞ ❛ ♦♥❡✲t♦✲♠❛♥② r❡❧❛t✐♦♥s❤✐♣ ✇✐t❤ t❤❡ ❞✐♠❡♥s✐♦♥ ❝❧❛ss ❚✐♠❡✳ ❇② ❞❡❢❛✉❧t✱ ❛❧❧ ♠❡❛s✉r❡s ✐♥ t❤❡ ❢❛❝t ❝❧❛ss ❛r❡ ❝♦♥s✐❞❡r❡❞ ❛❞❞✐t✐✈❡✳ ❋♦r ♥♦♥❛❞✲ ❞✐t✐✈❡ ♠❡❛s✉r❡s✱ ❛❞❞✐t✐✈✐t② r✉❧❡s ❛r❡ ❞❡✜♥❡❞ ❛s ❝♦♥str❛✐♥ts ❛♥❞ ❛r❡ ✐♥❝❧✉❞❡❞ ✐♥ t❤❡ ❢❛❝t ❝❧❛ss✳ ❋✉rt❤❡r♠♦r❡✱ ❞❡r✐✈❡❞ ♠❡❛s✉r❡s ❝❛♥ ❛❧s♦ ❜❡ ❡①♣❧✐❝✐t❧② ❝♦♥s✐❞❡r❡❞ ✭✐♥❞✐❝❛t❡❞ ❜② ✴ ✮ ❛♥❞ t❤❡✐r ❞❡r✐✈❛t✐♦♥ r✉❧❡s ❛r❡ ♣❧❛❝❡❞ ❜❡t✇❡❡♥ ❜r❛❝❡s ♥❡❛r t❤❡ ❢❛❝t ❝❧❛ss✱ ❛s s❤♦✇♥ ✐♥ ❋✐❣✳ ✶ ✭❛✮✳ ❚❤✐s ❖❖ ❛♣♣r♦❛❝❤ ❛❧s♦ ❛❧❧♦✇s ✉s t♦ ❞❡✜♥❡ ✐❞❡♥t✐❢②✐♥❣ ❛ttr✐❜✉t❡s ✐♥ t❤❡ ❢❛❝t ❝❧❛ss✱ ❜② ♣❧❛❝✐♥❣ t❤❡ ❝♦♥str❛✐♥t ④❖■❉⑥ ♥❡①t t♦ ❛♥ ❛ttr✐❜✉t❡ ♥❛♠❡✳ ■♥ t❤✐s ✇❛② ✇❡ ❝❛♥ r❡♣r❡s❡♥t ❞❡❣❡♥❡r❛t❡ ❞✐♠❡♥s✐♦♥s ❬✶✹❪❬✶✺❪✱ t❤❡r❡❜② ♣r♦✈✐❞✐♥❣ ♦t❤❡r ❢❛❝t ❢❡❛t✉r❡s ✐♥ ❛❞❞✐t✐♦♥ t♦ t❤❡ ♠❡❛s✉r❡s ❢♦r ❛♥❛❧②s✐s✳ ❋♦r ❡①❛♠♣❧❡✱ ✇❡ ❝♦✉❧❞ st♦r❡ t❤❡ t✐❝❦❡t ♥✉♠❜❡r ✭t✐❝❦❡t❴♥✉♠❜❡r✮ ❛s ❛ ❞❡❣❡♥❡r❛t❡ ❞✐♠❡♥s✐♦♥✱ ❛s r❡✢❡❝t❡❞ ✐♥ ❋✐❣✳ ✶ ✭❛✮✳ ❲✐t❤ r❡s♣❡❝t t♦ ❞✐♠❡♥s✐♦♥s✱ ❡✈❡r② ❝❧❛ss✐✜❝❛t✐♦♥ ❤✐❡r❛r❝❤② ✭❋✐❣✳ ✶ ✭❜✮✮ ❧❡✈❡❧ ✐s s♣❡❝✐✜❡❞ ❜② ❛ ❝❧❛ss ✭❝❛❧❧❡❞ ❛ ❜❛s❡ ❝❧❛ss ✮✳ ❆♥ ❛ss♦❝✐❛t✐♦♥ ♦❢ ❝❧❛ss❡s s♣❡❝✐✜❡s t❤❡ r❡❧❛t✐♦♥s❤✐♣s ❜❡t✇❡❡♥ t✇♦ ❧❡✈❡❧s ♦❢ ❛ ❝❧❛ss✐✜❝❛t✐♦♥ ❤✐❡r❛r❝❤②✳ ❚❤❡ ♦♥❧② ♣r❡r❡q✲ ✉✐s✐t❡ ✐s t❤❛t t❤❡s❡ ❝❧❛ss❡s ♠✉st ❞❡✜♥❡ ❛ ❉✐r❡❝t❡❞ ❆❝②❝❧✐❝ ●r❛♣❤ ✭❉❆●✮ r♦♦t❡❞ ✐♥ t❤❡ ❞✐♠❡♥s✐♦♥ ❝❧❛ss ✭❝♦♥str❛✐♥t ④❞❛❣⑥ ♣❧❛❝❡❞ ♥❡①t t♦ ❡✈❡r② ❞✐♠❡♥s✐♦♥ ❝❧❛ss✮✳ ✸ ✹

❲❡ r❡❢❡r t❤❡ r❡❛❞❡r t♦ ❬✺❪ ❢♦r ❛ ❝♦♠♣❧❡t❡ ❞❡s❝r✐♣t✐♦♥ ♦❢ t❤✐s ❛♣♣r♦❛❝❤✳ ■t ✐s ♥♦t t❤❡ s❝♦♣❡ ♦❢ t❤✐s ♣❛♣❡r t♦ ❝♦♥s✐❞❡r ❞②♥❛♠✐❝ ▼❉ ♣r♦♣❡rt✐❡s✳

Extending the UML for Multidimensional Modeling

293

❋✐❣✳ ✶✳ ▼✉❧t✐❞✐♠❡♥s✐♦♥❛❧ ♠♦❞❡❧✐♥❣ ✉s✐♥❣ t❤❡ ❯▼▲

❚❤❡ ❉❆● str✉❝t✉r❡ ❝❛♥ r❡♣r❡s❡♥t ❜♦t❤ ❛❧t❡r♥❛t✐✈❡ ♣❛t❤ ❛♥❞ ♠✉❧t✐♣❧❡ ❝❧❛ss✐✜❝❛✲ t✐♦♥ ❤✐❡r❛r❝❤✐❡s✳ ❊✈❡r② ❝❧❛ss✐✜❝❛t✐♦♥ ❤✐❡r❛r❝❤② ❧❡✈❡❧ ♠✉st ❤❛✈❡ ❛♥ ✐❞❡♥t✐❢②✐♥❣ ❛t✲ tr✐❜✉t❡ ✭❝♦♥str❛✐♥t ④❖■❉⑥✮ ❛♥❞ ❛ ❞❡s❝r✐♣t♦r ❛ttr✐❜✉t❡✺ ✭❝♦♥str❛✐♥t ④❉⑥✮✳ ❚❤❡s❡ ❛ttr✐❜✉t❡s ❛r❡ ♥❡❝❡ss❛r② ❢♦r ❛♥ ❛✉t♦♠❛t✐❝ ❣❡♥❡r❛t✐♦♥ ♣r♦❝❡ss ✐♥t♦ ❝♦♠♠❡r❝✐❛❧ r❡❧❛t✐♦♥❛❧ ❖▲❆P ✭❘❖▲❆P✮ t♦♦❧s✱ ❛s t❤❡s❡ t♦♦❧s ♥❡❡❞ t♦ st♦r❡ t❤❡s❡ ❛ttr✐❜✉t❡s ✐♥ t❤❡✐r ♠❡t❛❞❛t❛✳ ❚❤❡ ♠✉❧t✐♣❧✐❝✐t② ✶ ❛♥❞ ✶✳✳✯ ❞❡✜♥❡❞ ✐♥ t❤❡ t❛r❣❡t ❛ss♦❝✐❛t❡❞ ❝❧❛ss r♦❧❡ ❛❞❞r❡ss❡s t❤❡ ❝♦♥❝❡♣ts ♦❢ str✐❝t♥❡ss ❛♥❞ ♥♦♥✲str✐❝t♥❡ss r❡s♣❡❝t✐✈❡❧②✳ ❙tr✐❝t♥❡ss ♠❡❛♥s t❤❛t ❛♥ ♦❜❥❡❝t ❛t ❛ ❤✐❡r❛r❝❤②✬s ❧♦✇❡r ❧❡✈❡❧ ❜❡❧♦♥❣s t♦ ♦♥❧② ♦♥❡ ❤✐❣❤❡r✲❧❡✈❡❧ ♦❜❥❡❝t ✭❡✳❣✳✱ ❛s ♦♥❡ ♠♦♥t❤ ❝❛♥ ❜❡ r❡❧❛t❡❞ t♦ ♠♦r❡ t❤❛♥ ♦♥❡ s❡❛✲ s♦♥✱ t❤❡ r❡❧❛t✐♦♥s❤✐♣ ❜❡t✇❡❡♥ ❜♦t❤ ♦❢ t❤❡♠ ✐s ♥♦♥✲str✐❝t✮✳ ▼♦r❡♦✈❡r✱ ❞❡✜♥✐♥❣ t❤❡ ④❝♦♠♣❧❡t❡♥❡ss⑥ ❝♦♥str❛✐♥t ✐♥ t❤❡ t❛r❣❡t ❛ss♦❝✐❛t❡❞ ❝❧❛ss r♦❧❡ ❛❞❞r❡ss❡s t❤❡ ❝♦♠♣❧❡t❡♥❡ss ♦❢ ❛ ❝❧❛ss✐✜❝❛t✐♦♥ ❤✐❡r❛r❝❤② ✭s❡❡ ❛♥ ❡①❛♠♣❧❡ ✐♥ ❋✐❣✳ ✶ ✭❜✮✮✳ ❇② ❝♦♠✲ ♣❧❡t❡♥❡ss ✇❡ ♠❡❛♥ t❤❛t ❛❧❧ ♠❡♠❜❡rs ❜❡❧♦♥❣ t♦ ♦♥❡ ❤✐❣❤❡r✲❝❧❛ss ♦❜❥❡❝t ❛♥❞ t❤❛t ♦❜❥❡❝t ❝♦♥s✐sts ♦❢ t❤♦s❡ ♠❡♠❜❡rs ♦♥❧②✳ ❋♦r ❡①❛♠♣❧❡✱ ❛❧❧ t❤❡ r❡❝♦r❞❡❞ s❡❛s♦♥s ❢♦r♠ ❛ ②❡❛r✱ ❛♥❞ ❛❧❧ t❤❡ s❡❛s♦♥s t❤❛t ❢♦r♠ t❤❡ ②❡❛r ❤❛✈❡ ❜❡❡♥ r❡❝♦r❞❡❞✳ ❖✉r ❛♣♣r♦❛❝❤ ❛ss✉♠❡s ❛❧❧ ❝❧❛ss✐✜❝❛t✐♦♥ ❤✐❡r❛r❝❤✐❡s ❛r❡ ♥♦♥✲❝♦♠♣❧❡t❡ ❜② ❞❡❢❛✉❧t✳ ❚❤❡ ❝❛t❡❣♦r✐③❛t✐♦♥ ♦❢ ❞✐♠❡♥s✐♦♥s✱ ✉s❡❞ t♦ ♠♦❞❡❧ ❛❞❞✐t✐♦♥❛❧ ❢❡❛t✉r❡s ❢♦r ❝❧❛ss✬s s✉❜t②♣❡s✱ ✐s ❝♦♥s✐❞❡r❡❞ ❜② ♠❡❛♥s ♦❢ ❣❡♥❡r❛❧✐③❛t✐♦♥✲s♣❡❝✐❛❧✐③❛t✐♦♥ r❡❧❛t✐♦♥s❤✐♣s✳ ❍♦✇❡✈❡r✱ ♦♥❧② t❤❡ ❞✐♠❡♥s✐♦♥ ❝❧❛ss ❝❛♥ ❜❡❧♦♥❣ t♦ ❜♦t❤ ❛ ❝❧❛ss✐✜❝❛t✐♦♥ ❛♥❞ s♣❡❝✐❛❧✲ ✐③❛t✐♦♥ ❤✐❡r❛r❝❤② ❛t t❤❡ s❛♠❡ t✐♠❡✳ ❆♥ ❡①❛♠♣❧❡ ♦❢ ❝❛t❡❣♦r✐③❛t✐♦♥ ❢♦r t❤❡ Pr♦❞✉❝t ❞✐♠❡♥s✐♦♥ ❝❛♥ ❜❡ ♦❜s❡r✈❡❞ ✐♥ ❋✐❣✳ ✶ ✭❝✮✳

✹

❯▼▲ ❊①t❡♥s✐❜✐❧✐t② ▼❡❝❤❛♥✐s♠

❚❤❡ ❯▼▲ ❊①t❡♥s✐❜✐❧✐t② ▼❡❝❤❛♥✐s♠ ♣❛❝❦❛❣❡ ✐s t❤❡ s✉❜♣❛❝❦❛❣❡ ❢r♦♠ t❤❡ ❯▼▲ ♠❡t❛♠♦❞❡❧ t❤❛t s♣❡❝✐✜❡s ❤♦✇ s♣❡❝✐✜❝ ❯▼▲ ♠♦❞❡❧ ❡❧❡♠❡♥ts ❛r❡ ❝✉st♦♠✐③❡❞ ❛♥❞ ❡①t❡♥❞❡❞ ✇✐t❤ ♥❡✇ s❡♠❛♥t✐❝s ❜② ✉s✐♥❣ st❡r❡♦t②♣❡s✱ t❛❣❣❡❞ ✈❛❧✉❡s✱ ❛♥❞ ❝♦♥✲ str❛✐♥ts✳ ❆ ❝♦❤❡r❡♥t s❡t ♦❢ s✉❝❤ ❡①t❡♥s✐♦♥s✱ ❞❡✜♥❡❞ ❢♦r s♣❡❝✐✜❝ ♣✉r♣♦s❡s✱ ❝♦♥✲ st✐t✉t❡s ❛ ❯▼▲ ♣r♦✜❧❡✳ ❋♦r ❡①❛♠♣❧❡✱ t❤❡ ❯▼▲ ✶✳✹ ❬✽❪ ✐♥❝❧✉❞❡s ❛ st❛♥❞❛r❞ ♣r♦✜❧❡ ✺

❆ ❞❡s❝r✐♣t♦r ❛ttr✐❜✉t❡ ✇✐❧❧ ❜❡ ✉s❡❞ ❛s t❤❡ ❞❡❢❛✉❧t ❧❛❜❡❧ ✐♥ t❤❡ ❞❛t❛ ❛♥❛❧②s✐s✳

294

Sergio Luj´an-Mora et al.

❢♦r ♠♦❞❡❧✐♥❣ s♦❢t✇❛r❡ ❞❡✈❡❧♦♣♠❡♥t ♣r♦❝❡ss❡s ❛♥❞ ❛♥♦t❤❡r ♦♥❡ ❢♦r ❜✉s✐♥❡ss ♠♦❞✲ ❡❧✐♥❣✳ ❆

st❡r❡♦t②♣❡

✐s ❛ ♠♦❞❡❧ ❡❧❡♠❡♥t t❤❛t ❞❡✜♥❡s ❛❞❞✐t✐♦♥❛❧ ✈❛❧✉❡s ✭❜❛s❡❞ ♦♥

t❛❣❣❡❞ ✈❛❧✉❡s✮✱ ❛❞❞✐t✐♦♥❛❧ ❝♦♥str❛✐♥ts✱ ❛♥❞ ♦♣t✐♦♥❛❧❧② ❛ ♥❡✇ ❣r❛♣❤✐❝❛❧ r❡♣r❡s❡♥✲ t❛t✐♦♥ ✭❛♥ ✐❝♦♥✮✿ ❛ st❡r❡♦t②♣❡ ❛❧❧♦✇s ✉s t♦ ❛tt❛❝❤ ❛ ♥❡✇ s❡♠❛♥t✐❝ ♠❡❛♥✐♥❣ t♦ ❛ ♠♦❞❡❧ ❡❧❡♠❡♥t✳ ❆ st❡r❡♦t②♣❡ ✐s ❡✐t❤❡r r❡♣r❡s❡♥t❡❞ ❛s ❛ str✐♥❣ ❜❡t✇❡❡♥ ❛ ♣❛✐r ♦❢ ❣✉✐❧❧❡♠♦ts ✭≪ ❆

≫ ✮ ♦r r❡♥❞❡r❡❞ ❛s t❛❣❣❡❞ ✈❛❧✉❡ s♣❡❝✐✜❡s ❛ ♥❡✇

❛ ♥❡✇ ✐❝♦♥✳ ❦✐♥❞ ♦❢ ♣r♦♣❡rt② t❤❛t ♠❛② ❜❡ ❛tt❛❝❤❡❞ t♦ ❛

♠♦❞❡❧ ❡❧❡♠❡♥t✳ ❆ t❛❣❣❡❞ ✈❛❧✉❡ ✐s r❡♥❞❡r❡❞ ❛s ❛ str✐♥❣ ❡♥❝❧♦s❡❞ ❜② ❜r❛❝❦❡ts ✭❬ ❪✮ ❛♥❞ ♣❧❛❝❡❞ ❜❡❧♦✇ t❤❡ ♥❛♠❡ ♦❢ ❛♥♦t❤❡r ❡❧❡♠❡♥t✳ ❆

❝♦♥str❛✐♥t

❝❛♥ ❜❡ ❛tt❛❝❤❡❞ t♦ ❛♥② ♠♦❞❡❧ ❡❧❡♠❡♥t t♦ r❡✜♥❡ ✐ts s❡♠❛♥t✐❝s✳

❆s ✐t ✐s st❛t❡❞ ✐♥ ❬✶✻❪✱ ✏❆ ❝♦♥str❛✐♥t ✐s ❛ r❡str✐❝t✐♦♥ ♦♥ ♦♥❡ ♦r ♠♦r❡ ✈❛❧✉❡s ♦❢ ✭♣❛rt ♦❢ ✮ ❛♥ ♦❜❥❡❝t✲♦r✐❡♥t❡❞ ♠♦❞❡❧ ♦r s②st❡♠✑✳ ■♥ t❤❡ ❯▼▲✱ ❛ ❝♦♥str❛✐♥t ✐s r❡♥❞❡r❡❞ ❛s ❛ str✐♥❣ ❜❡t✇❡❡♥ ❛ ♣❛✐r ♦❢ ❜r❛❝❡s ✭④ ⑥✮ ❛♥❞ ♣❧❛❝❡❞ ♥❡❛r t❤❡ ❛ss♦❝✐❛t❡❞ ♠♦❞❡❧ ❡❧❡♠❡♥t✳ ❆ ❝♦♥str❛✐♥t ♦♥ ❛ st❡r❡♦t②♣❡ ✐s ✐♥t❡r♣r❡t❡❞ ❛s ❛ ❝♦♥str❛✐♥t ♦♥ ❛❧❧ t②♣❡s ♦♥ ✇❤✐❝❤ t❤❡ st❡r❡♦t②♣❡ ✐s ❛♣♣❧✐❡❞✳ ❆ ❝♦♥str❛✐♥t ❝❛♥ ❜❡ ❞❡✜♥❡❞ ❜② ♠❡❛♥s ♦❢ ❛♥ ✐♥❢♦r♠❛❧ ❡①♣❧❛♥❛t✐♦♥ ♦r ❜② ♠❡❛♥s ♦❢ ❖❈▲ ❬✶✻❪❬✽❪ ❡①♣r❡ss✐♦♥s✳ ❚❤❡ ❖❈▲ ✐s ❛ ❞❡❝❧❛r❛t✐✈❡ ❧❛♥❣✉❛❣❡ t❤❛t ❛❧❧♦✇s s♦❢t✇❛r❡ ❞❡✈❡❧♦♣❡rs t♦ ✇r✐t❡ ❝♦♥str❛✐♥ts ♦✈❡r ♦❜❥❡❝t ♠♦❞❡❧s✳

✺

❯▼▲ ❊①t❡♥s✐♦♥ ❢♦r ▼✉❧t✐❞✐♠❡♥s✐♦♥❛❧ ▼♦❞❡❧✐♥❣

❆❝❝♦r❞✐♥❣ t♦ ❬✾❪✱ ✏❆♥ ❡①t❡♥s✐♦♥ t♦ t❤❡ ❯▼▲ ❜❡❣✐♥s ✇✐t❤ ❛ ❜r✐❡❢ ❞❡s❝r✐♣t✐♦♥ ❛♥❞ t❤❡♥ ❧✐sts ❛♥❞ ❞❡s❝r✐❜❡s ❛❧❧ ♦❢ t❤❡ st❡r❡♦t②♣❡s✱ t❛❣❣❡❞ ✈❛❧✉❡s✱ ❛♥❞ ❝♦♥str❛✐♥ts ♦❢ t❤❡ ❡①t❡♥s✐♦♥✳ ■♥ ❛❞❞✐t✐♦♥ t♦ t❤❡s❡ ❡❧❡♠❡♥ts✱ ❛♥ ❡①t❡♥s✐♦♥ ❝♦♥t❛✐♥s ❛ s❡t ♦❢ ✇❡❧❧✲❢♦r♠❡❞♥❡ss r✉❧❡s✳ ❚❤❡s❡ r✉❧❡s ❛r❡ ✉s❡❞ t♦ ❞❡t❡r♠✐♥❡ ✇❤❡t❤❡r ❛ ♠♦❞❡❧ ✐s s❡♠❛♥t✐❝❛❧❧② ❝♦♥s✐st❡♥t ✇✐t❤ ✐ts❡❧❢ ✑✳ ❆❝❝♦r❞✐♥❣ t♦ t❤✐s q✉♦t❡✱ ✇❡ ❞❡✜♥❡ ♦✉r ❯▼▲ ❡①t❡♥s✐♦♥ ❢♦r ▼❉ ♠♦❞❡❧✐♥❣ ❢♦❧❧♦✇✐♥❣ t❤❡ s❝❤❡♠❛ s❤♦✇♥ ✐♥ ❚❛❜❧❡ ✶✳

✕ ❉❡s❝r✐♣t✐♦♥✿ ❆ ❧✐tt❧❡ ❞❡s❝r✐♣t✐♦♥ ♦❢ t❤❡ ❡①t❡♥s✐♦♥ ✐♥ ♥❛t✉r❛❧ ❧❛♥❣✉❛❣❡✳ ✕ Pr❡r❡q✉✐s✐t❡ ❊①t❡♥s✐♦♥s✿ ■t ✐♥❞✐❝❛t❡s ✇❤❡t❤❡r t❤❡ ❝✉rr❡♥t ❡①t❡♥s✐♦♥ ♥❡❡❞s t❤❡ ❡①✲ ✐st❡♥❝❡ ♦❢ ♣r❡✈✐♦✉s ❡①t❡♥s✐♦♥s✳ ✕ ❙t❡r❡♦t②♣❡s✿ ❚❤❡ ❞❡✜♥✐t✐♦♥ ♦❢ t❤❡ st❡r❡♦t②♣❡s✳ ✕ ❲❡❧❧✲❋♦r♠❡❞♥❡ss ❘✉❧❡s✿ ❚❤❡ st❛t✐❝ s❡♠❛♥t✐❝s ♦❢ t❤❡ ♠❡t❛❝❧❛ss❡s ❛r❡ ❞❡✜♥❡❞ ❛s ❛ s❡t ♦❢ ✐♥✈❛r✐❛♥ts ❞❡✜♥❡❞ ❜② ♠❡❛♥s ♦❢ ❖❈▲ ❡①♣r❡ss✐♦♥s✳ ✕ ❈♦♠♠❡♥ts✿ ❆♥② ❛❞❞✐t✐♦♥❛❧ ❝♦♠♠❡♥t✱ ❞❡❝✐s✐♦♥ ♦r ❡①❛♠♣❧❡✱ ✉s✉❛❧❧② ✇r✐tt❡♥ ✐♥ ♥❛t✉r❛❧ ❧❛♥❣✉❛❣❡✳

❚❛❜❧❡ ✶✳

❊①t❡♥s✐♦♥ ❞❡✜♥✐t✐♦♥ s❝❤❡♠❛

❋♦r t❤❡ ❞❡✜♥✐t✐♦♥ ♦❢ t❤❡ st❡r❡♦t②♣❡s ❛♥❞ t❤❡ t❛❣❣❡❞ ✈❛❧✉❡s✱ ✇❡ ❢♦❧❧♦✇ t❤❡ str✉❝t✉r❡ ♦❢ t❤❡ ❡①❛♠♣❧❡s ✐♥❝❧✉❞❡❞ ✐♥ t❤❡ ❯▼▲ ❙♣❡❝✐✜❝❛t✐♦♥ ❬✽❪✳ ■♥ ❚❛❜❧❡ ✷ ❛♥❞ ❚❛❜❧❡ ✸ ✇❡ s❤♦✇ t❤❡ s❝❤❡♠❛s ❢♦❧❧♦✇❡❞ ✐♥ ♦✉r ❞❡✜♥✐t✐♦♥ ♦❢ t❤❡ st❡r❡♦t②♣❡s ❛♥❞ t❤❡ t❛❣❣❡❞ ✈❛❧✉❡s✱ r❡s♣❡❝t✐✈❡❧②✳ ❲❡ ❤❛✈❡ ❞❡✜♥❡❞ ❡✐❣❤t st❡r❡♦t②♣❡s✿ t❤r❡❡ s♣❡❝✐❛❧✐③❡ ✐♥ t❤❡ ❈❧❛ss ♠♦❞❡❧ ❡❧❡✲ ♠❡♥t✱ ❢♦✉r s♣❡❝✐❛❧✐③❡ ✐♥ t❤❡ ❆ttr✐❜✉t❡ ♠♦❞❡❧ ❡❧❡♠❡♥t✱ ❛♥❞ ♦♥❡ s♣❡❝✐❛❧✐③❡s ✐♥ t❤❡

Extending the UML for Multidimensional Modeling

295

✕ ◆❛♠❡✿ ❚❤❡ ♥❛♠❡ ♦❢ t❤❡ st❡r❡♦t②♣❡✳ ✕ ❇❛s❡ ❝❧❛ss ✭❛❧s♦ ❝❛❧❧❡❞ ▼♦❞❡❧ ❝❧❛ss✮✿ ❚❤❡ ❯▼▲ ♠❡t❛♠♦❞❡❧ ❡❧❡♠❡♥t t❤❛t s❡r✈❡s ❛s t❤❡ ❜❛s❡ ❢♦r t❤❡ st❡r❡♦t②♣❡✳ ✕ ❉❡s❝r✐♣t✐♦♥✿ ❆♥ ✐♥❢♦r♠❛❧ ❞❡s❝r✐♣t✐♦♥ ✇✐t❤ ♣♦ss✐❜❧❡ ❡①♣❧❛♥❛t♦r② ❝♦♠♠❡♥ts✳ ✕ ■❝♦♥✿ ■t ✐s ♣♦ss✐❜❧❡ t♦ ❞❡✜♥❡ ❛ ❞✐st✐♥❝t✐✈❡ ✈✐s✉❛❧ ❝✉❡ ✭❛♥ ✐❝♦♥✮✳ ✕ ❈♦♥str❛✐♥ts✿ ❆ ❧✐st ♦❢ ❝♦♥str❛✐♥ts ❞❡✜♥❡❞ ❜② ♠❡❛♥s ♦❢ ❖❈▲ ❡①♣r❡ss✐♦♥s ❛ss♦❝✐❛t❡❞ ✇✐t❤ t❤❡ st❡r❡♦t②♣❡✱ ✇✐t❤ ❛♥ ✐♥❢♦r♠❛❧ ❡①♣❧❛♥❛t✐♦♥ ♦❢ t❤❡ ❡①♣r❡ss✐♦♥s✳ ✕ ❚❛❣❣❡❞ ✈❛❧✉❡s✿ ❆ ❧✐st ♦❢ ❛❧❧ t❛❣❣❡❞ ✈❛❧✉❡s t❤❛t ❛r❡ ❛ss♦❝✐❛t❡❞ ✇✐t❤ t❤❡ st❡r❡♦t②♣❡✳

❚❛❜❧❡ ✷✳

❙t❡r❡♦t②♣❡ ❞❡✜♥✐t✐♦♥ s❝❤❡♠❛

✕ ◆❛♠❡✿ ❚❤❡ ♥❛♠❡ ♦❢ t❤❡ t❛❣❣❡❞ ✈❛❧✉❡✳ ✕ ❚②♣❡✿ ❚❤❡ ♥❛♠❡ ♦❢ t❤❡ t②♣❡ ♦❢ t❤❡ ✈❛❧✉❡s t❤❛t ❝❛♥ ❜❡ ❛ss♦❝✐❛t❡❞ ✇✐t❤ t❤❡ t❛❣❣❡❞ ✈❛❧✉❡✳ ✕ ▼✉❧t✐♣❧✐❝✐t②✿ ❚❤❡ ♠❛①✐♠✉♠ ♥✉♠❜❡r ♦❢ ✈❛❧✉❡s t❤❛t ♠❛② ❜❡ ❛ss♦❝✐❛t❡❞ ✇✐t❤ t❤❡ t❛❣❣❡❞ ✈❛❧✉❡✳ ✕ ❉❡s❝r✐♣t✐♦♥✿ ❆♥ ✐♥❢♦r♠❛❧ ❞❡s❝r✐♣t✐♦♥ ✇✐t❤ ♣♦ss✐❜❧❡ ❡①♣❧❛♥❛t♦r② ❝♦♠♠❡♥ts✳

❚❛❜❧❡ ✸✳

❚❛❣❣❡❞ ✈❛❧✉❡ ❞❡✜♥✐t✐♦♥ s❝❤❡♠❛

❆ss♦❝✐❛t✐♦♥ ♠♦❞❡❧ ❡❧❡♠❡♥t✳ ■♥ ❋✐❣✳ ✷✱ ✇❡ ❤❛✈❡ r❡♣r❡s❡♥t❡❞ ❛ ♣♦rt✐♦♥ ♦❢ t❤❡ ❯▼▲ ♠❡t❛♠♦❞❡❧✻ t♦ s❤♦✇ ✇❤❡r❡ ♦✉r st❡r❡♦t②♣❡s ✜t✳ ❙♦♠❡ ✐ss✉❡s ♦❢ ♦✉r ▼❉ ❛♣♣r♦❛❝❤✱ s✉❝❤ ❛s t❤❡ ❞❡r✐✈❛t✐♦♥ r✉❧❡ ♦r t❤❡ ✐♥✐t✐❛❧ ✈❛❧✉❡ ♦❢ ❛♥ ❛ttr✐❜✉t❡✱ ❛r❡ ♥♦t ❞❡✜♥❡❞ ✐♥ ♦✉r st❡r❡♦t②♣❡s ❜❡❝❛✉s❡ t❤❡s❡ ❝♦♥❝❡♣ts ❤❛✈❡ ❛❧r❡❛❞② ❜❡❡♥ ❞❡✜♥❡❞ ✐♥ t❤❡ ❯▼▲ ♠❡t❛♠♦❞❡❧✳ ❲❡ ♣r♦✈✐❞❡ ❛ ❧✐st ♦❢ t❤❡s❡ ❝♦♥❝❡♣ts ✐♥ ❚❛❜❧❡ ✹✳ ■♥ t❤❡ ❢♦❧❧♦✇✐♥❣✱ ✇❡ ♣r❡s❡♥t ♦✉r ❡①t❡♥s✐♦♥ ❢♦❧❧♦✇✐♥❣ t❤❡ ❡①t❡♥s✐♦♥ ❞❡✜♥✐t✐♦♥ s❝❤❡♠❛ s❤♦✇♥ ✐♥ ❚❛❜❧❡ ✶✳ ✻

❆❧❧ t❤❡ ♠❡t❛❝❧❛ss❡s ❝♦♠❡ ❢r♦♠ t❤❡ ❈♦r❡ P❛❝❦❛❣❡✱ ❛ s✉❜♣❛❝❦❛❣❡ ♦❢ t❤❡ ❋♦✉♥❞❛t✐♦♥

P❛❝❦❛❣❡✳

❋✐❣✳ ✷✳

❊①t❡♥s✐♦♥ ♦❢ t❤❡ ❯▼▲ ✇✐t❤ st❡r❡♦t②♣❡s

296

Sergio Luj´an-Mora et al.

❈♦♥❝❡♣t ♥❛♠❡

❈♦♠❡s ❢r♦♠ ❉❡s❝r✐♣t✐♦♥

❯s❡❞ ❜②

■t ✐s ❛♥ ✐❞❡♥t✐✜❡r ❢♦r t❤❡ ▼♦❞❡❧✲ ❇❛s❡✱ ❈♦♠♣❧❡t❡♥❡ss✱ ❊❧❡♠❡♥t ❉❡s❝r✐♣t♦r✱ ❉✐♠❡♥s✐♦♥✱ ❉✐♠❡♥s✐♦♥❆ttr✐❜✉t❡✱ ❋❛❝t✱ ❋❛❝t❆ttr✐❜✉t❡✱ ❖■❉ ❞♦❝✉♠❡♥t❛t✐♦♥ ❊❧❡♠❡♥t ■t ✐s ❛ ❝♦♠♠❡♥t✱ ❞❡s❝r✐♣t✐♦♥ ♦r ❇❛s❡✱ ❈♦♠♣❧❡t❡♥❡ss✱ ❡①♣❧❛♥❛t✐♦♥ ♦❢ t❤❡ ❊❧❡♠❡♥t t♦ ❉❡s❝r✐♣t♦r✱ ❉✐♠❡♥s✐♦♥✱ ✇❤✐❝❤ ✐t ✐s ❛tt❛❝❤❡❞ ❉✐♠❡♥s✐♦♥❆ttr✐❜✉t❡✱ ❋❛❝t✱ ❋❛❝t❆ttr✐❜✉t❡✱ ❖■❉ t②♣❡ ❙tr✉❝t✉r❛❧❋❡❛t✉r❡ ❉❡s✐❣♥❛t❡s t❤❡ ❝❧❛ss✐✜❡r ✇❤♦s❡ ❉❡s❝r✐♣t♦r✱ ❉✐♠❡♥s✐♦♥✲ ✐♥st❛♥❝❡s ❛r❡ ✈❛❧✉❡s ♦❢ t❤❡ ❢❡❛✲ ❆ttr✐❜✉t❡✱ ❋❛❝t✲ t✉r❡ ❆ttr✐❜✉t❡✱ ❖■❉ ✐♥✐t✐❛❧❱❛❧✉❡ ❆ttr✐❜✉t❡ ❆♥ ❡①♣r❡ss✐♦♥ s♣❡❝✐❢②✐♥❣ t❤❡ ❉❡s❝r✐♣t♦r✱ ❉✐♠❡♥s✐♦♥✲ ✈❛❧✉❡ ♦❢ t❤❡ ❆ttr✐❜✉t❡ ✉♣♦♥ ✐♥✐✲ ❆ttr✐❜✉t❡✱ ❋❛❝t✲ t✐❛❧✐③❛t✐♦♥ ❆ttr✐❜✉t❡✱ ❖■❉ ❞❡r✐✈❡❞ ▼♦❞❡❧❊❧❡♠❡♥t ❆ tr✉❡ ✈❛❧✉❡ ✐♥❞✐❝❛t❡s t❤❛t t❤❡ ❉❡s❝r✐♣t♦r✱ ❉✐♠❡♥s✐♦♥✲ ▼♦❞❡❧❊❧❡♠❡♥t ❝❛♥ ❜❡ ❝♦♠♣❧❡t❡❧② ❆ttr✐❜✉t❡✱ ❋❛❝t❆ttr✐❜✉t❡ ❞❡r✐✈❡❞ ❢r♦♠ ♦t❤❡r ♠♦❞❡❧ ❡❧❡✲ ♠❡♥ts ❛♥❞ ✐s t❤❡r❡❢♦r❡ ❧♦❣✐❝❛❧❧② r❡❞✉♥❞❛♥t ▼♦❞❡❧❊❧❡♠❡♥t

❚❛❜❧❡ ✹✳ ❈♦♥❝❡♣ts ✐♥❤❡r✐t❡❞ ❢r♦♠ t❤❡ ❯▼▲ ♠❡t❛♠♦❞❡❧ ✺✳✶

❉❡s❝r✐♣t✐♦♥

❚❤✐s ❡①t❡♥s✐♦♥ t♦ t❤❡ ❯▼▲ ❞❡✜♥❡s ❛ s❡t ♦❢ st❡r❡♦t②♣❡s✱ t❛❣❣❡❞ ✈❛❧✉❡s✱ ❛♥❞ ❝♦♥✲ str❛✐♥ts t❤❛t ❡♥❛❜❧❡ ✉s t♦ ♠♦❞❡❧ ▼❉ ♠♦❞❡❧s✳ ❚❤❡ st❡r❡♦t②♣❡s ❛r❡ ❛♣♣❧✐❡❞ t♦ ❝❡rt❛✐♥ ❝♦♠♣♦♥❡♥ts t❤❛t ❛r❡ ♣❛rt✐❝✉❧❛r t♦ ▼❉ ♠♦❞❡❧✐♥❣✱ ❛❧❧♦✇✐♥❣ ✉s t♦ r❡♣r❡✲ s❡♥t t❤❡♠ ✐♥ t❤❡ s❛♠❡ ♠♦❞❡❧ ❛♥❞ ♦♥ t❤❡ s❛♠❡ ❞✐❛❣r❛♠s t❤❛t ❞❡s❝r✐❜❡ t❤❡ r❡st ♦❢ t❤❡ s②st❡♠✳ ❚❤❡ ♣r✐♥❝✐♣❛❧ ❡❧❡♠❡♥ts t♦ ▼❉ ♠♦❞❡❧✐♥❣ ❛r❡ t❤❡ ❋❛❝t ❝❧❛ss ❛♥❞ t❤❡ ❉✐♠❡♥s✐♦♥ ❝❧❛ss✳ ❆ ❋❛❝t ❝❧❛ss ❝♦♥s✐sts ♦❢ ❖■❉s ❛♥❞ ❋❛❝t❆ttr✐❜✉t❡s✱ ✇❤❡r❡❛s ❛ ❉✐♠❡♥s✐♦♥ ❝❧❛ss ❝♦♥s✐sts ♦❢ ❛♥ ❖■❉✱ ❉❡s❝r✐♣t♦r✱ ❛♥❞ ❉✐♠❡♥s✐♦♥❆ttr✐❜✉t❡s✳ ▼♦r❡♦✈❡r✱ t❤❡ ❤✐❡r❛r❝❤② ❧❡✈❡❧s ♦❢ ❛ ❉✐♠❡♥s✐♦♥ ❛r❡ r❡♣r❡s❡♥t❡❞ ❜② ♠❡❛♥s ♦❢ ❇❛s❡ ❝❧❛ss❡s✳ ❋✐♥❛❧❧②✱ ❛ ❈♦♠♣❧❡t❡♥❡ss ❛ss♦❝✐❛t✐♦♥ ✐s ❞❡✜♥❡❞✳ ✺✳✷

Pr❡r❡q✉✐s✐t❡ ❊①t❡♥s✐♦♥s

◆♦ ♦t❤❡r ❡①t❡♥s✐♦♥ t♦ t❤❡ ❧❛♥❣✉❛❣❡ ✐s r❡q✉✐r❡❞ ❢♦r t❤❡ ❞❡✜♥✐t✐♦♥ ♦❢ t❤✐s ❡①t❡♥s✐♦♥✳ ✺✳✸

❙t❡r❡♦t②♣❡s

❙t❡r❡♦t②♣❡s ♦❢ ❈❧❛ss

✕ ✕ ✕ ✕ ✕

◆❛♠❡✿ ❋❛❝t ❇❛s❡ ❝❧❛ss✿ ❈❧❛ss ❉❡s❝r✐♣t✐♦♥✿ ❈❧❛ss❡s ♦❢ t❤✐s st❡r❡♦t②♣❡ r❡♣r❡s❡♥t ❢❛❝ts ✐♥ ❛ ▼❉ ♠♦❞❡❧ ■❝♦♥✿ ❋✐❣✳ ✸ ✭❛✮ ❈♦♥str❛✐♥ts✿ • ❆❧❧ ❛ttr✐❜✉t❡s ♦❢ ❛ ❋❛❝t ♠✉st ❜❡ ❖■❉ ♦r ❋❛❝t❆ttr✐❜✉t❡✿

•

s❡❧❢✳❢❡❛t✉r❡✲❃s❡❧❡❝t✭♦❝❧■s❑✐♥❞❖❢✭❆ttr✐❜✉t❡✮✮✲❃❢♦r❆❧❧✭♦❝❧■s❚②♣❡❖❢✭❖■❉✮ ♦r ♦❝❧■s❚②♣❡❖❢✭❋❛❝t❆ttr✐❜✉t❡✮✮ ❆❧❧ ❛ss♦❝✐❛t✐♦♥s ♦❢ ❛ ❋❛❝t ♠✉st ❜❡ ❛❣❣r❡❣❛t✐♦♥s✿ s❡❧❢✳❛ss♦❝✐❛t✐♦♥✲❃❢♦r❆❧❧✭❛❣❣r❡❣❛t✐♦♥ ❂ ★❛❣❣r❡❣❛t❡✮

Extending the UML for Multidimensional Modeling

297

• ❆ ❋❛❝t ❝❛♥ ♦♥❧② ❜❡ ❛ss♦❝✐❛t❡❞ ✇✐t❤ ❉✐♠❡♥s✐♦♥ ❝❧❛ss❡s✿

s❡❧❢✳❛❧❧❖♣♣♦s✐t❡❆ss♦❝✐❛t✐♦♥❊♥❞s✲❃❢♦r❆❧❧✭♣❛rt✐❝✐♣❛♥t✳♦❝❧■s❚②♣❡❖❢✭❉✐♠❡♥s✐♦♥✮✮

✕

❚❛❣❣❡❞ ✈❛❧✉❡s✿ ◆♦♥❡

✕ ✕ ✕ ✕ ✕

◆❛♠❡✿ ❇❛s❡ ❝❧❛ss✿ ❈❧❛ss ❉❡s❝r✐♣t✐♦♥✿ ❈❧❛ss❡s ♦❢ t❤✐s st❡r❡♦t②♣❡ r❡♣r❡s❡♥t ❞✐♠❡♥s✐♦♥s ✐♥ ❛ ▼❉ ♠♦❞❡❧ ■❝♦♥✿ ❋✐❣✳ ✸ ✭❜✮ ❈♦♥str❛✐♥ts✿ • ❆❧❧ ❛ttr✐❜✉t❡s ♦❢ ❛ ❉✐♠❡♥s✐♦♥ ♠✉st ❜❡ ❖■❉✱ ❉❡s❝r✐♣t♦r✱ ♦r ❉✐♠❡♥s✐♦♥❆ttr✐❜✉t❡✿

❉✐♠❡♥s✐♦♥

s❡❧❢✳❢❡❛t✉r❡✲❃s❡❧❡❝t✭♦❝❧■s❑✐♥❞❖❢✭❆ttr✐❜✉t❡✮✮✲❃❢♦r❆❧❧✭♦❝❧■s❚②♣❡❖❢✭❖■❉✮ ♦r ♦❝❧■s❚②♣❡❖❢✭❉❡s❝r✐♣t♦r✮ ♦r ♦❝❧■s❚②♣❡❖❢✭❉✐♠❡♥s✐♦♥❆ttr✐❜✉t❡✮✮

• ❆❧❧ ❛ss♦❝✐❛t✐♦♥s ♦❢ ❛ ❉✐♠❡♥s✐♦♥ ✇✐t❤ ❛ ❋❛❝t ♠✉st ❜❡ ❛❣❣r❡❣❛t✐♦♥s ❛t t❤❡ ❡♥❞ ♦❢ t❤❡ ❋❛❝t ✭t❤❡ ♦♣♣♦s✐t❡ ❡♥❞✮✿

s❡❧❢✳❛ss♦❝✐❛t✐♦♥✳❛ss♦❝✐❛t✐♦♥✲❃❢♦r❆❧❧✭❛ss♦❝✐❛t✐♦♥❊♥❞✳♣❛rt✐❝✐♣❛♥t✳♦❝❧■s❚②♣❡❖❢✭❋❛❝t✮ ✐♠✲ ♣❧✐❡s ❛ss♦❝✐❛t✐♦♥❊♥❞✳❛❣❣r❡❣❛t✐♦♥ ❂ ★❛❣❣r❡❣❛t❡✮

• ❆❧❧ ❛ss♦❝✐❛t✐♦♥s ♦❢ ❛ ❉✐♠❡♥s✐♦♥ ✇✐t❤ ❛ ❋❛❝t ♠✉st ♥♦t ❜❡ ❛❣❣r❡❣❛t✐♦♥s ❛t t❤❡ ❡♥❞ ♦❢ t❤❡ ❉✐♠❡♥s✐♦♥ ✭t❤❡ ❝✉rr❡♥t ❡♥❞✮✿

•

✕

s❡❧❢✳❛ss♦❝✐❛t✐♦♥✳❛ss♦❝✐❛t✐♦♥✲❃❢♦r❆❧❧✭❛ss♦❝✐❛t✐♦♥❊♥❞✳♣❛rt✐❝✐♣❛♥t✳♦❝❧■s❚②♣❡❖❢✭❋❛❝t✮ ✐♠✲ ♣❧✐❡s ❛❣❣r❡❣❛t✐♦♥ ❁❃ ★❛❣❣r❡❣❛t❡✮ ❆ ❉✐♠❡♥s✐♦♥ ❝❛♥♥♦t ❜❡ ❛ss♦❝✐❛t❡❞ ✇✐t❤ ❛♥♦t❤❡r ❉✐♠❡♥s✐♦♥✿ s❡❧❢✳❛❧❧❖♣♣♦s✐t❡❆ss♦❝✐❛t✐♦♥❊♥❞s✲❃❢♦r❆❧❧✭♥♦t ♣❛rt✐❝✐♣❛♥t✳♦❝❧■s❚②♣❡❖❢✭❉✐♠❡♥s✐♦♥✮✮

❚❛❣❣❡❞ ✈❛❧✉❡s✿ • ✐s❚✐♠❡✿ ∗ ❚②♣❡✿ ❯▼▲✿✿❉❛t❛t②♣❡s✿✿❇♦♦❧❡❛♥

∗ ▼✉❧t✐♣❧✐❝✐t②✿ ✶ ∗ ❉❡s❝r✐♣t✐♦♥✿ ■♥❞✐❝❛t❡s ✇❤❡t❤❡r t❤❡ ❞✐♠❡♥s✐♦♥ r❡♣r❡s❡♥ts ❛ t✐♠❡ ❞✐♠❡♥s✐♦♥ ♦r ♥♦t

❇❛s❡

✕ ✕ ✕

◆❛♠❡✿ ❇❛s❡ ❝❧❛ss✿ ❈❧❛ss ❉❡s❝r✐♣t✐♦♥✿ ❈❧❛ss❡s ♦❢ t❤✐s st❡r❡♦t②♣❡ r❡♣r❡s❡♥t ❞✐♠❡♥s✐♦♥ ❤✐❡r❛r❝❤② ❧❡✈❡❧s ✐♥ ❛

✕ ✕

▼❉ ♠♦❞❡❧ ■❝♦♥✿ ❋✐❣✳ ✸ ✭❝✮ ❈♦♥str❛✐♥ts✿ • ❆❧❧ ❛ttr✐❜✉t❡s ♦❢ ❛ ❇❛s❡ ♠✉st ❜❡ ❖■❉✱ ❉❡s❝r✐♣t♦r✱ ♦r ❉✐♠❡♥s✐♦♥❆ttr✐❜✉t❡✿

•

•

•

s❡❧❢✳❢❡❛t✉r❡✲❃s❡❧❡❝t✭♦❝❧■s❑✐♥❞❖❢✭❆ttr✐❜✉t❡✮✮✲❃❢♦r❆❧❧✭♦❝❧■s❚②♣❡❖❢✭❖■❉✮ ♦r ♦❝❧■s❚②♣❡❖❢✭❉❡s❝r✐♣t♦r✮ ♦r ♦❝❧■s❚②♣❡❖❢✭❉✐♠❡♥s✐♦♥❆ttr✐❜✉t❡✮✮ ❆ ❇❛s❡ ♠✉st ❤❛✈❡ ❛♥ ❖■❉ ❛ttr✐❜✉t❡ ❛♥❞ ❛ ❉❡s❝r✐♣t♦r ❛ttr✐❜✉t❡✿ s❡❧❢✳❢❡❛t✉r❡✲❃s❡❧❡❝t✭♦❝❧■s❑✐♥❞❖❢✭❆ttr✐❜✉t❡✮✮✲❃❡①✐st✭♦❝❧■s❚②♣❡❖❢✭❖■❉✮✮ ❛♥❞ s❡❧❢✳❢❡❛t✉r❡✲❃s❡❧❡❝t✭♦❝❧■s❑✐♥❞❖❢✭❆ttr✐❜✉t❡✮✮✲❃❡①✐st✭♦❝❧■s❚②♣❡❖❢✭❉❡s❝r✐♣t♦r✮✮ ❆ ❇❛s❡ ❝❛♥ ♦♥❧② ❜❡ ❛ss♦❝✐❛t❡❞ ✇✐t❤ ❛♥♦t❤❡r ❇❛s❡ ♦r ❛♥♦t❤❡r ❉✐♠❡♥s✐♦♥✿ s❡❧❢✳❛❧❧❖♣♣♦s✐t❡❆ss♦❝✐❛t✐♦♥❊♥❞s✲❃❢♦r❆❧❧✭♣❛rt✐❝✐♣❛♥t✳♦❝❧■s❚②♣❡❖❢✭❇❛s❡✮ ♦r ♣❛rt✐❝✐✲ ♣❛♥t✳♦❝❧■s❚②♣❡❖❢✭❉✐♠❡♥s✐♦♥✮✮ ❆ ❇❛s❡ ❝❛♥ ♦♥❧② ❜❡ ❝❤✐❧❞ ✐♥ ♦♥❡ ❣❡♥❡r❛❧✐③❛t✐♦♥✿ s❡❧❢✳❣❡♥❡r❛❧✐③❛t✐♦♥✲❃s✐③❡ ❁❂ ✶

• ❆ ❇❛s❡ ❝❛♥♥♦t s✐♠✉❧t❛♥❡♦✉s❧② ❜❡❧♦♥❣ t♦ ❛ ❣❡♥❡r❛❧✐③❛t✐♦♥✴s♣❡❝✐❛❧✐③❛t✐♦♥ ❤✐❡r✲ ❛r❝❤② ❛♥❞ ❛♥ ❛ss♦❝✐❛t✐♦♥ ❤✐❡r❛r❝❤②✿

✕

✭s❡❧❢✳❣❡♥❡r❛❧✐③❛t✐♦♥✲❃s✐③❡ ❃ ✵ ♦r s❡❧❢✳s♣❡❝✐❛❧✐③❛t✐♦♥✲❃s✐③❡ ❃ ✵✮ ✐♠♣❧✐❡s ✭s❡❧❢✳❛ss♦❝✐❛t✐♦♥✲❃s✐③❡ ❂ ✵ ✮

❚❛❣❣❡❞ ✈❛❧✉❡s✿ ◆♦♥❡

298

Sergio Luj´an-Mora et al.

❋❛❝t

❉✐♠❡♥s✐♦♥

❇❛s❡

✭❛✮

✭❜✮

✭❝✮

❋✐❣✳ ✸✳ ❙t❡r❡♦t②♣❡ ✐❝♦♥s

❙t❡r❡♦t②♣❡s ♦❢ ❆ttr✐❜✉t❡ ✕ ◆❛♠❡✿ ❖■❉ ✕ ✕

❇❛s❡ ❝❧❛ss✿ ❆ttr✐❜✉t❡

✕ ✕

■❝♦♥✿ ❋✐❣✳ ✹ ✭❛✮

❉❡s❝r✐♣t✐♦♥✿ ❆ttr✐❜✉t❡s ♦❢ t❤✐s st❡r❡♦t②♣❡ r❡♣r❡s❡♥t ❖■❉ ❛ttr✐❜✉t❡s ♦❢ ❋❛❝t✱ ❉✐♠❡♥✲ ✼ s✐♦♥ ♦r ❇❛s❡ ❝❧❛ss❡s ✐♥ ❛ ▼❉ ♠♦❞❡❧ ❈♦♥str❛✐♥ts✿

• ❆♥ ❖■❉ ❝❛♥♥♦t ❜❡ ❞❡r✐✈❡❞✿ ♥♦t s❡❧❢✳❞❡r✐✈❡❞

✕

❚❛❣❣❡❞ ✈❛❧✉❡s✿ ◆♦♥❡

✕ ✕ ✕

◆❛♠❡✿

✕ ✕

❋❛❝t❆ttr✐❜✉t❡

❇❛s❡ ❝❧❛ss✿ ❆ttr✐❜✉t❡

❉❡s❝r✐♣t✐♦♥✿ ❆tt✐❜✉t❡s ♦❢ t❤✐s st❡r❡♦t②♣❡ r❡♣r❡s❡♥t ❛ttr✐❜✉t❡s ♦❢ ❋❛❝t ❝❧❛ss❡s ✐♥ ❛ ▼❉ ♠♦❞❡❧ ■❝♦♥✿ ❋✐❣✳ ✹ ✭❜✮ ❈♦♥str❛✐♥ts✿

• ❆ ❋❛❝t❆ttr✐❜✉t❡ ❝❛♥ ♦♥❧② ❜❡❧♦♥❣ t♦ ❛ ❋❛❝t✿ s❡❧❢✳♦✇♥❡r✳♦❝❧■s❚②♣❡❖❢✭❋❛❝t✮

• ■❢ ❛ ❋❛❝t❆ttr✐❜✉t❡ ✐s ❞❡r✐✈❡❞✱ t❤❡♥ ✐t ♥❡❡❞s ❛ ❞❡r✐✈❛t✐♦♥ r✉❧❡ ✭❛♥ ❖❈▲ ❡①♣r❡s✲ s✐♦♥✮✿

✕

s❡❧❢✳❞❡r✐✈❡❞ ✐♠♣❧✐❡s s❡❧❢✳❞❡r✐✈❛t✐♦♥❘✉❧❡✳♦❝❧■s❚②♣❡❖❢✭❖❝❧❊①♣r❡ss✐♦♥✮ ❚❛❣❣❡❞ ✈❛❧✉❡s✿

• ❞❡r✐✈❛t✐♦♥❘✉❧❡✿ ∗ ❚②♣❡✿ ❯▼▲✿✿❉❛t❛t②♣❡s✿✿❙tr✐♥❣ ∗ ▼✉❧t✐♣❧✐❝✐t②✿ ✶ ∗ ❉❡s❝r✐♣t✐♦♥✿ ■❢ t❤❡ ❛ttr✐❜✉t❡ ✐s ❞❡r✐✈❡❞✱ t❤✐s t❛❣❣❡❞ ✈❛❧✉❡ r❡♣r❡s❡♥ts t❤❡ ❞❡r✐✈❛t✐♦♥ r✉❧❡

✕ ✕ ✕ ✕ ✕

◆❛♠❡✿

❉❡s❝r✐♣t♦r

❇❛s❡ ❝❧❛ss✿ ❆ttr✐❜✉t❡ ❉❡s❝r✐♣t✐♦♥✿ ❆ttr✐❜✉t❡s ♦❢ t❤✐s st❡r❡♦t②♣❡ r❡♣r❡s❡♥t ❞❡s❝r✐♣t♦r ❛ttr✐❜✉t❡s ♦❢ ❉✐♠❡♥✲ s✐♦♥ ♦r ❇❛s❡ ❝❧❛ss❡s ✐♥ ❛ ▼❉ ♠♦❞❡❧ ■❝♦♥✿ ❋✐❣✳ ✹ ✭❝✮ ❈♦♥str❛✐♥ts✿

• ❆ ❉❡s❝r✐♣t♦r ❝❛♥ ♦♥❧② ❜❡❧♦♥❣ t♦ ❛ ❉✐♠❡♥s✐♦♥ ♦r ❇❛s❡✿ s❡❧❢✳♦✇♥❡r✳♦❝❧■s❚②♣❡❖❢✭❉✐♠❡♥s✐♦♥✮ ♦r s❡❧❢✳♦✇♥❡r✳♦❝❧■s❚②♣❡❖❢✭❇❛s❡✮

✼

❙❡❡ ❙❡❝t✐♦♥ ✸ ♦r ❬✺❪ ❢♦r ❢✉rt❤❡r ✐♥❢♦r♠❛t✐♦♥ ♦♥ ❖■❉ ❛♥❞ ❉❡s❝r✐♣t♦r ❛ttr✐❜✉t❡s✳

Extending the UML for Multidimensional Modeling

299

• ■❢ ❛ ❉❡s❝r✐♣t♦r ✐s ❞❡r✐✈❡❞✱ t❤❡♥ ✐t ♥❡❡❞s ❛ ❞❡r✐✈❛t✐♦♥ r✉❧❡ ✭❛♥ ❖❈▲ ❡①♣r❡ss✐♦♥✮✿

✕

s❡❧❢✳❞❡r✐✈❡❞ ✐♠♣❧✐❡s s❡❧❢✳❞❡r✐✈❛t✐♦♥❘✉❧❡✳♦❝❧■s❚②♣❡❖❢✭❖❝❧❊①♣r❡ss✐♦♥✮ ❚❛❣❣❡❞ ✈❛❧✉❡s✿ • ❞❡r✐✈❛t✐♦♥❘✉❧❡✿ ∗ ❚②♣❡✿ ❯▼▲✿✿❉❛t❛t②♣❡s✿✿❙tr✐♥❣

∗ ▼✉❧t✐♣❧✐❝✐t②✿ ✶ ∗ ❉❡s❝r✐♣t✐♦♥✿ ■❢ t❤❡ ❛ttr✐❜✉t❡ ✐s ❞❡r✐✈❡❞✱ t❤✐s ✈❛❧✉❡ r❡♣r❡s❡♥ts t❤❡ ❞❡r✐✈❛t✐♦♥ r✉❧❡

❉✐♠❡♥s✐♦♥❆ttr✐❜✉t❡

✕ ✕ ✕

◆❛♠❡✿ ❇❛s❡ ❝❧❛ss✿ ❆ttr✐❜✉t❡ ❉❡s❝r✐♣t✐♦♥✿ ❆ttr✐❜✉t❡s ♦❢ t❤✐s st❡r❡♦t②♣❡ r❡♣r❡s❡♥t ❛ttr✐❜✉t❡s ♦❢ ❉✐♠❡♥s✐♦♥ ♦r ❇❛s❡

✕ ✕

❝❧❛ss❡s ✐♥ ❛ ▼❉ ♠♦❞❡❧ ■❝♦♥✿ ❋✐❣✳ ✹ ✭❞✮ ❈♦♥str❛✐♥ts✿ • ❆ ❉✐♠❡♥s✐♦♥❆ttr✐❜✉t❡ ❝❛♥ ♦♥❧② ❜❡❧♦♥❣ t♦ ❛ ❉✐♠❡♥s✐♦♥ ♦r ❇❛s❡✿ s❡❧❢✳♦✇♥❡r✳♦❝❧■s❚②♣❡❖❢✭❉✐♠❡♥s✐♦♥✮ ♦r s❡❧❢✳♦✇♥❡r✳♦❝❧■s❚②♣❡❖❢✭❇❛s❡✮

• ■❢ ❛ ❉✐♠❡♥s✐♦♥❆ttr✐❜✉t❡ ✐s ❞❡r✐✈❡❞✱ t❤❡♥ ✐t ♥❡❡❞s ❛ ❞❡r✐✈❛t✐♦♥ r✉❧❡ ✭❛♥ ❖❈▲ ❡①♣r❡ss✐♦♥✮✿

✕

s❡❧❢✳❞❡r✐✈❡❞ ✐♠♣❧✐❡s s❡❧❢✳❞❡r✐✈❛t✐♦♥❘✉❧❡✳♦❝❧■s❚②♣❡❖❢✭❖❝❧❊①♣r❡ss✐♦♥✮ ❚❛❣❣❡❞ ✈❛❧✉❡s✿ • ❞❡r✐✈❛t✐♦♥❘✉❧❡✿ ∗ ❚②♣❡✿ ❯▼▲✿✿❉❛t❛t②♣❡s✿✿❙tr✐♥❣

∗ ▼✉❧t✐♣❧✐❝✐t②✿ ✶ ∗ ❉❡s❝r✐♣t✐♦♥✿ ■❢ t❤❡ ❛ttr✐❜✉t❡ ✐s ❞❡r✐✈❡❞✱ t❤✐s ✈❛❧✉❡ r❡♣r❡s❡♥ts t❤❡ ❞❡r✐✈❛t✐♦♥ r✉❧❡

❖■❉

❋❛❝t

❉❡s❝r✐♣t♦r ❉✐♠❡♥s✐♦♥

❆ttr✐❜✉t❡ ✭❛✮

✭❜✮

❆ttr✐❜✉t❡ ✭❝✮

✭❞✮

❋✐❣✳ ✹✳ ❙t❡r❡♦t②♣❡ ✐❝♦♥s

❙t❡r❡♦t②♣❡ ♦❢ ❆ss♦❝✐❛t✐♦♥ ✕ ◆❛♠❡✿ ❈♦♠♣❧❡t❡♥❡ss ✕ ✕ ✕ ✕

✕ ✽

❇❛s❡ ❝❧❛ss✿ ❆ss♦❝✐❛t✐♦♥ ✽ ❉❡s❝r✐♣t✐♦♥✿ ❆ss♦❝✐❛t✐♦♥s ♦❢ t❤✐s st❡r❡♦t②♣❡ r❡♣r❡s❡♥t ❝♦♠♣❧❡t❡ ❛ss♦❝✐❛t✐♦♥s ■❝♦♥✿ ◆♦♥❡ ❈♦♥str❛✐♥ts✿ • ❚❤❡ ❡♥❞s ♦❢ ❛ ❈♦♠♣❧❡t❡♥❡ss ❛ss♦❝✐❛t✐♦♥ ❝❛♥ ♦♥❧② ❜❡ ❉✐♠❡♥s✐♦♥ ♦r ❇❛s❡ ❝❧❛ss❡s✿ s❡❧❢✳❛ss♦❝✐❛t✐♦♥❊♥❞✳♣❛rt✐❝✐♣❛♥t✲❃❢♦r❆❧❧✭♦❝❧■s❚②♣❡❖❢✭❉✐♠❡♥s✐♦♥✮ ♦r ♦❝❧■s❚②♣❡❖❢✭❇❛s❡✮✮ ❚❛❣❣❡❞ ✈❛❧✉❡s✿ ◆♦♥❡

❆ ❝♦♠♣❧❡t❡ ❛ss♦❝✐❛t✐♦♥ ♠❡❛♥s t❤❛t ❛❧❧ ♠❡♠❜❡rs ❜❡❧♦♥❣ t♦ ♦♥❡ ❤✐❣❤❡r✲❝❧❛ss ♦❜❥❡❝t ❛♥❞ t❤❛t ♦❜❥❡❝t ❝♦♥s✐sts ♦❢ t❤♦s❡ ♠❡♠❜❡rs ♦♥❧②✳

300

✺✳✹

Sergio Luj´an-Mora et al.

❲❡❧❧✲❋♦r♠❡❞♥❡ss ❘✉❧❡s

◆❛♠❡s♣❛❝❡ ✕

✾

❆❧❧ t❤❡ ❝❧❛ss❡s ✐♥ ❛ ▼❉ ♠♦❞❡❧ ♠✉st ❜❡ ❋❛❝t✱ ❉✐♠❡♥s✐♦♥✱ ♦r ❇❛s❡✿

s❡❧❢✳❛❧❧❈♦♥t❡♥ts✲❃❢♦r❆❧❧✭♦❝❧■s❑✐♥❞❖❢✭❈❧❛ss✮ ✐♠♣❧✐❡s ✭♦❝❧■s❚②♣❡❖❢✭❋❛❝t✮ ♦r ♦❝❧■s❚②♣❡❖❢✭❉✐♠❡♥s✐♦♥✮ ♦r ♦❝❧■s❚②♣❡❖❢✭❇❛s❡✮✮✮

✺✳✺

❈♦♠♠❡♥ts

◆❡①t✱ ✇❡ s✉♠♠❛r✐③❡ t❤❡ ❯▼▲ ❡❧❡♠❡♥ts ✇❡ ❤❛✈❡ ❥✉st ✉s❡❞ ♦r ❞❡✜♥❡❞ t♦ ❝♦♥s✐❞❡r t❤❡ ♠❛✐♥ r❡❧❡✈❛♥t ▼❉ ♣r♦♣❡rt✐❡s✿

✕ ❋❛❝ts ❛♥❞ ❞✐♠❡♥s✐♦♥s✿ t❤❡② ❛r❡ r❡♣r❡s❡♥t❡❞ ❜② ♠❡❛♥s ♦❢ ❋❛❝t ❛♥❞ ❉✐♠❡♥s✐♦♥ st❡r❡♦t②♣❡s✳ ✕ ▼❛♥②✲t♦✲♠❛♥② r❡❧❛t✐♦♥s❤✐♣s✿ t❤❛♥❦s t♦ t❤❡ ✢❡①✐❜✐❧✐t② ♦❢ t❤❡ s❤❛r❡❞✲❛❣❣r❡❣❛t✐♦♥ r❡❧❛t✐♦♥s❤✐♣s✱ ✇❡ ❝❛♥ ❝♦♥s✐❞❡r ♠❛♥②✲t♦✲♠❛♥② r❡❧❛t✐♦♥s❤✐♣s ❜❡t✇❡❡♥ ❢❛❝ts ❛♥❞ ♣❛rt✐❝✉❧❛r ❞✐♠❡♥s✐♦♥s ❜② ♠❡❛♥s ♦❢ t❤❡ ✶✳✳✯ ❝❛r❞✐♥❛❧✐t② ♦♥ t❤❡ ❞✐♠❡♥s✐♦♥ ❝❧❛ss r♦❧❡✳ ✕ ❉❡r✐✈❡❞ ♠❡❛s✉r❡s✿ t❤❡② ❛r❡ r❡♣r❡s❡♥t❡❞ ❜② ♠❡❛♥s ♦❢ ❞❡r✐✈❡❞ ❛ttr✐❜✉t❡s ❢r♦♠ t❤❡ ❯▼▲ ♠❡t❛♠♦❞❡❧ ❛♥❞ t❤❡ t❛❣❣❡❞ ✈❛❧✉❡ ❞❡r✐✈❛t✐♦♥❘✉❧❡ ✇❡ ❤❛✈❡ ❞❡✜♥❡❞ ✐♥ t❤❡ ❉❡s❝r✐♣t♦r✱ ❉✐♠❡♥s✐♦♥❆ttr✐❜✉t❡✱ ❛♥❞ ❋❛❝t❆ttr✐❜✉t❡ st❡r❡♦t②♣❡s✳ ✕ ❆❞❞✐t✐✈✐t②✿ ❛❧❧ ❋❛❝t❆ttr✐❜✉t❡s ❛r❡ ❝♦♥s✐❞❡r❡❞ ❛❞❞✐t✐✈❡ ❜② ❞❡❢❛✉❧t✳ ❋♦r ♥♦♥❛❞✲ ❞✐t✐✈❡ ❋❛❝t❆ttr✐❜✉t❡s✱ t❤❡✐r ❛❞❞✐t✐✈✐t② r✉❧❡s ❛r❡ ❞❡✜♥❡❞ ❛s ❝♦♥str❛✐♥ts ♣❧❛❝❡❞ ♥❡❛r t❤❡ ❝♦rr❡s♣♦♥❞✐♥❣ ❋❛❝t ❝❧❛ss✳ ✕ ❈❧❛ss✐✜❝❛t✐♦♥ ❤✐❡r❛r❝❤✐❡s✿ t❤❡② ❛r❡ ❝♦♥s✐❞❡r❡❞ ❜② ♠❡❛♥s ♦❢ t❤❡ ❛ss♦❝✐❛t✐♦♥ ❜❡t✇❡❡♥ ❉✐♠❡♥s✐♦♥ ❛♥❞ ❇❛s❡ st❡r❡♦t②♣❡s✳ ✕ ❙tr✐❝t♥❡ss✿ t❤❡ ♠✉❧t✐♣❧✐❝✐t② ✶ ❛♥❞ ✶✳✳✯ ❞❡✜♥❡❞ ✐♥ t❤❡ t❛r❣❡t ❛ss♦❝✐❛t❡❞ ❝❧❛ss r♦❧❡ ♦❢ ❛ ❝❧❛ss✐✜❝❛t♦♥ ❤✐❡r❛r❝❤② ❛❞❞r❡ss t❤❡ ❝♦♥❝❡♣ts ♦❢ str✐❝t♥❡ss ❛♥❞ ♥♦♥✲ str✐❝t♥❡ss✳ ✕ ❈♦♠♣❧❡t❡♥❡ss✿ t❤❡ st❡r❡♦t②♣❡ ❈♦♠♣❧❡t❡♥❡ss ❛❞❞r❡ss❡s t❤❡ ❝♦♠♣❧❡t❡♥❡ss ♦❢ ❛ ❝❧❛ss✐✜❝❛t✐♦♥ ❤✐❡r❛r❝❤②✳ ✕ ❈❛t❡❣♦r✐③✐♥❣ ❞✐♠❡♥s✐♦♥s✿ ✇❡ ✉s❡ ❣❡♥❡r❛❧✐③❛t✐♦♥✲s♣❡❝✐❛❧✐③❛t✐♦♥ r❡❧❛t✐♦♥s❤✐♣s t♦ ❝❛t❡❣♦r✐③❡ ❛ ❉✐♠❡♥s✐♦♥✳

✻

❯s✐♥❣ ▼✉❧t✐❞✐♠❡♥s✐♦♥❛❧ ▼♦❞❡❧✐♥❣ ✐♥ ❘❛t✐♦♥❛❧ ❘♦s❡

❘❛t✐♦♥❛❧ ❘♦s❡ ✭❘❘✮ ✐s ♦♥❡ ♦❢ t❤❡ ♠♦st ✇❡❧❧✲❦♥♦✇♥ ✈✐s✉❛❧ ♠♦❞❡❧✐♥❣ t♦♦❧s✳ ❘❘ ✐s ❡①t❡♥s✐❜❧❡ ❜② ♠❡❛♥s ♦❢ ❛❞❞✲✐♥s✱ ✇❤✐❝❤ ❛❧❧♦✇s t♦ ♣❛❝❦❛❣❡ ❝✉st♦♠✐③❛t✐♦♥s ❛♥❞ ❛✉✲ t♦♠❛t✐♦♥ ♦❢ s❡✈❡r❛❧ ❘❘ ❢❡❛t✉r❡s t❤r♦✉❣❤ t❤❡ ❘♦s❡ ❊①t❡♥s✐❜✐❧✐t② ■♥t❡r❢❛❝❡ ✭❘❊■✮ ❬✶✼❪ ✐♥t♦ ♦♥❡ ❝♦♠♣♦♥❡♥t✳ ❆♥ ❛❞❞✲✐♥ ✐s ❛ ❝♦❧❧❡❝t✐♦♥ ♦❢ s♦♠❡ ❝♦♠❜✐♥❛t✐♦♥ ♦❢ t❤❡ ❢♦❧❧♦✇✐♥❣✿ ♠❛✐♥ ♠❡♥✉ ✐t❡♠s✱ s❤♦rt❝✉t ♠❡♥✉ ✐t❡♠s✱ ❝✉st♦♠ s♣❡❝✐✜❝❛t✐♦♥s✱ ♣r♦♣✲ ❡rt✐❡s ✭❯▼▲ t❛❣❣❡❞ ✈❛❧✉❡s✮✱ ❞❛t❛ t②♣❡s✱ ❯▼▲ st❡r❡♦t②♣❡s✱ ♦♥❧✐♥❡ ❤❡❧♣✱ ❝♦♥t❡①t✲ s❡♥s✐t✐✈❡ ❤❡❧♣✱ ❛♥❞ ❡✈❡♥t ❤❛♥❞❧✐♥❣✳ ✾

❛❧❧❈♦♥t❡♥ts ✐s ❛♥ ❛❞❞✐t✐♦♥❛❧ ♦♣❡r❛t✐♦♥ ❞❡✜♥❡❞ ✐♥ t❤❡ ❯▼▲ s♣❡❝✐✜❝❛t✐♦♥ ❬✽❪✿ ✏❚❤❡ ♦♣❡r❛t✐♦♥ ❛❧❧❈♦♥t❡♥ts r❡s✉❧ts ✐♥ ❛ ❙❡t ❝♦♥t❛✐♥✐♥❣ ❛❧❧ ▼♦❞❡❧❊❧❡♠❡♥ts ❝♦♥t❛✐♥❡❞ ❜② t❤❡ ◆❛♠❡s♣❛❝❡✑✳

Extending the UML for Multidimensional Modeling

301

■♥ t❤✐s s❡❝t✐♦♥✱ ✇❡ ♣r❡s❡♥t ❛♥ ❛❞❞✲✐♥ ✇❡ ❤❛✈❡ ❞❡✈❡❧♦♣❡❞✱ ✇❤✐❝❤ ❛❧❧♦✇s ✉s t♦ ✉s❡ t❤❡ ❡①t❡♥s✐♦♥ ✇❡ ❤❛✈❡ ❞❡✜♥❡❞ ✐♥ ❘❘✳ ❚❤❡r❡❢♦r❡✱ ✇❡ ❝❛♥ ✉s❡ t❤✐s t♦♦❧ t♦ ❡❛s✐❧② ♠♦❞❡❧ ▼❉ ❝♦♥❝❡♣t✉❛❧ ♠♦❞❡❧s✳ ❖✉r ❛❞❞✲✐♥ ❝✉st♦♠✐③❡s t❤❡ ❢♦❧❧♦✇✐♥❣ ❡❧❡♠❡♥ts✿

✕ ✕ ✕

❙t❡r❡♦t②♣❡s✿ ❲❡ ❤❛✈❡ ❞❡✜♥❡❞ t❤❡ st❡r❡♦t②♣❡s ❜② ♠❡❛♥s ♦❢ ❛ st❡r❡♦t②♣❡ ❝♦♥✲ ✜❣✉r❛t✐♦♥ ✜❧❡✳ Pr♦♣❡rt✐❡s✿ ❲❡ ❤❛✈❡ ❞❡✜♥❡❞ t❤❡ t❛❣❣❡❞ ✈❛❧✉❡s ❜② ♠❡❛♥s ♦❢ ❛ ♣r♦♣❡rt② ❝♦♥✲ ✜❣✉r❛t✐♦♥ ✜❧❡✳

▼❡♥✉ ✐t❡♠✿ ❲❡ ❤❛✈❡ ❛❞❞❡❞ t❤❡ ♥❡✇ ♠❡♥✉ ✐t❡♠ ▼❉ ❱❛❧✐❞❛t❡ ✐♥ t❤❡ ♠❡♥✉ ❚♦♦❧s ❜② ♠❡❛♥s ♦❢ ❛ ♠❡♥✉ ❝♦♥✜❣✉r❛t✐♦♥ ✜❧❡✳ ❚❤✐s ♠❡♥✉ ✐t❡♠ r✉♥s ❛ ❘♦s❡ s❝r✐♣t t❤❛t ✈❛❧✐❞❛t❡s ❛ ▼❉ ♠♦❞❡❧✿ ♦✉r s❝r✐♣t ❝❤❡❝❦s ❛❧❧ t❤❡ ❝♦♥str❛✐♥ts ✇❡ ❤❛✈❡ ♣r❡s❡♥t❡❞ ✐♥ ❙❡❝t✐♦♥ ✺✳

❋✐❣✳ ✺✳

▼✉❧t✐❞✐♠❡♥s✐♦♥❛❧ ♠♦❞❡❧✐♥❣ ✉s✐♥❣ ❘❛t✐♦♥❛❧ ❘♦s❡

❚❤❡ ❜❡st ✇❛② t♦ ✉♥❞❡rst❛♥❞ ♦✉r ❡①t❡♥s✐♦♥ ✐s t♦ s❤♦✇ ❛ t❛♥❣✐❜❧❡ ❡①❛♠♣❧❡✳ ❋✐❣✳ ✺ s❤♦✇s ❛ ▼❉ ❝♦♥❝❡♣t✉❛❧ ♠♦❞❡❧ ♦❢ t❤❡ ✇❡❧❧✲❦♥♦✇♥ ❡①❛♠♣❧❡ ✏●r♦❝❡r②✑ ❛s

❙❛❧❡s✱ ❛♥❞ ❚✐♠❡✱ Pr♦❞✉❝t✱ ❙t♦r❡✱ ❛♥❞ Pr♦♠♦t✐♦♥✳ ❊✈❡r② ❝❧❛ss✐✜❝❛t✐♦♥

❞❡s❝r✐❜❡❞ ✐♥ ❈❤❛♣t❡r ✷ ♦❢ ❬✶✺❪✳ ❚❤✐s ❡①❛♠♣❧❡ ❝♦♥t❛✐♥s ♦♥❡ ❋❛❝t ❝❧❛ss✱ ❢♦✉r ❉✐♠❡♥s✐♦♥ ❝❧❛ss❡s✿

❤✐❡r❛r❝❤② ❧❡✈❡❧ ♦❢ ❛ ❉✐♠❡♥s✐♦♥ ❝❧❛ss ✐s r❡♣r❡s❡♥t❡❞ ❜② ❛ ❇❛s❡ ❝❧❛ss✳ ❋♦r ❡①❛♠♣❧❡✱

❚✐♠❡ ❝♦♠♣r✐s❡s t❤❡ ❢♦❧❧♦✇✐♥❣ ❇❛s❡ ❝❧❛ss❡s✿ ▼♦♥t❤✱ ◗✉❛rt❡r✱ ❙❡♠❡st❡r✱ ❨❡❛r✱ ❛♥❞ ❙❡❛s♦♥✳ ❋♦r t❤❡ s❛❦❡ ♦❢ ❝❧❛r✐t②✱ ✇❡ ❞♦ ♥♦t s❤♦✇ ❛❧❧ t❤❡ ❛ttr✐❜✉t❡s✿ ♦♥❧② t❤❡ ❛ttr✐❜✉t❡s ♦❢ ❙❛❧❡s ❛♥❞ Pr♦❞✉❝t ❛r❡ ❞✐s♣❧❛②❡❞✳ ❲❡ ❝❛♥ ❛❧s♦ ♥♦t✐❝❡ t❤❛t ❛ st❡r❡♦t②♣❡ ❝❛♥ ❜❡ ❞✐s♣❧❛②❡❞ ✐♥ ❞✐✛❡r❡♥t ♠❛♥♥❡rs ✐♥ ❘❘✿ ❙❛❧❡s t❤❡ ❝❧❛ss✐✜❝❛t✐♦♥ ❤✐❡r❛r❝❤② ♦❢

302

Sergio Luj´an-Mora et al.

❛♥❞ Pr♦❞✉❝t ❛r❡ ❞✐s♣❧❛②❡❞ ✉s✐♥❣ t❤❡ st❡r❡♦t②♣❡ ✐❝♦♥ ✐♥s✐❞❡ t❤❡ ❝❧❛ss✱ ✇❤❡r❡❛s t❤❡ r❡st ♦❢ ❡❧❡♠❡♥ts ❛r❡ ❞✐s♣❧❛②❡❞ ✉s✐♥❣ t❤❡ st❡r❡♦t②♣❡ ✐❝♦♥✳ ❋✐❣✳ ✻ ❞✐s♣❧❛②s t❤❡ st❡r❡♦t②♣❡ ❝♦♥✜❣✉r❛t✐♦♥ ✜❧❡ t❤❛t ❝♦♥t❛✐♥s ♦✉r ▼❉ st❡r❡♦✲ t②♣❡s✳ ❚♦ ❣r❛♣❤✐❝❛❧❧② ❞✐st✐♥❣✉✐s❤ t❤❡ ♠♦❞❡❧ ❡❧❡♠❡♥ts ♦❢ ❞✐✛❡r❡♥t st❡r❡♦t②♣❡s✱ ❡❛❝❤ st❡r❡♦t②♣❡ ❝❛♥ ❤❛✈❡ ❛ ❣r❛♣❤✐❝❛❧ r❡♣r❡s❡♥t❛t✐♦♥✳ ❚❤✉s✱ ✇❡ ❤❛✈❡ ♣r♦✈✐❞❡❞ ❛❧❧ t❤❡ ♥❡❡❞❡❞ ✐❝♦♥s ❝♦♥❝❡r♥✐♥❣ t❤❡s❡ ❣r❛♣❤✐❝❛❧ st❡r❡♦t②♣❡ r❡♣r❡s❡♥t❛t✐♦♥s t♦ ❢❛❝✐❧✐t❛t❡ t❤❡✐r ✉s❡✳

❋✐❣✳ ✻✳

❉❡✜♥✐t✐♦♥ ♦❢ t❤❡ st❡r❡♦t②♣❡s ✐♥ ❘❛t✐♦♥❛❧ ❘♦s❡

❋✐♥❛❧❧②✱ ❛♥ ❛❞❞✲✐♥ ❝❛♥ ❛❧s♦ ❡①t❡♥❞ ♦r ❝✉st♦♠✐③❡ ❘❘ ♠❡♥✉s ❜② ♠❡❛♥s ♦❢ ❛ ♠❡♥✉ ❝♦♥✜❣✉r❛t✐♦♥ ✜❧❡✳ ❲❡ ♦♥❧② ❛❞❞ ❛ ♥❡✇ ♠❡♥✉ ✐t❡♠ ❝❛❧❧❡❞ ▼❉ ❱❛❧✐❞❛t❡ ✐♥ t❤❡ ❚♦♦❧s ♠❡♥✉✳ ❚❤✐s ♥❡✇ ♠❡♥✉ ✐t❡♠ ❡①❡❝✉t❡s ❛ ❘♦s❡ s❝r✐♣t t❤❛t ✈❛❧✐❞❛t❡s t❤❡ ❝♦rr❡❝t♥❡ss ♦❢ ❛ ▼❉ ♠♦❞❡❧✿ ✐t ❝❤❡❝❦s ❛❧❧ t❤❡ ❖❈▲ ❝♦♥str❛✐♥ts ✇❡ ❤❛✈❡ ♣r❡s❡♥t❡❞ ✐♥ ❙❡❝t✐♦♥ ✺✳ ❋♦r ❡①❛♠♣❧❡✱ ❛ ❢r❛❣♠❡♥t ♦❢ t❤✐s s❝r✐♣t ✐s s❤♦✇♥ ✐♥ ❋✐❣✳ ✼✳ ■♥ t❤✐s ❢r❛❣♠❡♥t ✇❡ ❝❛♥ ♥♦t✐❝❡ t❤❡ ❢✉♥❝t✐♦♥ ❱❆ss♦❝✐❛t✐♦♥❋❛❝t✱ ✇❤✐❝❤ ✈❛❧✐❞❛t❡s t❤❡ ❛ss♦❝✐❛t✐♦♥s ♦❢ ❛ ❋❛❝t✳ ■t ❝❤❡❝❦s t❤❡ ❖❈▲ ❝♦♥str❛✐♥ts ✇❡ ❤❛✈❡ ♣r❡✈✐♦✉s❧② ♣r❡s❡♥t❡❞ ✐♥ t❤❡ ❋❛❝t st❡r❡♦t②♣❡✿ ✕ ❆❧❧ ❛ss♦❝✐❛t✐♦♥s ♦❢ ❛ ❋❛❝t ♠✉st ❜❡ ❛❣❣r❡❣❛t✐♦♥s✳ ✕ ❆ ❋❛❝t ❝❛♥ ♦♥❧② ❜❡ ❛ss♦❝✐❛t❡❞ ✇✐t❤ ❉✐♠❡♥s✐♦♥ ❝❧❛ss❡s✳

Extending the UML for Multidimensional Modeling

303

❱❛❧✐❞❛t✐♦♥ s❝r✐♣t ❢♦r ❘❛t✐♦♥❛❧ ❘♦s❡ ✼ ❈♦♥❝❧✉s✐♦♥s ❛♥❞ ❋✉t✉r❡ ❲♦r❦ ❋✐❣✳ ✼✳

■♥ t❤✐s ♣❛♣❡r✱ ✇❡ ❤❛✈❡ ♣r❡s❡♥t❡❞ ❛♥ ❡①t❡♥s✐♦♥ ♦❢ t❤❡ ❯▼▲ t❤❛t ❛❧❧♦✇s ✉s t♦ r❡♣✲ r❡s❡♥t t❤❡ ♠❛❥♦r r❡❧❡✈❛♥t str✉❝t✉r❛❧ ▼❉ ♣r♦♣❡rt✐❡s ❛t t❤❡ ❝♦♥❝❡♣t✉❛❧ ❧❡✈❡❧✳ ❚❤✐s ❡①t❡♥s✐♦♥ ❝♦♥t❛✐♥s t❤❡ ♥❡❡❞❡❞ st❡r❡♦t②♣❡s✱ t❛❣❣❡❞ ✈❛❧✉❡s ❛♥❞ ❝♦♥str❛✐♥ts ❢♦r ❛ ❝♦♠♣❧❡t❡ ❛♥❞ ♣♦✇❡r❢✉❧ ▼❉ ♠♦❞❡❧✐♥❣✳ ❲❡ ❤❛✈❡ ✉s❡❞ t❤❡ ❖❈▲ t♦ s♣❡❝✐❢② t❤❡ ❝♦♥✲ str❛✐♥ts ❛tt❛❝❤❡❞ t♦ t❤❡s❡ ♥❡✇ ❞❡✜♥❡❞ ❡❧❡♠❡♥ts✱ t❤❡r❡❜② ❛✈♦✐❞✐♥❣ ❛♥ ❛r❜✐tr❛r② ✉s❡ ♦❢ t❤❡♠✳ ❲❡ ❤❛✈❡ ❛❧s♦ ♣r♦❣r❛♠♠❡❞ t❤✐s ❡①t❡♥s✐♦♥ ✐♥ ❛ ✇❡❧❧✲❦♥♦✇♥ ✈✐s✉❛❧ ♠♦❞❡❧✐♥❣ t♦♦❧✱ ❘❛t✐♦♥❛❧ ❘♦s❡✳ ❚❤❡ ♠❛✐♥ r❡❧❡✈❛♥t ❛❞✈❛♥t❛❣❡ ♦❢ t❤✐s ❛♣♣r♦❛❝❤ ✐s t❤❛t ✐t ✉s❡s t❤❡ ❯▼▲✱ ❛ ✇✐❞❡❧②✲❛❝❝❡♣t❡❞ ♦❜❥❡❝t✲♦r✐❡♥t❡❞ ♠♦❞❡❧✐♥❣ ❧❛♥❣✉❛❣❡✱ ✇❤✐❝❤ s❛✈❡s ❞❡✈❡❧♦♣❡rs ❢r♦♠ ❧❡❛r♥✐♥❣ ❛ ♥❡✇ ♠♦❞❡❧ ❛♥❞ ✐ts ❝♦rr❡s♣♦♥❞✐♥❣ ♥♦t❛✲ t✐♦♥s ❢♦r s♣❡❝✐✜❝ ▼❉ ♠♦❞❡❧✐♥❣✳ ❋✉rt❤❡r♠♦r❡✱ t❤❡ ❯▼▲ ❛❧❧♦✇s ✉s t♦ r❡♣r❡s❡♥t s♦♠❡ ▼❉ ♣r♦♣❡rt✐❡s t❤❛t ❛r❡ ❤❛r❞❧② ❝♦♥s✐❞❡r❡❞ ❜② ♦t❤❡r ❝♦♥❝❡♣t✉❛❧ ▼❉ ♣r♦✲ ♣♦s❛❧s✳ ❲❡ ❛r❡ ❝✉rr❡♥t❧② ✇♦r❦✐♥❣ ♦♥ ❞❡✜♥✐♥❣ ❛ ♠❡t❤♦❞♦❧♦❣② ❢♦r ▼❉ ♠♦❞❡❧✐♥❣ ❜❛s❡❞ ♦♥ t❤❡ ❡①t❡♥s✐♦♥ ♣r❡s❡♥t❡❞ ✐♥ t❤✐s ♣❛♣❡r✳ ❚❤✐s ♠❡t❤♦❞♦❧♦❣② ✇✐❧❧ ❡①♣❧✐❝✐t❧② ❝♦♥✲ s✐❞❡r ❛❧❧ ✉♥❞❡r❧②✐♥❣ ❞❡s✐❣♥ ❣✉✐❞❡❧✐♥❡s t❤❛t ❛r❡ ❤✐❞❞❡♥ ✉♥❞❡r ❡✈❡r② ❞❡✜♥❡❞ ♥❡✇ ▼❉ ❡❧❡♠❡♥t✳ ❋✉rt❤❡r♠♦r❡✱ ✐♥ t❤✐s ❯▼▲ ❡①t❡♥s✐♦♥ ✇❡ ❛r❡ ❛❧s♦ ❝♦♥s✐❞❡r✐♥❣ ♥❡✇ st❡r❡♦t②♣❡s r❡❣❛r❞✐♥❣ ♦❜❥❡❝t✲♦r✐❡♥t❡❞ ❛♥❞ ♦❜❥❡❝t✲r❡❧❛t✐♦♥❛❧ ❞❛t❛❜❛s❡s ❢♦r ❛♥ ❛✉✲ t♦♠❛t✐❝ ❣❡♥❡r❛t✐♦♥ ♦❢ t❤❡ ❞❛t❛❜❛s❡ s❝❤❡♠❛ ✐♥t♦ t❤❡s❡ ❦✐♥❞s ♦❢ ❞❛t❛❜❛s❡s✳

304

Sergio Luj´an-Mora et al.

❘❡❢❡r❡♥❝❡s ✶✳ ●♦❧❢❛r❡❧❧✐✱ ▼✳✱ ❘✐③③✐✱ ❙✳✿ ❆ ♠❡t❤♦❞♦❧♦❣✐❝❛❧ ❋r❛♠❡✇♦r❦ ❢♦r ❉❛t❛ ❲❛r❡❤♦✉s❡ ❉❡✲ s✐❣♥✳ ■♥✿ Pr♦❝✳ ♦❢ t❤❡ ❆❈▼ ✶st ■♥t❧✳ ❲♦r❦s❤♦♣ ♦♥ ❉❛t❛ ✇❛r❡❤♦✉s✐♥❣ ❛♥❞ ❖▲❆P ✭❉❖▲❆P✬✾✽✮✳ ✭✶✾✾✽✮ ✸✕✾ ✷✳ ❙❛♣✐❛✱ ❈✳✱ ❇❧❛s❝❤❦❛✱ ▼✳✱ ❍ö✢✐♥❣✱ ●✳✱ ❉✐♥t❡r✱ ❇✳✿ ❊①t❡♥❞✐♥❣ t❤❡ ❊✴❘ ▼♦❞❡❧ ❢♦r t❤❡ ▼✉❧t✐❞✐♠❡♥s✐♦♥❛❧ P❛r❛❞✐❣♠✳ ■♥✿ Pr♦❝✳ ♦❢ t❤❡ ✶st ■♥t❧✳ ❲♦r❦s❤♦♣ ♦♥ ❉❛t❛ ❲❛r❡❤♦✉s❡ ❛♥❞ ❉❛t❛ ▼✐♥✐♥❣ ✭❉❲❉▼✬✾✽✮✳ ❱♦❧✉♠❡ ✶✺✺✷ ♦❢ ▲◆❈❙✳✱ ❙♣r✐♥❣❡r✲❱❡r❧❛❣ ✭✶✾✾✽✮ ✶✵✺✕✶✶✻ ✸✳ ❚r②❢♦♥❛✱ ◆✳✱ ❇✉s❜♦r❣✱ ❋✳✱ ❈❤r✐st✐❛♥s❡♥✱ ❏✳✿ st❛r❊❘✿ ❆ ❈♦♥❝❡♣t✉❛❧ ▼♦❞❡❧ ❢♦r ❉❛t❛ ❲❛r❡❤♦✉s❡ ❉❡s✐❣♥✳ ■♥✿ Pr♦❝✳ ♦❢ t❤❡ ❆❈▼ ✷♥❞ ■♥t❧✳ ❲♦r❦s❤♦♣ ♦♥ ❉❛t❛ ✇❛r❡❤♦✉s✐♥❣ ❛♥❞ ❖▲❆P ✭❉❖▲❆P✬✾✾✮✳ ✭✶✾✾✾✮ ✹✳ ❍✉s❡♠❛♥♥✱ ❇✳✱ ▲❡❝❤t❡♥❜♦r❣❡r✱ ❏✳✱ ❱♦ss❡♥✱ ●✳✿ ❈♦♥❝❡♣t✉❛❧ ❉❛t❛ ❲❛r❡❤♦✉s❡ ❉❡s✐❣♥✳ ■♥✿ Pr♦❝✳ ♦❢ t❤❡ ✷♥❞ ■♥t❧✳ ❲♦r❦s❤♦♣ ♦♥ ❉❡s✐❣♥ ❛♥❞ ▼❛♥❛❣❡♠❡♥t ♦❢ ❉❛t❛ ❲❛r❡❤♦✉s❡s ✭❉▼❉❲✬✵✵✮✱ ❙t♦❝❦❤♦❧♠✱ ❙✇❡❞❡♥ ✭✷✵✵✵✮ ✺✳ ❚r✉❥✐❧❧♦✱ ❏✳✱ P❛❧♦♠❛r✱ ▼✳✱ ●ó♠❡③✱ ❏✳✱ ❙♦♥❣✱ ■✳❨✳✿ ❉❡s✐❣♥✐♥❣ ❉❛t❛ ❲❛r❡❤♦✉s❡s ✇✐t❤ ❖❖ ❈♦♥❝❡♣t✉❛❧ ▼♦❞❡❧s✳ ■❊❊❊ ❈♦♠♣✉t❡r✱ s♣❡❝✐❛❧ ✐ss✉❡ ♦♥ ❉❛t❛ ❲❛r❡❤♦✉s❡s ✸✹ ✭✷✵✵✶✮ ✻✻✕✼✺ ✻✳ ❆❜❡❧❧ó✱ ❆✳✱ ❙❛♠♦s✱ ❏✳✱ ❙❛❧t♦r✱ ❋✳✿ ❆ ❋r❛♠❡✇♦r❦ ❢♦r t❤❡ ❈❧❛ss✐✜❝❛t✐♦♥ ❛♥❞ ❉❡s❝r✐♣✲ t✐♦♥ ♦❢ ▼✉❧t✐❞✐♠❡♥s✐♦♥❛❧ ❉❛t❛ ▼♦❞❡❧s✳ ■♥✿ Pr♦❝✳ ♦❢ t❤❡ ✶✷t❤ ■♥t❧✳ ❈♦♥❢❡r❡♥❝❡ ♦♥ ❉❛t❛❜❛s❡ ❛♥❞ ❊①♣❡rt ❙②st❡♠s ❆♣♣❧✐❝❛t✐♦♥s ✭❉❊❳❆✬✵✶✮✱ ▼✉♥✐❝❤✱ ●❡r♠❛♥② ✭✷✵✵✶✮ ✻✻✽✕✻✼✼ ✼✳ ❇♦♦❝❤✱ ●✳✱ ❘✉♠❜❛✉❣❤✱ ❏✳✱ ❏❛❝♦❜s♦♥✱ ■✳✿ ❚❤❡ ❯♥✐✜❡❞ ▼♦❞❡❧✐♥❣ ▲❛♥❣✉❛❣❡✿ ❯s❡r ●✉✐❞❡✳ ❖❜❥❡❝t ❚❡❝❤♥♦❧♦❣② ❙❡r✐❡s✳ ❆❞❞✐s♦♥✲❲❡s❧❡② ✭✶✾✾✾✮ ✽✳ ❖❜❥❡❝t ▼❛♥❛❣❡♠❡♥t ●r♦✉♣ ✭❖▼●✮✿ ❯♥✐✜❡❞ ▼♦❞❡❧✐♥❣ ▲❛♥❣✉❛❣❡ ❙♣❡❝✐✜❝❛t✐♦♥ ✶✳✹✳ ■♥t❡r♥❡t✿ ❤tt♣✿✴✴✇✇✇✳♦♠❣✳♦r❣✴❝❣✐✲❜✐♥✴❞♦❝❄❢♦r♠❛❧✴✵✶✲✵✾✲✻✼ ✭✷✵✵✶✮ ✾✳ ❈♦♥❛❧❧❡♥✱ ❏✳✿ ❇✉✐❧❞✐♥❣ ❲❡❜ ❆♣♣❧✐❝❛t✐♦♥s ✇✐t❤ ❯▼▲✳ ❖❜❥❡❝t ❚❡❝❤♥♦❧♦❣② ❙❡r✐❡s✳ ❆❞❞✐s♦♥✲❲❡s❧❡② ✭✷✵✵✵✮ ✶✵✳ ◆❛✐❜✉r❣✱ ❊✳✱ ▼❛❦s✐♠❝❤✉❦✱ ❘✳✿ ❯▼▲ ❢♦r ❉❛t❛❜❛s❡ ❉❡s✐❣♥✳ ❖❜❥❡❝t ❚❡❝❤♥♦❧♦❣② ❙❡r✐❡s✳ ❆❞❞✐s♦♥✲❲❡s❧❡② ✭✷✵✵✶✮ ✶✶✳ ❆♠❜❧❡r✱ ❙✳✿ P❡rs✐st❡♥❝❡ ▼♦❞❡❧✐♥❣ ✐♥ t❤❡ ❯▼▲✳ ❙♦❢t✇❛r❡ ❉❡✈❡❧♦♣♠❡♥t ❖♥❧✐♥❡✳ ■♥t❡r♥❡t✿ ❤tt♣✿✴✴✇✇✇✳s❞♠❛❣❛③✐♥❡✳❝♦♠✴❞♦❝✉♠❡♥ts✴s❂✼✺✺✴s❞♠✾✾✵✽q✴ ✭✶✾✾✾✮ ✶✷✳ ❘❛t✐♦♥❛❧ ❙♦❢t✇❛r❡ ❈♦r♣♦r❛t✐♦♥✿ ❚❤❡ ❯▼▲ ❛♥❞ ❉❛t❛ ▼♦❞❡❧✐♥❣✳ ■♥t❡r♥❡t✿ ❤tt♣✿✴✴✇✇✇✳r❛t✐♦♥❛❧✳❝♦♠✴♠❡❞✐❛✴✇❤✐t❡♣❛♣❡rs✴❚♣✶✽✵✳P❉❋ ✭✷✵✵✵✮ ✶✸✳ ▼❛r❝♦s✱ ❊✳✱ ❱❡❧❛✱ ❇✳✱ ❈❛✈❡r♦✱ ❏✳▼✳✿ ❊①t❡♥❞✐♥❣ ❯▼▲ ❢♦r ❖❜❥❡❝t✲❘❡❧❛t✐♦♥❛❧ ❉❛t❛❜❛s❡ ❉❡s✐❣♥✳ ■♥✿ Pr♦❝✳ ♦❢ t❤❡ ✹t❤ ■♥t❧✳ ❈♦♥❢❡r❡♥❝❡ ❯▼▲ ✷✵✵✶✳ ❱♦❧✉♠❡ ✷✶✽✺ ♦❢ ▲◆❈❙✳✱ ❙♣r✐♥❣❡r✲❱❡r❧❛❣ ✭✷✵✵✶✮ ✷✷✺✕✷✸✾ ✶✹✳ ●✐♦✈✐♥❛③③♦✱ ❲✳✿ ❖❜❥❡❝t✲❖r✐❡♥t❡❞ ❉❛t❛ ❲❛r❡❤♦✉s❡ ❉❡s✐❣♥✳ ❇✉✐❧❞✐♥❣ ❛ st❛r s❝❤❡♠❛✳ Pr❡♥t✐❝❡✲❍❛❧❧✱ ◆❡✇ ❏❡rs❡②✱ ❯❙❆ ✭✷✵✵✵✮ ✶✺✳ ❑✐♠❜❛❧❧✱ ❘✳✿ ❚❤❡ ❞❛t❛ ✇❛r❡❤♦✉s✐♥❣ t♦♦❧❦✐t✳ ✷ ❡❞♥✳ ❏♦❤♥ ❲✐❧❡② ✭✶✾✾✻✮ ✶✻✳ ❲❛r♠❡r✱ ❏✳✱ ❑❧❡♣♣❡✱ ❆✳✿ ❚❤❡ ❖❜❥❡❝t ❈♦♥str❛✐♥t ▲❛♥❣✉❛❣❡✳ Pr❡❝✐s❡ ▼♦❞❡❧✐♥❣ ✇✐t❤ ❯▼▲✳ ❖❜❥❡❝t ❚❡❝❤♥♦❧♦❣② ❙❡r✐❡s✳ ❆❞❞✐s♦♥✲❲❡s❧❡② ✭✶✾✾✽✮ ✶✼✳ ❘❛t✐♦♥❛❧ ❙♦❢t✇❛r❡ ❈♦r♣♦r❛t✐♦♥✿ ❯s✐♥❣ t❤❡ ❘♦s❡ ❊①t❡♥s✐❜✐❧✐t② ■♥t❡r❢❛❝❡✳ ❘❛t✐♦♥❛❧ ❙♦❢t✇❛r❡ ❈♦r♣♦r❛t✐♦♥ ✭✷✵✵✶✮

A Metamodel for Package Extension with Renaming Tony Clark1, Andy Evans2, and Stuart Kent3 1

King’s College London, UK [email protected] 2 University Of York, UK [email protected] 3 University of Kent, UK [email protected]

Abstract. Package extension and template mechanisms were originally proposed as part of the Catalysis method. It has since been suggested that they can be used to capture patterns and for aspect-oriented modelling and metamodelling. This paper provides a rigorous metamodel definition of the package extension mechanism. It turns out that the definition is more subtle than one might at first think, and some of the subtleties are exposed in the paper. The paper concludes with an overview of how the core definition may be expanded to include templates and to deal with a richer base language. Tool implementation is also discussed.

1

Introduction

Package extension and package template mechanisms have been identified as potentially useful mechanisms in both modelling and metamodelling. They were introduced as part of the Catalysis method in [6], as a means of separating out different subject areas of an application model into packages, which can then be merged using package extension. Package templates are then used to capture common patterns of modelling that can be reused from across applications and across domains. This work has since be recognised as one approach to aspect-oriented software design [10], and is similar to the model merge operation described in [4][5]. In metamodelling, the mechanisms are being used to assist with the definition of families of languages, in two ways. Package extension allows definitions of fragments of language to be developed separately and then merged to form complete languages; package templates allow patterns of language definition to be distilled and then applied consistently across the definition of languages and their components. This results in a consistently architected, more complete and readable definition. For more details on the application of these mechanisms to metamodelling see [1][2][3][8]. The 2U submission [1], in particular, has a definition of the central core of UML rendered in this way.

J.-M. Jézéquel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 305-320, 2002.  Springer-Verlag Berlin Heidelberg 2002

306

Tony Clark et al.

This paper is the first in a series that aims to provide a rigorous metamodel definition of the package extension and template mechanisms. The focus of this paper is the package extension mechanism defined on top of a base language for structural modelling, including packages (of course), classes, attributes, associations and constraints. Further papers will extend this definition in two ways: by layering a definition of templates on top; and by broadening the base language to include constructs for modelling dynamic behaviour. A metamodelling approach has been taken for three reasons: it makes the definition accessible to the wider modelling community; it provides direct input to tool builders, either through processing the definition through e.g. MOF tools, or by providing direct input to an implementation in an OO programming language; it is the industry standard way for defining languages such as the UML. A metamodel definition for a mechanism for composing packages by merging of elements has been proposed in [4][5]. The mechanism considered there is similar in principle to the Catalysis mechanism of package extension, but significantly different in execution. Further, the metamodel does not include detailed rules in OCL which dictate how specific kinds of elements get merged. In our experience, attempting to write out such rules helps identify significant failings in initial attempts at a metamodel; developing the metamodel described in this paper has reinforced this experience. The paper is structured as follows. Section 2 introduces the package extension mechanism through a carefully constructed example that highlights some of the issues with its definition. Section 3 provides a definition of the base language and Section 4 the definition of package extension itself. The example is used to help explain the metamodels. Section 5 conducts a brief discussion of some of the outstanding issues concerned with the definition, as well as some ideas for further work in this area.

2

Indicative Example

Fig. 1. Package extension example

A Metamodel for Package Extension with Renaming

307

Fig. 1 provides an example of package extension. This represents what the modeller would write. Fig. 2 represents an expansion of the child package that can be calculated from this. Package extension is shown by the usual UML generalisation arrow, and this may be optionally annotated with renamings. A renaming has the form m/n which says rename m by n. m and n can be qualified names (e.g. X::aY), though this is more commonly required for n than m. The example has one instance where m is qualified, to indicate that the class W gets put inside a new package S in Q.

Fig. 2. Expansion of extending package

On package extension, the default is for elements of the same name to get merged. Thus, in the example, the class W from each of the parents gets merged with the additions to W explicitly defined in Q. The result on expansion is a class W with three attributes. Renamings allow this rule to be overridden, by allowing elements to be renamed which then forces or avoids a merge under the default rule. Thus X and Y in package R are forced to merge with Y and Z in package P, respectively, by renaming them. With package extension, it is often the case that one change in naming (e.g. changing the name of a class) precipates a whole series of renamings (e.g. changing the name of association ends which refer to that class). This is the problem that package templates solve, by allowing names to be calculated from a single source. For example, names of the association ends can be calculated from the name of a particular class, so changing that name causes the other renamings to be generated by default. Generated renamings can always be overridden by a further explicit renaming. Sometimes a set of package extensions will not be well-formed. For example, if the attribute in P::W were called a rather than b, then it would not be possible to merge P::W and R::W, because the types of the attribute a from each part would be incompatible. There are stronger and weaker notions of incompatibility: a strong notion would be that the types must be the same (subject to any renaming) and a weaker version that they must have a common subtype (or one is the subtype of the other). For this paper we encode the weaker notion, just to show that it can be done (it is more difficult to get right). It is not sufficient for the definition just to provide a representation of the extension arrows, the renamings and/or the additions explicitly provided in the child package. The definition must also specify how the contents of the child gets

308

Tony Clark et al.

calculated, and conditions under which the package extension is conformant. There is a range of possible interpretations of conformance [6], and we recognise that further work is required to provide a package extensions mechanism that offers alternative notions of conformance for the modeller. Provided here is a definition of conformance whereby it is possible to view an object configuration of a conformant child package as if it were a configuration of the parent. The need to support renaming and merging of elements, and the desire to characterise conformance, is what makes the definition non-trivial. We provide a metamodel definition of the mechanisms, restricted to a subset of UML suitable for structural modelling. To avoid a circular definition this paper uses a subset of UML that does not already include the mechanisms. The subset is similar to that used by the USE tool [9]. We also have a prototype tool that supports this subset [3].

3

Base Language Metamodel

We begin with a definition of a base language that includes classes, associations, attributes, types (including Set, Int, String and Bool), packages and a simple definition of class inheritance. A discussion of how to make the latter more sophisticated is given in the concluding section. For reasons of space, the formal constraints have been omitted. A copy of the paper including constraints is available from www.cs.ukc.ac.uk/people/ staff/sjhk. Fig. 3 is the class diagram introducing some of the basic model elements.

Fig. 3. Classes, Associations, Attributes, Types

An attribute is a property, a model element that can be referred to in navigation expressions of constraints (see below). A property has a type, which may be an element type or a Set type. A set type is defined by its element type. Thus we can

A Metamodel for Package Extension with Renaming

309

have sets of objects of a particular class, and values of primitive type Int, String or Bool. Constraints are required to ensure that: • • •

a class owns a set of attributes, whose names must be unique; a class can not be it’s own parent; an association end is navigable iff it is associated with a corresponding attribute in the source class, whose type is a set parameterised by the target class.

Association ends also have a multiplicity, whose bounds, here, are represented by lower and upper. For this paper, we have restricted the language to binary associations, so associations have two association ends. A further constraints will be required to tidy up the connection between association ends.

Fig. 4. Constraints and queries

Fig. 4 continues with the definition of Class, which also owns queries and constraints. A constraint is associated with an expression, and a query owns a number of typed (input) parameters. A query is also a property, so inherits a type and a name from there. Constraints are required to ensure that: • •

the expression associated with a constraint owned by a class only uses the properties of that class, where the properties of a class are defined to be the union of owned attributes and queries; the names of parameters for a query must also be unique.

This paper does not provide a definition of all possible expressions that can be used to write constraints for reasons of space (see e.g. [7]). Instead, it considers just enough to illustrate how constraints get treated under package extension: property call expressions and equality between them. Specifically, property call expressions refer to properties of classes, which can be redefined under package extension, as illustrated in Section 2. This fragment of a constraint expression language is defined by Fig. 5.

310

Tony Clark et al.

Fig. 5. Expression

PropertyCallExpression is defined recursively, as a property expression preceded by another set expression whose type has access to the property being called (so must be a class), and its type is a set of the elements returned by the property. Each expression is defined in the context of a universe, which provides access to the primitive types, and a class which provides the type of the self expression. For details of Universe see Fig. 6. Constraints will be required to define the properties and types for each kind of expression and to make sure that the universe and class get passed down. The constraint for Equals is given below as an example: context Equals inv: property = lhs.property->union(rhs.property) and type = universe.ownedBool and rhs.type = lhs.type and rhs.class = class and rhs.universe = universe and lhs.class = class and lhs.universe = universe

Fig. 6. Universe and packages

A Metamodel for Package Extension with Renaming

311

PropertyCallExpression may be further specialised to AttributeCallExpression and QueryCallExpression, but the details are not relevant to this paper. Fig. 6 deals with packages and introduces the concept of universe. The universe, which is also a package, holds one copy of each primitive type, which can be accessed by all typed elements used within that universe, and maximum one copy of each set type for each element type. A constraint will be required to capture the latter in addition to the constraint that a universe must own itself. Universe provides an approach to dealing with the thorny problem of ensuring that one does not have copies of primitive types in instances of the metamodel, which causes problems, for example, when comparing types of properties. An alternative approach is provided in [7]. Packages contain classes, associations and packages. A package also has a universe, which is the universe of its owning package. By making a universe its own owner, the universe of a universe is itself. Constraints will be required to define the types in scope for a package, which are the primitive types in its universe (not the classes) union the classes in scope, and classes in scope, which are the package’s own classes union the classes in scope of owned packages. Finally, constraints are also required to ensure that: • • •

4

properties, association ends and parameters only use types in scope; the Expression associated with a constraint is of boolean type (indeed the one belonging to the correct universe), and should be interpreted in the context of the owning class, and universe accessible from that class; names of classes, packages and associations are unique in packages.

Package Extension Metamodel

Before presenting the metamodel, we discuss one of the central issues in providing a definition of package extension. The issue arises because of the possibility of merging and extending elements in a child package. Fig. 7 is a stylised depiction of a metamodel instance for part of Fig. 1. Names of objects reflect the names of model elements they represent. Packages are shown by mini package symbols. Packages contain classes, and classes attributes. The types of attributes are indicated by directed links (targeted on the type). Associations have not be shown to avoid clutter – in the metamodel definition of the base language they have been defined to induce attributes (one per association end) on the appropriate classes. The triangle symbol indicates instances of extensions. Package extensions contain class extensions which contain attribute extensions. Not all attribute extensions have been shown, to avoid clutter. The class W has been omitted from all packages, as have constraints. Not all associations are included. The grey dashed links (1 & 2) indicate alternative ways of representing the information shown in grey. (1) is an invalid representation; (2) is a valid alternative. With (1), the idea is that because the class X remains seemingly untouched by the package extension from P (it is not renamed; Q adds nothing to it; R contributes nothing, as its X is renamed to Y), it is not necessary to copy it down into Q, but instead point directly at it from Q. However, look more closely and you see that X is changed

312

Tony Clark et al.

implicitly. Specifically, in the context of Q the type of the attribute y should be the Y in Q, not the Y in P. Y must be copied down, because it does change – Y in Q is the merge of Y in P and Y in R. In contrast, (2) is a valid alternative because the class V truly does remain unchanged in Q. So in this case it is not essential to copy down V.

Fig. 7. Naive vs. partial vs. complete copy down

This example illustrates that changes to elements inherited from a parent package need to be made even if those changes have not been explicitly modelled. One way to deal with this is just to copy down everything from the parent, enacting any changes as necessary. The (maximal) copy-down is structure preserving, so, for example, the attribute y is still contained in the class X, and its type points to class Y, though this time the copy of Y in Q. Whilst copy-down leads to a correct definition, it does have some built-in redundancy. In all this, the class V remains completely unaffected, and, importantly, completely unchanged in package Q (unlike X, it has no attributes that need to change their type). However, it has still been copied down, which is unnecessary. The alternative represented by (2) would only be to copy down strictly what needs to be copied down, a minimal copy-down, and refer directly to anything that remains unchanged. The definition provided here admits both maximal and minimal copy down views. That is, the definition is abstract enough to permit an implementation which chooses to copy everything down, or one which chooses only to copy down that which is necessary. Furthermore, we have isolated the conditions that express whether or not a particular extension is a minimal or maximal copy down. 4.1

Core

Fig. 8 introduces the notion of Extension, which represents the extension of one element by another. An element may be associated with a set element. For

A Metamodel for Package Extension with Renaming

313

example, a package is an element whose elements are packages, classes and associations. An Extension has a set extension of Extension, which has a set explicitExtension as a subset. context Extension inv: explicitExtension = extension->select(e | e.explicit)

An explicitExtension represents an explicit redefinition (such as a renaming) on an extension. So, if on a package extension we explicitly state that a class is renamed, this will be represented by an explicitExtension in the corresponding metamodel instance.

Fig. 8. Extensions

There is an attribute on Extension which indicates whether or not its extensionAreConformant. This will be the case provided that (a) there is exactly one extension for each element in the parent, that (b) each extension is conformant and (c) has a child that is either an owned or inherited element of the child of the containing extension, and that (d) each implicit extension (those which are not explicit) is locally unchanged. context Extension inv: extensionAreConformant = (extension.parent = parent.element->asBag and extension-explicitExtension->forAll(e | e.isLocallyUnchanged) and extension->forAll(e | e.isConformant and (e.child = e.parent or child.ownedElement->includes(e.child))))

The idea here is that an explicitExtension can change the child element in a way that is conformant with the parent (for example, it can change the name), but that an implicit one can not. It is the very fact of allowing the child of an extension either to

314

Tony Clark et al.

be the parent (i.e. an element that is inherited) or an owned element (condition (c)) which permits a complete or partial copy-down implementation of this definition. The elements of an element are either owned or inherited. The ownedElement are defined for each particular kind of element. The inheritedElement are defined to be all the elements which have been brought in by extension from a parent element. The universe of contained elements is the universe of the containing element. context Element inv: inheritedElement = element->select(e | e.childOf.parent = {e}) and ownedElement = element - inheritedElement and element.universe = {universe}

Additional constraints are required to define ownedElement for each kind of element (package, class etc.). The constraint for Class is given below. Others follow similarly. context Class inv: ownedElement = ownedAttribute->union(ownedQuery) ->union(ownedConstraint)

For an extension to be conformant at least its extensionAreConformant. For an extension to be locallyUnchanged it must be conformant. Other rules are specific to kinds of extension (for example the name must not be changed). An extension is unchanged if, in addition to being locallyUnchanged, all its extension are also unchanged. Of course if the extension does not contain any other extension, then it will be unchanged if it is locallyUnchanged. context Extension inv: isConformant implies extensionAreConformant and isLocallyUnchanged implies isConformant and isUnchanged = isLocallyUnchanged and extension ->forAll(e | e.isUnchanged))

We can now express the conditions which capture whether an extension is a maximal (complete) or a minimal (most efficient partial) copy-down. context Extension inv: isMaximalCopyDown = (extension->forAll( e | e.isMaximalCopyDown) and child.inheritedElements-> isEmpty) and isMinimalCopyDown = extension->forAll( e | e.isMinimalCopyDown and e.isUnchanged implies e.parent = e.child)

That is, a maximalCopyDown extension is one where the child has no inherited elements (so all elements of the parent must have been copied), and a minimalCopyDown is one in which contained extensions whose child is completely unchanged (which, recall, also means that extensions contained by that extension must have unchanged children) have just reused the parent and not created a copy. This paper only considers the case where package extensions are contained in the universe, not in packages. The latter would require consideration of what it means to extend an extension. This will be dealt with in a follow-up paper. Extensions in a universe may only be between packages contained in that universe: context PackageExtension inv: owningUniverse.ownedPackage ->includesAll({parent,child})

A Metamodel for Package Extension with Renaming

4.2

315

Different Kinds of Extension

As already indicated in Fig. 8 there are different kinds of extension. Fig. 9 elaborates the package, class and association extension. First, a constraint is required to ensure that a package may not extend itself either directly or indirectly. context Package inv: allParent = childOf.parent->union(childOf.parent.allParent) and allParent->excludes(self)

Fig. 9. Package, class and association extension

A similar constraint is not required for Class or Association, as the rules governing how extensions between those elements are constructed are dictated entirely by the package extension that owns them. The definition of extension, isConformant and isLocallyUnchanged needs to be refined for each kind of extension. There is nothing surprising here, except to note that the conformance of ClassExtension is also dependent on the parent class’ inherited classes being preserved in the child. context ClassExtension inv: extension = ownedAttributeExtension ->union(ownedConstraintExtension) ->union(ownedQueryExtension) and isConformant = (extensionAreConformant and child.parentClass = parent.parentClass->collect(c | owningPackageExtension.parentClassLookup(c).child)) isLocallyUnchanged =(isConformant and parent.name = child.name) context AssociationExtension inv: extension = ownedAssociationEndExtension and isConformant = extensionAreConformant and isLocallyUnchanged =(isConformant and parent.name = child.name) context PackageExtension inv: extension = ownedAssociationExtension ->union(ownedClassExtension)

316

Tony Clark et al. ->union(ownedPackageExtension) and isConformant = extensionAreConformant and isLocallyUnchanged =(isConformant and parent.name = child.name)

parentClassLookup(c:Class) is defined by: context PackageExtension inv: parentClassLookup(c) = ownedClassExtension->select(ce | ce.parent = c)

Fig. 10 defines the extensions at the next level down, and, again, is accompanied by a series of invariants defining isConformant and isLocallyUnchanged.

Fig. 10. Property & AssociationEnd extensions

An AttributeExtension is conformant if the type of the child is the type, or a supertype of the type, corresponding to the type of the parent under this package extension, thereby capturing the weaker form of type compatibility alluded to in Section 2. It isLocallyUnchanged if its name has not changed. context AttributeExtension inv: extension->isEmpty and isConformant= if parent.universe.type->includes(parent.type) then child.type=parent.type else {child.type}->union(child.type ->oclAsType(Class).allClassParent) -> includes(owningClassExtension.owningPackageExtension. parentClassLookup(parent.type->oclAsType(Class)). child) isLocallyUnchanged =(isConformant and parent.name = child.name)

Similarly for AssociationEndExtension, except this time one also needs to check that the cardinality constraints are only strengthened to remain conformant, or remain the same to be locally unchanged.

A Metamodel for Package Extension with Renaming

317

context AssociationEndExtension inv: extension->isEmpty and isConformant = (owningAssociationExtension.owningPackageExtension. parentClassLookup(parent.source). parentPropertyLookup(parent.attribute).child = child.attribute and parent.upper >= child.upper and parent.lower union(ownedQueryExtension)->select(ce | ce.parent = p)

A QueryExtension is like an attribute extension, in constraining the type of the child, and like a ClassExtension, in that it has ownedParameterExtension (ClassExtension has ownedAttributeExtension), which must be conformant. context QueryExtension inv: extension = ownedParameterExtension and isConformant = (extensionAreConformant and if parent.universe.type->includes(parent.type) then child.type=parent.type else {child.type}->union(child.type ->oclAsType(Class).allClassParent) -> includes(owningClassExtension. owningPackageExtension.parentClassLookup( parent.type->oclAsType(Class)).child)) isLocallyUnchanged =(isConformant and parent.name = child.name) context ParameterExtension inv: extension->isEmpty and isLocallyUnchanged =(isConformant and parent.name = child.name) and isConformant = if parent.universe.type->includes(parent.type) then child.type=parent.type else {child.type}->union(child.type ->oclAsType(Class).allClassParent) -> includes(owningClassExtension. owningPackageExtension.parentClassLookup( parent.type->oclAsType(Class)).child))

Finally, a ConstraintExtension is defined to own an ExpressionExtension (Fig. 11), and is constrained according to form: context ConstraintExtension inv: isLocallyUnchanged = (isConformant and parent.name = child.name) and isConformant = ownedExpressionExtension.isConformant(owningClassExtension) context ExpressionExtension inv: isConformant(ce) = child.matches(parent,ce)

matches(e:Expression,ce:ClassExtension) is defined recursively. The form is to check that the expression matches in kind with the expression passed as ar-

318

Tony Clark et al.

gument, and that the sub-expressions, where present, match. The interesting constraint is attached to PropertyCallExpression, which ensures that the appropriate property of the child of the class extension passed as argument is used in the expression.

Fig. 11. Constraint extension context Equals inv: matches(e,ce) = (e.oclIsKindOf(Equals) and lhs.matches(e.oclAsType(Equals).lhs,ce) and rhs.matches(e.oclAsType(Equals).rhs,ce)) context PropertyCallExpression inv: matches(e,ce) = (e.oclIsKindOf(PropertyCallExpression) and ((lhs.matches(e.oclAsType( PropertyCallExpression).lhs,ce)) and property = ce.parentPropertyLookup(e.oclAsType( PropertyCallExpression).property).child)) context Self inv: matches(e,ce) = e.oclIsKindOf(Self)

4.3

Multiple and Indirect Parents

The definition automatically deals with the case when a package may have multiple parents, by virtue of the fact that there are constraints on the specific kinds of element (Package, Class, Query) which ensures that names are unique amongst the individual groupings of elements (Class/Association/Package, Attribute/Query, Parameter) which they contain (see Section 3). For example, if a package Q extends a parent P and a parent R, both of which contain a class A with an attribute b, then, provided that the elements are not renamed on extension, the name uniqueness constraints require there only to be one class called A in Q, and that class can only have one attribute called b. The definition of extension ensures that A in Q must be conformant with A in both parents, which in turn requires the attribute b to be conformant with its correspondents in the parents, which will only be the case if its type is compatible with the correspondent of the type of b in each of the parents. The definition also ensures that the extension relationship between packages is transitive, so that a child not only inherits the elements introduced by a parent, but also the elements inherited from parents of that parent (i.e. indirect parents of the

A Metamodel for Package Extension with Renaming

319

child). This comes from the fact that for an extension to be conformant, the extensions it contains must be conformant, and one of the conditions for this to hold is that there must be exactly one extension per element contained in the parent (see page 313). The elements contained in the parent are defined to be the owned elements union any inherited elements (see page 314), so, whether or not elements are copied down on extension, a parent will include both elements it has introduced as well as elements inherited from its own parents, so the child will also inherit both of these groupings.

5

Conclusions and Future Work

We have provided the core part of a metamodel definition of package extension and applied this to a sizeable base language. The definition includes a rich set of wellformedness constraints, which also provides a specification of what it means for an extension to be conformant, whether an extension characterises a maximal or minimal copy-down approach, and what the result of calculating the expansion of a child package (required for any respectable tool) should be. We are working on providing a metamodel definition of the concrete syntax and its mapping to abstract syntax, and algorithms that will perform the expansion of child packages according to the specification provided here. We are particularly interested in an algorithm that results in a minimal copy-down structure for all extensions, as this should facilitate another direction of research – the generation of a standard OO framework API from a graph of package extensions. Such an ability would allow metamodels organised using package extension to live alongside current approaches to tool building, which rely on OO frameworks. A minimal copy-down structure would be the most appropriate input for this generation as a goal there is to ensure that the API is as small as possible, without any loss of information. The definition itself needs to be expanded in various ways. Firstly, a definition of templates needs to be provided. This has already been worked out in principle, and is currently being written up. Secondly, the base language needs to be expanded, and as this is done the interaction of package extension with new modelling elements needs to be considered. We would like to be able to handle the following additions to the base language: • • •

•

Packages could themselves own package extensions (currently only the universe does), which means that one must consider how package extensions get extended. Class inheritance/generalisation could also be given a renaming mechanism. The interaction of this with package extension may be non-trivial. Package imports needs to be considered. One view here is that imports is just a different kind of extension, one that, on the one hand, allows a subset of classes and associations from a package to be imported, yet on the other, requires these to be brought in unchanged (so, for example, no additions can be specified in the child). Constructs for modelling dynamic behaviour, for example state diagrams. This should be a matter of inventing new kinds of element and new kinds of

320

Tony Clark et al.

extension, and then stipulating specific rules for isConformant and isLocallyUnchanged. Thirdly, we would like to expand the metamodel to integrate other forms of composition between packages, such as those described in [4][5].

References [1]

2U Submitters. Submission to UML 2.0 Infrastructure and Superstructure RFPs Home page. http://www.2uworks.org. [2] Alvarez J.M., Clark A., Evans A. and Sammut P. An action semantics for MML. In C. Kobryn and M. Gogolla, editors, Proceedings of The Fourth International Conference on the Unified Modeling Language (UML'2001), LNCS. Springer, 2000. [3] Clark A., Evans A. and Kent S. Engineering modelling languages: A precise meta-modelling approach. In Proceedings of ETAPS 02 FASE Conference, LNCS. Springer, April 2002. [4] Clarke S. Composition of Object-Oriented Software Design Models, PhD Thesis, Dublin City University, January 2001. [5] Clarke S. Extending standard UML with model composition semantics. To appear, in Science of Computer Programming, Elsevier Science, 2002. [6] D'Souza D. and Wills A. Objects, Components and Frameworks With UML: The Catalysis Approach. Addison-Wesley, 1998. [7] OCL Submission Team. Response to the UML 2.0 OCL RfP, Revised Submission, Version 1.3 March 1, 2002, available from http://www.klasse.nl/ocl/ [8] Reggio G. and Astesiano E. A proposal of a dynamic core for UML metamodelling with MML. Technical Report DISI-TR-01-17, DISI, Universit di Genova, Italy, 2001. [9] Richters M. and Gogolla M. Validating UML models and OCL constraints. In A. Evans, S. Kent and B. Selic, editors, Proceedings of the third International Conference on the Unified Modeling Language (UML'2000), York, UK, LNCS, Springer. October 2000. [10] Tarr P., Ossher H., Harrison W. and Sutton Jr. S. M. N degrees of separation: Multidimensional separation of concerns. In Proceedings of the 21st International Conference on Software Engineering (ICSE’99), pages 107–119, May 1999.

Applying MDA Concepts to Develop a Domain CORBA Facility for E-learning Luis Anido, Manuel Caeiro, Judith Rodr´ıguez, and Juan Santos

ˆ‰Š‹Œ‹Ž‰ ‘‰ ’“‰”‰Œ´ıa Telem´atica, ETSI Telecomunicaci´on E-36210, Campus Universitario s/n, Vigo, Spain {lanido,mcaeiro,jestevez,jsgago}@det.uvigo.es

Abstract. A well-conceived service or facility is always based on an underlying semantic model that is independent of the target platform. However, the model may not be distilled explicitly, and this is the case with OMG’s vertical domain specifications because the model is not expressed separately from its IDL interfaces. Therefore, these services and facilities have not received the recognition and use that they deserve outside of the CORBA environment. This paper reports on the application of MDA concepts on the development of a draft proposal for a Domain CORBA Facility for e-learning. In order to maximize the utility and impact of the domain facility in the MDA, it was modelled in the form of a normative Platform Independent Model (PIM) expressed using UML, augmented by a normative Platform Specific Model (PSM) expressed using the UML profile for CORBA and IDL interface definitions.

1

Introduction

CORBA [1] is an object-based distributed architecture that allows distributed and heterogeneous applications to interoperate on a network. CORBA is a standard defined by more than 800 companies that form the Object Management Group (OMG). Over a software bus, the Object Request Broker (ORB), CORBA objects interact with each other via standard “contracts” written in the Interface Definition Language (IDL) [2]. The OMG has also defined the interfaces for 15 basic services for distributed computing (e.g. Naming Service, Event Service, etc.). Nowadays, a sizeable percentage of OMG activity is focused on standardizing services and facilities in specific vertical markets through Domain Task Forces (DTFs). Adoption of such facilities benefits both interoperability and software reuse and contributes to the standardization of that domain. Currently, there exist several of these domain specifications under the OMG supervision. Standardizing components at a platform level, in terms of standards such as CORBA, is certainly a viable contribution to solving the integration and interoperability problem. These specifications consist of interfaces written in the OMG IDL language with accompanying semantic description in English text. As a consequence, all of them present the same problem [3]: the underlying semantic model is not expressed separately from its IDL interfaces. Since their models are hidden, these services and facilities have received neither the recognition nor the J.-M. J´ ez´ equel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 321–335, 2002. c Springer-Verlag Berlin Heidelberg 2002


322

Luis Anido et al.

widespread implementation and use that they deserve outside of the CORBA environment. A well-conceived service or facility is always based on an underlying semantic model that is independent of the target platform. Thus, in order to maximize the utility and impact of OMG domain facility specifications in the Model Driven Architecture (MDA) [3], they will be in the form of normative Platform Independent Models (PIMs) expressed using UML, augmented by normative Platform Specific Models (PSMs) expressed using the UML profile and interface definitions for at least one target platform. The common basis in the MDA will promote partial generation of code as well, but implementation code, of course, will not be standardized. In this paper we propose (c.f. Sec. 2) an MDA-oriented methodology to produce standardized service architectures with a visible and separate underlying conceptual model. We have adapted well-known software development processes, oriented to obtain large and complex systems, to the definition of software services which, in turn, are used to develop such systems. We have applied this methodology to develop a Domain CORBA Facility for e-learning (c.f. Sec. 3), where an important standardization process is being carried out [4]. E-learning standardization efforts can be classified into two levels: 1. Specification of the information models involved. Several proposals have been produced to specify the format, syntax and semantics of data to be transferred among heterogeneous platforms (e.g. courses, educational metadata, learner profiles, evaluation objects, etc.). International standardization bodies (e.g. ISO, IEEE, CEN) and main educational software consumers worldwide (e.g. the Aviation Industry, the US Department of Defense) are actively involved in this process. 2. Specifications of the architectures, software components and provided interfaces. The work at this second level attempts to identify the software components involved in e-learning systems and the interfaces that must be provided by these components. So far, results have been scarce since most standardization bodies have been focused on the first level of standardization. Available proposals have not defined interfaces for the proposed architecture components [5] or do not cover the whole functionality needed in a complete e-learning environment [6]. Our proposal for a new Domain CORBA Facility [7], named CORBAlearn, is a contribution to the second level of standardization in the e-learning domain. The proposed standard includes a Reference Architecture, which is independent of any underlying platform. Such a standard will have a broad impact as the platform-independent model will be useful even in middleware environments other that CORBA. At the same time we took into account available proposals from the first level of standardization. Defined CORBAlearn services are able to deal with information models compliant with the main specifications but with no ties to any concrete proposal.

•––—˜™š› œD• CšžŸ– ¡ 2

323

Software Services Development Process

The proposed methodology follows the guidelines established by the OMG’s MDA and is based on the Unified Software Development Process [8] together with the recommendations by other authors [9]. The Unified Process guidelines are oriented to obtain a, possibly large, final product. Nevertheless, we need a methodology to define a standardized service architecture where those final applications can be built over. On the one hand, the Unified Process identifies a set of iterations in the software development process: requirements, analysis, design, implementation and test. It is an iterative and incremental process, centered on the architecture and driven by use cases. Designers begin by capturing customer requirements as use cases in the Use Case Model. Then, the next stages consist in analyzing and designing the system to meet the use cases, thus creating first an Analysis Model, a Design Model and a Deployment Model. Then, final development phases are modelled through an Implementation Model. Finally, developers prepare a Test Model that enables them to verify that the system provides the functionality described in the use cases. On the other hand, Bass [9] states that a Reference Model and a Reference Architecture are previous steps toward an eventual software architecture. The Reference Model is a division of the functionality together with the corresponding data flow between the identified components. Whereas a Reference Model divides the functionality, a Reference Architecture is the mapping of that functionality onto a system decomposition. Our proposed methodology (c.f. Fig. 1) includes a Reference Model as an initial stage of the development process to improve capture of requirements, and a Reference Architecture as an intermediate stage with a visible and platform independent model of the service architecture. An underlying platformindependent semantic model is used as a starting point for further, particular software service definition. Therefore, we are following the guidelines proposed in the MDA. The MDA separates certain key models of a system, and brings a consistent structure to these models. Models of different systems are structured explicitly into Platform Independent Models (PIMs) and Platform Specific Models (PSMs). Our PIM will be the Bass’ Reference Architecture, which is obtained, in turn, from Unified Process PIM artifacts (Use Case Model and service packages from the Analysis Model ). PSMs will correspond to subsequent Unified Process phases. How the functionality specified in a PIM is realized is specified in a platform-specific way in the PSM, which is derived from the PIM via some transformation. PIM artifacts are modelled using the Unified Modelling Language (UML) [10]. This is the ubiquitous modelling notation used and supported by every major company in the software industry. PSMs artifacts are modelled using the UML profile for the target platform. In our case, we used the UML profile for CORBA [11].

324

Luis Anido et al.

Domain Analysis Team Experience

Unified Software Development Process 1

Use Case Model

Reference Model

2

Identification of actors Capture of functional requirements

Analysis Model

CONCEPTUAL ARCHITECTURE Platform Independent

CORBA

3 wrapper

Design Artifacts

Reference Architecture

Offered Interface Definition

wrapper A

3 3.1

UML Profile for CORBA IDL

6

Value added services

Fig. 1.

5

Design Model

4

Use Case Realization Service Packages

Domain CORBA Facility

wrapper B

CORBAlearn

CORBAlearn

Final System A

Final System B

¢£¤£lopment methodology

Applying the Software Services Development Process to Develop a Domain CORBA Facility for E-learning The Reference Model

As stated before, the first stage in the methodology is the identification of a Reference Model (step 1 in Fig. 1). This is a business model where the key agents participating in the domain under study and the data flows among them are identified. For this identification, an exhaustive analysis of the most outstanding e-learning systems (some comparatives from other authors were taken as a reference [12, 13]), the proposed specifications from the main contributors to the e-learning standardization [4], and previous authors’ experience [14, 15] have been used. We have identified three elements in a Reference Model for e-learning (c.f. Fig. 2): – Educational Content Providers (ECPs) are responsible for developing learning objects. They are equivalent to publishers in conventional education. – Educational Service Providers (ESPs) are the schools, universities, or academic institutions in these virtual environments. ESPs use ECPs to access, maybe under payment, online courses to be offered at their institutions. – Brokers are responsible for helping both learners and ESPs to find suitable learning resources. 3.2

The Use Case Model

Once established the high level components of the system in the Reference Model, their functional requirements from clients’ viewpoint must be captured and docu-

¥¦¦§¨©ª« ¬DA Concepts

325

Fig. 2. Reference Model for the e-learning domain mented. Firstly, it is necessary to model the clients of the domain under consideration. We decided to use the ERILE recommendation [16], which is the pioneer specification identifying the actors that should be considered in standardized e-learning environments and it is widely recognized among the e-learning community. Secondly, a requirements analysis for these actors is needed. This is mainly modelled using use case diagrams, where the interaction of a particular actor with any of the elements from the Reference Model is depicted. Just the common functional aspects of the target domain must be considered because the eventually defined software services should be as general as possible, and therefore suitable for most final e-learning applications. The Use Case Model (step 2 in Fig. 1) was derived from a successive refinement process. As the use cases mature and are refined and specified in more detail, more of the functional requirements are discovered. This, in turn, leads to the maturation of more use cases. Use cases are not selected in isolation, they drive the system architecture and the system architecture influences the selection of the use cases. Therefore, both the system architecture and the use cases mature together. This process led to 215 use cases. As an example, Fig. 3 shows a use case diagram for the ERILE Tutor in his interaction with the ESP. The diagram gathers the different tasks the Tutor is responsible for: learner assessment and tracking, communication with learners, grading and supervision of the learning objects used in the system. Use cases are described in a twofold way. In the one hand, informal English text descriptions allow a first approach to captured requirements. On the other hand, a more formal description is provided following the table-based format proposed by Cockburn [17]. This format includes, among others, pre and post conditions, triggers, description and concrete steps, extensions and sub-variations. Both of them are used in the following process stage.

326

Luis Anido et al.

Select Learner

Grade

Access Tracking Data

Assess

Communicate with Learner

Tutorize

Tutor Update Learner Transcript

Communicate with Learner Off-Line

Communicate with Learner On-Line

Supervise Course

Comment Learning Resource

Fig. 3. Use case diagram for the Tutor in his interaction with the ESP 3.3

The Analysis Model

The Use Case Model is the starting point to define an Analysis Model (step 3 in Fig. 1). In analysis, use cases are further studied from the designer’s point of view. As a consequence, a deeper knowledge of the system is achieved. From an initial analysis of the use cases, a set of analysis packages for each element of the Reference Model is defined. Analysis packages group those use cases that are functionally related. Then, every package is analyzed separately, possibly by different teams, in order to identify analysis classes for them. We identify those classes that are able to realize cooperatively the functionality captured in use cases. Identification of analysis classes for every package is an iterative process. First, obvious classes are directly identified from the domain analysis. Then, from the realization of every use case new classes come up. However, whenever possible, we must reuse existing analysis classes, maybe adding new responsibilities. Three types of classifiers are used at this stage: –

boundary classes. They model the interaction between the system and its actors and other external systems.

–

control classes. They represent the needed coordination and sequencing among analysis classes in order to allow the realization of use cases.

­®®¯°±²³ ´DA Concepts –

327

entity classes. They are used to model persistent data. Basic access (read/write) operations are allowed from a boundary class. More complex operations need the intermediation of, at least, one control class.

Fig. 4 presents the analysis classes identified for the realization of the use cases presented in the previous subsection. Most entity classes encapsulate information models coming from the first level of e-learning standardization. Also, the Coach control class has been taken from the IEEE Learning Technology System Architecture (LTSA) [4]. Finally, three boundary classes were defined to represent user interfaces used by Tutors in different scenarios. All use cases presented in Fig. 3 can be realized [7] through collaboration of those classes included in Fig. 4. A final step at this stage is the identification of service packages. A service package groups those analysis classes offering basic common services useful for the development of distributed and interoperable systems. Classes in a service package have a strong relationship among them, offer basic services, manage the same underlying standardized information models and, therefore, tend to change together. They offer the basic functionality required to build final systems and

0..1 Course Structure Communication UI Transcript

0..1 Learner Profile

Coach

Security

Learner Supervision UI

SCO Trace 0..n

Course Trace 0..n

1 Analyzer

1

Course Supervision UI

Learner Record

Comment

Fig. 4. Analysis classes for the Tutor requirements from the ESP

328

Luis Anido et al.

allow those responsible for developing new systems to reuse service packages. In short, classes that can be easily reused to build a wide range of different applications for the domain in question are included in a service package. Classes representing application-specific functionality or that deal with data whose underlying model has not been standardized yet are kept out of service packages and included in the wrapper software layer (c.f. Fig. 1). Fig. 5 shows the services packages identified for the ESP: – Learner Administration. It offers services to develop management systems for Learners administrative information. Actual implementations should offer introspection mechanisms to identify supported profile data models. This subsystem also provides business logic for Learners registration and enrollment. – Employee Administration. It supports administrative information for Tutors, Teachers and Administrators. – Course Repository. It offers course management and storage. – Catalogue Management. It handles course descriptions for the ESP, and provides mechanisms to develop cataloguing and course searching systems. It uses the services provided by Learner Administration to extract learner’s profiles in order to provide customized searching services. – Unpackaging Management. It provides services to support course unpacking. It depends on Course Repository and Catalogue Management to unpack educational resources and course descriptions included in a course package. – Runtime Environment. It offers basic mechanisms to construct runtime environments, including course navigation, evaluation and assessment, and adaptation to learners. It is based on the LTSA proposal. It depends on Course Repository to obtain educational contents from courses, and on Learner Administration for learner’s record update and to extract learner’s profiles. Only analysis classes that meet the above presented requirements to be included in a service package are presented in the figure. The rest of the analysis classes were assigned to the wrapper. Fig. 5 also presents dependencies among service packages (wide arrows). These dependencies appear as a consequence of use case realizations where there are classes from different packages involved. In any case, these dependencies are not a restriction since all of them are from less to more basic service packages. For example, the Runtime Environment depends on the Course Repository and Learner Administration packages. We can assume that whenever we need a Runtime we will always have at our disposal a Course Repository to extract contents from, and a Learner Administration system to obtain and update learner data. We decided to separate them as they manage different standardized data models and provide different functionality. A standardized interface will define the communication among them. 3.4

The Reference Architecture

Service packages from the Analysis Model are the foundation for the Reference Architecture (step 4 in Fig. 1), which is the Platform Independent Model in our

µ¶¶·¸¹º» ¼DA Concepts

Employee Administration

Course Repository

(from Administration)

(from Courses)

Employee Relations

Learning Element

0..1 0..1 Employee Security

Employee Prefere nces 0..1

1

329

Evaluation Element

0..1 1..n

Employee Personal

Employee Profile

Employee Capabilities Learning Resource

1

SCO 1..n

1..n 1 Employee Record Course

Reviewer Record

Course Structure

Teacher Record Tutor Record

Unpackaging Management (from Courses)

Runtime Environment Unpackager

(from Learning Environ ment)

Catalogue Management Evaluator

(from Courses)

Presentation Manager Coach

Course Trace

SCO Trace

SCO State

Course Preference

Publication Configuration

Course Description

Learner Query A dapter

Search Engine

Course Interaction

Learner Administration (from Administration)

Enrolment Handler

Course Configuration

0..1 Preferences

0..1

Learner Record 1 0..n

1

Relations 0..1

1 1

Course Enrolment Request

Learner Profile

Learner Info

1

0..1

Transcript ESP Enro lment Request

Personal

Fig. 5. ESP service packages

Security

330

Luis Anido et al.

proposed methodology. It is a decomposition of the Reference Model into a set of components that provide the functionality identified along the previous stages. Note that, in a general sense, the objective is the definition of a set of services to facilitate and speed up the development of standardized distributed and interoperable final systems. To build such a final system, a possible approach is to acquire, or develop, an implementation compliant with the defined services and compatible with its development platform. Over it, the wrapper layer (c.f. Fig. 1) provides value-added system-specific features to meet the particular needs of their customers. The basic properties of a well-constructed Reference Architecture are: – Service architecture based on reusable subsystems. Architecture subsystems correspond to reusable service packages. The only necessary additional elements for building final systems are boundary classes representing user interfaces and control classes encapsulating value-added system-specific services. – Standard-driven architecture. Adopting appropriate industry standards is a vital decision. Subsystems in the architecture must correspond to components implementing business logic and management of information models identified by standardization bodies and institutions whenever possible. However, no dependency to specific proposals must be established. Actual bindings to existing information models is left for the implementation stages. Therefore, the implementation should offer introspection mechanisms to find out the particular supported models. – Architecture oriented to local changes. Most modifications and updates should affect just to one component. Dependencies in the existing information models and user requirements must be thoroughly analyzed prior to component decomposition. Changes in both of them should be reflected as updates of as few components (ideally one) as possible. – Scalability. Construction of final systems can be done as an incremental process through the successive introduction of new elements from the architecture. Architecture subsystems must be loosely coupled, and dependencies have to be directed from more complex to more basic components. – Adaptability. The clear identification of the role of each subsystem through use case realizations, decomposition and dependency analysis must support the replacement of specific subsystems by functionally equivalent ones. – Interoperability among heterogeneous systems. Open software interfaces and a common Reference Architecture support interoperation, provided final systems conform to the architecture. Value-added features are then implemented through the elaboration and improvement of wrapper classes. Full interoperability needs defining component interfaces using a concrete interface definition language, usually tied to a particular implementation environment. From here, platform-independent semantics are used as the supporting framework for the subsequent phases in the methodology. Fig. 6 shows the Reference Architecture identified for the e-learning domain. Subsystems are grouped according to the element of the Reference Model they

½¾¾¿ÀÁÂà ÄDA Concepts

331

ECP

Catalogue Management

ESP

Employee Administration

Runtime Environment

Course Repository

Broker

Broker Core

Notification Management

Federation Management

Profile Management

Packaging Management

Learner Administration

Catalogue Management

Unpackaging Management

Course Repository

Fig. 6. Reference Architecture b Ålong to. In addition to the services packages identified for the ESP and described in Sec. 3.3, the following subsystems were derived from our process: – Broker reference architecture elements: • Broker Core. It provides basic services to implement searching and retrieval of educational resources. • Profile Management. It supports customized searching for Searchers according to their profiles. • Notification Management. It provides notification services for the Broker. • Federation Management. It supports the construction of brokerage services based on federation topologies to perform collaborative searches among federated brokers. – ECP reference architecture elements: • Course Repository. It handles creation, storage and management of courses. • Catalogue Management. Like in the ESP, it provides mechanisms for the construction of educational resources cataloguing systems. Besides courses, this subsystem also supports asset and SCO1 cataloging. • Packaging Management. It provides course packaging services. It relies on Course Repository and Catalogue Management to obtain educational resources to be packed and their descriptions.

3.5

The Design Model

As the Reference Architecture includes only classes from the Analysis Model, it is implementation independent and purely conceptual. The next step lies in the 1

Sharable Content Object, the minimum traceable content that can be delivered to a learner.

332

Luis Anido et al.

CourseTracesSupervision getNumberOfLearnersForCourse() listLearnersForCourse() listCoursesForLearner() listLearningSessions() listLearningSessionsForPeriod() putSCOResult() getCourseTraceDescription() checkSessionWithFreeNavigation() getCourseTraces() getCourseTracesByType() getLastCourseTrace() getLastCourseTraceByType() getLastSessionCourseTraces() getCourseTracesForPeriod() getCourseTracesForPeriodByType() getCourseTracesForCourse() getCourseTracesForCourseByType() getCourseTracesForCourseAndPeriod() getCourseTracesForCourseAndPeriodByType()

CourseTraceSeq getCourseTraces ( in CL_CommonTypes :: CourseId course_id, in CL_ESPCommon :: LearnerId learner_id) raises ( CL_CommonExceptions ::Invalid Parameter, CL_CommonExceptions :: InternalError );

INPUT RETURNS EXCEPTIONS

course_id : Course identifier learner_id : Learner Identifier Traces generated by the Learner identified by learner_id during his interaction with the Course identified by course_id Invalid Parameter : Identifiers used are not compliant with the defined format. The parameter indicates which identifier is incorrect InternalError : The implementation raised an unexpected error

Fig. 7. CourseTraceSupervision iÆterface and method signature elaboration of a Design Model (step 5 in Fig. 1) using the constructs and concepts of a specific development environment for building distributed applications. As our final objective is the definition of a new Domain CORBA Facility for elearning we chose CORBA as the implementation/deployment environment. The Reference Architecture based on Analysis’ service packages allows the same model specifying system functionality to be realized on multiple platforms through auxiliary mapping standards, or through point mappings to specific platforms. It allows different applications to be integrated by explicitly relating their models, enabling integration and interoperability and supporting system evolution as platform technologies come and go. At this stage, the Reference Architecture subsystems derive in a set of design service subsystems that materialize the responsibilities of the analysis classes in a concrete environment. Unlike previous phases where the UML generic metamodel was used, at this stage we have used the UML profile for CORBA to model the resultant artifacts. As the different subsystems may be implemented by different vendors, we have used the CORBA Interface Definition Language (IDL) [2] to provide a precise definition of the corresponding interfaces and the expected behavior. CORBAlearn specifications include the definition of both service interfaces and data models involved. Following the example presented in Sec. 3.2 and Sec. 3.3, Fig. 7 presents the CourseTraceSupervision interface that is used to develop supporting tools for Tutors in an e-learning system. This interface defines methods to access tracking and session data generated by learners during their interactions with courses. The figure also includes the textual description for a particular method: getCourseTrace, which returns a sequence of CourseTrace structures. This structure, which offers support for storing course tracking data (i.e. interaction among learners and courses), is described using the UML profile for CORBA in Fig. 8. Apart from fixed attributes (e.g. the restricted

ÇÈÈÉÊËÌÍ ÎDA Concepts

CourseTraceSeq

PropertySeq (from CL_CommonTypes)

333

Time (from CL_ESPRuntimeEnvironment)

index: long{0..*} properties

0..1

1..1

1..1 timestamp

1..1

0..1

CourseTrace

CourseTraceParams

0..1 0..1

1..1

parameters

0..1

0..1

type 1..1

(aux)

subtype : [0..1] string {Case = OTHER} (aux)

CourseTraceParams_switch 1..1

0..1

0..1

{Case = (SCO_ENTRY, SCO_EXIT, COURSE_RESUMING, NEXT_SCO_REQUESTED, NEXT_LEARNING_ELEMENT_REQUESTED, NEXT_EVALUATION_ELEMENT_REQUESTED, PREVIOUS_SCO_REQUESTED, UPPER_SCO_REQUESTED, 0..1 ACCESS_DENIED)} sco_id

block_id {Case = BLOCK_TOC_REQUESTED}

CourseTraceType COURSE_ENTRY COURSE_EXIT SCO_ENTRY SCO_EXIT SCO_RESULT COURSE_RESUMING TOC_REQUESTED BLOCK_TOC_REQUESTED NEXT_SCO_REQUESTED NEXT_LEARNING_ELEMENT_REQUESTED NEXT_EVALUATION_ELEMENT_REQUESTED PREVIOUS_SCO_REQUESTED UPPER_SCO_REQUESTED ACCESS_DENIED OTHER

1..1

sco_id

1..1 (aux)

NodeId (aux) (from CL_CommonTypes)

1..1

data {Case = SCO_RESULT}

Status 0..1 1..1 NOT_ATTEMPTED

sco_status INCOMPLETED SCOResultTraceParams 1..1 COMPLETED 0..1 PASSED FAILED

Fig. 8. CourseTrace structure type vocabulary for the trace type) we always define extension mechanisms, in this case through the PropertySeq element (a sequence of pairs property name and any-typed value). The whole CORBAlearn specification includes the English text descriptions for the whole 888 methods derived in 13 different sub-specifications [7] and all the data structures defined and modelled with the UML profile for CORBA.

4

Summary

Nowadays, one of the hot topics at the OMG is the specification of services and facilities in specific vertical markets through Domain CORBA Facilities. These specifications consist of interfaces written in OMG IDL with accompanying semantic description in English text. A well-conceived facility is based on an underlying semantic model that is independent of the target platform. Nevertheless, the model could not be distilled explicitly, and this is the case with OMG domain specifications because the model for most of them is not expressed separately from its IDL interfaces. As their models are hidden, these facilities

334

Luis Anido et al.

have received neither the recognition nor the widespread implementation and use that they deserve outside of the CORBA world. Extending these implied models outside of CORBA makes sense. The Healthcare Resource Access Decision Facility, already implemented in Java and EJB in addition to CORBA, is an example, but there are more. This paper proposes an Unified Process-based and MDA-oriented methodology to produce standardized vertical facilities with a visible and separate underlying conceptual model. In the MDA, models of different systems are structured explicitly into Platform Independent Models (PIMs) and Platform Specific Models (PSMs). Since the Unified Process is oriented to the development of final systems, we had to adapt it to the definition of software services which, in turn, could be used to develop those final applications for the domain in question. For this, we included an initial Reference Model and an intermediate Reference Architecture, which is directly derived from analysis service packages. Our PIM will be the Bass’ Reference Architecture, which is obtained, in turn, from Unified Process PIM artifacts (Use Case Model and service packages from the Analysis Model ). PSMs will correspond to subsequent Unified Process phases (Design models). PIM artifacts are modelled using the Unified Modelling Language (UML) whereas PSMs artifacts are modelled using the UML profile for the target platform. In our case, we used the UML profile for CORBA. The strict application of the proposed methodology implies the development of a large set of modelling artifacts [7], which may be a costly process. The proposed methodology has been applied to the development process of a draft proposal for a Domain CORBA Facility for e-learning: CORBAlearn. CORBAlearn includes the definition of data structures to encapsulate outcomes from the first level of standardization, exceptions and service interfaces, which are distributed among 13 different specifications that cover the whole spectrum of functionality included in full-fledged e-learning environments. Open publication of these interfaces within the OMG framework will assure interoperability among products developed by different vendors, provided they are built over CORBAlearn-compliant products. Also, software reuse is promoted as new systems can be built over components offering the basic and fundamental services defined by the CORBAlearn specifications.

Acknowledgments We want to thank Xunta de Galicia and Ministerio de Ciencia y Tecnolog´ıa for their partial support to this work under grants Arquitecturas distribuidas para Teleservicios (PGIDT00TIC32203PR) and CORBALearn: Interfaz de Dominio guiada por Est´ andares para Aprendizaje Electr´ onico (TIC2001-3767), respectively.

ÏÐÐÑÒÓÔÕ ÖDA Concepts

335

References [1] OMG: The Common Object Request Broker: Architecture and Specification (2001) Electronic version available at http://www.omg.org/ cgi-bin/doc?formal/01-12-35.ps. 321 [2] OMG: IDL Syntax and Semantics chapter (2000) Electronic version available at http://www.omg.org/cgi-bin/doc?formal/01-02-39. 321, 332 [3] OMG: Model Driven Architecture (MDA). Technical report, OMG (2001) Electronic version available at http://www.omg.org/ cgi-bin/doc?ormsc/01-07-01.pdf. 321, 322 [4] Anido, L., Fern´ andez, M., Caeiro, M., Santos, J., Rodr´ıguez, J., Llamas, M.: Virtual Learning and Computer Based Training Standardization. Issues and Trends. Submitted to ACM Computing Surveys (2001) Electronic version available at http://www-gist.det.uvigo.es/~lanido/congresos/anidoSurveys.zip. 322, 324, 327 [5] GESTALT: Getting Educational System Talk Accross Leading edge Technologies project. Web site at http://www.fdgroup.co.uk/gestalt (2002). 322 [6] Dodds, P.: Sharable Content Object Reference Model (SCORM). The SCORM Run-time Environment. Technical Report Version 1.2, ADL Initiative (2001) Electronic version available at http://www.adlnet.org/library/documents/scorm/ specifications/SCORM 1.2 break RunTimeEnv.pdf. 322 [7] Anido, L.: Contribuci´ on a la Definici´ on de Arquitecturas Distribuidas para Sistemas de Aprendizaje Basados en Ordenador utilizando CORBA. Ph.D. thesis, Departamento de Ingenier´ıa Telem´ atica, Universidad de Vigo (2001). 322, 327, 333, 334 [8] Jacobson, I., Booch, G., Rumbaugh, J.: The Unified Software Development Process. Addison-Wesley (1999). 323 [9] Bass, L., Clements, P., Kazman, R.: Software Architecture in Practice. AddisonWesley (1999). 323 [10] Jacobson, I., Booch, G., Rumbaugh, J.: The Unified Modelling Language User Guide. Addison Wesley Longman (1999). 323 [11] OMG: UML Profile for CORBA Specification. Technical report, OMG (2000) Electronic version available at http://cgi.omg.org/cgi-bin/doc?ptc/00-10-01. 323 [12] Landon, S.: Comparative Analysis of On-line Educational Delivery. Technical report (2001) Electronic version available at http://www.ctt.bc.ca/landonline. 324 [13] Fredrickson, S.: Untangling a Tangled Web: An Overview of Web Based Instruction Programs. T. H. E. Journal 26 (1999) 67–77. 324 [14] Anido, L., Llamas, M., Fern´ andez, M.: Labware for the Internet. Computer Applications in Engineering Education 8 (2000) 201–208- 324 [15] Anido, L., Llamas, M., Fern´ andez, M.: Internet-based Learning by Doing. IEEE Transactions on Education 44 (2001) Accompanying CD-ROM. 324 [16] Lidner, R.: Expertise and Role Identification for Learning Environments (ERILE). Technical report, ISO/IEC JTC1 SC36 (2001) Electronic version available at http://jtc1sc36.org/doc/36N0065.pdf. 325 [17] Cockburn, A.: Basic UseCase Template. Humans and Technology (1998) Electronic version available at http://members.aol.com/ acockburn/papers/uctempla.htm. 325

Rapid Development of Modular Dynamic Web Sites Using UML Tim Schattkowsky1, Marc Lohmann2 1 Paderborn

University, C-LAB, D-33102 Paderborn, Germany [email protected] 2 Paderborn University, Department of Computer Science, D-33095 Paderborn, Germany [email protected]

Abstract. Development of dynamic Web sites is often performed by teams consisting of graphic designers and software developers. Communication between these different team members has to be supported with a simple modeling approach that considers their different academical backgrounds. Dynamic Web sites can contain multiple modules that may reappear on different pages. Reuse of both business logic and visual design modules would be desirable. Furthermore, a considerable amount of time is usually consumed by the implementation of data flows that are already defined in the model. Rapid development is enabled by providing roundtrip engineering capabilities with support for automatic code generation. We propose a simple subset of the UML adapted to the problem domain by means of stereotypes as well as a strategy for generating code templates from such models. These templates are tailored to the tasks of each team member. This enables parallel work and automated reintegration of results. Keywords: Unified Modeling Language, Hypermedia, WWW, Object-Oriented Design, Code Generation

1

Introduction

There is a growing demand for lightweight methods for the development of smalland medium scale Web applications. Short production time and heavy cost pressure from customers and competitors are major economic factors in the development process of these systems. Heavyweight development processes would introduce expensive overhead into such projects, which cannot be economically compensated by the process’s benefits. The development teams for such Web applications consist of people with different skills and academic backgrounds [10]. These people use different languages to communicate their ideas which leads to misunderstandings. This may cause expensive redesigns. In order to support successful communication, a common language is required, which is understandable to people of different background. The Unified Modeling Language (UML) [3,11] fulfills this requirement by providing a family of J.-M. J´ez´equel, H. Hussmann, S. Cook (Eds.): UML 2002, LNCS 2460, pp. 336-350, 2002. c Springer-Verlag Berlin Heidelberg 2002

Rapid Development of Modular Dynamic Web Sites Using UML

337

intuitive diagrammatic notations by which a software system can be described at a high level of abstraction. The different views and backgrounds of the team members have to be supported by the models. These models have to be focused on the information relevant to the different roles in the development team. In many cases, we can distinguish between the domain expert, who has knowledge about the business processes behind the Web application, the graphic designer, who is in charge of the creation of the user interface, usually consisting of HTML pages, and the developer, who has to build a working software system based on the work of his partners. Furthermore, we have the customer, who has little knowledge about the technical realization of the project. As a result, another requirement for a Web application engineering methodology is the support for the views and backgrounds of different roles in development teams. On the more technical side, many Web applications are based on dynamic Web pages generated by scripts written in a language like PHP [1], Microsoft’s Active Server Pages (ASP) [9] or Java Server Pages (JSP) [12]. Thus, these Web applications are in fact dynamic Web sites. This introduces a problem into the development process. The responsibilities for the script and the design of the generated pages are split between developer and graphic designer. Furthermore, these scripting languages usually lead to a mixture of business logic and design elements within one software module. This has to be clearly separated into separate modules to allow the reuse of both logic and design modules. The method we propose enforces modularization of Web applications. This enables the team members to work concurrently on different modules of a Web page and to consistently integrate their results. Many small and medium scale Web applications only have small business logic. For such systems, the realization of data input, transport and presentation consumes a considerable amount of production time. A modeling approach for dynamic Web sites should support automatic code generation and thus safe production time. The models should also yield a complete structural description of the Web site. This enables the generation of a working incomplete prototype without design elements and business logic and enables rapid prototyping. Such a prototype allows early demonstrations, which are very important for customer communication. We propose a lightweight UML-based approach to modeling small and medium sized Web applications aiming at the above requirements. The approach employs specific use case diagrams, activity diagrams and class diagrams in order to capture the fundamental structural and behavioral aspects of a Web application while providing different views on these aspects according to the needs of different team members. Using the running example of an online reservation system, we demonstrate the derivation of code templates in HTML and PHP from the models.

2

Related Work

In this section, we briefly discuss different approaches to the modeling of Web applications. Some focus on the modeling notation, like Conallen who proposes an extension to the UML. Other focuses on the development process, for example [2, 7], WebML or WSDM.

338

Tim Schattkowsky and Marc Lohmann

Conallen [5] defines a UML profile for Web application design. He introduces stereotypes for components, classes, methods and associations in order to distinguish, for example, server components, client components, server pages, etc. The approach covers the modeling of layout and implementation aspects. However, he does not support modularization besides using frames. Koch and others [2, 7] are describing a hypermedia extension to the UML to model Web applications, focusing on the navigation and the user interface. The conceptual model consists of a class diagram identifying the objects of the problem domain and their relations. The navigation structure is described by a class diagram specifying navigational nodes and links. The presentation model defines the structure of the user interface by means of composite objects and their dynamic behavior by state diagrams. Further, presentation objects are used to describe the concrete layout of the user interface. This approach seems to be oversized for small applications whose interface consists of simple HTML pages. Our modeling approach focuses on those aspects that are important for the cooperation between developers, graphic designers, and domain experts, leaving user interface design and layout to the graphic designer. The Web Modeling Language (WebML) [4] is a notation for specifying complex Web sites at a conceptual level. It distinguishes between a structural model, a composition model, and the topology of links between pages. Further, WebML lets you define layout and graphic requirements for page rendering and includes a personalization model. WebML also addresses the issue of different kinds of specialist playing different roles. WSDM (Web Site Design Method) [6] is a user centered approach. The starting point is a set of potential visitors of a Web site which are classified into user classes. The available data is modeled on the basis of the information requirements of the users. WSDM describes a four phase process: user modeling, conceptual design, implementation design, and implementation. The user modeling phase consists of two sub-phases, the user classification and the user class description. With the user classification the audience of the Web site are identified and classified. Different user classes perform different activities on the Web site. The user class description contains information requirements and the characteristics of the user classes. The conceptual design phase consists of the two sub-phases of object modeling and navigational design. Within object modeling, the information requirements of different user classes with their different perspectives are formalized. How the different users can navigate through the Web site is described within the navigation model. This method defines its own graphical notation for the objects of the navigation model and does not distinguish different views for designer and application developer.

3 Design Methodology 3.1 A Conceptual Model for Web Applications Small and medium size Web applications usually are based on dynamic Web pages using server side scripting. Fig. 1 shows a simple abstract model for such Web

Rapid Development of Modular Dynamic Web Sites Using UML

339

applications. All interactions in these Web applications are based on Web pages. We have to distinguish between a client page and the server page generating the client page. Static and dynamic Web pages are usually distinguished. For a static page, the client page is a simple client side copy of the server page. In the case of a dynamic page, a server side program is computing the client page. A dynamic page is usually implemented using some scripting language like PHP, JSP or ASP. This script generates the client page to be displayed by the client. For Web applications, all Web pages can be regarded as dynamic pages, since a static page is a special case of a dynamic page. Hence, we do not have to distinguish between static and dynamic pages in our model. Client ClientPageModule

Server ClientPage

consists of

Serv erPage

generates 0..n

1

0..n

0..n

BusinessLogic

«use»

Hyperlink LogicInterface

DesignElement

DesignTemplate «use»

Fig. 1: Abstract Model of Web applications Client pages consist of different modules. These modules are either pure design elements or logic interfaces. Such logic interfaces enable the user on the client side to interact with the server side business logic. The interaction between the client and the server is achieved through hyperlinks. The activation of such a hyperlink may also cause the transmission of data from the client to the server, i.e., as HTML form data (“post”) or URL-encoded (“get”). This data is used by the server page to compute a new client page. Thus, the business logic is contained in the dynamic pages on the server side. These pages also have design templates that define the visual appearance of the client page. A client page may contain hyperlinks to different server pages. While this model captures dynamic Web sites at a high level, it is not precise enough to support the development process and overcome common problems. Currently, many small- and medium size Web systems suffer from the mix of presentation and business logic in the code modules. These systems are implemented very straightforwardly using monolithic scripts, but certain parts of the business logic and the design are relevant for more than one server page and should be reused. Let us consider the example of a hotel reservation system where a business logic module computes the price for a room reservation. This module may be relevant for both a server page offering to place the reservation as well as for verifying the validity of the price of a confirmed reservation when booking this reservation. This raises the need for reuse of the business logic. Such a reuse is common sense for normal software development. For Web application development, this is still an important issue [8]. Our model supports the reuse of logic modules, because a logic module may be associated to multiple server pages. In our example, the module implementing the logic for computing the price for a reservation would be associated to both server pages mentioned above. We consider a Web page as a composition of reusable modules. From the model in Fig. 1 we can derive two kinds of modules. The logic module encapsulates a part of

340

Tim Schattkowsky and Marc Lohmann

the business logic while the design module represents a reusable part of the design template. These modules have both client side (client page module) and server side (server page module) representations. The client side subtypes of these modules are the design element representing a reusable design module and the logic interface representing the interface of a logic module. Since the logic modules in our model are also responsible for the generation of client page modules, they still combine logic and presentation. We have to decompose these logic modules into smaller modules (see Fig. 2). This allows us to encapsulate and separate these two aspects. Thus, we achieve a separation of the business logic and the presentation of the computed data. The different use cases of a logic module will be described as workflows composed from logic module elements. Client consists of

ClientPage

0..n

ClientPageModule

0..n

DesignElement

LogicInterface

Hyperlink represents

generates

represents

Server

0..n

1

contains

Serv erPage 1..n

Serv erPageModule

contains

DesignModule

1..n

represents

LogicModule

represents

Link

1..n BeginUseCase

1..n

UseCase

LogicElement next

generated by

uses 1

Alternativ e posts

allows

1..n

1..n

UserDecision

1..n

Serv erDecision

evaluates result of PersistentData Data

0..n InputData 0..n OutputData

1..n

1..n

uses 0..n

Processor

uses 0..n computes 0..n Renderer

renders

0..n

Fig. 2: Complete conceptual model for Web applications

Rapid Development of Modular Dynamic Web Sites Using UML

341

A renderer module generates the logic interface client page module representing a server side logic module. However, the renderer module is not intended to compute any function on its input data besides the presentation. Such computations belong to the business logic and are located in processor modules associated to the logic module. The data used by the renderer will usually be produced by a subset of the processors using input data from links and persistent data. In cases where no such data exists, the renderer produces always the same client page module and could be replaced by a corresponding design module. The user interacts with the system via hyperlinks. Therefore, these hyperlinks have to be utilized to integrate user interaction into the workflows. Within a workflow, these Links represent user decisions. We consider such links as single alternatives related to a user decision. Links are also needed to begin a certain use case. Fig. 2 presents a complete conceptual model including the presented concepts. This model allows the description of dynamic Web sites on a considerable level of precision that is suitable for customer communication as well as for code generation and rapid prototyping. 3.2 Modeling In order to support the capturing and presentation of requirements, UML use case diagrams are employed. They describe the fundamental functional aspect of the system from the perspectives of different users. We will use a simple example to illustrate our approach. This example is a hotel reservation system. The system provides the usual functionality of placing and cancellation a reservation and includes views for both the guest and the hotel clerk. Fig. 3 shows the use case diagram for this system. Reservation System

Cancel Reservation

Guest

Place Reservation «include» «include» Manage Reservations

Clerk

Fig. 3: Reservation System - use case diagram

Since the use case diagrams will later be used for code generation, we introduce additional semantics which influence the use of these diagrams. The root use case diagram is intended to provide the initial views of the system’s functionality. A starting module for every actor can be generated from this diagram. The actors represent different roles for users of the Web application. In our example, the clerk may act like a guest, e.g., to execute the guest’s orders, or perform administrative work that is not intended to be done by guests. This is a very usual and general distinction which can be found in almost any Web application. In our approach, a use case has to be detailed by an activity diagram or other use cases (possibly in a different use case diagram). Thus, at the lowest level all use cases

342

Tim Schattkowsky and Marc Lohmann

are described by activity diagrams. Such an activity diagram will describe the interactions between client and server as well as possible user interactions on the client side. Fig. 4 shows the activity diagram detailing the “Place Reservation” use case from the use case diagram above.

Fig. 4: Place Reservation activity diagram

The activity diagram detailing a use case has three areas. Swimlanes separate client and server from the communication. Only object flows and control flows are valid model elements for the communication area. In the client and server areas, we use stereotyped actions according to the conceptual model (see Fig. 2). «LogicInterface»is the only valid action stereotype for the client side, as «Processor» and «Renderer» are for the server side. Thus, dynamic modules will be modeled as subactivity graphs containing invocations of the associated renderers and processors as action states. Choice nodes may be used to evaluate the return value from a processor and make a decision between different execution flows. These execution flows may end in different renderers. The business logic will be contained in action states, which have to be detailed to provide the actual implementation of a certain action. To extract the server side subgraph related to a dynamic module, the graph has to be traced from an incoming control- or object flow to all reachable renderers. The client side subgraph can be found by tracing from all the renderers in the server side subgraph to the links. These two subgraphs are the basis for the code generation from the activity diagram, as they contain the description of both the behavior and the structure of a dynamic page. The necessary data information can be extracted from the type definition of the instances in the object flow. A data structure class diagram will be used for the description of the data processed by the Web application. This diagram shows the structure and composition of both transient and persistent data. All data passed in the activity diagrams using object flows has to be typed consistently with this class diagram. Fig. 5 shows the part of the class diagram for our reservation example, which is relevant to our example use case “Place Reservation”.

Rapid Development of Modular Dynamic Web Sites Using UML

343

Fig. 5: Part of the Reservation System data structure class diagram

It is important to distinguish between display data and editable data in the object flows. This information is essential for later code generation. Therefore, the objects in these object flows are assumed to be in a composite state according to the state chart diagram shown in Fig. 6. The state also reflects the persistence of the object. Persistent objects allow the generation of pure references in cases when data is only intended for parameter passing to the next activity.

Fig. 6: Data Flow Object State

To add business logic details to an activity diagram, the «Processor» actions can be detailed using a subactivity diagram. This diagram may contain action states as well as object flows that are typed consistently with the class diagram. Actions in this diagram may be detailed by a diagram of the same kind. The return values of the action states can be checked in guards. For the subactivity diagram related to those action states, the name of last action state visited will be considered as the return value to the parent activity diagram. contains

Serv erPage 1..n

Serv erPageModule 1..n

contains

Link

DesignModule

LogicModule

1..n Alternativ e

BeginUseCase

1..n

UseCase

LogicElement next uses

1

1..n

1..n

1..n

UserDecision

allows

Fig. 7: Metamodel for site structure diagrams

344

Tim Schattkowsky and Marc Lohmann

To compose the server page modules to server pages we have to relate certain elements from our conceptual model. Fig. 7 shows a metamodel containing the relevant elements from the conceptual model shown in Fig. 2. Instances of this metamodel are employed as a site map tailored to the specific needs described above. The model supports the reuse of server page modules and the integration of the behavioral description via associations to use cases, logic modules and their logic elements. Fig. 8 shows an example for a simple site structure diagram of our reservation system example. The semantics of a link between a design module and a server page depends on the subtype of link (see Fig. 7) used. While the basic link type indicates a simple link to another server page, the «BeginUseCase» link indicates that the associated use case will be executed by the target server pages. This implies that the target server page must have an association to the corresponding logic module. In our example, the use case PlaceReservation is part of the logic module ReservationSystem. Thus, the target server page for the «BeginUseCase» link associated to PlaceReservation must contain the corresponding ReservationSystem logic module. Since the corresponding logic module is determined by the composition between the use case and that logic module there is no need to explicitly associate the target logic module to the link. The same principle applies to «Alternative» links. These links indicate a change in the surrounding page within a use case. This implies that the corresponding logic module must be the link source logic and the target server page must be associated to the same logic module to provide a valid structural environment for the use case. «BeginUseCase» +

UseCase: = PlaceReservation

«DesignModule» Nav igationBar

«ServerPage» Reserv ation

«LogicModule» Reserv ationSystem

«Link»

«Link» «DesignModule» Greetings

«ServerPage» WelcomePage

«DesignModule» CommonElements

«DesignModule» Header

Fig. 8: Site structure diagram for the reservation system example

Jointly the presented models form a complete structural and behavioral description of those parts of the Web application, which are needed for the communication within the development team and with the customer. Furthermore, the model can be used for code generation leading to rapid prototyping from the model.

4

Code Generation from Models

In the following, we explain how the models in our approach can be used for the generation of a running prototype using PHP as the scripting language. We will

Rapid Development of Modular Dynamic Web Sites Using UML

345

describe our approach on a per-diagram basis. This will yield the necessary server side modules to create a complete running prototype. 4.1 Use Case Diagrams We mainly apply the use case diagrams to generate HTML modules for the designer of the Web pages. A HTML module, consisting at first on of a set of links, will be generated for each actor in the use case diagram. Each of these links is generated from a use case the actor is connected with. The link either references a page including a HTML module for starting a workflow modeled by an activity diagram or a HTML page including another static HTML module derived from a use case diagram detailing a top-level use case of the corresponding link. As a result, a tree of modules generated from more and more refined use cases is obtained. The developer can use these HTML modules to test the whole Web application. Therefore, the HTML modules have to be embedded in complete Web pages, as explained later in section 4.3. For example, from the use case diagram in Fig. 3 two HTML modules are obtained. The HTML module generated for the clerk (see below) consists of three links. All three links are referencing a server page, which includes modules to accomplish the corresponding use cases. The names to reference the server pages are taken from the site structure diagram, where the embedding of the modules in server pages is modeled. To show the correct module in the server page, it has to be referenced with parameters specifying the logic module and the use case to perform. The following HTML extract is an example for a module, which is possible integrated in a page, where the clerk can start all for him possible use cases. Starting module of Reservation System (clerk) Cancel Reservation