Guten Tag und Hallo, ich habe mir gedacht ich probiere es mal in einem Forum bei Leuten die mehr Ahnung haben als ich (Wasin diesem Fall nicht schwer ist). Ich muss ein Referat über State machine diagramme halten, da wir diese für die Dokumentation unserer Projektarbeit benötigen. (Fachgymnasium IT) Mein Problem liegt nun darin, dass ich als Quelle ledoglich einen für mich fast vollkommen unverständlichen ENGLISCHEN Wikipedia Text vorliegen habe. Ansich lese ich mcih in sowas rein und werde das shcon schaffen aber das wächst mir gerade echt über den Kopf... Jemand ne Idee wo ich einfache Informations-Kost bzw. verständliche Infos oder Hilfe finde? Oder hat jemand gar lust mir das ganze zu erklären!?/Zu helfen?! Vielen lieben Dank schoneinmal im Voraus Michelle
Hallo Michelle, wahrscheinlich googelst Du nach dem Falschen. Versuchs mal mit: Zustandsautomat, Zustandsgraph, endliche Automaten, Automatentheorie. Da gibts auch was in germanisch. Jürgen
@ Michelle (Gast) >Jemand ne Idee wo ich einfache Informations-Kost bzw. verständliche >Infos oder Hilfe finde? Oder hat jemand gar lust mir das ganze zu >erklären!?/Zu helfen?! Siehe Statemachine http://de.wikipedia.org/wiki/Zustandsautomat MfG Falk
Danke =) Sitze momentan noch an den 5 Seiten, zu Übersetzen. Ansich habe ich glaube ich verstanden, worum es geht, ich muss der Klasse jedoch näherbringen, wie die das aufgrund ihrer Programme (Jcontrol/Java) erstellen können und so weiter, sprich wie Visualisieren die den Aufbau ihres Projektes ohne uns einfach nur ihren Pgrammtext vorzubeten,... Und wie mache ich das am Ende bei meinem Projekt '=D Wie wird was zu was und Warum!?
Das ganze ist falsch herum aufgezogen. Du zeichnest die State Machine bevor du sie implementierst. Das ist ja genau das Wesen all dieser Beschreibungen: Man konzentriert sich auf die Aufgabe und nicht auf die Details die in einer Programmiersprache nötig sind. State-Maschinen sind besonders einfach zu beschreiben. Von den wahrscheinlich unzähligen Möglichkeiten bevorzuge ich die hier: Jeder State ist ein Kreis. Über dem Kreis (oder in ihm drinnen) steht der Name des Zustands, der natürlich so gewählt ist, dass man sofort erfasst, was dieser Zustand aussagt. Normalerweise sind das Eigenschaftswörter (wartend, lesend, Ventil geöffnet etc.). Jeder Zustand ist ein Kreis. Von einem Zustand zu einem anderen Zustand (aber auch zu sich selber) kann es einen Pfeil geben. Dieser Pfeil beschreibt den Übergang von einem Zustand in einen anderen Zustand. Über dem Pfeil steht die Bedingung, die vorliegen muss, damit dieser Pfad begangen werden kann, unter dem Pfeil steht die Aktion die dabei ausgeführt wird. Und das wars dann schon. Du hast eine graphische Repräsentierung einer State-Maschine. Mit ihr kann man hervorragend die Logik der State Maschine kontrollieren und verbessern. Ist man mit der Logik zufrieden, so ist es ebenfalls einfach aus dieser Graphik das Programm zu erzeugen.
Im Wesentlichen kann man das Ganze auch als Tabelle darstellen : Zustand Ereignis Aktion NeuerZustand .. .. .. .. .. .. .. ..
Hallo !! Oder du kannst auch die ganze Tabelle in einen Zustandsgraph packen. -> Jeder Zustand ein Kreis mit Zustandsname und ev. einer Zustandscodierung. -> und zwischen den Kreisen (Zuständen) Pfeile einzeichnen die du mit den Ereignissen für einen Zustandswechsel und den dabei gesetzten Ausgängen beschriftest. L.g
Angehängte Dateien:
-
michelle.gif
15 KB
So könnte sowas zb als Graphik aussehen (Bild) Es zeigt den 'Weg' der State-Machine 'Michelle' mit den möglichen Zuständen bei der Lösung des Problems "Wie schreibe ich ein Referat zum Thema 'Visualisierung von State-Machines'". Weitere Verfeinerungen sind natürlich möglich und sollten auch gemacht werden :-)
Hey Kbuchegg, Die Grafik ist klasse, darf ich die in 'ordentlich' gezeichnet überhnehm? Die ist total süß lach LG Michelle
Sicher. Aber viel wichtiger: Alles klar, worauf es ankommt? Es kommt nicht darauf an, alle ; an den richtigen Stellen zu haben. Es kommt nicht darauf an for und while richtig zu schreiben. Es kommt einzig und alleine darauf an nachvollziehen zu können, wie und warum und mit welchen Aktionen die Statemachine ihre Zustände wechselt. Man kann sich jede 'Maschine' als Zustandsmaschine denken und die Maschine wechselt von einem Zusatnd in irgend einen anderen. Bei manchen Maschinen sieht man das gut, zb eine Ampel. Die einzelnen Lichtphasen sind die Zustände. Bei wieder anderen sieht man es nicht so gut, zb. Getränkeautomat und bei wieder anderen sind die Zustände zwar auch da, aber von aussen nicht so toll bemerkbar. Im letzten Fall hindert einen aber nichts und niemand da ein paar Zustände zu postulieren.
@Karl heinz Buchegger: Mit was hast du denn das gezeichnet? 1,7MB sind dafür aber wirklich nicht notwendig... Oder wie Falk so schön sagen würde: Bildformate ;)
Uuups. Hab gar nicht drauf geachtet. Mit Paint gezeichnet und als GIF gespeichert. Hätte nicht gedacht, dass MS_Paint so dermassen schwach ist.
Karl heinz Buchegger schrieb: > Uuups. > Hab gar nicht drauf geachtet. Mit Paint gezeichnet und als GIF > gespeichert. Hätte nicht gedacht, dass MS_Paint so dermassen schwach > ist. Was kann Paint den dafür? :P
Läubi .. schrieb: > Karl heinz Buchegger schrieb: >> Uuups. >> Hab gar nicht drauf geachtet. Mit Paint gezeichnet und als GIF >> gespeichert. Hätte nicht gedacht, dass MS_Paint so dermassen schwach >> ist. > Was kann Paint den dafür? :P Na ja. ein 700*700 Pixel Bild in 4 Farbe solle als GIF dann schon ein wenig kleiner sein.
Ja, habe soweit Alles wichtige verstanden, nochmal vielen dank euch =) Bin schon fleissig dabei, die Präsi zu gestalten LG Michelle
Karl heinz Buchegger schrieb: > Läubi .. schrieb: >> Karl heinz Buchegger schrieb: >>> Uuups. >>> Hab gar nicht drauf geachtet. Mit Paint gezeichnet und als GIF >>> gespeichert. Hätte nicht gedacht, dass MS_Paint so dermassen schwach >>> ist. >> Was kann Paint den dafür? :P > > Na ja. > ein 700*700 Pixel Bild in 4 Farbe solle als GIF dann schon ein wenig > kleiner sein. Asche auf mein Haupt. Man sollte dann doch als Dateityp gif einstellen und nicht einfach nur eine Dateiendung .gif benutzen. Ich erkläre feierlich, dass Paint unschuldig ist, wenn sich der Benutzer zu dämlich anstellt.
wie viele Beiträge man einfach nur wegen der falschen abspeicherung eines Bilder vergeuden kann, faszinierend :D SO ich bin jetzt fertig und es war kürzer und einfachher als gedacht, Dank euch ;) Ich komm mal drauf zurück wenn ich das refi über verkabelungstechnik halte :P Eure Michelle
Hallo, noch ein wichtiger Hinweis: bei Zustandsautomaten unterscheidet man oft zwischen Moore- und Mealy-Automaten, siehe: http://de.wikipedia.org/wiki/Moore-Automat http://de.wikipedia.org/wiki/Mealy-Automat Jedoch kann man ohne weiteres auch Automaten implementieren, die Mischformen darstellen, was häufig auch sehr sinnvoll ist. Vor längerer Zeit gab es einmal ein Rapid-Prototyping-Werkzeug für GUIs namens Rapid, in dem die äußerst nützlichen Konventionen eingeführt wurden: Action: kurzzeitiger Vorgang bei Zustandsübergang Activity: Tätigkeit während des Aufenthalts in einem Zustand Die Acitivity "Lasse die Lampe leuchten, während sich der Automat in Zustand 5 befindet", lässt sich in die Actions "Schalte die Lampe beim Betreten in Zustand 5 ein" und "Schalte die Lampe beim Verlassen von Zustand 5 aus" überführen. Einen Blinkvorgang kann man entweder als zeitgesteuerten Wechsel zwischen zwei Zuständen realisieren, was aber schnell zu aufge- blähten Zustandstabellen und -diagrammen führen kann, oder über ein Schleifenkonstrukt (als Activity) innerhalb eines einzelnen Blink-Zustandes. Gruß Andreas Schweigstill
Hi, ja, das ging aus dem Englischen WIki hervor, dass es zwei arten gibt, da ich die UML state machine machen soll ist das jedoch egal, wie du schon sagst können sie ja vermischt werden und werden sie bei UML ja auch ;) trotzdem danke für den hinweis
Hmmm, ja. Wenn die Aktionen laenger dauern wie fuer die Maschine einen Augenblick ist, dann bekommt man transiente oder zerfallende Zustaende, wie zB Led-Blink, welches mind. 50ms dauern sollte.
Gleicher Tag schrieb:
> transiente oder zerfallende Zustaende
Solche Zustände sind in der Tat ein massives Problem, wenn es darum
geht, ein Modell, das man in einer entsprechenden Beschreibungssprache
oder CASE-Tool spezifiziert hat, auf ein Zielsystem zu übertragen,
z.B. auch per Codegenerierung.
Früher(tm) hatte ich mich u.a. mit dieser Thematik befasst, und zwar
im Zusammenhang mit SDL (Specification and Description Language, Z.100).
In SDL waren alle Zustandsübergänge stets zeitlos, im generierten Code
natürlich nicht. Es gibt nun verschiedene Möglichkeiten, eine Abbildung
der SDL-Prozesse auf die Betriebsmittel des Zielsystems vorzunehmen.
Zunächst banal sieht die Variante aus, bei der man jeden SDL-Prozess
auf einen Betriebssystemprozess abbildet (sog. Maximalintegration). Es
stellt sich jedoch heraus, dass das die mit Abstand gefährlichste
Variante ist, nämlich auf Grund drohender Race Conditions, die zum einen
durch Kontextwechsel während Zustandsübergängen und zum anderen durch
den Lebenszyklus nur kurzzeitig erzeugter Prozessinstanzen entstehen.
Andere Integrationsformen nennen sich Minimalintegration (alle SDL-
Prozesse in einem Betriebssystemprozess, eigener Scheduler für SDL,
Environment in eigenen Prozessor) und bare integration (kein Betriebs-
system, eigener Scheduler, Environment als Erweiterung des Schedulers).
Über diese Thematik kann man stunden-, ach tagelang diskutieren und
Bücher schreiben (was auch getan wurde). In vielen Fällen stellt sich
auch heraus, dass der Pflegeaufwand für solche Systeme so hoch ist,
dass der eingesparte Aufwand bei der Anwendungsentwicklung mehr als
aufgezehrt wird.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.