Facult des Sciences Dhar El Mehraz de Fs Dpartement de Mathmatique et Informatique Master Qualit du Logiciel

Rapport de Formation : MODELISATION UML

Document ralis par HANGAMA Cdric Etudiant en Master 1, Qualit du Logiciel

Sommaire
I. INTRODUCTION GENERALE .................................................................................................................. 3 II. LES DIAGRAMMES UML ...................................................................................................................... 5 Chap. I Les diagrammes des cas dutilisation ..................................................................................... 5 1. 2. 3. Dfinition et Objectifs ............................................................................................................. 5 Notations et Variantes............................................................................................................. 6 Une tude de cas ................................................................................................................... 10

Chap. II. Le diagramme de squence................................................................................................ 12 1. 2. 3. 4. Dfinition et Objectifs ........................................................................................................... 12 Type de message ................................................................................................................... 13 Activation et envoi des messages ......................................................................................... 14 Fragments dinteraction combins. ...................................................................................... 14

Chap. III. Le diagramme des classes .................................................................................................. 18 1. 2. 3. Dfinition et Objectifs ........................................................................................................... 18 Notations et Variantes........................................................................................................... 19 Une tude de cas ................................................................................................................... 21

Chap. IV. Le diagramme dtat - transition ....................................................................................... 21 1. 2. 3. Dfinition et Objectifs ........................................................................................................... 21 Notation et variantes............................................................................................................. 22 Etapes dlaboration dun diagramme dtats transitions ................................................. 23

III. CONCLUSION .................................................................................................................................... 24

I. INTRODUCTION GENERALE
Pour dvelopper un logiciel, il ne suffit pas de se lancer directement dans les lignes de code. Le dveloppement dune application exige une prparation rigoureuse : Il faut documenter ses ides, dfinir et organiser les diffrents modules de lapplication et prciser les tapes de ralisation. Cette tape ultime, dans la technologie objet, se nomme modlisation. Cest une dmarche antrieure au codage, c'est--dire la ralisation des modules de lapplication. Elle comprend lanalyse des besoins utilisateurs et la conception des objets du systme ; le but tant de produire le plus rapidement possible une application qui satisfasse au mieux ses utilisateurs et dassurer la comprhension de systmes souvent complexes. Dans le prsent document, il sagit de dtailler un des langages de modlisation les plus en vogue, UML, car intgrant le concept objet dans son formalisme et permettant dobtenir une modlisation de trs haut niveau indpendante des langages et des environnements. UML (Unified Modeling Language) est donc un langage unifi de modlisation permettant de modliser un problme de faon standard et de fournir une notation standard utilisable dans le dveloppement de systmes informatiques bass sur lobjet. Il est n de la fusion de plusieurs mthodes existant auparavant et a t conu pour permettre la modlisation de tous les phnomnes de lactivit dune entreprise et ce indpendamment des techniques dimplmentation mises en uvre par la suite. UML est devenu actuellement la rfrence en termes de modlisation objet. Il est signaler quUML ne suffit pas lui seul produire un dveloppement logiciel de qualit. Ce nest quun ensemble de formalismes, un outil permettant dapprhender un problme. Le succs du dveloppement du logiciel dpendra surtout de la faon dont on utilisera UML lintrieur du cycle de dveloppement du logiciel ce qui permettra par exemple dtendre la rutilisabilit de ce dernier. a. Les objectifs du langage UML

UML est un langage formel et normalis qui nous offre un gain de prcision avec un gage de stabilit car tant un support de communication performant, facile et comprhensible du fait de sa souplesse. Lutilisation de lapproche objet avec UML rduit lcart entre le langage utilisateur et le langage conceptuel. Il est aussi adapt toutes les phases de dveloppement logiciel et compatible avec toutes les techniques de ralisation. Les objectifs de ce langage de modlisation sont multiples : Proposer un langage visuel de modlisation ce qui rduit lambigit dun systme complexe. Etre indpendant des langages particuliers de programmation. Coordonner les quipes danalyse et de conception et sparer lanalyse de la ralisation. Exprimer dans un seul modle tous les aspects statiques, dynamiques ou mme de spcification. Prendre en compte lvolution de lanalyse et du dveloppement. Migrer facilement vers une architecture objet dun point de vue statique et dynamique. Encourager galement lapplication des outils orients objets. Disposer dune possibilit de gnrer automatiquement la partie logicielle du systme.

Etc.

b.

Lapproche Orient Objet

La programmation oriente objet consiste modliser un ensemble dlments dune partie du monde rel en un ensemble dentits informatiques appels objets. Elle repose sur un certains nombre de concepts qui sont des abstractions permettant de modliser plus facilement le comportement dun programme. Ces diffrents concepts de base sont entre autres : les Objets Les Classes dobjets correspondant une entit abstraite dun niveau suprieur Lassociation des donnes et des traitements dans une mme entit Lencapsulation masquant les donnes et traitements internes de lobjet Des niveaux daccs aux donnes et traitements (publique, priv, protg) La sparation des interfaces de manipulation de limplmentation des traitements Lhritage (gnralisation et spcialisation). Le polymorphisme, un mcanisme permettant linvocation doprations sur des objets avec abstraction du type de lobjet destinataire du message. Le principe de lapproche objet est donc de modliser des proprits statiques et dynamiques de lenvironnement dans lequel sont dfinis les besoins ce qui permettra de rduire lcart smantique entre la ralit et les diffrents modles. c. La dmarche UML

Dans le cadre de la modlisation d'une application informatique, UML prconise une dmarche : Guide par les besoins des utilisateurs du systme

Le primtre du systme modliser est dfini par les besoins des utilisateurs tant donn que le systme doit rpondre aux exigences de ces derniers. Centre sur larchitecture logicielle

Une architecture adapte est la cl dun succs d'un dveloppement. Elle dcrit des choix stratgiques qui dterminent en grande partie les qualits du logiciel (adaptabilit, performances, fiabilit...). Cette dmarche peut tre simplifie en un ensemble de techniques permettant de passer des modles de lapplication au codage de lapplication : 1. 2. 3. 4. 5. 6. Identification des cas dutilisation Ralisation du diagramme de squences Description le modle conceptuel Elaboration de diagramme dinteraction Ralisation du diagramme des classes de conception Production du code

II. LES DIAGRAMMES UML

Les diagrammes UML fournissent les informations sur un problme et sa solution. Ils forment les modles du systme (spcifier, visualiser) et peuvent montrer tout ou partie des caractristiques des lments de modlisation, selon le niveau de dtail utile dans le contexte dun diagramme donn. UML distingue principalement 9 sortes de diagrammes (13 avec la nouvelle version UML2.0) reparties sur trois axes de modlisation pour reprsenter les diffrents points de vue de modlisation : Vue fonctionnelle : Le diagramme des cas dutilisation Vue statique : Le diagramme des classes Le diagramme dobjet Le diagramme dimplmentation Le diagramme de dploiement Vue dynamique : Le diagramme de squence Le diagramme de collaboration Le digramme dtat Le diagramme dactivit

Dans le prsent rapport, on invoquera les modles qui ont t principalement voqus durant notre formation UML.

Chap. I Les diagrammes des cas dutilisation

1. Dfinition et Objectifs

Un cas dutilisation est tout simplement la description des interactions entre lutilisateur et le systme. Il sagit ici dlaborer un diagramme qui permet aux utilisateurs de structurer et darticuler leurs dsirs ; un diagramme qui les oblige dfinir la manire dont ils voudraient interagir avec le systme, prciser quelles informations ils entendent changer et dcrire ce qui doit tre fait pour obtenir le rsultat escompt. Les cas dutilisation (use cases) ont pour objectif dans la modlisation UML :

De concrtiser le futur systme dans une formalisation proche de lutilisateur. De favoriser la dfinition dun cahier des charges refltant rellement de lutilisateur final du systme. De donner une vision globale du comportement fonctionnel du systme logiciel. De servir dun support de communication exprimant ce que le client (lutilisateur final) attend du systme.

Ils forment dans leur ensemble des squences dactions observables, reprsentant les diffrentes manires de se servir fonctionnellement du systme. En produisant une collection des uses cases, on arrive dcrire lensemble des fonctionnalits dvelopper dune faon claire et comprhensible pour tous les intervenants du projet. Il sagit donc l dune conception du systme centre sur lutilisateur et sur les taches quil peut accomplir.

2. Notations et Variantes
La modlisation UML intgre dans son formalisme certaines notions pour reprsenter le diagramme des cas dutilisations. On distingue : Le cas dutilisation Les acteurs du systme Les diffrentes relations entre acteurs, entre cas dutilisation et entre acteur et cas dutilisation Description textuelle des cas dutilisation Les scenarios a. Le cas dutilisation

Le cas dutilisation reprsente la fonctionnalit du systme. Dans la notation UML, il est dcrit par un verbe linfinitif et un complment. Il est reprsent en UML par une ellipse contenant un nom dcrivant la fonctionnalit du cas et ventuellement un strotype :

<<stereotype>> Nom du cas d' utilisation

b.

Les acteurs

Un acteur est un lment externe qui interagit avec le systme. Cet lment peut tre un utilisateur ou un systme tiers. UML distingue 4 grandes catgories dacteurs : Les acteurs principaux qui utilisent les fonctions principales du systme Les acteurs secondaires, ceux qui effectuent des tches administratives ou de maintenance Le matriel externe, un dispositif matriel faisant partie du domaine de lapplication et devant tre utilis.

Les autres systemes externes, qui doivent interagir avec le systme modliser.

Un acteur peut tre reprsent en UML sous forme dun bonhomme (par exemple pour les acteurs principaux et secondaires) : Exemple :

Etudiant

On peut galement le reprsenter sous forme dun classeur lorsquil sagit par exemple de reprsenter un acteur systme externe ou matriel externe : Exemple :

c.

Les relations dans un diagramme des use cases

UML fournie de nombreuses relations entre acteurs du systme ou entre cas dutilisation pour mieux structurer un diagramme des cas dutilisation et le rendre plus comprhensible : Les relations entre acteur et cas dutilisation

UML dfinit une relation entre acteurs et cas dutilisation, la relation dassociation. Cette relation correspond prcisment a un potentiel de communication entre acteurs et systme. Les relations entre cas dutilisation, qui permettent dorganiser les interactions.

UML distingue trois types de relation standard entre cas dutilisation : <<include >> : un cas dutilisation qui incorpore explicitement et de manire obligatoire un autre cas dutilisation l endroit spcifi. <<extend>> : un cas dutilisation qui incorpore implicitement de manire facultative un autre cas dutilisation l endroit spcifi. Dans une relation dextension entre cas dutilisation, le cas dutilisation source ajoute son comportement au cas dutilisation destination. Gnralisation, une relation qui permet un sous cas dutilisation de spcialiser le comportement dun cas dutilisation de base. Exemple :

Authentification

<<include>>

Administrer les candidatures CEDST <<extend>> <<extend>>

Consulter les candidats

valider inscription

Les relations entre acteurs

La seule relation possible entre acteurs est la relation dhritage qui permet dviter de surcharger le diagramme car un acteur qui hrite dun autre acteur hrite aussi de toutes ses associations. Exemple :

Passer une commande Prpos aux commandes

Suivre une commande

Grer le stock Directeur des ventes

d.

Description textuelle des cas dutilisation

Le diagramme de cas dutilisation dcrit les grandes fonctions dun systme du point de vue des acteurs, mais nexpose pas de faon dtaille le dialogue entre les acteurs et les cas dutilisation.il est

donc recommand de rdiger une description textuelle car cest une forme souple qui convient dans bien des situations. Lide est de fournir un format de prsentation textuelle la fois souple et riche. Une description textuelle dun cas dutilisation se compose essentiellement de 3 parties : La premire permettant didentifier le cas dutilisation et doit contenir les informations suivantes : Le nom du cas Lobjectif, une description rsume permettant de comprendre lintention principale du cas dutilisation Les diffrents acteurs (principaux et secondaires) Les dates de cration et de mise jour de la description courante Le nom des responsables et le numro de version La deuxime partie contient la description du fonctionnement du cas sous la forme dune squence de messages changs entre les acteurs et le systme. Elle contient toujours une squence (scenario) nominale qui dcrit le droulement normal du cas. la squence nominale peuvent sajouter des squences alternatives et des squences dexceptions (qui interviennent quand une erreur se produit). Dans cette partie, on spcifiera donc les lments suivants : Les pr- conditions, dcrivant dans quel tat doit tre le systme avant que ce cas dutilisation puisse tre dclench Les diffrents scnarios dcrits sous la forme dchange dvnements entre lacteur et le systme Les post conditions dcrivant ltat du systme a lissu des diffrents systmes

La troisime partie, qui est une rubrique optionnelle, contient gnralement des spcifications non fonctionnelles. Elle peut ventuellement contenir une description des besoins en termes dinterface graphique.

e.

Les scnarios

En plus du diagramme des cas dutilisation, les cas dutilisation serviront laborer des scnarios de cas d'utilisation. Les scenarios consistent en une description textuelle de chaque cas d'utilisation. On y dtaillera de faon textuelle toutes les interactions entre les acteurs et l'application ; en prcisant aussi les variantes possibles dun mme scenario. Un cas dutilisation propose en effet diffrents comportements : Un scnario nominal, idal, dcrivant les interactions entre lacteur et le cas dutilisation dans un cas typique de succs. Un scnario alternatif proposant un flot dvnements alternatifs qui peuvent soit revenir au scnario nominal ou dboucher a un chec Un scnario dexception, levant le cas ou linteraction dbouche vers un chec

En rdigeant un scnario de cas d'utilisation, on doit considrer le systme comme une bote noire qui ne peut qu'accepter des requtes provenant des acteurs, et retourner des rsultats ces mmes acteurs. On se proccupe pas savoir comment cette bote noire accomplit les requtes.

Les cas d'utilisation font aujourd'hui partie intgrante dUML et constituent d'ailleurs le premier critre prendre en compte dans le choix de la mthode associe UML. Ils font rfrence aux acteurs, c.-d aux "choses" externes au systme et qui communiquent avec le systme. La dmarche consistera donc identifier les diffrents acteurs du systme et pouvoir recenser les diffrents cas dutilisation du systme.

3. Une tude de cas

Pour mieux illustrer toutes les tapes de modlisation UML dans la specification des cas dutilisation, faisons une tude de cas spcifique. Dans notre exemple, il sagit de modliser un systme e-

commerce Enonc :
Le commerce lectronique dans cette tude de cas, concerne le processus dachat/vente de livres sur Internet. La socit BookStore est spcialise dans la vente de livres de tout type (science, littrature, Art, etc) et sur tout support (livre papier, numrique, DVD, etc..). BookStore reoit ses commandes par fax et les chques par courrier puis envoie le bon de commande au client. Une fois le chque encaiss par la banque partenaire BookBank, elle utilise la socit de transport BookEx pour acheminer les livres vers leurs clients. La socit BookStore possde un systme Gestion des stocks qui met jour les donnes concernant le prix et ltat du stock des livres du catalogue. Ce systme est automatiquement charg dans la base de donnes de faon priodique. Actuellement, La socit BookStore souhaite raliser un site e-commerce pour grer seulement la vente de ses livres en ligne, grer son catalogue de livre et sa base de donnes de clients. Lobjectif fondamental du futur site BookStore est de permettre aux internautes de rechercher des ouvrages par thme, auteur, mot-cl, etc., de se constituer un panier virtuel, puis de pouvoir les commander et les payer directement sur le Web. 1. Diagramme de cas dutilisation. a. Identifier les acteurs du systme. b. Identifier les cas dutilisation. c. Etablir le diagramme de cas dutilisation final

10

Solution propose
1. La premire tape consiste identifier les diffrents acteurs du systme. Qui utilise le systme ? Qui maintient le systme? Quels sont les autres systmes qui utilisent le systme ? Qui rcupre de linformation partir du systme ? Ainsi, on pourra facilement identifier les acteurs du systme e-commerce prsent. on a comme acteurs externes du systme : -Un internaute naviguant sur le site e-commerce - Un visiteur voulant sinscrire pour devenir membre -Un client de la socit BookStore -Le systme de gestion de stock -Ladministrateur du site -La banque BookBank pour encaisser les chques 2. Deuxime tape, identification des cas dutilisation. Pour identifier les cas

Pour y parvenir, on se posera des questions comme :

dutilisation, il faut se placer du point de vue de chaque acteur et dterminer comment et surtout pourquoi il se sert du systme. On notera par exemple que : Un visiteur du site e-commerce pourra sinscrire et devenir membre du site Un internaute devra pouvoir rechercher des ouvrages et grer son panier Un client membre du site pourra commander un livre par exemple et le payer Un client membre devra sauthentifier pour accder au systme Le systme de gestion de stock est utilise pour maintenir le catalogue Ladministrateur du site pourra par exemple grer les clients et maintenir le site

3.

Avec la troisime tape, il sagit de dessiner le diagramme des cas dutilisation. Loutil de modlisation utilis dans notre tude est le powerAMC.

11

S'inscrire Visiteur

Maintenir le catalogue

Systeme Gestion de Stock Maintenir le site Rechercher ouvrage

<<include>> Internaute Se constituer un panier

Verifier le catalogue Administrateur du site

<<include>>

<<include>> Commander

S'authentifier

<<include>> Gerer les clients

<<include>> Client

Payer

BookBank

Signalons que dans la ralisation dun diagramme de cas dutilisation, il nest pas conseill de spcifier tous les cas possible. Un certain niveau dabstraction est recommand, en reprsentant juste les cas dutilisation gnraux du systme.

Chap. II. Le diagramme de squence

1. Dfinition et Objectifs

Pour accompagner la description textuelle des cas d'utilisation, UML fournit un autre modle de diagramme, le diagramme de squences. Le diagramme de squences permet de reprsenter des collaborations entre objets selon un point de vue temporel c.--d en mettant l'accent sur la

12

chronologie des envois de messages. Il modlise donc les interactions acteurs/systme dans les scenarios spcifiques et est le plus rpandu des diagrammes dinteraction. Il est utile pour mieux comprendre la squence des oprations dans un cas d'utilisation. Voici comment il fonctionne : 1. 2. 3. On place les acteurs gauche et, droite, le systme entier reprsent par une bote. On ajoute ensuite des lignes verticales qui reprsente le passage du temps, du haut vers le bas. Les interactions entre l'utilisateur et le systme sont marques par une ligne, avec une flche indiquant la direction du message. Une description de l'interaction est crite au-dessus de la flche. Exemple du cas dutilisation retrait argent dans un distributeur automatique

Il est possible de reprsenter dans un diagramme de squence des structures de contrle, de cration et de destruction dobjet, des branchements conditionnels et mme des contraintes temporelles.

2. Type de message
Les principales informations contenues dans un diagramme de squence sont les messages changs entre les lignes de vie, prsents dans un ordre chronologique. Un message dfinit donc une communication particulire entre des lignes de vie (objets ou acteurs). Les diagrammes de squence distinguent deux grandes catgories denvoi de message: Les envois synchrones pour lesquels lmetteur est bloqu et attend que lappel ait fini de traiter le message. Les envois asynchrones pour lesquels lmetteur nest pas bloqu et peut continuer son excution

13

Exemple :

Les messages simples et synchrones sont tous deux synchrones. Ce qui les diffrentie, cest le mode de contrle. Un message simple convient pour les systmes un seul flot de contrle, donc automatiquement lmetteur est bloqu jusqu la rponse du destinataire. Un message synchrone convient aux systmes plusieurs flots de contrle, lmetteur a son propre flot de contrle mais il reste nanmoins bloqu jusqu la rponse du destinataire. Pour pouvoir diter les proprits dun message, lobjet destinataire doit tre instance dune classe.

3. Activation et envoi des messages

Les diagrammes de squence permettent de reprsenter les priodes dactivit des objets. Une priode dactivit correspond au temps pendant lequel un objet effectue une action, soit directement, soit par lintermdiaire dun autre objet qui lui sert de sous-traitant. Les priodes dactivit se reprsentent par des bandes rectangulaires places sur les lignes de vie. Le dbut et la fin dune bande correspondent respectivement au dbut et la fin dune priode dactivit.

4. Fragments dinteraction combins.

Un fragment combin reprsente des articulations dinteractions. Il est dfini par un oprateur et des oprandes. Loprateur conditionne la signification du fragment combin. Les fragments combins permettent de dcrire des diagrammes de squence de manire compacte et peuvent faire intervenir lensemble des entits participant au scnario ou juste un sous-ensemble. Un fragment combin se reprsente de la mme faon quune interaction. Il est reprsent dans un rectangle dont le coin suprieur gauche contient un pentagone. Dans le pentagone figure le type de la combinaison, appel oprateur dinteraction. Les oprandes dun oprateur dinteraction sont spars par une ligne pointille. Les conditions de choix des oprandes sont donnes par des expressions boolennes entre crochets ([ ]). La liste suivante regroupe les oprateurs dinteraction par fonctions :

les oprateurs de choix et de boucle : alternative, option, break et loop ; les oprateurs contrlant lenvoi en parallle de messages : parallel et critical region ; les oprateurs contrlant lenvoi de messages : ignore, consider, assertion et negative ;

14

les oprateurs fixant lordre denvoi des messages : weak sequencing , strict sequencing.

Dans notre formation UML, nous navions abord que quelques-unes de ces interactions, celles plus frquemment utilises savoir les oprateurs de choix et de boucle (alt, loop et option) ainsi que loperateur de rutilisation dune interaction, ref. loperateur alt

L'oprateur alt dsigne un choix, une alternative. Il reprsente deux comportements possibles : c'est en quelque sorte l'quivalent du SI...ALORS...SINON : donc, une seule des deux branches sera ralise dans un scnario donn. La condition d'excution d'une des deux branches (l'quivalent du SI) peut tre explicite ou implicite. L'utilisation de l'oprateur else permet d'indiquer que la branche est excute si la condition du alt est fausse. Exemple : cas dutilisation Paiement du systme e-commerce
Paiement

:System client Bookbank

ref passerCommande()

choisir mode de paiement

alt

montant<somme

cumulerMontant()

montant>=somme effectuer_Transaction()

loperateur opt

Loperateur opt dsigne un fragment combin optionnel, c'est dire qu'il reprsente un comportement qui peut se produire ou pas. Un fragment optionnel est quivalent un fragment "alt" qui ne

15

possderait pas d'oprande else (qui n'aurait qu'une seule branche). Un fragment optionnel est donc une sorte de SI...ALORS Exemple : le cas dutilisation rechercher ouvrage du system e-commerce
Rechercher_ouvrage

:System internaute

ChoisirLivre(theme,auteur,editeur)

AfficherLivre()

opt

[choix du livre] AjouterPanier()

loperateur loop

Loprateur loop est utilis gnralement pour dcrire un ensemble d'interaction qui sexcute en boucle. En gnral, une contrainte indique le nombre de rptitions (minimum et maximum) ou bien une condition boolenne respecter. Exemple : supposons un cas dutilisation communication dun systme tlphonique

16

Communication

CT Appelant decrocher() Appel

tonalite

composer_Numero(numAbon)

sonner() loop emettre()

sonner()

transferer() emettre() transferer()

raccrocher() findecommunication() raccrocher()

loperateur ref

Une interaction peut faire rfrence a une autre explicitement grce a un cadre avec le mot cl ref Exemple : le cas dutilisation passer commande du systme e-commerce

17

En conclusion, ces diagrammes nous permettent de mieux cerner laspect dynamique du systme. Il sagit dune reprsentation intuitive lorsque lon souhaite concrtiser des interactions entre deux entits (deux sous-systmes ou deux classes dun futur logiciel) .Ils prsentent des messages changs entre des objets selon un point de vue temporel (chronologie denvoi des messages et ligne de vie des objets) et diffrent pour chaque dutilisation.

Chap. III. Le diagramme des classes

1. Dfinition et Objectifs

Le diagramme des classes est le diagramme le plus largement rpandu dans les spcifications d'UML. Il sagit dun lment important dans une dmarche de conception oriente objet, reprsentant les diffrentes entits (classes dobjet) intervenant dans le systme modliser ainsi que les diffrentes relations entre celles-ci. Il offre une vue statique du systme car il fait abstraction des aspects temporels et dynamiques. Llment classe dans la modlisation dun diagramme de classes dcrit les responsabilits, le comportement et le type dun ensemble dobjets. Il sagit dun ensemble de fonctions et dattributs qui sont lis ensemble par un champ smantique. Les diagrammes des classes permettent donc de dcrire dune manire gnrique le comportement du systme. Les autres lments associs la modlisation dun diagramme de classes sont : Les spcifications gnrales de la classe (type, parent) Les spcifications dtailles de la classe (cardinalit,) Les attributs et oprations de la classe Les associations entre classes Les dpendances

18

2. Notations et Variantes

Les lments d'un diagramme des Classes sont principalement les classes et les relations qui les lient. a. Classe

La notion de classe est essentielle en programmation oriente objets ; elle dfinit une abstraction, un type abstrait qui permettra plus tard dinstancier des objets. On distingue gnralement des classes abstraites (qui ne peuvent pas tre instancies directement) et des classes "normales" qui servent dfinir des objets. UML tant un langage de modlisation objet, il a la possibilit de reprsenter une classe. Dans la notation UML, une classe est dcrite par un rectangle compose de trois compartiments : Le premier au niveau suprieur contenant le nom de la classe Le second pour la liste des attributs de la classe Le dernier pour numrer les mthodes de la classe

Exemple : classe Animal

Les deux derniers compartiments ne sont pas forcment reprsents. b. Les relations entre les classes

Les diverses classes possdent des relations de dpendance entre elles. Cette communication interclasse est effectivement primordiale car la manire dont les messages sont changs entre les objets est un aspect important de la POO. Elles dfinissent le fonctionnement du programme. UML dfinit cinq types de relation interclasse qui sont couramment utiliss (il en existe d'autres) a savoir : -

Lhritage La dpendance Lagrgation La composition Lassociation

Chacune delle rpond un contexte d'utilisation, et offre des avantages parfois subtils mais rels. Lhritage

Elle prsente une classe spcifique comme descendante d'une classe plus gnrique. Cette classe spcifique propose des mthodes dont la classe gnrique ne dispose pas, tout en conservant la

19

plupart des mthodes de cette classe "parente". En UML, une dpendance est reprsente par une ligne en tirets, termine par une flche vide.

La dpendance

La relation de dpendance prsente l'utilisation que fait une classe d'une autre. Une classe dpend d'une autre si ses mthodes manipulent l'objet de cette classe. Par exemple, une classe Rservation ne pourrait exister que si la classe Compte indique les coordonnes de la personne... La dpendance est souvent strotype pour mieux expliciter le lien smantique entre les lments du modle. En UML, une dpendance est reprsente par une ligne en tirets, termine par une simple flche.

Lagrgation

Une relation d'agrgation indique un principe de subordination entre l'agrgat (classe qui regroupe les classes agrges) et les agrges. Concrtement, elle indique une "possession", une relation de contenant contenu. En UML, une agrgation est reprsente par une ligne entre deux classes, termine par un losange vide ("diamant") du ct de l'agrgat.

La composition

Il s'agit en fait d'une agrgation laquelle on impose des contraintes internes : un seul objet peut faire partie d'un composite (l'agrgat de la composition), et celui-ci doit grer toutes ses parties. En clair, les composants sont totalement dpendants du composite. En UML, la composition est reprsente de la mme manire que l'agrgation, mais le diamant est plein.

Lassociation

La relation dassociation existe partir du moment o l'une des deux classes sert de type un attribut de l'autre, et que cet autre envoi des messages la premire (condition ncessaire pour une association). Simplement, une association indique que deux classes communiquent entre elles (dans un sens ou dans les deux sens). En UML, Elle est modlise par une ligne reliant les deux classes. Cette ligne peut tre qualifie avec le type de relation, et peut galement comporter des rgles de multiplicit (par exemple un un, un plusieurs, plusieurs plusieurs) pour la relation.

20

3. Une tude de cas

Notre tude de cas concerne le systme e-commerce dj tudi ci-haut. Il sagit maintenant dlaborer le diagramme des classes correspondant.

Solution propose.
0..* Ligne 0..* - qtite - montant 0..1 0..* 1..* 0..* Theme - libelle 0..1

Ouvrage 0..1 1..* Panier 0..* - total 0..1 1 1..* Editeur 0..1 Client nom prenom login password email 0..* Commande numCommande date montant delai - nom - pays Auteur - nom - prenom ISBN titre date de parution prix 1..*

0..1 0..*

BookBank

1..* adresse facturation

Adresse - adr 1..1

0..* adresse livraison

1..1

Chap. IV. Le diagramme dtat - transition

1. Dfinition et Objectifs

Les diagrammes dtats-transitions dUML dcrivent le comportement interne dun objet laide dun automate tats finis. Ils prsentent les squences possibles dtats et dactions quune instance de classe peut traiter au cours de son cycle de vie en raction des vnements discrets. Ils spcifient habituellement le comportement interne dautres lments tels que les cas dutilisation, les soussystmes, les mthodes. Le diagramme dtats-transitions est le seul diagramme, de la norme UML, offrir une vision complte et non ambigu de lensemble des comportements de llment auquel il est attach. En effet, un diagramme dinteraction noffre quune vue partielle correspondant un scnario sans spcifier comment les diffrents scnarios interagissent entre eux. La vision globale du systme napparat pas

21

sur ce type de diagramme puisquils ne sintressent qu un seul lment du systme indpendamment de son environnement. Concrtement, un diagramme dtats-transitions est un graphe qui reprsente un automate tats

finis, cest--dire une machine dont le comportement des sorties ne dpend pas seulement de ltat
de ses entres, mais aussi dun historique des sollicitations passes. Ces diagrammes nous permettent donc : de dcrire les changements d'tats d'un objet ou d'un composant, en rponse aux interactions avec d'autres objets/composants ou avec des acteurs. De reprsenter lvolution du systme au cours du temps en raction aux vnements externes. De reprsenter une conjonction instantane des valeurs des attributs dun objet.

2. Notation et variantes
Un diagramme dtats est un graphe orient dtats et de transitions. Exemple :

Les diagrammes dtat-transition sont bass sur les notions suivantes : Ltat dun objet Dans llaboration dun diagramme dtat-transition, ltat reprsente une situation dans laquelle peuvent se trouver les objets dune classe durant leur vie. Il a une dure finie, variable selon la vie de lobjet, en particulier en fonction des vnements qui lui arrivent. Un objet passe donc par une succession dtats durant son existence En plus de la succession dtats normaux correspondant au cycle de vie dun objet, le diagramme dtats comprend galement deux pseudo-tats a savoir: Ltat initial du diagramme dtats correspondant la cration de linstance. Ltat final du diagramme dtats correspondant la destruction de linstance.

Exemple :

Un vnement qui est un stimulus interne ou externe envoy lobjet. Il se produit

Instantanment lchelle dvolution du systme et est not entre guillemets. Un vnement peut tre

reu ou envoy par un objet.

Transition

Une transition indique le passage dun tat dun objet a un autre tat lorsquun vnement se produit. Elle est reprsente par une flche pointe de ltat de dpart vers ltat darrive et qui porte les paramtres des vnements qui lui sont associs. Exemple :

22

Un message qui est lvnement mis entre deux objets, lobjet metteur et lobjet

rcepteur. Le mode de communication peut tre synchrone ou asynchrone. Condition qui est une expression boolenne qui doit tre vraie lorsque lvnement

arrive pour que la transition soit dclenche.

Effet, action ou activit

Une transition peut spcifier un comportement optionnel ralis par lobjet lorsque la transition est dclenche. Ce comportement est appel effet. Cela peut tre une simple action ou une squence dactions (une activit). Soulignons que les activits associes aux transitions sont considres comme atomiques, cest-dire quelles ne peuvent tre interrompues.

3. Etapes dlaboration dun diagramme dtats transitions

Identifier les tats dune classe. Sil y a des valeurs seuil dattributs ou de

comportements conditionnels qui modifient le comportement dynamique, il faut dfinir les tats en dterminant les vnements reus et mis par les objets. Reprsenter le scnario principal qui dcrit la squence essentielle dvnements. Ajouter progressivement les transitions correspondant aux scnarios secondaires, qui

dcrivent les comportements alternatifs et derreur. Reprer les boucles. Si le scnario peut se rpter indfiniment, boucler le chemin

dans le diagramme. Complter les actions sur les transitions et les activits dans les tats. Structurer en sous-tats, si le diagramme est devenu trop complexe.

Il est souhaitable de construire un diagramme dtats-transitions pour chaque classe possdant un comportement dynamique important.

23

III. CONCLUSION

Dans le but dassurer la qualit logicielle et de rduire les risques quelconques lies au dveloppement logiciel, il simpose dtablir des plans permettant dorganiser les diffrents modules de lapplication et de prciser les tapes de ralisation ; donc de mettre en place une phase de modlisation. Les langages de modlisation sont nombreux mais UML sest impose car, intgrant dans ses formalismes lapproche objet, il permet de mieux matriser la part d'inconnu et d'incertitudes qui caractrisent les systmes complexes et de faciliter la maintenance du logiciel. UML est donc un langage de modlisation qui permet, outre le fait de se concentrer sur lutilisateur, de documenter trs clairement les besoins exprimes par ces derniers dans le cadre dune gestion de projet de dveloppement qui va de la conception jusquau dploiement de lapplication. UML nous fourni un ensemble de diagrammes regroupes en modles fonctionnel, statique et dynamique qui permettent de modliser un systme dinformations. Durant notre formation, on a labor quatre de ces diagrammes qui, dans lensemble, prsentent au mieux les besoins fonctionnels : Le diagramme des cas dutilisation dcrivant les fonctions du systme du point de vue de ses utilisateurs Le diagramme de squence reprsentant la succession chronologique des oprations ralises par un acteur. Le diagramme des classes pour reprsenter larchitecture conceptuelle du systme a modliser. Le diagramme dtat transitions dcrivant le comportement dune classe en terme dtats li au cycle de vie des objets.

24