oose
Welcome to your Competence Navigator oose
EnglishEnglish

UML – Unified Modeling Language

UML is the notation for modeling almost everything. Even though it is currently perceived mainly as a software tool, it has already been used successfully for such diverse things as business process modeling, modeling complex systems of systems or defining an ontology. Here you can find some information about UML.

Object Management Group

The Object Management Group is the organization behind the UML. oose is a member and works on the UML specification in the network of international UML experts.

There is a wealth of further information on the OMG's UML-Website. In particular, of course, the current UML specification itself. This is a complex work of over 1000 pages (if you include associated documents such as OCL). Of course there are still errors. Every reader, whether a member or not, can report these using a form. However, the error may already have been reported. There is already a long list, but it is also interesting because some supposed errors are simply misunderstandings.

The machine-readable metamodel is also part of the UML specification. It is not easy to find your way around it, as the UML consists of 242 metaclasses, of which only 193 are effective (49 are abstract). In this file you will find a taxonomic overview that can even be printed out legibly on DIN A3.

UML 2.4.1 Taxonomy

Almost all metaclasses and their specializations and generalizations are included. We have only omitted 34 special actions that are really only needed for special purposes (keyword: executability). We have included a few classes more than once in the diagram in order to achieve crossover freedom. These doubles are then shown in a lighter color. For each class in a dark color, all its generalizations and specializations are indicated.

The information from the xmi metamodel is also available from the OMG as an attractively presented website. There you will also find a validator with which you can check the conformity of xmi files you have created yourself.

Certification

The OMG has set up a program for the certification of UML professionals so that you can prove your hard-won knowledge. You can find more information here.

UML tools

A pure painting tool is not enough for UML. After all, the tool must also be able to manage the model itself. After all, the diagrams are only views of the model. There is a large selection of tools, but there is no one ultimate tool. We will be happy to help you select the modeling tool that best suits your requirements. Here is an uncommented Werkzeugliste for your pre-selection.

Generating documents from UML models

What you have modeled can be used in many different ways. If necessary, it can also be used to generate documents - and this is often necessary. For different groups of readers, you need selected contents of the model, presented in a readable form. The topic is currently being hotly debated and an OMG standard is under discussion. We have had good experience with various approaches. You can use a well-known template language (e.g. Velocity or Xtend) ), which is also used internally by some tools. Other tools have their proprietary template editor on board. A completely new approach from the European Southern Observatory defines the document as a UML model using stereotypes. If you use Magic Draw, you can download the open source plugin from SourceForge.

UML Books

Analyse und Design mit UML 2.5, Bernd Oestereich, Axel Scheithauer unter Mitarbeit von Stefan Bremer 11. Auflage, 2013, 350 Seiten, Oldenbourg Wissenschaftsverlag

UML notation overview

Here you can find the current UML 2 notation overview (PDF file, 4 pages, 304 KB)

If you are looking for a large poster to hang on the wall - we distribute one at trade fairs and in our seminars. It is also included in the book "Analysis and Design with UML 2.5".

For the related SysML, you can find SysML notation overviews here.

All files offered here are licensed under the Creative Commons License.

UML history

The idea of object orientation is over 30 years old and the development of object-oriented programming languages goes back almost as long. While there have been publications on object-oriented programming for around this time, the first books on object-oriented analysis and design methods did not appear until the early 1990s.

They include those by Booch, Coad and Yourdon, Rumbaugh and others, Wirfs-Brock and Johnson, Shlaer and Mellor, Martin and Odell, Henderson-Sellers and Firesmith. Goldberg and Rubin and Jacobson also provided important impulses. Many methods are specialized and limited to certain areas of application.

The methods of Grady Booch and James Rumbaugh developed into the most popular methods in the early 1990s. Rumbaugh's method was based more on the structured methods. Booch's covered the areas of commercial, technical and comparatively time-critical applications. In 1995, Booch and Rumbaugh then began to merge their methods, initially in the form of a common notation to form the Unified Method (UM). However, the Unified Method was soon renamed Unified Modeling Language (UML), which was also a more appropriate name because it was essentially just a standardization of the graphical representation and semantics of the modeling elements, but no methodology was described. Modeling Language is mainly a more elegant way of describing notation.

Stifling diversity? The basic concepts of object-oriented software development methodology are mature and have proven themselves in practice. On the other hand, UML in particular offers a considerable wealth of detail and should therefore be used with caution.

The variety of description options can seem very overwhelming, and a deeper understanding of the UML constructs in all their facets requires some effort. In an initial approach, you can therefore limit yourself to the basic elements. In our seminars, we explicitly take this knowledge into account and also convey which UML constructs are problematic in practice and which are important. Although this may leave semantic gaps in the modeling, working at this level can be sufficient in practice. Quite apart from this, in many places no systematic approach is used at all.