|
|
 |
|
|
|
|
 |
|
|
|
UML wurde als Sprache zur Modellierung von kompletten Softwaresystemen entwickelt. Sie eignet sich jedoch auch sehr gut, um nur Teile von Systemen zu beschreiben. Für diesen Fall ist es jedoch noch dringender als im ersten Fall nötig, die Semantik der UML präzise festzulegen. Nicht nur die informale Definition der Konstrukte trägt hier zu Missverständnissen bei, sondern auch deren Fehlen. Im folgenden soll also beschrieben werden, wann, zu welchem Zweck und auf welche Weise Spezifizierungen ohne Informationsverlust ausgespart werden können.
|
|
|
Beispiel 1:
In Figur 1 wird eine isolierte Klasse ohneSuperklasse und zugehöriges Statechart Diagramm deklariert. Argumentiert man auf rein sysntaktischer Ebene, so hat diese Klasse damit kein (durch ein Statechart darstellbares) Verhalten.
Tatsächlich aber sollen die deklarierten Operationen der Reihe nach aufgerufen werden können. Sinnvoll ist daher, das in Figur 2 dargestellte default Statechart Diagramm anzunehmen (es ist nur eine der 2 rekursiven Transitionen sichtbar, Gruss an Rational). Demnach können, nachdem das Objekt erzeugt wurde, der Reihe nach die Operationen aufgerufen werden, bis das Objekt zerstört wird. Es ist sicherlich weder nötig noch realistisch, in einem solchen Fall jedes Statechart Diagramm für alle Klassen mit allen Operationen manuell einzugeben. Ratsam ist daher diese erste Interpretation eines fehlenden Statechart Diagramms.
|
|
|
|
|
Die Sache wird allerdings erst dann interessant, wenn eine Klasse neben Attributen und Operationen auch ein Statechart von seiner Oberklasse erbt wie in Figur 3 dargestellt.
Spezifiziert die Unterklasse neue Operationen, die nicht in dessen Statechart Diagramm auftauchen, gibt es mindestens drei Interpretationen:
- Die Operation passt in ein besonderes aus der Oberklasse resultierendes Schema.
- Die neue Operation kann immer ausgeführt werden.
- Wir haben einen Fehler gefunden, der nicht automatisch behoben werden kann.
In den beiden ersten Fällen kann es möglich sein, die fehlerhafte Spezifikation sinnvoll zu vervollständigen. Im ersten Fall wird dabei von der neuen Operation erwartet, dass sie sich analog zu den ererbten Operationen verhält. Die Schwierigkeit liegt hier offensichtlich darin, die Schemata automatisch zu erkennen und die neue Operation sinnvoll einzufügen. Realistisch ist hier nur interaktive Vervollständigung, die das zugrundeliegende Schema bafragt und entsprechend behandelt.
Im zweiten Fall ist die Lage sehr viel einfacher. Die Operation kann als rekursive Operation an allen Platzen definiert werden.
|
|
wird fortgesetzt... :-((
|
|
|
