Académique Documents
Professionnel Documents
Culture Documents
Programme
Introduction Besoin de modles Diagrammes de classes Reverse Engineering Rtro conception et patrons de conception Gnration de code Diagrammes de squence Diagrammes de cas dutilisation
21/11/2012
Le gnie logiciel
Le gnie logiciel est lensemble des rgles quil faut respecter pour avoir une chance de dvelopper un programme sans trop de bug et que lon pourra facilement faire voluer ultrieurement. Un bug dsigne une faute du programme lors de son excution ou une erreur dcriture qui fait quil ne fait pas exactement ce quil devrait.
21/11/2012
21/11/2012
Introduction
UML (Unified Modeling Language) UML est un langage de modlisation trs complet, qui couvre de nombreux aspects du dveloppement des logiciels, comme : Les exigences, larchitecture, les structures et les comportements.
21/11/2012
besoin de modles
Construction dapplications : la construction dune application informatique se rsume raliser du code pour rpondre au besoin dun utilisateur
la ralisation du code nest pas la seule activit effectuer lorsque nous souhaitons construire une application.
besoin de modles
Parmi les autres activits non moins indispensables effectuer : Sassurer davoir bien compris le besoin de lutilisateur afin de raliser un code qui le satisfasse. Sassurer davoir ralis un code facilement modifiable, permettant de prendre en compte des volutions futures. Dfinir larchitecture de lapplication (dfinition de ses diffrents composants, indpendamment du langage de programmation) afin de bien comprendre les relations entre les composants de lapplication.
7 21/11/2012
besoin de modles
Raliser une batterie de tests afin de mesurer, dune certaine manire, la qualit du code. Effectuer un suivi des besoins de lutilisateur afin dintgrer des amliorations. Effectuer des corrections de erreurs. La prsence de erreurs tant invitable, il faut la grer plutt que la subir. crire la documentation utilisateur. crire la documentation dinstallation de lapplication. crire la documentation de lapplication afin quune autre quipe de dveloppeurs puisse reprendre le dveloppement.
8 21/11/2012
besoin de modles
Pour faire face cette complexit de construction des applications informatiques, lingnierie logicielle propose des mthodes et des techniques permettant de rpondre aux questions suivantes :
Objectif : montrer en quoi les diffrentes techniques de modlisation UML (quoi et comment) permettent dobtenir rapidement un gain de productivit.
besoin de modles
Le code : Le code occupe donc une place particulire dans la construction dune application informatique, mais laquelle exactement ? 1. Question : Comment le code peut-il tre utilis pour faciliter la maintenance des applications informatiques ? 2. Question. Comment pouvons-nous retrouver les fonctionnalits dune application en lisant le code ? 3. Question. Comment pouvons-nous dcrire la faon de mettre en production une application ? 4. Question. Comment pouvons-nous dcrire la faon dutiliser une application ?
besoin de modles
Documentation un ensemble de documents ncessaires raliser pour complter le code. Ces documents sont changs entre les clients de lapplication et les diffrents membres de lquipe de dveloppement. larchitecte, concevait les composants principaux de lapplication, le dveloppeur, dveloppe les composants de lapplication, et ladministrateur, installe lapplication afin quelle puisse tre utilise par lutilisateur.
besoin de modles
12
21/11/2012
besoin de modles
Ces documentations soient comprhensibles et quelles soient cohrentes entre elles. Ce problme peut tre rsum : Comment rdiger les documentations afin quelles soient intelligibles de manire non ambigu ? Comment sassurer que les documentations ne contiennent pas dincohrences ? Pour rpondre ces questions il faut que les modles soient utiliss.
13
21/11/2012
besoin de modles
Les modles Dfinition :
Un modle contient donc plusieurs informations sur une application informatique : vue des donnes, vue des utilisateurs (fonctionnalits), vue technique.
14
21/11/2012
besoin de modles
15
21/11/2012
besoin de modles
Modles et code : le code est diffrent du modle. Cest la matrialisation de la solution. Le code nest pas plus dtaill que les modles. le modle devant contenir toute linformation permettant la production du code, un modle doit tre au moins aussi dtaill que le code. Faire un modle nest pas plus facile qucrire du code. le modle contient des informations fortement diversifies se doivent dtre cohrentes.
16
21/11/2012
besoin de modles
Ne pas confondre niveau dabstraction et niveau de prcision. Abstraction : le fait de pouvoir masquer dans une vue certaines informations inutiles par rapport lobjectif bien dfini de cette vue.
Par exemple, il nest pas intressant de montrer les dtails techniques Java dans la vue des donnes. Toutes les informations de chaque vue doivent tre prcises.
17
21/11/2012
besoin de modles
Les modles doivent tre productifs plutt que dclaratifs. Lobjectif des modles est de contenir linformation ncessaire la production et lvolution du code. Les informations contenues dans les modles doivent donc tre synchronises avec le code. Nous considrons les modles comme des lments de production plutt que comme des lments de documentation.
18
21/11/2012
besoin de modles
19
21/11/2012
besoin de modles
Le concept de modle tel quil sera tudi dans ce cours, selon les vues structurelle , comportementale et fonctionnelle , sur trois niveaux dabstraction. Nous prsenterons de plus les relations de cohrence entre ces lments de modles ainsi que la relation de synchronisation avec le code.
20
21/11/2012
Diagrammes de classes
La vue structurelle du modle UML est la vue la plus utilise pour spcifier une application. Objectif de vue : modliser la structure des diffrentes classes dune application oriente objet ainsi que leurs relations. UML dfinit sa propre smantique OO, laquelle ressemble la smantique des langages de programmation objet Java ou C++. Il est donc important de considrer UML comme un langage part entire, et non pas comme une couche graphique permettant de dessiner des applications Java ou C++.
21 21/11/2012
Diagrammes de classes
Concepts lmentaires : Classe : Smantique En UML, une classe dfinit la structure commune dun ensemble dobjets et permet la construction dobjets instances de cette classe. Une classe est identifie par son nom. Graphique Une classe se reprsente laide dun rectangle, qui contient le nom de la classe.
22 21/11/2012
Diagrammes de classes
la classe nomme Personne. Interface Smantique En UML, une interface dfinit un contrat que doivent respecter les classes qui ralisent linterface. Une interface est identifie par son nom. Les objets instances des classes qui ralisent des interfaces sont aussi des instances des interfaces. Une classe peut raliser plusieurs interfaces, et une interface peut tre ralise par plusieurs classes.
23 21/11/2012
Diagrammes de classes
Graphique Une interface se reprsente de deux faons : soit laide dun rectangle contenant le nom de linterface, au-dessus duquel se trouve la chane de caractres interface, soit laide dun cercle, au-dessous duquel se trouve le nom de linterface.
24
21/11/2012
Diagrammes de classes
La relation de ralisation entre une classe et une interface est reprsente par une flche pointille la tte en forme de triangle blanc.
25
21/11/2012
Diagrammes de classes
Proprit (appele attribut) dune classe ou dune interface Smantique Les classes et les interfaces peuvent possder plusieurs proprits. Une proprit a un nom et un type. Le type peut tre soit une classe UML, soit un type de base (integer, string, boolean, char, real). Un objet instance de la classe ou de linterface doit porter les valeurs des proprits de sa classe.
26
21/11/2012
Diagrammes de classes
Graphique Les proprits dune classe ou dune interface se reprsentent dans le rectangle reprsentant la classe ou linterface. Chaque proprit est reprsente par son nom et son type. la classe Personne, avec sa proprit nom de type string.
27
21/11/2012
Diagrammes de classes
Opration dune classe ou dune interface Smantique Les classes et les interfaces peuvent possder plusieurs oprations. Une opration a un nom et des paramtres et peut lever des exceptions. Les paramtres sont typs et ont un sens (in, out, inout, return). Un objet instance de la classe ou de linterface est responsable de la ralisation des oprations dfinies dans la classe ou dans linterface.
28 21/11/2012
Diagrammes de classes
Si le sens dun paramtre de lopration est in, lobjet appelant lopration doit fournir la valeur du paramtre. Si le sens dun paramtre de lopration est out, lobjet responsable de lopration doit fournir la valeur du paramtre. Si le sens dun paramtre de lopration est inout, lobjet appelant lopration doit fournir la valeur du paramtre, mais celle-ci peut tre modifie par lobjet responsable de lopration.
29
21/11/2012
Diagrammes de classes
Si une opration possde un paramtre dont le sens est return, cela signifie que lobjet responsable de lopration rend cette valeur comme rsultat de lopration. Lapport de la direction return par rapport la direction out est de faciliter la combinaison de fonction. Il est important de souligner que les oprations UML ne dfinissent pas le comportement qui sera ralis lors de traitement de lopration.
30
21/11/2012
Diagrammes de classes
Graphique Les oprations dune classe ou dune interface se reprsentent dans le rectangle reprsentant la classe ou linterface. Chaque opration est reprsente par son nom et ses paramtres. Il est aussi possible de masquer les paramtres de lopration. prsente la classe Personne avec son opration getNom.
31
21/11/2012
Diagrammes de classes
Hritage entre classes Smantique En UML, une classe peut hriter dautres classes. Lhritage entre classes UML doit tre considr comme une inclusion entre les ensembles des objets instances des classes. Graphique La relation dhritage entre deux classes est reprsente par une flche la tte en forme de triangle blanc.
Classe Personne, qui hrite de la classe EtreVivant.
32 21/11/2012
Diagrammes de classes
Package Smantique Un package permet de regrouper des classes, des interfaces et des packages. Ils ne peuvent avoir quun seul package dans lequel ils sont regroups. La possibilit dtablir un lien entre des classes et des interfaces dpend du lien qui existe entre les packages qui les contiennent.
33
21/11/2012
Diagrammes de classes
Graphique Les packages se reprsentent laide dun rectangle possdant un onglet dans lequel est inscrit le nom du package. Les lments contenus se reprsentent dans le rectangle. La taille du rectangle sadapte la taille de son contenu. le package nomm personnel, qui contient la classe Personne.
34
21/11/2012
Diagrammes de classes
Import de package Smantique Afin que les classes dun package puissent hriter des classes dun autre package ou y tre associes , il faut prciser une relation dimport entre ces deux packages. La relation dimport est monodirectionnelle, cest--dire quelle comporte un package source et un package cible. Les classes du package source peuvent avoir accs aux classes du package cible.
35
21/11/2012
Diagrammes de classes
Graphique La relation dimport entre deux packages sexprime laide dune flche en pointill. La chane de caractres access element inscrite au-dessus de cette flche peut tre optionnellement positionne. Relation dimport entre deux packages P1 et P2 contenant resp. les classes A et B. La classe A a besoin daccder la classe B.
36
21/11/2012
Diagrammes de classes
Note Smantique Une note UML est un paragraphe de texte qui peut tre attach nimporte quel lment du modle UML (package, classe, proprit, opration, association). Le texte contenu dans la note permet de commenter llment cibl par la note.
37
21/11/2012
Diagrammes de classes
Graphique Les notes se reprsentent laide dun rectangle contenant le texte et dont un des coins est corn. Une ligne discontinue permet de relier la note llment du modle quelle cible. une note attache lopration nomme getNom().
38
21/11/2012
Diagrammes de classes
Associations entre classes UML dfinit le concept dassociation entre deux classes permet de prciser les relations qui peuvent exister entre plusieurs objets. une association se fait entre deux classes a un nom et deux extrmits, qui permettent de la connecter chacune des classes associes. Les objets instances de ces deux classes peuvent tre relis entre eux. lassociation nomme habite, qui associe les classes Personne et Adresse.
39 21/11/2012
Diagrammes de classes
Chaque extrmit de lassociation a un nom de rle, qui permet didentifier chacune des classes lies dans le contexte de lassociation. mme association en prcisant le nom des rles de chaque classe lie. Dans le contexte de cette association, la classe Personne reprsente lhabitant alors que la classe Adresse reprsente la rsidence.
il est possible de spcifier chaque extrmit les nombres minimal et maximal dobjets devant tre relis.
40 21/11/2012
Diagrammes de classes
rsidence 1 : pour 1 habitant, il y a au minimum 1 rsidence et au maximum 1 rsidence. habitant * : pour 1 rsidence, il y a au minimum 0 habitant et au maximum une infinit dhabitants. Il est possible de rendre chacune des extrmits navigable ou non. Si une extrmit est navigable, cela signifie que lobjet peut naviguer vers lautre objet auquel il est reli et ainsi obtenir les valeurs de ses proprits ou invoquer les oprations dont il est responsable.
41
21/11/2012
Diagrammes de classes
les habitants peuvent naviguer vers leurs rsidences (et pas linverse), ce qui permet dobtenir, par exemple, le numro de rue.
42
21/11/2012
Diagrammes de classes
UML propose deux smantiques de contenance : une smantique de contenance faible, dite dagrgation : permet de prciser que les lments contenus peuvent tre partags entre plusieurs conteneurs, Graphique
43
21/11/2012
Diagrammes de classes
une smantique de contenance forte, dite composition, qui permet de prciser que les lments contenus ne peuvent tre partags entre plusieurs conteneurs. Graphique
44
21/11/2012
Diagrammes de classes
la classe Personne joue un rle de conteneur pour la classe Compte Bancaire dans le cadre de lassociation moyens de paiement, ce qui signifie quun compte bancaire ne peut tre le moyen de paiement que dune seule personne.
45
21/11/2012
Diagrammes de classes
Concepts avancs Classe abstraite Smantique Une classe UML peut tre abstraite. Dans ce cas, elle ne peut pas directement instancier un objet car certaines proprits et certaines oprations sont abstraites. Graphique Pas de reprsentation graphique particulire pour les classes abstraites, il fallait mettre le nom de la classe en italique.
46 21/11/2012
Diagrammes de classes
Multiplicit des proprits et des paramtres Smantique Une proprit ou un paramtre peut porter plusieurs valeurs. UML permet de prciser les nombres minimal et maximal de ces valeurs. Graphique Pour les proprits et les paramtres, les nombres minimal et maximal des valeurs apparaissent entre crochets. Le caractre * est utilis pour prciser que le nombre maximal de valeurs est infini.
47 21/11/2012
Diagrammes de classes
diffrentes proprits en prcisant des nombres minimal et maximal de valeurs.
48
21/11/2012
Diagrammes de classes
Visibilit des classes, des proprits et des oprations Smantique On dit quune classe A accde la proprit dune classe B si le traitement associ une opration de A utilise la proprit de B. On dit quune classe A accde lopration dune classe B si le traitement associ une opration de A fait un appel lopration de B.
49
21/11/2012
Diagrammes de classes
Les visibilits proposes par UML 2.0 sont les suivantes :
Public : la proprit ou lopration peuvent tre accdes par nimporte quelle autre classe. Private : la proprit ou lopration ne peuvent tre accdes que par la classe elle mme. Protected : la proprit ou lopration ne peuvent tre accdes que par des classes qui hritent directement ou indirectement de la classe qui dfinit la proprit ou lopration.
50
21/11/2012
Diagrammes de classes
Graphique Le caractre + est utilis pour prciser la visibilit public. Le caractre - est utilis pour prciser la visibilit protected. Le caractre # est utilis pour prciser la visibilit private.
51
21/11/2012
Diagrammes de classes
Proprits et oprations de classe Smantique la valeur dune proprit dfinie par une classe est porte directement par la classe elle-mme pas par objet Il est possible de prciser quune classe est directement responsable dune opration quelle dfinit. On appelle ces proprits et ces oprations des lments de niveau classe .
52
21/11/2012
Diagrammes de classes
Graphique Dans la reprsentation graphique de la classe, les proprits et les oprations de niveau classe sont soulignes.
53
21/11/2012
Reverse Engineering
Concepts UML inexistants dans les langages de programmation : Association UML permet de dfinir une proprit de type B dans une classe A. Il est aussi possible dutiliser les multiplicits de cette proprit pour rfrencer plusieurs objets. En Java, il nest pas possible de prciser que deux rfrences appartenant deux classes correspondent la mme association et que lune est loppose de lautre.
54 21/11/2012
Reverse Engineering
Import entre packages En UML, la notion de package existe indpendamment de la notion de classe. Il est possible de dfinir des relations dimport directement entre les packages. Direction des paramtres En UML, les paramtres dune opration ont une direction (in, out, inout, return), qui prcise la faon dont les valeurs doivent tre transmises. Java ne supporte que les directions in et return dUML.
55
21/11/2012
Reverse Engineering
Concepts des langages de programmation inexistants en UML Corps des mthodes Les langages de programmation permettent tous de coder le traitement associ chaque opration. UML ne permet pas de dfinir le traitement associ aux oprations des classes.
56
21/11/2012
Reverse Engineering
Smantique dappel dopration Chaque langage de programmation dfinit sa propre smantique dappel dopration. En UML, aucune smantique dappel dopration nest impose Il est possible de modliser diffrentes smantiques dappel dopration dans la partie comportementale du modle.
57
21/11/2012
Reverse Engineering
API Chaque langage de programmation dispose de sa propre API (Application Programming Interface) : ce qui fait la richesse du langage de programmation. API permet dappliquer des oprations arithmtiques lmentaires, denvoyer des messages sur Internet, dcrire et de lire dans des fichiers et dafficher des composants graphiques.
58
21/11/2012
Reverse Engineering
UML ne propose aucune API. Il est impossible de modliser en UML lapplication Salut tout le monde, car il nexiste aucune API permettant dafficher une chane de caractres lcran (quivalant du System.out.println de Java).
59
21/11/2012
Reverse Engineering
Concepts communs UML et aux langages de programmation qui nont pas le mme sens Hritage En Java, seul lhritage simple entre classes est autoris. Il nest donc pas possible de faire quune classe hrite de plusieurs classes. En UML, lhritage multiple est autoris.
60
21/11/2012
Reverse Engineering
Types de base Comme tout langage de programmation, Java possde un ensemble de types de base (byte, short, int, long, float, double, boolean, char, String). UML ne propose que peu de types de base (Integer, String, Boolean, Char, Real). La raison est que UML a t conu pour tre un langage de modlisation.
61
21/11/2012
Reverse Engineering
Synthse entre UML et les langages de programmation
Reverse Engineering
Passage de code Java vers les diagrammes de classes Le code nest que la matrialisation de la solution. Objectif de lopration de Reverse Engineering : construire un diagramme de classes partir du code, est de construire le modle de la solution partir de sa matrialisation (la partie structurelle ). Lopration de Reverse Engineering permet de construire automatiquement la partie du modle de lapplication relative la vue structurelle et ciblant le niveau dabstraction le plus bas.
63 21/11/2012
Reverse Engineering
Code, modle et opration du Reverse Engineering
64
21/11/2012
Reverse Engineering
Intrt : tablir un lien entre le code et le modle. Le code est li au modle grce cette relation. Reverse Engineering ne permet en aucun cas de construire automatiquement lintgralit du modle.
65
21/11/2012
Reverse Engineering
Rgles de correspondance du Reverse Engineering Rgles de correspondance Java vers UML 1. toute classe Java doit correspondre une classe UML portant le mme nom que la classe Java. 2. toute interface Java doit correspondre une interface UML portant le mme nom que linterface Java.
66
21/11/2012
Reverse Engineering
3. tout attribut dune classe Java doit correspondre une proprit appartenant la classe UML correspondant la classe Java. Le nom de la proprit doit tre le mme que le nom de lattribut. Le type de la proprit doit tre une correspondance UML du type de lattribut Java. Si lattribut est un tableau, la proprit peut avoir plusieurs valeurs (en fonction de la taille du tableau).
67
21/11/2012
Reverse Engineering
4. toute opration dune classe Java doit correspondre une opration appartenant la classe UML correspondant la classe Java. Le nom de lopration UML doit tre le mme que celui de lopration Java. Pour chaque paramtre de lopration Java doit correspondre un paramtre UML de mme nom, dont la direction est in et dont le type est le type UML correspondant au type du paramtre Java.
68
21/11/2012
Reverse Engineering
5. Si une classe Java appartient un package Java, ce dernier doit correspondre un package UML correspondant au package Java qui doit contenir la classe UML correspondant la classe Java. 6. Si une classe Java importe un package Java, ce dernier doit correspondre une relation dimport entre le package UML de la classe UML correspondant la classe Java et le package UML correspondant au package Java import. 7. Si une classe Java hrite dune autre classe Java, les classes UML correspondantes doivent avoir elles aussi une relation dhritage.
69 21/11/2012
Reverse Engineering
8. Si une classe Java ralise une interface, la classe UML correspondante doit aussi raliser linterface UML correspondante. Ces rgles de correspondance ne prennent pas en considration le concept UML dassociation.
9. Si une opration Java possde un code de traitement, alors doit correspondre une note UML contenant ce code et qui doit tre attache lopration UML correspondant lopration Java.
70
21/11/2012
Reverse Engineering
Soulignons le fait quil existe plusieurs rgles de correspondance possibles : partir dun mme programme Java, il est possible dobtenir plusieurs modles UML diffrents.
71
21/11/2012
Reverse Engineering
Intrt et limites du Reverse Engineering UML fait la distinction entre modle UML et diagramme UML. Un diagramme nest quune reprsentation graphique dune partie dun modle. Il est possible de dfinir plusieurs diagrammes pour un mme modle.
72
21/11/2012
Reverse Engineering
Modle UML dune application informatique et ses diagrammes
73
21/11/2012
Les diagrammes reprsentent graphiquement linformation contenue dans un modle. Reverse Engineering ne construit donc pas de diagramme de classes mais une partie du modle. Reverse Engineering construit la partie structurelle du modle et la stocke dans une base de donnes ou dans un fichier. Grce aux informations contenues dans la base de donnes ou dans le fichier, il est possible de construire plusieurs diagrammes de classes.
74
21/11/2012
Reverse Engineering
Diagrammes faire aprs un Reverse Engineering Aprs avoir ralis une opration de Reverse Engineering, nous prconisons dlaborer les diagrammes suivants : un diagramme de classes reprsentant lintgralit des informations ; un diagramme de classes reprsentant uniquement lensemble des packages et leurs relations dimport sans montrer leur contenu ;
75
21/11/2012
Reverse Engineering
un diagramme par package montrant uniquement le contenu dun package ; un diagramme par classe permettant de montrer le contenu de la classe et les associations et les liens dhritage vers les autres classes.
76
21/11/2012
Reverse Engineering
Gains offerts par le Reverse Engineering premire opration de modlisation qui permette dobtenir un gain de productivit. permettant de gnrer automatiquement une des neuf parties du modle UML Possibilit de gnrer une documentation de la structure de lapplication laide des diagrammes de classes labors. Cette documentation a lavantage dtre faite dans un langage de modlisation standard trs largement diffus.
77
21/11/2012
Reverse Engineering
Possibilit dlaborer les autres parties du modle UML tout en gardant une cohrence avec le code.
78
21/11/2012
80
21/11/2012
81
21/11/2012
82
21/11/2012
Il faut rduire autant que possible les dpendances mutuelles et les cycles de dpendances entre classes mais il nest pas ncessaire de les interdire.
83 21/11/2012
84
21/11/2012
85
21/11/2012
86
21/11/2012
87
21/11/2012
88
21/11/2012
89
21/11/2012
90
21/11/2012
Pour pouvoir appliquer ce principe sur nimporte quel modle, il faut : 1. Identifier la dpendance sur laquelle peut se faire lindirection (cette dpendance ne peut avoir un hritage comme cause). 2. Isoler le besoin de la dpendance dans une superclasse afin de dplacer la dpendance. Par exemple, si A dpend de B car A utilise une opration de la classe B, il faut positionner cette opration dans la superclasse afin de pouvoir dplacer le lien de dpendance.
91 21/11/2012
3. tablir la relation dhritage. 4. Positionner les classes dans les packages et mettre les bonnes relations dimport. La difficult principale : est de pouvoir isoler dans une superclasse le besoin dune dpendance afin de permettre la cration dune indirection.
92
21/11/2012
97
21/11/2012
98
21/11/2012
99
21/11/2012
Diagramme de squence
Vue comportementale du modle UML Laspect comportemental dune application oriente objet est dfini par la faon dont interagissent les objets qui composent lapplication. Les objets qui composent une application pendant son excution et leurs changes de messages permettent lapplication de raliser les traitements. Cette vue (diagramme de squence) dfinit deux concepts principaux : celui dobjet et celui de message chang entre deux objets. Une interaction permet didentifier plusieurs objets et de reprsenter les messages quils schangent.
100 21/11/2012
Diagramme de squence
Concepts lmentaires Objet Smantique Dans une application, chaque objet peut envoyer et recevoir des messages des autres objets qui composent lapplication. En UML, les objets qui participent une interaction schangent des messages entre eux.
101
21/11/2012
Diagramme de squence
Graphique un carr contenant lidentifiant de lobjet (si lobjet nest pas anonyme), suivi du nom de la classe dont lobjet est instance (si lobjet est typ). Attach ce carr, une ligne verticale reprsente la vie de lobjet dans le temps (laxe du temps tant dirig vers le bas du diagramme).
102
un objet anonyme non typ, un objet anonyme typ, un objet identifi non typ et un objet identifi typ.
21/11/2012
Diagramme de squence
Message Smantique les objets communiquent par changes de messages. Le message le plus important est de demande de ralisation dopration, par lequel un objet demande un autre objet (ou lui-mme) de raliser une des oprations. En thorie, avec ce message seul, il est possible de dcrire compltement le comportement dune application.
103 21/11/2012
Diagramme de squence
Graphique Le premier message est un message de cration chang entre lobjet identifi id1 et lobjet identifi id2. Ce message signifie que lobjet id1 cre lobjet id2.
104
21/11/2012
Diagramme de squence
Le deuxime message est un message dappel synchrone dopration. Lobjet id1 demande lobjet id2 de raliser lopration nomme opration1. Lobjet id1 attend que lobjet id2 finisse de raliser cette opration avant de continuer son activit. Le message de fin de traitement est reprsent par une flche pointille. Le dernier message est un message de suppression. Lobjet id1 supprime lobjet id2.
105 21/11/2012
Diagramme de squence
Le temps dans les diagrammes de squence Une interaction spcifie une succession dchanges de messages entre les objets participant linteraction. Le temps est donc trs important puisquil prcise lordre dexcution entre tous les messages dune mme interaction.
106
21/11/2012
Diagramme de squence
le temps est gouvern par deux rgles principales. Ces rgles considrent les messages dappel synchrone dopration et de cration comme deux messages, un appel et un retour. Il y a donc une flche de lobjet metteur vers lobjet rcepteur (appel) et une autre de lobjet rcepteur vers lobjet metteur (retour).
107
21/11/2012
Diagramme de squence
Chaque message est ensuite dcompos en deux vnements, un vnement denvoi et un vnement correspondant la rception. Lenvoi est matrialis par lextrmit de dpart de la flche correspondant au message et la rception par lextrmit darrive de la flche. le temps est rgul par les rgles suivantes :
108
21/11/2012
Diagramme de squence
Sur laxe dun objet, tous les vnements sont ordonns du haut vers le bas. Cela entrane quun vnement arrive avant un autre vnement sil est positionn plus haut sur laxe dun mme objet. Pour un mme message, lenvoi se droule toujours avant la rception.
109
21/11/2012
Diagramme de squence
110
21/11/2012
Diagramme de squence
Liens avec la vue structurelle du modle Objet et classe Tout objet participant une interaction doit obligatoirement avoir son type dcrit sous forme de classe dans la partie structurelle. Nous dconseillons fortement lutilisation dobjets non typs.
111
21/11/2012
Diagramme de squence
Tout message dappel dopration (synchrone ou asynchrone) doit cibler une opration spcifie dans la vue structurelle. Cette opration doit appartenir la classe dont lobjet qui reoit le message est instance. Tout message dappel dopration (synchrone ou asynchrone) doit porter les valeurs des paramtres de lopration cible par le message.
112
21/11/2012
Diagramme de squence
Objets typs dans une interaction
Les rgles de cohrence entre parties de modles nous imposent davoir dans la partie structurelle la dfinition des classes A et B ainsi que la dfinition de lopration opration1
113 21/11/2012
Diagramme de squence
reprsente le diagramme de classes correspondant cette partie structurelle (les paramtres de lopration de la classe B sont masqus).
114
21/11/2012
Diagramme de squence
Diagramme et modle Un diagramme est une reprsentation graphique dun modle et qu un modle peuvent correspondre plusieurs diagrammes. Un diagramme de squence est la reprsentation graphique de la partie comportementale (interaction) dun modle UML. Toute les informations (objets, messages, etc.) sont contenues dans le modle et reprsentes graphiquement laide des diagrammes. Il est donc possible de reprsenter une mme information dans diffrents diagrammes.
115 21/11/2012
Diagramme de squence
Deux diagrammes partageant de mmes objets
116
21/11/2012
Diagramme de squence
deux interactions qui peuvent sexcuter dans une application de gestion de prts bancaires. Ces interactions font intervenir les mmes objets (le client c1 et la banque bk). La premire interaction reprsente un cas nominal : le prt est accord. La deuxime montre un cas soulevant une erreur : le prt est refus. Le fait quun objet appartienne plusieurs interactions na pas de consquence sur lordre entre les vnements des interactions.
117 21/11/2012
Diagramme de squence
Interactions et gnration de code Les interactions permettaient uniquement de spcifier des exemples dexcution dapplication Elles ne peuvent tre utilises pour spcifier intgralement des algorithmes et ainsi servir la gnration de code. Une interaction ne dfinit quune seule excution possible, alors quun algorithme dfinit lensemble des excutions possibles.
118
21/11/2012
Diagramme de squence
Exemple : lalgorithme correspondant la porte logique ET ralisant lopration boolenne ET Lensemble des excutions possibles est fini, que le rsultat ne dpend que de lentre et que ltat de lobjet ne change pas aprs excution de lalgorithme. Les quatre excutions possibles de lalgorithme sont illustres ici :
119
21/11/2012
Diagramme de squence
Diagrammes de squence spcifiant lalgorithme de la porte logique ET
120
21/11/2012
Diagramme de squence
Pour pouvoir tre totalement sr que ces interactions spcifient lintgralit des excutions de la porte ET, il faut savoir, que la porte ET a un comportement dterministe (le rsultat ne dpend que de lentre), Lexcution de la porte ET ne modifie par ltat de lobjet. si la porte ET avait un comportement indterministe ou si le comportement modifiait ltat de lobjet, il ne serait pas possible de gnrer le code.
121
21/11/2012
Diagramme de squence
il serait possible de gnrer le code suivant partir des diagrammes que nous venons de prsenter :
122
21/11/2012
Diagramme de squence
Limites des interactions Les interactions permettent uniquement de prsenter des changes de messages entre objets. Il nest donc pas possible de spcifier : Les accs aux proprits des objets. Les navigations sur les associations navigables. Les crations de liens entre objets. Les appels aux oprations de classes, car aucun objet nest directement responsable de la ralisation de lopration.
123 21/11/2012
124
21/11/2012
125
21/11/2012