Principes et conseils : Concevoir des applications Web avec UML
Rubriques
Les ouvrages et documents suivants ont servi de référence pour ces principes et conseils :
Ce qui diffère par rapport à l'Activité : Analyse des cas d'utilisation, c'est que les classes frontières sont plus centrées et plus singulières dans leur objectif. Les objets de ces classes ont un cycle de vie court et chaque état client (dans des pages Web) doit être géré de manière explicite par des mécanismes spécifiques. Par exemple, les pages Microsoft Active Server Pages utilisent des "cookies" en tant qu'index dans une carte de l'état de tous les clients actuellement actifs.
Ainsi, lorsqu'on lit les spécifications d'un cas d'utilisation, les principes suivants s'appliquent :
- Chaque référence à une page Web renvoie à une classe frontière.
- Chaque référence à un lien hypertexte renvoie à une association entre une classe frontière et une autre classe frontière ou une classe contrôleur.
- Les verbes et les descriptions des processus correspondent souvent à des classes contrôleur
- Les substantifs correspondent à des classes d'entité
La classe frontière, à travers laquelle est lancée la communication, communique avec une classe contrôleur. Habituellement, cette classe contrôleur ne répond pas par la même instance de classe frontière.
Lorsque l'analyse des cas d'utilisation est en cours, les scénarios peuvent être décrits à l'aide de diagrammes de séquences. Ceci contribue à valider l'existence d'objets d'analyse relatifs à un scénario de cas d'utilisation. Si vous découvrez que des objets d'analyse ne prennent part à aucun de vos scénarios, ils sont suspects et nécessitent une réévaluation. Le risque ici, c'est que si vous vous noyez dans les détails, les diagrammes deviennent immenses et ingérables. Afin d'éviter cela, concentrez-vous sur des scénarios courts et discrets et n'incluez que des objets frontières et des objets contrôleurs principaux ainsi que des objets d'entité
Souvenez-vous que les objets frontières ont une courte durée de vie dans les applications Web. Une classe frontière peut toutefois être instanciée plusieurs fois pendant l'exécution d'un scénario, ce qui signifie qu'il existe plusieurs objets frontières instanciés par la même classe dans le diagramme.
L'acteur d'un diagramme de séquence de niveau analyse interagit avec un objet frontière. Un message de navigation est envoyé par l'acteur à l'objet frontière.
Conceptions initiales de classe frontière
Une classe frontière peut être transférée dans une classe page client.
Si la classe frontière implique la saisie d'informations, vous l'associerez traditionnellement avec un formulaire (ou un formulaire web) par le biais d'une agrégation. Un formulaire peut être modélisé sous la forme d'une classe imbriquée dans la page client car son cycle de vie entier est régi par cette page client. Les formulaires ont toujours une relation de soumission avec la page serveur qui traite les valeurs qu'ils contiennent, et une nouvelle page client est finalement renvoyée.
Si l'interface client exige un comportement dynamique sur le client, le moyen le plus simple d'y parvenir est d'utiliser un langage HTML dynamique sur le client. Dans le modèle de conception, ceci apparaît habituellement sous la forme d'opérations sur la page client. Les opérations sur la page client établissent directement une correspondance vers les fonctions du script java. Les attributs d'une page java correspondent directement aux variables de la page, à l'échelle de cette page. Les gestionnaires d'événements HTML dynamiques sont capturés sous la forme de valeurs marquées.
Si l'interface client dispose d'un comportement très sophistiqué, vous pourrez envisager d'associer un applet à la classe frontière, en utilisant une agrégation.
Si votre architecture repose sur un système distribué d'objets (comme RMI, IIOP ou DCOM), alors la page client peut fournir les références des interfaces aux composants qui communiquent directement avec le serveur avec RMI, IIOP ou DCOM, et en circonvenant HTTP. Ces types sont habituellement stéréotypés de la façon suivante : <<rmi>>, <<iiop>>, ou
<<dcom>> afin d'indiquer au concepteur toutes les zones génératrices de trafic sur le réseau pouvant devenir des goulets d'étranglement potentiels.
Conceptions initiales de classe d'entité
Lors de la conception d'une application Web, la seule chose qui diffère à propos des classes d'entité, si l'objet se trouve dans le cadre de la page client, c'est que l'objet entité correspondra à un objet script java.
Conceptions initiales des classe contrôleur
Les classes contrôle correspondent à des pages serveur. Les contrôleurs expriment et coordonnent la logique de l'entreprise et coordonnent les autres logiques. Ils se trouvent généralement sur le serveur. De nombreux objets contrôleur sont chargés de la construction de pages client (leurs produits sont généralement en HTML). Les objets contrôleur peuvent interagir avec les ressources côté serveur, comme les bases de données, les composants de la couche intermédiaire, les moniteurs transactionnels et ainsi de suite.
Les classes contrôleur correspondent généralement à des pages Web scriptées côté serveur (pages Active Server Pages, pages de serveur java).
|