UML 2

Modlisation Oriente Objet de Systmes Logiciels

Pierre Grard

Universit de Paris 13 IUT Villetaneuse

DUT Informatique S2 - 2007/2008

Table des matires

1 Introduction la Modlisation Oriente Objet 1

2 Modles de base 72.1 Diagrammes de cas d'utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Diagrammes de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3 Diagrammes de squences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3 Processus de dveloppement avec UML 353.1 Des besoins au code avec UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2 Rational Unied Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.3 eXtreme programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4 Autour d'UML 574.1 OCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.2 Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5 Modles complmentaires 775.1 Diagrammes d'objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.2 Diagramme de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.3 Diagramme d'tats-transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.4 Digrammes d'activit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.5 Diagrammes de composants et de dploiement . . . . . . . . . . . . . . . . . . . . . . . . . 99

1 INTRODUCTION LA MODLISATION ORIENTE OBJET

1 Introduction la Modlisation Oriente Objet

Bibliographie UML UML 2.0, guide de rfrence James Rumbaugh, Ivar Jacobson, Grady Booch Editions Campus Press (2005)

UML 2.0 Benot Charoux, Aomar Osmani, Yann Thierry-Mieg Editions Pearson, Education France (2005)

UML 2.0 Superstructure et UML 2.0 Infrastructure OMG (Object Management Group) www.uml.org (2004).

Bibliographie OCL UML 2.0 Object Constraint Language (OCL) OMG (Object Management Group) www.uml.org (2004)

Cours de Jean-Marie Favre, IMAG www-adele.imag.fr/jmfavre

Matriel et logiciel Systmes informatiques : 80 % de logiciel ; 20 % de matriel.

Depuis quelques annes, la fabrication du matriel est assure par quelques fabricants seulement. Le matriel est relativement able. Le march est standardis.

Les problmes lis l'informatique sont essentiellement des problmes de logiciel.

Spcicit du logiciel Un produit immatriel, dont l'existence est indpendante du support physique Un objet technique fortement contraint qui fonctionne ou ne fonctionne pas, avec une structurecomplexe

Un cycle de production particulier : La reproduction pose peu de problmes, seule la premire copie d'un logiciel a un cot.

Compte tenu du cycle de production, il faut bien faire tout de suite.

La qualit du processus de fabrication est garante de la qualit du produit.

La crise du logiciel tude sur 8 380 projets (Standish Group, 1995) : Succs : 16 % ; Problmatique : 53 % (budget ou dlais non respects, dfaut de fonctionnalits) ; chec : 31 % (abandonn).

Le taux de succs dcrot avec la taille des projets et la taille des entreprises.

Gnie Logiciel (Software Engineering) : Comment faire des logiciels de qualit ? Qu'attend-on d'un logiciel ? Quels sont les critres de qualit ?

UML 2 1 / 102

1 INTRODUCTION LA MODLISATION ORIENTE OBJET

Critres de qualit d'un logiciel Utilit Adquation entre le logiciel et les besoins des utilisateurs ;

Utilisabilit Fiabilit Interoprabilit Interactions avec d'autres logiciels ;

Performance Portabilit Rutilisabilit Facilit de maintenance Un logiciel ne s'use pas pourtant, la maintenance absorbe une trs grosse partie des eorts dedveloppement.

Poids de la maintenance

Rartition eortdv.

Origine deserreurs

Cot de lamaintenance

Dnition desbesoins

6% 56% 82%

Conception 5% 27% 13%Codage 7% 7% 1%

Intgration Tests 15% 10% 4%Maintenance 67%

(Zeltovitz, De Marco)

Principes utiliss dans le Gnie Logiciel Gnralisation Regroupement d'un ensemble de fonctionnalits semblables en une fonctionnalit paramtrable(gnricit, hritage).

Structuration Faon de dcomposer un logiciel (utilisation d'une mthode ascendante ou descendante).

Abstraction Mcanisme qui permet de prsenter un contexte en exprimant les lments pertinents et enomettant ceux qui ne le sont pas.

Principes utiliss dans le Gnie Logiciel Modularit Dcomposition d'un logiciel en composants discrets.

Documentation Gestion des documents en incluant identication, acquisition, production, stockage et distribution.

Vrication Dtermination du respect des spcications tablies sur la base des besoins identis dans laphase prcdente du cycle de vie.

Cycle de vie

La qualit du processus de fabrication est garante de la qualit du produit.

Pour obtenir un logiciel de qualit, il faut en matriser le processus d'laboration. La vie d'un logiciel est compose de direntes tapes. La succession de ces tapes forme le cycle de vie du logiciel. Il faut contrler la succession de ces direntes tapes.

2 / 102 UML 2

1 INTRODUCTION LA MODLISATION ORIENTE OBJET

Etapes du dveloppement tude de faisabilit Spcication Dterminer les fonctionnalits du logiciel ;

Conception Dterminer la faon dont dont le logiciel fournit les direntes fonctionnalits recherches ;

Codage Tests Essayer le logiciel sur des donnes d'exemple pour s'assurer qu'il fonctionne correctement ;

Maintenance

Types de cycle de vie Dveloppement en cascade Chaque tape ne dbute que lorsque la prcdente est acheve.

Dveloppement en V A chaque tape correspond une tape de test spcique. Les tests peuvent tre dnis avant les phases de test.

Dveloppement non linaire On commence par dvelopper un sous ensemble des fonctionnalits du logiciel, de manire linaire ; On itre un modle linaire pour dvelopper incrmentalement de plus en plus de fonctionnalits,jusqu' achvement du projet.

Dmarche et modles Dmarche : succession d'tapes pour : Mieux matriser le droulement d'un projet ; Meilleure visibilit pour les utilisateurs sur certains rsultats intermdiaires et garantir que lersultat nal sera celui attendu.

A chaque tape, on produit des modles dirents niveaux d'abstraction, un utilisant un forma-lisme : Un langage formel ; Un langage semi-formel gnralement graphique ; Un langage naturel ;

Modlisation

Modle Un modle est une reprsentation abstraite de la ralit qui exclut certains dtails du monde rel. Il permet de rduire la complexit d'un phnomne en liminant les dtails qui n'inuencent passon comportement de manire signicative.

Il rete ce que le concepteur croit important pour la comprhension et la prdiction du phno-mne modlis, les limites du phnomne modlis dpendent des objectifs du modle.

UML 2 3 / 102

1 INTRODUCTION LA MODLISATION ORIENTE OBJET

Intrt de la modlisation Modliser le processus de dvemoppement permet de Bien rpartir les tches et d'automatiser certaines d'entre elles ; Rduire les cots et les dlais ; Assurer un bon niveau de qualit et une maintenance ecace.

Modliser un systme avant sa ralisation permet de Comprendre le fonctionnement du systme ; Matriser sa complexit ; Assurer sa cohrence ; Pouvoir communiquer au sein de l'quipe de ralisation .

Proprits attendues

Le choix du modle a une inuence capitale sur les solutions obtenues.

Il faut bien choisir les modles employs. Les modles doivent pouvoir dcrire un systme dirents niveaux d'abstraction. Les modles doivent avoir un comportement proche de la ralit. Un seul modle est souvent insusant. Les systmes non-triviaux sont mieux modliss par unensemble de modles inter-indpendants.

Selon les modles employs, la dmarche de modlisation n'est pas la mme.

Dmarches de modlisation pour le logiciel Approche fonctionnelle Approche traditionnelle utilisant des procdures et des fonctions. Les grand programmes sont ainsi dcomposs en sous programmes.

Approche oriente objets

1. On identie les lments du systme et on en fait des objets.

2. On cherche faire collaborer ces objets pour qu'ils accomplissent la tche voulue.

Modlisation par dcomposition fonctionnelle Approche descendante : Dcomposer la fonction globale jusqu' obtenir des fonctions simples apprhender et donc programmer.

C'est la fonction qui donne la forme du systme

Critique de l'approche fonctionnelle Avantages : Organise, rchie, logique. Ordonne, rduit la complexit.

Inconvnients : Comment assurer l'volution du logiciel ? Comment rutiliser les parties dj dveloppes ? Comment structurer les donnes ?

4 / 102 UML 2

1 INTRODUCTION LA MODLISATION ORIENTE OBJET

Approche oriente objets La Conception Oriente Objet (COO) est la mthode qui conduit des architectures logiciellesfondes sur les objets du systme, plutt que sur une dcomposition fonctionelle.

C'est la structure du systme lui donne sa forme.

On peut partir des objets du domaine (briques de base) et remonter vers le systme global Approche ascendante Attention, l'approche objet n'est pas seulement ascendante

Critique de l'approche oriente objet Avantages : Simple : peu de concepts de base ; Raisonnement par abstraction sur les objets du domaine (voir critres de qualit).

Inconvnients : Parfois moins intuitive que l'approche fonctionnelle. Rien dans les concepts de base objets ne dicte comment modliser la structure objet d'un systmede manire pertinente. L'application des concepts objets ncessite de l'exprience et une grande rigue