Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
UML sequenzdiagramme: Bedeutung von Operanden
Hallo,
in einer Altklausur bin ich auf eine Aufgabe gestoßen, wo ein partielles Sequenzdiagramm mit dem Operator “seq” gegeben war.
Im unteren Operand waren jetzt zwei Aktivitäten, die sich keine gemeinsame Lebenslinie geteilt haben (Aber im gleichen Operanden). Aktivität a1 kam vor Aktivität a2
Als mögliche Traces waren nun auch welche dabei, die die Reihenfolge innerhalb der Operanden nicht beachtet haben. Z.B. war dann möglich, dass zuerst a2 ausgeführt wurde und danach a1, obwohl die beiden ja sich im gleichen Operanden befunden haben.
Ich hab gedacht bei kombinierten Fragmenten, muss bei dem Operator “seq”, aber auch bei allen Anderen, die Reihenfolgen innerhalb der Operanden eingehalten werden und zwischen den Operanden muss dann dementsprechend auf die gemeinsamen Lebenslinien etc geachtet werden. Welchen Sinn hätten diese Operanden ansonsten?
LG
Jonnyfoka
Hi Jonnyfoka,
echt gute Frage von dir. Kann es sein das du dich auf eine Aufgabe der WS15/16 Klausur beziehst?
Habe die Klausur damals selbst mitgeschrieben und mir die Aufgabe kürzlich nochmal angesehen und hatte sie immer noch nicht wirklich verstanden. 
Fand die Erklärung auf der Vorlesungsfolie von den Operatoren + Traces etwas knapp und das Beispiel zu trivial / hat nicht alle Fälle abgedeckt.
Kein Plan ob in UML@Work (ist ja in den Folien empfohlen das Buch) das noch etwas umfangreicher erklärt.
Aber jetzt hab ich nochmal etwas recherchiert und habe den seq-Operator nun wohl endgültig verstanden:
Quelle: Advance Praise for The Unified Modeling Language Reference Manual, Second Edition
D.h. der seq Operator verhält sich wie ein par Operator, nur mit einem zusätzlichen Constraint: Die Reihenfolge von Ereignisspezifikationen auf der gleichen Lebensline von unterschiedlichen Operanden ist gewährleistet. Bei par ist dies nur innerhalb eines Operanden so.
Jetzt zu der Aufgabe die du vor dir hattest:
Du hattest dich gewundert das die Reihenfolge innerhalb des Operanden nicht gewährleistet war. Nun gut, da sich der seq Operator innerhalb eines Operanden wie par verhält, denke ich ist deine Frage damit beantwortet. Innerhalb eines Operanden wird sowohl bei par als auch bei seq nur die Reihenfolge von Ereignisspezifikationen auf der gleichen Lebensline gewährleistet.
Zur Nachvollziehbarkeit ein kurzes Beispiel, da die Klausuraufgabe nicht public ist:
A B C D
| seq | | | | |
|--------------/ | | | |
| | msg1 | | | |
| |------------>| | | |
| | msg2 | | | |
| |<------------| | msg3 | |
| | | |-------------->| |
| | | | | |
| | | | | |
| | | | | |
| | msg4 | | | |
| |<------------| | msg5 | |
| | | |-------------->| |
| | | | | |
Eine Nachricht besteht immer aus 2 Ereignisspezifikationen (Sender und Empfänger jeweils)
Welche Constraints sind hier also definiert: (Ich definiere hier mal A < B als A MUSS immer vor B kommen)
msg1 < msg2 < msg4
msg3 < msg5
(Ereignisspezifikationen auf der selben Lebenslinie)
Wäre das kein seq Operator, sondern ein par Operator hätten wir nur folgenden Constraint:
msg1 < msg2 (Ereignisspezifikationen innerhalb eines Operanden und auf der selben Lebenslinie)
Als Fazit zu der Beispielaufgabe:
msg4 muss nicht vor msg5 kommen, da keine der Ereignisspezifikationen auf den selben Lebenslinien stattfindet.
(Hat bissi länger gedauert die Antwort auf deine Frage. xD Die UML Spezifikation hat sich als nicht besonders erleuchtend erwiesen :D)
Gruß
Christian
critical operator
Hi Christian,
vielen Dank für deine sehr hilfreichen und verständlichen Erklärungen!
Beim Sequenzdiagramm stellt sich mir aber noch folgende Frage:
Ich bin neulich über eine Aufgabe gestolpert die wie folgt lautete:
A B C D
| critical | | |
|--------------/ |
| | | msg.a | |
|<-------------------------------------------------------------------------|
| | | | |
| | | msg.b | |
| |---------------------------------------->| |
| | | | |
| | | | |
Die Aufgabe bestand darin, den Operator herauszufinden, so dass msg.a IMMER unmittelbar vor msg.b kommt. Und die richtige Antwort war “critical” (ich habe jetzt hier schon mal critical zum Verständnis eingezeichnet).
Zum Kontext der Aufgabe: Das Fragment mit “critical” war noch in ein paralleles Fragment eingebettet, welches 2 anderen Messages (was meiner Meinung nach aber ja nichts an der Lösung ändern sollte) beinhaltet. Warum ist hier z.B nicht möglich, dass msg.b vor msg.a kommt. Denn critical besagt ja nur, dass dieses Fragment nicht unterbrochen werden darf. Jedoch kann doch durchaus die Reihenfolge geändert werden (da die msg’s sich keine gemeinsame Lebenslinie teilen)
Vielen Dank,
Simon
Hey Simon,
hmm meinst du die Aufgabe 32 aus dem Braindump SS 17?
Kann mir die Antwort jetzt ad hoc auch nicht erklären… vielleicht auch irgendein Fehler in der Angabe?
Habe bisher bei Critical nur an einen Constraint gedacht:
Abfolge von Ereignissen auf einer Lebenslinie können nicht durch Ereignisse außerhalb des Fragments unterbrochen werden.
Daher kein Plan. Ist dir die Klausur zugänglich? Wenn ja kannst du dich ja nochmal melden.
Will iwie nicht mehr Aufwand in die Aufgabe stecken, wenn ich nicht verifizieren kann ob die Aufgabenstellung im Braindump überhaupt passt 
Gruß
Christian
Nochmal vielen Dank Christian für deine Erklärung.
Endlich verstehe ich jetzt wie das mit den Seq, bzw. Par Operatoren gemeint ist!
Bzgl. Critical bleibt es aber, wie Tenma bereits angedeutet hat, noch unverständlich.
Hierzu habe ich auch gestern den Professor nach der Vorlesung gefragt.
Wenn sich zwei messages bei Critical eine Lebenslinie teilen, dann ist diese Reihenfolge fest und außerdem darf keine andere Message dazwischen kommen, d.h. sie dürfen von einer anderen Message nicht unterbrochen werden. Leider hat er mir jetzt nicht erklärt wie es ist, wenn innerhalb eines Critical Fragments die zwei Messages keine gemeinsame Lebenslinie teilen :-/
Gruß
Jonnyfoka