1

Concepts et Formalismes UML

www.thierrycros.net

2 __________________________________________________________________________ UML

2
Unified Modeling Language

2.1 Historique
Les concepts objet se diffusent au dbut des annes 90, en particulier grce au langage C++. Les mthodes simposent lentement tel point que OMT devient en quelques annes une rfrence. Lunification des formalismes qui se concrtise par la standardisation de UML en novembre 1997 provoque alors une certaine obsolescence des mthodes. Curieusement, UML est peru comme leur suite logique alors que sa finalit est essentiellement de remplacer les formalismes natifs par une notation standard. La portabilit des notations en est lenjeu.

Booch

Rumbaugh

Jacobson concevoir() concevoir()

uml : Language

OMG

concevoir() standardiser() 1997

Les 3 amigos ne sont pas les seuls concepteurs de UML

Figure 21 : Gense de UML

www.thierrycros.net

___________________________________________________ 3 Unified Modeling Language

Pourquoi percevoir UML comme une mthode ? UML offre certaines caractristiques attribues gnralement aux mthodes1 telles que Abstraction (UML repose sur le concept dobjet et dfinit de nombreux lments de modlisation dans son metamodle) Formalisme (UML propose un formalisme). Mais UML nest pas une mthode : Cycle de vie (organis en phases), Dmarches (UML propose simplement le concept de modle) sont absents. Par ailleurs, UML induit quelques micro-processus ou micro dmarches. Par exemple, une dmarche simplifie dobtention des cas dutilisation repose essentiellement sur la nature des concepts utiliss dans les diagrammes. 1. Obtenir les acteurs 2. Lister les cas dutilisation 3. Les dcrire. Cette procdure, bien que simpliste, peut donner lillusion dune mthode inhrente UML. Dans les faits, OMT (qui est probablement la mthode la plus utilise en France au milieu de la dcemnie) est effectivement mise en uvre sur de nombreux projets mais son avenir est plus que compromis. UML est conu et le Unified Process prend forme. Le Unified Process est dailleurs nommment cite dans les spcifications UML2.

2.2 Diagrammes UML

2.2.1 Modlisation des situations dutilisation
UML propose le diagramme de cas dutilisation. Un cas dutilisation est une situation dutilisation du systme (ou plus gnralement dun classifieur) dcrite en terme dinteractions. Les acteurs (lments externes) interagissent avec le systme. La description textuelle, le moyen dobtention des cas, de dcouverte des acteurs sont autant daspects non dcrits par le langage. UML fournit des relations entre cas. <<include>> joue exactement le rle de la directive #include du C++, un cas reprsente ainsi un ensemble dinteractions acteur(s)/systme. Pratiquement, cette

1 Les dfinitions formelles des termes mthode, mthodologie, dmarche nimpactent pas beaucoup le quotidien du dveloppeur. 2

OMG Unified Modeling Language Specification, Chapitre 4 : Standard Profiles

4 __________________________________________________________________________ UML

relation de dpendance strotype indique lutilisation systmatique dinteractions (dcrites dans le cas inclus) dans le cas origine de la dpendance. <<extend>> correspond une option en terme dinteractions. Le cas tendu existe en tant que tel sans lapport du cas source de lextension. Un ou plusieurs points dextension prcisent lendroit de linsertion. Le label de la relation dfinit la condition dextension. lhritage entre cas : le principe de substitution li cette relation entre classificateurs est ici lessence mme de la spcialisation.[TC1]

Transaction Cas abstrait.

include Consultation Connexion

extend Comptable

Modification

Figure 22 : Relations entre cas dutilisation

Les diagrammes de cas dutilisation offrent aussi la modlisation de procdures mtier. Ce sont alors des business use case ou cas dutilisation mtier. La distinction provient essentiellement du contexte : le systme modlis est lorganisation elle-mme.

Organisation
Business use case Commande

Client

Figure 23 : Exemple de cas dutilisation mtier

2.2.2 Modlisation de la dynamique dun systme

Les diagrammes dinteraction Collaboration Squence

www.thierrycros.net

___________________________________________________ 5 Unified Modeling Language

modlisent des scnarios, instances de cas dutilisation et plus gnralement toute suite de messages entre objets. Ces deux diagrammes sont dans un premier temps des diagrammes dobjet : ils reprsentent les objets en prsence dans une interaction. Les deux diagrammes visualisent aussi les messages changs. Le diagramme de squence met laccent (visuellement) sur le temps, autrement dit le squencement des messages. Au contraire, un diagramme de collaboration met en exergue les objets : cest plus spatial, par opposition laspect temporel du diagramme prcdent. Contrairement une ide reue, les diagrammes de collaboration sont plus adapts la modlisation dinteractions, de squencements, complexes. La numrotation lexicographique des messages offre un moyen sophistiqu de reprsentation. Par ailleurs, seuls les diagrammes de collaboration indiquent la nature des liens entre objets (connaissance dun objet destinataire dun message parce quil est local, global...). Les mthodes insistent plus ou moins sur lutilisation de ces diagrammes, en fonction des activits de dveloppement (analyse, conception en particulier). Les diagrammes dtat transition correspondent une synthse de la dynamique dun classificateur. Les diagrammes dactivit sont une variation des diagrammes dtat, focalise sur les activits dans les tats.

2.2.3 Modlisation de la structure dun systme

UML offre plusieurs diagrammes de modlisation de laspect statique du systme. Diagramme dobjet Diagramme de classes Diagramme de dploiement Diagramme de composants. Les diagrammes dobjet visualisent les objets qui collaborent un instant donn. Ils correspondent souvent la premire version dun diagramme de collaboration ou de squence.

entity eter param echo tango : Avion tc : TourDeControle

para

mete r

entity whisky bravo : Avion

Modlisation d'un scnario aspect structurel : objets en prsence

Figure 24 : Diagramme dobjets

Les diagrammes de classes sont au coeur de nombreuses modlisations. Ce sont trs certainement les plus utiliss dans la panoplie UML. Pourtant, ils ne reprsentent jamais que laspect structurel du modle, alors que lessence mme du systme est dynamique.

6 __________________________________________________________________________ UML

M ote ur

1..8 {self.altitude > sol.altitude } 1 1 TourDe Controle * +co-pilote Aeronef

+pilote Pilote

entity Avi on

Figure 25 : Elments de base dun diagramme de classes

Les nuds et composants sont des classificateurs particuliers qui rsident dans le monde des bits. Les formalismes graphiques sont apparents : ils sont bass sur un rectangle muni de dcorations spcifiques. Un noeud est reprsent par un cube, ce qui suggre le volume dune unit centrale, dun routeur, etc. A noter : les diagrammes de dploiement et composants, dits diagrammes dimplmentation, jouent aussi le rle de diagrammes dobjets (cas o les labels sont souligns) ou de classes.

www.thierrycros.net

___________________________________________________ 7 Unified Modeling Language

Wintel {disque = 10 Go, mmoire = 128 Mo, cran = 17"}

Main Frame

Serveur BdD Navigateu r X25 * Serveur rseau TCP/IP serveur web

Figure 26 : Diagramme de dploiement avec composants

Ce type de diagramme visualise des classificateurs de type nud et composant. En fonction du degr davancement de larchitecture, les diagrammes dimplmentation deviennent de plus en plus prcis. Les relations de communication entre nuds sont strotypes, ce qui indique le type de la liaison. Le dploiement ou une architecture de dveloppement, de test, peut tre reprsente par des diagrammes de nuds et de composants au sens objets et non plus classificateurs.

8 __________________________________________________________________________ UML

pcCompatbilit : Wintel

netscape.exe : Navigateur {version = 4.5}

Machines utilises pour le test de faisabilit

et he rn et

akhenaton : Serveur rseau {os = GNU/Linux}

apache : serveur w eb

Figure 27 : Diagrammes de dploiement : instances de nuds et composants

2.2.4 Autres diagrammes

Les neuf diagrammes proposs par UML couvrent lessentiel des besoins en modlisation. Toutefois, certains aspects ne sont pas traits dans ces diagrammes de base : volution dun lment dans les modles par exemple, ce qui correspond la relation de dpendance strotype <<refine>> ou <<trace>>. Dans ce cas, rien nempche la dfinition de diagrammes supplmentaires3, la contrainte tant le respect des concepts manipuls dans les formalismes.
boundary analyse::DemandeInfo

trace

conception::Formulaire

boundary est un strotype de classe d'analyse

Figure 28 : Exemple de diagramme supplmentaire

Voir par exemple Modlisation objet avec UML de Pierre-Alain Muller 2me dition page 149

www.thierrycros.net

___________________________________________________ 9 Unified Modeling Language

2.2.5 Relations entre lments

UML propose quatre relations. Association Hritage Dpendance Ralisation. Lassociation se dcline en communication (par exemple entre acteurs et cas dutilisation), agrgation, composition. Dun point de vue statique, elle correspond une relation logique entre lments. Dans une perspective plus dynamique, elle est vue comme un potentiel de communication, instanci en liens entre objets. Dans tous les cas, elle ne peut reprsenter directement une interaction. La distinction association / lien est fournie par la nature des lments relis (respectivement classificateur et instance). La relation dhritage entre deux lments est une spcialisation ou une extension. Une sous-classe spcialise la sur-classe en jouant ventuellement sur le polymorphisme de certaines oprations. Une sous-classe tend aussi les responsabilits dune sur-classe en ajoutant des oprations et/ou des attributs. La relation de dpendance est extrmement gnrale. De nombreux strotypes UML adaptent cette subordination. Elle signifie simplement : si la cible volue, la source est impacte, le contraire ntant pas ncessairement vrai. La ralisation, comme les autres relations, couvre plusieurs cas de figure. Elle correspond la mise en oeuvre ou implmentation. Cas typique : un composant ralise une interface. Ds lactivit danalyse, la ralisation permet de relier (par raffinage dune certaine manire) des lments de modlisation. La collaboration entre objets (et donc classes) danalyse est une ralisation dun cas dutilisation. Ces relations fondamentales ne sont pas exclusives. Une spcialisation par hritage est aussi une dpendance : lvolution de la sur-classe impacte les sous-classes. Les modlisations de systmes comportent souvent des ambiguts quil faut lever par la connaissance plus approfondie des lments. Un avion possde un moteur... ou bien un avion est-il un moteur spcialis (un moteur et beaucoup dlments tout autour) ?
N O T E Les relations entre lments sont quelquefois subtiles. Le choix entre hritage et dpendance de type <<binding>> (pour les classes paramtres) nest pas toujours vident. Un container dentier est-il un container spcialis ou bien un container gnr par binding (liaison) depuis une classe paramtre ? Ltude prcise des classes permet de statuer. Dans ce cas, les algorithmes des mthodes (comme insererElement() ) sont identiques quels que soient les lments insrs, au type prs des lments. Il sagit de binding.

2.3 Mcanismes communs

2.3.1 Etendre UML
Lun des points forts dUML est son adaptabilit. Les trois mcanismes

10 _________________________________________________________________________ UML

Strotype Contrainte Proprit forment une boite outil dextension du metamodle et des formalismes. Lextension dUML est la base de la modlisation de systmes non logiciels. En particulier, les strotypes appliqus aux relations de dpendance offrent de multiples possibilits. 2.3.1.1 Strotypes Ils permettent de crer de nouveaux types au sens lments de modlisation. Le Unified Process propose par exemple les trois strotypes <<boundary>> <<control>> <<entity>>. UML en tant que langage utilise intensivement ce mcanisme. De nombreuses relations entre lments de modlisation reposent sur les strotypes. Toutefois, les strotypes devraient tre manipuls avec prcaution. Au plus les lments sont strotyps, au plus les modles sloignent du standard UML. Dans cet ordre dide, les standard profiles sont un moyen terme : ils adaptent UML des situations classiques de modlisation et font partie de la spcification.
N O T E Pratiquement, comment grer les strotypes ? Le premier point prendre en compte est la relation entre le strotype et le metamodle UML. Un strotype est ncessairement attach une classe de base dans le metamodle. Le deuxime point est lensemble des strotypes qui doit tre rfrenc dans le projet, voire dans lorganisation. Un document des Strotypes applicables permet dviter des doublons entre autres problmes.

Un nouvel lment de modlisation peut tre reprsent par une icne spcifique. Ainsi, les diagrammes deviennent plus naturels.

:Serveur Web

pcComptabilit

:Mainframe

Figure 29 : Diagramme de dploiement avec strotypes

2.3.1.2 Contraintes et proprits Les strotypes enrichissent le mtamodle par ajout dlments. Les contraintes et proprits (ou valeurs marques, nommes) enrichissent les proprits des lments de modlisation.

www.thierrycros.net

__________________________________________________ 11 Unified Modeling Language

{self.altitude > sol.altitude}

La responsabilit de la classe peut tre visualise dans un quatrime compartiment

entity Avion {responsibility = substitut d'avion offre les comportements necessaires au vol, tat = draft, auteur = twam, version = 1.0} -altitude : <unspecified> = 0

Figure 210 : Contraintes et valeurs marques sur un lment de modlisation

N O T E Les ateliers de gnie logiciel offrent plus ou moins de possibilits : cration de strotypes dicnes, gestion des contraintes et valeurs marques des lments, etc. Un guide dutilisation de loutil, dfini en dbut de projet, permet dharmoniser les diagrammes.

2.3.2 Organiser
Organiser est essentiel. De mme que les fichiers dune machine sont regroups, structurs en arborescence de rpertoire, de mme les lments de modlisation sont organiss en paquetages. Un paquetage est une unit dorganisation. Pratiquement, il regroupe lments de modlisation et diagrammes UML. 2.3.2.1 Paquetage Un paquetage a un rle prdestin : organiser. Les rpertoires contiennent des fichiers de plusieurs types : traitement de texte, images, feuilles de calcul, sous-rpertoires, etc. Cet inventaire clectique est en harmonie avec une certaine rigueur dorganisation. La gestion dun projet, par exemple, se concrtise en terme de documents, de tableaux de cots, de sous-rpertoire par quipe de dveloppement, etc. Ainsi un rpertoire correctement gr contient malgr tout des fichiers de types diffrents. Plus prcisment, un paquetage contient Des lments de modlisation Des diagrammes Des sous-paquetages. La prcocit de la structuration en paquetages garantit une bonne organisation des modles. 2.3.2.2 Sous-systme Un sous-systme est un paquetage. Cest aussi un classificateur. Autrement dit, il peut tre instanciable. Contrairement au paquetage qui a pour objectif unique lorganisation, le soussystme reprsente aussi des macro objets du systme. La relation de composition relie les sous-systmes et les lments, physiques ou logiques, qui le constituent. De mme quune classe est intrinsquement compose partir de datatypes (entier, long), de mme un

12 _________________________________________________________________________ UML

sous-systme est compos de classes et plus gnralement dlments de modlisation. Cest la mme relation, mais un niveau diffrent.

Devis

-montant datatype C++ Data Types::double

Facture -montant : double

Figure 211 : Relations de composition entre classificateurs

La relation entre une classe et un datatype (souvent prdfini dans la mise en uvre) nest pas une relation de composition entre deux types abstraits. Elle est donc gnralement visualise sous forme dattribut. Toutefois, la nature des liens entre les lments est la mme dans le cas dune composition par valeur. Le sous-systme constitue un niveau organisationnel suprieur, do la notion de macroobjet.

IHM::Form ulaire subsystem IHM Winte l

Navigate u r

Figure 212 : Sous-systme et lments qui le composent

2.3.3 Annoter
De mme quun fichier source doit tre comment, un diagramme doit tre annot. Peut-on imaginer un fichier source sans commentaire ?4 Certains commentaires peuvent tre grs
4

Je crains que oui

www.thierrycros.net

__________________________________________________ 13 Unified Modeling Language

par un outil : auteur, version, date, etc. La difficult du bien commenter est relle : le commentaire est-il simplement un bruit ? Est-il adapt au lecteur ? Est-il obsolte ? Par ailleurs, les notes de UML pallient une mconnaissance du formalisme ou un manque de loutil.
requirement Les modifications doivent tre rpercutes sur tous les sites dans la journe titre Expression des besoins : modification

Modification

Comptable

Figure 213 : Notes strotypes

Certains situations se prtent particulirement des commentaires. Un diagramme dinteraction (squence, collaboration) modlise un scnario qui peut tre dcrit dans une note Une question en suspens est facilement injecte dans le diagramme sous forme de note Un guide de lecture du diagramme (pour bien comprendre, commencer par la classe Orbite et drouler les relations partir de l).

14 _________________________________________________________________________ UML

UNIFIED MODELING LANGUAGE ..........................................................................2 2.1 Historique .......................................................................................................................2 2.2 Diagrammes UML..........................................................................................................3
2.2.1 Modlisation des situations dutilisation.......................................................................................3 2.2.2 Modlisation de la dynamique dun systme ................................................................................4 2.2.3 Modlisation de la structure dun systme ....................................................................................5 2.2.4 Autres diagrammes .......................................................................................................................8 2.2.5 Relations entre lments ...............................................................................................................8

2.3 Mcanismes communs ...................................................................................................9

2.3.1 Etendre UML ................................................................................................................................9 2.3.2 Organiser ....................................................................................................................................11 2.3.3 Annoter .......................................................................................................................................12

www.thierrycros.net