UML-MX^©

Download

Download UML-MX^© Version 1.0.2 (10 Sep 2024)

UML-MX^© is an adapted version of XModeler^ML. For installation guidance, click here.

Most recent updates:

• fixed bug when using MonetaryValue data type [v-1.0.2]
• fixed bug in association identifiers [v-1.0.1]
• corrected web link to online tutorials [v-1.0.1]
• fixed bug in operations editor when generating getters and setters [v-1.0.1]
• fixed bug in “Select Learning Unit” window [v-1.0.1]

Motivation

The UML language architecture and common UML modeling tools face two major limitations. (1) First, as a result of the fixed-level language architecture of the UML, objects and classes reside on the same modeling level. The UML meta model resides on modeling level M2 and user-defined models are always instances of this meta model on M1. M0 objects are not part of UML models even if the UML includes an object diagram type. The official UML documentation itself states that run-time objects “don’t appear in models directly” and only “underlie the meaning of models” (OMG 2005, p. 11). (2) Second, in typical UML modeling tools a mismatch of abstraction levels between model and code exists. A UML class will itself be an instance of some programming class, prohibiting any further instantiation into run-time objects (Frank 2022). As a result, it becomes necessary to generate the code from the model and keep both representations in sync, which is difficult and error-prone (ibid.).

These limitations are overcome in the FMML^x and XModeler^ML. Here, model and code share a common representation, avoiding the need for any additional code generation. The model is the code. Objects are programmed on the level they conceptually belong to. We therefore envisioned for long the development of an improvement version of the UML – called UML++ – that allows for the instantiation and execution of models at run time (Frank et al. 2022; Frank and Clark 2023). We think the instantiation and execution of models at run time is especially beneficial for learning object-oriented modeling (Maier and Schwarz 2024) since it allows students to interact with an integrated view of classes and objects and get immediate feedback on modeling decisions.

References

UML++: Commonalities and Differences to UML

As a result of the shortcomings UML modeling tools face we have developed UML++, which is an adapted version of our multi-level modeling language, the FMML^x. The core modeling concepts are the same in UML++ and UML: Classes have a name, a set of attributes, and may be associated to other classes. Each attribute has a name, a type, and a multiplicity. Each association has a name, a reading direction, may be uni- or bidirectional, always has two ends each of which specifies a minimum and a maximum multiplicity. The meta model of the FMML^x (described here) explicates these commonalities.

In contrast to the UML, however, UML++ models can be instantiated and executed. We presume that this is especially adventageous in learning and teaching contexts as a means to provide real-time feedback on modeling decisions. Although we have adapted the FMML^x for teaching purposes, it differs to the UML in some regards:

Aspects of UML not covered in UML++:

• Currently, UML++ only supports modeling class and object diagrams. Other diagram types of the UML are not yet supported. The effort of adding a diagram type varies:
  • The addition of a new structural diagram type (or an entire domain-specific modeling language) poses no particular challenge: It only requires the specification of a meta model and a concrete syntax. The addition of a concrete syntax is supported through the XModeler^ML‘s Concrete Syntax Wizard (illustrated in Demo 2, separate screencast on how to use it follows).
  • Adding behavioural diagram types like activity diagrams is challenging, though. Multi-level dynamic abstractions, in general, cannot be implemented in the same manner as static or functional abstractions (Frank 2012) and are thus not yet supported by the XModeler^ML. Even for two-level models like activity diagrams, this requires the addition of something similar to a workflow engine which, among others, needs to implement a control flow and keep track of past executions. Such an engine is not part of the native XModeler^ML distrubution. Additionally, the UML itself does not specify instance-level execution semantics of behavioural diagram types as is the case for, e.g., BPMN.
• Some language concepts of UML class diagrams are not yet supported in UML++ diagrams; either because they are not relevant for our teaching context or because the concept becomes obselete in a multi-level modeling environment. These include:
• Association classes
• Native support for aggregation and composition associations. The recent addition of association types to the XModeler^ML supports the addition of non-standard associations
• Stereotypes, profiles, and tagged values

Aspects of UML++ not covered in UML: (cf. Maier and Schwarz 2024)

• Traditionally, the UML offers two separate diagram types for classes and objects. In UML++, objects and classes may be modeled within the same diagram. Note that it is still possible to model classes and objects in different diagrams if desired.
• UML++ objects must be instances of modeled UML++ classes. In contrast to the UML, the class name of an object is not entered manually but determined automatically. As a result, it may not be any string value but must correspond to its actual class name.
• Operations and constraints in UML++ are executable. While in the UML operations are confined to their signature, the executability of UML++ offers the specification of an operation body. We have adjusted our operation editor so that a user can switch between a normal mode and an expert mode. In the normal mode, users can only adjust the signature; the operation body can only be modified in the expert mode.
• The graphical representation of objects in UML++ includes a compartment with all executed operations and their respective return values.
• Because UML++ objects are run-time instances of UML++ classes, we require the use of actual data types. UML++, as a subset of the FMML^x, offers the following data types per default: Boolean, Integer, Float, String, Date, Currency, MonetaryValue. It is also possible to add, what we refer to in our lectures as, domain-specific data types, i.e., to use one user-defined class as a type for an attribute of another class. Furthermore, users can specify enumerations that contain a custom set of values. In case an enumeration is selected as a data type for an attribute, users can select the slot value via a drop-down menu.
• The context of a constraint must not be added by a user but is added automatically. In UML++, the representation of a class contains an additional compartment that includes its constraints.
• Violations to constraints are shown in UML++ objects. This includes violations to custom constraints (XOCL expressions) or also other constraint violations such as violation of association multiplicity.
• UML++ offers native support for delegation associations.

References

UML++ Introduction Screencast

The following screencast guides users through UML++ modeling concepts. The introduction is implemented in our guided-modeling mode (see further information on this below) and is part of the regular UML-MX distribution available for download.

Created with UML-MX^© version 0.9

UML-MX^© Demonstration

UML-MX (“Modeling and Execution”) is a new modeling tool developed by our team. To the best of our knowledge, it is the first UML modeling editor that allows for the instantiation and execution of object models. It supports constructing and executing UML++ models at run time. We postulate that UML-MX offers an unprecedented, inspiring teaching environment for students. While they create their first models, they implicitly implement a corresponding program, simply by instantiating the model.

 

My First UML++ Model

The following example is focused on a simplified case of course management at a university. The first screen cast uses a regular version of the XModeler^ML, that does not include classes at a level above 1. It seems similar to a regular UML class diagram. However, you will see how the FMML^x and the XModeler^ML add value to object models by enabling features that go clearly beyond existing UML modeling tools.

 

 

The second screen cast recreates parts of this model with UML-MX^© version 0.9