Last modified 3 years ago
Review textuelle Syntax für Statecharts
rvh: hat während KLausuraufsicht mit verschiedenen Syntaxen herumgespielt
- Grundsätze:
- allow anonymous states (States without names)
- make common case compact
- allow structuring (separate/external components)
Allgemeine Ideen
- Ideen:
- {} um hierarchisch zu schachteln
- Transitionen: WaitA -(A)-> final;
- state modifier: zustand -(translabel)-> zustand;
- alternativen:
- zustandsname
- state zustandsname vs init zustandsname
- init state zustandsname
- Initial Pseudostate ist eher init Modifier als echte Transition
- Nachteil von Transitionslabeln in Pfeilen: unübersichtlich bei langen Labeln
AB-(laaaaaanges Label superlanges Label )->final;
- Quellzustände nur einmal assoziieren: zu unübersichtlich, Quellzustand ausfindig zu machen
- Mischen von Modifiern an verschiedenen Stellen zu gleichem Zustand problematisch. Syntaxchecker sollte das überprüfen und warnen
- schm: Sinnvoll feste Ordnungen zwischen Transitionen und States festzulegen? Unklar, möglicherweise nur als Konvention.
- Transitionsarten: über labels: z.B. A-(strong: I/O)->B
- Symbole: final state (()) oder ()statename, Strong abort: o-(R)-
- Claus: schöner mit expliziten Schlüsselwörtern als modifier
Beschlüsse
- Strukturierung
- einfacher Mechanismus (textuelle Ersetzung)
- Umbenennung nochmal extra
- {} für Verschachtelungen UND beliebigem Inhalt (wie im SyncChart?-MetaModell?)
- Transitionen besser nicht darin enthalten (Analogie zum grafischen Editor)
- Inhalt z.T. ausserhalb definiert wie z.B. Modifier
- Dann evtl auch Label ausserhalb "label" optional, sonst ist der Identifyer (Name) das Label
- ID optional, aber trotzdem eindeutig! d.h. "keine Id ist auch EINE EINDEUTIGE ID", andernfalls ID mit leerem Label
- Schlüsselwörter bei Uneindeutigkeit (z.B. einmal als final, einmal als init)
- dann visuelle Warnung!!!
- nicht überschreibbar (erste Deklaration bleibt gültig)
- Keine verschiedenen Klammern
- Transitionen
- Transitionen als symbolische Abkürzungen für weak, strong, join
- Symbole zusammenhängend als "Bild"
- kein Modifier wie strong, join danach
- with-Modifier + Label + erstmal ohne Semikolon (s.u.)
- keine Schlüsselwörter für die symbolischen Abkürzungen
- Quellzustände immer implizit als zuletzt deklarierter/genannter Zustand (wenn kein optionaler Quellzustand)
- Aber nochmalige Referzierbarkeit des Quellzustands
- Immer nur EIN Quellzustand, hier A: A --> B --> C
- Variablen
- an Esterel V5 angelehnt, nach Möglichkeit "nichts neues ausdenken"
- input, output, local, var, inputoutput
- Priorities
- Reihenfolge durch textuelle Reihenfolge (analog zu XML)
- Whitespace
- Sollte KEINE Rolle spielen
- Semikolon
- Als Separator oder Terminator
- Aber möglichst nur bei Uneindeutigkeit
- Actions
- keine extra modifiyer (entry, exit, inside)
- besser nur ein zusammenhängendes schlüsselwort
- onenry I/O
- oninner I/O
- onexit I/O
- suspend I/
- Delay gehört zur Action
- nicht zur Transition
- nachträgliche semantische Überprüfung (oAW Check)
- kein extra Schlüsselwort
- Regions mit Namen (?)
- Parallelität
- Symbol wie in KIT
- Eindeutige IDs pro State (nicht global eindeutige) (?)
- Pfad-Notation mit Punkt (.)
- In parallelen Regions, Namen eindeutig (?)
Examples
See the attachement Syntax.pdf in the minutes of this meeting for the examples below:
- fullstate
state Statechart { init state fullstate{ INTEGER localvariable onentry "blabla" oninner "blup" onexit "bla" } }
- fulltransition
state SC { init state strt >-> end with 1 myTrigger/myEffects }
- thread
state Thread { init state disabled --> enabled with forked state enabled { state active{ onentry "effect" init state preempted "stateLabel" o-> running with iclockAndSchedule running --> preempted with iclockAndNotSchedule } || init state inactive --> final state semiEnd } >-> disabled with joined }
- decos_monitor (See /<KIEL_DIR>/Examples/KIT/haf/decos_monitor)
state SCU_Monitor { init state power_off o-> operational with notRESET state operational{ init state active{ init state hold_mode{ init state init_hold o-> activehold with FAIL_BRAKE o-> brake with MS100 state brake{ init state brake_monitor o-> fail_act_brake with preFAIL_ACTUATORandEXCEED o-> final state acthold with EXCEED_AorEXCEED_B state fail_act_brake{ onentry "EMERGENCE" } } //brake brake >-> activehold state activehold{ init state wait4motors o-> unspecified_failure with MS500 o-> activehold_monitor with notEXCEED state activehold_monitor o-> cond2 with EXCEED pseudo state cond2 --> motor_fault_b with EXCEED_BandpreEXCEED_A --> motor_fault_a with EXCEED_AandpreEXCEED_B --> cs_breakage state cs_breakage{ onentry "EMERGENCE" } state motor_fault_b{ onentry "EMERGENCE" } state motor_fault_a{ onentry "EMERGENCE" } state unspecified_failure{ onentry "EMERGENCE" } } //activehold }//hold_mode o-> drive_hold with DRIVE drive_mode //{ Inhalt von drive_mode } o-> hold_mode with HOLD }//active --> emergency with EMERGENCY }//operational o-> power_off with RESET }//SCU_Monitor
- Von rvh leicht überarbeitet:
// DECOS Monitor example in experimental textual SyncChart syntax // =========================================== state SCU_Monitor { init state power_off o-> operational with notRESET extern state operational o-> power_off with RESET } // =========================================== state operational { extern init state active --> emergency with EMERGENCY } // =========================================== state active { extern init state hold_mode o-> drive_mode with DRIVE extern state drive_mode o-> hold_mode with HOLD } // =========================================== state hold_mode { // ----------------------------- init state init_hold o-> activehold with FAIL_BRAKE o-> brake with MS100 // ----------------------------- state brake { init state brake_monitor o-> fail_act_brake with preFAIL_ACTUATORandEXCEED o-> final state acthold with EXCEED_AorEXCEED_B state fail_act_brake { onentry EMERGENCY } } // brake >-> activehold // ----------------------------- state activehold { init state wait4motors o-> unspecified_failure with MS500 o-> activehold_monitor with notEXCEED state activehold_monitor o-> cond2 with EXCEED cond state cond2 --> motor_fault_b with EXCEED_BandpreEXCEED_A --> motor_fault_a with EXCEED_AandpreEXCEED_B --> cs_breakage state cs_breakage { onentry EMERGENCY } state motor_fault_b { onentry EMERGENCY } state motor_fault_a { onentry EMERGENCY } state unspecified_failure { onentry EMERGENCY } } // activehold }