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

Polymorphismus in UML Kommunikationsdiagrammen

Die Modellierung von Polymorphismus in Sequenzdiagrammen war bereits Thema dieses Blogs. Kommunikationsdiagramme fristen leider in der Praxis ein Schattendasein, zu Unrecht! Dieser Beitrag zeigt anhand eines einfachen Beispiels die Abbildung von Polymorphismus in Kommunikationsdiagrammen.

Zunächst ein Klassendiagramm. Beispielszenario: Die Klasse „Briefkopf“ soll, je nachdem, ob es sich um eine natürliche oder juristische Person handelt, einen passenden Briefkopf erzeugen.

Unterschiedliche Anreden für natürliche und juristische Personen

Unterschiedliche Anreden für natürliche und juristische Personen

Nun der polymorphe Aufruf: Der Briefkopf sendet die Nachricht „getAnrede“ an die Person, und je nachdem, welche konkrete Implementierung diese Nachricht empfängt, wird unterschiedlich darauf reagiert.

Abstrakter Empfang der Nachricht

Abstrakter Empfang der Nachricht

Die konkrete Verarbeitung der Nachricht für eine natürliche Person: Im Sequenzdiagramm wurde die polymorphe Nachricht durch eine „found message“ dargestellt. Im Kommunikationsdiagramm bietet mein UML-Tool keine „found message“ an, deshalb benutze ich einen Actor, um die Aktivierung der konkreten Implementierung zu modellieren. Die Instanz der natürlichen Person empfängt die Nachricht und benutzt das Geschlecht, um eine Anrede zu generieren.

Konkreter Empfang der Nachricht

Konkreter Empfang der Nachricht

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.

OMG Certified UML Professional Teil 1: Informationen

Seit einigen Jahren bietet OMG eine Zertifizierungsreihe zu UML an. Diese besteht aus drei Stufen: Fundamental, Intermediate und Advanced. Ich habe vor fünf Jahren die Fundamental Zertifizierung gemacht, und nehme nun das Intermediate-Level in Angriff. An dieser Stelle möchte ich einige meiner Eindrücke schildern:

Das Lernen für die Zertifizierung besteht aus dem Auswendiglernen von Teilen des UML Metamodells. Es gibt soviel ich weiss nur ein Buch, um sich vorzubereiten. Ich habe mit diesem Buch gelernt und fand es nicht so gut. Zum einen, weil einige offensichtliche Fehler in dem Buch enthalten sind. Zum anderen, weil der Aufbau des Buchs etwas unglücklich ist, denn schon im ersten Kapitel tauchen „redefines“ und „subsets“ bei Assoziationen im Metamodell auf, obwohl deren Semantiken erst an viel späterer Stelle erklärt werden. Ebenso der Package Merge. Andererseits ist das Buch eine der wenigen verfügbaren Resourcen, und die Alternative besteht im Lernen mit den Metamodelldokumenten. Da in dem Buch auch Beispielfragen enthalten sind (aber fast nur für das Fundamental Level), empfehle ich es zur Vorbereitung.

Der Inhalt der Prüfung besteht größtenteils aus dem Metamodell, es wird also gar nicht auf die objektorientierte Analyse, Design und Architektur eingegangen, sondern nur die Theorie von UML abgefragt. Eine praxisnähere Prüfung, die auch UML beinhaltet, ist der Sun Certified Enterprise Architect (SCEA), nun „Oracle Certified Master, Java EE 6 Enterprise Architect“ genannt. Wer die OCUP-Zertifizierung besitzt, kann deswegen nicht notwendigerweise mit UML modellieren. Das Zertifizierungswissen hilft aber bei der Benutzung von UML-Tools und natürlich bei eigenen Metamodellen.

Wer sich für die OCUP-Zertifizierung entscheidet, der sollte nach bestandener Fundamental-Stufe am besten sofort mit der Intermediate Stufe weitermachen, denn diese setzt das Wissen der ersteren voraus.

Notizen über den Stoff habe ich nebenbei gemacht, zum Beispiel war es für mich sehr hilfreich, die Vererbungshierarchie von Element zu den konkreten Classifiers aufzuzeichnen. Meine Unterlagen werde ich in Blog-Beiträgen veröffentlichen. Und den Package-Merge kann man sehr gut mit der UML-Spezifikation selbst durchspielen, um ihn richtig zu verstehen. Neben dem Buch sollten auch die OMG-Dokumente, zumindest die Superstructure Specification gelesen werden, da dort weitere Informationen enthalten sind, die Sachverhalte verständlicher machen.

Ich habe Zweifel, ob diese Zertifizierung der Karriere hilft. Bei Interviews wird der Bewerber eher nach seinem Fachwissen im Gespräch beurteilt. Ich glaube aber, dass Zertifikate bei der Auswahl von Kandidaten, die dann zum persönlichen Gespräch eingeladen werden, doch einige Vorteile verschafft. Das Lernen für die Prüfung macht aber Spass, und zusammen mit dem Erfolgserlebnis nach der Prüfung macht das die Zertifizierung lohnend.

Alles in allem ist die Zertifizierung zwar schwierig, aber dennoch beherrschbar. Ich hatte während des Lernens nie das Gefühl, ausreichend vorbereitet zu sein. Irgenwann habe ich mich dann einfach zur Prüfung angemeldet.

Geduld und etwas Neugier auf Metamodelle sind die besten Hilfen zu diesem Zertifikat. Ich wünsche allen, die sich darauf vorbereiten, viel Spass und viel Erfolg.

Modeling in Color – Verbrennungsmotor II

Im vorigen Beitrag wurde ein klassisches UML-Diagramm eines Verbrennungsmotors entwickelt. Am Ende stand eine Liste mit Begriffen, die in der Domäne „Verbrennungsmotor“ auftauchen. In diesem Beitrag soll ein Diagramm nach dem „Modeling in Color“ Ansatz entwickelt werden. Abschließend ist dann die Frage zu klären, ob mit diesem Ansatz die Dynamik (die Ablaufsicht) aus dem Klassendiagramm ersichtlich wird.

Um nochmal auf den „Modeling in Color“-Ansatz einzugehen: Dieser behauptet nicht, dass nur Klassendiagramme zur Modellierung verwendet werden sollen. Es ist z.B. auch möglich, Sequenzdiagramme mmit den verwendeten Archetypen zu zeichnen. Der Ansatz behauptet aber, dass Klassendiagramme nicht nur die statische Sicht des Quellcodes darstellen, sondern dass die Teilnahme der Objekte an einer Interaktion daraus ersichtlich wird.

Als Vorgehen wurden die Begriffe aus der Domäne nach Archetypen kategorisiert. Die wichtigsten Archetypen sind die „moment-intervals“, die auch mit der Signalfarbe Rot gekennzeichnet werden. Es ist schnell ersichtlich, dass die vier Takte eines Ottomotors etwas temporäres sind, und sie deshalb die wichtigsten Vertreter dieses Archetyps in dem Beispiel sind.

Als nächstes können die Rollen identifiziert werden. Die Unterscheidung zwischen Rollen und Dingen ist mir relativ schwer gefallen, die prüfende Frage war dabei: „Wenn es eine Identität besitzt, dann ist es ein Ding“. Und jetzt stellte sich heraus, dass das Beispiel nicht ideal ist, denn wie auch in Peter Coads Buch erwähnt wird, besitzen vor allem Parteien und Orte eine Rolle, aber selten Dinge. Da im Beispiel nur Dinge vorkommen, können manche Rollen etwas konstruiert erscheinen. Es spricht aber nichts dagegen, die Dinge direkt mit dem Moment-Interval zu verbinden, wenn keine Rolle gefunden wird.

Nach der Trennung der Rollen von den Dingen bleiben nur noch Vertreter des Archetyps „Description“ über, diese sind im Beispiel auch nur spärlich vertreten, was allerdings eher am Detaillierungsgrad als am Beispiel liegt.

Die identifizierten Klassen werden mit dem passenden Stereotyp in ein Klassendiagramm eingefügt. Wenn das UML-Tool es erlaubt für Stereotypen Farben zu hinterlegen, geht das sehr schnell. Nach dem Einfügen der Beziehungen zwischen den Klassen stellt sich heraus, ob der gewählte Archetyp passt oder nicht.

Hier das fertige Klassendiagramm:

Beispiel Modeling in color

Beispiel Modeling in color

Abschließend ein Vergleich des Ergebnis des klassischen (siehe hier) und des „Modeling in Color“-Ansatzes. Zunächst ein Vergleich der Zeiten: den klassischen Ansatz habe ich in fünf Minuten erstellt, während ich für das farbige Diagramm eine Stunde gebraucht habe. Natürlich ist dadurch der klassische Ansatz weniger detailliert, aber meiner Meinung nach sind beide Diagramme hinsichtlich der Dynamik typische Vertreter ihres Ansatzes. Und da im farbigen Diagramm die Takte nicht als Methoden, sondern als Klassen, die ihren Nachfolger kennen, modelliert sind, steckt dort mehr Dynamik. Ohne Sequenzdiagramm ist die Abfolge der Takte direkt ersichtlich. Meine Bewertung: „Modeling in Color with UML“ hält, was es verspricht.

UML Praxis: Modeling in Color – Verbrennungsmotor

Bereits vor zwei Jahren habe ich in diesem Blog über UML in Color berichtet, nämlich in einer Einführung und einem Erfahrungsbericht. Ich habe die Artikel in der Kategorie „Coad“ eingeordnet.

Die meinsten Beispiele zum „UML in Color“ drehen sich um Warenkörbe in Shops und ähnliche Beispiele. UML in Color verspricht, dass aus einem Klassendiagramm die interaktive Sicht herausgelesen werden kann, und genau das soll an dieser Stelle überprüft werden. Als Beispiel habe ich einen Verbrennungsmotor (Ottomotor) gewählt, da dessen Arbeitsprinzip zum einen sehr dynamisch, zum anderen allgemein bekannt ist.

Vererbung kommt in dem Buch „Java Modeling in Color with UML“ von Peter Coad, Eric Lefebvre und Jeff DeLuca nur am Rande vor. In den „Modeling Tips“ wird aber erwähnt, dass Vererbung für spezialisierte Moment-Intervals, Descriptions und Party/Place/Things verwendet wird. Für Rollen wird sie nicht verwendet.

Bevor der Verbrennungsmotor mit dieser Methode modelliert wird, zunächst ein grober Vorschlag für ein klassisches Diagramm. Der Motor hat für die vier Takte jeweils eine Operation, und delegiert z.B. in der Methode „verbrennen()“ an die Zündkerze. In welcher Reihenfolge die Takte erfolgen, würde über ein Sequenzdiagramm oder ein Kollaborationsdiagramm dargestellt werden.

Klassisches Modell eines Verbrennungsmotors

Motor klassisch

Nun ein Brainstorming für die wichtigen Dinge, die zu einem Verbrennungsmotor gehören:
Luft (angesaugt)
Benzin
Kolben
Zylinder
Kurbelwelle
verdichten
Abgas
ausstoßen
ansaugen
Zündkerze
verbrennen
Einlassventil
Auslassventil

Als nächstes werden diese Begriffe in die vier Kategorien (Moment-Interval, Role, Party/Place/Thing und Description) eingeordnet. Das wird in einem der nachfolgenden Beiträge geschehen. Darauf aufbauend wird dann ein farbiges Klassendiagramm entwickelt, und abschließend wird überprüft, ob dieses Diagramm tatsächlich auch die Dynamik darstellt.

Praxis: Logische Schichten in Klassendiagrammen

In diesem Blog wurde es schon betont: Die Schichten einer Architektur werden in der logischen Sicht des 4+1-Modells dargestellt (z.B. über Packages). Die logische Sichte zeigt die Organisation der Software (z.B. Schichten, Subsysteme, Packages, Frameworks, Interfaces und wichtige Klassen).

Im Laufe eines Projekts kommt oft der Punkt, an dem der Ablauf eines UseCase durch die verschiedenen Schichten betrachtet werden soll (für die Einarbeitung eines Kollegen, für Powerpoint-Folien, für die Stakeholders…) Es wird dann ein Klassendiagramm gefordert, welches sowohl die für den UseCase relevanten Klassen, als auch die Schichten zeigt.

Grundsätzlich werden dabei mehrere Sichten vermischt, nämlich die logische Sicht und die Ablaufsicht. Weiterhin erstreckt sich der UseCase über Instanzen, ein Objektdiagramm wäre wahrscheinlich geeigneter. Aber die Zielgruppe kann nur Klassendiagramme lesen, und das geforderte Diagramm ist ein pragmatischer Kompromiss.

Die zwei Konzepte „Schicht“ und „Klasse“ sollen also gemeinsam in einem Diagramm auftauchen. Werden die Schichten als Packages modelliert, so kollidiert das mit den normalen Paketen der Klassen. UML bietet dafür Stereotypen an, über ein Profil können diese für die logischen Schichten definiert werden. Oder es wird mit Farben gearbeitet (dann aber bitte durchgängig in allen Diagrammen). Je nach Tool können auch Farben für die Stereotypen hinterlegt werden (in Astah über „Tool->Project->Set Project Properties->Default Stereotype Color“). Oder als schlechtere Lösungen, bei denen Informationen verloren gehen: Die Packages der Klassen werden weggelassen, oder die Schichten werden als Shapes modelliert.

Schichten in Klassendiagrammen

Schichten in Klassendiagrammen