Chapitre 7 Dveloppement du modle statique

Objectifs du chapitre

Ce chapitre va nous permettre d'illustrer les principales constructions du diagramme de classes UML durant l'tape d'analyse, Le diagramme de classes a toujours t le diagramme le plus important dans toutes les mthodes orientes objet. C'est galement celui qui contient !a plus grande gamme de notations et de variantes. UML a russi unifier le vocabulaire et les concepts sans perdre la richesse et les apports des diffrentes mthodes existantes.

Quand intervient le dveloppement du modle statique ?

Le dveloppement du modle statique constitue la deuxime activit de l'tape d'analyse. Elle se situe sur la branche gauche du cycle en Y et succde au dcoupage en catgories. Les diagrammes de classes tablis sommairement dans les DCP (diagrammes des classes participantes du chapitre 4), puis rorganiss lors du dcoupage en catgories (chapitre 6), vont tre dtaills, complts, et optimiss. Il s'agit d'une activit itrative, fortement couple avec la modlisation dynamique, dcrite au chapitre suivant. Pour les besoins du livre, nous avons prsent ces deux activits de faon squentielle, mais dans la ralit elles sont effectues quasiment en parallle.

134
UML en action

Figure 7-1. : Situation du dveloppement du modle statique dans le 2TUP

lments mis en jeu

Classe, responsabilit, Association, multiplicit, agrgation, composition, Attribut, attribut driv, attribut de classe, Classe d'association, qualificatif, Opration, opration de classe,
Classification, gnralisation, spcialisation,

Classe abstraite, principe de substitution, gnralisation multiple, Contrainte.

Affiner les classes

Les classes identifies lors de l'tude des cas d'utilisation (chapitre4), puis rparties dans les catgories (chapitre 6), sont simplement des classes candidates pour l'analyse objet. Il convient dsormais de les examiner de manire dtaille, d'en liminer certaines, ou au contraire d'en ajouter d'autres. Cette activit de validation est itrative ; raffinement des associations, ainsi que l'ajout des attributs ei des oprations, vont nous fournir de prcieuses informations. On peut cependant ds prsent rpertorier quelques principes gnraux pour liminer les classes qui n'en sont pas : classes redondantes : elles reprsentent le mme concept ;

Chapitre 7 Dveloppe ment du modle statique

135

Exemple SIVEx : si plusieurs analystes avaient travaill en parallle, on

aurait pu trouver les classes redondantes Vhicule et Camion, EnCoursDeCmd et SuiviCommande. IncidentMission et Alarme, etc.

classes vagues : elles ne correspondent pas des concepts que l'on peut exprimer par des classes. Ainsi, des termes tels que organisation des rseaux ou configuration des tapes sont trop gnraux et ne sont pas suffisamment prcis pour justifier la cration d'une classe ; classes la place d'attribut : elles expriment des concepts quantifiables ; Exemple SIVEx : pas de classe Poids, ce n'est qu'un attribut de Colis. classes la place d'un rle : elles expriment un rle dans une association particulire ;

Exemple SIVEx : dans la catgorie Ressources, la notion d'agence principale est reprsente par un rle d'association entre les classes ZoneRedistribution et Agence, et non par une classe part entire. classes reprsentant des acteurs : souvent utiles, mais uniquement lorsque le systme gre des informations sur l'acteur ; Exemple SIVEx : dans la catgorie Ressources, on ne trouve pas la classe Rpartiteur, contrairement aux autres acteurs. En effet, elle semble inutile, alors qu'OperateurQuai est utilise dans Colis, Rceptionniste dans Commandes, et Chauffeur dans Missions. classes de conception : elles introduisent trop tt des choix de ralisation. Ainsi, le concept fichier client n'a pas de sens dans le mtier, bien qu'intgr au jargon des utilisateurs ; -- classes reprsentant des groupes d'objets : elles sont inutiles, car implicites dans les multiplicits des associations, et font souvent rfrence des choix de conception.
Exemple SIVEx : on ne trouve pas dans le modle d'analyse de classe ListeCommandes ou ListeColis. Ces groupes d'objets sont implicites dans les associations entre Mission et Commande, et entre Commande et Colis.

De la mme faon, on peut indiquer quelques principes afin d'optimiser le modle structurel. Cela conduit tantt ajouter des classes manquantes, tantt subdiviser une classe existante en plusieurs : une classe ne doit pas avoir trop de responsabilits, il en rsultera sinon un nombre lev d'associations, d'attributs ou d'oprations. 11 est donc prfrable de la dcouper en ensembles plus petits et homognes en termes de responsabilits et de cycles de vie ; ne pas confondre objet physique et objet logique : autrement dit une entit et sa description. Ces deux principes sont illustrs dans l'tude de cas ci-aprs.

136

UML en action

ETUDE DE CAS : SEPARATION DE RESPONSABILITES

Dans la catgorie Commandes, nous avons isol une classe EnCoursDeCmd laquelle la classe Commande dlgue le suivi rel des dates d'enlvement et de livraison, ainsi que des dates de dpart et d'arrive dans les agences Nous sommes amens de la mme faon sparer le SuiviMission de la Mission, pour traiter tous les aspects lis au suivi en temps rel des vnements, Nous avons identifi au chapitre 4 (voir la figure 4-16) l'association dcrit entre Commande et Cote. En fait, une commande contient initialement la description de chacun des colis prvus, puis au cours d'une mission, chaque colis rel est identit et rattach une commande. Il faut donc distinguer deux classes diffrentes : DescriptionColis et Colis, qui ne comportent ni les mmes responsabilits, ni les mmes tats Notez galement que les multiplicits des associations ont t affines, pour que les cas dgrads, tels que la possibilit d'garer des colis, soient pris en compte

est rattach

Figure 7-2. : Modification de la relation entre Commande et Colis

Affiner les associations

l'instar des classes, les associations identifies jusqu' prsent ne forment qu'une bauche de structure statique. Il convient prsent de les valider, les prciser, en liminer, el en ajouter. L encore, il s'agit d'une activit itrative, qui sera complte grce l'identification des attributs. N'oublions pas qu'en analyse, les associations reprsentent des relations conceptuelles entre les classes. On peut galement dire qu'elles impliquent des responsabilits en termes de navigation. La navigation dans un modle statique reprsente la capacit obtenir des informations en parcourant tes associations entre les classes. L'exemple de la figure 7-2 indique que l'on peut demander une Commande quelles sont les DescriptionColis qui lui sont rattaches et rciproquement toute DescriptionColis quelle Commande elle est rattache. On peut donc considrer les associations comme porteuses d'une partie fondamentale de la structure statique des classes, en ce sens qu'il est de la nature d'une Commande d'tre relie des DescriptionColis.

Chapitre 7 Dveloppement du modle statique

137

En revanche, ces responsabilits ne prjugent pas de la structure des classes en conception. C'est en effet durant l'tape de conception dtaille (voir chapitre 11), qu'on effectue les choix d'implmentation du modle structurel, avec des objectifs d'optimisation et de modularit. Voici deux principes gnraux qui permettent d'liminer les associations incorrectes ou inutiles : associations non structurelles : elles expriment des relations dynamiques, c'est--dire des liens instantans entre objets. Les liens structurels se caractrisent par une certaine dure et une certaine stabilit ; associations redondantes ; elles peuvent tre retrouves par navigation grce aux associations existantes.

ETUDE DE CAS : ASSOCIATIONS A ELIMINER

II n'incombe pas une Commande de savoir quel Rpartiteur est en train de la slectionner pour l'affecter une Mission II s'agit d'une relation purement dynamique entre un acteur Repartiteur et un objet Commande L'association ne doit donc pas figurer dans le modle statique, mais tre exprime par une construction dynamique, comme l'envoi de messages.

Figure 7-3. : Association errone entre Commande et Rpartiteur

Un EnCoursDeCmd concerne une Commande, une Commande concerne un Client II serait inutile d'ajouter une association entre EnCoursDeCmd et Client pour prciser qu'un EnCoursDeCmd concerne un et un seul Client. En effet, implicitement, un parcours enchanant plusieurs associations combine les multiplicits successives, en multipliant respectivement entre elles les bornes minimales et les bornes maximales. En voici un exemple :
de EnCoursDeCmd Client en passant par Commande, la multiplicit s'obtient par : ( 1 . . 1 ) x

(1..1) = 1..1;
dans l'autre sens, de Client EnCoursDeCmd en passant par Commande, la multiplicit s'obtient par . (0..*)x(0..1) = 0..*. L'association concerne est donc totalement redondante avec les deux autres associations et

peut tre supprime sans consquence

138
o

UML en action

Figure 7-4. : Association redondante entre EnCoursDeCmd et Client

INFLUENCES DES MULTIPLICITS SUR LES ASSOCIATIONS

La multiplicit exprime sur les associations doit tre vraie tous les moments du cycle de vie des instances. Elle induit donc des contraintes sur le processus d'instanciation des classes. Dans l'exemple de la figure 7-4, on ne peut pas instancier d'EnCoursDeCmd sans lui assigner une instance de Commande. En revanche, pour instancier une Commande, il n'est videmment pas obligatoire de lui associer ds le dpart un EnCoursDeCmd... La diffrence entre 0..1 et 1 est par consquent plus forte qu'il n'y parat.

De mme, la smantique des classes associes et de l'association elle-mme peut subtilement influencer les multiplicits. Une illustration en est donne par les trois exemples suivants, tous corrects1, mais ayant des significations diffrentes.

Figure 7-5. : Exemples de multiplicits diffrentes pour des associations voisines

Un Mari est forcment mari une et une seule pouse, dans le contexte de la loi franaise actuelle. En revanche, si les concepts plus gnraux d'Homme et de Femme nous intressent indpendamment des liens du mariage, l'association ; devient optionnelle ; Mari et Epouse deviennent alors des rles. Vous remarquerez au passage combien la diffrence entre classe et rle est tnue, dans la mesure o elle dpend fortement du contexte du problme. Si enfin, on veut conserver l'historique des liens de mariage, la multiplicit devient non borne.
I .Attention, prcisons que ces diagrammes sont corrects dans le conteste de la loi franaise en ce dbut d'anne 2004 ! Ils excluent en effet la polygamie ainsi que le mariage homosexuel...

Chapitre 7 Dveloppement du modle statique

139

Affiner les associations consiste galement utiliser deux notions complmentaires fournies par UML ; l'agrgation et la composition. Une association entre deux classes reprsente par dfaut une relation structurelle symtrique entre entits de mme importance. Mais UML fournit deux notions qui permettent d'affiner la dfinition conceptuelle d'une association. Il s'agit de l'agrgation et de la composition qui ajoutent l'association le sens d'une relation d'lments ensemble. Si l'une des classes joue le rle d'ensemble compos d'instances de l'autre classe, utilisez l'agrgation. Une agrgation n'est plus smantiquement symtrique, puisqu'elle privilgie l'une des deux classes en l'levant au rang de conteneur. L'agrgation garde cependant les proprits d'une association et n'influe ni sur l'expression des multiplicits, ni sur la navigabilit, ni sur le cycle de vie des instances relies. Par consquent, il est possible de partager l'agrgation : une partie peut appartenir simultanment plusieurs agrgats. La composition est en revanche une variante d'agrgation qui influe sur la structure des instances qu'elle relie. Avec une composition, nous introduisons
ainsi les deux caractristiques suivantes :

la composition n'est pas partageable : un objet ne peut appartenir qu' un seul composite la fois ; le cycle de vie des parties est fortement li celui du composite : la destruction du composite entrane en particulier la destruction de ses parties.

ETUDE DE CAS : AGREGATION ET COMPOSITION

Figure 7-6.: Exemples d'agrgation et de composition autour de la classe Agence

140

UML en action

Dans cet exemple, toutes les associations ont la smantique de l'agrgation. Mais vrifient-elles en plus les critres de la composition ? Le premier critre (non partageable) est bien vrifi par toutes les agrgations sauf celle entre ZoneRedistribution et Agence. En revanche, seule l'agrgation entre Agence et Quai correspond au critre d'imbrication du cycle de vie entre composite et composants. Par exemple, la suppression d'une Agence n'entrane pas celle de ses vhicules et chauffeurs, qui vont tre raffects une autre agence. Si l'on reprend l'exemple de la figure 7-2, on peut galement distinguer une composition et une agrgation, en fonction du critre qui consiste lier les cycles de vie des parties leur ensemble : la suppression d'une commande implique celle de ses descriptions de colis.

Agrgation

Figure 7-7. : Exemples d'agrgation et de composition dans la catgorie Commandes

Affiner les associations, c'est aussi identifier leurs rgles de gestion. UML propose un certain nombre de proprits standard applicables aux associations: on peut spcifier que les objets une extrmit de l'association doivent tre ordonns avec la proprit { ordered} ; on peut galement prciser qu'un lien ne peut plus tre modifi ni dtruit avec la proprit { frozen} . Dans le mme esprit, la proprit { addOnly} signifie que de nouveaux liens peuvent tre ajouts depuis un objet de l'autre ct de l'association, mais non supprims'. Il est noter que la proprit { ordered} n'induit pas la faon dont les objets vont tre ordonns : numro, ordre alphabtique, etc. Il s'agit en gnral d'un choix de conception.

1.Mme si les contraintes prdfinies ! frozen} et {addOnly} semblent avoir disparu du standard UML 2.0, nous continuerons les utiliser pour leur valeur ajoute.

Chapitre 7 Dveloppement du modle statique

141

ETUDE DE CAS : PROPRIETES DES ASSOCIATIONS DES CATE6ORIES MISSIONS ET COMPTABILIT

{ordered)

0.1

figure 7-8. : Associations ordonnes dans la catgorie Missions

Les associations entre IncidentMission, EvenementMission et Mission ne sont pas seulement ordonnes. En effet, les liens ne pouvant plus tre modifis ni dtruits du ct Mission, ils s'ajoutent obligatoirement de l'autre ct.

Figure 7-9.. Autres proprits des associations de la catgorie Missions Dans la catgorie Comptabilit, une rflexion plus pousse sur les multiplicits, les proprits et la navigabilit permet d'liminer une association redondante et supprime de (a sorte la dpendance

entre tes catgories Comptabilit & Clients.

142

UML en action

tienne lieu
' -{orOerea, addOnly}

Figure 7-10. Proprits des associations de la catgorie Comptabilit

Ajouter les attributs

Un attribut est une proprit nomme d'une classe qui dcrit un domaine de valeurs possibles partag par tous les objets de la classe. tout instant, chaque objet d'une classe porte une valeur spcifique pour chaque attribut de sa classe. Dans un modle d'analyse, vous conserverez uniquement comme attributs les proprits simples des classes que le systme doit mmoriser et utiliser. Exemples SIVEx : un Vhicule a un n d'immatriculation et un kilomtrage ;
un Chauffeur et un Client ont un nom ;

une Commande a une rfrence, un cot estim et un type de service ; un Colis a un poids.

e
tude

DIFFRENCE ENTRE CLASSE ET ATTRIBUT

En analyse, un concept est une entit utilise par l'expert du domaine dans le ; cadre de son mtier ou de l'application. Tout concept doit tre modlis par ; une classe car il est implicitement porteur de proprits, assume des responsabilits fonctionnelles dans le systme et parcourt ventuellement des tats diffrents. L'attribut n'est qu'une des proprits d'une classe se caractrisant par une quantit mesurable, comme le poids du Colis, ou la possibilit d'tre valoris par une ou plusieurs donnes, par exemple le nom d'un Client.

Chapitre 7 Dveloppement du modle statique

143

I Notez encore qu'un attribut peut tre valoris par une structure de donnes ou bien qu'il peut tre multiple au sein d'une classe. Contrairement ce que twfe nous rencontrons souvent dans les projets, ces caractristiques ne transforment pas pour autant un attribut en classe. Dans l'exemple ci-dessous, l'analyste comprend qu'un Point n'est pas manipul par l'utilisateur et que l'on : peut valoriser un Point par la donne de deux coordonnes dans son modle. II transforme donc la classe Point en attribut mulliple dans les diffrentes classes gomtriques. Remarquez comment le diagramme s'en trouve allg.

Figure 7-11. : Attribut ou classe ? Nous allons illustrer la diffrence entre attribut et classe sur l'tude de cas, ainsi que trois erreurs frquentes de modlisation lies au concept d'attribut.

ETUDE DE CAS : ATTRIBUTS ERRONES OU REDONDANTS

Le Compte d'un Client n'est pas un simple nombre, c'est un concept part entire comportant luimme plusieurs attributs ; il peut tre bloqu ou dbloqu, ce qui implique des tats et des responsabilits.

figure 7-12. : Exemple d'attribut abusif Un autre dfaut frquent consiste dcrire correctement l'association entre les deux classes, mais ajouter tout de mme un attribut redondant dans l'une des classes Par exemple, la classe Commande n'a pas besoin d'un attribut nomClient, puisque chaque Commande concerne un Client qui a dj un nom

144
Attribut redondant

UML en action

Figure 7-13. : Attribut redondant avec une association

Le cas suivant est un peu plus complexe, car la correspondance n'esl pas directe Cependant, l encore, l'attribut est inutile en analyse, car il peut tre dduit de la navigation de l'association. Le nombre de colis d'une Commande s'obtient simplement en comptant le nombre d'objets DescriptionColis lis l'objet Commande correspondant.

Figure 7-14. : Attribut inutile car implicite d'aprs l'association

Le cas contraire peut galement arriver une des classes candidates s'avre reprsenter un - type simple , et non un concept du domaine C'est le cas dans la catgorie Rseau, o la classe Commune est superflue. En effet, elle ne sert qu' stocker une structure de donnes reprsentant la position d'un Site Comme dans l'exemple de la figure 7-11. on peut simplifier le modle en la transformant en attribut. Notez aussi la multiplicit et la navigabilit de l'association : le fait que Commune ne soit pas tenue de connatre ses Sites est un argument qui joue en faveur de sa suppression

Figure 7-15.. Remplacement d'une classe candidate par un attribut

DENOMINATION DES ASSOCIATIONS PAR LES ROLES

La diffrence subtile entre les concepts d'attribut et de classe se retrouve galement dans la notion de rle d'une extrmit d'association.
lude

Chapitre 7 Dveloppement du modle statique

145

Revenons sur les deux faons possibles de nommer les associations. La premire consiste utiliser un groupe verbal, afin que l'association puisse tre lue comme une phrase. C'est ainsi que procdaient les mthodes traditionnelles de modlisation de donnes. Cette mthode prsente un inconvnient : le sens de lecture du verbe n'est pas forcment le sens naturel (de gauche droite ou de haut en bas) aprs plusieurs remaniements de diagramme. Cependant, en analyse, c'est souvent la technique la plus simple mettre en uvre. La deuxime consiste nommer le rle que joue chacune des classes dans son association avec l'autre. Ce rle reprsente une sorte d'attribut complexe de la classe distante, il est donc dcrit par un substantif. L'inconvnient de la mthode prcdente est ainsi rsolu, puisque les noms de rles restent bien accrochs leur extrmit d'association, mme si on les dplace graphiquement. De plus, le substantif a de grandes chances d'tre utilis lors de la gnration de code (voir le chapitre 11 sur la conception dtaille).

Figure 7-16. : Exemples de rles d'association II est noter que les noms de rles sont obligatoires pour les associations qui ' bouclent sur une classe, comme celle de la classe Site sur la figure prcdente Toutefois, il faut rester pragmatique : ne nommez les associations que si le nom apporte une information significative pour le lecteur. Inutile de prciser est reli , est associ ou de recopier le nom de la classe comme nom de rle ! Certaines associations sont videntes ; par ailleurs n'oubliez pas que l'agrgation et la composition signifient dj quelque chose par elles-mmes.
DISTINGUEZ LES ATTRIBUTS DRIVES !

Conseil

Un attribut driv est un attribut intressant pour l'analyste, mais redondant, car sa valeur peut tre dduite d'autres informations disponibles pour la classe concerne. UML permet la fois de le citer en tant qu'attribut, d'indiquer au lecteur du modle son caractre redondant grce au / et enfin d'exprimer la contrainte associe.

146

UML en action

ETUDE DE CAS : ATTRIBUTS DERIVES

Le cas le plus simple esl celui d un attribut driv d'un autre attribut de la mme classe. Par exemple, l'ge d'un Chauffeur est driv de sa date de naissance.

Figure 7-17. : Attribut driv et contrainte

En analyse, un attribut driv indique seulement une contrainte entre deux proprits, un invariant, comme le montre l'exemple prcdent. Il ne prcise pas encore ce qui doit tre calcul par rapport ce qui doit tre stock : ce sera un choix de conception. Un attribut driv peut aussi tre dduit de faon plus complexe. Par exemple, le poids estim d'une Commande est gal la somme des poids estims de ses descriptions de colis.

Contraints

Figure 7-18. : Autre exemple d'attribut driv

DISTTN6UEZ LES ATTRIBUTS DE CLASSE !

Conseil

Par dfaut, un attribut a une porte d'instance : chaque objet de la classe possde sa propre valeur pour la proprit. Dans certains cas plus rares, l'attribut peut avoir une porte de classe : il existe alors une seule valeur commune de la proprit pour toutes les instances de la classe. On parle dans ce cas d'attribut de classe1, et on le souligne pour le distinguer des attributs d'instance.
l.La plupart des outils de modlisation proposent plutt une case cocher static . d'aprs le mot-cl correspondant en Java. C++ ou C#

Chapitre 7 dveloppement du modle statique

147

ETUDE DE CAS : ATTRIBUT DE CLASSE

Figure 7-19. : Attribut de classe

Les factures sont transmises en fin de journe au module CO de SAP : la classe TransmissionComptable comporte deux attributs principaux une date et une heure de transmission effective. On souhaite suivre les carts de transmission relle par rapport a l'heure planifie, soit 22 h tous les soirs. Il suffit pour cela d'ajouter un attribut de classe heurePlanifiee, dont la valeur est identique pour tous les objets de la classe, et un attribut driv cart.

N'UTILISEZ PAS LA NOTATION COMPLETE DE L'ATTRIBUT EN ANALYSE !

0
Ne pas faire

Dans les diagrammes prcdents, nous avons simplement indiqu le nom des attributs. C'est gnralement suffisant pour le lecteur d'un modle d'analyse. Il sait parfaitement ce qu'est une date, unpoidsEstime, ou un coutEstime. La syntaxe complte d'un attribut en UML est videmment plus complexe :
[ visibilit] nom [ multiplicit] [{proprit}] [: type] [ = val_init]

Les dclarations optionnelles (entre [ ] ) sont utiles en conception ; certaines sont mme ncessaires. En revanche, en analyse, nous vous conseillons de ne les employer qu'avec parcimonie, le risque tant de faire prmaturment des choix de conception injustifis. En analyse, il faut rarement anticiper le type, la valeur initiale, ou la visibilit. Les seules dclarations intressantes sont les suivantes : la multiplicit permet de simplifier certains diagrammes, en exprimant de faon condense des structures de donnes, comme nous l'avons vu la figure 7-11; la valeur initiale est surtout utile pour les attributs de classe (comme dans l'exemple de la TransmissionComptable : heurePlanifiee = 22h) ;

148

UML en action

la proprit { f rozen} permet d'indiquer un attribut dont la valeur ne peut plus changer une fois que l'objet a t cr. Ne pas faire La proprit permet d'indiquer un attribut dont la valeur ne peut pas tre modifie par les objets clients.

Figure 7-20. : Utilisation avance de la syntaxe de l'attribut en analyse

Nous venons de voir comment affiner les classes, affiner les associations et ajouter les attributs. 11 arrive que l'on ait besoin d'effectuer les trois activits la fois : ajouter une classe pour dcrire des attributs ports par une association. En effet, une association entre deux classes peut elle-mme comporter des attributs. L'exemple type est celui de la relation employeur/employ entre Socit ei Personne. O placer les proprits de salaire, anciennet, etc.. si les multiplicits sont 0..* des deux cts de l'association ? Il faut valoriser ces attributs pour chaque couple d'instances (SocitPersonne), et pas simplement pour un objet. La solution en UML consiste modliser cette association comme une classe Emploi qui contient les proprits de l'association. Il existe alors une instance d'Emploi pour chaque lien entre objets des deux classes. La classe Emploi esl appele classe d'association ; il s'agit d'un lment de modlisation UML qui est la fois une classe et une association. Elle peut donc son tour tablir des relations avec d'autres classes, comme Emploi avec ConventionCollective.

Figure 7-21 : Exemple de classe d'association

Chapitre 7 Dveloppement du modle statique

149

La figure suivante prsente une instanciation possible du diagramme prcdent, dans lequel les objets El et E2 portent des valeurs diffrentes pour certains attributs. Nous ne les avons pas indiqus pour des raisons videntes de confidentialit :-).

Instance de classe d'association

Figure 7-22. : Exemples d'objets d'association

ETUDE DE CAS : CLASSE D'ASSOCIATION PARCOURS

Dans la catgorie Reseau, chaque Parcours dcrit en ralit une relation entre deux Sites (il en va de mme pour les Connexions entre Agences). Le modle se trouve amlior si l'on transforme Parcours et Connexion en classes d'associations.

Figure 7-23. : Exemple de classe d''association dans SIVEx

Notez que l'existence d'un objet Parcours est obligatoirement subordonne au lien entre deux objets Site. Cette relation de dominance entre Site et Parcours est plus clairement exprime par la deuxime solution celle o Parcours devient une classe d'association.

150

UML en action

Une association ne peut comprendre des proprits qu'en se transformant en classe d'association. En consquence, le nom de la classe d'association est galement celui de l'association. Vous pouvez nanmoins nommer galement les rles ports par les extrmits de cne association, comme la figure 7-23. Il peut arriver que vous vouliez dcrire les mmes proprits pour plusieurs associations. Dans ce cas, vous ne pouvez pas rutiliser une classe d'association en l'attachant d'autres associations, puisqu'elle est l'association elle-mme. Une solution peut consister dfinir une super-classe (gnralement abstraite) dont hriteront les diffrentes classes d'association, comme illustr la figure ci-aprs.

Figure 7-24. : Super-classe d'association

Dfinition

Parfois, un ou plusieurs attributs initialement affects une classe ne servent qu' prciser la dsignation d'objets par le biais d'une association.
QU'EST-CE QU'UN QUALIFICATIF ?

Un qualificatif est un attribut d'association dont les valeurs partitionnent la liste des objets relis par le biais d'une association. En d'autres termes, la connaissance d'un objet et d'une valeur de qualificatif permet de retrouver un ou plusieurs objets lis l'autre bout de l'association concerne. Le qualificatif affine donc l'accs une instance par navigation sur une association. Il ne s'applique videmment qu' une multiplicit suprieure 1 puisqu'on ne peut partitionner une liste compose d'un seul lment.
I .Ou qualifieur ? Il s'agit en effet d'une traduction du terme anglais qualifier ...

La dfinition du qualificatif n'est pas aise saisir sans exemple, nous en dveloppons ci-aprs diffrentes utilisations. Reprenons par exemple la relation employ-employeur de la figure 7-21. O placer l'attribut matricule ? premire vue, il s'agit d'une proprit de la classe Personne. Mais en fait, une personne possde un matricule pour chacun

Chapitre 7 Dveloppement du modle statique

151

de ses employeurs. Il s'agit donc plutt d'un attribut de l'association, que nous pouvons placer dans la classe Emploi. Poussons l'analyse encore un peu plus loin : quoi sert l'attribut matricule sinon rfrencer un employ au sein de son employeur? Il s'agit d'un identifiant relatif, dont la valeur permet d'accder une instance particulire de Personne, pour une Socit donne. C'est exactement la notion de qualificatif en UML. Il se reprsente graphiquement comme indiqu la figure ci-aprs, qui rcapitule les tapes de la transformation d'un attribut en attribut d'association, puis en qualificatif, avec la rduction de multiplicit qui s'ensuit.

Figure 7-25 : Exemple de qualificatif remplaant un attribut

Un objet Socit dot d'une valeur particulire du qualificatif matricule a accs un objet Personne au plus, car la multiplicit a t rduite 0..1 , II peut y avoir des numros de matricule inutiliss, d'o la limite infrieure 0.

ETUDE DE CAS ' QUALIFICATIFS

Une Agence contient des Quais et chaque Quai y est rfrenc par un numro. Ce numro reprsente un identifiant relatif une Agence particulire, et non un identifiant absolu du Quai. Dans un sens, numro n'est pas seulement un attribut de l'association. puisqu'il permet d'identifier de faon unique un Quai 'par rapport une Agence.

192

UML en action

Notez bien la modification de la multiplicit de l'autre cot du qualificatif. Pour une instance d'Agence el une valeur de numro, il existe au plus un Quai. Autrement dit. dans une agence donne, deux quais ne peuvent porter le mme numro. Attention cependant car mme si c'es! te cas le plus frquent, un qualificatif ne rduit pas systmatiquement ia multiplicit de 0..* -1 (ou - 0..1 ) Supposons que chaque Agence possde plusieurs parcs de vhicules Si l'on utilise le numro de parc comme qualificatif, la multiplicit du ct de la classe Vhicule reste 0..* -.

Figure 7-27. : Exemple de qualificatif ne rduisant pas la multiplicit

Ajouter les oprations (optionnel)

Une opration reprsente un service, un traitement qui peut tre demand n'importe quel objet de la classe. Une opration est l'abstraction de ce que vous pouvez raliser sur un objet, et elle est partage par tous les objets de la classe. Souvent, invoquer une opration sur un objet modifie son tat ou les valeurs de certains attributs, ou encore l'existence de certains liens avec d'autres objets. En analyse, il est possible d'identifier certaines oprations par analyse textuelle du cahier des charges et des riches de description des cas d'utilisation. Il faut chercher des verbes d'action, comme envoyer , valider , les verbes d'tat comme appartient ou concerne , se traduisant plutt par des associations.

Figure 7-28. : Exemples d'oprations identifies par analyse textuelle

Chapitre 7 Dveloppement du modle statique

153

Soyez toutefois vigilants dans la mesure o toutes les oprations identifies de cette faon ne sont pas pertinentes. Certains verbes ne traduisent pas des oprations mtier, mais plutt des traitements de l'IHM comme les oprations saisir et diter de l'exemple prcdent, qui ne seront pas conserves. D'autres verbes reprsentent des oprations implicites en analyse, qui ne seront donc pas indiques sur le diagramme de classes. Au prochain chapitre, nous verrons que la meilleure faon d'identifier les oprations consiste tudier la dynamique de l'application : les interactions entre les objets et les tats des classes en fournissent la matire premire.
NE REPERTORIEZ PAS LES OPERATIONS IMPLICITES EN ANALYSE !

Ht pas fort

Pour ne pas surcharger les diagrammes de classes, il est inutile de recenser certaines oprations implicites pour toutes les classes, comme : ta cration et la destruction d'instances : constructeur et destructeur en programmation objet ; la manipulation des attributs, savoir lecture et modification : accesseurs en programmation objet ; la cration et la destruction de liens, implicites d'aprs les associations, avec leurs multiplicits et leurs proprits ventuelles ; les parcours et les recherches sur les associations. Notez que cette recommandation s'applique souvent tout aussi bien en conception, puisque la plupart des outils UML du march sont capables d'ajouter automatiquement les oprations cites prcdemment. De mme, les oprations non mtier lies en particulier l'IHM ou au stockage physique seront ajoutes ultrieurement. Il n'est donc pas tonnant qu'une classe d'analyse ait rarement plus de quatre ou cinq oprations. Toutes les autres oprations, implicites ou non mtier, viendront s'ajouter en conception'.
! N'UTILISEZ PAS LA NOTATION COMPLETE <0 ^

Ne pal fort

Comme pour les attributs, le nom des oprations est suffisant pour le lecteur d'un modle d'analyse. Il comprend ce que signifient envoyer, bloquer, valider. Au mieux, il se rfrera au modle dynamique pour saisir le contexte : dans lequel l'opration est effectue (voir chapitre 8).

I .Depuis plusieurs annes, la tendance consiste reporter l'identification des oprations dans les classes l'tape de conception. De nombreux auteurs recommandent soit de ne lister en analyse que des responsabilits (et pas de figer l'interface de la classe) soit carrment de ne pas du tout s'occuper des oprations ! Voil la raison pour laquelle nous avons indiqu en dbut de chapitre que l'ajout des oprations dans le modle d'analyse est optionnel.

154

UML en action

La syntaxe complte d'une opration en UML est videmment plus complexe :

[visibilit] nom [ (liste_param)] [ : type_retour] [{proprit}]

Mais il est clair qu'en analyse, le nom de l'opration et un commentaire textuel suffisent. Toutes les autres informations ne seront utiles qu'en conception. Comme pour les attributs, une opration a une porte d'instance par dfaut : elle s'applique un objet de la classe. Certaines oprations ont une porte de classe, on parle alors d'opration de classe. Les deux exemples les plus courants d'oprations de classe sont : les oprations qui permettent de crer de nouvelles instances ; les oprations qui manipulent les attributs de classe. Or, d'aprs ce que nous avons dit prcdemment, ces types d'oprations sont implicites en analyse. On peut donc en conclure que les oprations de classe sont trs rarement utiles en phase d'analyse, en tout cas nettement moins que les attributs de classe.
ETUDE DE CAS : OPERATIONS DES CLASSES DE LA CATGORIE CLIENTS

Figure 7-29. : Oprations des classes de la catgorie Clients

Notez les deux seules oprations vraiment mtier de la classe Compte Toutes les autres seraient des oprations implicites de manipulation d'attributs Ces oprations font penser des changements d'tat Le modlisateur doit donc considrer l'opportunit de raliser un diagramme d'tats pour la classe Compte (voir chapitre suivant)

Chapitre 7 Dveloppement du modle statique

155

Optimiser avec la gnralisation

ce stade, il s'agit de dcouvrir les classes possdant des caractristiques communes : attributs, associations, oprations. Les proprits communes seront rassembles dans une super-classe, et les proprits spcifiques resteront dans les sous-classes.
ETUDE DE CAS : GENERALISATION DE LA CLASSE EVENEMENT MISSION

Reprenons l'exemple du suivi de mission (figure 7-8). Si nous ajoutons les attributs et les oprations et que nous extrayons la classe Su/vMission de la classe Mission existante (pour bien sparer les responsabilits), nous obtenons le diagramme suivant :

Figure 7-30. : IncideniMission et EvenementMission

II est clair que nous pouvons simplifier ce schma en considrant IncidentMission comme une sous-classe d'EvenementMission. En effet, toutes les proprits d'EvenementMission se retrouvent dans IncidentMission, et smantiquement un IncidentMission est bien une sorte d'EvenementMission. On obtient alors :

Figure 7-3T. : EvenementMission comme gnralisation d'IncidentMission

156

UML en action

On peut mme affiner plus avant en distinguant deux types d'incidents : les incidents de trajet (panne du vhicule, etc.) et les incidents d'tape (client absent, livraison refuse, etc.).

Figure 7-32. : Arbre de gnralisation d'EvenementMission Dans le diagramme prcdent, vous remarquez que la classe IncidentMission est en italique. En UML, cela signifie que cette classe est abstraite, c'est--dire qu'on ne peut pas l'instancier directement. Autrement dit, pour instancier la super-classe abstraite IncidentMission. il faut obligatoirement instancier une de ses sous-classes, qui sont pour leur part concrtes. Une super-classe n'est pas forcment abstraite Ainsi, la classe EvenementMission ne l'est pas, car il peut en exister des instances directes Sa sous-classe IncidentMission est en revanche abstraite, ce qui montre que la super-classe d'une classe abstraite peut tre concrte ! Nous avons dit qu'IncidentMission peut tre considre comme une sous-classe d'Evenemeni-Mission, puisque toutes les proprits d'EvenementMission valent galement pour IncidentMission, et qu'elle a des proprits spcifiques supplmentaires Une autre faon de l'exprimer consiste utiliser le principe de substitution de Liskov Partout o nous parlons d'EvenementMission (la super-classe). nous devons pouvoir lui substituer n'importe laquelle de ses sous-classes, sans que cela cause le moindre problme. Si nous crivons la phrase : - Un EvenementMisson concerne une et une seule Mission, il est dat et peut tre archiv -, nous pouvons remplacer EvenementMission par IncidentMission, IncidentTraiet, ou IncidentEtape, et la phrase doit rester vraie.

N'ABUSEZ PAS DE LA SENER A LIS A TTON/ SPECIALISATION !

On s'aperoit parfois, aprs avoir ajout les attributs et les oprations, que certaines sous-classes ont t distingues tort. En effet, elles ont les mmes proprits et les mmes comportements et peuvent tre facilement fusionnes.
Ne pas fort

CHapitre 7 Dveloppement du modle statique

157

CAS : AFFINEMENT ET GNRALISATIONS

Prenons les diffrentes sous-classes d'Utilisateur, que nous retrouvons dans plusieurs catgories. Si Chauffeur et Client ont bien des attributs et des associations propres, on peut se passer de Rceptionniste et OperateurQuai. C'est le cas galement pour tes sous-classes MissknEnlevement et MissionLivraison. qui ne prsentent aucune diffrence fondamentale il est donc souhaitable de les fusionner en une seule classe AfesnDe Tourne, en ajoutant simplement un attnbut nature pour pouvoir les distinguer. Nous conservons en revanche l'autre sous-classe MtssionTraction, car elle possde une association supplmentaire (avec Agence), ainsi que des rgles de gestion diffrentes

Figure 7-33. : Simplification de l'arbre de gnralisation de Mission Notez que la classe Mission est maintenant considre comme une classe abstraite. Pour la catgorie Ressources, nous avons spar le modle statique sur deux diagrammes de classes : un diagramme gnral sur les agences. puis le dtail concernant les vhicules et les chauffeurs. Nous n'avons pas encore envisag le fait qu'une ressource d'une agence peut tre provisoirement mise disposition d'une autre agence. Il en rsulte des associations supplmentaires par-

158

UML en action

tant d'Agence, et arrivant Vhicule et Chauffeur Pour factoriser toutes ces associations identiques, nous avons introduit une super-classe abstraite Ressource. Notez galement la classe d'association MiseADisposition Les dates de mise disposition des ressources d'une agence une autre sont typiquement valorises pour chaque couple (Agence, Ressource).

Figure 7-34. : Ressources : diagramme gnral de l'agence

La figure suivante prsente le dtail concernant les chauffeurs et les vhicules. On peut remarquer l'hritage multiple de la classe Chauffeur. En effet, tout chauffeur est un Utilisateur, mais aussi une Ressource Ds lors que le principe de substitution est respect, il n'y a pas de raison d'interdire la gnralisation multiple en analyse.

Figure 7-35. : Gnralisation multiple de la classe Chauffeur

Chapitre 7 Dveloppement du modle statique

159

Encore un petit effort !

Le modle statique doit rendre compte au final de toutes les rgles structurelles, II sera certes complt par le modle dynamique, mais doit tre exhaustif pour tout ce qui concerne les relations statiques et le contenu des classes. Il faut galement s'assurer de son homognit, de sa cohrence, et de sa modularit. A cet effet, il est ncessaire de vrifier si les responsabilits attribues aux classes sont cohrentes, homognes et pas trop nombreuses. Il arrive frquemment que l'on puisse amliorer encore le modle en introduisant des classes supplmentaires appeles mtaclasses, comme nous allons l'illustrer avec l'tude de cas.

ETUDE DE CAS : AJOUT DE LA ETACLASSE TYPE VEHICULE

Reprenons la liste des responsabilits de la classe Vhicule (cf chapitre 4) Nous pouvons la complter par la gestion du numro d'immatriculation et du kilomtrage, ainsi que la notion de qualification des chauffeurs suivant le type de vhicule. La traduction de chacune de ces responsabilits, sous forme d'attributs ou d'associations, est dtaille dans le schma suivant :

R3

Figure 7-36. : Traduction des responsabilits de la classe Vhicule

Si l'on regarde plus attentivement, on s'aperoit que les responsabilits R2 et R4 ne dpendent pas de chaque instance de Vhicule. En effet, les capacits d'un vhicule dpendent exclusivement de son type De mme, un chauffeur est qualifi pour un type de vhicule, et non pour un vhicule particulier. La bonne solution de modlisation consiste isoler cette notion de type de

160

UML en action

celle de vhicule, afin de mieux rpartir les responsabilits cet effet, nous allons crer une nouvelle classe, appele TypeVehicule, et modifier la rpartition des attributs et associations de la faon suivante :

Figure 7-37. : Sparation des responsabilits en ajoutant TypeVehicule

Vous pouvez noter que cette manire de procder est rutilisable quel que soit le contexte1. On identifie une classe XX qui possde de nombreuses responsabilits. Certaines ne sont pas propres chaque instance. On ajoute alors la classe TypeXX ou ModeleXX et on rpartit les attributs et associations sur les deux classes. On termine en reliant XX et TypeXX par une association * -1 , souvent unidirectionnelle vers TypeXX. La classe TypeXX est qualifie de mtaclasse, car elle contient des informations qui dcrivent la classe-XX".

Figure 7-38. : Schma gnrique rutilisable (paRem d'analyse).

1 .On peut parler dans ce cas de partent d'analyse (analysis pallern).

Chapitre 7 Dveloppement du modle statique

161

On nomme classiquement dlgation la technique consistant pour un objet dlguer une partie de ses responsabilits un autre objet li. Dernier avantage de cette solution : elle permet de lier de nombreuses instances de XX la mme instance de TypeXX, au lieu de rpter les valeurs communes des attributs att3 et att 4.

AJOUTEZ DES CONTRAINTES I

Conseil

Nous avons prcdemment voqu des proprits prdfinies en UML concernant les attributs et les associations. Il est parfois utile d'exprimer des Contraintes plus sophistiques entre plusieurs lments de modlisation. C'est le cas pour les attributs drivs : cela peut galement concerner les associations. On peut ainsi indiquer des contraintes d'inclusion ou d'exclusion entre associations, des contraintes de navigation ou des contraintes de drivation. i Attention cependant : on peut, si on abuse des contraintes, tre tent de combler des lacunes de modlisation par ce biais.

ETUDE DE CAS : AJOUT DE CONTRAINTES SUR LES ATTRIBUTS ET LES ASSOCIATIONS

Voici un exemple de contrainte d'inclusion entre associations :

pona pale

Figure 7-39. : Exemple de contrainte d'inclusion entre associations Nous avons dj signale un certain nombre de contraintes sur les attributs, telles que celles qui expriment la drivation des attributs drivs, comme indiqu aux figures 7-17.7-18, et 7-19. Le schma suivant traduit un autre exemple de contrainte entre attributs

162

UML en action

Figure 7-40. : Exemple de contrainte entre attributs Remarquez la notation pointe qui est utilise dans la contrainte de la ligure prcdente. En fait, elle fait partie d'une syntaxe plus tendue appele OCL et propose par UML. Le langage OCL (Object Constraint Language) fait en eftet partie prenante d'UML et permet d'exprimer des contraintes sous forme d'expressions boolennes qui doivent tre vrifies par le modle Mais son utilisation n'est absolument pas impose, et suivant l'objectif du modle, vous pouvez exprimer vos contraintes en texte libre, ou plus formellement en CL OCL est un langage expressions, sans effet de bord sur le systme modlis. Sans entrer dans les dtails, l'exemple suivant montre l'utilisation du langage OCL La contrainte que nous voulons exprimer formellement est la suivante. un colis est dans l'tat nominal s'il n'a pas donn lieu la moindre anomalie.

Figure 7-41. : Exemple de contrainte exprime en OCL

OCL dfinit plusieurs types de collections d'objets, ainsi que de nombreuses oprations de manipulation de ces collections. Set est un ensemble au sens mathmatique. L'expression self..anomalieColis retourne l'ensemble des objets AnomalieColis lis l'objet colis concern. L'opration prdfinie size permet de tester si l'ensemble est vide. Pour une prsentation approfondie d'OCL. le lecteur se reportera [Warmer 99].

Phases de ralisation du modle statique d'analyse

Le dveloppement du modle statique constitue la deuxime tape de la phase d'analyse. Les diagrammes de classes prliminaires obtenus lors du dcoupage en catgories sont dtaills, complts et optimiss.

Chapitre 7 Dveloppement du modle statique

163

II faut d'abord valider les classes et les associations candidates. Ce travail d'affinement est itratif: il ne faut pas hsiter modifier, ajouter ou mme Supprimer des classes et des associations, en se fondant sur la dfinition de leurs responsabilits. Sur les associations retenues, on prcise les multiplicits, les proprits, les contraintes, et l'on distingue les agrgations et les compositions. On ajoute ensuite les attributs, en distinguant les attributs drivs et les attributs de classe. Cela conduit frquemment identifier des classes d'association, et des qualificatifs. Une premire recherche d'oprations peut alors tre effectue ; elle sera complte lors de l'analyse dynamique. On optimise ensuite les diagrammes de classes en introduisanl des super-classes par gnralisation, tout en respectant le principe de substitution. La dmarche mise en uvre dans ce chapitre est synthtise par la figure suivante :
Diagrammes de classes optimiss

Cahier dts

Diagrammes des classes candidates

4. Ajouter le* oprations (optionnel)

fiches de description des cas d'utilisation

Diagrammes de elasses complts

Figure 7-42. : Dmarche d'laboration du modle statique