UML 2.0 -- a major revision of the industries de facto software modelling language. (Technote -- Software Intelligence).

Over the past 5 years the Unified Modelling Language (UML) has been growing in popularity and I have seen it dramatically improve the effectiveness of client's software development. The UML is a graphical language for specifying, visualizing, constructing and documenting the artefacts of software systems. It represents a collection of the best engineering practices proven successful in modelling large and complex systems. The language is used to model software systems prior to construction, as a method of automating the production of software, improve quality, reduce cost, and time-to-market. It can also be used to solve recurring architectural problems such as physical distribution, concurrency, replication, security, load balancing, and fault tolerance.

The UML notation is derived from and unifies the notations of three object-oriented design and analysis methodologies..

* Grady Booch's methodology for describing a set of objects and their relationships

* James Rumbaugh's Object-Modelling Technique (OMT)

* Ivar Jacobson's approach, which includes a use case methodology

The UML standard was adopted by the OMG in November 1997 as UML 1.1. Since then it has undergone a number of minor revisions - the most recent of these is UML 1.4, which was adopted in May 2001. The next major revision is UML 2.0, which is scheduled for completion early in 2003.

Why then is UML so important? As software architectures grow in size and complexity so does the need for software models. UML is currently the software industry's dominant modelling language. In fact, it is true to say that it is difficult to find a software project with more than 10 developers who do not use UML in some way to specify their architecture. UML has enormous growth potential. The evolution of methods to automate code generation, and reduce the chasm between design and implementation, is a very exciting area. However, there is still a long way to go before this is refined for all languages, but this must only be a matter of time.

Moreover, the first version of the language has been showing signs of stress and age. Problems that I regularly encounter regarding UML 1.x include excessive size, gratuitous complexity, imprecise semantics, limited customisability, non-standard implementations and the inability to interchange model diagrams.

It is also not surprising that UML shows the effects of age. Five years is a long time in the software industry, especially if we consider the evolution of 00 to component-based technologies such as J2EE and NET.

The OMG 4-Layer Metadata Architecture

In order to more effectively convey the message about the path of UML it is important to understand the architecture that the UMG has chosen for its standards. The architecture has four layers, called MO, MI, M2 and M3.

M2, the 'metamodel level', is the level where the UML metamodel is defined. This refers to the concepts used by the modeller, such as Class, Attribute, Message, etc.

M3, the 'metametamodel level' is the top level, which is an instance of itself (known as the Metametamodel). We will not worry about this too much for the purposes of this article.

M1, the' model level' is the level where the UML models live (those that are developed by UML modellers).

MO, the 'user object level', is the level where the actual runtime objects reside.

Language Structure

Structuring a language revision is always a risky business. Revising a language can often introduce as many problems as it attempts to solve. In particular the number of individuals and organisations involved in the current process could cause the language revision to lose focus and become overcomplicated. Ideas and frills that may have been cautiously sidetracked in the initial version may creep into the language. This is clearly a concern for the, OMG and one that they have been diligently guarding against. At this stage it may be pertinent to describe a little of the process that they are going through. With the UML 2.0 revision, the OMG has separated the topics into 4 areas and issued 4 separate Requests for Proposals (RFPs). The areas are Diagram Interchange, Object Constraint Language (OCL), Infrastructure, and Superstructure.

Diagram Interchange refers to the diagrams and constructs which are being reviewed and revised. Current standards will be refined, retired or deprecated as is felt appropriate.

The Object Constraint Language will be fully revised, with OCL 2.0 to be defined.

Infrastructure revision is concerned with reviewing the basic constructs and improving scope for customising the language. This will most likely not directly affect most modellers. The changes will affect tool builders and methodologists who create their own extensions to UML.

The Superstructure revision focuses on issues that directly affect the UML modeller. Vague areas of UML will be cleaned up and many extensions will be added. Particular attention is being paid to improving the support for more advanced constructs such as components and interactions. I shall focus on Infrastructure and Superstructure. In my opinion it is these areas that have the greatest potential to improve the efficiency and usability of the language.

Goals

The main goals of the UML 2.0 revisions are to restructure and refine the language to make it easier to apply, implement and customise. This should assist developers with increasing precision, and practicing reuse. These goals of the infrastructure revision include the definition of a 'metalanguage' kernel, the provision of more powerful mechanisms to customise UML, and provision for the definition of language dialects.

The concept of a language kernel derives from the reality that one fifth of the UML is currently used to describe four fifths of the common software problems. The definition of such a kernel would make the UML significantly easier to learn and more importantly more straightforward to implement. A basic kernel would be used in conjunction with a mature profile mechanism to handle the more advanced features of the language (essentially that remaining four fifths). This could allow significant customisation of the language (some refer to this as the definition of 'language dialects'), so that it can be tailored for different domains (such as financial services, telecommunications etc.). I'm certain that in my area - aerospace and defence - this work could yield great value. In addition tailoring could take place for specific platforms, such as J2EE and .NET.

The creation of a language kernel is essentially an effort to simplify things on the metamodel level. In addition to this there is substantial work on cleaning up the UML metamodel by adding abstractions and removing programming language specific (e.g. C++) structures. Inconsistencies will be addressed with a 'purer UML' being the result.

There is also an effort to improve extensibility. The current mechanism is limited and not well defined. UML 2.0 is likely to 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).

The goals of the superstructure revision are many and of real significance. There are areas which will become particularly relevant in the Military/Aerospace arena in which my company and I are extensively involved. The enhanced support for Real-Time development is a particular highlight. State machines are to be updated to make them more scalable and easy to generalise, and able to support a transition- centric view. More interesting to the wider software community is the specification of both platform-independent components (e.g., business components) and platform-specific components (e.g., BIB, COM+). Currently the UML includes the concept of a component, but this is a rather naive notion. Efforts have been made to use subsystems and/or classes to model software components, but the results are not really satisfying.

In the current specification of UML, Component models and architectural frameworks, such as Enterprise JavaBeans, CORBA Component Model and COM+ cannot be modelled easily. Complex frameworks and patterns are difficult to express in UML. There are a number of clearly identified and well-known weaknesses in this area:

* It is not possible to specify plug-substitutability of components.

* The notion of interface is rather weak. This is particularly so when attempting to describe interactions between interfaces and the specifying outgoing signals and messages.

* Specifying the requirements a component places on its environment is not made possible.

Business Process modelling is due to receive greater support under the new 2.0 standard. The revision of activity diagrams is due to support more flexible parallelism and furnish more I/O options. The connection between activity diagrams and other diagrams are currently badly defined. There are also real limitations to their scope for expressing complex systems.

There are a number of other areas of interest, which I will paraphrase below:

In structural modelling there is an issue with the overlap between the nations of Type, Class, Interface and Role as used in collaboration diagrams.

It is not currently possible for architects to be able to model

object and data flows between entities at a high level of granularity, such as with packages and subsystems.

The current sequence and collaboration diagram notation offers little help with the structuring of specifications using sequence diagrams. It is not currently possible to decompose or combine sequence and collaboration diagrams. Modellers cannot reference one sequence diagram from another.

I could mention a number of other areas in which improvements are due to be made. Different organisations will have their own slant on things and their own set of priorities. The above-mentioned list are, I feel, a fair representation of the areas being addressed.

I think it would be inappropriate to dwell too much on some of the diagrams we will see in 2.0. Required and provided interfaces (see fig.3) seem to me to have roots in the HOOD (Hierarchical Object Orientated Design) methodology.

Summary

Debates are currently raging over the effects of the next step of evolution for UML. Will it provide an even more effective language to unite software developers in expressing their systems, or will the language become far too awkward for practical usage by most developers? I believe that the OMG have been cautious in their process to achieve balanced moderation. The design by committee effect is a well-known and well-understood phenomenon, which I am convinced has been sufficiently mitigated against. A lot rests on this revision for the UML both for the OMG, and the member companies. 1 have long believed that it is a language that is here to stay, and one that will develop as new technologies evolve. I am excited about eventual standard and its effect an the industry.

Editorial Note:

Andrew Bissell, Managing Director of training and consultancy company, Objektum (www.objektum.com) has been involved in the introduction of a large number of companies to the UML over the past three years. In an effort to get more involved with the definition of the language Objektum has become a member of the 0MG. The Object Management Group (OMG) is a non-profit consortium that produces and maintains computer industry specifications such as UML and CORBA. The membership list includes virtually every large company in the computer industry, and hundreds of smaller ones. Objektum will play a role in helping to define the currently evolving standards of UML 2.0, and Model Driven Architecture (MDA). The vision embodied by MDA is an architecture that supports interoperability between specifications that address integration through the entire systems life cycle: from analysis and design of processes and information to system design, to component construction, to assembly, integration, deployment, management, and e volution.

Objektum specialises in training for the Defence and Aerospace industry. It is the only OMG listed training and consultancy company in the UK.