Archiv der Kategorie: Metamodelle

Das Java Memory Model

Als Java-Programmierer macht man sich im Allgemeinen keine Gedanken über die Hardware, auf der das Programm ausgeführt wird. Das ist eine riesige Erleichterung für Entwickler, aber das bedeutet auch, dass sich JVM und Compiler um das gleiche Verhalten auf unterschiedlicher Hardware (Multiprozessorsysteme) kümmern müssen. Mit Java 5 wurde der JSR-133 umgesetzt, dieser beschreibt das Java Memory Model.

Ein Programm mit mehreren Threads kann bei mehrmaliger Ausführung jeweils einen anderen Ablauf haben (je nachdem, wann ein anderer Thread aktiviert wird). Das Memory Model definiert also nicht einen bestimmten Ablauf für ein Programm, sondern bietet die Möglichkeit, eine bestimmten Ausführungsreihenfolge für ein Programm zu verifizieren. Der Entwickler kann sich einen Ablauf überlegen, in dem das Programm ein falsches Verhalten zeigt, und das Memory Model sagt dann, ob dieser für das Programm gültig ist. Da sowohl der Compiler, als auch der Prozessor pro Thread unabhängige Statements in eine andere Reihenfolge bringen können, gibt es sehr viele potentielle Fehler. Das Memory Model bietet aber über Synchronisierung die Möglichkeit, eine threadübergreifende Vorher-Nachher-Beziehung zwischen Programmteilen zu definieren.

Das Memory Model ist in der „Java Language and Virtual Machine Specification“  beschreiben, die für Java 8 im Abschnitt 17.4. Die Spezifikation ist relativ einfach zu Lesen mit vielen Beispielen, ich empfehle die Lektüre!

Weitere Hintergrundinformationen und Beispiele gibt es in dem Google Talk und auf der Seite http://www.cs.umd.edu/~pugh/java/memoryModel/.

Vererbung von Komponenten am Beispiel von EJBs

Im Laufe der Zeit wurde der Begriff einer Komponente in UML immer weiter geschärft. Die aktuelle Spezifikation definiert eine Komponente folgendermaßen:
„A component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. A component defines its behavior in terms of provided and required interfaces.“
Mit eigenen Worten: Eine Komponente wird über ihre Interfaces verwendet und ist dadurch austauschbar. Das Metamodell sieht folgendermaßen aus:

vererbung_Komponenten

In der EJB-Welt lassen sich Komponenten mit Session Beans abbilden. Diese können mehrere Interfaces exportieren und die Implementierung dahinter kann ausgetauscht werden.
In der EJB-3.1 Spezifikation steht folgendes über Superklassen von Session Beans:
„A session bean class is permitted to have superclasses that are themselves session bean classes. …the use of session bean classes as superclasses merely represents a convenient use of implementation inheritance, but does not have component inheritance semantics“.
Das bedeutet, dass es keine Komponenten-Vererbung bei Session Beans gibt.
Deutlich wird das z.B. bei den exportierten Interfaces: Die Superklasse S implementiert das Interface A, deren Subklasse K implementiert das Interface B. Bei echter Komponentenvererbung ist die Erwartung, dass die Subklasse (Subkomponente) K beide Interfaces (A und B) exportiert. Da es an dieser Stelle aber keine Komponentenvererbung gibt, exportiert K lediglich das Interface B.

UML ist nicht auf Java/JEE zugeschnitten. Dadurch, dass UML bei der Vererbung von Komponenten mächtiger ist als Session Beans, erfüllt UML ihren Anspruch, eine allgemeingültige Modellierungssprache zu sein. Das bedeutet andererseits aber auch, dass UML-Modelle nicht immer eins zu eins in einer anderen Sprache umgesetzt werden können.

What is a classifier?

„A classifier is a namespace and a type, and it can be generalized“ [UML spec].
Many different classes of the UML metamodel are subclasses of „Classifier“. It is important to know what a classifier is and thus to get a feeling of why some Metaclass is a „Classifier“.

Hierarchy of Classifier
Classes that are classifiers (the annex of the UML Superstructure contains a full taxonomy):

  • Class
  • Interface
  • Association
  • Component
  • DataType
  • Collaboration
  • UseCase

Classes that are not a classifier:

  • Comment
  • Parameter
  • Dependency
  • Generalization
  • Package

While „Package“ itself is a Namespace, it is not a Type, and thus is not a Classifier. Association was a surprise for me, because it feels like it shouldn’t be a Classifier. But thinking about it, an association can be generalized, and there is the concept of the „association class“. An association class „will be both an association, connecting a set of classifiers and a class, and as such have features and be included in other associations“ [UML Superstructure].

So all in all, the three criteria given (be a namespace, be a type, be generalizable) combined with some gut feeling allow us to guess what is a classifier and what is not.

All sciences are based on the concept of classification, for example taxonomy in biology. Object are assigned to different classes, which in turn often form a hierarchy (although there are classifications that are not based on hierarchies).
UML is based on a hierarchic classification. Or, to put it in the words of the spec: „A classifier is a classification of instances, it describes a set of instances that have features in common“.

OCUP part 5: State diagrams

A state machine specifies behaviour of a modelled element. Since the modelled element can have attributes, the state represents a valid combination of values for those attributes (=value configuration).

The following description of the diagram is technical and doesn’t render our intuitive understanding of state machines obsolete:

A vertex is an abstract superclass for all state nodes. The metamodel looks like this:
state_machine_1
A state can be a FinalState, indicating that the enclosing region is completed.
state_machine_2
Why didn’t the OMG model the information if a state is final as a boolean property of State? After all, it has the implication that you have to pick a special element (=create a special metamodel instance) instead of just toggeling a value between true and false (like marking a class abstract). My guess is that they want to force you to think twice before considering a final state. In contrast to abstract classes, the FinalState has some implication on the model’s structure, the model can’t just continue with transitions to other states after reaching the FinalState. But then again, the metamodel of Transition has no special handling for FinalStates.

Pseudostates do not represent value configurations of the modeled element, they stand for a transient node. Thus they are not a specialization of State.
state_machine_3

OCUP part 4: Metamodel instances in a composite structure diagram

How exactly does a given Composite Structure diagram map to the UML Metamodel? First some definitions form the UML spec:

„Connector=link that enable communication between two or more instances. Each connector may be attached to two or more connectable elements, each representing a set of instances“. This states that the instances in the Composite Structure diagram are represented by ConnectableElements (which are abstract and subclassed by Property). Looking at a composite structure diagram, one may mistake those Properties as Objects, but they are not.

„A property specifying an instance that is not owned by the instance of the containing classifier is shown by graphical nesting of a box with a dashed outline. The contained box symbol [of a part (represented by a solid box)] has only a name compartment, which contains a string according to the syntax defined in the notation sub clause of ‚Property'“. This indicates that the whole diagram is based on the viewpoint of the containing [structured] classifier. The following two images show the class diagram and the composite structure diagram from the viewpoint of the class „car“.

car-wheel-axle

car-wheel-axle

composite structure car-wheel-axle

composite structure car-wheel-axle

 

„A property symbol may be shown containing just a single name (without the colon) in its name string. This implies the definition of an anonymously named class nested within the namespace of the containing class“.

To sum it up: Take a structured classifier. To make a composite structure diagram for this class, take the properties that are linked to it by composition and represent them with a solid box. All relevant Properties that are not owned [by composition] can be represented via a dashed box. One hint to represent the composite structure diagram as a set of metamodel instances: The Association (which is part of the fundamental certification) can own Properties (association ends) that are not owned by a class. Here is a very simple class diagram and its representation as a set of metamodel instances:

class_car_wheel

class_car_wheel

car-wheel as metamodel instances

car-wheel as metamodel instances

 

OCUP part 3: Composite Structure diagrams

Composite structure diagrams describe which object relationships are valid and which ones are not.

Structured Classifier = a Classifier with behavior that [can be described] depends on referenced instances.

Part = association end (of a composition)

So far my notes on composition structures. In a class diagram, you can model a composition with a certain multiplicity. With a composite structure diagram, you can put additional constraints on those multiplicities.

Here is the part of the merged metamodel that concerns composite structures. As always, abstract classes are not marked.

metamodel for composite structures

metamodel for composite structures

How exactly do the metamodel instances look like for a given composite structure diagram? This will be the next article in this series.

OCUP part 2: Data types and other basics of the fundamental exam

I include this part of the fundamental exam here, because it’s important for the following parts of the exam. This is part of my notes for the examination.
A DataType (and all its subclasses) has no identity.
PrimitiveType= Integer, Boolean, UnlimitedNatural, String
An example for UnlimitedNatural is the upper bound of a Multiplicity, see MultiplicityElement.
DataTypes are marked by keywords and not stereotypes (although the notation looks the same „<<enumeration>>“)

hierarchy of datatypes

hierarchy of datatypes

Diagram header:
– diagram type, optional
– diagram name
– parameters, optional

Stereotype= way of extending the metamodel, adds semantics to an existing model element
– multiple possible
– can have attributes to store additional information

Anmerkungen zu der OCUP Serie

Da der Test für die OCUP-Zertifizierungen in Englisch ist, sind meine Notizen größtenteils auch in Englisch.
In den Diagrammen, in denen es nur um die Vererbungshierarchie geht, sind abstrakte Klassen nicht als solche gekennzeichnet. Auch die Attribute lasse ich meist (bis auf die in diesem Kontext relevanten) weg. Es geht darum, bestimmte Zusammenhänge zu begreifen, anstatt das Metamodell nachzuzeichnen.

Stereotypen und Tagged Values

Alte Hasen kennen das: Früher erlaubten es die UML-Tools, einfach einen String als Stereotypen zu verwenden, und einen String mit „=“ als Tagged Value.
Dann kam UML2. Tagged Values sind nun Meta-Attribute von Stereotypen. Stereotypen sind nun Meta-Klassen, die Profilen zugeordnet sind.
Metamodell von Profilen
Profile wurden eingeführt, um UML für verschiedene Einsatzzwecke anpassbar zu machen. Sie sind keine Erweiterung von UML, sondern können nur zum Metamodell weitere Einschränkungen definieren.

Um in einem UML-Tool einen eigenen Stereotypen zu verwenden, muss zumindest ein neues Package angelegt werden, in dem für den Stereotyp eine Klasse angelegt wird. Tagged Values sind die Attribute dieser Klasse. Die Verwaltung von Profilen ist sehr Tool-spezifisch, bei einigen Tools muss ein eigenes Projekt für das Profil angelegt werden, bei anderen Tools reicht ein Package aus.

MindMaps Teil 2

Wie im vorigen Beitrag angekündigt wird jetzt untersucht, wie ein Metamodell für MindMaps aussehen könnte. Dabei soll es am Ende möglich sein, einfache MindMaps als Instanzen des Metamodells darzustellen.

Als Ausgangspunkt dient das UML-Metamodell. Eine MindMap besteht hauptsächlich aus Topics, die untereinander in einer Beziehung stehen. Im Metamodell gibt es daher die Klasse „Topic“. Ein „Classifier“ ist laut der UML-Spezifikation folgendermaßen definiert: „A classifier is a classification of instances, it describes a set of instances that have features in common“. Im Metamodell ist ein „Classifier“ eine Generalisierung von „Topic“.

Topics

Jedes Topic kann in der Mitte eines weiteren MindMap-Diagramms stehen, deshalb gibt es keine Klasse „RootTopic“ mit „SubTopics“, sondern alle Topics sind Instanzen derselben Metamodellklasse. Nichtsdestotrotz muss die Beziehung „Topic“-„SubTopic“ im Modell dargestellt werden, dafür dient eine Assoziation mit Rollenbezeichnung. An dieser Stelle würde eine Komposition dafür sorgen, dass Topics nicht separat angelegt und nachträglich untereinander verbunden werden können. Das kann an dieser Stelle durchaus Sinn ergeben, ich habe mich aufgrund der größeren Flexibilität aber für eine Assoziation entschieden. Mit der „Topic“-„SubTopic“-Beziehung sieht das Metamodell folgendermaßen aus:

SubTopics

Die Beziehung ist ungerichtet, je nach Anforderung kann die Assoziation auch nur in Richtung des SubTopics navigierbar sein.

Im Moment fehlt zur Darstellung des Beispiels des ersten Teils noch der „Link“ zwischen „Verständnis des Lesers“ und „MindMap to class diagram“. Der Link ist eine gerichtete Beziehung zwischen zwei Topics, er wird mit Hilfe der „DirectedRelationship“ des UML-Metamodells modelliert.

Links

Das Beispiel des ersten Teils kann jetzt als Instanz dieses Metamodells dargestellt werden:
Beispiel

Instanzen