Archiv der Kategorie: Coad

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.

Erfahrungsbericht UML colors

UML colors war bereits früher ein Thema dieses Blogs. An dieser Stelle kommt deshalb ein Erfahrungsbericht über einen Praxiseinsatz vom UML colors. Der Einsatz liegt zwei Jahre zurück, und die verschiedenen Modelle können leider auf Kundenwunsch nicht hier veröffentlicht werden.

Ein JEE-Projekt für eine kleine Anwendung (Modell als EJBs, View über JSF), die das Testen und Mocking von WebServices unterstützt, sollte von drei Personen durchgeführt werden. Da wir noch nie zusammengearbeitet haben, prallten auch drei verschiedene Ansätze zu objektorientierten Analyse / Design aufeinander.
Normalerweise hätten wir jetzt über Diskussionen (und auch über die Verwendung von GRASP) zu einem gemeinsamen Modell finden können. Da ich aber schon vorher in Kontakt mit UML colors kam (unter anderem durch die IDE „Together„, die das sehr gut unterstützt), schlug ich vor, unser erarbeitetes (und noch nicht ganz vollständiges) Domänenmodell nochmals mit UML colors zu erstellen.

Da wir durch vorherige Diskussionen schon die meisten unklaren Punkte beseitigt hatten, ging die Erstellung des Modells relativ schnell. Eine große Verbesserung gegenüber unserem vorherigen Modell war die strikte Trennung von PPT und Description. Hatten wir vorher noch bei einigen Klassen unbewußt auf diese Trennung verzichtet, konnten diesmal die Descriptions direkt gesucht und identifiziert werden.

Als ein ungewohntes Konzept haben sich die „Rollen“ entpuppt. Dazu muss man Peter Coad verstehen, der immer eine Hinterfragung der Rolle (ist eine Rolle mehr als ein Marker, enthält sie evtl. mehr Informationen) fordert. Wenn eine Rolle zusätzliche Informationen (z.B. Berechtigungen) enthält, kommt man mit dem Rollen-Verständnis von UML colors gut zurecht.

Moment-Intervals und Rollen hängen voneinander ab, d.h. eine Rolle kann man am Besten dann identifizieren, wenn man schon eine Vorstellung des Moment-Intervals, an dem diese Rolle teilnimmt, besitzt. Darüberhinaus war ich erstaunt, dass die Moment-Intervals sich relativ einfach und ohne viele Diskussionen identifizieren ließen.

Das fertige Modell hat mich überrascht. UML colors hat uns wenig Freiraum für Meinungsverschiedenheiten gelassen, und am Ende stand ein Modell, das meiner Meinung nach verständlicher als unser klassisches Modell war.

Die Entwicklungsgeschwindigkeit läßt sich nicht direkt ablesen, denn während des Entwurfs des „klassischen“ Modells wurden auch Dinge geklärt, die dann bei dem UML colors Modell bekannt waren. Subjektiv kam mir die Modellierung nach UML colors aber bedingt durch weniger Diskussionen (über Modellierungsentscheidungen, damit sind jetzt nicht die Diskussionen über Anforderungen / Fachlichkeiten gemeint, die bereits während des Entwurfs des „klassischen“ Modells geführt wurden) aber schneller vor.

Die am Projekt mitwirkenden Personen waren neben mir ein Kollege mit ~20 Jahren Berufserfahrung und ein Kollege mit ~7 Jahren Berufserfahrung. Also reichlich Praxiserfahrung und Design-Fertigkeiten. Dass trotzdem ein deutlich anderes Modell nach dem Ansatz von Peter Coad herauskam, hat mich daher erschreckt; eigentlich dachte jeder von uns, dass er gute, funktionierende Modelle entwerfen kann. An den Gedanken, dass ein schematisches Vorgehen (dass aber weiterhin kreativ bleibt) zu einer besseren Lösung (wie oben beschrieben erscheint sie mir verständlicher) führen kann, musste ich mich erst gewöhnen.

Fazit: UML colors hat in unserem Projekt sehr gut funktioniert, und es hat uns Diskussionszeit gespart. Ich suche immer noch nach der nächsten Gelegenheit, diesen Ansatz wieder einzusetzen.

UML in Farbe: UML colors

Bei der Programmierung von Anwendungen wird (in den meisten Sprachen) mit Klassen gearbeitet. Eine Person wird durch eine Klasse (oder zumindest durch eine Instanz dieser Klasse) repräsentiert. Eine Action, die eine Buchung durchführt, ist bei der Programmierung ebenfalls eine Klasse. Hinter Person und Buchung stehen aber völlig verschiedene Konzepte, eine Person ist mit Information verknüpft und etwas dauerhaftes (im Sinne von: „sollte in einer DB gespeichert werden“). Eine Buchung (damit ist jetzt kein Objekt gemeint, welches Buchungsinformationen darstellt, sondern etwas im Sinne einer Gui-Action oder einer Stateless SessionBean) ist etwas hochdynamisches, sie besitzt keine Identität und ist die in eine Klasse gepackte Business-Logik.
Es werden üblicherweise völlig unterschiedliche Konzepte in Klassen gepackt.

Nun stellt sich die Frage: Ist eine „Klasse“ genug, um diese verschiedenen Konzepte abzubilden?

Peter Coad hat in seinem Ansatz „UML colors“ diese Konzepttypen in vier Archetypen unterteilt:

  • PPTs (Party, Place or Thing): Objekte, die eine echte Identität besitzen
  • Description: Eine Beschreibung, die für eine Klasse von Objekten (also die Gesamtmenge der Instanzen) gilt
  • Role: Eine Rolle, mit der ein Objekt (ein PPT) an einer Interaktion teilnimmt
  • Moment-Interval: Etwas temporäres, kurzlebiges, zum Beispiel temporäre Objekte oder Interaktionsobjekte

Die vier Archetypen ordnen sich in typischer Weise an.  Da eine vollständige Beschreibung von Peter Coads Ansatz nicht Ziel dieses Eintrags ist, verweise ich an dieser Stelle auf diesen Bericht.
Meiner Meinung nach zeigt Peter Coads Konzept sehr gut, dass UML als universelle Modellierungssprache nicht auf spezielle Konstrukte Rücksicht nehmen kann. Peter Coad setzt mit der Markierung der Archetypen durch Stereotypen auf ein von UML bereitgestelltes Mittel, um die Sprache zu erweitern.

Eine andere Möglichkeit zur Unterstützung dieser Konstrukte ist eine Erweiterung des UML-Metamodells. Über einen Package-Merge können die vier Archetypen als Subklassen von „Class“ definiert werden, und dann als Instanzen in Modellen genutzt werden.

uml colors

Die Frage am Anfang war: Ist eine “Klasse” genug, um diese verschiedenen Konzepte abzubilden? Dieser Blog-Eintrag hat die Frage nicht beantwortet. Eine Anwendung kann aus „Klassen-Bausteinen“gebaut werden,  sie kann aber auch aus den vier „Archetyp-Bausteinen“ zusammengesetzt werden.

Der Einsatz von UML colors führt zu neuen Erkenntnissen, ich habe ihn in einem kleinen Projekt eingesetzt, nachdem zu dritt ein herkömmliches UML-Modell erstellt wurde. Unheimlich war, dass das Modell nach UML colors sich anders „anfühlte“, es war aber lückenlos und wurde dann später auch so als Modell der Anwendung  verwendet. Bei Gelegenheit werde ich einen Erfahrungsbericht zu „UML colors“ veröffentlichen.