Archiv der Kategorie: modellierung

Wortstämme

Eine reine Suche nach exakten Wörtern ist bei Internet-Suchmaschinen überholt. Heutzutage werden als Ergebnisse auch Wortvarianten angezeigt. Z.B. liefert eine Suche nach „arbeiten agentur“ die Bundesagentur für Arbeit als ersten Treffer, obwohl auf deren Einstiegsseite das Wort „arbeiten“ gar nicht auftaucht. Das liegt daran, dass die Suche nicht auf den exakten Wörtern, sondern auf Wortstämmen stattfindet.
Ein Wort in der Deutschen Sprache lässt sich auf eine Grundform zurückführen. So haben die Wörter „Arbeiter“, „arbeitete“, „Verarbeitung“ alle die Grundform „Arbeit“. Anders gesagt: Wenn in einem Satz eine bestimmt Form eines Worts stehen muss, dann gibt es eine Bildungsregel, die aus der Grundform die gewünschte Form produziert (insofern besitzt jede Sprache auch ein Metamodell). Für die Suche ist das Gegenteil erforderlich: Bei der Analyse einer Webseite werden aus den Wörtern die Grundformen gebildet und in einer Datenbank abgelegt. Bei der Suche wird die Grundform des Suchbegriffes dann mit der Datenbank verglichen (teilweise können Datenbanken, z.B. MongoDB, schon selbst die Wortstämme bilden).

Natürlich gibt es in den Sprachen Ausnahmen: Neben unregelmäßigen Verben können noch die Bildungsregeln in die Irre führen. Wenn „Arbeit“ und „Verarbeitung“ denn gleichen Sinn besitzen, dann führt dieselbe Bildungsregel bei „Verfassung“ in die Irre, denn „Fass“ besitzt eine andere Bedeutung.

Bei der Internet-Suche ist der Vorteil, dass die Grundform der Wörter für den Nutzer nicht sichtbar ist. Deshalb muss gar nicht die linguistische Grundform gebildet werden, sondern es reicht, mit Reduzierungsregeln die Wörter in eine vergleichbare Form zu bringen. Ein verbreiteter Algorithmus dazu ist der Porter-Stemmer [http://snowball.tartarus.org/algorithms/german/stemmer.html]. Für diesen Algorithmus gibt es Portierungen in unterschiedliche Programmiersprachen, deren Ergebnisse sich aber teilweise von dem beschriebenen Algorithmus unterscheiden. Für die deutsche Sprache wird immer eine spezielle Variante der Implementierung benötigt, die dann auch funktioniert. Ich empfehle, mit ein paar Tests die Eignung des Stemmers zu testen, der Diminutiv wird in den meisten Implementierungen nicht beachtet („Schiffchen“ sollte dasselbe Ergebnis wie „Schiff“ haben), auch bei kurzen Wörtern kann es Probleme geben („ein“, „eine“, „einer“ sollten ebenfalls dasselbe Ergebnis produzieren). Eine Herausforderung ist auch, unterschiedliche Wörter nicht auf denselben Stamm zurückzuführen, „Schwer“ und „Schwester“ können hier zu Verwirrungen führen.

Falls Sie mit dem Gedanken spielen, eine eigene Implementierung eines Stemmers für die deutsche Sprache zu versuchen, so können Sie mich kontaktieren, ich kann Testdaten zur Verfügung stellen und habe auch eine eigene Implementierung eines Stemmers. Kontaktdaten unter http://www.modellierung.net/.

Alles in allem ist die Wortstammbildung noch nicht gänzlich von Computern beherrschbar. Vor dem Anwender kann das teilweise verborgen werden, in der Informationsverarbeitung führt das aber zu großen Problemen.

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