Archiv der Kategorie: uml

Reihenfolge von Nachrichten in Sequenzdiagrammen

Ein Sequenzdiagramm beinhaltet Lesenslinien von Objekten und Nachrichten, die zwischen den Objekten ausgetauscht werden. Dabei gilt das Kausalitätsprinzip: Eine Nachricht kann erst empfangen werden nachdem sie gesendet wurde. Davon abgesehen ist die Reihenfolge von Nachrichten nur pro Lebenslinie definiert; bei mehreren aktiven Objekten (oder bereits mit der Verwendung von asynchronen Nachrichten) legt ein Sequenzdiagramm weniger fest als intuitiv erwartet wird. Weiterhin kann zwischen dem Senden einer Nachricht und deren Empfang Zeit vergehen. Das ein Sequenzdiagramm die Reihenfolge nicht strikt festlegt ist ein Feature. Denn ansonsten müssten für die verschiedenen Möglichkeiten der Nachrichten-Reihenfolgen mehrere Sequenzdiagramme angelegt werden.

Sequenzdiagramm ohne Reihenfolge

Sequenzdiagramm ohne Reihenfolge

In diesem Beispiel ist nicht definiert, ob getMetaData() vor getNumberOfPlans() aufgerufen wird.
Um genau das zu definieren, also eine Reihenfolge zwischen Nachrichten lebenslinienübergreifend festzulegen, bietet UML das Konstrukt „GeneralOrdering“.
Das folgende Bild zeigt die Verwendung von GeneralOrdering (zugegeben, das Beispiel ist fachlich unglücklich).

Sequenzdiagramm mit Reihenfolge über GeneralOrdering

Sequenzdiagramm mit Reihenfolge über GeneralOrdering

Die Aussage des Diagramms: Der Empfang von getMetaData findet vor dem Empfang von getNumberOfPlans statt, über die Reihenfolge des Versands dieser Nachrichten wird keine Festlegung getroffen.
Für die Verwendung von GeneralOrdering gibt es zwei Gegenanzeichen:

  1. die Frage, ob die Zielgruppe das Diagramm noch versteht
  2. wird GeneralOrdering nicht von allen UML-Tools komfortabel unterstützt

Davon abgesehen bieten Sequenzdiagramme mit GeneralOrdering eine mächtige Möglichkeit, Szenarien zu definieren. Ein Sequenzdiagramm steht für eine Menge von Nachrichtenreihenfolgen, und mit GeneraOrdering kann zwischen einigen dieser Nachrichten eine Art „Precondition“ definiert werden.

Namensgebung

Namensgebung, Nomenklatur oder auch „Benamsung“ genannt, ist täglicher Teil der Arbeit in der Softwarebranche. Die Wichtigkeit eines sinnvollen Namens, unter dem alle Beteiligten dasselbe verstehen, wird oft in Büchern über Patterns betont. Uncle Bob hat in seinem Buch „Clean Code“ sogar ein ganzes Kapitel über „Meaningful Names“ geschrieben. Und trotzdem fällt in Abstimmungen von Schnittstellen oft der Satz: „Über den Namen können wir uns noch später einigen“.

Ein Beispiel, warum genaues Nachdenken über Namen wichtig ist:
Für eine Konsumentenbefragung wird ein Fragebogen modelliert, der mehrere Fragen mit Multiple-Choice Antworten enthält.

Homonym im Modell

Homonym im Modell

Soll neben dem Fragebogen auch das Befragungsergebnis des Konsumenten gespeichert werden, so besteht der ausgefüllte Fragebogen aus den gegebenen Antworten. Die hier zu modellierende Antwortklasse ist allerdings etwas anderes als die in dem Beispieldiagramm:
Ein Fragebogen enthält Fragen, die mehrere Antwortmöglichkeiten haben. Ein ausgefüllter Fragebogen besteht aus gegebenen Antworten.

Wörter, die mehrere Bedeutungen haben („Antwort“ im Beispiel), heißen Homonyme. Beim Modellieren ist peinlichst genau darauf zu achten, dass die einzelnen Bedeutungen durch sinnvolle Namensgebung deutlich gemacht werden.

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“.

Unternehmensformen / Organisation

Hierarchiegeführte Unternehmen haben es schwer, Komplexität zu bewältigen. Dazu gibt es interessante Bücher und Vorträge, z.B. von Niels Pfläging.

Leider haben die wenigsten Gelegenheit, moderne „Beta-Organisationen“ (Begriff von Niels) kennenzulernen, da viele Unternehmen noch hierarchiebehaftet oder eine gemischte Form sind. Hier eine Skizze eines hierarchiegeführten Unternehmens:

Hierarchie

Die Software-Entwicklung oder zumindest Teile dieser Abteilung setzt sich heutzutage oft aus Scrum-Teams zusammen, die allerdings durch die übrigen Hierarchien keinen direkten Kundenkontakt haben. An die übrige Organisation sind diese Teams meist nur über die Person angebunden.

gemischte Unternehmen

Schließlich gibt es Organisationen, die ausschließlich in Teams organisiert sind:

Teams

Und hier ein agiles Unternehmen mit seinen Kunden. Teams, die Kundenkontakt haben, wirken direkt an der Wertschöpfung mit. Teams ohne Kundenkontakt liegen im Inneren der Organisation und werden bei Bedarf von den äußeren Teams in Anspruch genommen.

Kundenkontakt

OCUP part 6: protocol state machines

In addition to the behavioral state machines described in the previous article (that model the behavior of individual entities), there are also „protocol state machines“, which express the valid transitions that can be triggered on a classifier instance.
This type of state machine is widely used in framework documentation to describe the permitted order in which operations of a class can be invoked. A good example for that is the hibernate persistence lifecycle.

A protocol state machine has the keyword „{protocol}“ in its diagram header to be distinguished from behavioral state machines.

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.