Archiv der Kategorie: praxis

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.

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

EJB: How to start a new transaction for a call on this()

Sometimes it is necessary to start a new transaction in a stateless sessionbean with container managed transactions (CMT). For that, usually a new SLSB is created and given the transactionattribute REQUIRES_NEW. Unknown to many is the fact that from a SLSB, methods on this() can be called that also start a new transaction.
The reason why this doesn’t work out-of-the-box is that a call on this() is a POJO-call and thus the container is unaware of the call and has no chance to handle transactions. So the solution is to make the container aware of the call by obtaining a reference to this() through the SessionContext.
Here is an example for it:

@javax.ejb.Stateless
@javax.ejb.Local(SomeInterface.class)
public class SomeInterfaceImpl implements SomeInterface {
    @javax.annotation.Resource
    private SessionContext sessionContext;

    @Override //has the TX-Attribute REQUIRED
    public List<String> doSomething(){
        sessionContext.getBusinessObject(SomeInterface.class).doInNewTx();
        throw new RuntimeException(); //Abort the Transaction
    }

    @Override
    @javax.ejb.TransactionAttribute(REQUIRES_NEW)
    public void doInNewTx(){
        /* persist something with the EntityManager, it will be persisted
           although the caller rolls back its Tx, cause this method runs
           in its own transaction */
    }
}

To try this out, create SomeInterfaceImpl and SomeInterface, and call doSomething() via an EJB-call. It will internally call doInNewTx() in a new transaction and then abort the current transaction by throwing a RuntimeException. Everything persisted in doInNewTx() will be written to the database, as it uses a new transaction that is committed independently.

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

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.