Comment l'utilisation de diagrammes d'état peut faire de vous un meilleur codeur Web

Le diagramme d'état est un outil qui devrait figurer dans votre arsenal de codage Web. Un diagramme d'états indique les différents "états" (réactions) dans lesquels votre application (site Web, par exemple) peut être, ainsi que l'action ou l'entrée (de l'utilisateur) nécessaire pour atteindre un état spécifique. Un diagramme d'état aide à concrétiser dans votre esprit toutes les interactions possibles entre l'utilisateur et l'application. Cela augmente les chances que vous envisagiez au moins de coder pour toutes les possibilités simplement parce que vous les connaissez toutes - ce qui réduit les chances que vous ayez un code erroné ou pire, que vous ayez oublié de gérer des fonctionnalités spécifiques..

Pourquoi utiliser un diagramme d'état?

Un diagramme d'états comprend deux composants: des cercles pour représenter les états (réactions / sortie de l'application) et des flèches pour représenter les transitions (actions de l'utilisateur / entrées). Les diagrammes d'état sont très pratiques pour les applications informatiques complexes et peu complexes. Cependant, en ce qui concerne le développement de sites Web, les diagrammes d'état ne sont pas toujours utiles:

1. Si vous avez un site Web statique dans lequel la navigation garantit que chaque page est liée à une autre page, un diagramme d'état est redondant. (Dans la branche des mathématiques appelée théorie des graphes, cette situation est appelée "graphe entièrement connecté". Un graphe est un ensemble d'arêtes et de nœuds, c'est-à-dire de transitions et d'états.)
2. Si vous avez un site Web dynamique fonctionnant sur un CMS (système de gestion de contenu), qui inclut des plates-formes de blogs, une grande partie des transitions d'état est déjà codée sur votre site. Donc, encore une fois, un diagramme d'état n'est pas d'une grande utilité.

D'autre part, si vous construisez un site Web sur lequel vous devez gérer des transitions spéciales, un diagramme d'états peut s'avérer très utile:

1. Gestion des entrées utilisateur spéciales, où ce qu’ils sélectionnent décide de l’état suivant. (Par exemple, des formulaires ou des menus comportant des listes déroulantes ou dynamiques.)
2. Les sites AJAX-y où l’URL ne change pas même après une action utilisateur importante. (Le contenu ne l'est pas, mais pas l'URL.)

Comment créer des diagrammes d'état?

La chose surprenante est que les diagrammes d'état ne sont pas si compliqués à produire. Cependant, selon mon expérience, ils ne sont pas utilisés très souvent par la plupart des programmeurs, malgré les avantages (compréhension plus approfondie des interactions des utilisateurs; cohésion des efforts de codage). Je jure par eux - ou je le faisais quand je codais tous les jours dans divers emplois.

Il est recommandé de créer d'abord les diagrammes d'état sur papier, puis de les transférer sur une copie numérique si et seulement si cela est nécessaire. (Il y a quelque chose dans la tactilité de dessiner des relations d'entrée / affichage sur papier qui les rend plus concrètes dans votre esprit, ce qui permet de gérer plus facilement toutes les interactions possibles et ainsi de réduire les bugs dans vos applications.)

Un diagramme d'état comprend:

• Flèches étiquetées pour montrer la saisie / l'action de l'utilisateur (transition).
• Cercles étiquetés pour afficher l'affichage du contenu résultant (état de l'application).
• Etat de départ avec un cercle double frontière.
• États finaux (mais pas lorsque l'application est basée sur le Web. Voir l'explication ci-dessous.)

Vous pouvez voir un exemple simple directement ci-dessous - qui sera développé plus loin dans cet article:

Voici les étapes à suivre pour créer des diagrammes d'état (avec un penchant pour les applications basées sur les sites Web):

1. Faites une liste de toutes les entrées possibles par l'utilisateur de l'application, à partir de chaque état.
2. Dessinez l'état de départ - un cercle à double bordure étiqueté "S". Avec un site Web, l’état de départ est la page d’accueil et son affichage par défaut.
3. Tracez des cercles pour un ou plusieurs états uniques possibles. Pour les sites statiques, chaque page Web est un état distinct. Si pour votre application Web peut avoir différents sous-états pour la même URL, vous devez dessiner des cercles d'état distincts..
4. Pour chaque action possible à partir de l’état de départ, tracez des flèches étiquetées (transitions) vers le cercle de l’état suivant possible..
5. Répétez cette opération à partir de chaque état jusqu'à obtenir un diagramme d'état complet pour l'application..
6. N'oubliez pas les transitions circulaires. Par exemple, d'un État à lui-même (peut-être parce que vous avez cliqué deux fois sur le même lien).
7. Les transitions répétitives d'un groupe d'états liés peuvent être représentées avec une forme abrégée, comme nous le verrons plus loin..
8. Les diagrammes d'état pour les applications non Web ont presque toujours un état "Fin". Cependant, le Web est dit "sans état" car dans un navigateur Web, chaque état est un état final. Vous pouvez prendre une mesure et partir, ou prendre une autre mesure et puis laisser, etc. Donc, pour les applications Web, il n'est pas nécessaire de dessiner l'état final.

Pour développer le numéro 7 ci-dessus, gardez à l'esprit qu'avec les sites Web, les actions pourraient être répétées. Par exemple, si chaque page comprend le même menu de navigation, il n'est pas nécessaire d'afficher ces transitions à plusieurs reprises et d'encombrer le diagramme d'états. Il suffit de représenter des actions en cluster avec une notation / symbole abrégé.

(Il est beaucoup plus facile de comprendre un diagramme d'état si vous êtes la personne qui le dessine, étape par étape. Si vous regardez un diagramme d'état complet, cela peut être intimidant. Pour cette raison, les diagrammes d'état ne vivent souvent que sur papier. - en supposant que vous les utilisiez.

Comment les diagrammes d'état s'appliquent-ils aux applications Web??

Pour un site web statique qui utilise non Fonctionnalités AJAX-y (c’est-à-dire toute fonctionnalité dont l’URL ne change pas), un diagramme d’état est relativement facile à produire mais généralement inutile. Par exemple, un site Web statique dans lequel chaque page est connectée à une page sur deux génère un diagramme d'états appelé parfois un graphe "entièrement connecté". De tels diagrammes d'état sont généralement inutiles car il n'y a aucune manipulation particulière à visualiser. Chaque état est connecté à tous les autres états)

Les diagrammes d’état sont particulièrement utiles pour les sites dynamiques - en particulier ceux avec Fonctionnalités AJAX-y (telles que menus déroulants, curseurs, accordéons, galeries, etc.). Dans ce dernier cas, l'URL dans le navigateur peut ne pas changer mais le contenu de la page le fait partiellement. Il est plus difficile de visualiser tous les états et transitions possibles (actions) car une "page" peut avoir plusieurs sous-états..

Un diagramme d’état (ou un ensemble de diagrammes de plus en plus détaillés) s’avère très utile dans ce cas, surtout s’il existe une équipe de codeurs (et parfois de concepteurs) avec laquelle travailler..

Un exemple d'utilisation du diagramme d'état

Dans un prochain tutoriel, je vais vous montrer comment coder jQuery pour deux effets que j'utilise dans mon modèle AboutMe. La page en direct présente quelques problèmes CSS qui doivent être résolus en premier. J'aimerais également ajouter d'autres fonctionnalités basées sur jQuery s'il reste suffisamment de temps. Ces fonctionnalités supplémentaires feront l’objet de notre exemple.

À l'avenir, ce modèle deviendra un thème WordPress gratuit destiné aux pigistes souhaitant mettre en valeur leur expérience de travail (concerts). Pour l'instant, je veux montrer comment les diagrammes d'état peuvent vous aider à comprendre la cause / les réactions nécessaires (entrée / transitions) pour la galerie "Current Gigs" présentée ci-dessus. Comprendre les transitions nécessaires vous aide à coder avec plus de confiance, et tout est indépendant du langage de codage. Vous pouvez donc choisir la bibliothèque / le code après avoir créé le diagramme d'état..

Caractéristiques de l'application souhaitées

Si vous regardez la galerie "Current Gigs" au centre à gauche de l'image ci-dessus, ou sur la page en direct, vous verrez qu'il s'agit essentiellement du même concept qu'une galerie d'images. Cliquez sur un lien et les détails de ce "concert" apparaîtront. Cependant, lorsque j'ai créé la page en direct, il n'y avait pas de tutoriels jQuery sur la manière d'ajouter du texte dans le mix, pour chaque "cadre" de la vitrine. Je devais venir avec mon propre code.

Pour ce faire, je devais d'abord comprendre toutes les interactions possibles entre les utilisateurs. Un diagramme d'état est idéal pour cela. Let's up the ante, cependant. Ce que je voulais vraiment, c’est un espace vitrine montrant les concerts actuels et passés. C'est un peu comme un visuel visuel. (Curriculum Vitae, aussi appelé "CV"), présentant une galerie d’expériences professionnelles. Le cadre de chaque concert contient une capture d'écran de la page d'accueil du site associé, ainsi qu'un texte donnant des détails sur le travail que j'ai effectué / que j'effectue actuellement..

Pour le moment, la page contient uniquement les "concerts actuels", mais devrait également contenir les "concerts passés". Voici une liste des exigences fonctionnelles pour ce que la zone de démonstration devrait avoir:

1. Interface jQuery à onglets, mais "invisible". Au lieu d'utiliser des onglets classiques, utilisez des mini-bannières similaires au graphique "Concerts actuels"..
2. Lorsque vous cliquez sur un "onglet" (concerts en cours, concerts passés), la liste de concerts appropriée s'affiche, ainsi que le cadre (détails) du premier élément..
3. La vitrine par défaut est "Gigs actuels".
4. Lorsque quelqu'un clique sur "Past Gigs", la liste des concerts passés doit s'afficher, ainsi que le cadre de détails du premier élément de cette liste..
5. Listes de concerts. Chaque "onglet" fournira une liste de concerts positionnés à gauche en utilisant une grille CSS Blueprint.
6. Les éléments de la liste de concerts seront des liens de texte.
7. Chaque vitrine aura des liens totalement différents (travail passé et présent). Donc, une "expérience de travail" ne peut apparaître que dans une vitrine à la fois.
8. Lorsqu'un élément de la liste de concerts est cliqué, les "cadres" des détails du concert apparaissent. Chaque cadre affichera une capture d'écran (précédemment enregistrée) et la description de travail associée. Le cadre de la grille CSS de Blueprint sera utilisé pour positionner les éléments de la vitrine. (Ce n'est pas nécessaire, mais c'est ce que je vise.)

Donc, pour réitérer, l'objectif est d'avoir une interface à onglets où les onglets sont étiquetés "concerts actuels" et "concerts passés". Cela permet d'avoir plus d'onglets plus tard, uniquement limité par la largeur de chaque étiquette et la largeur de l'espace d'affichage (590 pixels). Mais je veux que les onglets soient "invisibles", comme mentionné. Au lieu des onglets typiques d'une interface à onglets, je souhaite utiliser des mini-bannières. Si vous regardez la page de test en direct, il y a une mini-bannière intitulée "Current Gigs" et une autre intitulée "Past Gigs". Ce seront les onglets. Voici un aperçu en gros plan de ce à quoi la zone finale de la vitrine pourrait ressembler, avec les paramètres par défaut.

Création du diagramme d'état

Pour créer le diagramme d'états, nous devons d'abord énumérer tous les états, entrées et actions uniques possibles:

1. Etat de départ: Au chargement de la page d'accueil:
   1. Masquer (non afficher) toutes les images de concert en utilisant CSS.
   2. Présenter la vitrine "Current Gigs" par défaut.
   3. Dans la vitrine par défaut, présentez le cadre par défaut pour le 1er élément de la liste des concerts. Donc, chaque fois que quelqu'un clique sur "l'onglet" des concerts actuels, la vitrine se réinitialisera.
2. Actions génériques possibles à partir de l'état de départ:
   
   1. Cliquez sur "onglet". Réaction / transition: rendre la vitrine correspondant à l'onglet sur lequel vous avez cliqué.
   2. Cliquez sur un élément de la liste de concerts. Réaction / transition: restitue la trame de la tâche correspondante.
3. Actions génériques possibles d'autres États: exactement le même. Nous sommes chanceux dans ce cas, car cela simplifie beaucoup le diagramme d'états..

Remarque: pour l'instant, nous ne nous intéressons qu'à ce qui se passe dans le C.V. vitrine. Dans le diagramme d'état, nous ne nous soucions pas des actions qui affectent d'autres parties de la page Web. Nous ne montrons que les actions / réactions qui affectent le CV. vitrine.

Voici un exemple de diagramme d'état pour la fonctionnalité ci-dessus..

Quelques notes sur ce diagramme:

1. Aux fins de la présente discussion, la signification de chaque étiquette n’est pas très importante. Ici, chacun représente un site Web que je suis en train d’écrire pour le moment ou utilisé pour écrire.
2. Ce n'est pas aussi compliqué qu'il n'y paraît. Concentrez-vous sur une transition à la fois et vous verrez clairement ce qui se passe. [Ici, les étiquettes d'action sont les mêmes que les étiquettes d'état. Ce n’est pas toujours le cas.] C’est généralement beaucoup plus clair de dessiner le diagramme vous-même, en ajoutant de nouveaux cercles d’état et de nouvelles flèches de transition..
3. Les transitions, autrement dit les actions de l'utilisateur, sont représentées par des flèches étiquetées. (Normalement, les étiquettes sont du texte intégral, pas les formes abrégées utilisées ici.)
4. Les états, ou réactions, sont représentés par des cercles. L'état de départ est toujours marqué d'un double cercle et d'un "S".
5. Des formes abrégées sont utilisées pour les deux types d’étiquettes, pour que le diagramme soit moins encombré..
6. Les états et les sous-états sont codés par couleur en fonction de leur nature primaire ou secondaire. Par exemple, le bleu représente les états primaires (et les transitions). Vous pouvez passer de l'état de démarrage à n'importe quel état bleu en un seul clic sur le lien approprié. Vous ne pouvez pas passer à un état violet (secondaire) à partir de Démarrer sans d'abord passer par un état principal.
7. Comme il y a beaucoup de transitions répétitives (c'est-à-dire, d'un article de concert à un autre), des groupes de transitions sont montrés avec l'une des flèches à contour épais (remplissage bleu ou violet). Par exemple, lorsque vous consultez les détails du concert FF (FreelanceFolder), vous pouvez cliquer sur l’un des éléments de concert répertoriés pour la vitrine CG (Current Gigs), y compris FF. Ou vous pouvez cliquer sur l'onglet "onglet" CG et réinitialiser la vitrine. Vous ne pouvez pas passer d’une trame de concert "actuelle" à une trame de "passé", ni inversement.
8. La courte flèche bleue soulignée inclut les transitions vers l'état par défaut de CG. La courte flèche violette soulignée n'inclut pas les transitions vers l'état par défaut de PG. (C'est parce que ces transitions sont déjà indiquées explicitement. Elles n'étaient pas pour CG, car le diagramme serait trop encombré.)

En développant le point 5 ci-dessus, la règle de base est que s'il existe plusieurs transitions répétitives à partir d'un groupe d'états apparentés, vous pouvez les annoter avec une sorte de forme abrégée. Vous voulez simplement avoir une idée des transitions importantes pour qu’elles soient au premier plan dans votre esprit. Une autre approche consiste à prendre un diagramme complexe et à le scinder en plusieurs parties: aperçu général, puis versions "éclatées" des grappes de transition..

Par exemple, le diagramme ci-dessus aurait pu avoir un diagramme d'état principal contenant les nœuds S, CG et PG. Ensuite, il y aurait deux schémas détaillés. On aurait S, CG, et les sous-états correspondants représentant divers concerts. L'autre diagramme détaillé aurait S, PG et les sous-états de gig correspondant.

Dernières pensées

Globalement, vous devriez maintenant avoir une image mentale plus claire du fonctionnement de la section vitrine. Je ne vais pas vous expliquer comment passer d'un diagramme d'état à un code réel. Cela devrait devenir évident une fois que vous aurez compris toutes les interactions de l'utilisateur. Diagrammes d'état - et votre compréhension de ceux-ci devrait vous aider à écrire un code plus cohérent, réduisant ainsi les risques d'application buggy. Votre technique de codage ne change pas.