Bereits im Beitrag „Die Tücken der Implizität“ meiner Kollegin Anja Ranft wurde über eine kleine aber nicht zu verachtende Stolperfalle bei der Modellierung mit der UML 2 berichtet. Da möchte ich mich nun anschließen und eine kleine Tücke aus dem Zustandsautomaten vorstellen.
Jeder Zustandsautomat beginnt für gewöhnlich mit einem Startzustand und einer Transition zu einem „richtigen“ Zustand.

So weit so gut.

Sehr oft wird an die Transition ein Trigger modelliert. Dabei handelt es sich meist um einen initialen Trigger – ein initiales Ereignis – welches das Verhalten des Zustandsautomaten startet. Die Frage, ob das vernünftig ist, stellen wir erstmal zurück. Die UML hat nämlich in der Version 2.1 zu diesem Thema eine klare Aussage getroffen. Dort wird nun gesagt, dass an der Transition, die vom Startzustand ausgeht, kein Trigger modelliert werden darf.

Abgesehen von dieser Festlegung muss man sich auch einen anderen Gedanken dabei machen. Um auf den Trigger reagieren zu können, muss das System sich in einem Zustand befinden. Dieser Zustand versteckt sich hinter dem schwarzen Punkt. Es gibt aber keine Möglichkeit, diesen Zustand weiter zu spezifizieren –  welche Regeln gelten in diesem Zustand? Führt das System Aktivitäten aus,etc… So besteht die große Gefahr, dass sich hinter dem Startzustand ein „richtiger“ Zustand des Systems verbirgt, der aber in der gesamten Systemmodellierung lediglich durch einen schwarzen Punkt gekennzeichnet ist. Gerade wegen dieser Gefahr ist es sehr zu empfehlen, auch bei der Modellierung mit älteren UML-Versionen an die Starttransition keinen Trigger zu modellieren, sondern stattdessen einen „richtigen“ Zustand zusätzlich in das Modell einzubauen. Der Startzustand mit der Transition sollte lediglich als Wegweiser dienen, um den Leser zu zeigen, wo der Zustandsautomat beginnt.

Weiterhin viel Erfolg beim Modellieren

Euer

Carsten Pflug