21/12/2008

Conception et Programmation Oriente Objet

Plan
Introduction Prsentation dUML
Dfinitions Domaines dutilisation Elments de base

Unified Modeling Language

Lilia SFAXI
RT3 Anne universitaire : 2008/2009

Diagramme de cas dutilisation Diagramme de classes Diagramme dobjets Diagramme de squences et de collaboration Conclusion
2

Modlisation
Modle
Reprsentation abstraite et simplifie dune entit du monde rel en vue de le dcrire, de lexpliquer ou de le prvoir Thorie oriente vers laction quelle doit servir

Modlisation

Introduction

Permet de rduire la complexit dun phnomne

liminer les dtails non significatifs Reflter ce qui est important pour la comprhension et prdiction du phnomne modlis

Exemples de modles
Modle mtorologique Modle conomique Modle dmographique Plans
3 4

21/12/2008

Modlisation
Modliser un systme pour :
Mieux comprendre son fonctionnement Matriser sa complexit Assurer sa cohrence Permettre la communication entre les diffrents membres de lquipe Permettre une bonne rpartition des tches Rduire les cots et les dlais

Gestion de projet
Bien comprendre les besoins, les demandes et les exigences des utilisateurs finaux. Bonne communication avec le client pour valider certains choix et vrification de ltape (1). Tester et valider chaque phase de la conception pour ne pas dcouvrir des problmes plus tard. Traiter au plus tt les problmes. Matriser la complexit et augmenter la rutilisation. Dfinir une architecture robuste. Faciliter le travail en quipe.
6

Bonnes pratiques
Dveloppement itratif
Dcoupage du problme en tapes lmentaires Chaque tape produit des retours et adaptations si ncessaire

Dveloppement base de composants

Dcoupage en modules rutilisables

Pilotage du dveloppement par les risques

Analyse des risques au plus tt Travailler sur les risques critiques

UML

Gestion des exigences

Fonctionnelles : ce que le systme doit savoir faire Non fonctionnelles : QoS, temps de rponse, scurit,

Matrise des modifications

Demande dvolution Rapport danomalie

Evaluation continue de la qualit Modlisation visuelles

Utilisation de langages visuels et schmatiques
7 8

21/12/2008

Dfinition
Langage standard conu pour permettre aux concepteurs dlaborer les plans des logiciels quils doivent dvelopper N de la fusion de 3 mthodes:
OMT Booch OOSE

UML est un langage

Ce langage possde un vocabulaire et des rgles qui permettent de combiner les mots afin de communiquer. La modlisation permet de comprendre le systme,
Tous les modles sont lis les uns avec les autres afin de reprsenter le systme et les interactions entre les blocs lmentaires.

On se sert du langage UML pour:

Visualiser Spcifier Construire Documenter Communiquer (travailler plusieurs)
9

Le vocabulaire et les rgles dcriture rgissent la manire de construire et de lire les modles correctement mis en forme.
Aucune dcision dimplmentation.

10

UML, un langage pour visualiser

Pour certains dveloppeurs, il existe un lien direct entre une ide et son code dimplmentation.
Utilisation dun modle de reprsentation mental.

UML, un langage pour spcifier

Dans le cadre dUML, spcifier signifie construire sans ambigut UML offre la possibilit de spcifier le comportement de lapplication de manire formelle,
Rflexion sur des modles formels Approche indpendante du langage objet d'implmentation (C++, Java, etc.).

Problme dans le partage de ces modles avec dautres personnes

Risques dincomprhension, dincertitudes... Chaque organisation et/ou personne possde son propre langage (difficult dintgration)

UML permet de rsoudre les problmatiques du partage de linformation de manire visuelle. UML est bien plus quun assemblage de symboles graphiques !
Chaque symbole graphique possde sa smantique propre (signification universelle). Un modle peut tre crit par un concepteur et compris pas un autre sans ambigut... Une automatisation par outil peut ainsi tre mise en place pour traiter certaines informations.

UML nest pas une mthode mais une notation qui laisse la libert de conception.

UML est un mta-langage de modlisation permettant dunifier les modles utiliss dans les mthodes de dveloppement (raffinement).
11 12

21/12/2008

UML, un langage pour documenter

Lors du dveloppement dun produit, on ralise des choix
Architecture dimplmentation Besoins identifis Code source du projet Planning de dveloppement Les plans et les jeux de test,

Les domaines dutilisation de UML

UML est employ dans lensemble des secteurs du dveloppement informatique
Systmes dinformation Tlcommunication, dfense Transport, aronautique, arospatial Domaines scientifiques

UML permet de raliser la dfinition et la documentation de ces tches.

Mais pas seulement : on peut modliser des comportement mcaniques, humain, etc. Structure dun systme de sant / judiciaire, etc.

13

14

Les briques de base dUML

Dans le langage UML, il existe 3 types de briques de base
Les lments
Ce sont les abstractions essentielles au modle.

Les lments
Ce sont les lments de base qui vont permettre la dfinition par la suite des modles Il existe 4 types dlments en UML
Les lments Les lments Les lments Les lments structurels comportementaux de regroupement dannotation

Les relations
Les relations expriment les liens existants entre les diffrents lments.

Les diagrammes
Les diagrammes comprennent des ensembles dlments dignes d'intrt.

15

16

21/12/2008

Les lments structurels

Les lments structurels sont les lments les plus statiques dUML, il en existe 7 types distincts
Les classes Les interfaces Les collaborations Les cas dutilisation Les classes actives Les composants Les noeuds

Les lments comportementaux

Les lments comportementaux reprsentent les parties dynamiques des modles Ils permettent de dfinir le comportement du modle dans le temps et lespace Il en existe 2 types fondamentaux :
Les interactions Les automates tats finis

17

18

Les lments de regroupement

Les lments de regroupement reprsentent les parties organisationnelles des modles UML Ce sont les boites dans lesquelles un modle peut tre dcompos Il existe un seul type dlment de regroupement :
le package

Les lments dannotation

Les modles dannotation reprsentent les parties explicatives des modles UML. Ce sont les commentaires qui vont tre ajouts aux modles afin :
Dexpliquer un choix Dcrire le fonctionnement Faire une remarque Dtailler une hypothse Spcifier une contrainte dimplmentation

19

20

21/12/2008

Les relations dans UML

Afin dexprimer les liens interconnectant les diffrents lments des modles, 4 relations de base ont t dfinies :
La dpendance La gnralisation Lassociation La ralisation

Les diagrammes en UML

Un systme est un ensemble de sous-systmes organiss pour atteindre un objectif et dcrit laide de modles Un sous-systme est un regroupement dlments , dont certains spcifient le comportement propos par les autres lments contenus. Un modle est une abstraction complte et cohrente dun systme permettant den faciliter la comprhension.
Modlisation des parties structurelles (statique) Modlisation du comportement (dynamique)

21

22

Les diagrammes en UML

Un diagramme est une reprsentation visuelle de lensemble des lments qui constituent le systme Ils servent visualiser un systme sous diffrents angles (utilisateur, administrateur par ex.) Dans les systmes complexes, un diagramme ne fournit quune vue partielle du systme
Lensemble des diagrammes runis permet dobtenir une vue globale du systme concevoir Chaque diagramme va permettre de modliser ou spcifier une vue (spcificit) du systme concevoir

Les diagrammes en UML

Diagrammes structurels / statiques (UML Structure)
diagramme de classes (Class diagram) diagramme dobjets (Object diagram) diagramme de composants (Component diagram) diagramme de dploiement (Deployment diagram) diagramme de paquetages (Package diagram) diagramme de structures composites (Composite structure diagram)

Diagrammes comportementaux / dynamiques (UML Behavior)

diagramme de cas dutilisation (Use case diagram) diagramme dactivits (Activity diagram) diagramme dtats-transitions (State machine diagram) diagrammes dinteraction (Interaction diagram)
diagramme de squence (Sequence diagram) diagramme de communication (Communication diagram) diagramme global dinteraction (Interaction overview diagram) diagramme de temps (Timing diagram)
24

23

21/12/2008

Diagramme de cas dutilisation

Capturer le comportement dun systme, dun soussystme, dune classe ou dun composant tel quun utilisateur extrieur le voit Scinder la fonctionnalit du systme en units cohrentes

Diagramme de cas dutilisation

Cas dutilisation

Exprimer les besoins des utilisateurs dun systme Se compose de :

Acteurs Cas dutilisation Relations

25

26

Acteurs
Idalisation dun rle jou par :
Une personne externe Un processus Un autre systme

Cas dutilisation
Unit cohrente Reprsente une fonctionnalit visible de lextrieur Ralise un service pour lacteur qui linitie, avec:
Dclenchement Droulement Fin

Reprsent par un petit bonhomme Il faut identifier les rles des utilisateurs dun systme pour trouver les acteurs Dfinition de la frontire du systme
Tout ce qui est lextrieur du systme : Acteur Tout ce qui est lintrieur du systme : Fonctionnalit

Modlise un service rendu par le systme Reprsent par une ellipse contenant le nom du cas (verbe linfinitif)
Effectuer Virement

27

28

21/12/2008

Relations acteurs/cas dutilisations

Association
Chemin de communication entre acteur et cas dutilisation Reprsent par un trait continu Peut dfinir :
Une multiplicit : un acteur peut interagir plusieurs fois avec le cas dutilisation

Relations entre cas dutilisation

Relation dinclusion
Un cas A inclut un cas B si lexcution de A entrane obligatoirement celle de B Permet de
Dcomposer un cas complexe en sous-cas Factoriser un comportement commun plusieurs cas dutilisation

Strotype <<include>>

Relation dextension
Un cas A tend un cas B quand A peut tre appel au cours de lexcution de B Lextension est optionnelle Dfinit
Point dextension : point prcis du cas tendu au niveau duquel lextension peut intervenir Une contrainte : condition pendant laquelle lextension intervient

Acteur Principal / Secondaire

Acteur principal : si le cas rend service lacteur
Strotype <<primary>>

Acteurs secondaires : les autres acteurs

Strotype <<secondary>>

Strotype <<extend>>

Relation de gnralisation
Le cas A est une gnralisation du cas B si B est un cas particulier de A Concept dhritage
30

29

Exemple : Borne interactive dune banque

Description textuelle dun cas dutilisation

Obligatoire pour la description du comportement du systme Se dcompose en :
Identification du cas dutilisation
Nom : infinitif Objectif : description rsume Acteurs : principaux et secondaire

Description du fonctionnement
Squence nominale : dcrit le droulement normal du cas Pr-conditions : tat du systme avant le dclenchement du cas Post-conditions : tat du systme lissue de lexcution du cas

Rubrique optionnelle
Spcifications non fonctionnelles : spcifications techniques, besoins en interface graphique
31 32

21/12/2008

Diagramme de classes
Le diagramme le plus important de la modlisation oriente objet : le seul obligatoire Dcrit la structure interne du systme Fournir une reprsentation abstraite des objets du systme qui interagissent ensemble pour raliser le cas dutilisation Vue statique : pas de facteur temporel Modlisation des classes du systme et leurs relations
Indpendant du langage de programmation

Diagramme de classes

33

34

Classes
Description formelle dun ensemble dobjets ayant une smantique et des caractristiques communes Un objet est une instance de classe Reprsente par un rectangle divis en 3 compartiments obligatoires et 2 optionnels
Nom de la classe Attributs Mthodes Responsabilits (op)
ensemble des tches devant tre assures par la classe mais pour lesquelles on ne dispose pas dassez dinformations

Caractristiques dune classe

Visibilit
Public ou +
tout lment qui peut voir la classe courante peut galement voir llment indiqu

Protected ou #
seul un lment situ dans la classe courante ou un de ses descendants peut voir llment indiqu.

Private ou
seul un lment situ dans la classe courante peut voir llment.

Package ou ~ ou rien
seul un lment dclar dans le mme paquetage peut voir llment.

Nom de la classe
A la forme :
[ <Nom_du_paquetage_1>:: ... ::<Nom_du_paquetage_N> ] <Nom_de_la_classe> [ { [abstract], [<auteur>], [<date>], ... } ]

Exceptions (op)
Situations exceptionnelles devant tre gres par les classes
35 36

Exemple :
Pack1::Class1 {abstract, Lilia}

21/12/2008

Attributs
Donnes encapsules dans les objets de cette classe Dfinis par un nom, un type de donnes, et une visibilit A la forme
<visibilit> [/] <nom_attribut> : <type> ['['<multiplicit>']' [{<contrainte>}] ] [ = <valeur_par_dfaut> ]

Mthodes
Dcrit une fonctionnalit de la classe Doit contenir un nom, un type de retour et des paramtres A la forme :
<visibilit> <nom_mthode> ([<paramtre_1>, ... , <paramtre_N>]) : [<type_renvoy>] [{<proprits>}]

Exemple
+ couleur : int [3] {list}

Attribut de classe
Attribut propre la classe, pas linstance(static en java) Garde une valeur unique et partage par toutes les instances de la classe Graphiquement : soulign
37

Un paramtre a la forme :
[<direction>] <nom_paramtre>:<type> ['['<multiplicit>']'] [=<valeur_par_dfaut>]

Exemple
+ dplacer (in distance : int = 2) : void {abstract}
38

Interfaces
Type particulier de classes Classe o toutes les mthodes sont abstraites
Strotype interface

Relation dassociation
Relation entre deux classes ou plus dcrivant les connexions structurelles entre leurs instances Relie des classes au mme niveau hirarchique (conceptuellement parlant) 4 dcorations permettent de spcifier le lien entre objets
Nom : nature des relations entre les objets Direction : direction dapplication du nom Rle : rle spcifique de chacune des classes dans lassociation Cardinalit : nombre dlments affects

Permet de regrouper un ensemble de proprits et doprations assurant un service cohrent Doit tre ralise (implmente) par au moins une classe et peut ltre par plusieurs
Strotype realize

Une classe peut dpendre dune interface

Strotype use

Exemple

39

40

10

21/12/2008

Relations dagrgation et de composition

Agrgarion
Dfinit une relation hirarchique entre les entits Dfinit la relation : se compose de et modlise la notion de possession ou de tout et partie

Relation de dpendance
La dpendance tablit une relation dutilisation entre 2 entits dun mme diagramme. La plupart du temps il sagit dune dpendance dutilisation :
Argument dune mthode par exemple On parle alors de relation dutilisation

Composition
Dfinit une contenance structurelle entre les instances La destruction de lobjet composite implique la destruction de ses composants Une instance du composant appartient au plus une instance du composite

Cela permet didentifier implications possibles des modifications apporter dans une entit
Changement du comportement dune des classes par exemple

Agrgation 41

Composition 42

Dpendance

Relation de gnralisation
Modlise la relation dhritage
La gnralisation correspond la notion est une sorte de Modlisation des relations parents / enfants

Les Notes (commentaires)

Lors des phases de modlisation et de spcification, il est ncessaire de documenter ses modles :
Contraintes matrielles Contraintes de performance Choix techniques raliss Rfrences dautres documents Explications techniques, etc.

Les entits issues dune gnralisation sont utilisables partout ou leur classe mre peut l'tre (mais pas linverse) Gnralisation (classe, classe) ou (classe, interface) Cette relation est modlise par une flche pointant sur la classe mre

En UML, on utilise les Notes

43

44

11

21/12/2008

Exemple : Banque

Diagramme dobjet

45

46

Diagramme dobjets
Reprsente des objets (i.e. instances de classes) et leurs liens (i.e. instances de relations) pour donner une vue fige de ltat dun systme un instant donn Peut tre utilis pour
illustrer le modle de classes en montrant un exemple qui explique le modle prciser certains aspects du systme en mettant en vidence des dtails imperceptibles dans le diagramme de classes exprimer une exception en modlisant des cas particuliers ou des connaissances non gnralisables qui ne sont pas modliss dans un diagramme de classe prendre une image (snapshot) dun systme un moment donn

Graphiquement
Un objet est reprsent comme une classe, mais le compartiment des mthodes nest pas indiqu Le nom de lobjet est compos du nom de linstance, suivi de celui de la classe, et est soulign Les attributs reoivent des valeurs
Si certaines valeurs ne sont pas renseignes, lobjet est partiellement dfini

Le diagramme de classes modlise les rgles et le diagramme dobjets modlise des faits
47

La relation de gnralisation nest jamais reprsente Les multiplicits ne sont pas reprsentes On peut reprsenter de dpendance dinstanciation
Strotype instance of
48

12

21/12/2008

Exemples

Diagrammes de squence et de collaboration

49

50

Diagramme de squences
Modlisation les interactions entre les objets Mise en vidence de laspect temporel des traitements (ordre chronologique de ralisation) Mise en vidence des objets et des messages changs par les entits interagissant avec et/ou dans le systme La modlisation est base sur laffichage des objets participant la squence et lordre des messages et des actions associes.

Exemple : Client / Serveur

51

52

13

21/12/2008

Diagramme de collaboration
Mise en vidence de lorganisation des objets qui vont collaborer pour effectuer une interaction
On reprsente les objets qui vont intervenir (les sommets) On modlise les liens qui vont modliser les communications entre les objets (les arcs) On annote les liens laide des informations qui vont tre changes entre les entits

Exemple : Client / Serveur

Visualisation claire du flot de contrle dans le contexte de l'organisation structurelle

53

54

Conclusion
UML : Langage permettant d'apprhender la ralisation dun systme informatique complexe Ensemble de diagrammes qui permettent daider la rflexion, de permettre la discussion sur des bases normalises et formalises (clients, dveloppeurs) Pas de solution unique mais un ensemble de solutions plus ou moins acceptables Contraintes clients (performances et fonctionnalits) Architectures logicielles et matrielles disposition Des itrations successives du flot permettent daboutir une solution Les diagrammes et notions prsentes dans ce cours ne sont quune petite introduction UML
56

Conclusion

55

14