Hauptseminar Semantik der UML 2.0

Transkript

1 Hauptseminar Semantik der UML 2.0 UML 2.0 Interaktionen Semantik und Verfeinerung Betreuer: Peter Graubmann Bearbeiter: Fei Xie

2 - 1 -

3 INHALTSVERZEICHNIS 1 EINLEITUNG.3 2 GESCHICHTE UND DIAGRAMMARTEN DER UML SEQUENZDIAGRAMME Basis-Sequenzdiagramme Strukturierte Sequenzdiagramme SEMANTIK Die Präliminarien für die Semantik der Interaktionen Die Semantik des positiven Fragments Die Negationen Die Semantik das negativen Fragments VERBESSERUNG DER NEGATION σ-funktionen...15 Funktionen ע IMPLEMENTIERUNG UND VERFEINERUNG ZUSAMMENFASSUNG LITERATURVERZEICHNIS

4 1. Einleitung Diese Seminararbeit basiert auf [1]: UML 2.0 Interactions: Semantics and Refinement (CSDUML 04 Proceedings) 2004 von Maria Victoria Cengarle (Technische Universität) und Alexander Knapp (Ludwig-Maximilians-Universität München). Die in UML 2.0 beschriebenen Semantiken für Interaktionsdiagramme, besonders für die Negation, sind grob und undeutlich. Das Ziel der Autoren war, eine formale Grundlage für eine eindeutige Definition des Negationsoperators der Interaktionsdiagramme in UML 2.0 zur Verfügung zu stellen. Die Kernsprache, die in dieser Arbeit benutzt wurde, ist die Sprache für die verneinte Interaktion. Es hat sich herausgestellt, dass bei der Definition der formalen Semantik für diese Sprache viele Fragen entstanden. Diese betrafen zum Beispiel die klare Klassifizierung der verneinten Interaktionen. In diesem Dokument werden diese Probleme identifiziert und versucht, durch klassische Negation zu lösen. Für weitere Informationen zu Grundlagen der UML können [6]: Object Management Group. Unified Modeling Language Specification, Version 2.0 (Superstructure). Adopted draft, OMG 2003, und die im Literaturverzeichnis angegebenen Veröffentlichungen benutzt werden. 2. Geschichte und Diagrammarten der UML 2.0 Die Unified Modeling Language ("vereinheitlichte Modellierungssprache"), üblicherweise mit UML abgekürzt, ist eine von der Object Management Group (OMG) entwickelte und standardisierte Beschreibungssprache, um Strukturen und Abläufe in objektorientierten Softwaresystemen darzustellen. In diesem Sinne einer Sprache definiert die UML dabei einen Bezeichner für die meisten Begriffe, die im Rahmen der Objektorientierung entstanden sind, und legt mögliche Beziehungen zwischen diesen Begriffen fest. Die UML definiert darüber hinaus grafischen Notationen für diese Begriffe und für Modelle von Software oder anderen Abläufen, die man in diesen Begriffen formulieren kann. Die Väter der UML (insbesondere Grady Booch, Ivar Jacobson und James Rumbaugh, auch "die drei Amigos" genannt) waren in den 90er-Jahren bekannte Propagandisten der objektorientierten Programmierung, die alle bereits ihre (mehr oder weniger ähnlichen) eigenen Systeme entwickelt hatten. 3

5 Als sie zusammen beim Unternehmen Rational Software beschäftigt waren, entstand der Ansatz, die verschiedenen Notationssysteme strukturiert zusammenzuführen. Die UML wurde am 19. November 1997 von der OMG als Standard akzeptiert und wird seitdem von ihr weiter entwickelt. Im Juni 2003 wurde die jüngste Version 2.0 der UML von der OMG als Entwurf veröffentlicht. Die UML 2.0 wurde im November 2004 endgültig verabschiedet [13]. UML 2.0 unterstützt insgesamt 14 Diagrammarten. Sie werden in zwei Gruppen, Strukturdiagramme und Verhaltensdiagramme, unterteilt. Strukturdiagramme haben folgende Diagrammarten: Klassendiagramm, Objektdiagramm, Paketdiagramm, Komponentendiagramm, Verteilungsdiagramm und Kompositionsstrukturdiagramm. Verhaltensdiagramme können eine von acht Formen haben: Interaktionsübersichtsdiagramm, Kommunikationsdiagramm, Aktivitätsdiagramm, Sequenzdiagramm, Anwendungsfalldiagramm, Zustandsdiagramm, Kollaborationsdiagramm oder Zeitverlaufsdiagramm. (siehe Abb. 1). Abbildung 1. Diagrammarten der UML 2.0 [14] Aus Abbildung 1 ersehen wir, dass es vier Arten von Interaktionsdiagrammen gibt: Kommunikationsdiagramme, Sequenzdiagramme, Interaktionsübersichtsdiagramme und Zeitdiagramme. Interaktionsdiagramme beschreiben die Wechselwirkungen zwischen einer Anzahl von Objekten im System. In dieser Arbeit werden wir uns auf Sequenzdiagramme konzentrieren. 4

6 3. Sequenzdiagramme Sequenzdiagramme sind die wichtigsten Interaktionsdiagramme. Ein Sequenzdiagramm beschreibt die zeitliche Abfolge von Interaktionen zwischen einer Menge von Objekten innerhalb eines zeitlich begrenzten Kontextes. Mittels des Sequenzdiagramms beschreibt man die Interaktionen zwischen den Modellelementen ähnlich, wie bei einem Kommunikationsdiagramm, jedoch steht beim Sequenzdiagramm der zeitliche Verlauf des Nachrichtenaustausches im Vordergrund. 3.1 Basis-Sequenzdiagramme Die Objekte werden lediglich mit senkrechten Lebenslinien dargestellt. Die Lebenslinie bedeutet grundsätzlich, dass eine Instanz während der gesamten Ausführung des Ablaufs existiert und zur Verfügung steht. Oberhalb der Linie steht der Name einer Klasse bzw. das Objektsymbol in der Form: Instanzname:Klassenname. Die Nachrichten werden durch waagerechte Pfeile zwischen den Objektlebenslinien beschrieben. Es gibt folgende Nachrichtenarten: Asynchrone Nachrichten werden durch offene Pfeilspitzen gekennzeichnet. Synchrone Kommunikation wird durch ausgefüllte Pfeilspitzen gekennzeichnet. Antworten sind optional und werden durch eine gestrichelte Linie mit offener Pfeilspitze dargestellt. Geht eine Nachricht verloren bzw. ist der Sender einer Nachricht nicht bekannt (>>gefundene<< Nachricht), so dient ein kleiner ausgefüllter Kreis als End- bzw. Anfangspunkt des Nachrichtenpfeils. Auf den Pfeilen werden die Nachrichtennamen notiert. Nach der Spezifikation von UML 2.0 [6] wird die Syntax für Nachrichten wie folgende definiert: messageident::=[attribute=]signal-or-operation-name[(arguments)] [:return-value] * arguments ::= argument [, arguments] argument::=[parameter-name=]argument-value attribute=out-parameter-name [:argument-value] - 5

7 Die Überlagerung der gestrichelten Lebenslinien durch breite, nicht ausgefüllte (oder graue) senkrechte Balken symbolisiert den Steuerungsfokus. Der Steuerungsfokus ist optional und gibt an, welches Objekt gerade die Programmkontrolle besitzt, d.h. welches Objekt gerade aktiv ist. Lokale Attribute, die beispielsweise als Schleifenzähler o.ä. verwendet werden können, werden oben links im Diagramm deklariert. Das Erzeugen (Objektkonstruktion) und Entfernen (Objektdestruktion) von Objekten kann in Sequenzdiagrammen ebenfalls dargestellt werden. Die Konstruktion eines neuen Objektes wird durch eine Nachricht, die auf ein Objektsymbol trifft, angezeigt, die Destruktion eines Objektes durch ein Kreuz am Ende der Lebenslinie. Ein Sequenzdiagramm wird mit dem Schlüsselwort sd gekennzeichnet. Für den durch das Diagramm dargestellten zeitlichen Ablauf gelten die folgenden Regeln: Die Abfolge von Sende- und Empfangsaktionen auf der gleichen Lebenslinie beschreibt deren zeitliche Abfolge. Hierbei ist aber nur die Anordnung der Ereignisse entscheidend, dagegen lassen sich aus der Länge des vertikalen Abstands zwischen Ereignissen keine Informationen über die abgelaufene Zeit ableiten. Die Sendeaktion einer Nachricht findet stets vor der Empfangsaktion für diese Nachricht statt. Auch hier gibt das Diagramm nur die Reihenfolgeninformation wieder, eine Ableitung der Zeitdauer zwischen Senden und Empfangen ist nicht möglich. Für viele Anwendungen sind die reinen Reihenfolgenangaben von Ereignissen aber nicht ausreichend, so spielen Antwort-, Übertragungs- und Verarbeitungszeiten in Echtzeitsystemen eine entscheidende Rolle. Aus diesem Grund können Lebenslinien und Nachrichten in UML 2.0 mit zusätzlichen Zeitangaben verbunden werden. Es gibt zwei Formen für Zeitangaben: Zeitdauerinformationen und Zeitpunktinformationen. Ein erstes einfaches Sequenzdiagramm ist in Abbildung 2 gegeben. In diesem Diagramm ist die externe Sicht auf die Abläufe in einer Organisation dargestellt. Wir erkennen hier vier beteiligte Instanzen: ein Objekt von Klasse Organisator, ein Objekt von Klasse Teambesprechung, sowie zwei Instanzen m1 und m2 der Klasse Teammitglied. Das Diagramm visualisiert einen positiven, d.h. gewünschten Ablauf: ein Organisator erzeugt ein Objekt der Klasse Teambesprechung. Das Objekt sendet 6

8 zuerst eine Nachricht (Termin bestätigen) an das Objekt m1. m1 schickt dann eine Nachricht OK an das Objekt von Typ Teambesprechung zurück. So funktioniert es auch bei m2. Danach wird eine Nachricht (bestätigt) von Teambesprechung an den Organisator gesendet und das Objekt von Typ Teambesprechung wird gelöscht. sd Organization :Organisator m1:teammitglied m2:teammitglied create :Teambesprechung Termin bestätigen OK Termin bestätigen bestätigt OK Abbildung 2. Beispiel für ein Sequenzdiagramm 3.2 Strukturierte Sequenzdiagramme Die lineare Form der Darstellung in Sequenzdiagrammen kann bei komplexen Abläufen schnell zu unübersichtlichen Diagrammen führen. Zusätzlich tauchen auch bestimmte Teilabläufe wie z.b. Initialisierungsphasen in allen Sequenzdiagrammen auf oder aber Abläufe sind bis auf eine kleine Menge von Abweichungen identisch. Aus diesen Gründen bietet UML zwei Mechanismen an, um Sequenzdiagramme besser zu strukturieren und Teilabläufe wieder zu verwenden. Innerhalb eines Sequenzdiagramms kann durch eine Referenz auf ein anderes Sequenzdiagramm verwiesen werden, das einen Teilablauf beschreibt. Alle Lebenslinien, die von der Referenz überdeckt sind, müssen auch in dem zusätzlichen Diagramm auftreten. Dieses kann aber darüber hinaus noch weitere Lebenslinien enthalten. Durch Referenzen kann eine Interaktionsbeschreibung in beliebig vielen anderen Sequenzdiagrammen wieder verwendet werden. Operatoren erlauben es auf der anderen Seite, ähnliche Abläufe innerhalb eines Sequenzdiagramms darzustellen. Dabei werden durch die Operatoren diejenigen Abschnitte gekapselt, die die Einzelabläufe voneinander unterscheiden. 7

9 Ein Operator wird durch ein Rechteck dargestellt, das horizontal alle Lebenslinien überdeckt, die von diesem Operator betroffen sind und in seiner linken oberen Ecke den Namen des Operators trägt. Alle Kommunikationsaktionen (Senden und Empfangen von Nachrichten), die unter Kontrolle des Operators ablaufen, werden innerhalb des Operator-Rechtecks dargestellt. Der Operator kann wiederum mehrere einzelne Sektionen enthalten, die durch eine gestrichelte waagerechte Linie voneinander abgetrennt sind. Die Interpretation der Einzelsektionen ist unterschiedlich in Abhängigkeit von der Form des Operators. In UML 2.0 gibt es folgende Operatoren. opt: Die einfachste Form eines Operators ist der opt-operator. Mit ihm werden optionale Teilabläufe markiert. Ein opt-operator umfasst nur eine Sektion. seq: Der Seq-Operator definiert eine bestimmte Art der Sequentialisierung der Teilabläufe. (schwache Sequenzialisierung). par: Der par-operator fügt Teilabläufe parallel zusammen. Er erlaubt eine beliebige Vermischung der Sende- und Empfangsaktionen aus den verschiedenen Sektionen. Gefordert wird lediglich, dass die Reihenfolge der Aktionen bezogen auf die Einzelsektionen eingehalten wird. strict: Der strict-operator definiert eine Sequenzialisierung der Teilabläufe die stärker eingeschränkt ist als beim seq-operator. Die durch den strict-operator definierte starke Sequenzialisierung verlangt, dass die Abläufe der einzelnen Sektionen vollständig abgeschlossen sind, bevor die Abläufe in den nachfolgenden Sektionen fortgesetzt werden. Somit ist innerhalb des strict- Operators die vertikale Position von Sende- und Empfangsereignissen nicht nur separat für jede einzelne Lebenslinie, sondern für alle Lebenslinien gleichzeitig signifikant. loop: Durch den loop-operator wird die wiederholte Sequenzialisierung der gleichen Abläufe definiert: Der durch den Operator gekapselte Teilablauf kann gar nicht, einmal oder mehrfach nacheinander ausgeführt werden. Der loop- Operator besitzt zwei optionale Argumente, die die minimale und maximale Anzahl an Wiederholungen angeben. Zunächst wird die vorgeschriebene Mindestanzahl an Wiederholungen ausgeführt. Vor jeder weiteren Wiederholung wird dann geprüft, ob die Bedingung wahr ist und ob die maximale Zahl an Wiederholungen noch nicht erreicht wurde, und gegebenenfalls der Operator verlassen. 8

10 alt: Durch einen alt-operator werden verschiedene alternative Abläufe in einem Sequenzdiagramm zusammengefasst. Ein alt-operator besitzt zwei oder mehrere Sektionen, die den einzelnen Alternativen entsprechen. Die Auswahl der zu nutzenden Alternative erfolgt auf der Grundlage einer entsprechenden Bedingung, die zur Ausführung der Sektion wahr sein muss. Eine Sektion kann dabei durch else gekennzeichnet werden. Sie wird immer dann ausgewählt, wenn keine der mit expliziten Bedingungen versehenen Sektionen genutzt werden kann. ignore: Alle in einem ignore-operator als Parameter übergebenen Nachrichtentypen werden bei der Ausführung der Interaktion nicht berücksichtigt. Das bedeutet, dass sie den Ablauf nicht beeinflussen und, obwohl nicht explizit angegeben, jederzeit während des Ablaufs auftreten können. assert: Durch den assert-operator kann eine zwingend notwendige Ablauffolge angegeben werden. neg: Mit einem Sequenzdiagramm können auch unerwünschte bzw. unzulässige Abläufe spezifiziert werden. Mit dem neg-operator gekapselte Abläufe entsprechen genau diesen unzulässigen Abläufen. Es gibt zusätzlich noch ein paar Operatoren, z.b. break, critical, consider, die jedoch in diese Arbeit nicht betrachtet werden. Die abstrakte Syntax der Interaktion ist durch die Grammatik in Tabelle 1 gegeben. Tabelle 1. Abstrakte Syntax der Interaktionen (Fragment) 9

11 Hier ist ein einfaches Beispiel für den Operator ref. Abbildung 3. Sequenzdiagramm mit Operator ref Hier ist ein ganz einfaches Beispiel für Diagramm mit Referenz. Das Diagramm hat drei Instanzen, x, y, z und zwei Referenzen auf andere Sequenzdiagramme. Wir können die drei Sequenzdiagramme zusammen in ein einziges Sequenzdiagramm zeichnen. Das oben gezeigte Interaktionsdiagramm ist äquivalent zu dem folgenden traditionellen Interaktionsdiagramm: sd x Y z Abbildung 4. Basis-Sequenzdiagramm von Abb. 3 10

12 Operatoren können miteinander kombiniert werden. In diesem Fall werden alle anzuwendenden Operatornamen gleichzeitig in dem Operatorrahmen angegeben (z.b. assert consider oder opt alt). 4. Semantik In den vorstehenden Abschnitten werden folgende Themen diskutiert: Was ein Sequenzdiagramm ist, welche Komponenten Sequenzdiagramme haben und wie die Komponenten in Diagrammen notiert werden. Wir gehen jetzt noch einen Ebene tiefer und untersuchen, wie die Interaktionen formal beschrieben werden sollen. 4.1 Die Präliminarien für die Semantik der Interaktion In Abbildung 5 wird ein ganz einfaches Sequenzdiagramm gezeigt. x Y e1 a e2 e3 b e4 Abbildung 5. Beispiel für einfaches Sequenzdiagramm In diesem Sequenzdiagramm sind die folgenden Abläufe und nur sie möglich: e1 e2 e3 e4 oder e1 e3 e2 e4 Um alle möglichen Abläufe mathematisch formal zu beschreiben, verwendet man partiell geordnete, bezeichnete Multimenge (pomset). Eine partiell geordnete, bezeichnete Multimenge (oder pomset) ist eine Klasse [(X, x, λx)], wobei X eine vorgegebene Menge von Ereignissen, x eine partielle Ordnungsrelation und λx eine Bezeichnerfunktion sind. Eine Spur ist eine pomset, die total geordnet ist. Wir schreiben lin(p) für alle möglichen Linearisierungen einer 11

13 pomset p. [(X, x, λx )] ist ein Element von lin([(x, x, λx)]), wenn und nur wenn, X =X, λx = λx and x x, wobei x1 x x2 oder x2 x x1 für alle x1, x2 X. Das leere pomset, das durch (φ,φ,φ ) repräsentiert wird, ist durch ε gekennzeichnet. Sei p = [(X, x, λx)] und q = [(Y, y, λy)] und X Y =φ. Die Nebenläufigkeit von p und q, die als p q geschrieben wird, ist durch die Klasse [(X Y, x y, λx λy)] gegeben. Die Konkatenation von p und q, die als p;q geschrieben wird, ist durch die Klasse [(X Y, ( x y (X Y))*, λx λy)] gegeben. Sei eine symmetrische Relation der Beschriftungen von p und q. Die -Konkatenation von p und q, ist durch p; q gegeben, das eine Klasse [(X Y, ( x y {(x,y) X Y λ X (x) λ Y (y)})*, λx λy)] definiert. Die Konkatenation und Nebeläufigkeit ist assoziativ und kommutativ. -Konkatenation sind assoziativ, die Das pomset, das das Sequenzdiagramm in Abbildung 5 beschreibt, kann wie folgend definiert werden. [({e1,e2,e3,e4}, {(e1,e1),(e1,e2),(e1,e3)(e2,e2),(e2,e4)(e3,e3),(e3,e4)(e4,e4)}, {e1 snd(x,y,a}, e2 rcv(x,y,a), e3 snd(x,y,b), e4 rcv(x,y,b)})] Wir definieren zusätzlich noch zwei Domänen für Instanzen I und Nachrichten M. Ein Ereignis e ist entweder in der Form snd(s, r, m) oder in der Form rcv(s, r, m). Die beiden Formen repräsentieren das Absenden und den Empfang der Nachricht m mit Sender s und Empfänger r. Hier sind s und r Instanzen. Die Menge von Ereignissen wird durch E bezeichnet. Außerdem definieren wir eine binäre, symmetrische Konfliktrelation auf Ereignisse: Wenn eine Instanz aktiv für beide Ereignisse e und e ist, wird diese Beziehung durch e e bezeichnet. Bei der Repräsentation eines endliches pomsets schreiben wir eine konkretere Notation {snd(s, r, m) rcv(s, r, m)} statt die [({e1, e2}, {(e1, e1), (e1, e2), (e2, e2)}, {e1 a snd(s, r, m), e2 a rcv(s, r, m)})]. In gleicher Weise benutzten wir für die Repräsentation endlicher Spuren des obigen Beispiels die Notation snd(s, r, m) rcv(s, r, m). Die Domäne P beinhaltet alle pomsets [(E, E, λ E )] mit allen Ereignisse in E. Wir definieren hier eine Funktion: filter(m): P φp. Diese Funktion nimmt ein paar Elemente von der Domäne P weg, die eine Nachricht in M haben. 4.2 Die Semantik des positiven Fragments Wir nennen die Interaktionen ohne Auftreten der Negation und Assertion das positive Fragment. Die positive Befriedigungsrelation (Eng. Positiv Satisfactions) zwischen Spuren und Interaktionen ist durch t p S gekennzeichnet, wobei t eine Spur und S 12

14 eine Interaktion des positiven Fragments ist. Die Semantik des positiven Fragments ist induktiv in Tabelle 2 definiert; dabei steht B für die Menge der (nicht durch Operatoren zusammengesetzten) Basis-Interaktionen, S, S1 und S2 sind Interaktionen, M steht für Nachrichten, m und n sind natürliche Zahlen. Tabelle 2. Semantik des positiven Fragments 4.3 Die Negationen In dieser Arbeit werden wir uns auf die Negation konzentrieren. In der UML 2.0 Spezifikation sind manche Features der Interaktionssprache nicht eindeutig spezifiziert, z.b. die Negation. In [6] wird der Operator neg folgendermaßen spezifiziert: The interaction Operator neg designates that the Combined Fragment represents traces that are defined to be invalid. The set of traces that defined a negative Combined Fragment is equal to the set of traces given by its (sole) operand, only that this set is a set of invalid rather than valid traces. All Interaction Fragments that are different from Negative are considered positive meaning that they describe traces that are valid and should be possible. UML 2.0 Interaktionen beschreiben positive und negative Spuren des Auftretens von Ereignissen. Die Benutzung der monadischen Operatoren neg(-) und assert(-) führt zu negativen Spuren. Die positiven und negativen Spuren, die durch eine Interaktion definiert sind, decken nicht alle mögliche Interaktionen ab. Die übrigen Spuren werden ergebnislos (Eng. inconclusive) genannt. Um die Ungenauikeiten der Spezifikation zu vermeiden, versucht man eine klarere Spezifikation für Operator neg 13

15 zu definieren. Störrle bedenkt drei verschiedene Interpretationen für Operator neg(s). (1) not the [valid] traces of s. (2) Anything but the [valid] traces of s. (3) The negative traces of S to be the positive traces for neg(s)[7]. Haugen und Stølen interpretieren hingegen, dass die positive Spuren von neg(s) nur aus der leeren Spur bestehen [3]. In dieser Arbeit werden wir die Definition von Haugen und Stølen benutzen. 4.4 Die Semantik das negativen Fragments Die Semantik einer verneinte Interaktion neg(s) ist wie folgend definiert. Die positiven Spuren von neg(s) sind solche Spuren, die nicht positiv für S sind und die negativen Spuren sind die Spuren, die positiv für S sind. Derartige Definition schließen jedoch die ergebnislosen (inconlusive) Spuren aus. Im Allgemeinen müssen wir die positiven, negativen und inconlusiven Abläufe unterscheiden. Wir schreiben n, wenn t negativ S befriedigt. Die induktive Definition für die Relation n ist in Tabelle 3 gezeigt, wobei B für die Menge der Basis-Interaktionen steht, S, S1 und S2 sind Interaktionen, M steht für Nachrichten, m und n sind natürliche Zahlen. Wir definieren n besonders für alle kombinierten Interaktionsfragmente. Sie entsprechen der Definition von Haugen und Stølen. Wir betrachten die leere Spur als positiv für neg(s). Für die kombinierte Fragments strict(-, -) und seq(-, -) sind nur solche Spuren negativ, die negativ für den erste Operand sind oder positive für den erste Operand aber negativ für den zweite Operand sind. Ein sehr interessanter Fall ist gegeben durch folgendes Beispiel. Sei Bi die Basis- Interaktion {snd(s i, r i, m i ) rcv(si, r i, m i )} (i = 1, 2, 3), wobei alle m i verschieden sind und t i die Spuren snd(s i, r i, m i ) rcv(s i, r i, m i ) (i = 1, 2, 3) bedeuten. Von den obenstehenden zwei Formeln käönnen wir ableiten, dass t2 gleichzeitig positiv und negativ für die Interaktion strict(neg(b2), B2) ist. Wir nennen strict(neg(b2), B2) deshalb eine überspezifizierte Interaktion. 14

16 Tabelle 3. Erweitete Semantik für die Negation 5. Verbesserung der Negation Die nicht klassische Interpretation der Negation ist schwierig zu handhaben. Vor allem werden zwei Befriedigungsrelationen, eine positive und eine negative, gebraucht. Es ist schwer zu entscheiden, ob eine Spur positiv, inconclusive oder negativ für eine Interaktion ist. Die Negation ist natürlich nicht nötig für die positive Befriedigungrelation. Für die Ableitung der negativen Befriedigung wird die Negation natürlich gebraucht. Die kann aber durch eine klassische Version ersetzt werden. Wir führen jetzt die Sprache der Interaktion in klassische Sinne ein. 5.1 σ-funktionen Wir definieren hierfür eine Funktion σ, die einer Interaktion genau eine Interaktion des positiven Fragments zuweist. Die Funktion σ ist induktiv wie in Tabelle 5 definiert; dabei steht B wieder für die Menge der Basis-Interaktionen, S, S1 und S2 sind Interaktionen, M steht für Nachrichten, m ist eine natürliche Zahl, n ist eine natürliche Zahl oder. 15

17 Tabelle 4. Die Definition für die σ Funktion Aus Tabelle 2 und Tabelle 4 ist leicht abzuleiten, dass t p S wenn und nur wenn t p σ(s). Aber eine binäre Logik ohne Negation ist nicht genug. Allerdings reicht eine binäre Logik mit klassischer Negation aus. Wir fügen hierfür einen Operator not(-) zum positiven Fragment der Interaktion hinzu. Diese Interaktion ist eine sogenannte Interaktion im klassischen Sinne. Die Operatoren neg(-) und assert(-) werden entfernt und der Operator not(-) wird hinzugefügt. Die positive Semantik der Interaktion im klassischen Sinne ist gegeben durch die Semantik für das positive Fragment von UML 2.0 Interaktion in Tabelle 2 und Wir führen weitere Abkürzung hinzu: Any = ignore(m, skip) None = not(any) and(s1, S2) = not(all(not(s1), not(s2))) Funktionen -ע 5.2 Wir definieren eine Funktion,ע die einer Interaktion genau eine Interaktion im klassischen Sinne zuweist. Die Funktion σ ist induktiv wie in Tabelle 6 definiert, wobei B für die Menge der Basis-Interaktion steht, S, S1 und S2 sind Interaktionen, M steht für Nachrichten, m ist eine natürliche Zahl, n eine natürliche Zahl oder. 16

18 Tabelle 5. Die Definition für die ע Funktion Sei S eine UML 2.0 Interaktion und t eine Spur. Dann ist t n S, dann und nur dann, wenn, t p.( S )ע Um dies zu beweisen, führen wir ein partielle Ordnung in UML 2.0 Interaktionen ein, wobei S, S1 und S2 beliebige Interaktionen, und m und n natürliche Zahlen sind. Tabelle 6. Partielle Ordnung an UML 2.0 Interaktionen Zusammengefasst haben wir zwei Resultate: t p S falls t p σ(s) t n S falls t p ( S )ע Dabei ist S eine beliebige UML 2.0 Interaktion, σ(s) eine Interaktion des positives Fragments und ( S )ע eine Interaktion im klassischen Sinn. Mittels der zwei Transformationen σ und ע können wir ein Testen auf negative Befriedigung vermeiden. 17

19 6. Implementierung und Verfeinerung Wir haben eine formale Semantik für Interaktionen und die Implementierung einer Interaktion durch einen Prozess ein. führen jetzt die Notation für Ein Prozess I ist eine Implementierung einer Interaktion S, geschrieben I 1. Es existiert ein t lin(i) mit t p S, und 2. t S für alle t lin(i). Eine Interaktion ist implementierbar, wenn es einen Prozess I mit I S, falls S gibt. Für jede Interaktion S existiert eine Spur t mit t p S. Zwei Interaktionen S1 und S2 sind äquivalent, gekennzeichnet durch S1 S2, wenn für alle Prozesse I gilt, I und nur wenn I S2. S1 wenn Eine Interaktion S ver feinert eine Interaktion S, geschrieben S S, wenn alle Implementierung für S auch eine Implementierung für S sind. Das heißt, I S impliziert I S für alle Implementierung I. Ein Beispiel für eine Interaktionsverfeinerung ist wie folgend gezeigt. alt(s1, S2) Si, für i =1, 2 7. Zusammenfassung Im Dokument UML 2.0 Spezifikation sind einige der Features der Interaktionssprache nicht eindeutig spezifiziert, z.b. die Negation. Das Ziel dieser Arbeit ist der Versuch, die Lösung des Problems zu beschreiben. Deshalb haben wir zuerst die Syntax und Semantik der Interaktion formal beschrieben. Besonders haben wir die positiven, negativen und inconclusiven Abläufe für Interaktionen klassifiziert. Schließlich versuchten wir durch die Einführung von zwei Funktionen, σ und ע eine klassische Interpretation des Negationsbegriffs einzuführen, die das Testen auf negative Befriedigung überflüssig macht. 18

20 8. Literaturverzeichnis 1. Maria Victoria Cengarle und Alexander Knapp. UML 2.0 Interactions: Semantics and Refinement. In Jan Jürgens et. Al., editors, Critical Systems Development with UML (CSDUML 04, Proceedings). To apper, Tom Pender. UML Bible. Wiley Publishing, Øystein Haugen and Ketil Stølen. STAIRS Steps to Analyze Interactions with Refinement Semantics. In Perdita Stevens, Jon Whittle, and Grady Booch, editors, Proc. 6th Int. Conf. Unified Modeling Language (UML 03), volume 2863 of Lect. Notes Comp. Sci., pages Springer, Berlin, Marc Born, Eckhardt Holz und Olaf Kath. Softwareentwicklung mit UML 2. ADDISON-WESLEY, Bernd Oestereich. Objektorientierte Softwareentwicklung, Analyse du Design mit der UML 2.0. Oldenbourg, Object Management Group. Unified Modeling Language Specification, Version 2.0 (Superstructure). Adopted draft, OMG, Harald Störrle. Assert, Negate and Refinement in UML-2 Interactions. In Jan Jürjens, Bernhard Rumpe, Robert France, and Eduardo B. Fernandez, editors, Proc. Wsh. Critical Systems Development with UML (CSDUML 03), San Francisco, Technische Universität München, Technical report TUM-I SS2003/vortrag3.pdf