SLE 1.3. UMLP Class Diagrams

Material for the Software Language Engineering lecture, Bernhard Rumpe

UMLP Class Diagrams (based on MontiCore’s CD4Analysis)

This explanation is intended for students who want to understand how class diagrams are realized using textual language and what syntactic constructs the language allows.

The explanation gives an overview of the CD4Analysis language, which is used in several software engineering tools based on MontiCore.

In the following, we assume that you are familiar with UML class diagrams.

CD4Analysis (read: “CD for Analysis”) is a textual language that is mainly intended for

  • analysis modeling (i.e., structures of the system context as well as data structures of the system),
  • code generation,
  • database generation (which includes the data structure, and functionality to load and store the data, create new objects, and delete objects),
  • test case and especially test data generation (in a randomized form),
  • transport infrastructure to communicate data between client and server,
  • reporting, monitoring data changes, and many more.

With MontiGem we are even able to produce complete, running web systems in a way that additional functionality can be plugged in based on the generated data structures.

The UML has a lot of different sub languages. Class diagrams are among the more prominent ones. Some of the languages can be used for constructive code generation, others for test case generation, while all of them are amenable for early checks for consistency and syntactical correctness as well as for typical “smells”. In this document, we only adress class diagrams and here especially the subset of all language constructs for modeling requirements during the analysis phase.

Because the main form of usage is the definition of data structures during the analysis phase, CD4A does not cover all features that UML class diagrams provide, but concentrates on the structural parts. I.e. classes, attributes, datatypes, associations, and enumerations are available.

Methods and their signatures are omitted.

  • The textual CD4A language is designed in the spirit of Java, using similar keywords, types, delimiters for statements “;” and blocks “{“, “}”.

  • The body of a class diagram consists of a list of classes, interfaces, enumerations, associations, and compositions. The order is irrelevant; it is especially allowed to reference later classes early on. We suggest to either put all classes at the top and the associations later or to group a class and related associations into topical sections.

  • Please note that CD4A starts with the keyword classdiagram, while some tools also accept keyword umlp as the starting point.

  • The SocNet.cd example used here can also be directly examined.

  • More examples can be found in the CD4Analysis project.

  • To repeat, the bodies of classes are very similar to the classes in the Java language, because the syntax is inspired by Java. The lines 5–8 could directly come from a Java class, also no method or constructor is defined.

  • Neither classes nor interfaces require bodies, e.g., when you don’t know anything about them yet. An empty body can be denoted using a ;.

  • Associations are not present in Java, yet exhibit a complex set of information.

  • The text form reads from left to right almost identical to the graphical depiction above: Only the name of the association was moved to the left, and the middle contains the iconic forms of the arrow <->, ->, etc.

  • Note that we use underspecification as a significant construct within modeling languages, meaning that if certain information is not given, nothing is said. I.e. many pieces of information can be refined, for example -- just tells us that we don’t know in which directions navigation might be available.

  • Role names like (organizer) can also be attached on both sides.

  • Qualifiers like [[profileName]] resemble the box that they are embedded in. CD4A allows two kinds of qualifiers, either the name of an attribute of the other side (in this case class Person) or a data type resembling the key values of the qualified association. Semantics is defined in UML/P books by Bernhard Rumpe.

  • Compositions follow the same syntax as associations, just with the keyword composition to indicate their compositional semantics.
  • Enumerations are defined with a set of constants as their body.

  • Enumeration constants are visible inside the enumeration and can be used outside only through qualified names (like RelationType.FRIEND) or an explicit import statement.

An import statement similar to Java’s import is available. It allows to import foreign types, e.g. defined as Java classes, like Date or Account, but also allows to refer to other kinds of models that define datatypes, such as other class diagrams.

  • This is a core feature of allowing to compose class diagrams that build on each other but are independently developed by different teams of a project or taken from a library.

  • Please note this restriction: when generating from a bidirectional association, the class on the opposite side must be generatable or similarly genrated too. (I.e. association Person <-> Date will not work, because of the external class Date.)

  • The mechanism to make other models and libraries known to the compiler is described in the tool calling (see e.g. --path).

CD4A generally follows the requirements engineering guideline, which states that during the requirements elicitation process generic classes are not really needed and not also not introduced. However, it is sometimes convenient to rely on the most relevant basic generics directly, which are the four Optional< . >, Set< . >, List< . >, and Map< . , . >. But please note that these four directly correspond to associations that can describe the very same properties, but the CD4A generator for associations also produce lots of access and manipulation methods with integrated data consistency checking and can be used bidirectionally.

  • CD4A allows derived attributes (and associations), marked by /. It is notable that this indicates a dependency of this attribute from other attributes, which, however, there is not made explicit in the model itself.

  • The package name first of all describes in which directory the model of the class diagram can be found, but by default also carries over to the packages where the modeled (and finally generated) classes reside. Please note: an explicit statement, which is not shown here, can attach individual packages to each class.

  • Like in Java, the import statement is required when external datatypes, classes, etc. are used. Such an import may refer to another model or in this case to an already existing Java class. A context condition checks whether the used classes actually exist in the local model or in the imports.

  • It is a convention to name enums in UPPERCASE, in CamelCase for classes, interfaces, and enumeration types, and to use uncapped names for attributes.

  • In fact, CD4A applies the same restrictions and capabilities for names as does Java, which means that numbers and the dollar sign $ are allowed within a name and underscore _ in any position.

  • More (sometimes subtle) context conditions apply to give a well-formed model. However, the resulting error message should be detailed enough to explain the problem.

  • As a general guideline, CD4A uses similar naming and visibility conventions as Java does, i.e., enum constants and attributes are visible locally and can be used from outside using their qualification – as described above.

  • Note that this description does not infer how the CD4A model is actually used. During a requirement elicitation activity, such a model is basically used as a communication vehicle to understand the underlying data structure. However, appropriate tools (including the CD4A generators and MontiGem) are able to produce a lot of infrastructure for such a class diagram. This can be used both for prototyping and actual use later on. As indicated, this may include data structures, access functions, transport, communication and storage, and potentially also web representation.

Join our mailing list for updates regarding courses and theses: