Chapitre 1

Mthode de dveloppement du
logiciel avec UML
Dans ce livre nous traitons la fois de modlisation et de spcication avec UML pour
dvelopper du logiciel. Dans cette introduction, nous positionnons le cours et la contribution
dans le large espace des mthodes de dveloppement du logiciel objets. Ce dernier reste le
support dimplantation de la majorit des applications dveloppes actuellement, y compris
dans la vision service actuelle.
Aprs un rapide rappel de ce quest le dveloppement du logiciel nous mettons en vidence
les composantes dune mthode de dveloppement avec UML, notamment les concepts, la
notation, le processus et les outils.
Les concepts et la notation UML sont examins en section 2. Nous ne dtaillons pas la
volumineuse notation mais dcorticons les principes majeurs. La structure des spcications
(les modles) est relativement complexe, elle est fonde sur la notation darchitecture. Nous
dtaillons ce point dans la section 2.4.
Le processus met en vidence les activits de dveloppement et leur enchanement. ce
niveau, la pratique est loin dtre unie. Ici aussi un expos exhaustif est rdhibitoire. Dans
la section 3, nous prsentons les principes, les grandes activits et les principales approches,
en insistant notamment sur le RUP et le 2TUP. Puis nous croisons activits et notation dans
la section 3.5 en indiquant quels diagrammes sont utiliss quelle tape. En eet, lutilisation
des notations varie en fonction des tapes du processus de dveloppement utilis. Pour ce faire
le processus est simpli et reste commun la plupart des mthodes objets
La section 4 propose des pointeurs sur des outils autour dUML (dessin, modlisation,
vrication, gnration de modles ou de codes) et quelques rfrences bibliographiques ou
webographiques cibles.

Le dveloppement du logiciel

Dvelopper cest passer de lide au code (exprimer, programmer, vrier) avec mthode
(dans le bon ordre, viter lanarchie, travailler en groupe) et qualit (modles corrects, ables,
volutifs. . .- processus ecace, rentable...).
Dans un dveloppement individuel, lanalyse peut tre lgre ou dans la tte , la
programmation incrmentale et itrative sur le test comme dans les mthodes agiles ou
XP (eXtreme Programming).
Lorsque le dveloppement grossit, on communique et collabore, on a donc besoin de
mettre en place une organisation (organiser et rpartir les tches, dnir les participants,
grer la communication et les normes dchange, suivre lavancement...).
La troisime dimension prend en compte le client. Aux lments prcdents on ajoute
une dimension cot (nancier, temporel, humain...) qui fait aussi intervenir une analyse

CHAPITRE 1. MTHODE DE DVELOPPEMENT DU LOGICIEL AVEC UML

de comptence et de performance (rentabilit). De nouvelles tapes sont ncessaires

dans la gestion du projet (opportunit, faisabilit, risques, dcisions) ainsi quune prise
en compte du rle du client, notamment pour la validation. De manire orthogonale,
on doit prvoir dans les projets lassurance qualit, lautomatisation... La qualit des
rsultats est lie dune part la satisfaction du client et dautre part la facilit
maintenir les applications. La qualit du processus se voit dans le respect des dlais et
des cots et donc dans sa rentabilit.
La quatrime dimension met en jeu le prestataire (SSII ou service interne) qui dveloppe ou assure la maintenance corrective ou volutive (TMA, tierce maintenance
applicative). Ses proccupations sont similaires celles du client, mais du point de vue
de la production : gestion des ressources humaines (carrires, formations...), gestion
commerciale (rentabiliser les produits sur plusieurs clients), rentabilit en rutilisant
tout ou partie de la la production, automatisation du codage...
Un projet informatique met donc en uvre des aspects techniques (mthode de dveloppement), organisationnels (gestion de projet) et mthodologiques (qualit). Il met contribution dirents acteurs avec des objectifs et des visions direntes. Lobjectif majeur est de
produire du logiciel de qualit, rationaliser le dveloppement, rentabiliser les investissements.
Le gnie logiciel vise rpondre ces besoins : mettre en uvre des moyens pour raliser
du logiciel de qualit en respectant des contraintes de cots. Le gnie logiciel est lart de
construire industriellement du logiciel en sappuyant notamment sur des outils intgrs,
de type AGL (Atelier de Gnie Logiciel). Une bonne rfrence ce sujet est [Pre10].
Nous classons les applications en trois catgories :
1. Les systmes dinformation (de gestion) sont caractriss par un stockage important dinformations et de nombreux traitements simples en consultation et mise
jour de ces informations e.g. achat par Internet, gestion adminsitratives.
2. Linformatique temps rel (automatismes, contrle de processus) se caractrise
par une ractivit trs forte du systme dinformation e.g. pilotage automatique
davion, surveillance de centrale nuclaires. Linterface entre le systme dinformation et son objet naturel (le processus) prend ici une grande importance
(capteurs, actionneures).
3. Le calcul scientique se caractrise par des calculs complexes et nombreux e.g. simulation, mto, imagerie, web smantique. Un critre important est lecacit
des traitements.
Nous estimons que ces trois catgories reprsentent, assez grossirement, les dirents
types de systmes dinformation que nous sommes susceptibles de modliser ici.
Dans cet ouvrage, nous considrons principalement les aspects techniques du projet informatique, la mthode de dveloppement. Ainsi que nous lavions dtaill dans le chapitre
1 de [AV01a], une mthode est la fois une philosophie dans lapproche des problmes, une
dmarche ou un l conducteur dans la rsolution, des outils daide et enn un formalisme ou
des normes. Prcisons ces volets dans le cas du dveloppement objet.
La philosophie est celle des objets, savoir un ensemble dacteurs qui collaborent pour
raliser les fonctionalits du systme. Le chapitre 6 du tome 2 [AV01b] dtaille ces
aspects de la conception objets.
Le formalisme est la norme UML, le standard adopt universellement. Nous en donnons les principes gnraux dans la section 2. UML inclut des notations pour les trois
catgories dapplication que nous avons mis en vidence.
Il ny a pas de dmarche explicite, mais des principes accepts : dveloppement est
itratif et incrmental, bas sur les cas dutilisation et larchitecture. Le processus uni

2. LA NOTATION UML

est une proposition de Rational (IBM) qui illustre bien cette dmarche [RJB99]. Nous
dtaillons les lments dun processus dans la section 3.
Les outils couvrent une large gamme de produits, du logiciel de dessin comme Visio
lAGL complet permettant le round trip (lien troit entre le code et son modle), le
dploiement et la gestion de la qualit. Nous proposons un chantillon dans la section 4.

La notation UML

La notation UML inclut un grand nombre de concepts autour de lobjet mais aussi de
lanalyse des besoins (acteurs, cas dutilisation), de la conception du logiciel (composants, modules, processus) ou de limplantation (nuds, liaisons, dploiement). La raison est que cette
notation est conue pour dcrire des modles couvrant lensemble du cycle de dveloppement.
De plus certains concepts sont perus des niveaux dabstraction dirents. Par exemple,
les oprations des objets sont dcrites plus nement la conception. UML vise unier les
notations des nombreuses mthodes objets. Elle est donc un compromis. Heureusement, les
auteurs se sont entendus pour dnir une notation de base, que chacun peut ensuite tendre
par le mcanisme de strotypage. Par exemple, une classe abstraite est une classe ane par
le strotype abstract. Ainsi, une limite raisonnable est donne au nombre de concepts.
Nous dsignons par UML 1.X la famille de langage de premire gnration dUML. Cette
famille est caractrise par une approche unicatrice de la notation, qui fait dUML un
langage universel. Dans cette vision, UML sinspire de nombreuse rfrences et regroupe un
maximum de concept pour correspondre tous les besoins. Les principales inuences sont :

Booch : Catgories et sous-systmes

Embley : Classes singletons et objets composites
Fusion : Description des oprations, numrotation des messages
Gamma, et al. : Frameworks, patterns, et notes
Harel : Automates (Statecharts)
Jacobson : Cas dutilisation (use cases)
Meyer : Pr- et post-conditions
Odell : Classication dynamique, clairage sur les vnements
OMT : Associations
Shlaer-Mellor : Cycle de vie des objets
Wirfs-Brock : Responsabilits (CRC)

On peut aussi armer que UML 1.X vise satisfaire les utilisateurs (ceux qui dveloppent
avec UML). UML rpond en ce sens la cacophonie des mthodes et notations des annes
1990.
Depuis, les principes fondateurs ont volus, notamment sous limpulsion des architectures
applicatives mergentes (composants, Architectures de logiciels (ADL), services) mais aussi
de lapproche lingnierie des modles (IDM) prne par lOMG (Object Management Group)
sous lappellation Model Driven Architecture (MDA). La famille UML 2.X marque cette
double rupture, dans laquelle UML devient un langage pivot pour une famille de langages
spciques, les Domain Specic Languages (DSL). De ce fait, la smantique est devenue moins
contraignante pour pouser les smantiques prcises des DSL. UML 2.X nest plus porte par
les utilisateurs mais par les fournisseurs doutils pour les modles.
Prsenter la notation UML est un exercice assez dlicat car elle est complexe. Cette
complexit trouve ses sources dans le nombre de concepts reprsents, la varit dutilisation
de ces concepts et la confusion possible entre la notation et le modle de la notation (le
mtamodle) qui permet de lexprimer.

CHAPITRE 1. MTHODE DE DVELOPPEMENT DU LOGICIEL AVEC UML

UML 1.X disposait dun guide de la notation ou dun manuel de rfrence de la notation. Dans UML 2.X, la spcication de superstructure donne la vision pour lutilisateur, mais cest trop technique pour un manuel utilisateur tandis la spcication
dinfrastructure, oriente vers larchitecture, donne bien lide dune rfrence pour les
fournisseurs doutils.
Compte-tenu des remarques prcdentes, nous navons pas adopt une prsentation rigoureuse et complte de la mthode. Nous vitons de prsenter lensemble des concepts puis
les diagrammes dans lesquels on les retrouve. Nous vitons aussi dutiliser le mtamodle
comme support car il nous loigne des concepts. Ces deux alternatives entranent une description structurelle, longue et rbarbative, de la notation. Nous avons choisi de prsenter les
concepts dans leur contexte dutilisation habituel.
Avertissement
Cet ouvrage nest pas conu comme un manuel de la notation : tous les concepts ne
seront pas illustrs individuellement par des exemples. Nous avons choisi une approche
plus globale, en commentant la notation sur des exemples plus large . Pour un
expos de la notation, consulter [Aud09, Fow04, PP05, Bal06]. Noter que les manuels
de rfrence de lOMG (infrastructure [Gro11b], superstructure [Gro11c]) sont orients
par lapproche MDA, cest--dire plus pour les manipulateurs de modles que pour les
utilisateurs naux de la notation, cest pourquoi nous ne les conseillons pas ici.
Dans cette section, nous traons les grandes lignes de la notation : les lments gnraux,
les concepts fondamentaux, les outils de structuration et de prsentation.
2.1

Les lments gnraux

Nous prsentons dans cette section quelques lments et mcanismes gnraux de la notation qui nous semblent ncessaires la comprhension de la suite du chapitre.
Terminologie
La notation UML inclut trois sortes de briques : les lments, les relations et les diagrammes [RJB98]. Les lments de modlisation reprsentent les concepts (au sens o nous
lavons entendu jusquici) et des facilits de notation (paquetages, notes, contraintes). Les
relations reprsentent des liens entre lments de modlisation 1 . Elles sont dtailles dans la
section 2.2. Un paquetage est un lment qui regroupe lments et relations. La notion de
diagramme ne fait pas partie des lments de modlisation, contrairement au modle qui est
un paquetage. Un diagramme est une vue de lutilisateur sur un modle.
Strotype
La notion de strotype est un lment cl de lextensibilit de la notation UML et de
son adaptabilit aux AGL et aux mthodes propritaires. Chaque concept de la notation peut
tre spcialis par strotype. Le strotype est une annotation qui enrichit la description,
mais nintervient pas a priori dans les vrications des modle produits. Par exemple, une
classe abstraite est un strotype de la classe. Les strotypes sont reprsents par des doubles
chevrons . Au l des versions dUML, certains strotypes ont t intgrs directement
dans la notation. Par exemple, un nom de classe en italique indique que la classe est abstraite.
1. Bien que nous les prsentions part, les relations sont aussi des lments de modlisation au sens du
mtamodle dUML.

2. LA NOTATION UML

Collaboration, interaction
La notion de collaboration a quelque peu perdu de la valeur au l des volutions dUML.
Une collaboration dcrit une structure dlments qui collaborent selon des rles dtermins.
Cette terminologie provient de la mthode Fusion, une des sources dinspiration dUML.
Cest une vision statique (structurelle) des liens entre objets. Il est dusage de dire quune
collaboration implante un cas dutilisation.
Une interaction dcrit un change entre les lments de la collaboration. Cest la vision
dynamique (comportementale) des liens entre objets. On dira quune interaction se fait
au travers denvois de messages ou de signaux. Dans UML, deux points de vue quivalents
reprsentent les interactions : les diagrammes de squences qui insistent sur lenchanement et
la causalit des interactions (vision temporelle) tandis que le diagramme de communications
(ou de collaborations) qui met plus en vidence une vision spatiale de la collaboration. Le
support de la collaboration est un rseau dobjets interconnects (objets et liens).
Dans UML 2.X, il y a clairement une dichotomie mais aussi une dualit entre la vision
structurelle et la vision comportementale du systme. Est-ce un retour aux sources des
mthodes traditionnelles et la vision Merise de la systmique ?

Paquetage
Un paquetage est un mcanisme qui permet de grouper des lments. Il permet de structurer la spcication mais ne correspond pas une abstraction dun lment de conception
comme le composant. Les paquetages sont surtout utiliss pour regrouper des classes. Un paquetage peut contenir dautres paquetages. Le paquetage est reprsent par un dossier. Des
strotypes du paquetage le spcialisent en fonction du contexte. On parle de catgorie pour
les paquetages de la vue logique et de sous-systmes pour les paquetages dimplantation.
Comme pour les autres notations, plusieurs interprtations sont possibles. Dans une premire interprtation, un paquetage est un module. Les relations entre paquetages sont alors
des variantes de la relation de dpendance et on vite, autant que possible, les dpendances
circulaires. Le critre de cohrence est soit une proximit logique (les cassettes et les exemplaires), soit de fonctionalit (objets interfaces, objets mtiers). . . Une autre interprtation
est le dcoupage physique en sous-systmes.
Systme, sous-systme
Un systme est llment quon dveloppe et pour lequel on construit des vues. Un soussystme est une partie dun systme. Chaque sous-systme dun systme est reprsent par un
paquetage. La relation principale est lagrgation mais la spcialisation est aussi autorise. Le
paquetage dun sous-systme comprend trois lments : linterface (opration), les lments de
spcication et les lments de ralisation. Les modlisations faites pour un systme peuvent
ltre identiquement pour un sous-systme. Autrement dit, le discours sapplique quelle que
soit lchelle.
Espace de nommage
Un espace de nommage permet de dnir un contexte lexical pour les lments de modlisation. De nombreux concepts sont des expaces de nommages : les paquetages bien sr,
mais aussi les classes, les oprations ou mme les tats. Un lment sera donc dsign par son
nom et lensemble des espaces de nommages qui le contiennent hirarchiquement. On utilise
le sparateur :: pour construire le nom complet, par exemple pack::class:op(param).

CHAPITRE 1. MTHODE DE DVELOPPEMENT DU LOGICIEL AVEC UML

2.2

Les relations dans le modle objets

Les relations permettent de structurer les lments dun modle objets. Ayant des objets
et des classes, nous trouvons naturellement des relations entre instances (objets), des relations
entre types (classes, classiers) et des relations entre instances et types.
i) Relations entre objets et types
La relation entre un objet et sa classe est la relation dinstanciation. Un objet est
instance dune seule classe qui dnit sa structure et son comportement.
ii) Relations entre objets
La base de linteraction entre objets est lenvoi de message qui suppose un mdium,
une relation de lobjet client (metteur) et lobjet serveur (receveur). Le client invoque un
service du serveur, cest une relation de clientle, ou de dlgation. Par exemple, on peut
demander une cassette quel est son lm. Cest une relation fondamentale dans un
modle objets, qui se reprsente en UML par un lien entre objets. Les liens sont abstraits
au niveaux des classes par une association entre les classes de ces objets.
Un objet (le compos) peut inclure un autre objet (le composant). Cette relation de
structuration est appele agrgation, relation tout-partie. Elle induit une relation de
clientle de lobjet compos vers lobjet composant. Lagrgation est une relation dont les
contours ne sont pas toujours bien dnis [HSB99] car elle recouvre divers aspects :
Visibilit. Lobjet composant est encapsul dans lobjet compos. De ce fait il doit suivre
les rgles de visibilit dnies par celui-ci. En particulier, il se pose la question de savoir
quels objets le composant peut tre associ : uniquement des objets composants du
mme compos ou alors nimporte quel objet du systme ?
Dure de vie. Quelles sont les rgles de synchronisation entre la vie de lobjet compos
et celle de ses composants ? Y-a-til suppression en cascade ?
Evolution dynamique. Lobjet composant a-t-il un ot de contrle indpendant (concurrent) de lobjet compos ou son ot est-il assujetti celui du compos ?
Si lobjet composant est fortement corrl lobjet compos (dnition xer sur les critres
ci-dessus) alors on parle de dagrgation forte ou de composition.
Dans une modlisation objets, les objets sont rarement reprsents, on modlise plutt
leurs classes, les relations ci-dessus sont donc abstraites au niveau des classes. Illustrons les
dirences sur un exemple via la notation UML. Soient les trois relations de la gure 1.
Salari
est_dirig_par

Personne

commande
1..*

enfants

0..*

(3) composition

(1) association
Jumelle

(2) agrgation
Lentille

contenu
1..1

parents

0..*

Figure 1 : Association, agrgation, composition

1. Lassociation symbolise des liens entre deux instances des classes associes. Un salari
est dirig par un autre salari. Le patron est dirig par lui-mme. Dans une association,
un objet peut tre li lui-mme.

2. LA NOTATION UML

2. Une personne a deux parents mais ne peut tre parent delle-mme. Lagrgation est
pertinente ici car cest une association non rexive (un objet nest pas li lui-mme)
et les objets ont des lignes de vie propres (parents et enfants ont une vie indpendante !).
3. Les lentilles dune jumelle font partie intgrante de la jumelle. Cette dpendance forte
sexprime en UML par une relation de composition. La composition est exclusive.
iii) Relations entre classes
Il existe deux types de relations entre classe : lutilisation et lhritage. Nous traitons aussi
de la gnricit.
Relation dutilisation La relation dutilisation exprime le fait que pour raliser ses fonctionalits un objet utilise les services dautres objets. Elle correspond limportation modulaire : un module utilise les services dun autre module pour raliser ses propres services.
Cette structuration entre classes peut tre ane. Etudions quelques critres danement,
qui font parfois la dirence entre deux modles objets.
Agrgation ou composition : ce point a t examin dans le point ii).
Sens de la relation : pour lagrgation, la relation est oriente du compos vers le composant. Pour la relation de clientle, plusieurs cas se prsentent. Si toutes les instances
dune classe A sont clientes (au travers denvois de messages) dinstances dune classe
B alors une relation dutilisation existe entre la classe A et la classe B. Si inversement
les instances de la classe B sont clientes des instances de la classe A, alors la relation
dutilisation est symtrique (ou bidirectionnelle). Par exemple connaissant la cassette,
on peut demander quel est le lm enregistr et connaissant le lm, on peut demander
quels sont les exemplaires en boutiques.
Mmorisation : pour envoyer un message un objet serveur, le client doit connatre
lobjet serveur (ou son identit si le modle dispose de cette notion). Lobjet serveur
peut tre mmoris soit au sein de lobjet client soit dans lenvironnement (le systme
objets). Il peut aussi tre pass en paramtre dune mthode.
Multiplicit (cardinalit) : une instance dune classe peut faire appel une ou plusieurs instances direntes dune autre classe. Ce critre a une inuence sur les critres
prcdents. Par exemple, un mme lm peut tre enregistr sur plusieurs cassettes.
Nerson distingue cinq types de relation dutilisation [Ner92], issues des cardinalits du modle
objets et de la dualit association/agrgation : du client vers le serveur (utilise, a besoin
de, a, consiste en) et du serveur vers le client (fournit). Notons aussi quune distinction est
parfois faite dans certaines mthodes entre les attributs typs par un type de base et les
attributs typs par une classe.
En programmation objets, la relation dutilisation restreinte aux attributs de la structure
est appele dpendance structurelle (on suppose ici que le type de lattribut est connu). La
structure de lobjet (ses attributs) sert mmoriser les valeurs simples (dont le type est un
type de base), les objets composs et les objets serveurs. En C++, par exemple, une donne
membre (un attribut) a pour type un type C (type de base), une classe (objet compos) ou
un pointeur vers une classe (objet serveur). Si la multiplicit est suprieure 1, on utilise des
collections dobjets ou des collections de pointeurs vers les objets. En analyse et conception
objets, les valeurs simples sont des attributs, les objets composants sont relis par une relation
dagrgation et les objets serveurs sont relis par une association.
La remarque prcdente montre que limplantation dune modlisation objets implique
des choix de reprsentation dans le langage cible. En particulier, si la relation de clientle
est symtrique ou bidirectionnelle, plusieurs implantations sont possibles, qui ncessitent des
pointeurs. Pour les mmes raisons, dnir quel est le receveur dune mthode quelconque est
un problme pineux. Par exemple, emprunter(cassette, boutique, adhrent) est-elle

10

CHAPITRE 1. MTHODE DE DVELOPPEMENT DU LOGICIEL AVEC UML

une mthode de la classe adhrent, de la classe boutique ou de la classe cassette ou des trois ?
Le critre de regroupement nest pas uniquement la structure mais aussi le comportement.
La relation de dpendance est un cas particulier dutilisation qui exprime que pour
dnir une classe on fait rfrence dautres classes ou des interfaces.
Relation dhritage Linnovation la plus importante du modle classes est lhritage
(relation de gnralisation/spcialisation, sous-classe, sous-typage, ranement). Voici une
dnition extraite de [Mey97].
Dnition 1.1 (hritage) Lhritage est un mcanisme permettant de dnir une nouvelle classe (la sous-classe) partir dune classe existante (la super-classe) par extension ou
restriction.
Lextension se fait en rajoutant des mthodes dans le comportement ou des attributs dans
la structure. Par exemple, les conditions demprunts des adhrents peuvent tre direntes
sil sagit demploys du magasin ou dautres personnes. La classe employ du magasin est une
extension de la classe adhrent laquelle on ajoute un compte boutique. La restriction consiste
rduire lespace des valeurs dnies par la classe en posant des contraintes (conditions
logiques vrier) sur ces valeurs. Par exemple, supposons un attribut ge dans la classe
adhrent et la rgle suivante : les jeunes adhrents peuvent emprunter deux exemplaires de
plus que les autres adhrents. La classe jeune adhrent est une restriction de la classe adhrent
dont la contrainte porte sur lge. La restriction correspond plutt au sous-typage, qui est
souvent dni comme une inclusion ensembliste des valeurs de deux types. On retrouve donc
le double aspect classe = module et classe = type de donne.
Lhritage induit le polymorphisme : une instance de la sous-classe est aussi une instance
de la super-classe. Un jeune adhrent reste un adhrent. Cette instance peut donc utiliser
sans les dnir les mthodes de la super-classe.
Lhritage est la fois un mcanisme dinfrence permettant de dnir des hirarchies
de gnralisation/spcialisation (taxonomie) et un mcanisme de construction incrmentale
de classes par rutilisation de code. Ou bien, dit autrement, une sous-classe reprsente soit
un sous-type soit une autre implantation du mme type (soit les deux bien sr). Certains
modles autorisent lhritage multiple.
Dnition 1.2 (gnricit) La gnricit est un mcanisme permettant de paramtrer
des types par dautres types. Lactualisation (ou instanciation) de paramtres formels de
types se fait en fournissant des types dnis (des classes ou des types de base). Une classe
gnrique acceptera donc en paramtre dautres classes (et sous-classes).
Lexemple classique est celui des collections dlments (ensemble dentiers, de personnes. . .).
Le type des lments ninue pas sur les oprations de la collection. Combin avec lhritage,
la gnricit ore un support puissant la rutilisation.
Lhritage et la gnricit forment les deux cas de vrai polymorphisme (le mme code
est utilis quels que soient les types). La coercition (cast, transtypage) et la surcharge (y
compris les rednitions) sont des cas de faux polymorphisme puisquun code dirent
va tre utilis. Evidemment seul le vrai polymorphisme apporte la rutilisabilit du
code.

Notation UML des relations

En UML, les relations sappliquent aux lments de modlisation. De ce fait, on peut
dire que leur smantique est surcharge. Toutes ces relations sont binaires. Elles peuvent tre
anes par strotypage.