Instructions: Concevoir des applications Web avec UML
Ces instructions approfondissent l'analyse de cas d'utilisation pour commencer la conception d'applications Web.
Relations
Eléments connexes
Description principale

Références

Les livres et documents suivants sont des références pour ces instructions :

Développement de l'analyse de cas d'utilisation

Ce qui diffère de ce que vous trouverez dans Tâche : Analyse de cas d'utilisation est que l'accent est mis sur les classes frontières et que leur but est plus singulier. Les objets de ces classes ont une durée de vie courte, chaque état du client (dans les pages Web)) doit être géré explicitement par des mécanismes particuliers. Par exemple, les pages Microsoft Active Server utilisent des "cookies" comme l'index d'une carte représentant l'état de tous les clients actifs sur le moment.

Lorsque vous lisez la spécification d'un cas d'utilisation, ce qui suit s'applique : 

  • Chaque mention de page Web se traduit par une classe frontière. 
  • Chaque mention d'un lien hypertexte se traduit par l'association d'une classe frontière avec une autre classe frontière ou avec une classe de contrôle. 
  • Les verbes ou les descriptions de processus se mappent généralement sur les classes de contrôle. 
  • Les noms se mappent sur les classes entité. 

La classe frontière, où la communication commence, s'adresse à une classe contrôleur. Le classe contrôleur ne répondra pas, en général, avec la même instance que cette classe frontière.

Utilisation des diagrammes d'interaction

Lors de l'analyse du cas d'utilisation, les scénarios peuvent être décrits à l'aide de diagrammes de séquence. Cela aide à confirmer l'existence d'objets d'analyses contre le scénario d'un cas d'utilisation. Si vous découvrez que des objets d'analyse ne participent à aucun de vos scénarios, ils sont suspects et ont besoin d'être réévalués. Si vous détaillez trop vos scénarios, vos diagrammes risquent de devenir trop grands et donc ingérables. Pour éviter cela, choisissez des scénarios courts et discrets, et n'utilisez que les objets frontière, contrôleur principal et entité.

N'oubliez pas que, dans les applications Web, les objets frontière ont une durée de vie courte. Une classe frontière peut cependant être instanciée plusieurs fois pendant l'exécution d'un scénario. Cela signifie que plusieurs objets frontière ont été instanciés de la même classe dans le diagramme.

Dans un diagramme de séquence du niveau d'analyse, l'acteur interagit avec un objet frontière. Un message de navigation est envoyé par l'acteur à l'objet frontière.

Création des classes de conception initiales

Créations initiales des classes frontière

Une classe frontière peut être mappée à une classe de page client.

Si la classe frontière contient des informations d'entrée, il faut l'associer à un formulaire (ou un formulaire Web) grâce à l'agrégation. Un formulaire peut être modélisé comme une classe imbriquée de la page client, puisque son cycle de vie est dirigé par la page client. Les formulaires ont toujours une relation de soumission à une page serveur, qui traite les valeurs du formulaire, donnant une nouvelle page client renvoyée.

Si l'interface utilisateur a besoin d'un comportement dynamique chez le client, la façon la plus simple de l'obtenir est d'utiliser un langage HTML dynamique chez le client. Dans le modèle de conception, cela apparaît généralement sous forme d'opérations sur la page client. Les opérations sur la page client se mappent directement sur les fonctions JavaScript. Les attributs de la page Java se mappent directement sur les variables sectorisées de la page. Les gestionnaires d'événements de langage HTML dynamique sont enregistrés en tant que valeurs marquées.

Si l'interface utilisateur a un comportement très sophistiqué, il faut envisager d'associer un applet à la classe frontière, en utilisant une agrégation.

Si votre architecture est basée sur un objet système réparti (comme une invocation RMI, un protocole IIOP, ou un modèle DCOM), la page client peut référencer les interfaces de composants qui communiquent directement avec le serveur en utilisant une invocation RMI, un protocole IIOP, un modèle DCOM, contournant le protocole HTTP. Ces types de relations sont généralement stéréotypées <<rmi>>, <<iiop>>, ou <<dcom>> pour indiquer au concepteur les zones dans lesquelles il y aura du trafic réseau, et qui sont donc potentiellement des goulots d'étranglement.

Créations initiales des classes entité

Lors de la conception d'une application Web, la seule chose qui diffère concernant les classes entité, si l'objet est dans la portée de la page client, est que l'objet entité va se mapper à un objet JavaScript.

Créations initiales des classes contrôleur

Les classes de contrôle se mappent sur les pages serveur. Les contrôleurs expriment et coordonnent la logique du métier et coordonnent les autres logiques. Ils sont généralement hébergés sur le serveur. Beaucoup d'objets contrôleurs s'occupent de la construction de pages client (ils transmettent du langage HTML comme leur sortie principale). Les objets contrôleurs peuvent interagir avec des ressources du côté serveur, comme des bases de données, des composants intermédiaires, des moniteurs de traitement transactionnel etc. 

Les classes contrôleur se mappent généralement sur des pages Web du côté serveur (pages Active Server et pages Java Server).