So können Sie mithilfe von Zustandsdiagrammen einen besseren Web-Coder erstellen

Ein Werkzeug, das in Ihrem Web-Codierungsarsenal enthalten sein sollte, ist das Zustandsdiagramm. Ein Zustandsdiagramm zeigt die verschiedenen "Zustände" (Reaktionen), in denen sich Ihre Anwendung (z. B. eine Website) befinden kann, sowie die Aktionen oder Eingaben (vom Benutzer), die erforderlich sind, um zu einem bestimmten Status zu gelangen. Ein Zustandsdiagramm hilft Ihnen dabei, alle möglichen Benutzer- / Anwendungsinteraktionen zu konkretisieren. Dies erhöht die Wahrscheinlichkeit, dass Sie zumindest die Kodierung aller Möglichkeiten in Betracht ziehen, nur weil Sie sie jetzt alle kennen - was die Wahrscheinlichkeit verringert, dass Sie fehlerhaften Code haben oder, schlimmer, bestimmte Funktionen nicht verwenden.

Warum ein Zustandsdiagramm verwenden??

Ein Zustandsdiagramm besteht aus zwei Komponenten: Kreise zur Darstellung von Zuständen (Anwendungsreaktionen / Ausgabe) und Pfeile zur Darstellung von Übergängen (Benutzeraktionen / Eingaben). Zustandsdiagramme sind sehr praktisch für komplexe und weniger komplexe Computeranwendungen. Bei der Website-Entwicklung sind Zustandsdiagramme jedoch nicht immer von Nutzen:

1. Wenn Sie über eine statische Website verfügen, auf der die Navigation garantiert, dass jede einzelne Seite mit jeder anderen Seite verlinkt ist, ist ein Zustandsdiagramm überflüssig. (Im Zweig der Mathematik, der Graphentheorie, wird diese Situation als "vollständig zusammenhängender Graph" bezeichnet. Ein Graph ist ein Satz von Kanten und Knoten - d. H. Übergängen und Zuständen.)
2. Wenn Sie über eine dynamische Website verfügen, die auf einem CMS (Content Management System) ausgeführt wird - einschließlich Blog-Plattformen -, sind so viele Zustandsübergänge bereits in Ihre Website codiert. Wieder einmal ist ein Zustandsdiagramm nicht sehr nützlich.

Wenn Sie hingegen eine Website erstellen, auf der Sie spezielle Übergänge behandeln müssen, kann ein Zustandsdiagramm von großem Nutzen sein:

1. Behandelt spezielle Benutzereingaben, wobei das, was sie auswählen, den nächsten Status festlegt. (Z. B. Formulare oder Menüs, die Dropdown- oder dynamische Listen enthalten.)
2. AJAX-y-Sites, bei denen die URL auch nach einer erheblichen Benutzeraktion nicht geändert wird. (Content tut, URL nicht.)

Wie erstellen Sie Zustandsdiagramme??

Das Überraschende ist, dass Zustandsdiagramme nicht allzu kompliziert sind. Nach meiner Erfahrung werden sie jedoch von den meisten Programmierern nicht allzu oft verwendet, trotz der Vorteile (tieferes Verständnis der Benutzerinteraktionen; Kohäsion des Codieraufwands). Ich schwöre bei ihnen - oder habe es gemacht, als ich jeden Tag in verschiedenen Jobs programmiert habe.

Es wird empfohlen, Zustandsdiagramme zuerst auf Papier zu erstellen und sie dann, wenn und nur dann, in eine digitale Kopie zu übertragen. (Die Skalierbarkeit von Eingabe- / Darstellungsbeziehungen auf Papier ist etwas Konkretes, das sie in Ihrem Kopf konkreter macht, wodurch es einfacher wird, alle möglichen Interaktionen zu berücksichtigen und so Fehler in Ihren Anwendungen zu reduzieren.)

Ein Zustandsdiagramm besteht aus:

• Beschriftete Pfeillinien zur Anzeige der Benutzereingabe / Aktion (Übergang).
• Beschriftete Kreise, um die resultierende Anzeige des Inhalts anzuzeigen (Anwendungsstatus).
• Beginnen Sie den Zustand mit einem doppelten Randkreis.
• Endzustände (jedoch nicht, wenn die Anwendung webbasiert ist. Eine Erläuterung finden Sie unten.)

Direkt unten sehen Sie ein einfaches Beispiel, auf das später in diesem Artikel eingegangen wird:

Hier sind die Schritte zum Erstellen von Zustandsdiagrammen (mit einer Neigung zu website-basierten Anwendungen):

1. Erstellen Sie eine Liste aller möglichen Eingaben durch den Anwendungsbenutzer aus jedem einzelnen Status.
2. Zeichnen Sie den Startzustand - einen mit "S" gekennzeichneten Kreis mit doppeltem Rand. Bei einer Website ist der Startstatus die Startseite und ihre Standardanzeige.
3. Zeichnen Sie Kreise für mögliche eindeutige Zustände oder Unterzustände. Bei statischen Websites ist jede Webseite ein separater Status. Wenn Ihre Web-App unterschiedliche Unterzustände für dieselbe URL haben kann, müssen Sie separate Zustandskreise zeichnen.
4. Zeichnen Sie für jede mögliche Aktion aus dem Startzustand beschriftete Pfeile (Übergänge) in den nächsten möglichen Zustandskreis.
5. Wiederholen Sie diesen Vorgang für jeden Status, bis Sie ein vollständiges Statusdiagramm für die Anwendung haben.
6. Vergessen Sie nicht die kreisförmigen Übergänge. Zum Beispiel von einem Zustand zurück zu sich selbst (möglicherweise weil der gleiche Link zweimal erneut angeklickt wird).
7. Wiederholte Übergänge von einem Cluster verwandter Zustände können mit einer kurzen Form dargestellt werden, wie nachstehend erläutert wird.
8. Zustandsdiagramme für Nicht-Webanwendungen haben fast immer den Status "Ende". Das Web wird jedoch als "zustandslos" bezeichnet, da in einem Webbrowser jeder einzelne Zustand ein Endzustand ist. Sie können eine Aktion ausführen und gehen oder eine andere Aktion ausführen und dann lassen, usw. Für Webanwendungen muss also nicht der End-Status gezeichnet werden.

Um auf Nummer 7 zu erweitern, bedenken Sie, dass es bei Websites zu zahlreichen Wiederholungen von Aktionen kommen kann. Wenn beispielsweise jede Seite dasselbe Navigationsmenü enthält, müssen Sie diese Übergänge nicht immer wieder anzeigen und das Zustandsdiagramm nicht durcheinander bringen. Stellen Sie einfach gruppierte Aktionen mit Kurznotation / Symbol dar.

(Es ist viel einfacher, ein Zustandsdiagramm zu verstehen, wenn Sie die Person zeichnen, die Sie Schritt für Schritt zeichnen. Wenn Sie eine Person sind, die ein fertiges Zustandsdiagramm betrachtet, kann dies einschüchternd sein. Aus diesem Grund sind Zustandsdiagramme oft nur Papier - vorausgesetzt, Sie verwenden sie.

Wie können Zustandsdiagramme auf website-basierte Anwendungen angewendet werden??

Für eine statische Website, die verwendet Nein AJAX-y-Features (d. H. Jedes Feature, bei dem sich die URL nicht ändert), ein Zustandsdiagramm ist relativ einfach zu erstellen, aber im Allgemeinen nicht erforderlich. Beispielsweise führt eine statische Website, bei der jede Seite mit jeder anderen Seite verbunden ist, zu einem Zustandsdiagramm, das manchmal als "vollständig verbundener" Graph bezeichnet wird. Solche Zustandsdiagramme sind in der Regel nicht sinnvoll, da keine spezielle Handhabung zu visualisieren ist. Jeder Staat ist mit jedem anderen Staat verbunden.

Wo Zustandsdiagramme am praktischsten sind, gilt für dynamische Websites - insbesondere für solche mit AJAX-y-Funktionen (wie Drop-Menüs, Schieberegler, Akkordeons, Galerien usw.). In letzterem Fall ändert sich die URL im Browser möglicherweise nicht, der Inhalt der Seite jedoch teilweise. Es ist schwieriger, alle möglichen Zustände und Übergänge (Aktionen) zu visualisieren, da eine "Seite" mehrere Unterzustände haben kann.

Ein Zustandsdiagramm (oder ein Satz immer detaillierterer Diagramme) ist in diesem Fall sehr nützlich - vor allem, wenn ein Team von Programmierern (und manchmal auch Designern) zur Verfügung steht.

Ein Beispiel für die Verwendung von Zustandsdiagrammen

In einem anstehenden Tutorial werde ich Ihnen zeigen, wie Sie jQuery für zwei Effekte codieren, die ich in meiner AboutMe-Vorlage verwende. Die Live-Seite enthält einige CSS-Fehler, die zuerst ausgebügelt werden müssen. Ich würde auch gerne weitere jQuery-basierte Funktionen hinzufügen, wenn genügend Zeit zur Verfügung steht. Diese zusätzlichen Funktionen werden in unserem Beispiel behandelt.

In Zukunft wird diese Vorlage zu einem kostenlosen WordPress-Theme, das sich an Freiberufler richtet, die ihre Arbeitserfahrungen präsentieren möchten. Im Moment möchte ich zeigen, wie Zustandsdiagramme Ihnen helfen können, die notwendigen Ursachen / Reaktionen (auch als Eingabe / Übergänge bezeichnet) für die "Current Gigs" -Galerie zu verstehen. Wenn Sie die notwendigen Übergänge verstehen, können Sie selbstsicherer codieren, und es ist alles sprachunabhängig. So können Sie nach der Erstellung des Zustandsdiagramms die Codebibliothek / -sprache festlegen.

Gewünschte Anwendungsmerkmale

Wenn Sie sich die Galerie "Current Gigs" in der Mitte links im Bild oben oder auf der Live-Seite anzeigen, sehen Sie, dass dies im Wesentlichen das gleiche Konzept wie eine Bildergalerie ist. Klicken Sie auf einen Link und Details zu diesem "Gig" werden angezeigt. Bei der Erstellung der Live-Seite gab es jedoch keine jQuery-Tutorials zum Einfügen von Text in den Mix für jeden "Frame" des Showcases. Ich musste mir meinen eigenen Code einfallen lassen.

Dazu musste ich zunächst alle möglichen Benutzerinteraktionen verstehen. Ein Zustandsdiagramm ist dafür ideal. Lassen Sie uns den Ante hochgehen. Was ich wirklich wollte, ist ein Showcase-Bereich, in dem sowohl Current Gigs als auch Past Gigs gezeigt werden. Es ist wie eine visuelle C.V. (Lebenslauf, auch "Lebenslauf" genannt), zeigt eine Galerie der Arbeitserfahrung. Der Rahmen jedes Gig enthält einen Bildschirmausschnitt der Homepage der zugehörigen Site sowie Text, der Details zu meiner Arbeit dort angibt.

Im Moment hat die Seite nur "Current Gigs", sollte aber auch "Past Gigs" haben. Hier ist eine Liste der funktionalen Anforderungen, was der Schaufensterbereich haben sollte:

1. Tab jQuery-Schnittstelle, aber "unsichtbar". Verwenden Sie anstelle von regulären Registerkarten Mini-Banner, die der Grafik "Current Gigs" ähneln.
2. Wenn ein "Tab" angeklickt wird (Current Gigs, Past Gigs), wird die entsprechende Gigliste zusammen mit dem Rahmen (Details) des ersten Elements angezeigt.
3. Der Standard-Showcase ist "Current Gigs"..
4. Wenn jemand auf "Frühere Gigs" klickt, muss die Liste der vergangenen Gigs zusammen mit dem Detailrahmen des ersten Elements in dieser Liste angezeigt werden.
5. Gigs-Listen Jede "Registerkarte" enthält eine Liste von Gigs, die mit einem Blueprint-CSS-Raster links positioniert sind.
6. Die Gig-Listenelemente werden Textlinks sein.
7. Jedes Schaufenster wird völlig unterschiedliche Verbindungen haben (frühere und gegenwärtige Arbeit). Eine "Berufserfahrung" kann also immer nur in einer Vitrine erscheinen.
8. Wenn auf ein Element in einer Gigliste geklickt wird, wird der "Frame" des Gig angezeigt. Jeder Frame zeigt einen Bildschirmauszug (zuvor gespeichert) und die zugehörige Jobbeschreibung. Das Blueprint-CSS-Raster-Framework wird zur Positionierung der Schaufensterelemente verwendet. (Dies ist nicht notwendig, aber das ist es, was ich anstrebe.)

Um dies zu wiederholen, besteht das Ziel darin, eine Registerkarte mit Registerkarten zu haben, in der die Registerkarten mit "Current Gigs" und "Past Gigs" gekennzeichnet sind. Dies ermöglicht später mehr Registerkarten, die nur durch die Breite der einzelnen Beschriftungen und die Breite des Vitrinenbereichs (590 Pixel) begrenzt sind. Aber ich möchte, dass die Registerkarten wie erwähnt "unsichtbar" sind. Anstelle der typischen Registerkarten in einer Registerkartenoberfläche möchte ich Mini-Banner verwenden. Wenn Sie sich die Live-Testseite ansehen, gibt es ein Mini-Banner mit der Aufschrift "Current Gigs" und ein weiteres mit der Bezeichnung "Past Gigs". Das werden die Registerkarten sein. Hier ist ein Nahaufnahmebildschirm mit den Standardeinstellungen, wie der endgültige Schaufensterbereich aussehen könnte.

Zustandsdiagramm erstellen

Um das Zustandsdiagramm zu erstellen, müssen wir zunächst alle möglichen eindeutigen Zustände, Eingaben und Aktionen auflisten.

1. Startzustand: Beim Laden der Homepage:
   1. Alle Gig-Frames mithilfe von CSS ausblenden (nicht anzeigen).
   2. Präsentieren Sie den Showcase "Current Gigs" als Standard.
   3. Zeigen Sie im Standard-Showcase den Rahmen für das erste Element in der Gig-Liste als Standard an. Wenn also jemand auf die Registerkarte "Current Gigs" klickt, wird der Showcase von selbst zurückgesetzt.
2. Mögliche generische Aktionen ab dem Startstatus:
   
   1. Klicken Sie auf "Tab". Reaktion / Übergang: Rendern Sie das Showcase entsprechend der angeklickten Registerkarte.
   2. Klicken Sie auf einen Gig-Listeneintrag. Reaktion / Übergang: Rendern Sie den entsprechenden Gig-Artikelrahmen.
3. Mögliche generische Aktionen aus anderen Staaten: genauso. Wir sind in diesem Fall glücklich, weil das Zustandsdiagramm dadurch viel einfacher wird.

Hinweis: An dieser Stelle geht es uns nur um das, was in der C.V. passiert. Vitrine. Im Zustandsdiagramm interessieren uns keine Aktionen, die sich auf andere Teile der Webseite auswirken. Wir zeigen nur Aktionen / Reaktionen, die den C.V. betreffen. Vitrine.

Hier ist ein Beispiel für ein Zustandsdiagramm für die obige Funktionalität.

Ein paar Anmerkungen zu diesem Diagramm:

1. Für die Zwecke dieser Diskussion ist es nicht so wichtig, was jedes Etikett eigentlich ist. Hier ist jeder eine Website, für die ich jetzt schreibe oder für die ich früher geschrieben habe.
2. Es ist nicht so kompliziert wie es aussieht. Konzentriere dich einfach auf einen Übergang und es wird klar, was los ist. [Hier sind die Aktionsbeschriftungen mit den Zustandsbeschriftungen identisch. Das ist nicht immer der Fall.] Normalerweise ist es viel klarer, wenn Sie das Diagramm selbst zeichnen und nacheinander neue Zustandskreise und Übergangspfeile hinzufügen.
3. Übergänge, auch als Benutzeraktionen bezeichnet, werden durch beschriftete Pfeile dargestellt. (Normalerweise handelt es sich bei den Beschriftungen um Volltext, nicht um die hier verwendeten Kurzformen.)
4. Staaten, auch Reaktionen genannt, werden durch Kreise dargestellt. Der Startzustand ist immer mit einem Doppelkreis und einem "S" markiert..
5. Für beide Beschriftungstypen werden Kurzformen verwendet, um das Diagramm übersichtlicher zu gestalten.
6. Die Zustände und Unterzustände sind farblich codiert, je nachdem, ob sie primärer oder sekundärer Natur sind. Blau steht beispielsweise für Primärzustände (und Übergänge). Sie können vom Startstatus zu einem beliebigen blauen Status wechseln, indem Sie auf den entsprechenden Link klicken. Sie können nicht von Anfang an in einen violetten (sekundären) Status wechseln, ohne zuvor einen primären Status durchlaufen zu haben.
7. Da es viele wiederholte Übergänge gibt (d. H. Von einem beliebigen Gig zum anderen), werden Gruppen von Übergängen mit einem der dicken umrandeten Pfeile (blaue oder violette Füllung) dargestellt. Während Sie beispielsweise die Details zum FF (FreelanceFolder) anzeigen, können Sie auf eines der Gig-Elemente klicken, die für den Showcase CG (Current Gigs) aufgeführt sind, einschließlich FF selbst. Oder Sie können auf das CG-Register klicken und den Showcase zurücksetzen. Sie können nicht von einem "aktuellen" Gig-Frame zu einem "vergangenen" Gig-Frame wechseln oder umgekehrt.
8. Der kurze, umrahmte blaue Pfeil enthält Übergänge zum Standardzustand von CG. Der kurze, umrandete violette Pfeil enthält keine Übergänge zum Standardstatus von PG. (Das liegt daran, dass diese Übergänge bereits explizit dargestellt werden. Sie waren nicht für CG gedacht, da das Diagramm viel zu unübersichtlich wäre.)

Wenn Sie sich auf Punkt 5 oben erstrecken, gilt als Faustregel, dass Sie bei mehrfachen wiederholten Übergängen aus einem verwandten Cluster von Zuständen die Übergänge mit einer Art Kurzform versehen können. Sie möchten einfach nur ein Gefühl für die wichtigen Übergänge bekommen, damit diese in Ihrem Kopf an erster Stelle stehen. Ein anderer Ansatz besteht darin, ein komplexes Diagramm zu erstellen und in Teile aufzuteilen: Hauptübersicht, dann "explodierte" Versionen von Übergangsclustern.

Beispielsweise könnte das obige Diagramm ein Hauptzustandsdiagramm enthalten, das die Knoten S, CG und PG enthält. Dann gäbe es zwei detaillierte Diagramme. Man hätte S, CG und die entsprechenden Unterzustände, die verschiedene Gigs repräsentieren. Das andere detaillierte Diagramm hätte S, PG und die entsprechenden Gig-Unterzustände.

Abschließende Gedanken

Insgesamt sollten Sie jetzt ein klareres Bild von der Funktionsweise des Schaufensterabschnitts haben. Ich werde nicht näher darauf eingehen, wie ich von einem Zustandsdiagramm zum eigentlichen Code wechseln kann. Wenn Sie alle Benutzerinteraktionen verstanden haben, sollte dies offensichtlich werden. Zustandsdiagramme - und Ihr Verständnis davon sollte Ihnen helfen, zusammenhängenden Code zu schreiben, wodurch die Wahrscheinlichkeit einer fehlerhaften Anwendung verringert wird. Ihre Codiertechnik ändert sich nicht.