Modélisation OO avec UML

Transcription

1 Méthodes orientées objet - analyse et conception Modélisation OO avec UML R. Bendraou & S. Bouzitouna Reda.Bendraou@lip6.fr Salim.Bouzitouna@lip6.fr 1

2 Organisation du Cours 10 Séances de 3h 1/2 Séance divisée en deux parties: Cours Travaux pratiques Projet: fil conducteur pendant la durée du cours Note finale du module: Examen écrit prévu pour le 02 Décembre Note du contrôle continu (Réalisation du projet + soutenance + appréciation) 2

3 Plan du cours Introduction au Génie Logiciel Définitions Cycles de vie d'un logiciel Méthodologies Modélisation Orienté Objet avec UML Un besoin de modélisation Rappel sur les concepts Orientés Objet UML Diagrammes UML Outils standards UML Profiles UML Recherche UML: MDA (Model-Dirven Architecture) 3

4 Définition Qu est ce que le Génie Logiciel? "Le processus visant la résolution de problèmes posés par un client par le développement systématique et l évolution de systèmes logiciels de grande taille et de haute qualité en respectant les contraintes de coûts, de temps, et autres". Définition de l'ieee "The application of a systematic, disciplined, quantifiable approach to the development, operation, maintenance of software; that is, the application of engineering to software". 4

5 Qu est ce que le Génie Logiciel? Les quatre P du génie logiciel Personnel Qui produit le logiciel? Processus Comment le logiciel est-il produit? Projet La production réelle du logiciel Produit Tous les objets fabriqués pendant la production: code source, exécutables, documentation, modèles de conception, cahier de charges, résultats de testes, mesures de productivité, 5

6 Activités communes aux projets de Génie Logiciel (1/2) Gestion du projet choisir un modèle/processus de développement diviser le projet en différentes activités décider ce qui est inclus en chaque activité décider sur la séquence d'activités Définition et spécification des exigences Analyse de domaine Définition du problème Cueillette des exigences Analyse des exigences Conception Analyse de domaine Déterminer ce qui sera réalisé par le logiciel ( software) et par le matériel ( hardware) Mettre au point l architecture du système, la définition des sous-systèmes et de leurs interactions Élaborer les éléments internes de chaque sous-système Concevoir des interfaces usagers et des bases de données 6

7 Activités communes aux projets de Génie Logiciel (2/2) Modélisation (UML) Créer des représentations du logiciel et de son domaine d application Modélisation de son utilisation ( use case modelling) Modélisation de sa structure ( structural modelling) Modélisation de sa dynamique et de son comportement ( dynamic and behavioural modelling) Programmation Déploiement distribution et installation du logiciel Assurance de qualité 7

8 Cycle de vie d'un logiciel Il existe différents types de cycles de développement entrant dans la réalisation d'un logiciel. Prennent en compte toutes les étapes de la conception d'un logiciel. Les Grandes Familles: Cycle en Cascade Cycle en V Cycle en Spirale etc. 8

9 Cycle de vie d'un logiciel: cycle en Cascade Cycle en Cascade Ce cycle est hérité du bâtiment. Ce modèle repose sur les hypothèses suivantes: on ne peut pas construire la toiture avant les fondations les conséquences d'une modification en amont du cycle ont un impact majeur sur les coûts en aval 9

10 Cycle de vie d'un logiciel: cycle en V Imaginé pour pallier le problème de réactivité du modèle en cascade permet en cas d'anomalie, de limiter un retour aux étapes précédentes Les phases de la partie montante, doivent renvoyer de l'information sur les phases en vis-à-vis lorsque des défauts sont détectés afin d'améliorer le logiciel. met en évidence la nécessité d'anticiper et de préparer dans les étapes descendantes les «attendus» des futures étapes montantes Le cycle en V est devenu un standard de l'industrie du développement de logiciel et de la gestion de projet depuis les années

11 Cycle de vie d'un logiciel: cycle en spirale s'appuie sur une succession de cycles dont chacun se déroule en quatre phases : analyse initiale des besoins et des objectifs du cycle (solutions et contraintes) ou analyse à partir du cycle précèdent, étude des risques, évaluation des solutions de remplacement et éventuellement conception, développement et vérification de la solution résultant de l'étape précédente, examen du produit et projection vers le cycle suivant. Peu utilisé en pratique: difficile (cher!) à mettre en œuvre 11

12 Définition: Au cœur du Génie Logiciel: La Méthodologie "An organised, documented set of procedures and guidelines for one or more phases of the software life cycle, such as analysis or design. Many methodologies include a diagramming notation for documenting the results of the procedure; a step-by-step "cookbook" approach for carrying out the procedure; and an objective (ideally quantified) set of criteria for determining whether the results of the procedure are of acceptable quality". ~Foldoc. Méthodologie = Techniques (Savoir faire) + Notation + Outils (Optionnel) 12

13 Au cœur du Génie Logiciel: La Méthodologie Méthodologies existantes Les premières méthodologies d'analyse (c.1970) Découpe cartésienne (fonctionnelle et hiérarchique) Exemples : méthode structurée, de Jackson L'approche systémique (c.1980) Modélisation des données et des traitements Exemples : Merise, Axial, IE L'émergence des méthodologies objets (c.1990) Plus de 50 méthodes objet sont apparues Exemples : Booch, Classe Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE Aucune ne s'est réellement imposée 13

14 Les méthodologies OO L apparition du paradigme objet à permis la naissance de plusieurs méthodes de modélisation Chacune de ces méthodes fournie une notation graphique et des règles pour élaborer les modèles Certaines méthodes sont outillées 14

15 Problème: Trop de Méthodes!Toutes avec une notation et des modèles différents Entre 89 et 94 : le nombre de méthodes orientées objet est passé de 10 à plus de 50 Toutes les méthodes avaient pourtant d énormes points communs (objets, méthode, paramètres, ) Au milieu des années 90, G. Booch, I. Jacobson et J. Rumbaugh ont chacun commencé à adopter les idées des autres. Les 3 auteurs ont souhaité créer un Langage de Modélisation Unifié 15

16 Modélisation Orienté Objet avec UML 16

17 Qu est-ce qu un modèle? Du réel au modèle Méthode de modélisation La réalité représentations mentales, connaissances, règlements... Le modèle représentations schématiques, formulations rigoureuses Du modèle au logiciel 17

18 Les objectifs de la modélisation COMMUNIQUER Le premier but de la modélisation est de garantir la bonne compréhension entre les acteurs. Entre utilisateurs et informaticiens Entre informaticiens : analystes, concepteurs, développeurs, mainteneurs... CONTROLER Le second but de la modélisation est de fournir une description rigoureuse et contrôlable. Qualité des modèles : cohérence, exhaustivité, couverture, pertinence, économie... 18

19 Un bref rappel sur les concepts objets La classe "Abstraction d'un type de donnée caractérisée par des propriétés (attributs et méthodes) communes à des objets, et permettant de créer des objets ayant ces propriétés". L objet "une instance de la structure de données ainsi que du comportement définit par la class de l'objet. Chaque Objet a ses propres valeurs pour les variables d'instances de sa classe et répond aux méthodes définies par celle-ci". Encapsulation, messages, héritage, polymorphisme 19

20 La classe - modele - puissance - vitesse - couleur Locomotive + allerenavant( ) + allerenarriere( ) + demarrer( ) + stopper( ) + accelerer( ) 20

21 L objet OBJET Données protégées Services publics Environnement Messages 21

22 UML Unified Modeling Language 22

23 La genèse d UML Méthode OOD BOOCH Modélisation dynamique Méthode OMT RUMBAUGH Modélisation statique Méthode OOSE JACOBSON Cas d utilisation UML Unified Modeling Language 23

24 Définition en cours par une commission de révision Soumission à l OMG Standardisation par l OMG Soumission à l OMG Soumission à l OMG Version bêta OOPSLA 96 Historique UML 1.x UML 1.2 UML 1.1 UML 1.0 UML 0.9 UML Juin 1998 Novembre 1997 Septembre 1997 Janvier 1997 Juin 1996 OOPSLA 95 Méthode unifiée 0.8 Octobre 1995 Booch 93 OMT-2 Autres méthodes Booch 91 OMT-1 OOSE Partenaires 24

25 Introduction à UML UML c est Une norme (OMG) Un langage visuel de modélisation Orienté Objet pseudo-formel (rigoureux, non formel) Diagrammes et éléments de modélisation (classes, association, agrégation, package ) 25

26 UML: aujourd hui UML est le langage de modélisation orienté objet le plus connu et le plus utilisé au monde UML s applique à plusieurs domaines OO, RT, Deployment, Requirement, UML n est pas une méthode RUP Peut d utilisateurs connaissent le standard, ils ont une vision outillée d UML (Vision Utilisateur) 5% forte compréhension, 45% faible compréhension, 50% aucune compréhension UML est fortement critiqué car pas assez formel Le marché UML est important et s accroît MDA, UML2.0, IBM a racheté Rational!!! 26

27 UML Pourquoi Réfléchir Définir la structure «gros grain» Documenter Guider le développement Développer, Tester, Auditer 27

28 Un problème - Un diagramme UML 1.x Modélisation statique Diagramme Modélisation des comportements Cas d'utilisation Classes Objets Etats-Transitions Activités Recueil des besoins Séquence Collaboration Composants Déploiement Modélisation de la dynamique: les diagrammes d interactions Modélisation de l architecture 28

29 UML Unified Modeling Language Le Diagramme de Cas d'utilisation 29

30 Diagramme de Cas d Utilisation Pourquoi les cas d utilisation? Un système est conçu pour les utilisateurs : ils savent ce que le système doit faire mais pas comment le faire ; ils connaissent l aspect fonctionnelle du système. Les utilisateurs du système sont les plus aptes à décrire comment ils s en servent Le système doit donc être bâti à partir des descriptions des utilisateurs. 30

31 Diagramme de cas d Utilisation Le diagramme des cas d utilisation est modélisé par : Des acteurs qui représentent les entités externes du système; Des cas d utilisation qui représentent les fonctionnalités attendues du système. Ses objectifs sont : capturer les besoins fonctionnels du système; délimiter le système; visualiser le cahier des charges graphiquement ; peut servir à concevoir les tests. vérifier le status client passer la commande vendeur traiter la commande 31

32 Identification des acteurs Comment? Par un dialogue avec le client et les utilisateurs ; en délimitant les frontières du système. Qui sont-ils? les utilisateurs humains: les profils possibles sans oublier l administrateur et l opérateur de maintenance ; les autres systèmes connexes interagissant avec le système : logiciels, périphériques ; Client Louer DVD Vidéothèque 32

33 Identification des Cas d Utilisation Il existe plusieurs approches pour découvrir les uses case d un système: Répondre aux questions suivantes: Quels sont les services rendus par le système? Quelles sont les interactions Acteurs/ système? Pour chaque acteur identifié Rechercher les différentes intentions métier avec lesquelles il utilise le système ; Déterminer les services fonctionnels attendus du système par cet acteur. Quels sont les évènements perçus par le système (externes, temporels, changement d état)? 33

34 Les relations entre cas d utilisation Il existe trois types de relations Généralisation (héritage): le cas fils spécialise le cas père. Inclusion (<<include>>): le cas source incorpore directement et nécessairement le cas cible à un endroit précis dans son enchaînement. Le cas inclus n est jamais exécuté tout seul. Client <<include>> Authentification Virement <<extend>> Consulter le solde Extension (<<extend>>): le cas de base en incorpore indirectement et pas nécessairement un autre à un endroit précis dans son enchaînement. Le cas de base peut être exécuté tout seul. Client en ligne Virement en Ligne 34

35 Description des cas d utilisation (1) Les cas d'utilisation peuvent être décrits sous la forme de scénarii. Un scénario représente une séquence d actions qui s exécute du début à la fin d un use case. Client retrait Scénario : Client 1: Afficher le message d'accueil 2: introduire CB 3: Demander le code de la CB 4: composer le code de la CB 5: Diag Séquence Textuel 1. Le distributeur affiche un message d accueil demandant à un client d introduire sa carte bancaire ; 2. le client introduit sa CB ; 3. le distributeur demande le code de la CB ; 4. Le client compose le code de la CB 5. 35

36 Description des cas d utilisation (2) Un même use case peut être décrit par plusieurs scénarii: - Un scénario principal : le service est accompli sans exceptions ou erreurs - Plusieurs scénarii alternatifs : cas des exceptions, des erreurs, autres variantes du scénario principal Client retrait Scénario Scénario principal Scénario alternatif : C lient 1: Afficher le message d'accueil : Client 1: Afficher le message d'accueil 2: introduire C B 3: Demander le code de la CB 2: introduire CB 3: Demander le code de la CB 4: composer le code de la CB 4: composer le code de la CB 5: code accepté 5:code erroné 36

37 Digrammes des cas d utilisations- fin Les diagrammes de cas d utilisation sont souvent employés Ils permettent de décrire le système de façon très abstraite Ils offrent une vue fonctionnelle (par opposition à une vue Orienté Objet) Ils sont très simples Les cas d utilisation se limitent à décrire le «quoi» d un système mais pas le «comment» ; Les cas d utilisation sont une description fonctionnelle d un système après quoi il faut passer à une description objet (les scénarii) utilisant : les diagrammes de séquences ou les diagrammes d activités comme alternative ; les diagrammes de collaboration ; il y a en général peu de cas d utilisation (de 10 à 20) mais beaucoup de scénarii. La difficulté consiste à passer des cas d utilisation aux classes 37

38 UML Le Diagramme de Classes 38

39 Diagramme de Classes Un diagramme de classes est un graphe d éléments connectés par des relations. Un diagramme de classes est une vue graphique de la structure statique d un système. Company Person Company members 0..1 * Employee 39

40 Classes Une classe représente la structure commune d un ensemble d objets. Une classe est représentée par un rectangle qui contient une chaîne de caractères correspondant au nom de la classe Ce rectangle peut être séparé en trois parties (nom, attributs, opérations). Le nom de la classe doit commencer par un caractère alphabétique et ne pas contenir le caractère :: 40

41 Classes Em ploye e Person +name : string +firstname : string #id : string nbperson : integer /completename : string 41

42 Attributs Une classe peut contenir des attributs La syntaxe d un attribut est : visibilité nom : type La visibilité est: + pour public # pour protected - pour private UML définit son propre ensemble de types Integer, real, string, Un attribut peut être un attribut de classe, il est alors souligné. Un attribut peut être dérivé, il est alors préfixé par le caractère / 42

43 Attributs Person Company url [3] : string name : string +name : string +firstname : string #id : string nbperson : integer /completename : string 43

44 Opérations Une opération est un service qu une instance de la classe peut exécuter La syntaxe d une opération est: visibility name(parameter):return La syntaxe des paramètres est: kind name : type Le kind peut être: in, out, inout 44

45 Opérations url [3] : string name : string Company +makeprofit():real +getworkingemployee(): [*] Employee Employee +stopwork():boolean +startwork(in work:string):boolean 45

46 Héritage L héritage est une relation entre un élément plus général et un élément plus spécifique. L héritage existe entre des classes, des packages, L héritage multiple est possible en UML Shape Rectangle Circle 46

47 Associations Les associations binaires connectent deux éléments entre eux Une association binaire est composée de deux associations ends. Une association end est paramétrée par: Un nom (le role joué par l entité connectée) Une multiplicity (0, 1, *, 1..*, ) Un genre d aggregation (composite, aggregation, none) De plusieurs propriétés: isnavigable, ischangeable 47

48 Associations Student students attendedcourses * attends * Course Un cours est suivi par plusieurs étudiants (0 ou plusieurs). Un étudiant suit des cours (0 ou plusieurs). A partir d un étudiants, il est possible d identifier les cours suivis (navigable). public class Student { public Course attendedcourses[]; } public Student() { } public class Course { } public Course() { } 48

49 Associations public class School //En Java { public Student thestudent[]; } public School(){ } Composition Aggrégation School 1..* member * has 1 1..* Department public class Department { public Department() {} } Student public class Student { public Student(){} } 49

50 Associations Les associations N-aire connectent plusieurs éléments entre eux. Les associations N-aire sont très peu utilisées. Class Class1 Class2 50

51 Classes - Associations Une classe-association est une association qui est aussi une classe. Les classes-associations sont utilisées lorsque les associations doivent porter des informations Il est toujours possible de se passer des classesassociations. * Company 1..* Employee Job salary : undefined 51

52 Établir le diagramme de classes «1» A partir de(s) mots clés de l énoncé du problème, l analyse du diagramme de Use cases l analyse des digrammes de séquence correspondants aux scénarii des use cases 1. Établir une liste des objets candidats pour le modèle statique de l application 2. Evaluer chaque objet de cette liste en vu de le retenir ou de l éliminer dans le modèle statique de l application Classe/ Objet candidat Nom trouvé dans les spécifications Eliminé pour les raisons suivantes L élément peut être un simple attribut, une classe utilitaire ou en dehors du sujet de modélisation Nom retenu pour la modélisation Nom de classe pour la modélisation 52

53 Établir le diagramme de classes «2» 1. Réaliser un premier diagramme de classes qui contiendra l ensemble des classes retenues et qui mettra en évidence des associations entre les classe. Les associations seront de simples traits banalisés : pas de nom, pas de multiplicité. 2. Raffiner le diagramme précédent 1. Renseigner les association nom, multiplicité, agrégation,navigabilité, rôles des classes associées 2. Renseigner les classes attributs, classes associations, classes abstraites, héritage 3. Vérifier que le diagramme permet de remplir les différents cas d utilisation et leurs scénarii associés 53

54 A vous! Donnez le code Java correspondant au diagramme de Classe suivant: Etudiant Nom : String Prenom : String DateN : Date Adr : String Classement : Integer +etudiants 1..n Suit +CoursSuivi 1..n Cours Intitule : String Resume : String Coef : Integer NbrHeures : Integer +etudiantg ro upe 1..n contient +goupe 1 NumGroupe : Integer 54

55 Interfaces Une interface est la spécification externe (en terme d opérations) d une classe. Une interface peut donc contenir des opérations Une classe réalise une interface si elle est capable d exécuter toutes les opérations de l interface On utilisera une relation de dépendance pour exprimer le fait qu une classe est cliente d une interface. 55

56 Interfaces Engine Element +addchild(in child:element) +getchildren(): [*] Element Parser Engine Element Parser 56

57 Contraintes et Notes Il est possible de contraindre ou d annoter n importe quel élément du modèle Les contraintes et les notes sont bien souvent écrites en langage naturel Le langage OCL est cependant préconiser pour décrire des contraintes self.age<60 57

58 Contraintes et Notes <<comment>> Une association n'est pas une company Company * 1..* Employee agelimit {self.age<60} 58

59 Packages Un package permet de grouper des éléments Un package sert d espace de désignation Un package peut inclure d autres package Un package peut importer d autres package L héritage entre package est possible 59

60 Packages 60

61 Diagramme de Classe - Fin Les diagrammes de classes sont les diagrammes les plus utilisés Ils permettent la décrire des programmes objet Ils permettent de décrire le schéma logique de bases de données Ils permettent de décrire des relations de concepts (modèle métier) Les diagrammes de classes peuvent être de différents niveaux d abstraction 61

62 Établir le diagramme de classes «1» A partir de(s) mots clés de l énoncé du problème, l analyse du diagramme de Use cases l analyse des digrammes de séquence correspondants aux scénarii des use cases 1. Établir une liste des objets candidats pour le modèle statique de l application 2. Evaluer chaque objet de cette liste en vu de le retenir ou de l éliminer dans le modèle statique de l application Classe/ Objet candidat Nom trouvé dans les spécifications Eliminé pour les raisons suivantes L élément peut être un simple attribut, une classe utilitaire ou en dehors du sujet de modélisation Nom retenu pour la modélisation Nom de classe pour la modélisation 62

63 Établir le diagramme de classes «2» 1. Réaliser un premier diagramme de classes qui contiendra l ensemble des classes retenues et qui mettra en évidence des associations entre les classe. Les associations seront de simples traits banalisés : pas de nom, pas de multiplicité. 2. Raffiner le diagramme précédent 1. Renseigner les association Nom, multiplicité, agrégation,navigabilité, rôles des classes associées 2. Renseigner les classes Attributs, classes associations, classes abstraites, héritage 3. Vérifier que le diagramme permet de remplir les différents cas d utilisation et leurs scénarii associés 63

64 Diagramme d Objets Un diagramme d objet représente la vue statique d un ensemble d instance de classes Le digramme d objet doit reprendre la même structure en terme d attributs des classes et les associations les reliant Un diagramme d objet permet de vérifier les multiplicités des associations Digramme de classes T ria n g le Digramme d objets correspondant 1 parto f 3 P o i n t x : Float y : Float 64

65 DIAGRAMME D'OBJETS Exemple d instances: twingo:voiture Instance nommée de la classe voiture :Voiture Instance anonyme de la classe voiture twingo Instance nommée d une classe anonyme Couleur = grise :Voiture Immatriculation = 995 LKZ 75 Instance anonyme de la classe voiture; dont les valeurs de certains attributs sont spécifiées explicitement safrane:véhicule::voiture :Voiture Instance nommée dune classe dont on spécifie le nom complet (conteneur :: contenu) Collection d instance anonymes, de la classes voitures 65

66 Les diagrammes d interaction Le diagramme de séquence Le diagramme de collaboration Le diagramme d activité 66

67 Diagramme de séquence Les diagrammes de séquence permettent de représenter des interactions entre instances (Objets); Les instances communiquent entre-eux par envoi de messages (appel de méthodes) ; Un objet peut recevoir un événement. 67

68 Instances & Messages Instances Un diagramme de séquence met en œuvre des instances (instance de classe, instance d acteur) La durée de vie des instances est définie sur l axe vertical du diagramme Graphiquement l activité d une instance se voit grâce à un rectangle sur l axe du temps Messages Creation: Une instance peut créer une autre instance grâce à un message de création Destruction: Une instance peut détruire une autre instance grâce à un message de destruction Message de Séquence: Une instance peut envoyer un message de séquence à une autre instance pour demander l exécution d une opération 68

69 Intérêt et limites des diagrammes de séquence Les diagrammes de séquence sont utilisés : pour illustrer les use cases ; dans le modèle dynamique. Les limites des diagramme de séquence : comment faire apparaître des opérations non séquentielles? Si la somme est insuffisante! 69

70 La syntaxe des messages La syntaxe pour un message est la suivante : [ condition vraie ou faux ] valeur retournée := nom du message( liste des paramètres) 70

71 Les types de messages Synchrone : l émetteur reste bloqué le temps que le récepteur traite le message envoyé ; Asynchrone : l émetteur n est pas bloqué lorsque le récepteur traite le message envoyé. Mode synchrone : le retour est implicite. Mode asynchrone : le retour doit être explicite s il existe. 71

72 Les boucles et les conditions Représenter une boucle : Représenter une boucle : Représenter une condition: 72

73 Diagramme de Collaboration Un diagramme de collaboration représente la vue statique et la vue dynamique d un ensemble d élément Une collaboration définit des rôles (et non pas des classes!) 3: message3 objet1 2: message2 objet2 objet3 1: message1 73

74 Distributeur automatique de billets 74

75 L ascenseur : Ascenseur 1: monter : Cabine 3: fermer : Porte 2: allumer : Lumière 75

76 UML Diagramme d Etats -Transitions 76

77 Diagramme E/T Les diagrammes d états sont propres à une classe et permettent de représenter les états d un objet ainsi que les transitions entre ces états sont construits pour les objets du système ayant un comportement non trivial Un état se caractérise par sa durée et sa stabilité, il représente l ensemble des valeurs des attributs d'un objet. un objet ne peut pas être dans un état inconnu ou non défini Une transition représente le passage instantané d'un état vers un autre Une transition est déclenchée par un événement. En d'autres termes : c'est l'arrivée d'un événement qui conditionne la transition. En plus de spécifier un événement précis, il est aussi possible de conditionner une transition, à l'aide d'expressions booléennes (gardes) 77

78 Diagramme E/T - Concepts Etat : a tout instant un état représente l ensemble des valeurs des attributs et des liens avec les autres objets un état est caractérisé par une durée / stabilité Transition : connexion unidirectionnelle reliant 2 états assure le passage d un état à l autre est supposée instantanée une transition peut être réflexive Evénement : occurrence de quelque chose qui arrive à un instant inconnu ou connu (IT, envoi de message, ) peut être chargé d information doit avoir été prévu par la conception l événement est le déclencheur d une transition 78

79 Diagramme E/T - Etats Un état est toujours nommé Il comporte un certain nombre de champs qui permettent de décrire les actions dans un état : entry / action : action exécutée à l'entrée de l'état exit / action : action exécutée à la sortie de l'état on événement / action : action exécutée à chaque fois que l'événement cité survient do / action : action récurrente ou significative, exécutée dans l'état Etats particuliers : Etat initial Etat final 79

80 Exemple d'un diagramme E/T (1) Une personne peut être dans trois états : demandeur d emploi ; en phase d embauche ; embauché. Sous - états Une personne embauchée peut avoir deux états : au travail ; en congés. La transition de l état «au travail» à l état «en congés» se fait s il reste des jours de congés. 80

81 Exemple d'un diagramme E/T (2) Une personne en phase d embauche passe par trois état, PréparationEntrevue, Entrevue, Evaluation pour aboutir à l un des états final : embauché ; demandeur d emploi. 81

82 Diagramme E/T - Transitions Syntaxe : event[garde]/action event : événement ou rien garde = expression logique liée à l état que l on quitte action exécutée lors du franchissement de la transition 82

83 Diagramme E/T - Evénements Un événement est un stimulus envoyé à un objet, il traduit l arrivée de quelque chose ; l objet recevant un événement peut réagir en changeant son état (en exécutant une opération) et/ou en émettant un autre événement ; un objet placé dans un état donné attend l occurrence d un événement pour changer d état ; un événement n a pas de durée contrairement à un état ; un événement peut être émis par un objet du système ou provenir de l extérieur du système (clic de souris par exemple) ; un message est un événement émis par un objet ; Types d événement : <<signal>> : signal asynchrone <<crée>>, <<détruit>>, : appel <<top>> : signal synchrone - fin de délai, top horloge, événement instantané : pas de label - correspond à la fin de l activité dans l état de départ 83

84 Comment construire un diagramme E/T Choisir une classe sur le diagramme des classes ; Identifier tous les messages qui arrivent sur un objet correspondant dans le diagramme de séquence afin de trouver les transitions ; Dressez une liste d états possibles en pensant à la vie de l objet (comment est-il créé, comment et à quel moment est-il supprimé, l objet possède-t-il des états actifs, inactifs, y a-t-il des états ou l objet attend? Construisez des fragments du diagramme d états avec des chemins possibles entre états ; Révisez tous les chemins en identifiant les chemins concurrents ; jumelez différents états et demandez-vous si l objet peut être dans ces deux états en même temps, ou si l un suit l autre naturellement ; Développez chaque transition et chaque état ; Réfléchissez à la possibilité q'un état puisse inclure des sous -états Révisez votre diagramme. 84

85 UML Diagramme d Activités 85

86 Diagramme d Activités Un diagramme d activité représente la vue dynamique d un ensemble d éléments sous forme de flux d exécution Une activité représente une exécution d'un mécanisme, un déroulement d'étapes séquentielles Le passage d'une activité vers une autre est matérialisé par une transition. Les transitions sont déclenchées par la fin d'une activité et provoquent le début immédiat d'une autre (elles sont automatiques). 86

87 Diagramme d Activités Les mécanismes dynamiques peuvent être décrits par un diagramme d'activités seuls les mécanismes complexes ou intéressants méritent d'être représentés. Peut servir à décrire le déroulement d'un cas d'utilisation une variante des diagrammes d'états-transitions 87

88 Exemple de diagramme d'activités (1) 88

89 Diagramme d Activités Les Transitions conditionnelles Vérifier Solde Branchement conditionnel Garde [Solde>0] [Solde<0] Autoriser Virement Invitation à réapprovisionner le compte 89

90 Diagramme d Activités Synchronisation Il est possible de synchroniser les transitions à l'aide des "barres de synchronisation" Une barre de synchronisation permet d'ouvrir et de fermer des branches parallèles au sein d'un flot d'exécution Les transitions qui partent d'une barre de synchronisation ont lieu en même temps. On ne franchit une barre de synchronisation qu'après réalisation de toutes les transitions qui s'y rattachent. 90

91 Exemple de diagramme d'activités (2) 91

92 Diagramme de composant Un diagramme de composant représente les composants logiciels d un système 92

93 UML Diagramme de composants et de déploiement 93

94 Diagramme de Composants 1 Les diagrammes de composants permettent de décrire l'architecture physique et statique d'une application en termes de composants et de dépendances entre ces composants Les composants sont des conteneurs (exécutables, librairies ) de classificateurs (classes, interfaces ). Ils exposent des interfaces représentant les services réalisés par leurs classificateurs Les dépendances entre composants permettent notamment d'identifier les contraintes de compilation et de mettre en évidence la réutilisation de composants Notation Server: Client: Component Dépendance Interface Class3: Class1: Class2: Classificateurs 94

95 Exemple : Diagramme de Composants

96 Diagramme de déploiement 1 Les diagrammes de déploiement montrent la disposition physique des matériels qui composent le système et la répartition des composants sur ces matériels. Les ressources matérielles sont représentées sous forme de noeuds. Les noeuds sont connectés entre eux, à l'aide d'un support de communication. La nature des lignes de communication et leurs caractéristiques peuvent être précisées. Les diagrammes de déploiement peuvent montrer des instances de noeuds (un matériel précis), ou des classes de noeuds. Notation Noeud Composants 96

97 Exemple : Diagramme de déploiement

98 UML Le Besoin de Méthode Le standard UML et Editeurs Profiles UML MDA 98

99 Le Besoin de Méthode Un modèle UML représente un système et son environnement Les diagrammes UML offrent différentes vues d un même modèle Certains diagrammes sont complémentaires, d autres non Certains diagrammes sont très abstrait, d autres non Il est nécessaire de définir une organisation entre les diagrammes (Une méthode) 99

100 La méthode IL (pédagogique) 1. Cahier des charges 2. Analyse (Quoi?) Identifier les Actors et les Use Case 1 Diagramme de Séquence / Use Case Diagramme de Classe 3. Conception (Comment?) Diagramme de Séquence Diagramme de Classe 4. Implémentation Diagramme de Composants Diagramme de Déploiement 100

101 Standard UML et Éditeur Le standard UML définit ce qu est UML Les éditeurs doivent être conformes au standard Pas de procédure de conformité Forte évolution des standards sans compatibilité ascendante 101

102 Le standard UML définit précisément tous les éléments UML et leurs relations : sémantique adopte précisément pour élément sa notation graphique: notation 102

103 La sémantique Sémantique UML Une classe est une description d un ensemble d objets qui partagent les mêmes attributs, les mêmes opérations, les mêmes relations et la même sémantique. Une classe peut utiliser un ensemble d interfaces pour exposer les opération qu elle fournit. Propriétés: IsActive: Spécifie si une instance de cette classe maintient le control de son Thread. Modéliser la sémantique faire un modèle représentant les éléments UML : Un méta-modèle generalization * Package 0..1 * Class * Opération * Attribut 103

104 Le méta-modèle UML Le standard UML définit de manière pseudo formelle la sémantique des concepts UML en fournissant le méta-modèle UML Plus de 50 concepts (méta-classes) dans UML1.4 Structuration en package (core, common behavior, ) Aucune présence des diagrammes Extrait du méta-modèle UML 104

105 Notation La notation est la représentation graphique des éléments UML. La notation est la partie visible du standard La sémantique des utilisateurs se base sur la notation Le standard n établit pas un lien précis entre la notation et la sémantique La notation d une Classe UML 105

106 Outil UML standard Il est communément établie qu un outil UML standard est un outil qui Respecte intégralement la notation UML Même si tous les diagrammes ne sont pas supportés Dispose d un format de représentation interne compatible avec le méta-modèle UML standard Le difficulté de ce point s illustre avec XMI 106

107 Exemples d'outils standards Rational Rose Outil de plus important du marché IBM Together Outil fortement couplé avec Java Borland ArgoUML Outil Open Source Visio Outil non complet de microsoft 107

108 Profils UML 108

109 Du contemplatif au productif Les modèles sont souvent utilisés pour Réfléchir, Définir la structure gros grain, documenter Les modèles sont alors contemplatifs Ils ne permettent aucun gain significatif Il faut alors que les modèles deviennent productifs Permettre la génération automatique de code, de déploiement, 109

110 UML Productif Par nature, un modèle UML ne peut pas être productif Indépendance des langages, sémantique trop générale Il faut donc spécialiser UML pour être productif UML pour CORBA, UML pour EJB, UML pour RT, Il faut profiler UML 110

111 Profil UML Un profil UML permet de spécialiser UML à un domaine particulier Un profil UML permet par exemple de préciser qu une classe UML est en fait une Table de base de données Un profil est composé de stéréotypes, de tagged value et de contraintes 111

112 Stéréotypes Un stéréotype se défini principalement sur les classes UML Une classe stéréotypée porte la sémantique du stéréotype Les stéréotypes sont fortement utilisés pour les générations de code <<EJBRemoteInterface>> Shop <<process>> Test 112

113 Tagged Value Les tagged value sont principalement utilisés pour ajouter des informations sur les éléments UML Une tagged value peut être vue comme une nouvelle méta-propriété Exemple : Persistance : tagged value associé àla méta classe attribute pour déterminer si un attribut dans une classe est persistant, i.e. si sa valeur est préservée entre deux sessions d utilisation. Voiture {Persistant} NImmat : String {EJBTransType= SUPPORTED} EJBTransType: tagged value associé au stéréotype EJBSessionBean pour déterminer le contexte transactionnel d un EJB de type session (Required, Supported ) <<EJBSessionBean>> Server 113

114 Contraintes Les contraintes sont utilisées pour exprimer des relations les stéréotypes et les tagged value Les contraintes servent a exprimer la sémantique du profil Exemple: Toute classe stéréotypée «EJBRemoteInterface» doit être réalisée par une classe stéréotypé «EJBImplementationClass» Les contraintes en UML sont souvent exprimées en OCL (Object Constraint Language) 114

115 Définition d un profil Un profil UML standard est composé de la liste des Stéréotypes; Tagged values; Contraintes. Il existe plusieurs profils standards EJB, CORBA, SPEM, 115

116 Profil et génération de code Les profils ne rendent les modèles productifs qui s ils servent à générer du code Il faut donc associer aux profils des règles de génération de code Les profils standards proposent quasiment tous des règles de génération de code EJB, CORBA 116

117 L approche MDA 117

118 MDA: Model Driven Architecture L OMG a défini en 2000 sa nouvelle approche pour réaliser, faire évoluer et maintenir les systèmes informatique : le MDA Le MDA se base sur la technique de séparation des préoccupations L idée est de séparer les aspects métiers des aspects techniques en utilisant les modèles Cette séparation facilite la migration des applications vers les nouvelles technologies 118

119 MDA : PIM vers PSM PIM PIM: Plateform Independent Model PSM PSM: Plateform Specific Model CODE 119

120 Chalenges Définition précise de la frontière entre PIM et PSM Méthodologie MDA (stratégique) Explicitation des transformations (UML vers EJB, UML vers WS, ) Outillage 120