Analyse et Conception objet du logiciel

L approche Oriente Objet et UML

Rmy Courdier

email : Remy.Courdier@univ-reunion.fr
Rmy Courdier - V1.11 1

Analyse et Conception objet du logiciel

Plan du cours
! !

Introduction au Gnie Logiciel L approche Oriente Objet et Notation UML

!Les
! ! !

diagrammes de modlisation

Relations entre les diffrents diagrammes De l analyse la conception Relation entre les notations OMT et UML

Rmy Courdier - V1.11

Analyse et Conception objet du logiciel

3. Les diagrammes de modlisation

Chapitre 3 : Les diagrammes de modlisation

! ! ! ! ! ! ! ! !

Les diagrammes d objets Les diagrammes de collaboration Les diagrammes de classes Moyens de Les diagrammes de cas d utilisationvisualiser et de manipuler des Les diagrammes de squence lments de Les diagrammes d tats-transitions modlisation Les diagrammes d activits Les diagrammes de composants Les diagrammes de dploiement
3

Rmy Courdier - V1.11

Analyse et Conception objet du logiciel

3. Les diagrammes de modlisation 3.1 Diagrammes d objets, de collaboration et de classes

3.1Diagrammes objets, de collaboration et de classes

!

Les diagrammes d objets (ou d instances)

! reprsenter les objets et leurs relations sans reprsenter les envois de messages (reprsentation statique). ! permettre la comprhension gnrale du systme ! faciliter la comprhension des structures complexes (rcursives)

Les diagrammes de collaboration

! correspondent une extension des diagrammes d objets. ! reprsentation de la structure spatiale statique qui permet la mise en relation d un groupe d objets ! reprsentation des interactions entre objets.

Les diagrammes de classes

! reprsente la structure abstraite statique en terme de classe et de relations ! description abstraite des liens potentiels d un objet vers Rmy Courdier - V1.11 d autres objets 4

Analyse et Conception objet du logiciel

Petits conseils pour un schma UML efficace

!

Lorsque l'on passe la conceptualisation d'une application de taille, on garde souvent les mauvaises habitudes datant de diagrammes plus simples. Voici quelques rgles pour raliser des diagrammes clairs et lisibles par tous. !
! Placer avant de relier Les petits projets n'ont qu'un temps, et il faut rapidement perdre l'habitude de construire son diagramme UML au fur et mesure, associer deux classes par une ligne ds que celles-ci sont cres. Bien au contraire, l'utilit d'UML tant de vous permettre de rflchir votre application avant de vous lancer dans sa ralisation, il faut prendre (et non "perdre") son temps faire la liste de tous les lments placer dans le diagramme, ensuite seulement les placer de manire logique dans le diagramme, et enfin, en tout dernier, associer les lments entre eux.

Rmy Courdier - V1.11

Analyse et Conception objet du logiciel

Petits conseils pour un schma UML efficace (2)

! Ne pas croiser les associations L'association entre deux lments est primordiale la bonne comprhension d'un diagramme. Autant que faire se peut, il faut viter de placer les lments de telle sorte que leur association puisse se croiser : un ensemble d'associations clairement distinctes permet une lecture beaucoup plus rapide de l'ensemble du diagramme. Dans le cas o deux associations doivent se croiser, il faut bien marquer la distinction entre celles-ci : au point de croisement, l'une d'entre elles doit faire un "saut" par-dessus l'autre, indiquant ainsi qu'elle ne sont pas lies. ! Mettre des codes couleurs Mme avec des lments bien disposs et des associations distinctes, le diagramme d'une grosse application peut facilement devenir illisible l'oeil humain (sans pour autant gner sa lecture par un logiciel). Pour ne pas tre le seul savoir lire votre diagramme, prenez le temps de marquer selon diffrentes couleurs les lments d'une mme catgorie, ou marquer d'une couleur vive les lments principaux de votre diagramme. Il deviendra ainsi un bien meilleur outil de travail de groupe.

Rmy Courdier - V1.11

Analyse et Conception objet du logiciel

Conseils Mthodologiques (suite)

! Diviser pour mieux rgner Il faut savoir rester sobre : ds que vous vous apercevez que votre diagramme a des grandes chances de contenir beaucoup d'lments dans tous les sens, dcoupez-le en plusieurs sous-diagramme, auxquels le diagramme principal fera rfrence. La plupart des outils de conception UML vous permettent de lier deux fichiers UML directement depuis l'interface : n'hsitez pas y faire appel ! Accessoirement, cela vous permet de simplifier votre diagramme lors de prsentation vos managers ou d'autres groupes, probablement peut intresss par les dtails... ! Mettre du sens N'oubliez jamais d'utiliser des flches l o elles sont requises, c'est-dire dans une association sens unique, indiquant qu'un message ne peut tre transmis que dans un seul sens. Cela implique de nombreuses choses au niveau de dveloppement, et savoir qu'un lment n'a pas besoin d'mettre des messages, mais seulement d'en envoyer, peut simplifier de beaucoup la ralisation de l'application.

Rmy Courdier - V1.11

Analyse et Conception objet du logiciel

3. Les diagrammes de modlisation 3.2 Diagrammes de cas d utilisation

3.2 Les Diagrammes de cas d utilisation

!

Dfinition
! Description sous forme d actions et de ractions du comportement d un systme du point de vue de l utilisateur

Objectif
! Dfinir les limites du systme concevoir ! Dfinir les relations entre le systme et l environnement ! Partitionner l ensemble des besoins d un systme

Notation UML
! Un utilisateur ou acteur est reprsent par un petit personnage, un cas d utilisation ou fonctionnalit du systme par un ovale, les flches issues d un personnage pointent vers les cas d utilisation. systme
retrait client virement
8

Rmy Courdier - V1.11

Analyse et Conception objet du logiciel

3. Les diagrammes de modlisation 3.2 Diagrammes de cas d utilisation(2)

Les acteurs
!

Quatre catgories d acteurs

! acteurs principaux : utilisent les fonctions principales du systme ! acteurs secondaires : tches administratives ou de maintenance ! matriel externe : dispositifs matriels incontournables utiliss ! autres systmes : systmes avec lesquels le systme doit interagir

Les 3 types de relations entre acteurs et cas d utilisation

! relation de communication : Dclenche
" dclenchement d un cas d'utilisation par un un acteur

! relation d utilisation : Utilise

" un cas d utilisation comprend le comportement d un autre cas d utilisation

! relation d extension : Etend

Rmy Courdier - V1.11

" le cas d utilisation source tend ou enrichi le comportement du cas d utilisation destination

Analyse et Conception objet du logiciel

3. Les diagrammes de modlisation 3.2 Diagrammes de cas d utilisation(3)

Spcification d un cas d utilisation

La spcification d un cas d utilisation comprend : L vnement qui dclenche le cas d utilisation ! L vnement qui cause l arrt du cas d utilisation ! L interaction entre le cas d utilisation et les acteurs ! Les changes d informations ! La chronologie et l origine des informations ! Les rptitions de comportements ! Les situations optionnelles (Choix a, Choix b, Choix c)
!

Rmy Courdier - V1.11

10

Analyse et Conception objet du logiciel

3. Les diagrammes de modlisation 3.3 Les diagrammes de squence

3.3 Les diagrammes de squence

!

! !

Un diagramme de squence montre des interactions entre objets selon un point de vue temporel La reprsentation se concentre sur l expression des interactions Notation :
objet1 message 1 message 2 ex. Dtruire envoi synchrone envoi rflexif envoi asynchrone l expditeur) (expditeur bloqu jusqu acceptation du destinataire) (envoi d un objet soi-mme) (n interrompt pas l excution de
11

objet2

objet3

Rmy Courdier - V1.11

Analyse et Conception objet du logiciel

3. Les diagrammes de modlisation 3.3 Les diagrammes de squence(2)

Priode d activits
Une priode d activit correspond au temps pendant lequel un objet effectue une action
objet1 message 1 objet2 envois synchrone : Le retour est implicite

objet1 message 1

objet2

objet1 message 1

objet2

Retour explicite d envoi asynchrone

Rmy Courdier - V1.11

Retour explicite avant suicide

12

Analyse et Conception objet du logiciel

3. Les diagrammes de modlisation 3.4 Les diagrammes de d tats-transitions

3.4 Les diagrammes d tats-transitions

Un diagramme d tats-transitions est un automate d tats fini dterministe associ une classe
!

Abstraction des comportements possibles

!chaque objet suit le comportement dcrit dans l automate associ sa classe, son tat caractrise ses conditions dynamiques

On associe un tel automate toute classe qui prsente un comportement ractif marqu ! Statecharts de D. Harel
! !D. Harel, Statecharts : A Visual Formalisme for Complexe Systems , Science of Computer Programming, vol. 8, 1987. !Automates hirarchiques, possdant les concepts d orthogonalits, d agrgation et de gnralisation
Rmy Courdier - V1.11 13

Analyse et Conception objet du logiciel

3. Les diagrammes de modlisation 3.4 Les diagrammes de d tats-transitions

Smantique du diagramme
!

Ce diagramme sert reprsenter des automates d'tats finis, sous forme de graphes d'tats, relis par des arcs orients qui dcrivent les transitions. Les diagrammes d'tats-transitions permettent 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. Un tat se caractrise par sa dure et sa stabilit, il reprsente une conjonction instantane des valeurs des attributs d'un objet. Une transition reprsente le passage instantan d'un tat vers un autre. Une transition est dclenche par un vnement. En d'autres termes : c'est l'arrive d'un vnement qui conditionne la transition. Les transitions peuvent aussi tre automatiques, lorsqu'on ne spcifie pas l'vnement qui la dclenche. En plus de spcifier un vnement prcis, il est aussi possible de conditionner une transition, l'aide de "gardes" : il s'agit d'expressions boolennes, exprimes en langage naturel (et encadres de crochets).

! !

Rmy Courdier - V1.11

14

Analyse et Conception objet du logiciel

3. Les diagrammes de modlisation 3.4 Les diagrammes de d tats-transitions(2)

Notations
!

Etat, Transition et Evnement

tat initial Un tat Evnement Un autre tat tat final

la transition : passer d un tat un autre

Un vnement dclenche la transition qui lui est associe

Les gardes
! Une garde est une condition qui valide ou non le dclenchement d une transition lors de l occurence d un vnement ! Elles doivent tre mutuellement exclusives (aspect dterministe)
A Trop chaud [t] Climatiser Trop chaud [hiver] Arer

Evnement[condition]
15

Rmy Courdier - V1.11

Analyse et Conception objet du logiciel

3. Les diagrammes de modlisation 3.4 Les diagrammes de d tats-transitions(3)

Evnements & Oprations, Actions

!

Le lien entre Evnements et Opration du diagramme de classe apparat dans l automate

! Chaque transition peut tre dcore par le nom d une action excuter lorsque la transaction est dclenche par un vnement ! L action correspond une des oprations dclares dans la classe de l objet destinataire de l vnement

Les tats peuvent contenir des actions

! excutes l entre ou la sortie ! excutes lors de l'occurrence d un vnement pendant que l objet est dans l tat Etat A entry: Les mot-cls entry: et exit:
" indique les actions d entre et de sortie
on UnEvnment: exit:

Le mot-cl on Un vnement:
" indique une action sur vnement externe

Une transition rflexive entrane les Rmy Courdier - V1.11 actions de sortie et d entre

Ev1 / UneAction
16

Analyse et Conception objet du logiciel

3. Les diagrammes de modlisation 3.4 Les diagrammes de d tats-transitions(4)

Actions et activits
!

Dfinitions
! Une action correspond une opration dont le temps d excution est ngligeable ! Une activit est une opration qui prend du temps qui est excute pendant qu un objet est dans un tat donn. ! Le mot-cl do: indique une activit ! Activit cyclique : s arrte lorsqu une transition de sortie est dclenche. activit squentielle : l tat peut tre quitt si lorsque l'activit parvient son terme l une des transitions est franchissable

Les 6 types d Actions/Activits

Etat A / Op1 entry:Op2 on UnEvnment: Op3 do: Op4 exit:Op5 / Op6

Rmy Courdier - V1.11

17

Analyse et Conception objet du logiciel

3. Les diagrammes de modlisation 3.4 Les diagrammes de d tats-transitions(5)

Notion avance : Gnralisation d tat

!

Un tat peut tre dcompos en sous-tats disjoints

! tats gnraux = super-tats, tats spcialiss = sous-tats ! l objet doit tre dans un et un seul sous-tat la fois
C1 E1 C2 E2 C1 E2

C3

La transition E2 peut tre factorise

E1

E2

C3

C2

Rmy Courdier - V1.11

18

Analyse et Conception objet du logiciel

3. Les diagrammes de modlisation 3.4 Les diagrammes de d tats-transitions(6)

Notion avance : Agrgation d tat

!

Composition d un tat partir de plusieurs autres tats indpendants

! on parle d agrgation d tats et d tat composant ! l objet doit tre simultanment dans tous les tats composant l agrgation d tats
S T C1 E1 C2 E2 E3 U C1 C3 E1 C2

L tat S - produit cartsien des tats T et U

Rmy Courdier - V1.11 19

Analyse et Conception objet du logiciel

Les diagrammes d tats-transitions : exemple

Le diagramme d'tatstransitions prsent, montre les diffrents tats par lesquels passe une machine laver les voitures. En phase de lustrage ou de lavage, le client peut appuyer sur le bouton d'arrt d'urgence. S'il appuie sur ce bouton, la machine se met en attente. Il a alors deux minutes pour reprendre le lavage ou le lustrage (la machine continue en phase de lavage ou de lustrage, suivant l'tat dans lequel elle a t interrompue), sans quoi la machine s'arrte. En phase de schage, le client peut aussi interrompre la machine. Mais dans ce cas, la machine s'arrtera dfinitivement (avant de reprendre un autre cycle entier).

Lavage

attente lustrage

sechage

Rmy Courdier - V1.11

20

Analyse et Conception objet du logiciel

3. Les diagrammes de modlisation 3.5 Les diagrammes de d activits

3.5 Les Diagrammes d activits

! !

Variante des diagrammes d tats-transitions destine reprsenter le comportement interne d une mthode Ils reprsentent :
! le droulement d tapes regroupes squentiellement ! les synchronisations entre flots de contrles

Notations :
Activit 1 Activit 1

[cond1]

[cond2]

Activit 2

Activit 3

Activit 2

Activit 3

Rmy Courdier - V1.11

21

Analyse et Conception objet du logiciel

3. Les diagrammes de modlisation 3.6 Les diagrammes de composants

3.6 Les diagrammes de composants

Description des lments physiques et leurs relations dans l environnement de ralisation ! Un composant
! lment informatique qui entre dans la fabrication d une application. ! ex : fichiers, paquetage ADA, bibliothque charge dynamiquement,... ! On distingue 3 types de composants : Spcification ou Interface, Corps , Spcification gnrique

Les dpendances entre composants ! Les processus et tches ! Les programmes principaux ! Les sous-programmes ! - V1.11 Rmy CourdierLes sous-systmes
!

22

Analyse et Conception objet du logiciel

3. Les diagrammes de modlisation 3.7 Les diagrammes de dploiement

3.7 Les diagrammes de dploiement

Ils montrent la disposition physique des matriels qui composent le systme ainsi que la rpartition des excutables sur ces matriels
!

Les nuds
! un nud est une ressource matrielle physique
" Dispositif (ex. Modem), Processeur (ex. PC), Mmoire (ex. Disque)

Liens entre nuds

! lignes qui symbolisent un support de communication priori bidirectionnel
" connexion (ex. TCP-IP, RNIS,...)
PC 1 1..10 Porte scurit

*
Rmy Courdier - V1.11

<<RNIS>> 1

Serveur
23

Analyse et Conception objet du logiciel

Fin du Chapitre 3

Les diagrammes de modlisation

Rmy Courdier - V1.11

24