Hello

Disponible uniquement sur Etudier
  • Pages : 6 (1273 mots )
  • Téléchargement(s) : 0
  • Publié le : 27 mai 2011
Lire le document complet
Aperçu du document
Structuration en packages
Pour améliorer notre modèle, nous allons organiser les cas d’utilisation et les regrouper en ensembles fonctionnels cohérents. Pour ce faire, nous utilisons le concept général d’UML, le package.
Les acteurs ont également été regroupés dans un package séparé sur lequel s’appuient les deux packages de cas d’utilisation. L’organisation générale du modèledans un outil de modélisation est représentée sur la figure 3-7.
Le sigle UC pour use case est souvent utilisé pour raccourcir les noms de packages.
Affinement du modèle de cas d’utilisation
Après une nouvelle réunion d’expression des besoins avec le responsable du projet, nous sommes arrivés à la conclusion qu’il était nécessaire de distinguer deux profils d’internautes :
• leVisiteur, inconnu du site web, mais qui peut néanmoins recher- cher des ouvrages et gérer un panier ;
• leClient,déjàconnuparlesiteweb,quipeutseuleffectuerunecom- mande et en suivre l’état.
B.A.-BA Package
Le package est un mécanisme général de regrou- pement d’éléments en UML, qui peut être utilisé par exemple pour regrouper des cas d’utilisation, mais aussi des acteurs, des classes, etc.Figure 3–7
Organisation des cas d’utilisation et des acteurs en packages (avec l’outil Enterprise Architect)
© Groupe Eyrolles, 2005
45
3 – Spécification des exigences d’après les cas d’utilisation
Figure 3–8
Cas d’utilisation du Visiteur et du Client
B.A.-BA Acteur généralisé
À tout moment, le visiteur peut choisir de créer un compte, afin de devenir client. Le client aégalement la possibilité de modifier les infor- mations le concernant (adresse de facturation, adresses de livraison, adresse électronique, etc.) stockées par le site web.
Nous avions également oublié de mentionner l’important système externe de Paiement sÈcurisÈ, nécessaire au moment du paiement en ligne.
Le diagramme de cas d’utilisation des internautes devient donc tel que représenté sur lafigure 3-8.
Nous remarquons maintenant que les deux acteurs Client et Visiteur partagent deux cas d’utilisation : ils sont également acteurs principaux de Chercher des ouvrages et GÈrer son panier. Or, une bonne pratique consiste à identifier un seul acteur principal par cas d’utilisation. UML
Il arrive que deux acteurs, ou plus, présentent des similitudes dans leurs relations aux casd’utilisa- tion. On peut l’exprimer en créant un acteur géné- ralisé, éventuellement abstrait, qui modélise les aspects communs aux différents acteurs concrets. nous fournit la solution en permettant de créer un acteur généralisé Dans notre exemple, l’acteur Internaute est la
Internaute, dont Client et Visiteur seront des spécialisations. Le diagramme devient alors celui de la figure 3-9,avec un seul acteur
généralisation abstraite des rôles Visiteur et Client. Notez que le nom d’un acteur abstrait s’écrit en italique. principal par cas d’utilisation.
46
© Groupe Eyrolles, 2005
Cahier du programmeur UML 2
Figure 3–9
Cas d’utilisation des internautes
On pourrait relier les cas d’utilisation des internautes par des relations d’extension :
• La recherche d’ouvrages peutdonner lieu à leur mise dans le panier (et réciproquement !).
• Lagestiondupanierpeutdonnerlieuaupassaged’unecommande. • Lepassaged’unecommandepeutdonnerlieuàlagestionducompte
client (ajout d’une adresse, etc.).
De même, les différentes possibilités de recherche d’ouvrages seront modélisées plus finement par une relation de généralisation/spécialisation.
Enfin, l’authentification duclient est nécessaire au début du passage d’une commande, du suivi des commandes, ou de la modification des informations du compte.
Toutes ces relations entre cas d’utilisation, légales en UML, mais sou- vent mal utilisées et sources de confusion pour les experts métier, sont illustrées sur la figure 3-10.
Pensez-vous vraiment que le diagramme ainsi obtenu soit satisfaisant ? Non, même...
tracking img