The future of UML

Jos Warmer, Klasse Objecten J.Warmer@klasse.nl www.klasse.nl

Abstract This document describes the background behind the Requests for Proposals for UML 2.0 as being issued by the OMG. This includes both an internal upgrade of the UML structure, and extensions that users find lacking in the current UML. The corresponding presentation will focus mostly on the latest developments in industry what all these changes mean for end users, i.e. the UML modeller.

UML U SAGE
It could be argued that UML is the most successful standard from the OMG. It is not only a formal OMG standard, but also a defacto standard in the modelling world. UML is used in many different ways and many different domains to specify different kind of concepts: Visual representation os language implementations (Java, C++, Smalltalk, CORBA IDL etc.) Directly executable models (e.g. xUML) Language-independent software specification High level architecture and framework description Process (re)engineering Website structures Workflow specification Business modelling

In each of these uses, the meaning of UML symbols and concepts is different. A rectangle in a class may be a Java or C++ class, an IDL interface, a business entity, a web page, a component, a process or something completely different. Not only is the meaning of the class symbol different, but the allowed structures are different as well. C++ classes may have multiple superclasses, while Java and Smalltalk dont. Java, C++ and Smalltalk classes can have instances, while IDL interfaces cannot. And these are just a few differences between language mapping implementations. As a result of UML being used extensively in all these different ways and in all different types of businesses, people often find that they cannot express what they would like in UML. For this purpose new concepts are added to UML, that extend the language beyond its current scope.

Distinguishing different usage

In many cases, people simply have their own interpretation, which is implicitly known by other people in their team, project or department. The environment and background of the reader/writer of the

KLASSE OBJECTEN

THE FUTURE OF UML

model determines its meaning. The consequence of this is that UML is a standard notation, but without a standard meaning. An alternative is to use the UML extension mechanism to define custom tags, stereotypes and constraints. A group of these definitions can be packaged in a UML profile. This allows one to precisely define a UML variant. This approach is used to define many current OMG standards, for example in the OMG standards for CORBA, EAI, EDOS, SPE, and Scheduling. A third way is to extend the UML metamodel with the addition of new meta-classes and metaassociations. This allows one to make more elaborate changes to the UML. An example of this is the CWM (Common data Warehouse Model) standard from the OMG.

U ML 2.0
A request for information (RfI) was issued by the OMG to find out what changes and enhancements users of UML found neccesary. This RfI was answered by as many as 21 individuals, companies or consortia, and the contents covers a wide range of subjects. The most prominent requests were: Precise and unambiguous language kernel Additional concepts layered on top of kernel Compliance with the Meta Object Facility (MOF) First-class extensibility mechanism Support for component-based development Internal structure of classifiers/interfaces/classes/types/roles Limit associations to context Metamodel for the Object Constraint Language (OCL) to integrate better with UML metamodel Statemachine generalization Scalability and encapsulation of statemachines Scalability, encapsulation and structuring of collaboration and sequence diagrams Modelling of architectures Abstract data flow modelling Rigorous mapping from notation to abstract syntax

Additionally, over 500 formal usage and implementation issues have been submitted to the UML Revision Task Force (RTF). Many of them have been resolved in the UML 1.4 version, but many have been postponed to UML 2.0.

T HE OMG 4-L AYER M ETADATA A RCHITECTURE

To facilitate the description of the UML it is important to understand the architecture that the OMG has chosen for its standards. The architecture has four layers, called M0, M1, M2 and M3. Figure 1 shows these levels. M0 is the level where the actual runtime object reside. M1is the level where the UML models live, that are developed by UML modellers. M2 is the level where the UML metamodel is defined. The concepts used by the modeller, such as Class, Attribute, Message, etc., are defined at this level.

KLASSE OBJECTEN

THE FUTURE OF UML 3

M3 is the top level which is an instance of itself. An instance at a certain level is always an instance of something defined at one level higher. An actual runtime object at M0 is an instance of a class defined at M1. The classes defined in UML models at M1 are instances of the concept Class defined at M2. The UML metamodel itself is an instance of M3. Other meta-models that define other modelling languages are also instances of M3. CWM is one example.

M3

Metametamodel

Meta Object Facility (MOF)

M2

Metamodel

CWM, UML Metamodel e.g. Class, Interface, Attribute

M1

Model

Your own UML model e.g. Car

M0

User objects

The actual objects that I model e.g. the car with license plate XX-31-NN

Figure 1 OMG 4-layer architecture

T HE UML 2.0 R OADMAP

As a result of the RfI, the 500 formal issues and the informal feedback from many users, the OMG has decided to send out a Request for Proposals (RfP) for UML 2.0. The request for proposals (RfP) by the OMG for UML 2.0 is divided into three separate parts. Although they are separate RfPs, they must be completely aligned to form one UML 2.0 standard. They consist of: UML Infrastructure RfP. This RfP requests a re-architecture of the UML to simplify its foundation and make UML into a modular and extensible language. This will not change UML at the modelling level, as most users view UML. UML Superstructure RfP. This RfP requests a number of enhancements to UML, which are directly usable to the UML modeller. The requirements originate from UML users that found UML unable to express their modelling needs. UML Object Constraint Language RfP. This RfP requests an explicit integration at the metamodel level with the rest of UML (both superstructure and infrastructure). As OCL is used in the definition of UML itself, it is important that its definition is completely integrated. The UML specification will become more rigorous by this. Also, a number of extensions are needed by modellers who use OCL and encountered areas where they cannot express their specifications in OCL.

KLASSE OBJECTEN

THE FUTURE OF UML

UML I NFRASTRUCTURE R F P
The infrastructure will not directly affect most modellers. The changes will affect tool builders and methodologists who create their own extensions to UML. Architectural alignment and restructuring. The UML metamodel is huge, lacks good abstractions and is difficult to maintain, implement and extend. Changes that are requested are: Simplifying the metamodel defining a kernel language on top of which the rest of UML can be defined. Clean up the UML metamodel by adding abstractions and removing programming language specific (e.g. C++) structures. Fixing inconsistencies. Extensibility. The UML extensibility mechanism is limited and not well-defined. UML 2.0 will include a lightweight mechanism which can be used at the model level (M1) and a heavyweight mechanism that can be used at the metamodel level (M2).

UML S UPERSTRUCTURE R F P
The superstructure RfP focuses on issues that directly affect the UML modeller. Vague areas of UML will be cleaned up and many extension, as requested by the users, will be added. Structural modelling. In the structural modelling part there is an overlap between the notions of Type, Class, Interface and Role as used in collaboration diagrams. This results in roles being more flexible, where the others are much too restricted in their usage. Component Based Development. UML includes the concept of Component, but this is a rather naive notion of this concept. Efforts have been made to use subsystems and/or classes to model software components, but the results are not really satisfying. Component models and architectural frameworks, such as Enterprise JavaBeans, CORBA Component Model and COM+ cannot be modelled easily: There is no possibility to specify plug-substitutability of components. The notion of interface is very weak. Especially missing are the possibilities to describe interactions between interfaces and the ability to specify outgoing signals and messages. There is no possibility to specify the requirements a component places on its environment. Complex frameworks and patterns are difficult to express in UML. Run-time Architectures. The way that objects and other data flow between parts of a system is crucial to understanding its architecture. The UML currently supports object/data flow only at the lowest level of granularity, between the steps in an activity graph. It is important for architects to be able to model object and data flows between entities at a higher level of granularity, such as packages and subsystems. Relationships. Several types of relationships are ill-defined. For example the meaning of generalization between packages or statemachines is undefined. Furthermore the "refine" and "trace" dependencies are rather vague. Activity Graphs. Activity diagrams have an ill-defined connection with the other diagrams and are too limited in their expressibility.

KLASSE OBJECTEN

THE FUTURE OF UML 5

Interactions. Experience has shown that to maintain a large set of sequence diagrams is difficult. The current sequence and collaboration diagram notation offers little help to structure specifications using sequence diagrams nor does it provide an overview of how these sequence diagrams are related to each other. Issues encountered include: Sequence and collaboration diagrams cannot be decomposed and combined. Both a decomposition of the roles involved in an interaction as well as a decomposition of the sequence itself are needed. Modellers cannot reference one sequence diagram from another. Notation. The UML notation has a number of inconsistencies and shortcomings. The mapping between the notation and the metamodel is informal and sometimes unclear or even missing.

UML O BJECT C ONSTRAINT L ANGUAGE R F P

The OCL is widely used both to define well-formedness rules for the UML metamodel (as well as for other meta-models in the OMG), and as a way for UML users to express precise constraints in UML models. The OCL semantics is currently built on the UML semantics. Their integration, however, is only through natural language, and there is no metamodel for OCL itself, and in consequence no clear separation between the semantics and notation of OCL. This causes problems with the precise interpretation of OCL, for example the context of OCL expressions within UML models is not fully defined. Without an OCL metamodel, structured interchange of OCL constraints via XMI is not possible (although they can be exchanged as uninterpreted strings). Without a metamodel it is also difficult to ensure consistency amongst OCL implementations. OCL Metamodel. OCL has no metamodel, which makes it impossible to formally define the integration with the UML metamodel. Also, the distinction between concrete syntax and semantics is blurred. Therefore OCL should get a metamodel, separated from its syntax. Expressibility and Usability. OCL lacks expressibility in several areas: Additional concepts will be added to OCL to allow for a more complete specification of components and to allow the specification of behavioural constraints. An extension mechanism for OCL needs to be defined. This will allow one to extend OCL in a well-defined way for use in different domains. The use of OCL as a general expression language (cf. only a constraint language) for the UML will be clearly defined.

C ONCLUSION
The evolution of UML is absolutely required to make sure that UML will stay up to date with the latest developments in the software industry. The direction taken is guided by the user community, but it requires a big effort. At the moment of writing a large number of companies is discussing the possibility to define a combined submission that fulfils all of the above requirements. It is also expected that several smaller groups will submit partial solutions, especially extensions to the UML for usage in specific domains. UML 2.0 will become the next step forward on the long road that lies ahead. The road followed allows UML to directly fit the needs from industry, thus ensuring that UML remains the standard modelling language for the coming decade.

KLASSE OBJECTEN

THE FUTURE OF UML

R EFERENCES
[Cook 2000] Steve Cook, IBM, The UML Family, keynote at UML 2000 Conference, York, October 2000 [UML 1.3] OMG UML Specification v 1.3, OMG doc. nr. ad/06/08/99 [UML 1.4] OMG UML Specification v 1.4, final, UML Revision Task Force, February 2001 [ad/09-09-01] OMG UML 2.0 Infrastructure RfP [ad/09-09-02] OMG UML 2.0 Superstructure RfP [ad/09-09-03] OMG UML 2.0 OCL RfP

KLASSE OBJECTEN