Structuration en packages
Pour ame?liorer notre mode?le, nous allons organiser les cas d’utilisation et les regrouper en ensembles fonctionnels cohe?rents. Pour ce faire, nous utilisons le concept ge?ne?ral d’UML, le package.
Les acteurs ont e?galement e?te? regroupe?s dans un package se?pare? sur lequel s’appuient les deux packages de cas d’utilisation. L’organisation ge?ne?rale du mode?ledans un outil de mode?lisation est repre?sente?e sur la figure 3-7.
Le sigle UC pour use case est souvent utilise? pour raccourcir les noms de packages.
Affinement du mode?le de cas d’utilisation
Apre?s une nouvelle re?union d’expression des besoins avec le responsable du projet, nous sommes arrive?s a? la conclusion qu’il e?tait ne?cessaire de distinguer deux profils d’internautes :
• leVisiteur, inconnu du site web, mais qui peut ne?anmoins recher- cher des ouvrages et ge?rer un panier ;
• leClient,de?ja?connuparlesiteweb,quipeutseuleffectuerunecom- mande et en suivre l’e?tat.
B.A.-BA Package
Le package est un me?canisme ge?ne?ral de regrou- pement d’e?le?ments en UML, qui peut e?tre utilise? 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 – Spe?cification des exigences d’apre?s les cas d’utilisation
Figure 3–8
Cas d’utilisation du Visiteur et du Client
B.A.-BA Acteur ge?ne?ralise?
A? tout moment, le visiteur peut choisir de cre?er un compte, afin de devenir client. Le client ae?galement la possibilite? de modifier les infor- mations le concernant (adresse de facturation, adresses de livraison, adresse e?lectronique, etc.) stocke?es par le site web.
Nous avions e?galement oublie? de mentionner l’important syste?me externe de Paiement sE?curisE?, ne?cessaire au moment du paiement en ligne.
Le diagramme de cas d’utilisation des internautes devient donc tel que repre?sente? sur lafigure 3-8.
Nous remarquons maintenant que les deux acteurs Client et Visiteur partagent deux cas d’utilisation : ils sont e?galement acteurs principaux de Chercher des ouvrages et GE?rer son panier. Or, une bonne pratique consiste a? identifier un seul acteur principal par cas d’utilisation. UML
Il arrive que deux acteurs, ou plus, pre?sentent des similitudes dans leurs relations aux casd’utilisa- tion. On peut l’exprimer en cre?ant un acteur ge?ne?- ralise?, e?ventuellement abstrait, qui mode?lise les aspects communs aux diffe?rents acteurs concrets. nous fournit la solution en permettant de cre?er un acteur ge?ne?ralise? Dans notre exemple, l’acteur Internaute est la
Internaute, dont Client et Visiteur seront des spe?cialisations. Le diagramme devient alors celui de la figure 3-9,avec un seul acteur
ge?ne?ralisation abstraite des ro?les Visiteur et Client. Notez que le nom d’un acteur abstrait s’e?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 a? leur mise dans le panier (et re?ciproquement !).
• Lagestiondupanierpeutdonnerlieuaupassaged’unecommande. • Lepassaged’unecommandepeutdonnerlieua?lagestionducompte
client (ajout d’une adresse, etc.).
De me?me, les diffe?rentes possibilite?s de recherche d’ouvrages seront mode?lise?es plus finement par une relation de ge?ne?ralisation/spe?cialisation.
Enfin, l’authentification duclient est ne?cessaire au de?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, le?gales en UML, mais sou- vent mal utilise?es et sources de confusion pour les experts me?tier, sont illustre?es sur la figure 3-10.
Pensez-vous vraiment que le diagramme ainsi obtenu soit satisfaisant ? Non, me?me…