Archiv der Kategorie: modellierung

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.

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

ScrumRechner Teil 7: Was ist da, was fehlt?

An dieser Stelle kann folgender kurzer Zwischenstand für den ScrumRechner gezogen werden:

Es gibt eine abstrakte Übersicht über alle UseCases, sowie eine detaillierte Beschreibung eines dieser UseCases, mit der in eine Iteration gestartet wurde. Es gibt eine abstrakte Übersicht über die logischen Schichten. Die Ablauf-Sicht wurde kurz gestreift, dabei wurde die erste Designdiskussion dargestellt und mit einem Ergebnis abgeschlossen.

Die Ablauf-Sicht ist noch nicht ausreichend erfasst, es fehlt eine Darstellung der Kommunikation der Objekte über alle Schichten hinweg. Dabei können weitere logische Schichten eingeführt werden. Weiterhin fehlt die Entwicklungssicht mit Komponenten, Paketen und Klassen. Schließlich fehlt noch die Physische Sicht, wobei bei dieser Anwendung die Artefakte und Knoten überschaubar sind.

 

ScrumRechner Teil 6: Die Prozess/Ablauf-Sicht

Der Ablauf einer User-Interaktion zwischen den Schichten ist auf sehr abstrakter Ebene in folgendem Sequenzdiagramm dargestellt:

Ablauf-Sicht

Ablauf-Sicht

Schon auf dieser abstrakten Ebene stellt sich eine grundsätzliche Designfrage: Wer ist verantwortlich, aus den Tastendrücken eine Zahl zusammenzusetzen?

Das GRASP Controller Pattern definiert den Controller folgendermaßen:
Ein Controller ist das erste Objekt hinter der UI-Layer, das für die Verarbeitung der System-Events verantwortlich ist.
Zur Beantwortung der Frage, wo die Verantwortlichkeit zum Zusammensetzen der Zahl aus der Benutzereingabe stattfindet, ist eine Abwägung erforderlich: Ist das Zusammensetzen einer Zahl so kompliziert, dass es bereits einen (Sub-) Prozess des Systems darstellt? Wenn das der Fall ist, dann meldet die UI-Layer die einzelnen Ziffern an den Controller, und ermöglicht die Wiederverwendung dieser BusinessLogik für andere GUI-Technologien (in den UseCases gibt es einen Hinweis auf eine Portierung auf Mobiltelefone). Da es bei der Eingabe der StoryPoints nicht nur um natürliche Zahlen, sondern auch um Kommazahlen (die UseCases erwähnen halbe StoryPoints) geht, ist das Parsen der Zahlen hinreichend kompliziert, um einen Teil der BusinessLogik darzustellen und somit nicht in der View zu erledigen.

Scrum-Rechner Teil 5: Die logische Sicht als Teil des Konzepts

In diesem Beitrag wird die logische Sicht des Scrum-Rechners auf einer sehr abstrakten Ebene entwickelt. Die Anforderungen bestehen in den UseCases, von denen im Moment einer in Details untersucht wurde.
Die Frage, die mit der logischen Sicht beantwortet werden soll, ist: „Wie ist die Software konzeptuell organisiert?“. „Konzeptuell“ in diesem Zusammenhang bedeutet, dass nicht die Organisation in deploybaren Artefakten, sondern die logische Struktur untersucht wird. Detailfagen, die gestellt werden müssen, sind: „Welches sind die wichtigsten Schichten, Subsysteme, Packages, Frameworks, Interfaces und Klassen?“.

Traditionell ist eine Entkopplung der Darstellungsschicht von dem Rest des Systems gewünscht, um den „Impact of change“ bei neuen Anforderungen an die GUI (Designänderungen oder neue Technologien) gering zu halten. Während der traditionelle objektorientierte Weg besagt, dass jedes Objekt sich selbst darstellt (siehe GRASP: Information Expert), wird dieses Prinzip den nicht-funktionalen Anforderungen (hier: der Wartbarkeit) geopfert, und in View-Klassen ausgelagert (GRASP: Pure Fabrication). Microsoft bezeichnet die Trennung der View von dem Rest des Systems als „Document-View Architecture“.

Der UseCase beschreibt schon einige „Spielregeln“, nämlich die Abfolge Operand->Operator->Operand->…. Diese Regeln sollen von der Geschäftslogik (Durchführung der Berechnung) getrennt werden, sie werden also in einen Controller ausgelagert. Ergebnis wäre das Model-View-Controller-Pattern.

Wird für die bekannten Anwendungsfälle wirklich Model-View-Controller benötigt? Der UseCase „Daten eingeben“ erfordert zumindest keine Verbindung zwischen Modell und View. Im Zweifel gilt hier erst einmal: YAGNI. Statt MVC folgt der Entwurf in der logischen Sicht dem Model-View-Presenter Pattern.

logische Sicht des Scrum-Rechners

logische Sicht des Scrum-Rechners

Taschenrechner Teil 4: Die UseCases

Scrum-Rechner: UseCase „Daten eingeben“

Wie schon zuvor in diesem Blog erwähnt, sind UseCases Text, ein UML-Diagramm gibt nur eine Übersicht. Hier wird ein UseCase beschrieben, dafür gibt es auch fertige Templates.

UseCases

UseCases für den Scrum-Rechner

UseCase: Daten eingeben
Scope: Scrum Rechner
Level: User Goal
Primary actor: ScrumMaster
Stakeholders:

  • ScrumMaster: will eine schnelle Eingabe der Daten
  • Empfänger: will eine korrekte Eingabe der Daten, damit das Ergebnis richtig ist

Preconditions: Scrum-Rechner ist gestartet
Postconditions: Ergebnis wird angezeigt
Main Success Scenario:

  1. ScrumMaster startet den Scrum-Rechner
  2. ScrumMaster gibt die StoryPoints einer UserStory ein
  3. ScrumMaster gibt einen Operator ein
  4. ScrumMaster wiederholt Schritte 2+3 solange, bis der „=“-Operator gedrückt wird
  5. Scrum-Rechner zeigt das Ergebnis an

Extensions:
a: jederzeit, Programm stürzt ab

  1. ScrumMaster startet den Scrum-Rechner erneut
  2. Scrum-Rechner zeigt Bereitschaft für eine neue Berechnung an

b: jederzeit, ScrumMaster bemerkt einen Fehler

  1. ScrumMaster wählt „clear all“
  2. Scrum-Rechner zeigt Bereitschaft für eine neue Berechnung an

2a: ScrumMaster gibt eine Zahl > 100 ein

  1. System weist die Eingabe zurück
  2. ScrumMaster wiederholt die Eingabe

2b: ScrumMaster gibt statt einer Zahl einen Operator ein

  1. System weist die Eingabe zurück
  2. ScrumMaster wiederholt die Eingabe

Taschenrechner Teil 3: Das Funktionale

B: Wie werden die Leute dein Produkt verwenden? Lass uns das einmal durchspielen…
A: Also, am Ende jedes Sprints muss ich die StoryPoints (SP) von den UserStories, die der Product Owner abgenommen hat, addieren. Jede Story kann 0-100 StoryPoints haben, es gibt auch halbe Punkte.

Üblicherweise werden 5-8 Stories in einem Sprint fertig. Nehmen wir zum Beispiel den letzten Sprint, da wurden 3 Stories mit 1 SP, eine mit 5 SP und eine mit 8 abgenommen.

Ich starte das Programm, es soll dann bereit für die Berechnung sein. Ich gebe „3 * 1 + 5 + 8 =“ ein, und nach dem „=“ soll das Ergebnis, also 16, angezeigt werden. Wenn mir das plausibel vorkommt, dann klicke ich auf „versenden“, wähle eine Empfängerliste, und dann wird das Ergebnis in einer Mail mit dem Betreff „berechnete Velocity“ an die Personen auf der Liste versendet.

Taschenrechner Teil 2: Die Anforderungen

Zur Kommunikation mit der Person, die das Wissen/die Idee für das Produkt hat, kann ein Dokument mit der Beschreibung der UseCases verwendet werden. In agilen Projekten werden die Anforderungen als User Stories verpackt. Ist der Ideengeber verfügbar, so gibt es eine Interviewtechnik namens „6 Question Analysis“, die an dieser Stelle exemplarisch verwendet wird. Aus den Resultaten des Interviews entstehen dann die UseCases. Das Beispiel konzentriert sich auf die Erfassung der Anforderungen, es wird kein Entwicklungsprozess beschrieben.

Die „6 Question Analysis“ gibt dem Interviewer sechs Fragetypen an die Hand, um die sechs Dimensionen einer Produktidee zu erfahren. Zu jeder Dimension gibt es eine zusätzliche Frage, um die Quantität der Dimension zu erfassen. Die Fragen und Dimensionen sind:
– Was? für das Konzeptuelle
– Warum? für die Motivation
– Wie? für das Funktionale
– Wer? für das Organisatorische
– Wann? für das Zeitliche
– Wo? für das Geographische

– Wie viel? für die Quantität

Hier ein fiktiver Dialog mit der 6 Question Analysis (die Quantität wird in dem Dialog noch nicht besprochen):

A: Ich möchte eine Taschenrechnersoftware für den PC entwickeln lassen und dann als Produkt verkaufen.
B: Was bringt dich auf diese Idee? (Was, Das Konzeptuelle)
A: Ich arbeite als ScrumMaster und muss die Velocity immer im Kopf ausrechnen und dann das Ergebnis per Mail verschicken. Das muss einfacher werden.
B: Welche Gruppe von Personen wird den Taschenrechner kaufen wollen? Gibt es auch Personen, die den Taschenrechner nicht gut finden werden? (Wer, das Organisatorische)
A: Die meisten ScrumMaster, mit denen ich gesprochen habe, hätten auch gerne eine Hilfe zur Berechnung der Velocity. Darunter gibt es Benutzer von HP Taschenrechnern, sie werden den Taschenrechner ablehnen, weil er keine „Umgekehrte Polnische Notation“ (RPN) kann. Und die Firma Microsoft, sie bietet einen ähnlichen Rechner und werden von meinem Produkt nicht begeistert sein.
B: Was werden die Gründe für jede der Gruppen sein, dein Produkt zu nutzen oder abzulehnen? (Warum, die Motivation)
A: Nun, für die ScrumMaster spart das Zeit. Das Rechnen im Kopf mit Kontrolle und das Versenden dauert doppelt so lange. Außerdem werden manchmal Empfänger vergessen, es gibt da immer wieder Fehler. Mit der Software wird es also schneller und besser gehen. Für die anderen Gruppen habe ich die Ablehnungsgründe vorhin schon gesagt.
B: Wann werden die Kunden dein Produkt benutzen? (Wann, das Zeitliche)
A: Nach jedem Sprint, also alle 2-4 Wochen. Das Berechnen und das Versenden wird etwa sieben Minuten dauern.
B: Wo wird dein Produkt eingesetzt werden? (Wo, das Geographische)
A: Die potentiellen Kunden sind in Europa, Nordamerika und Asien. Im Moment will ich mich aber auf Deutschland konzentrieren. Dort soll das Produkt am Arbeitsplatz des ScrumMasters eingesetzt werden, ein PC ist da immer vorhanden. Obwohl, wenn ich mir das recht überlege, in Zukunft ist auch ein Produkt fürs Mobiltelefon denkbar.
B: Wie werden die Leute dein Produkt verwenden? Lass uns das einmal durchspielen… (Wie, das Funktionale)