Braindump SS2010 Aufgabe 9 UML

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.

Braindump SS2010 Aufgabe 9 UML
Hat da jemand eine Lösung, die her hier posten würde?

Danke


Hier nochmal der Link zum Braindump https://fsi.informatik.uni-erlangen.de/dw/_media/pruefungen/bachelor/konzmod-braindump-ss10.txt?id=pruefungen%3Abachelor%3Aindex&cache=cache

Traces sind bei soetwas normalerweise vorgegeben und die sind hier nicht angegeben.
[???] Ich nehm an, dass die Reihenfolge auf den Lebenslinien selbst eingehalten werden muss (sowohl fürs Empfangen als auch fürs Senden) nachdem es ja keine strict, par oder seq Fragmente gibt. Außerdem nehme ich an dass der Wert gr aus dem Opt und loop sich auf das ausführen der Nachricht gr bezieht nachdem oben auch überall 1 steht.[???].

Nach diesen Annahmen müsste ja:

g vor gr wird gefolgt von j
ohne j keine loop
f vor fr
r schließt p aus

imho sollte immer gehen (unabhängig von meinen zwei Behauptungen oben):
g → gr → j → f → fr → p
g → gr → j → f → fr → r
Wahrscheinlich geht:
g → gr → j → f → fr → p → f → fr → r (loop wird nur einmal ausgeführt)
Glaube nicht:
f → g → gr → j → fr → p (geht nicht weil die zweite Lebenslinie f empfangen hat bevor sie j empfangen hat)
f → fr → r (sieht so aus als würde es gehen aber wenn gr = 0, darf die loop nicht ausgeführt werden)
g → gr → j → f → fr → p → f → fr → p (loop darf nur einmal ausgeführt werden wenn gr = 1 nachdem j ausgefürht wurde)
f → g → gr → fr → p (j muss benutzt werden nachdem gr ausgeführt wurde)

Folgendes hättest du sicher nicht gebraucht aber ich schreib nochmal raus was ich denk was die bedeuten, dass ggf noch jemand seinen Senf dazu geben kann und ich es einmal mehr geschrieben hab :wink:

strict → Nachrichten werden von oben nach unten abgearbeitet, egal auf welcher Lebenslinie
critical → Bereich der nicht unterbrochen werden darf
consider → Markiert wichtige Nachricht, die beim Fehlen zu Fehlern führen
ignore → Markiert unwichtige Nachrichten die eintreten können aber nicht relevant sind
assert → Zusicherung dass Bedingung eingetroffen sein muss für das Fragment
neg → Markiert Nachrichten die nicht eintreffen dürfen


g → gr → j
sollte auch auf jeden Fall gehen - außerdem bump um Jemanden zu finden der mehr Ahnung davon hat als ich


Laut Spezifikation heißt consider: ignore alles andere.


Danke, wo hast du das her? Also die einzige Spezifikation die ich find ist bei IBM und die ist ehrlich gesagt nicht recht viel besser als der Satz im Script und in der Übung.


Die komplette Spezifikation findet sich hier:
http://www.omg.org/spec/UML/2.2/

Und konkret die Bedeutung von consider/ignore findet sich in diesem Dokument auf pdf-Seite 491 bzw. Seitennummer 475, Abschnitt “Semantics”:
http://www.omg.org/cgi-bin/doc?formal/2009-02-02.pdf

Wer wissen will wie toll UML wirklich ist lese das ganze verlinkte Dokument durch - aber bitte erst nach der Klausur… kotz


Danke für die Links.

Außerdem mag nicht jemand anders mal seine Meinung zu dem abgebildeten Sequenzdiagram sagen? (Vorallem lächerlich wie das nur 3 Punkte gibt obwohl es eine Transferaufgabe ist, während TopN mehr als das doppelte gibt und standardisierter Quark ist)


Ich hab jetzt nochmal in der Spezifikation gelesen, danke für den Link, aber was seq und vor allem strict genau bedeuten hab ich immer noch nicht gerafft.

par:

  • Reihenfolge innerhalb der Operanden abhängig von den Lebenslinien
  • wann Ereignisse anderer Operanden dazwischenfunken ist egal

seq (stimmt das so?):

  • Reihenfolge innerhalb der Operanden muss genau so bleiben, wie die Aktionen auftauchen
  • die Reihenfolge von Ereignissen verschiedener Operanden ist beliebig, solange alle Ereignisse auf den selben Lebenslinien ihre Reihenfolge nicht ändern

strict:

  • keine Ahnung
    Mein erster Gedanke war ja, dass strict wie seq ist, nur dass die Operanden komplett abgeschlossen sein müssen, bevor der nächste begonnen wird. Aber dann könnte man sich die Unterteilung in Operanden auch ganz sparen.

Stimmt so. Bei strict wird alles von oben nach unten abgehandelt, also die beiden Fragmente vermischen sich nicht.


… d.h. ein Operand nach dem nächsten bei strict?


Ja, laut Definition wird da der 2. noch gar nicht beachtet und einfach zuerst beim 1. alles ausgeführt, erst anschließend kommt der nächste.


Aber dann bräuchte man ja garkeine Operanden machen, wenn man sowieso alles nacheinander Ausführt. Oder ist die Reihenfolge innerhalb der Operanden bei strict (im gegensatz zu seq) egal?

(Edit: Und sorry dass das so ähnlich schon woanders gefragt wurde, dachte ich hätte alles UML Threads durch gehabt^^)


Nein, ist nicht egal. Ein Beispiel ist in den Folien, Seite 36f. Da sieht man eigentlich ganz schön den Unterschied …


Ich glaube strict müssen immer so konstruiert werden, dass wenn ich sie von oben nach unten abarbeite die Lebenslinien nicht verletzt werden.

Aber was ist dann der Unterschied zu keinem Fragment?

/edit am Beispiel Seite 37 Skript UML 1

ginge ohne Strict die Traces:
c1 → a1 → a2 → b1 → c2
a1 → c1 → a2 → b1 → c2

und das ist der Unterschied (also dass ich nicht von oben nach unten durchgehen muss wie beim strict und keine Lebenslinien verletzten darf?)

Aber dann gibts wieder keinen Unterschied zu seq… :cry:


Ich hab mir die Vorlesung zu den Sequenzdiagrammen nur als Video vom letzten Semester angeschaut und glaube mich erinnern zu können, dass er da gesagt hat, das seq default ist. also wenn nichts da steht ists seq


Prima danke, dann ist ja wieder alles gut