Channels ▼


The Road Ahead for UML

Refactoring UML

Once the simplification of the UML specification is complete in 2011, we will be able to move onto the next phase, which will be to refactor UML so that it can more effectively address the changing needs of many different classes of users. This section proposes some techniques that we can apply for this. It will be very important to retain backwards compatibility with the existing UML while doing this: we must not introduce changes that invalidate existing investments in tools, models or training.

We suggest it is possible to create a very small kernel of no more than 20 elements such as objects, links, types and actions, so that almost everyone can learn it in a few hours. In these elements, we will only add things that are necessary to understand the kernel, so that it in a way becomes complete. The kernel by itself is not particularly useful to any developer as it is, although it might suffice for abstract conceptual modeling. It is intended to serve as a basis to describe useful elements.

On top of the kernel we now add more useful concepts. The most essential UML use cases can be defined as extensions to the kernel. An example of an essential use case of UML would be: "Developing from requirements to test".

[Click image to view at full size]
Figure 2: Suggested simplification of UML through separation of concerns.

The key idea here is that the kernel should be kept small and only includes generic elements and attributes needed by most use cases of UML. Specific elements or attributes to existing elements in the kernel which are needed to provide support for the use case "Developing from requirements to test" are added along with that use case. Thus they don't belong to the kernel. Everything new is added with the new use case, since it supports the use case. This is the whole point. This is what is called an "aspect-oriented structure", where the kernel can be kept clean and simple without knowledge of how it will be extended. The new additions to the kernel will be added with the new elements coming with the use cases that need them.

Returning to the use case example of "Developing from requirements to test".... There are many specializations of this use case; for example, "Developing a web application from requirements to test", and variants such as complex system, distributed system, which all wouldn't be essentials, but extensions to the essential use cases.

[Click image to view at full size]
Figure 3: Adding a non-essential use case.

Since the use case "Developing from requirements to test" in itself is a large use case, we would need to find its constituent smaller use cases: Use case modeling, Designing, Implementing, Testing, Deploying. They are all different aspects or separate concerns of UML (see " Aspect-Oriented Software Development With Use Cases. Note that there is a danger in breaking down the complete use case into constituent use cases, which is that it might create silos and increase the risk of getting waste, contradicting principles of lean development. We mitigate this by using the Framework design principle where "each component should only do what only that component can do". This forces clean minimal factoring.

[Click image to view at full size]
Figure 4: Constituent use cases of the larger use case "Developing from requirements to test".

Technically, we need some enhancements to the mechanisms used to extend UML. Today there is a mechanism called Profiles which provides some of the required capability but is not well integrated with the rest of the UML architecture. A simple new mechanism for extending UML -- multiple dynamic classification of model elements -- is currently under development at the OMG, and is scheduled to be available as an OMG standard in 2011. This enables, for example, the specification of Ports to be completely separated from the specification of Classes, so that Ports can be added to Classes only for those advanced use cases where they are required.

Structuring UML like this will help eliminate today’s dilemma of choosing between UML and one or more domain-specific languages (DSLs). When UML is structured as a simple kernel plus extensions, new domains can be addressed by crafting further extensions that can be seamlessly integrated with the existing structures. Another mechanism currently under development at the OMG -- Diagram Definition -- will enable new standard diagram types to be specified and integrated with existing ones. Diagram Definition is also scheduled to be available as an OMG standard in 2011, and will be applied to UML and to other modeling languages including BPMN (Business Process Model and Notation).

To help users get started we should define a basic subset of UML, here called "Essential UML", which can be learnt quickly in a few days. This would include the simple aspects of most of the familiar UML diagrams. The rest of the UML can be added as a set of seamlessly interwoven, deeply integrated yet completely independent extensions without altering what already has been described, and taught. This is smart!

During the last 10 years UML has not adapted quickly enough to developments in the software world. Ten years ago, for example we didn’t have so many frameworks. Today we are inundated with frameworks. The work of programming has increasingly moved to become a job of connecting already developed components or to use existing frameworks. The amazing production of apps for mobile phones is a perfect example. Today, we have not found a place for UML in this context. That does not mean that such a place does not exist, just that we have not yet adapted UML to this context or made UML appetizing to use in these contexts.

As we move forward with improving the UML, however, the first step is to simplify the existing UML, so we get it to become what UML should have been. We need to shrink UML first to lay the foundation for radical expansion of UML into many different new and exciting domains. As the basis for this work is being laid, we can begin to enrich UML with the possible new constructs we need today and tomorrow.

As a consequence of these developments, users can carry on investing in UML with confidence that the value of their investment will grow as UML moves into new domains, and becomes easier to apply and to integrate with other technologies.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.