UML Zustandsautomat: Syntax von Transitionen

Wissenschaft Informatik
#1

Hallo,

kann mir jemand erklären, wozu in einer Transition eines Protokollzustandsautomaten der „/“

Eine Transition in einem Verhaltenszustandsautomat sieht aus wie auf Seite 566 in Tabelle 15.2.
Bei einem Protokollzustandsautomat habe ich ja allerdings nur Vorbedingung, Trigger und Nachbedingung (Superstructure S. 518f), die Transition würde dann so aussehen:

[pre condition] trigger [post condition] /

Was soll da jetzt der Slash bedeuten?? Ich seh eindeutig, dass er da hin gehört, kann aber die Stelle nicht finden, die mir besagt, dass er da hin gehört und was er da soll.

Tausend Dank für jede hilfreiche Antwort!
Dirk

#2

Beispiel war falsch,

[pre condition] trigger [post condition] /

laut Seite 520

[pre condition] trigger / [post condition]

Fragen bleiben aber die selben…

#3

Hallo Dirk.

kann mir jemand erklären, wozu in einer Transition eines
Protokollzustandsautomaten der „/“

  • dient,
  • was er zu bedeuten hat und
  • wo er definiert ist in der UML Superstructure

Die Notation der Transition im Verhaltenszustandsautomaten
(=BehaviourStateMachine für die interne White-Box-Verhaltensbeschreibung) ist in Kapitel 15.3.14 auf Seite 557 der UML Superstructure Spec 2.0
definiert als (hier etwas vereinfacht):

TRIGGER [GUARD] / EFFECT

Unter TRIGGER ist ein Auslöser, ein Ereignis oder
ein Methodenaufruf zu verstehen.

Die Protokolltransition in einem Protokollzustandsautomaten (ProtocolStateMachine)
dagegen darf als Black-Box-Verhaltensbeschreibung keine
Seiteneffekte (EFFECT) haben und muss alle Zuständsübergänge
vollständig beschreiben.

Daher wird statt EFFECT eine Vor- und eine Nachbedingung
eingeführt. Es ergibt sich die Notation aus Figure 15.15, S. 521 der
Spec:

[PRECONDITION] TRIGGER / [POSTCONDITION]

Es handelt sind also um verschiedene Notationen für zwei
unterschiedliche Konzepte bzw. Transitionstypen.

Da alle Elemente der Notationen optional sind,
können sich im Protokollzustandsautomaten
Transitionsbeschriftungen wie

open/

sowie

[doorWay-\>isEmpty] Close/

aus Abbildung 15.12, S. 518 ergeben, bei denen der
abschliessende „/“ das voranstehende Wort eindeutig
als TRIGGER kennzeichnet und andeutet, dass die
POSTCONDITION ausgelassen wurde.

Gruß,
-Andreas.

#4

Da alle Elemente der Notationen optional sind,
können sich im Protokollzustandsautomaten
Transitionsbeschriftungen wie

open/

sowie

[doorWay->isEmpty] Close/

aus Abbildung 15.12, S. 518 ergeben, bei denen der
abschliessende „/“ das voranstehende Wort eindeutig
als TRIGGER kennzeichnet und andeutet, dass die
POSTCONDITION ausgelassen wurde.

Dankeschön, aber wäre es bei den Protokoll-Transitionen

open

und

[doorWay-\>isEmpty] Close

nicht auch eindeutig, dass open und close die Trigger sind?
Bedingungen für die Transition können sie nicht sein, da ihnen die [] fehlen.

Steht das auch irgendwo in der UML Superstructure 2, dass es der Zweck des „/“ ist, den Trigger eindeutig als solchen zu kennzeichen, oder ist das nur deine Interpretation?

Grüße,
Dirk

#5

Hallo Dirk.

wäre es bei den Protokoll-Transitionen

open

und

[doorWay->isEmpty] Close

nicht auch eindeutig, dass open und close die Trigger sind?

Nicht, wenn Du nur die Transition siehst und nicht darauf
achtest, ob es sich um einen alleinstehenden TRIGGER in einer
Verhaltens- oder eine Protokolltransition handelt:

Verhaltenstransition: TRIGGER
Protokolltransition: TRIGGER/

Steht das auch irgendwo in der UML Superstructure 2, dass es
der Zweck des „/“ ist, den Trigger eindeutig als solchen zu
kennzeichen, oder ist das nur deine Interpretation?

Für die Verhaltenstransition ist eine BNF angegeben,
für die Protokolltransition leider nicht. Deshalb
interpretiere ich das zugehörige Beispiel aus Abb. 15.12
als verbindlich, das konsequent die „TRIGGER/“-Notation
verwendet.

In der Praxis wird das Ganze nicht einheitlich gehandhabt:

  • in UML 2 glasklar, S. 389, Abb. 14.88 wird der „/“
    nach dem TRIGGER weggelassen (ISBN 3446229523 Buch anschauen)

  • in UML 2.0 kurz&gut, S. 109, Abb. 116 wird der „/“
    ebenfalls weggelassen. Dafür werden auch die Klammern
    der Nachbedingung ausgelassen, was eindeutig falsch
    ist, wenn man die Spec liest (ISBN 3897215217 Buch anschauen)

  • lediglich in UML 2 erfolgreich einsetzen wird
    konsequent die Standardnotation „TRIGGER/“ verwendet,
    siehe S. 209, Abb. 11.18 (ISBN 3827322685 Buch anschauen)

Letztlich kannst Du Dir also eine Variante raussuchen.

Wieso willst Du das so genau wissen, bewirbst Du Dich
irgendwo als UML-Experte oder schreibst Du ein UML-Tool?

Fragende Grüße,
-Andreas.

#6

Steht das auch irgendwo in der UML Superstructure 2, dass es
der Zweck des „/“ ist, den Trigger eindeutig als solchen zu
kennzeichen, oder ist das nur deine Interpretation?

Für die Verhaltenstransition ist eine BNF angegeben,
für die Protokolltransition leider nicht. Deshalb
interpretiere ich das zugehörige Beispiel aus Abb. 15.12
als verbindlich, das konsequent die „TRIGGER/“-Notation
verwendet.

Soweit bin ich mittlerweile auch, aber trotzdem vielen dank!

In der Praxis wird das Ganze nicht einheitlich gehandhabt:
…
Letztlich kannst Du Dir also eine Variante raussuchen.

Das es die Autoren dieser Bücher auch nicht genau wissen heisst noch lange nichts…

Wieso willst Du das so genau wissen, bewirbst Du Dich
irgendwo als UML-Experte oder schreibst Du ein UML-Tool?

Nein, ich schreibe gerade selbst über die Geschichte der Protokollzustandsautomaten (Automatentheorie, Harel, Hatley/Pirbhai, Selic, Booch, etc).

Werde demnächst nochmal Bran Selic kontaktieren. Vielleicht kann der mir weiterhelfen…

Dirk

#7

Hallo Dirk.

Werde demnächst nochmal Bran Selic kontaktieren. Vielleicht
kann der mir weiterhelfen…

Du kannst mir ja dann Bescheid geben, wenn Du was Verbindliches
herausgefunden hast und ob meine „TRIGGER/“-Theorie stimmt.

Viel Erfolg,
-Andreas.