Revision history for ZustandsAutomaten


Revision [22968]

Last edited on 2016-02-21 05:15:37 by ToBo
Additions:
~-[[Schaltwerke]]


Revision [22601]

Edited on 2015-12-01 11:57:04 by ToBo
Additions:
~-[[https://www.johner-institut.de/blog/iec-62304-medizinische-software/zustandsautomat/ Unterscheidung zwischen Zustandsautomat für die Implementierung von Software und die Beschreibung von Anforderungen als Zustandsautomat]], Instituts-Journal: Ausgabe 06/15, Prof. Dr. Johner


Revision [13493]

Edited on 2012-04-15 20:30:59 by ToBo
Additions:
Wenn wir von Zustandsautomaten reden, meinen wir meist [[EndlicherAutomat endliche Zustandsautomaten (engl. finite state machines)]]. Ursprünglich hat man diese aus Logik-Gattern gebaut, heute werden endliche Zustandsautomaten in Software implementiert. Nach wie vor sind Zustandsautomaten ein effizientes und mächtiges Mittel bei der Lösung von technischen Problemen. Sie sind beinahe in jedem Gerät bei dem es um die Bewältigung mehrerer Aufgaben und gute [[Fehlertoleranz]] geht, angefangen von der Waschmaschine, über die Aufzugssteuerung, die Kaffee-Maschine, bis hin zum Handy in Software oder Hardware umgesetzt.
Deletions:
Wenn wir von Zustandsautomaten reden, meinen wir meist [[EndlicherAutomat endliche Zustandsautomaten (engl. finite state machines)]]. Ursprünglich hat man diese aus Logik-Gattern gebaut, heute werden endliche Zustandsautomaten in Software implementiert. Nach wie vor sind Zustandsautomaten ein effizientes und mächtiges Mittel bei der Lösung von technischen Problemen. Sie sind beinahe in jedem Gerät bei dem es um die Bewältigung mehrerer Aufgaben und gute Fehlertoleranz geht, angefangen von der Waschmaschine, über die Aufzugssteuerung, die Kaffee-Maschine, bis hin zum Handy in Software oder Hardware umgesetzt.


Revision [13280]

Edited on 2012-03-18 01:42:46 by ToBo
Additions:
In der **Elektrotechnik** werden endliche Zustandsautomaten (in dem Zusammenhang auch Schaltwerke genannt) durch das Zusammenschalten von Logik-Gatter entworfen (vgl. TietzeSchenk2002, S. 699). Noch vor der Zeit der Prozessoren gab es schon [[DetEndlAutomaten deterministischen, endlichen Automaten]]. Es gibt sie noch heute, allerdings werden diese mit einer Hardware-Beschreibungssprache wie z.B. [[Vhdl VHDL]] umgesetzt (SkriptSehrVhdl, S. 99). Diese Hardware-Zustandsautomaten bestehen aus einem Schaltwerk aus Logikgattern (siehe nächste Abbildung) in die die Eingaben hineingehen und die Ausgänge zur der Außenwelt hinausgehen (HorowitzHill1996, Teil II, ab S. 84). Wie jeder Automat, so hat auch dieser einen Speicher für die Zustandsvariablen - ein Register. Dieses Register ist meist ein D-Flip-Flop, wie z.B. der Baustein 74HC573, ein 8-fach-D-Flip-Flop. Ich gehe hier darauf ein, denn es ist zwar nicht unbedingt notwendig aber sehr nützlich, zu verstehen, wie diese Hardware-Zustandsautomaten funktionieren, um einen gegenüber Störungen robusten, fehlertoleranten, ggf. an harte Echtzeitbedingungen geknüpften virtuellen Zustandsautomaten in Software implementieren zu können.
Deletions:
In der **Elektrotechnik** werden endliche Zustandsautomaten (in dem Zusammenhang auch Schaltwerke genannt) durch das Zusammenschalten von Logik-Gatter entworfen (vgl. TietzeSchenk2002, S. 699). Noch vor der Zeit der Prozessoren gab es schon [[DetEndlAutomaten deterministischen, endlichen Automaten]]. Es gibt sie noch heute, allerdings werden diese mit einer Hardware-Beschreibungssprache wie z.B. [[Vhdl VHDL]] umgesetzt. Siehe dazu Modellierung von FSMs in [[VHDL]] in HorowitzHill1996, Teil II, ab S. 84 oder SkriptSehrVhdl, S. 99. Diese Hardware-Zustandsautomaten bestehen aus einem Schaltwerk aus Logikgattern (siehe nächste Abbildung) in die die Eingaben hineingehen und die Ausgänge zur der Außenwelt hinausgehen. Wie jeder Automat, so hat auch dieser einen Speicher für die Zustandsvariablen - ein Register. Dieses Register ist meist ein D-Flip-Flop, wie z.B. der Baustein 74HC573, ein 8-fach-D-Flip-Flop. Ich gehe hier darauf ein, denn es ist zwar nicht unbedingt notwendig aber sehr nützlich, zu verstehen, wie diese Hardware-Zustandsautomaten funktionieren, um einen gegenüber Störungen robusten, fehlertoleranten, ggf. an harte Echtzeitbedingungen geknüpften virtuellen Zustandsautomaten in Software implementieren zu können.


Revision [13276]

Edited on 2012-03-18 01:07:28 by ToBo
Additions:
In der **Informatik** gibt es neben den endlichen Automaten auch Sonderformen wie Turingmaschinen, Kellerautomaten, nichtdeterministische Automaten etc., die leider meist sehr theoretisch und formal behandelt werden. Hier wird der Student mit Puming-Lemma und Co. bis zum Exzess beglückt. In der Praxis setzt der Informatiker oder Programmierer dann doch fast ausschließlich die [[DetEndlAutomaten deterministischen, endlichen Automaten]] und bestenfalls Kellerautomaten ein. Sollen Automaten in einer Programmiersprache implementiert werden, so werden sie als //virtuelle Automaten// umgesetzt, die nicht direkt auf der Hardware laufen, sondern als Programm auf der Hardware. Der Automat wird also simuliert. Diese virtuellen Automaten unterscheiden sich bei genauer Betrachtung insbesondere in den Echtzeit-Kriterien von den mit Logik-Gattern umgesetzten Automaten. In Anschluss ist nunmehr über __virtuelle__, [[EndlicherAutomat endliche Zustandsautomaten]] die rede (Zustandsautomaten in Software).
Deletions:
In der **Informatik** gibt es neben den endlichen Automaten auch Sonderformen wie Turingmaschinen, Kellerautomaten, nichtdeterministische Automaten etc., die leider meist sehr theoretisch und formal behandelt werden. Hier wird der Student mit Puming-Lemma und Co. bis zum Exzess beglückt. In der Praxis setzt der Informatiker oder Programmierer dann doch fast ausschließlich die [[DetEndlAutomaten deterministischen, endlichen Automaten]] und Kellerautomaten ein. Sollen Automaten in einer Programmiersprache implementiert werden, so werden sie als //virtuelle Automaten// umgesetzt, die nicht direkt auf der Hardware laufen, sondern als Programm auf der Hardware. Der Automat wird also simuliert. Diese virtuellen Automaten unterscheiden sich deshalb bei genauer Betrachtung insbesondere in den Echtzeit-Kriterien von den mit Logik-Gattern umgesetzten Automaten. In Anschluss ist nunmehr über __virtuelle__, [[EndlicherAutomat endliche Zustandsautomaten]] die rede (Zustandsautomaten in Software).


Revision [13275]

Edited on 2012-03-18 01:04:44 by ToBo
Additions:
In der **Elektrotechnik** werden endliche Zustandsautomaten (in dem Zusammenhang auch Schaltwerke genannt) durch das Zusammenschalten von Logik-Gatter entworfen (vgl. TietzeSchenk2002, S. 699). Noch vor der Zeit der Prozessoren gab es schon [[DetEndlAutomaten deterministischen, endlichen Automaten]]. Es gibt sie noch heute, allerdings werden diese mit einer Hardware-Beschreibungssprache wie z.B. [[Vhdl VHDL]] umgesetzt. Siehe dazu Modellierung von FSMs in [[VHDL]] in HorowitzHill1996, Teil II, ab S. 84 oder SkriptSehrVhdl, S. 99. Diese Hardware-Zustandsautomaten bestehen aus einem Schaltwerk aus Logikgattern (siehe nächste Abbildung) in die die Eingaben hineingehen und die Ausgänge zur der Außenwelt hinausgehen. Wie jeder Automat, so hat auch dieser einen Speicher für die Zustandsvariablen - ein Register. Dieses Register ist meist ein D-Flip-Flop, wie z.B. der Baustein 74HC573, ein 8-fach-D-Flip-Flop. Ich gehe hier darauf ein, denn es ist zwar nicht unbedingt notwendig aber sehr nützlich, zu verstehen, wie diese Hardware-Zustandsautomaten funktionieren, um einen gegenüber Störungen robusten, fehlertoleranten, ggf. an harte Echtzeitbedingungen geknüpften virtuellen Zustandsautomaten in Software implementieren zu können.
Deletions:
In der **Elektrotechnik** werden endliche Zustandsautomaten (in dem Zusammenhang auch Schaltwerke genannt) durch das Zusammenschalten von Logik-Gatter entworfen (vgl. TietzeSchenk2002, S. 699). Noch vor der Zeit der Prozessoren gab es schon [[DetEndlAutomaten deterministischen, endlichen Automaten]]. Es gibt sie noch heute, allerdings werden diese mit einer Hardware-Beschreibungssprache wie z.B. [[Vhdl VHDL]] umgesetzt. Siehe dazu Modellierung von FSMs in [[VHDL]] in HorowitzHill1996, Teil II, ab S. 84 oder SkriptSehrVhdl, S. 99. Diese Hardware-Zustandsautomaten bestehen aus einem Schaltwerk aus Logikgattern (siehe nächste Abbildung) in die die Eingaben hineingehen und die Ausgänge zur der Außenwelt hinausgehen. Wie jeder Automat, so hat auch dieser einen Speicher für die Zustandsvariablen - ein Register. Dieses Register ist meist ein D-Flip-Flop, wie z.B. der Baustein 74HC573, ein 8-fach-D-Flip-Flop. Ich gehe hier darauf ein, denn es ist nützlich, zwar nicht unbedingt notwendig aber sehr nützlich zu begreifen, wie diese Hardware-Zustandsautomaten funktionieren, um einen gegenüber Störungen robusten, fehlertoleranten virtuellen Automaten in Software implementieren zu können.


Revision [13274]

Edited on 2012-03-18 01:01:55 by ToBo
Additions:
In der Informatik und der Elektrotechnik ist das Prinzip des Automatenentwurfs ähnlich, die Umsetzung jedoch komplett verschieden.
Deletions:
In der Informatik und der Elektrotechnik werden unterschiedliche Schwerpunkte verfolgt.


Revision [13273]

Edited on 2012-03-18 00:56:17 by ToBo
Additions:
Endliche Zustandsautomaten haben eine endliche Anzahl an Zuständen. Sie wechseln in einen anderen Zustand beim Eintreffen eines **Ereignisses** (engl. Event). In welchen Zustand gewechselt wird, hängt von dem Ereignis und dem aktuellen Zustand ab.
Deletions:
Endliche Zustandsautomaten haben eine endliche Anzahl an Zuständen. Sie wechseln in einen anderen Zustand beim Eintreffen eines **Ereignisses** (engl. Event). In welchen Zustand gewechselt hängt von den Ereignis und dem aktuellen Zustand ab.


Revision [13272]

Edited on 2012-03-18 00:53:03 by ToBo
Additions:
Wenn wir von Zustandsautomaten reden, meinen wir meist [[EndlicherAutomat endliche Zustandsautomaten (engl. finite state machines)]]. Ursprünglich hat man diese aus Logik-Gattern gebaut, heute werden endliche Zustandsautomaten in Software implementiert. Nach wie vor sind Zustandsautomaten ein effizientes und mächtiges Mittel bei der Lösung von technischen Problemen. Sie sind beinahe in jedem Gerät bei dem es um die Bewältigung mehrerer Aufgaben und gute Fehlertoleranz geht, angefangen von der Waschmaschine, über die Aufzugssteuerung, die Kaffee-Maschine, bis hin zum Handy in Software oder Hardware umgesetzt.
Deletions:
Wenn wir von Zustandsautomaten reden, meinen wir meist [[EndlicherAuto endliche Zustandsautomaten (engl. finite state machines)]]. Ursprünglich hat man diese aus Logik-Gattern gebaut, heute werden endliche Zustandsautomaten in Software implementiert. Nach wie vor sind Zustandsautomaten ein effizientes und mächtiges Mittel bei der Lösung von technischen Problemen. Sie sind beinahe in jedem Gerät bei dem es um die Bewältigung mehrerer Aufgaben und gute Fehlertoleranz geht, angefangen von der Waschmaschine, über die Aufzugssteuerung, die Kaffee-Maschine, bis hin zum Handy in Software oder Hardware umgesetzt.


Revision [13271]

Edited on 2012-03-18 00:52:41 by ToBo
Additions:
Wenn wir von Zustandsautomaten reden, meinen wir meist [[EndlicherAuto endliche Zustandsautomaten (engl. finite state machines)]]. Ursprünglich hat man diese aus Logik-Gattern gebaut, heute werden endliche Zustandsautomaten in Software implementiert. Nach wie vor sind Zustandsautomaten ein effizientes und mächtiges Mittel bei der Lösung von technischen Problemen. Sie sind beinahe in jedem Gerät bei dem es um die Bewältigung mehrerer Aufgaben und gute Fehlertoleranz geht, angefangen von der Waschmaschine, über die Aufzugssteuerung, die Kaffee-Maschine, bis hin zum Handy in Software oder Hardware umgesetzt.
Man kann zwischen einem Mealy-Automaten, einem Moore-Automat und der Kombination aus beiden, den Harel-Automaten, unterscheiden. Die Unterschiede lassen sich sehr gut mit [[ZustandsDiagramm Zustandsdiagrammen]] erläutern. [[ZustandsDiagramm Zustandsdiagramme]] sind eine grafische Darstellung von Zustandsautomaten.
Deletions:
Wenn wir von Zustandsautomaten reden, meinen wir endliche Zustandsautomaten. [[ZustandsDiagramm Zustandsdiagramme]] sind eine grafische Darstellung von Zustandsautomaten.
Man kann zwischen einem Mealy-Automaten, einem Moore-Automat und der Kombination aus beiden, den Harel-Automaten, unterscheiden.


Revision [13270]

Edited on 2012-03-18 00:43:21 by ToBo
Additions:
In der **Elektrotechnik** werden endliche Zustandsautomaten (in dem Zusammenhang auch Schaltwerke genannt) durch das Zusammenschalten von Logik-Gatter entworfen (vgl. TietzeSchenk2002, S. 699). Noch vor der Zeit der Prozessoren gab es schon [[DetEndlAutomaten deterministischen, endlichen Automaten]]. Es gibt sie noch heute, allerdings werden diese mit einer Hardware-Beschreibungssprache wie z.B. [[Vhdl VHDL]] umgesetzt. Siehe dazu Modellierung von FSMs in [[VHDL]] in HorowitzHill1996, Teil II, ab S. 84 oder SkriptSehrVhdl, S. 99. Diese Hardware-Zustandsautomaten bestehen aus einem Schaltwerk aus Logikgattern (siehe nächste Abbildung) in die die Eingaben hineingehen und die Ausgänge zur der Außenwelt hinausgehen. Wie jeder Automat, so hat auch dieser einen Speicher für die Zustandsvariablen - ein Register. Dieses Register ist meist ein D-Flip-Flop, wie z.B. der Baustein 74HC573, ein 8-fach-D-Flip-Flop. Ich gehe hier darauf ein, denn es ist nützlich, zwar nicht unbedingt notwendig aber sehr nützlich zu begreifen, wie diese Hardware-Zustandsautomaten funktionieren, um einen gegenüber Störungen robusten, fehlertoleranten virtuellen Automaten in Software implementieren zu können.
Deletions:
In der **Elektrotechnik** werden endliche Zustandsautomaten (in dem Zusammenhang auch Schaltwerke genannt) durch das Zusammenschalten von Logik-Gatter entworfen (vgl. TietzeSchenk2002, S. 699). Noch vor der Zeit der Prozessoren gab es schon [[DetEndlAutomaten deterministischen, endlichen Automaten]]. Es gibt sie noch heute, allerdings werden diese mit einer Hardware-Beschreibungssprache wie z.B. [[Vhdl VHDL]] umgesetzt. Siehe dazu Modellierung von FSMs in [[VHDL]] in HorowitzHill1996, Teil II, ab S. 84 oder SkriptSehrVhdl, S. 99. Diese Hardware-Zustandsautomaten bestehen aus einem Schaltwerk aus Logikgattern (siehe nächste Abbildung) in die die Eingaben hineingehen und die Ausgänge zur der Außenwelt hinausgehen. Wie jeder Automat, so hat auch dieser einen Speicher für die Zustandsvariablen - ein Register. Dieses Register ist meist ein D-Flip-Flop, wie z.B. der Baustein 74HC573, ein 8-fach-D-Flip-Flop. Es ist nützlich zu begreifen, wie diese Zustandsautomaten funktionieren, um einen gegenüber Störungen robusten virtuellen Automaten in Software implementieren zu können.


Revision [13269]

Edited on 2012-03-18 00:40:43 by ToBo
Additions:
==a==State-Event-Matrix==a==
Die Übergangstabelle (engl. State Event Matrix) bietet eine lückenlose Definition von Übergängen von jedem möglichen Zustand in alle anderen möglichen Zustände in Abhängigkeit von den möglichen Ereignissen. Die Übergangstabelle ist ein effektives Mittel um alle Fälle eines Zustandsautomaten zu erfassen. Bei sicherheitskritischen Anwendungen ein unentbehrliches Muss, auch wenn die Anzahl der Zustände und Ereignisse überschaubar ist!
Beispiel zu State-Event-Matrix in Wiegelmann2004, S. 158, allerdings ist der Zustandsautomat dort leider etwas ineffizient mit SWITCH- und CASE-Anweisungen implementiert. Diese haben den Nachteil mit steigender Anzahl von Ereignissen eine zunehmende Laufzeitabhängigkeit aufzuweisen. Siehe dazu die Implementierung mit [[FunctionPointerStateMachine in C mit Function-Pointern]], die ich im Rahmen einer Studienarbeit bei Prof. Dr. Robra erstellen musste. Tolle Sache!
Werden nur bei virtuellen, endlichen Zustandsautomaten benötigt. Eine Zustandstabelle definiert, unter welchen Bedingungen von dem aktuellen Zustand in einen anderen gewechselt wird und was bei Eintritt in den betrachteten Zustand und beim Verlassen dieses Zustandes ausgeführt wird.
Deletions:
Werden nur bei virtuellen, endlichen Zustandsautomaten benötigt. Eine Zustandstabelle definiert, unter welchen Bedingungen von dem aktuellen Zustand in einen anderen Führen und was bei Eintritt in den betrachteten Zustand oder beim Verlassen dieses Zustandes ausgeführt wird.
==a==State Event Matrix==a==
Die Übergangstabelle (engl. State Event Matrix) bietet eine lückenlose Definition von Übergängen von jedem möglichen Zustand in alle anderen möglichen Zustände in Abhängigkeit von den möglichen Ereignissen. Die Übergangstabelle ist ein effektives Mittel um alle Fälle eines Zustandsautomaten zu erfassen. Bei sicherheitskritischen Anwendungen ein unentbehrliches Muss!
Beispiel in Wiegelmann2004, S. 158, allerdings ist der Zustandsautomat dort leider etwas ineffizient mit SWITCH- und CASE-Anweisungen implementiert. Diese haben den Nachteil mit steigender Anzahl von Ereignissen eine zunehmende Laufzeitabhängigkeit aufzuweisen. Siehe dazu die Implementierung mit [[FunctionPointerStateMachine in C mit Function-Pointern]], die ich im Rahmen einer Studienarbeit bei Prof. Dr. Robra erstellen musste.


Revision [13268]

Edited on 2012-03-18 00:31:47 by ToBo
Additions:
In der **Elektrotechnik** werden endliche Zustandsautomaten (in dem Zusammenhang auch Schaltwerke genannt) durch das Zusammenschalten von Logik-Gatter entworfen (vgl. TietzeSchenk2002, S. 699). Noch vor der Zeit der Prozessoren gab es schon [[DetEndlAutomaten deterministischen, endlichen Automaten]]. Es gibt sie noch heute, allerdings werden diese mit einer Hardware-Beschreibungssprache wie z.B. [[Vhdl VHDL]] umgesetzt. Siehe dazu Modellierung von FSMs in [[VHDL]] in HorowitzHill1996, Teil II, ab S. 84 oder SkriptSehrVhdl, S. 99. Diese Hardware-Zustandsautomaten bestehen aus einem Schaltwerk aus Logikgattern (siehe nächste Abbildung) in die die Eingaben hineingehen und die Ausgänge zur der Außenwelt hinausgehen. Wie jeder Automat, so hat auch dieser einen Speicher für die Zustandsvariablen - ein Register. Dieses Register ist meist ein D-Flip-Flop, wie z.B. der Baustein 74HC573, ein 8-fach-D-Flip-Flop. Es ist nützlich zu begreifen, wie diese Zustandsautomaten funktionieren, um einen gegenüber Störungen robusten virtuellen Automaten in Software implementieren zu können.
{{image url="images/ZustandsautomatLogik.png"}}
In der **Informatik** gibt es neben den endlichen Automaten auch Sonderformen wie Turingmaschinen, Kellerautomaten, nichtdeterministische Automaten etc., die leider meist sehr theoretisch und formal behandelt werden. Hier wird der Student mit Puming-Lemma und Co. bis zum Exzess beglückt. In der Praxis setzt der Informatiker oder Programmierer dann doch fast ausschließlich die [[DetEndlAutomaten deterministischen, endlichen Automaten]] und Kellerautomaten ein. Sollen Automaten in einer Programmiersprache implementiert werden, so werden sie als //virtuelle Automaten// umgesetzt, die nicht direkt auf der Hardware laufen, sondern als Programm auf der Hardware. Der Automat wird also simuliert. Diese virtuellen Automaten unterscheiden sich deshalb bei genauer Betrachtung insbesondere in den Echtzeit-Kriterien von den mit Logik-Gattern umgesetzten Automaten. In Anschluss ist nunmehr über __virtuelle__, [[EndlicherAutomat endliche Zustandsautomaten]] die rede (Zustandsautomaten in Software).
Seit dem Einzug der Computer und Mikrocontroller in der Steuerungstechnik sind nun auch __virtuelle__, [[EndlicherAutomat endliche Zustandsautomaten]] möglich (engl. Virtual Finite State Machines, VFSM). Bei der Umsetzung dieser Art von Zustandsautomaten müssen jedoch einige Randbedingungen im Gegensatz zu realen Zustandsautomaten beachtet werden. Wie die Väter der Zustandsautomaten in Hardware, so benötigt auch der VFSM einen Takt. Ohne einen regelmäßigen Takt sind die Zustandswechsel eines Zustandsautomaten, egal ob Hardware oder Software nicht vorhersehbar. Hier empfiehlt es sich bei harten Echtzeit-Anforderungen einen Timer auf einem Mikrocontroller zu verwenden. Existieren keine Echtzeitbedingungen, dann ist selbstverständlich ein variabler Takt, der von der Auslastung anderer Systemprozesse z.B. unter Windows oder Linux auf einem PC abhängig sein könnte zulässig.
Werden nur bei virtuellen, endlichen Zustandsautomaten benötigt. Eine Zustandstabelle definiert, unter welchen Bedingungen von dem aktuellen Zustand in einen anderen Führen und was bei Eintritt in den betrachteten Zustand oder beim Verlassen dieses Zustandes ausgeführt wird.
Die Übergangstabelle (engl. State Event Matrix) bietet eine lückenlose Definition von Übergängen von jedem möglichen Zustand in alle anderen möglichen Zustände in Abhängigkeit von den möglichen Ereignissen. Die Übergangstabelle ist ein effektives Mittel um alle Fälle eines Zustandsautomaten zu erfassen. Bei sicherheitskritischen Anwendungen ein unentbehrliches Muss!
Beispiel in Wiegelmann2004, S. 158, allerdings ist der Zustandsautomat dort leider etwas ineffizient mit SWITCH- und CASE-Anweisungen implementiert. Diese haben den Nachteil mit steigender Anzahl von Ereignissen eine zunehmende Laufzeitabhängigkeit aufzuweisen. Siehe dazu die Implementierung mit [[FunctionPointerStateMachine in C mit Function-Pointern]], die ich im Rahmen einer Studienarbeit bei Prof. Dr. Robra erstellen musste.
Der Testplan ist eine Methode zum Test von Zustandsautomaten. Es gibt sie je nach Abwägung von Sicherheit und Aufwand in zwei Stufen.
Siehe dazu ScriptRobra2007
Deletions:
In der **Elektrotechnik** werden endliche Zustandsautomaten (in dem Zusammenhang auch Schaltwerke genannt) durch das Zusammenschalten von Logik-Gatter entworfen (vgl. TietzeSchenk2002, S. 699). Heute geschieht das häufiger mit einer Hardware-Beschreibungssprache wie z.B. [[Vhdl VHDL]]. Siehe dazu Modellierung von FSMs in VHDL (SkriptSehrVhdl, S. 99)
In der **Informatik** gibt es neben den endlichen Automaten auch Sonderformen wie Turingmaschinen, Kellerautomaten, nichtdeterministische Automaten etc., die leider meist sehr theoretisch und formal behandelt werden. Hier wird der Student mit Puming-Lemma und Co. behandelt, bis er den Glauben an die Umsetzung in der Praxis verliert. Findet der Informatiker später doch den Bezug zur Realität, so werden vor allem sehr oft die [[DetEndlAutomaten deterministischen, endlichen Automaten]] und Kellerautomaten verwendet. Sollen schließlich Automaten vom Informatiker implementiert werden, so werden sie als virtuelle Automaten umgesetzt, die nicht direkt auf der Hardware laufen, sondern als Programm auf der Hardware. Der Automat wird also simuliert. Diese virtuellen Automaten unterscheiden sich deshalb bei genauer Betrachtung von den mit Logik-Gattern umgesetzten Automaten.
Seit dem Einzug der Computer und Mikrocontroller in der Steuerungstechnik sind nun auch __virtuelle__, [[EndlicherAutomat endliche Zustandsautomaten]] möglich (engl. Virtual Finite State Machines, VFSM). Bei der Umsetzung dieser Art von Zustandsautomaten müssen jedoch einige Randbedingungen im Gegensatz zu realen Zustandsautomaten beachtet werden. Beispielsweise ist hier die Definition von Zustandstabellen empfehlenswert.
http://de.wikipedia.org/wiki/Virtueller_endlicher_Automat
http://www.stateworks.com/active/download/wagf92-software-engineering.pdf
Werden nur bei virtuellen, endlichen Zustandsautomaten benötigt. Eine Zustandstabelle definiert, unter welche Bedingungen von diesem Zustand in einen anderen Führen und was bei Eintritt in den betrachteten Zustand oder beim Verlassen dieses Zustandes ausgeführt wird.
Die Übergangstabelle (engl. State Event Matrix) bietet eine lückenlose Definition von Übergängen von jedem möglichen Zustand in alle anderen möglichen Zustände in Abhängigkeit von den möglichen Ereignissen. Die Übergangstabelle ist ein effektives Mittel um alle Fälle eines Zustandsautomaten zu erfassen.
Beispiel in Wiegelmann2004, S. 158, allerdings ist der Zustandsautomat dort leider etwas ineffizient mit SWITCH- und CASE-Anweisungen implementiert.
Siehe ScriptRobra2007
==a==Implementierung==a==
~-[[FunctionPointerStateMachine In C mit Function-Pointern]]


Revision [11299]

Edited on 2010-12-26 02:20:09 by ToBo
Additions:
==a==Implementierung==a==
~-[[FunctionPointerStateMachine In C mit Function-Pointern]]


Revision [10021]

Edited on 2009-08-22 00:45:45 by ToBo
Additions:
Wenn wir von Zustandsautomaten reden, meinen wir endliche Zustandsautomaten. [[ZustandsDiagramm Zustandsdiagramme]] sind eine grafische Darstellung von Zustandsautomaten.
Deletions:
Wenn wir von Zustandsautomaten reden, meinen wir endliche Zustandsautomaten.


Revision [10020]

Edited on 2009-08-22 00:44:03 by ToBo
Additions:
Wenn wir von Zustandsautomaten reden, meinen wir endliche Zustandsautomaten.
Endliche Zustandsautomaten haben eine endliche Anzahl an Zuständen. Sie wechseln in einen anderen Zustand beim Eintreffen eines **Ereignisses** (engl. Event). In welchen Zustand gewechselt hängt von den Ereignis und dem aktuellen Zustand ab.
In der **Elektrotechnik** werden endliche Zustandsautomaten (in dem Zusammenhang auch Schaltwerke genannt) durch das Zusammenschalten von Logik-Gatter entworfen (vgl. TietzeSchenk2002, S. 699). Heute geschieht das häufiger mit einer Hardware-Beschreibungssprache wie z.B. [[Vhdl VHDL]]. Siehe dazu Modellierung von FSMs in VHDL (SkriptSehrVhdl, S. 99)
Deletions:
In der **Elektrotechnik** werden endliche Zustandsautomaten (auch Schaltwerke) durch das Zusammenschalten von Logik-Gatter entworfen (vgl. TietzeSchenk2002, S. 699). Heute geschieht das häufiger mit einer Hardware-Beschreibungssprache wie z.B. [[Vhdl VHDL]]. Siehe dazu Modellierung von FSMs in VHDL (SkriptSehrVhdl, S. 99)


Revision [10019]

Edited on 2009-08-22 00:35:03 by ToBo
Additions:
Siehe ScriptRobra2007
Deletions:
Siehe SkcriptRobra2007


Revision [10018]

Edited on 2009-08-22 00:34:37 by ToBo
Additions:
Man kann zwischen einem Mealy-Automaten, einem Moore-Automat und der Kombination aus beiden, den Harel-Automaten, unterscheiden.
=a=Mealy-Automat=a=
Mealy-Automat führt Aktionen im Zustandsübergang aus.
{{image url="images/ATFS_AutomatMealy.png"}}
=a=Moore-Automat=a=
Moore-Automat führt Aktionen beim Betreten und Verlassen eines Zustands aus.
=a=Harel-Automat=a=
Harel-Automat sind Hybride aus Mealy- und Moore-Automaten, sie erlauben zudem bedingte Zustandsübergänge, Zustände mit Gedächtnis, nebenläufige Zustände. Siehe dazu Balzert2000, S. 323 und Zustandsautomaten der [[SoftwareUml2 UML2]].
Erweiterte, endliche Zustandsautomaten besitzen abgesehen von ihren Zuständen, als Erweiterung lokale Variablen, die das Verhalten beim Eintreffen von Ereignissen beeinflussen können, wie bei Zustandsautomaten der [[SoftwareUml2 UML2]] oder allgemein Harel-Automaten.
Werden nur bei virtuellen, endlichen Zustandsautomaten benötigt. Eine Zustandstabelle definiert, unter welche Bedingungen von diesem Zustand in einen anderen Führen und was bei Eintritt in den betrachteten Zustand oder beim Verlassen dieses Zustandes ausgeführt wird.
Beispiel in Wiegelmann2004, S. 158, allerdings ist der Zustandsautomat dort leider etwas ineffizient mit SWITCH- und CASE-Anweisungen implementiert.
Siehe SkcriptRobra2007
~-[[ZustandsDiagramm Zustandsdiagramme]]
Deletions:
~-Mealy-Automat führt Aktionen im Zustandsübergang aus.
~{{image url="images/ATFS_AutomatMealy.png"}}
~-Moore-Automat führt Aktionen beim Betreten und Verlassen eines Zustands aus.
~-Harel-Automat sind Hybride aus Mealy- und Moore-Automaten, sie erlauben zudem bedingte Zustandsübergänge, Zustände mit Gedächtnis, nebenläufige Zustände. Siehe dazu Balzert2000, S. 323 und Zustandsautomaten der [[SoftwareUml2 UML2]].
==a==Composite State und Submachine States==a==
Zustandsautomaten können mit zunehmender Anzahl der Zustände unübersichtlich werden. Um dies zu vermeiden können bereiche von Zustandsautomaten oder ganze Zustandsautomaten zu einem Zustand zusammengefasst werden. Die UML 2 bietet hier die Composite State und Submachine States. Es wird auch von Dekomposition von Zuständen (Born2004, S. 177) oder auch s.g. hierarchischen Zustandsautomaten (Balzert2000, S. 325) gesprochen. Es ist bis auf kleine Feinheiten immer dasselbe gemeint - das Zusammenfasen von Zuständen oder ganzer Zustandsautomaten zu einem Zustand.
Die [[SoftwareUml2 UML2]] bietet zwei Varianten von zusammengesetzten Zuständen.
~-Die orthogonale Dekomposition liefert Composite States, die aus s.g. Regionen, engl. regions (Born2004, S. 183) bestehen. Man spricht von Composite States wenn mindestens eine Region vorhanden ist. Die Regionen beinhalten Zustandsautomaten. Die Zustandsautomaten werden innerhalb einer Region vollständig dargestellt.
~-Submachine States sind Zustände, die __einen__ Zustandsautomaten beinhalten. Der Zustandsautomat wird in einem separaten Diagramm, also im Gegensatz zu Composite States nicht im inneren des oberliegenden Zustandes dargestellt.
//A **composite state** either contains one region or is decomposed into two or more orthogonal regions. Each region has a set of mutually exclusive disjoint subvertices and a set of transitions. A given state may only be decomposed in one of these two ways.// (OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, Page 549)
//A **submachine state** specifies the insertion of the specification of a submachine state machine. The state machine that contains the submachine state is called the containing state machine. The same state machine may be a submachine more than once in the context of a single containing state machine.// (OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, Page 549)
Erweiterte, endliche Zustandsautomaten besitzen abgesehen von ihren Zuständen, als erweiterung lokale Variablen, die das Verhalten beim Eintreffen von Ereignissen beeinflussen können, wie bei Zustandsautomaten der [[SoftwareUml2 UML2]] oder allgemein Harel-Automaten.
Werden nur bei virtuellen, endlichen Zustandsaustomaten benötigt. Eine Zustandstabelle definiert, unter welche Bedingungen von diesem Zustand in einen anderen Führen und was bei Eintritt in den betrachteten Zustand oder beim Verlassen dieses Zustandes ausgeführt wird.
Beispiel in Wiegelmann2004, S. 158, allerdings ist der Zustandsautomat dort mit SWITCH- und CASE-Anweisungen implementiert.


Revision [8705]

Edited on 2009-05-21 01:32:16 by ToBo
Additions:
In der **Elektrotechnik** werden endliche Zustandsautomaten (auch Schaltwerke) durch das Zusammenschalten von Logik-Gatter entworfen (vgl. TietzeSchenk2002, S. 699). Heute geschieht das häufiger mit einer Hardware-Beschreibungssprache wie z.B. [[Vhdl VHDL]]. Siehe dazu Modellierung von FSMs in VHDL (SkriptSehrVhdl, S. 99)
Deletions:
In der **Elektrotechnik** werden endliche Zustandsautomaten durch das Zusammenschalten von Logik-Gatter entwickelt - heute in der Regel mit einer Hardware-Beschreibungssprache wie z.B. [[Vhdl VHDL]]. Siehe dazu Modellierung von FSMs in VHDL (SkriptSehrVhdl, S. 99)


Revision [6686]

Edited on 2008-11-30 02:15:58 by ToBo
Additions:
In der Informatik und der Elektrotechnik werden unterschiedliche Schwerpunkte verfolgt.
In der **Elektrotechnik** werden endliche Zustandsautomaten durch das Zusammenschalten von Logik-Gatter entwickelt - heute in der Regel mit einer Hardware-Beschreibungssprache wie z.B. [[Vhdl VHDL]]. Siehe dazu Modellierung von FSMs in VHDL (SkriptSehrVhdl, S. 99)
In der **Informatik** gibt es neben den endlichen Automaten auch Sonderformen wie Turingmaschinen, Kellerautomaten, nichtdeterministische Automaten etc., die leider meist sehr theoretisch und formal behandelt werden. Hier wird der Student mit Puming-Lemma und Co. behandelt, bis er den Glauben an die Umsetzung in der Praxis verliert. Findet der Informatiker später doch den Bezug zur Realität, so werden vor allem sehr oft die [[DetEndlAutomaten deterministischen, endlichen Automaten]] und Kellerautomaten verwendet. Sollen schließlich Automaten vom Informatiker implementiert werden, so werden sie als virtuelle Automaten umgesetzt, die nicht direkt auf der Hardware laufen, sondern als Programm auf der Hardware. Der Automat wird also simuliert. Diese virtuellen Automaten unterscheiden sich deshalb bei genauer Betrachtung von den mit Logik-Gattern umgesetzten Automaten.
Deletions:
In der Informatik und der Elektrotechnik werden unterschiedliche Schwerpunkte verfolgt. In der **Elektrotechnik** werden endliche Zustandsautomaten durch das Zusammenschalten von Logik-Gatter entwickelt - heute in der Regel mit einer Hardware-Beschreibungssprache wie z.B. [[Vhdl VHDL]]. Siehe dazu Modellierung von FSMs in VHDL (SkriptSehrVhdl, S. 99)
In der **Informatik** gibt es neben den endlichen Automaten auch Sonderformen wie Turingmaschinen, Kellerautomaten, nichtdeterministische Automaten etc., die leider meist sehr theoretisch und formal behandelt werden. Hier wird der Student mit Puming-Lemma und Co. behandelt, bis er den Glauben an die Umsetzung in der Praxis verliert. Findet der Informatiker später doch den Bezug zur Realität, so werden vor allem sehr oft die [[DetEndlAutomaten deterministischen, endlichen Automaten]] und Kellerautomaten verwendet. In der Informatik werden die Automaten, falls sie jemals implementiert werden, in der Regel als virtuelle Automaten umgesetzt, die sich bei genauer Betrachtung von den mit Logik-Gattern umgesetzten Automaten unterscheiden.


Revision [6685]

Edited on 2008-11-30 02:11:23 by ToBo
Additions:
Einordnung [[EndlicherAutomat endlicher Zustandsautomaten]] (engl. Finite State Machines) in der theoretischen Informatik:
In der Informatik und der Elektrotechnik werden unterschiedliche Schwerpunkte verfolgt. In der **Elektrotechnik** werden endliche Zustandsautomaten durch das Zusammenschalten von Logik-Gatter entwickelt - heute in der Regel mit einer Hardware-Beschreibungssprache wie z.B. [[Vhdl VHDL]]. Siehe dazu Modellierung von FSMs in VHDL (SkriptSehrVhdl, S. 99)
In der **Informatik** gibt es neben den endlichen Automaten auch Sonderformen wie Turingmaschinen, Kellerautomaten, nichtdeterministische Automaten etc., die leider meist sehr theoretisch und formal behandelt werden. Hier wird der Student mit Puming-Lemma und Co. behandelt, bis er den Glauben an die Umsetzung in der Praxis verliert. Findet der Informatiker später doch den Bezug zur Realität, so werden vor allem sehr oft die [[DetEndlAutomaten deterministischen, endlichen Automaten]] und Kellerautomaten verwendet. In der Informatik werden die Automaten, falls sie jemals implementiert werden, in der Regel als virtuelle Automaten umgesetzt, die sich bei genauer Betrachtung von den mit Logik-Gattern umgesetzten Automaten unterscheiden.
Seit dem Einzug der Computer und Mikrocontroller in der Steuerungstechnik sind nun auch __virtuelle__, [[EndlicherAutomat endliche Zustandsautomaten]] möglich (engl. Virtual Finite State Machines, VFSM). Bei der Umsetzung dieser Art von Zustandsautomaten müssen jedoch einige Randbedingungen im Gegensatz zu realen Zustandsautomaten beachtet werden. Beispielsweise ist hier die Definition von Zustandstabellen empfehlenswert.
Deletions:
Einordnung endlicher Zustandsautomaten in der theoretischen Informatik:
[[EndlicherAutomat Endliche Zustandsautomaten]] (engl. Finite State Machines) werden in der Elektrotechnik mit der Zusammenschaltung von Logik-Gattern realisiert. Dies ist die ursprüngliche Form von Zustandsaustomaten.
Siehe dazu Modellierung von FSMs in VHDL (SkriptSehrVhdl, S. 99)
Seit dem Einzug der Computer und Mikrocontroller in der Steuerungstechnik sind nun auch __virtuelle__, [[EndlicherAutomat endliche Zustandsautomaten]] möglich (engl. Virtual Finite State Machines, VFSM). Bei der Umsetzung dieser Art von Zustandsautomaten müssen jedoch einige Randbedingungen beachtet werden. Beispielsweise ist hier die Definition von Zustandstabellen empfehlenswert.


Revision [6684]

Edited on 2008-11-30 01:47:40 by ToBo
Additions:
Einordnung endlicher Zustandsautomaten in der theoretischen Informatik:
Deletions:
Einordnung endlicher Zustandsautomaten in der theoretischen Informatik


Revision [6683]

Edited on 2008-11-30 01:47:14 by ToBo
Additions:
{{image url="images/15_automaten.dot.png"}}
Einordnung endlicher Zustandsautomaten in der theoretischen Informatik


Revision [6631]

Edited on 2008-11-28 03:31:49 by ToBo
Additions:
Siehe dazu Modellierung von FSMs in VHDL (SkriptSehrVhdl, S. 99)


Revision [6480]

Edited on 2008-11-16 16:39:06 by ToBo
Additions:
Beispiel in Wiegelmann2004, S. 158, allerdings ist der Zustandsautomat dort mit SWITCH- und CASE-Anweisungen implementiert.


Revision [5737]

Edited on 2008-10-25 11:19:12 by ToBo
Additions:
~~-Stufe 1: Zustandsabdeckung: Jeder Zustand wird mindestens einmal erreicht.
~~-Stufe 2: Abdeckung aller Zustandswechsel: Jeder Zustandsübergang wird mindestens einmal ausgeführt.
Deletions:
~~-Stufe 1: Zustandsabdeckung
~~Jeder Zustand wird mindestens einmal erreicht.
~~-Stufe 2: Abdeckung aller Zustandswechsel
~~Jeder Zustandsübergang wird mindestens einmal ausgeführt.


Revision [5736]

Edited on 2008-10-25 11:18:45 by ToBo
Additions:
~~Jeder Zustand wird mindestens einmal erreicht.
~~Jeder Zustandsübergang wird mindestens einmal ausgeführt.


Revision [5735]

Edited on 2008-10-25 11:09:21 by ToBo

No Differences

Revision [5734]

Edited on 2008-10-25 11:08:55 by ToBo
Additions:
~-Mealy-Automat führt Aktionen im Zustandsübergang aus.
~{{image url="images/ATFS_AutomatMoore.png"}}
~-Moore-Automat führt Aktionen beim Betreten und Verlassen eines Zustands aus.
~{{image url="images/ATFS_AutomatMealy.png"}}
Deletions:
~-Mealy-Automat führt Aktionen im Zustandsübergang aus. {{image url="images/ATFS_AutomatMoore.png"}}
~-Moore-Automat führt Aktionen beim Betreten und Verlassen eines Zustands aus. {{image url="images/ATFS_AutomatMealy.png"}}


Revision [5733]

Edited on 2008-10-25 11:08:13 by ToBo
Additions:
~-Mealy-Automat führt Aktionen im Zustandsübergang aus. {{image url="images/ATFS_AutomatMoore.png"}}
~-Moore-Automat führt Aktionen beim Betreten und Verlassen eines Zustands aus. {{image url="images/ATFS_AutomatMealy.png"}}
Deletions:
~-Mealy-Automat führt Aktionen im Zustandsübergang aus. {{image url="images/ATFS_AutomatMoore"}}
~-Moore-Automat führt Aktionen beim Betreten und Verlassen eines Zustands aus. {{image url="images/ATFS_AutomatMealy"}}


Revision [5732]

Edited on 2008-10-25 11:07:37 by ToBo
Additions:
~-Mealy-Automat führt Aktionen im Zustandsübergang aus. {{image url="images/ATFS_AutomatMoore"}}
~-Moore-Automat führt Aktionen beim Betreten und Verlassen eines Zustands aus. {{image url="images/ATFS_AutomatMealy"}}
Deletions:
~-Mealy-Automat führt Aktionen im Zustandsübergang aus.
~-Moore-Automat führt Aktionen beim Betreten und Verlassen eines Zustands aus.


Revision [5640]

Edited on 2008-10-23 11:37:59 by ToBo
Additions:
[[EndlicherAutomat Endliche Zustandsautomaten]] (engl. Finite State Machines) werden in der Elektrotechnik mit der Zusammenschaltung von Logik-Gattern realisiert. Dies ist die ursprüngliche Form von Zustandsaustomaten.
Seit dem Einzug der Computer und Mikrocontroller in der Steuerungstechnik sind nun auch __virtuelle__, [[EndlicherAutomat endliche Zustandsautomaten]] möglich (engl. Virtual Finite State Machines, VFSM). Bei der Umsetzung dieser Art von Zustandsautomaten müssen jedoch einige Randbedingungen beachtet werden. Beispielsweise ist hier die Definition von Zustandstabellen empfehlenswert.
Deletions:
[[EndlicheAutomaten Endliche Zustandsautomaten]] (engl. Finite State Machines) werden in der Elektrotechnik mit der Zusammenschaltung von Logik-Gattern realisiert. Dies ist die ursprüngliche Form von Zustandsaustomaten.
Seit dem Einzug der Computer und Mikrocontroller in der Steuerungstechnik sind nun auch __virtuelle__, [[EndlicheAutomaten endliche Zustandsautomaten]] möglich (engl. Virtual Finite State Machines, VFSM). Bei der Umsetzung dieser Art von Zustandsautomaten müssen jedoch einige Randbedingungen beachtet werden. Beispielsweise ist hier die Definition von Zustandstabellen empfehlenswert.


Revision [5639]

Edited on 2008-10-23 11:37:33 by ToBo
Additions:
[[EndlicheAutomaten Endliche Zustandsautomaten]] (engl. Finite State Machines) werden in der Elektrotechnik mit der Zusammenschaltung von Logik-Gattern realisiert. Dies ist die ursprüngliche Form von Zustandsaustomaten.
Seit dem Einzug der Computer und Mikrocontroller in der Steuerungstechnik sind nun auch __virtuelle__, [[EndlicheAutomaten endliche Zustandsautomaten]] möglich (engl. Virtual Finite State Machines, VFSM). Bei der Umsetzung dieser Art von Zustandsautomaten müssen jedoch einige Randbedingungen beachtet werden. Beispielsweise ist hier die Definition von Zustandstabellen empfehlenswert.
Deletions:
Endliche Zustandsautomaten (engl. Finite State Machines) werden in der Elektrotechnik mit der Zusammenschaltung von Logik-Gattern realisiert. Dies ist die ursprüngliche Form von Zustandsaustomaten.
Seit dem Einzug der Computer und Mikrocontroller in der Steuerungstechnik sind nun auch virtuelle, endliche Zustandsaustomaten möglich (engl. Virtual Finite State Machines, VFSM). Bei der Umsetzung dieser Art von Zustandsautomaten müssen jedoch einige Randbedingungen beachtet werden. Beispielsweise ist hier die Definition von Zustandstabellen empfehlenswert.


Revision [5109]

Edited on 2008-09-03 03:23:59 by ToBo
Additions:
~-Die orthogonale Dekomposition liefert Composite States, die aus s.g. Regionen, engl. regions (Born2004, S. 183) bestehen. Man spricht von Composite States wenn mindestens eine Region vorhanden ist. Die Regionen beinhalten Zustandsautomaten. Die Zustandsautomaten werden innerhalb einer Region vollständig dargestellt.
~-Submachine States sind Zustände, die __einen__ Zustandsautomaten beinhalten. Der Zustandsautomat wird in einem separaten Diagramm, also im Gegensatz zu Composite States nicht im inneren des oberliegenden Zustandes dargestellt.
Deletions:
~-Die orthogonale Dekomposition liefert Composite States, die aus s.g. Regionen, engl. regions (Born2004, S. 183) bestehen. Die Regionen beinhalten im Zustandsautomaten. Die Zustandsautomaten werden innerhalb der Region dargestellt.
~-Submachine States sind Zustände, die einen Zustandsautomaten beinhalten. Der Zustandsautomat wird in einem separaten Diagramm, also im Gegensatz zu Composite States nicht im inneren des oberliegenden Zustandes dargestellt.


Revision [4948]

Edited on 2008-08-31 03:38:45 by ToBo
Deletions:
==a==UML2==a==
===Typen===
~-Mealy-, Moore- oder Harel-Automaten darstellbar
~-Zustände mit Gedächtnis, nebenläufige Zustände (siehe dazu Balzert2000, S. 323 und Zustandsautomaten der [[SoftwareUml2 UML2]]).
~-Erweiterter endlicher Automaten
===Events===
~-Call event
~-Signal event
~-Time event
~-Change event
===Aktionen===
~-entry / <Aktion> wird als erstes beim Betreten des Zustandes ausgeführt.
~-do / <Aktivität> wird nach der entry-Aktion ausgeführt und läuft bis sie beendet oder der Zustand verlassen wird.
~-exit / <Aktion> wird beim Verlassen ausgeführt.


Revision [4945]

Edited on 2008-08-31 03:22:57 by ToBo
Additions:
Zustandsautomaten können mit zunehmender Anzahl der Zustände unübersichtlich werden. Um dies zu vermeiden können bereiche von Zustandsautomaten oder ganze Zustandsautomaten zu einem Zustand zusammengefasst werden. Die UML 2 bietet hier die Composite State und Submachine States. Es wird auch von Dekomposition von Zuständen (Born2004, S. 177) oder auch s.g. hierarchischen Zustandsautomaten (Balzert2000, S. 325) gesprochen. Es ist bis auf kleine Feinheiten immer dasselbe gemeint - das Zusammenfasen von Zuständen oder ganzer Zustandsautomaten zu einem Zustand.
Die [[SoftwareUml2 UML2]] bietet zwei Varianten von zusammengesetzten Zuständen.
~-Submachine States sind Zustände, die einen Zustandsautomaten beinhalten. Der Zustandsautomat wird in einem separaten Diagramm, also im Gegensatz zu Composite States nicht im inneren des oberliegenden Zustandes dargestellt.
//A **composite state** either contains one region or is decomposed into two or more orthogonal regions. Each region has a set of mutually exclusive disjoint subvertices and a set of transitions. A given state may only be decomposed in one of these two ways.// (OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, Page 549)
//A **submachine state** specifies the insertion of the specification of a submachine state machine. The state machine that contains the submachine state is called the containing state machine. The same state machine may be a submachine more than once in the context of a single containing state machine.// (OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, Page 549)
Deletions:
Zustandsautomaten können mit zunehmender Anzahl der Zustände unübersichtlich werden. Die [[SoftwareUml2 UML2]] bietet hierfür die Dekomposition von Zuständen (Born2004, S. 177) oder auch s.g. hierarchische Zustandsautomaten (Balzert2000, S. 325). Es ist immer dasselbe gemeint. Dabei werden Zustände, der Übersicht und Ordnung wegen, zu einem übergeordneten Zustand zusammengefasst.
Die [[SoftwareUml2 UML2]] bietet genauer genommen zwei Varianten von zusammengesetzten Zuständen.
~-Submachine States sind Zustände, die einen Zustandsautomaten beinhalten. Der Zustandsautomat wird nicht im inneren des oberliegenden Zustandes dargestellt.
//A **composite state** either contains one region or is decomposed into two or more orthogonal regions. Each region has a set of mutually exclusive disjoint subvertices and a set of transitions. A given state may only be decomposed in one of these two ways.// (OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, 549)
//A **submachine state** specifies the insertion of the specification of a submachine state machine. The state machine that contains the submachine state is called the containing state machine. The same state machine may be a submachine more than once in the context of a single containing state machine.// (OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, 549)


Revision [4944]

Edited on 2008-08-31 03:13:41 by ToBo
Additions:
==a==Composite State und Submachine States==a==
Die [[SoftwareUml2 UML2]] bietet genauer genommen zwei Varianten von zusammengesetzten Zuständen.
~-Die orthogonale Dekomposition liefert Composite States, die aus s.g. Regionen, engl. regions (Born2004, S. 183) bestehen. Die Regionen beinhalten im Zustandsautomaten. Die Zustandsautomaten werden innerhalb der Region dargestellt.
~-Submachine States sind Zustände, die einen Zustandsautomaten beinhalten. Der Zustandsautomat wird nicht im inneren des oberliegenden Zustandes dargestellt.
//A **composite state** either contains one region or is decomposed into two or more orthogonal regions. Each region has a set of mutually exclusive disjoint subvertices and a set of transitions. A given state may only be decomposed in one of these two ways.// (OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, 549)
//A **submachine state** specifies the insertion of the specification of a submachine state machine. The state machine that contains the submachine state is called the containing state machine. The same state machine may be a submachine more than once in the context of a single containing state machine.// (OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, 549)
==a==Testplan==a==
Deletions:
==a==Dekomposition==a==
Die [[SoftwareUml2 UML2]] bietet genauer genommen drei Varianten der Dekomposition von Zuständen
~-Composite State: Zusammenfassung mehrerer Zustände in einem Zustand; Die Transitionen werden unverändert dargestellt
~-Orthogonale Dekomposition zu s.g. Regionen (Born2004, S. 183)
~-Statemachine State
~-**Composite State** fasst eine Gruppe von Zuständen in einem Zustand zusammen.


Revision [4939]

Edited on 2008-08-31 02:32:18 by ToBo
Additions:
Zustandsautomaten können mit zunehmender Anzahl der Zustände unübersichtlich werden. Die [[SoftwareUml2 UML2]] bietet hierfür die Dekomposition von Zuständen (Born2004, S. 177) oder auch s.g. hierarchische Zustandsautomaten (Balzert2000, S. 325). Es ist immer dasselbe gemeint. Dabei werden Zustände, der Übersicht und Ordnung wegen, zu einem übergeordneten Zustand zusammengefasst.
Die [[SoftwareUml2 UML2]] bietet genauer genommen drei Varianten der Dekomposition von Zuständen
~-Composite State: Zusammenfassung mehrerer Zustände in einem Zustand; Die Transitionen werden unverändert dargestellt
~-Orthogonale Dekomposition zu s.g. Regionen (Born2004, S. 183)
~-Statemachine State
Deletions:
Zustandsautomaten können mit zunehmender Anzahl der Zustände unübersichtlich werden. Die [[SoftwareUml2 UML2]] bietet hierfür die Dekomposition von Zuständen (Born2004, S. 177) zu s.g. composite states oder auch s.g. hierarchische Zustandsautomaten (Balzert2000, S. 325). Es ist immer dasselbe gemeint. Dabei werden Zustände, der Übersicht und Ordnung wegen, zu einem übergeordneten Zustand zusammengefasst.


Revision [4938]

Edited on 2008-08-31 02:23:18 by ToBo
Additions:
Erweiterte, endliche Zustandsautomaten besitzen abgesehen von ihren Zuständen, als erweiterung lokale Variablen, die das Verhalten beim Eintreffen von Ereignissen beeinflussen können, wie bei Zustandsautomaten der [[SoftwareUml2 UML2]] oder allgemein Harel-Automaten.
Deletions:
Erweiterte, endliche Zustandsautomaten besitzen abgesehen von ihren Zuständen, lokale Variablen, die das Verhalten beim Eintreffen von Ereignissen beeinflussen können, wie bei Zustandsautomaten der [[SoftwareUml2 UML2]].


Revision [4937]

The oldest known version of this page was created on 2008-08-31 02:21:35 by ToBo
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki