oo[se] seminar planner
Hier werden Regeln beschrieben, die bei der Modellierung einzuhalten sind.
Das beschreibt die mit ooseminars entwickelte Design-Sprache.
Die Modellierung findet für zwei Schichten statt: die Business-Schicht und
die Präsentations-Schicht.
Dieser Abschnitt bezieht sich auf Regeln, die bei der Modellierung der Business-Schicht eingehalten werden müssen.
| Stereotyp | Anzuwenden auf | Beschreibung |
|---|---|---|
| entity | Class | Eine entity steht für eine Persistenz-Klasse. Sie wird von Hibernate verwaltet. |
| persistent | Attribut einer entity | Ein Attribut, das mit persistent gekennzeichnet ist, wird mit der Entität persistiert. |
| primarykey | Attribut einer entity | Ein primarykey stellt den Primärschlüssel oder einen Teil des Primärschlüssels einer Persistenz-Klasse dar. Der Primärschlüssel ist ein spezielles persistentes Attribut. |
| service | Class | Ein service ist für die Verwaltung von Entitäten verantwortlich und stellt Dienste z.B. für die Präsentations-Schicht zur Verfügung. |
Entitäten können primitive Datentypen speichern.
Zusätzlich zu den primitiven Datentypen, die durch die
UML definiert sind, stehen List, Set und Date
zur Verfügung. Für diese werden bei der Generierung Sprach-spezifische
Klassen eingesetzt.
Beziehungen zu anderen Entitäten müssen über Assoziationen modelliert
werden. Eine Assoziation zu einer anderen Entität kann nicht
über ein Attribut modelliert werden (das ist durch den XMI-Export
von Enterprise Architect begründet).
Dabei müssen gerichtete Beziehungen verwendet werden, weiterhin
müssen Multiplizität und Rollenname angegeben werden.
Ein Service definiert zu einem großen Teil Methoden zum Anlegen,
Aktualisieren und Löschen von Entitäten. Die Generierung der Business-Schicht
verarbeitet z.Z. nur statische Aspekte, da es zu Beginn des Projekts
nicht möglich war, dynamische Aspekte anhand des instanziierten Metamodells
sinnvoll auszuwerten.
Das führt dazu, dass Methoden sowohl als Operationen modelliert
werden müssen, als auch entsprechende Aktivitäten modelliert werden müssen, die
die selbe Signatur wie die modellierten Operationen haben.
Die Operationen müssen modelliert werden, da für sie der Code in Services
generiert wird, die Aktivitäten werden modelliert, um sie von der Präsentations-Schicht,
in der die Abläufe mit Aktivitäten modelliert werden, referenzieren zu können.
Enterprise Architect bietet leider keine Möglichkeit, Operationen und Aktivitäten
synchron zu halten oder in Beziehung miteinander zu setzen, darauf ist zu achten.
Ein Beispiel für die Operation-Aktivität-Beziehung:
Für eine Methode, die eine Liste von Event-Objekten zu einer gegebenen Seminar-Nummer
zurückgeben soll, wurde eine Operation definiert, die sich folgendermaßen
beschreiben lässt:
public List findEventsBySeminarId( int seminarId ).
Dazu muß eine Aktivität modelliert werden, die einen Eingangsparameter seminarId
(der Name muss nicht übereinstimmen) vom Typ int hat mit der Multiplizität 1,
und einen Ausgangsparameter vom Typ Event mit der Multiplizität 0..*.
Die Aktivität muss genauso wie die Operation im Kontext des entsprechenden Services modelliert
werden, d.h. sie muss ein Kind-Element des Services sein.
Die Generierung von Methoden-Deklarationen und -Definitionen auf Grundlage von
modellierten Aktivitäten ist für die Version 1.0 von ooseminars und der Anwendungsfamilie geplant.
Die Generierung von Aktivitäten wird bisher nur in der Präsentations-Schicht umgesetzt.
Dieser Abschnitt bezieht sich auf Regeln, die bei der Ablaufmodellierung mit Aktivitäten beachtet werden müssen. Das ist hauptsächlich für die Präsentationsschicht relevant.
| Stereotyp | Anzuwenden auf | Beschreibung |
|---|---|---|
| control | Activity | Eine mit control stereotypisierte Aktivität beschreibt das Verhalten einer Control-Klasse. Eine Control-Klasse ist für die Ablaufsteuerung verantwortlich. |
| view | Action | Eine mit view stereotypisierte Aktivität repräsentiert einen Benutzerdialog. |
| in | ActionPin, ActivityParameter | Dieser Stereotyp zeigt die Richtung des Objekt-Knotens an.
Wird z.B. ein ActionPin im Sinne eines InputPins modelliert,
muss der ActionPin mit in stereotypisiert werden. |
| out | ActionPin, ActivityParameter | Dieser Stereotyp zeigt die Richtung des Objekt-Knotens an. |
Kontext der Control-Action
Jede mit control stereotypisierte Action muss im Kontext
(als Kind-Element) einer Klasse modelliert werden. Das ist notwendig,
da für eine Control-Action eine Struts-Action generiert wird, und
das Paket für die Klasse bekannt sein muss.
Aufruf von Service-Methoden
Um eine Service-Methode nutzen zu können, muss für diese Methode
eine Aktivität im Kontext des Services modelliert worden sein (s.o.).
Dann kann diese Aktivität in der Control-Action referenziert werden,
indem die Service-Aktivität via Drag'n'Drop auf die Control-Action
gezogen wird. Sollte die Service-Aktivität Objekt-Knoten haben,
müssen diese evtl. separat "nachgezogen" werden (so bei EA Build 733).
Modellierung von Entscheidungen
Bei der Generierung werden z.Z. nur wahr-/falsch-Entscheidungen berücksichtigt.
D.h. eine Decision darf nur zwei ausgehende Kanten mit den Werten true
und false haben.
Die Endknoten, die an den Enden der jeweiligen Abläufe liegen, müssen
benannt sein (das entspricht dem Name des Struts-ActionForward).
Die Control-Action hat entsprechend eine ausgehende Kante, die
auf eine Decision führt. Diese Decision muss zwei ausgehende Kanten
besitzen, die die Namen der Endknoten als Guards haben.
Modellierung von Objekt-Knoten mit primitivem Datentyp
Soll ein Objekt-Knoten einen primitiven Datentyp transportieren,
muss der Objekt-Knoten mit dem Eigenschaftswert ClassifierType
und einem primitiven Datentypen versehen werden. Das ist notwendig,
da EA (in Version 4.1 Build 733) es nicht ermöglicht, nicht modellierte
Klassen als Typ für einen Objekt-Knoten anzugeben.