UML Concepts de base et applications Par Jérôme DIVO.

Présentation au sujet: "UML Concepts de base et applications Par Jérôme DIVO."— Transcription de la présentation:

1 UML Concepts de base et applications Par Jérôme DIVO

2 2 Plan 1. Introduction 2. Rappel Objet 3. Présentation générale d’UML 4. Les structures de bases 5. Les Uses Cases 6. Les classes et les objets 7. Les diagrammes de collaborations 8. Les diagrammes d’états-transitions 9. Les diagrammes d’activités 10. UML dans les projets 11. Du modèle à la réalisation 12. Les outils d’UML

3 3 Introduction 1. La modélisation  Pourquoi modéliser ?  Les principes de la modélisation 2. La modélisation Orientée Objet

4 4 1.1 La modélisation Postulats :  L’objectif : satisfaire son client  La réussite est basée sur la production d’applications de qualité  La modélisation est une des caractéristiques d’un projet qui réussi Les moyens : Pour réaliser un logiciel, il faut les outils de communication adéquats pour  Simplifier la réalité  Mieux appréhender le système à concevoir

5 5 1.1 La modélisation Objectifs :  Visualiser les problèmes  Préciser les comportements et les structures  Fournir un guide pour la réalisation  Documenter les décisions Principes :  Le choix des modèles a une forte influence sur la manière d’aborder le problème et sa solution  Le niveau de précision du modèle dépend de l’interlocuteur  Un très bon modèle ne perd pas le sens des réalités  Il faut décomposer un système en ensembles de modèles pour en améliorer la compréhension

6 6 1.2 Modélisation Orienté Objet But : Avoir un outil donnant une dimension méthodologique à l'approche objet. Un outil pour caractériser:  L’identité des Objets  L’état des Objets  Les comportements de Objets  Les interactions entre Objets => Ce sont les objectifs d’UML.

7 7 Plan 1. Introduction 2. Rappel Objet 3. Présentation générale d’UML 4. Les structures de bases 5. Les Uses Cases 6. Les classes et les objets 7. Les diagrammes de collaborations 8. Les diagrammes d’états-transitions 9. Les diagrammes d’activités 10. UML dans les projets 11. Du modèle à la réalisation 12. Les outils d’UML

8 8 2. Rappel Objet Les principales entités:  Classes  Objets  Polymorphisme  Héritage

9 9 Plan 1. Introduction 2. Rappel Objet 3. Présentation générale d’UML 4. Les structures de bases 5. Les Uses Cases 6. Les classes et les objets 7. Les diagrammes de collaborations 8. Les diagrammes d’états-transitions 9. Les diagrammes d’activités 10. UML dans les projets 11. Du modèle à la réalisation 12. Les outils d’UML

10 10 3. Présentation générale d’UML 1. Qu’est ce qu’UML ? 2. Historique d’UML 3. Les idées reçues d’UML 4. Vue d’ensemble des éléments d’UML 5. Vue d’ensemble des diagrammes UML

11 11 3.1 Qu’est ce Qu‘UML Présentation :  UML pour Unified Modeling Language  Les éléments fondamentaux sont faciles à appréhender  Chaque symbole est porteur d’une sémantique propre UML est un langage qui permet de :  Visualiser  Spécifier  Construire  Documenter On trouve UML dans les domaines tels que:  les systèmes informatiques d’entreprise  les banques  Les télécoms  Les transports  La défense  Le WEB……………….

12 12 3.2 Historique Apparition des premières modélisations OO début 80 avec une forte extension entre 1989 et 1994. 3 se détachent du lot  BOOCH de Booch  OOSE de Jacobson  OMT de Rumbaugh Ces 3 auteurs se rapprochent peu à peu (1994) En 1996 Booch, Jacobson et Rumbaugh sortent la version 0.9 d’UML En Janvier 1997 un comité composé de IBM, Rational, Oracle, TI…. propose la norme UML 1.0 à l’OMG (Object Management Group) qui standardise le langage. Version 1.1 en Juillet 97 validée en Septembre 97 UML 1.2 Juin 1998 et UML 1.5 Mars 2003 UML 2.0 en cours d’étude

13 13 3.3 Les idées reçues d’UML La notation graphique d'UML n'est que le support du langage : la puissance et l'intérêt d'UML, c'est qu'il normalise la sémantique des concepts qu'il véhicule ! UML n’est qu’un langage, il n’apporte en aucun cas la réponse absolue à un problème.

14 14 3.4 Les éléments d’UML Les éléments structuraux Les classes, les collaborations, les cas d’utilisation (use cases), les composants, les nœuds…. Les éléments comportementaux Les messages, les états, les objets Les éléments de regroupements Les packages Les éléments d’annotation Les annotations

15 15 3.5 Les Diagrammes d’UML Les diagrammes : De classes D’ objets De cas d’utilisation De séquences De collaborations D’ états-transitions D’ activités De composants (non vu en cours) De déploiement (non vu en cours)

16 16 Plan 1. Introduction 2. Rappel Objet 3. Présentation générale d’UML 4. Les structures de bases 5. Les Uses Cases 6. Les classes et les objets 7. Les diagrammes de collaborations 8. Les diagrammes d’états-transitions 9. Les diagrammes d’activités 10. UML dans les projets 11. Du Modèle à la réalisation 12. Les outils d’UML

17 17 4. Structures de base 1. Les notes 2. Les stéréotypes 3. Les packages

18 18 4.1 Structures de base : Note Permet d’inclure dans un modèle une remarque, un commentaire…

19 19 4.2 Structures de base : stéréotype Un stéréotype :  est un nouveau concept créé à partir d’un élément UML  a les mêmes caractéristiques (et mêmes obligations) que l’élément UML sur lequel il se base Un stéréotype peut être représenté par un nouvel objet graphique ou par l’ajout du nom du stéréotype entre ‘« »’ dans l’objet UML. Trois manières de représenter une classe stéréotypée « Entity »

20 20 4.3 Structures de base : Package Un package organise ou regroupe au sein d’une même entité des ensembles d’éléments. Package simple, le nom peut être mis au centre du package ou sur le tag (en haut à gauche). Un package peut être stéréotypé Des packages peuvent être liés entre eux par des associations stéréotypées «import» ou «access». Un package peut hériter d’un autre package

21 21 Plan 1. Introduction 2. Rappel Objet 3. Présentation générale d’UML 4. Les structures de bases 5. Les Uses Cases 6. Les classes et les objets 7. Les diagrammes de collaborations 8. Les diagrammes d’états-transitions 9. Les diagrammes d’activités 10. UML dans les projets 11. Du Modèle à la réalisation 12. Les outils d’UML

22 22 5 Cas d’utilisation (Présentation) Les cas d’utilisation :  Permettent de structurer les besoins  Permettent d’identifier les services rendus (fonctionnalités) par un système vis à vis de ses utilisateurs (acteurs) Les acteurs :  Permettent de structurer les entités externes (ensemble de rôle ) qui agissent sur le système (opérateur, autre système...). Un cas d’utilisation est décrit par :  Ses acteurs (primaires et secondaires)  Sa pré-condition  Sa post-condition  Ses scénarios (interactions entre le cas d’utilisation et les acteurs)

23 23 5 Cas d’utilisation (Les scénarios) Les scénarios :  Ils permettent de décrire de façon brève les interactions entre un système et ses acteurs  Ils peuvent être de type nominal d’exception ou alternatif  Un scénario alternatif permet d’identifier un flot d’événement variant du scénario nominal  Un scénario d’exception est un scénario ne permettant pas d’aboutir à la post-condition du use case Les use cases, permettent de modéliser les besoins des clients d'un système et doivent aussi posséder ces caractéristiques. Ils ne doivent pas chercher l'exhaustivité, mais clarifier, filtrer et organiser les besoins !

24 24 5 Cas d’utilisation (représentation) Les noms des acteurs et des uses cases : Doivent être clair Reprendre au maximum la terminologie utilisateur Le nom peut être une forme verbale active

25 25 5. Diagramme de cas d’utilisation Définition : Le diagramme de cas d’utilisation a pour but de montrer les acteurs et les cas d’utilisation d’un système, ainsi que leurs relations Rôle : Modélisation des services visibles de l’extérieur (donc par les acteurs), fournis par le système. Contenu :  Cas d’utilisation  Acteurs  Relation de dépendance, de généralisation, d’association Il existe 2 axes de modélisation :  Orienté système  Orienté client

26 26 5. Diagramme de cas d’utilisation Acteur : élément à l’origine d’un interaction avec le système Note : documente un élément du modèle Nature de l’interaction

27 27 5. Diagramme de cas d’utilisation La relation d’inclusion ou d’utilisation La relation d’extension Indique que le cas d’utilisation source inclus (utilise) le cas d’utilisation cible Par exemple ici : Pour imprimer un solde, il faut consulter un compte Indique que le cas d’utilisation source précise (étend) le cas d’utilisation cible. Point d’extension

28 28 5. Exercice 1 Etude d’une bibliothèque : Dans une bibliothèque, des abonnés peuvent emprunter et restituer des livres auprès d’un bibliothécaire. Un gestionnaire d’abonnement a la charge de gérer les nouveaux abonnés, les résiliations, et les cas litigieux. Définir pour un cas d’utilisation sa prè-condition, sa post-condition, décrire en entier un scénario nominal, donner un titre de scénario alternatif et un titre de scénario d’exception.

29 29 5. Exercice 2 Etude d’une banque de données médicales : Un grand hôpital souhaite pouvoir gérer les dossiers de ses patients de façon centralisée. Pour cela, il a besoin de mettre en place un système d’alimentation des dossiers par les images provenant des différents services (Scanner, Radiologie, IRM, Médecine Nucléaire). Chacun de ces services utilisant des formats d’image différents, il faut que le système permette de stocker toutes les données sous le même format. A chaque fois qu’une nouvelle image vient d’un service, l’ancienne image est historisée, et la nouvelle image est transmise par mail aux médecins suivants le patient.

30 30 5. Exercice 3 Étude d’un téléphone portable : Vous devez concevoir un téléphone portable à carte, le plus simple possible. Ce téléphone possède :  Un répertoire  Une gestion locale des temps de communication  La gestion de l’envoi et de la réception des appels téléphoniques

31 31 Plan 1. Introduction 2. Rappel Objet 3. Présentation générale d’UML 4. Les structures de bases 5. Les Uses Cases 6. Les classes et les objets 7. Les diagrammes de collaborations 8. Les diagrammes d’états-transitions 9. Les diagrammes d’activités 10. UML dans les projets 11. Du Modèle à la réalisation 12. Les outils d’UML

32 32 6. Les classes (Définition et règles) Une classe décrit un ensemble de concepts métiers ou techniques. C’est un type abstrait caractérisé par des propriétés (attributs, méthodes, relation, sémantique) communes, permettant de créer des instances ayant ces propriétés. Un attribut est une propriété nommée d’une classe qui décrit un ensemble de valeur qu’un instance de cette propriété peut prendre. Une méthode est l’implémentation d’un service qui peut être demandée à tous les objets d’une même classe.

33 33 6. Les classes (Représentation) Une classe peut :  Ne pas comporter d’attributs  Ne pas comporter de méthodes  Préciser les valeurs limite de ses attributs  Fournir les niveaux de protection de ses éléments constitutifs Sur le symbole graphique d’une classe :  On peut ne pas représenter les attributs ou les méthodes d'une classe  On peut ne pas spécifier les niveaux de protection des membres d'une classe Le nom d’une classe doit être clair et concis

34 34 6. Les classes (Représentation) Classe Simple Classe Abstraite Classe : non documentée Non de la classe Zone pour les attributs Zone pour les méthodes (ou opérations) Le nom en italique indique une classe abstraite

35 35 6. Les classes (Représentation) Classe Template Non de la classe Paramètre du Template

36 36 6. Les classes (Représentation) Description d’un attribut [visibilité] nom [multiplicité] [:type] [= valeur initiale] [{Chaîne-propriété}] Visibilité : Public (+), protected (#), private (-) Multiplicité : Le nombre d’élément possible pour l’attribut Type : Type de l’attribut Valeur initiale : C’est la valeur par défaut de l’attribut Chaîne-propriété : changeable, addonly, frozen Exemple EscaledeDépart => Nom simple +EscaledeDépart => Attribut Public -EscaledeDépart : String => Nom et type d’un attribut privé -EscaledeDépart [0..5] : String => Tableau de 0 à 5 escales #EscaledeDépart : String = CDG {Frozen} => Attribut protected dont la valeur par défaut et CDG. Cette valeur ne peut être changée après avoir été initialisée. Note Un attribut précédé d’un ‘/’ indique qu’il est dérivée, c’est à dire qu’il est calculé à partir d’autres attributs /tempsDeVol=heure_’arrivée _ heure_départ + 24*variation

37 37 6. Les classes (Représentation) Description d’une opération [visibilité] nom [(Liste des paramètres)] [:type de retour] [{Chaîne-propriété}] Visibilité : Public (+), protected (#), private (-) Liste des paramètres : Signature de la méthode [direction] nom [:Type] [= valeur par défaut] Le type peut être In, Out ou InOut Type de retour : Valeur renvoyée par la méthode Chaîne-propriété : isquery,sequential, guarded, concurrent Exemple TempsdeVol => Non Simple #TempsdeVol => Méthode Privée #TempsdeVol (in TypeAvion : String = 747) : Date => méthode recevant en paramètre le type d’un avion, et retournant une date #FiltrerSignal () {concurrent} => méthode de filtrage numérique permettant un accès concurrent Note Une méthode en italique indique une méthode virtuelle

38 38 6. Les classes (Représentation)  Exemple d’une classe détaillée

39 39 6. Les relations (Présentations) UML définit 3 types de relations :  Les associations  Les dépendances  Les généralisations

40 40 6. Les relations (Les associations) Une association :  C’est un lien nommé entre 2 classes  Elle caractérise une navigabilité Association en forme verbale active Rôles d’une association Permet de décrire la fonction que remplit la classe dans le cadre de cette association On précise le nom de l’association. La flèche définit le sens Escale peut avoir des rôles différents : Départ ou Arrivée d’un vol

41 41 6. Les relations (Les associations) La Multiplicité Précise le nombre d'instances qui participent à une relation La cardinalité est définie comme suit :  1 : exactement 1 (n, entier naturel > 0)  1..n : de 1 à n  0..1 :Aucun ou un  n :n’importe quelle valeur Parfois on trouve * à la place de n Association à navigabilité restreinte Par défaut, une association est navigable dans les deux sens. La réduction exprime que les instances d'une classe ne "connaissent" pas les instances d'une autre. Un vol utilise un et un seul avion, et un vol ne peut se faire sans avion. Un avion peut être utilisé pour un nombre quelconque de vols Un électeur connaît le candidat pour lequel il vote l’inverse n’est pas vrai

42 42 6. Les relations (Les associations) Les classes d’association Il s'agit d'une classe qui réalise la navigation entre les instances d'autres classes Association n-aire C’est une association qui relie plus de 2 classes

43 43 6. Les relations (Les associations) L’agrégation L'agrégation exprime un couplage fort et une relation de subordination. Elle représente une relation de type "ensemble / élément". La composition C’est une agrégation forte  Les cycles de vies des éléments et de l'agrégat sont liés  A un même moment, une instance ne peut être liée qu'à un seul agrégat. Un meuble est un conteneur qui peut contenir de la vaisselle Un livre ne peut exister sans pages, et une page est forcément rattachée à un livre et un seul

44 44 6. Les relations (Les dépendances) Une relation de dépendance permet de symboliser l’emploi d’une classe dans une autre classe. Les deux classes ne sont pas liées d’un point de vue métier, mais d’un point de vue technique.

45 45 6. Les relations (La généralisation) C’est exactement la notion d’héritage

46 46 6. Les classes avancées (Les stéréotypes) L’interface L’interface permet de caractériser les services que l’on va rendre aux clients. Elle symbolise les frontières du système Le contrôleur Le contrôleur permet de définir une classe qui va organiser les processus

47 47 6. Les classes avancées (Les stéréotypes) L’entité C’est une classe qui va servir de conteneur pour relier les objets formant une même abstraction du système

48 48 6. Diagramme de classe Définition : Le diagramme de classe a pour but de présenter une modélisation statique d’un système. Rôle : Présenter un système en faisant intervenir les concepts et les relations entre ces concepts Contenu :  Classes  Packages  Relations Le niveau de granularité dépend du besoin associé au diagramme.

49 49 6. Exercice 1 Etude d’une bibliothèque : Modéliser la bibliothèque (Modèle de domaine)

50 50 6. Exercice 2 Etude d’une banque de données médicales : Faire le modèle de classe du système de gestion des images

51 51 6. Exercice 3 Modéliser le système de téléphone

52 52 6. Instances Les instances sont des représentations concrètes des classes. Elles permettent de définir et d’expliciter un état particulier d’un objet Instance anonyme de laclasse Etudiant Instance nommée de la classe Etudiant Instance nommée d’une classe anonyme Instance nommée de la classe sur laquelle une partie des attributs a été spécifiée Instance multiple ou collection d’instances anonymes

53 53 6. Instances composites Objet Composite : c’est la représentation sous forme d’instance d’une agrégation Constituant de l’agrégat

54 54 6. Diagramme d’objets ou d’instances Définition : Le diagramme d’objets représente un ensemble d’instances de classes et leurs relations. Rôle : Représenter l’état du système (un contexte) à un moment donné du temps afin d’éclaircir ou d’illustrer une situation Contenu :  Instances  Relations  Packages

55 55 Plan 1. Introduction 2. Rappel Objet 3. Présentation générale d’UML 4. Les structures de bases 5. Les Uses Cases 6. Les classes et les objets 7. Les diagrammes de collaborations 8. Les diagrammes d’états-transitions 9. Les diagrammes d’activités 10. UML dans les projets 11. Du Modèle à la réalisation 12. Les outils d’UML

56 56 7. Diagramme de séquence Définition : Les diagrammes de séquences permettent de représenter les échanges, ou collaborations entre objets, d’ un point de vue temporel Rôle : Le diagramme de séquence va permettre de représenter, par exemple, un scénario particulier d’un USE CASE. Contenu :  Instances  Acteurs  Messages (ou opérations)  Notes  Des informations temporelles  Des informations processus

57 57 7. Diagramme de séquence Un diagramme de séquence :  met l’accent sur le comportement du système  est basé sur la chronologie de l’envoi des messages  n’apporte pas d’importance au placement des objets sur l’axe horizontal

58 58 7. Diagramme de séquence (Les rôles) Objet nommé ou non :NonDelaclasse Ligne de vie Période d’activation de l’objet Fin de vie explicite de l’objet Appel Récursif Branchement conditionnel Ne confondez pas la période d'activation d'un objet avec sa création ou sa destruction. L’objet peut être un acteur (rôle) défini dans le diagramme de USE CASE. Pour représenter une exécution conditionnelle, on peut noter du pseudo code. Exemple : If X else endif

59 59 7. Diagramme de séquence (Les messages) Message Synchrone : Bloque l ’expéditeur jusqu’à la prise en compte du message par le récepteur Message Asynchrone : Le message n’interrompt pas l’exécution. Le récepteur peut prendre en compte le message à n’importe quel moment, voir ne pas le prendre en compte. Message Retour : Indique l’envoi d’une réponse à un message ou stimulus

60 60 7. Diagramme de séquence (Les messages) Message réflexif : Permet de représenter une activité interne à l’objet, ou l’abstraction d’une autre interaction. (Cette autre interaction peut être développée dans un autre diagramme de séquence). Messages conditionnels : Permet d’indiquer un choix au niveau du processus. Ce choix est effectué par une condition (If, else). Message avec délai de propagation : Permet de caractériser le temps de transit d’un message Repère de temps Contrainte temporelle

61 61 7. Diagramme de séquence (Syntaxe des messages) La syntaxe est la suivante : [ pré "/"] [["["cond"]"] [séq] ["*"["||"]["["iter"]"]] ":"] [r ":="] msg"("[par]")« pré : C’est une liste de numéros de séquence séparés par une virgule, indiquant que le message courant ne sera envoyé que lorsque tous ses prédécesseurs le seront aussi (permet de synchroniser l'envoi de messages). cond : Permet de conditionner l'envoi du message, à l'aide d'une clause exprimée en langage naturel. Le résultat de la condition est un booléen. séq : numéro de séquence du message. Il indique le rang du message, c'est-à-dire son numéro d'ordre par rapport aux autres messages. Les messages sont numérotés à la façon de chapitres dans un document, à l'aide de chiffres séparés par des points. Pour représenter l'envoi simultané de deux messages, il suffit de les indexer par une lettre. Exemple : l'envoi des messages 1.3.a et 1.3.b est simultané. iter : Permet de signaler une récurrence. Elle spécifie en langage naturel l'envoi séquentiel (ou en parallèle, avec "||") de messages. r : valeur de retour du message. Permet d'affecter la valeur de retour d'un message, pour par exemple la retransmettre dans un autre message, en tant que paramètre. msg : nom du message. par : paramètres du message.

62 62 7. Diagramme de séquence (Syntaxe des messages) 1 : bonjour() Message simple ayant pour numéro de séquence 1. [Etat Personne = Pas Vue] 1 : Bonjour() Message conditionné par l’état de la personne. 1.3 * : ouvrir() Ce message 1.3 est envoyé de manière séquentielle un certain nombre de fois. 3 / *||[i := 1..5] : Fermer() Ce message est envoyé 5 fois en parallèle. Ces messages ne seront envoyés qu'après l'envoi du message 3. 1.3,2.1 / [t < 10s] 2.2 : age := demanderAge(nom,prenom) Le message numéro 2.2 ne sera envoyé qu'après les messages 1.3 et 2.1, et que si "t < 10s". La valeur retournée est un age, et on passe en argument un nom et un prénom. 1.3 / [disk full] 1.7.a * : deleteTempFiles() 1.3 / [disk full] 1.7.b : reduceSwapFile(20%) Ces messages ne seront envoyés qu'après l'envoi du message 1.3 et si la condition "disk full" est réalisée. Si tel est le cas, les messages 1.7.a et 1.7.b seront envoyés simultanément. Plusieurs messages 1.7.a peuvent être envoyés.

63 63 7. Exercice

64 64 7. Diagramme de collaboration Définition : Les diagrammes de collaboration permettent de représenter les échanges, ou collaborations entre objets, en spécifiant l’état de chaque objet Rôle : Le diagramme de collaboration a le même rôle que le diagramme de séquence, à la différence près qu’il permet de caractériser l’état d’un objet. Contenu :  Instances  Acteurs  Messages (ou opérations)  Notes  Des contraintes

65 65 7. Diagramme de collaboration Les objets sont décrits de la même façon qu’au paragraphe 6 (Instances) Les messages ont le même format que pour les diagrammes de séquence Les représentations graphiques des messages sont les mêmes que pour le diagramme de séquence.

66 66 7. Exercice

67 67 Plan 1. Introduction 2. Rappel Objet 3. Présentation générale d’UML 4. Les structures de bases 5. Les Uses Cases 6. Les classes et les objets 7. Les diagrammes de collaborations 8. Les diagrammes d’états-transitions 9. Les diagrammes d’activités 10. UML dans les projets 11. Du Modèle à la réalisation 12. Les outils d’UML

68 68 8. Diagramme d’états-transitions Définition : C’est un graphe d’état et de transitions décrivant les réponses (les états) d’un objet à une sollicitation. Rôle : Il s’agit de représenter une machine à état fini, permettant de décrire un processus ou un algorithme, sous forme d’état et d’arc entre ces états, représentant des transitions. Contenu :  Etats  Transitions

69 69 8. Diagramme d’états-transitions Début d’un diagramme d’état Fin d’un diagramme d’état

70 70 8. Diagramme d’états-transitions (Représentations) Un état représente un objet à un moment donnée de sa vie. L’état de objet est fini dans le temps. Un état peut être représenté par un ensemble d’action :  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 arrive. Cette action bloque toutes les autres actions si elle survient. On peut préciser une liste d’argument à l’événement.  Do / action : Action exécutée dans l’état. Les transitions permettent de nommer l’événement qui va faire changer d’état :  Nom {(argument)} {[In « état »]} /action

71 71 8. Diagrammes d’états-transitions (Etats) Etat complet L’état Historique H Ce symbole représente la mémorisation du dernier état actif pour y revenir directement ultérieurement. Sur l’événement F10 si le user est valide, on envoi un message nommé mail à EnvoiMotDePasse en lui passant en argument le USER

72 72 8. Diagrammes d’états transitions (Etats composites) Les Supers Etats Un état peut être le conteneur d’autres diagramme d’états-transitions.

73 73 8. Diagrammes d’états transitions (Etats composites) Les souches Afin d'introduire plus d'abstraction dans un diagramme d'états-transitions complexe, il est possible de réduire la charge d'information, tout en matérialisant la présence de sous-états, à l'aide de souches.

74 74 8. Diagramme d’états transitions (Synchro, Thread,…) La barre de synchronisation permet de représenter graphiquement des points de synchronisation.  Les transitions qui en partent ont lieu en même temps  On ne la franchit qu'après réalisation de toutes les transitions qui y rentrent Les états concurrents permettent de représenter des Etats concurrents sur un même diagramme. Ces deux états fonctionnent en parallèle. La ligne discontinue indique la frontière Point de synchroPoint de fork

75 75 8. Exercice

76 76 Plan 1. Introduction 2. Rappel Objet 3. Présentation générale d’UML 4. Les structures de bases 5. Les Uses Cases 6. Les classes et les objets 7. Les diagrammes de collaborations 8. Les diagrammes d’états-transitions 9. Les diagrammes d’activités 10. UML dans les projets 11. Du Modèle à la réalisation 12. Les outils d’UML

77 77 9. Diagramme d’activité Définition : Un diagramme d’activité est une variation du diagramme d’état, ou les états sont des activités représentant la réalisation des opérations liées à cet état. La transition entre les activités se fait automatiquement à chaque fois qu’une activité est terminée. Rôle : Ce diagramme permet de fournir la description d’une procédure, sous forme d’un WORKFLOW. Contenu :  Activités  Transitions  Objets

78 78 9. Diagramme d’activité (Représentation) Exemple Début Fin Activité Transition Synchroniser Condition Une Activité peut être une opération (y=pente*x) ou une description de l’action. Dans le cas ou l’activité est présentée sous la forme Nom (), il s'agit d’un état d’activité, c’est à dire que l’action peut être décomposée de façon plus poussée.

79 79 9. Diagramme d’activité (Objets) Il est possible de montrer dans un diagramme d’activité les objets manipulés durant le processus. Le formalisme utilisé est celui des objets (6). Activité Lien Objet

80 80 9. Diagramme d’activité (Travées) Il est possible d’organiser un diagramme d'activités selon les différents responsables des actions représentées. La segmentation se fait par ‘Couloirs D’activités’ ou Travées

81 81 Plan 1. Introduction 2. Rappel Objet 3. Présentation générale d’UML 4. Les structures de bases 5. Les Uses Cases 6. Les classes et les objets 7. Les diagrammes de collaborations 8. Les diagrammes d’états-transitions 9. Les diagrammes d’activités 10. UML dans les projets 11. Du Modèle à la réalisation 12. Les outils d’UML

82 82 10. UML dans les projets Echanger avec son client  Définir ensemble un diagramme de cas d’utilisation  Valider ensemble les scénarios Analyser et concevoir le système  A partir des Uses Cases et des scénarios, définir le diagramme de classe  A partir des scénarios, définir les diagrammes de séquence et de collaboration (et enrichir les classes)  Définir si besoins les diagrammes d’états…..

83 83 10. UML dans les projets La Méthode itérative (basée sur la méthode UP) Le but est d’augmenter le périmètre à chaque étape. La durée d’une étape varie de 15 jours à 3 mois. La phase d’expression et de structuration des besoins correspond à la définition des UC. La phase d’analyse à la définition des classes et des diagrammes de séquence. La phase de conception-réalisation permet de générer le code, appliquer les patterns, écrire les tests unitaires. La phase d’intégration valide le code. La phase de recette valide le produit. A la fin de chaque phase on augmente le périmètre ou on revient sur les choix faits. En cas de non conformité, le problème est traité immédiatement.

84 84 11. Du Modèle à la réalisation(TP)  Présentation des outils  Cas particulier de ROSE  Transposition du modèle de classe en code C++  Exercices  Génération automatique de code  Design patterns

85 85 Web, Bibliographie et contact  www.omg.org : Site officel d’UMLwww.omg.org  www.developpez.com : Site consacré au développement (site francophone)www.developpez.com  Le Guide de l’utilisateur UML (Eyrolles) ISBN : 2-212-09103-6  Le processus unifié (Eyrolles) ISBN : 2-212-09142-7  Le langage C++ (Stroustrup-Campus press) ISBN : 2-7440-0609-2  Pour vos questions : jedivo@airfrance.fr Tél : 01 64 47 79 84