La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

16/08/2014 00:59 1 Jean-Marc Jézéquel IRISA/CNRS et Yves Le Traon IRISA/Ifsic Unified Modeling Language.

Présentations similaires


Présentation au sujet: "16/08/2014 00:59 1 Jean-Marc Jézéquel IRISA/CNRS et Yves Le Traon IRISA/Ifsic Unified Modeling Language."— Transcription de la présentation:

1 16/08/ :59 1 Jean-Marc Jézéquel IRISA/CNRS et Yves Le Traon IRISA/Ifsic Unified Modeling Language

2 16/08/ :59 2 PLAN n Introduction à la modélisation selon UML –historique, intérêts de la modélisation –cycles de vie n Les 9 vues d’un modèle UML –Use Cases, diagrammes de classes, modèles dynamiques, packages... n Processus de développement avec UML –Expression des besoins (étude de cas télécom : serveur SMDS) –Analyse (Technique de découverte des classes...) –Conception (Systémique, notion de Design Patterns) –Réalisation et Validation

3 16/08/ :59 3 Généalogie de UML OOA (P. Coad) OMT (J. Rumbaugh et al.) Data-Flow SADT/SA-SD (De Marco) OOA - OODLE (Schlaer & Mellor) Diagrammes Etat-Transition (HAREL) FUSION (HP-Labs) UML (Rumbaugh, Booch, Jacobson) Use-Case (I.Jacobson) Entite-Relation Merise (Chen) OOA-OOD ( G.Booch ) CLASSE- RELATION (P. Desfray) CRC (R. Wirf-Brooks) JSD (M. Jackson)

4 16/08/ :59 4 De OMT à UML n 1990 : Object-oriented Modeling Technique ( Rumbaugh et al., G.E.) –Succès de la méthode du aux qualités de la notation : –Concise, assez précise, simple à utiliser et à outiller –Rien de fondamentalement nouveau »Inspirée “ entité-relation ” pour la modélisation des objets »Notation de Harel pour la dynamique des objets » De Marco/Yourdon flots de données & transformations n 1995 : Version préliminaire de UML –extensions et améliorations, publications JOOP,... –inspirées par les auteurs eux-mêmes et par Booch n 1997 : UML version 1.0 –Intégration de la méthode OOSE de Jacobson (use-cases), et des remarques de grandes sociétés informatiques –Standardisée à l’OMG. 2Q99 =>Version 1.4

5 16/08/ :59 5 La consécration des méthodes fondées sur la modélisation n L’approche par modélisation facilite –Communication (et sa précision) »avec donneur d’ordre »entre différentes phases de développement et de maintenance –Capacité de vérification »Cohérence »Complétude –Continuité entre les différentes phases du cycle de vie »cf. Jackson et JSD »N.B.: continuité <> isomorphique ou plongement/projection

6 16/08/ :59 6 Un peu de Méthodologie... n Une méthode de développement de logiciels, c’est : –Une notation »La syntaxe --- graphique dans le cas de UML –Un méta-modèle »La sémantique --- paramétrable dans UML (stéréotypes) –Un processus »Détails dépendants du domaine d’activité : n Informatique de gestion n Systèmes réactifs temps-réels n Shrink-wrap software (PC)

7 16/08/ :59 7 Activités du développement de logiciels Définir ce qui sera développé Définir comment il sera développé Développer un des composants Assembler les composants Valider le logiciel n L’organisation de ces activités et leur enchaînement définit le cycle de développement du logiciel

8 16/08/ :59 8 Processus «classique» Expression du besoin Analyse Analyse détaillée Codage Mise au point Réalisation Tests unitaires Validation Mise en œuvre Etude technique préalable Conception préliminaire Conception Conception détaillée Intégration Tests d'Intégration n Cycle de vie normalisé AFNOR Variante US : Cycle en « cascade »

9 9 Problèmes avec le processus classique... Ce que l’analyste a spécifié Ce que le programmeur a écrit Ce que la mise au point a fait Ce que l’utilisateur n’a pas su exprimer Ce que demande l’utilisateur Ce que prévoit le concepteur

10 16/08/ :59 10 Problèmes du processus classique n Organisation « industrielle » héritée du XIX ème siècle –rassurant pour les managers –hiérarchie malsaine dans les rôles –antinomie : Coplien ’s organizational pattern » Architects Also Implement » Architects Also Implement n cycle management <> cycle développement n linéarité implicite –temps d ’approbation des documents => effet tampon –coût de la (non-) modification d ’un document « final » –irréaliste pour un projet innovant, donc à risques

11 16/08/ :59 11 Cycle de vie en « spirale » Intégration Réalisation Conception Analyse détaillée Analyse préliminaire « (de risque) » V1V2 Validation Synergie avec approche par objets

12 16/08/ :59 12 Cycle de vie en « spirale » n Bien adapté au développements innovants –les progrès sont tangibles : c ’est du logiciel qui « tourne » et pas seulement des kilos de documents –possibilité de s ’arrêter « à temps », i.e. avant que l ’irréalisabilité du projet ait crée un gouffre financier n Moins simple à manager –difficile à gérer en situation contractuelle –mal contrôlé => on retombe dans le hacking n Production des incréments asservie sur 2 parmi 3 : –période (e.g. release toutes les 2 semaines) –fonctionnalités (releases découpés suivant use-cases) –niveau de qualité (problème de la mesure)

13 16/08/ :59 13 Vision «générique» d’un cycle UML INCEPTION Cas d'utilisation Modèle des objets du domaine Interfaces Maquettes VALIDATION Validation technique Validation par les utilisateurs ELABORATION Architecture Modèles des objets et scénarios Règles de transformation (Design patterns) CONSTRUCTION Modèle détaillé des objets Scénarios détaillés Algorithmes Codage - Mise au point Intégration UML Modèle utilisateur Modèle statique Modèle dynamique Modèle d’implantation

14 16/08/ :59 14 Modélisation UML n Modélisation selon 4 points de vue principaux : –Vision utilisateur du système »Cas d’utilisation –Aspects statiques du système »Description des données et de leurs relations »Structuration en paquetages –Aspects dynamiques du système (comportemental) »Diagramme de séquences (scénarios) »Diagramme de collaborations (entre objets) »Diagramme d’états-transitions (Harel) »Diagramme d’activités –Vision implantation »Diagramme de composants et de déploiement

15 16/08/ :59 15 Température des diagrammes UML Besoins Conception V & V Analyse Réalisation n Diagramme de cas d’utilisations n Diagramme de classes n Diagramme de paquetages n Diagramme de séquences n Diagramme de collaborations n Diagramme d’états-transitions n Diagramme d’activités n Diagramme d’implantation «Température»

16 16/08/ :59 16 Modélisation UML n Modélisation selon 4 points de vue principaux : –Vision utilisateur du système »Cas d’utilisation –Aspects statiques du système »Description des données et de leurs relations »Structuration en paquetages –Aspects dynamiques du système (comportemental) »Diagramme de séquences (scénarios) »Diagramme de collaborations (entre objets) »Diagramme d’états-transitions (Harel) »Diagramme d’activités –Vision implantation »Diagramme de composants et de déploiement

17 16/08/ :59 17 n Sujet longtemps négligé (e.g. OMT) n Question de l'expression des besoins pourtant fondamentale –Et souvent pas si facile (cible mouvante) »cf. syndrome de la balançoire n Object-Oriented Software Engineering (Ivar Jacobson et al.) –Principal apport : la technique des acteurs et des cas d'utilisation –Cette technique est intégrée a UML Expression des besoins et OOAD

18 16/08/ :59 18 ¶ Se comprendre · Représenter le système ¸ Exprimer le service rendu ¹ Décrire la manière dont le système est perçu Quatre objectifs

19 16/08/ :59 19 Les moyens n Les acteurs UML n Les use-cases UML n Utilisation d’un dictionnaire du domaine

20 16/08/ :59 20 n Outil de dialogue n Informel, évolutif, simple a réaliser n Etablir et figer la terminologie –Permet de figer la terminologie du domaine d'application. –Constitue le point d'entrée et le référentiel initial de l'application ou du système. Intérêt du dictionnaire

21 16/08/ :59 21 Exemple de dictionnaire –Dictionnaire d'un simulateur de vol Notion Définition Nom informatique Traduit en... Pilotage Action de piloter un avion en enchaînant des manoeuvres élémentaires Pilotage Package Manette des gaz Instrument qui permet d'agir sur la quantité de carburant injectée dans le moteur Classe abstraite Manette_gaz Classe Instrument Organe d'interaction entre le pilote et l'avion ou entre l'avion et le pilote Mettre_a_fondOpération Mettre les gaz à fond Action qui permet d’injecter le maximum de carburant pour atteindre la vitesse maximale Action Définition Nom informatiqueTraduit en...

22 16/08/ :59 22 Acteurs n Entité externe au système et amenée à interagir avec lui. Un acteur «joue un rôle» vis-a-vis du système n Un acteur est une classe n Un acteur peut représenter un être humain, un autre système,... n L'identification des acteurs permet de délimiter le système

23 16/08/ :59 23 Acteurs : notations «Actor» SUPERVISEUR CLIENT «Actor» EXPEDITEUR Système de vente par correspondance (VPC)

24 16/08/ :59 24 Les cas d'utilisation (use-cases) n Un cas d'utilisation est une manière particulière d'utiliser le système –séquence d'interactions entre le système et un ou plusieurs acteurs –Ils s’expriment par des diagrammes de séquences n La compilation des cas d'utilisation décrit de manière informelle le service rendu par le système –fournissent une expression "fonctionnelle" du besoin –peuvent piloter la progression d ’un cycle en spirale n Les cas d'utilisation sont nommes en utilisant la terminologie décrite dans le dictionnaire

25 16/08/ :59 25 Cas d'utilisation : exemple et notation CLIENT EXPEDITEUR Traiter commande MAJ catalogue Etablir crédit SUPERVISEUR Commander Consulter VPC

26 16/08/ :59 26 Relations sur les use-cases n Communication –Lien entre le use case et l’acteur. –De type « association » n Utilisation («uses») –Utilisation d’autres use-cases pour en préciser la définition Extension («extends») : utilisation « optionnelle » (attention au sens des flèches. Inclusion (« includes ») : utilisation systématique n Héritage (« Generalization »

27 16/08/ :59 27 Relations sur les use-cases : notation Commander Commander échantillon «extends» Organiser paiement Lire données client Sélectionner produit «includes» Consulter Catalogue

28 16/08/ :59 28 Exprimer le service rendu n Besoins fondamentaux : manières d'utiliser le système –Représentation globale par cas d'utilisation –  taille du système, seulement de 3 à 10 Use Cases n Besoins opérationnels : interactions avec le système –Représentation détaillée par raffinement des cas d'utilisation –Début de décomposition fonctionnelle : ne pas aller trop loin

29 16/08/ :59 29 Besoins fondamentaux et opérationnels n Besoin fondamental : –Conduire une voiture n Besoins opérationnels –Ouvrir la porte –Mettre le contact –Accélérer –Tourner le volant –... conduire une voiture {fondamental} conduire une voiture {fondamental} ouvrir la porte {opérationnel} mettre le contact {opérationnel} accélérer {opérationnel} tourner le volant {opérationnel} «includes»

30 16/08/ :59 30 Utiles pour l’établissement de scénarios n Modélisation d’exemples issus des use-cases Domaine de l’application Utilisateur 1 Utilisateur 2 besoin1 besoin2 besoin3 besoin4 service1() service3() service1() service2() service3() service5() service6() service1() service6() service2() Objet1 Objet2 Objet3 service1 service2 service3 service4 service5 service3 scénario du use case «besoin 2» service4() service5()

31 16/08/ :59 31 Modélisation UML n Modélisation selon 4 points de vue principaux : –Vision utilisateur du système »Cas d’utilisation –Aspects statiques du système »Description des données et de leurs relations »Structuration en paquetages –Aspects dynamiques du système (comportemental) »Diagramme de séquences (scénarios) »Diagramme de collaborations (entre objets) »Diagramme d’états-transitions (Harel) »Diagramme d’activités –Vision implantation »Diagramme de composants et de déploiement

32 16/08/ :59 32 Notations UML pour classes et objets n Représentation d’une classe CL : Compte Représentation simplifiée Nom de la classe Compartiment des Attributs Compartiment des Opérations Compte solde: Somme plancher: Somme créditer (Somme) débiter (Somme) Représentation des objets Nom de l’objet

33 16/08/ :59 33 Constituants d’une classe n Concept représenté (nom) n Classes héritées (concepts précisés) n Relations avec autres classes n Attributs (classe, nom, visibilité) n Opérations (paramètres) n Contraintes, invariants n Généricité (classes paramétrées) n Stéréotypes

34 16/08/ :59 34 Représentation des attributs n Caractérisation des attributs Nom de l'attribut Type de l'attribut ATTRIBUTS Compte solde: Somme plancher: Somme créditer (Somme) débiter (Somme)

35 16/08/ :59 35 Attributs dérivés n Attributs dont la valeur peut être déduite d ’autres éléments du modèle –e.g. âge si l ’on connaît la date de naissance –notation : /age n En termes d ’analyse, indique seulement une contrainte entre valeurs et non une indication de ce qui doit être calculé et ce qui doit être mémorisé

36 16/08/ :59 36 Représentation des opérations n Vues graphiques Nom de l’opération Nom de paramètre Classe du paramètre Compte solde: Somme plancher: Somme créditer (montant: Somme) débiter (montant: Somme)

37 16/08/ :59 37 Représentation des invariants n Des contraintes peuvent être ajoutées aux éléments du modèle UML –notation entre { } n Invariants = Propriétés vraies pour l'ensemble des instances de la classe –dans un état stable, chaque instance doit vérifier les invariants de sa classe –exprimés à l ’aide d ’OCL »Object Constraint Language –e.g. {solde >= plancher} Compte {solde>=plancher} solde: Somme plancher: Somme créditer (Somme) débiter (Somme)

38 16/08/ :59 38 Représentation des pré/post conditions n Préconditions –{«precondition» expression booléenne OCL} –Abrégé en: {pre: expression booléenne OCL} n Postconditions –{«postcondition» expression booléenne OCL} –Abrégé en: {post: expression booléenne OCL} –Operateur « valeur précédente » (idem old Eiffel): »expression

39 16/08/ :59 39 Etre abstrait et précis avec UML Compte {solde>=plancher} solde: Somme plancher: Somme créditer (montant : Somme) {pre: montant > 0} {post: solde = + montant} débiter (s: Somme) {pre: montant > 0 and montant<=solde-plancher} {post: solde = - montant} Analyse précise ou “analyse par contrat”

40 16/08/ :59 40 Relation entre classes n Deux points de vue : –Une relation met en correspondance des éléments d’ensembles –Une relation permet la description d'un concept à l’aide d’autres concepts n Une contrainte : –Une relation est un lien stable entre deux objets

41 16/08/ :59 41 Relation entre classes Personne Voiture Possession Personne Voiture propriétaire propriété possession n Notation n Vue ensembliste = Graphe de la relation Une association met en correspondance des éléments d’ensembles 1 *

42 16/08/ :59 42 Représentation des relations Rôle Nom de relation Cardinalité précisée n Relation, direction, rôle, cardinalité Voiture Personne * passager moyen_de_transport transporte direction de relation Rôle

43 16/08/ :59 43 * Cardinalité d'une relation Classe Exactement une Classe Plusieurs (0 à n) Classe Optionnelle (0 ou 1) Classe 1,2,4 Classe ,1 1 Cardinalité spécifiée Intervalle

44 16/08/ :59 44 Cas particuliers de relations Une relation réflexive lie des objets de même classe encadre sous-fifre chef 1 n Relations réflexives Personne 1..*

45 16/08/ :59 45 n Cas particuliers de relations : –Notion de tout et parties Composition et Agrégation 1 4,6 Roue Voiture Personne * passager moyen_de_transport transporte Chassis 1 Composition Agrégation 1 1 roulement > structure >

46 16/08/ :59 46 n Différentes formes suggérant l’inclusion Autre vues de la composition/agrégation Voiture roulement[4-6]: Roue structure: Chassis Voiture Roue Chassis roulement 4-6 structure 1

47 16/08/ :59 47 Relations n-aires n Relations entre plus de 2 classes (à éviter si possible) MATIERE CLASSE Enseignement 1..* Enseignant Enseignée Destinataire PROFESSEUR * 1..* Enseignant Enseignée 1..* Destinataire 1 PROFESSEUR MATIERE Enseignement CLASSE 1..* 0..*

48 16/08/ :59 48 n L'attribut porte sur le lien Relations attribuées Etudiant Matière candidat objet_épreuve n..k Note épreuve

49 16/08/ :59 49 Qualifieurs de relations n Un qualifieur est un attribut spécial qui permet, dans le cas d'une relation 1-vers-plusieurs ou plusieurs-vers-plusieurs, de réduire la cardinalité. Il peut être vu comme une clé qui permet de distinguer de façon unique un objet parmi plusieurs. Fichier Répertoire Fichier Nom du fichier Répertoire Relation non qualifiée Nom du fichier Relation qualifiée Un répertoire + un nom de fichier identifient de façon unique un fichier 0..*

50 16/08/ :59 50 Représentation de la généralisation (héritage) AVION Héritage simpleHéritage multiple AEROPLANE VEHICULE_DE_TRANSPORT AVION n Héritage simple et multiple

51 16/08/ :59 51 Interfaces et « lollipop » AVION MOBILE Raffinement AVION MOBILE « interface »

52 16/08/ :59 52 Héritage des relations REPERTOIRE 1..* DRIVERFICHIER_TEXTEFICHIER_BINAIRE FICHIER lien logique n Les relations sont héritées par les sous classes : VEHICULEMOTEUR 1..2 VOITURE CAMION motorisation *

53 16/08/ :59 53 Représentation de classes abstraites n Classes sans instances immédiates Une instance de «Forme» est obligatoirement une instance de la classe Carre ou de la classe Cercle Cercle Carre Forme {abstract}

54 16/08/ :59 54 Représentation des opérations abstraites n Opération sans corps d’une classe abstraite calculer_surface () {abstract} Forme {abstract} calculer_surface() CarreCercle calculer_surface()

55 16/08/ :59 55 Visibilité n Différentes visibilités des membres d'une classe Interface corps implémenteur usager héritier privé = - protégé = # public = +

56 16/08/ :59 56 Visibilité #m1 (p1,P2,p3) +a1 : T1 -a2 : T2 +m2 (p1,P2,p3) Classe n Représentation n Pas de sens en analyse...

57 16/08/ :59 57 Classes paramétrées (Généricité) Tableau element : T taille : Entier T, Entier : Integer Tableau > Classe générique Classe effective paramètres génériques paramètres effectifs

58 16/08/ :59 58 Les relations en tant que classes n Pratique dans certains cas –Relations ternaires. –La relation a des opérations appelées : classe de liaison utilisateur station de travail autorisation priorité privilèges session de démarrage répertoire home directory autorisation sur * * *

59 16/08/ :59 59 Les stéréotypes n Nouveaux éléments de modélisation instanciant –Des classes du méta modèle UML (pour les stéréotypes de base UML) –Des extensions de classes du méta modèle UML (pour les stéréotypes définis par l’utilisateur) n Peuvent être attachés aux éléments de modélisations et aux diagrammes : –Classes, objets, opérations, attributs, généralisations, relations, acteurs, uses-cases, événements, diagrammes de collaboration...

60 16/08/ :59 60 Notations pour les stéréotypes «persistent» CLIENT nom : string adresse : string «persistent» CLIENT nom : string adresse : string CLIENT nom : string adresse : string stéréotype

61 16/08/ :59 61 Les notes n Compléments de modélisation –Attachés à un élément du modèle ou libre dans un diagramme –Exprimés sous forme textuelle –Elles peuvent être typées par des stéréotypes modèle réalisé par John Doe PERSONNE ENTREPRISE * 0..1 employéemployeur 0..1 chef {PERSONNE.employeur = PERSONNE.chef.employeur}

62 16/08/ :59 62 Conseils pratiques n Réfléchir au problème avant de commencer –Soigner le nommage, insister sur le nommage des relations et des rôles n Faire simple! –«Things must be as simple as possible, but no simpler». A. Einstein –éviter toute complication nuisible »utiliser les qualifieurs »éviter les relations ternaires, quaternaires (trop complexe) »se dégager de l’implémentation : raisonner objets, classes, messages, relations, attributs, opérations –ne pas s’inquiéter si les possibilités de la notation ne sont pas toutes exploitées

63 16/08/ :59 63 Conseils pratiques (suite) n Approche incrémentale –Itérer –Confronter ses modèles aux autres –Savoir s'arrêter avant d’atteindre la perfection... »prise en compte qualité (niveau de précision), coûts, délais... »asservissement au processus de développement n Faire simple (encore) –Un bon modèle n’est pas un modèle où l’on ne peut plus rien ajouter, mais un modèle où on ne peut plus rien enlever. (d’après A. de St-Exupéry)

64 16/08/ :59 64 Modélisation UML n Modélisation selon 4 points de vue principaux : –Vision utilisateur du système »Cas d’utilisation –Aspects statiques du système »Description des données et de leurs relations »Structuration en paquetages –Aspects dynamiques du système (comportemental) »Diagramme de séquences (scénarios) »Diagramme de collaborations (entre objets) »Diagramme d’états-transitions (Harel) »Diagramme d’activités –Vision implantation »Diagramme de composants et de déploiement

65 16/08/ :59 65 Notion de package n Élément structurant les classes –Modularisation à l'échelle supérieure –Un package partitionne l'application : »Il référence ou se compose des classes de l’application »Il référence ou se compose d’autres packages –Un package réglemente la visibilité des classes et des packages qu’il référence ou le compose –Les packages sont liés entre eux par des liens d'utilisation, de composition et de généralisation –Un package est la représentation informatique du contexte de définition d’une classe

66 16/08/ :59 66 Représentation d’un package n Vue graphique externe n Vue graphique externe n Vue graphique externe et interne n Vue graphique externe et interne P1 P2 P3 C1 C2 P1

67 16/08/ :59 67 n Définition de vues partielles d'une application Partitionnement d’une application ENSEMBLE DES CLASSES DE L'APPLICATION SYNTHÈSE EN PACKAGES N.B.: une classe appartient à un et un seul package

68 16/08/ :59 68 n Réglementation de la visibilité des classes –Classes de visibilité publique : »classes utilisables par des classes d’autres packages –Classes de visibilité privée : »classes utilisables seulement au sein d’un package n Représentation graphique Visibilité dans un package CLASSE D'INTERFACE CLASSE DE CORPSCLASSE EXTERNE {public } Classe {private } Package::Classe

69 16/08/ :59 69 Utilisation entre packages n Définition –Il y a utilisation entre packages si des classes du package utilisateur accèdent à des classes du package utilisé –Pour qu’une classe d’un package p1 puisse utiliser une classe d’un package p2, il doit y avoir au préalable une déclaration explicite de l’utilisation du package p2 par le package p1 n Représentation graphique P2P1 Vue externe du package P1

70 16/08/ :59 70 Utilisation entre packages n Exemple (vue externe du package livraisons) LIVRAISONS VEHICULES COLIS LIVREURS

71 16/08/ :59 71 Héritage entre packages n Exemples JeuPlateau JeuDame JeuEchec Windowing System Motif MicrosoftWindows

72 16/08/ :59 72 Utilité des packages n Réponses au besoin –Contexte de définition d'une classe –Unité de structuration –Unité d'encapsulation –Unité d'intégration –Unité de réutilisation –Unité de configuration –Unité de production

73 16/08/ :59 73 Structuration par packages (vs) décomposition hiérarchique u Pour les grands systèmes, il est nécessaire de disposer d’une unité de structuration : v À un niveau supérieur, v Plus souple que : v La composition de classe v Le référençage de packages => domaines de structuration : Packages décomposables en packages

74 16/08/ :59 74 Exemple : Package entreprise n Exemple de composition ENTREPRISE COMPTABILITÉ COMMERCIAL LIVRAISON

75 16/08/ :59 75 Exemple : Package entreprise n Ensemble des packages terminaux de l’application Véhicules Personnel Colis Clientèles Livraisons Facturation Bilan Livreurs Commerciaux Tenue Comptes

76 16/08/ :59 76 Exemple : Package entreprise n Composition des packages en sous-packages COMMERCIAL ENTREPRISE COMPTABILITÉ Facturation Tenue Comptes Personnel Bilan LIVRAISONS Véhicules Livreurs Livraisons Colis Clientèles Commerciaux

77 16/08/ :59 77 Modélisation UML n Modélisation selon 4 points de vue principaux : –Vision utilisateur du système »Cas d’utilisation –Aspects statiques du système »Description des données et de leurs relations »Structuration en paquetages –Aspects dynamiques du système (comportemental) »Diagramme de séquences (scénarios) »Diagramme de collaborations (entre objets) »Diagramme d’états-transitions (Harel) »Diagramme d’activités –Vision implantation »Diagramme de composants et de déploiement

78 16/08/ :59 78 Aspects dynamiques du système n Jusqu’ici, système décrit statiquement: –Décrivent les messages (méthodes ou opérations) que les instances des classes peuvent recevoir mais ne décrivent pas l’émission de ces messages –Ne montrent pas le lien entre ces échanges de messages et les processus généraux que l’application doit réaliser n Il faut maintenant décrire comment le système évolue dans le temps

79 16/08/ :59 79 Modélisation UML n Modélisation selon 4 points de vue principaux : –Vision utilisateur du système »Cas d’utilisation –Aspects statiques du système »Description des données et de leurs relations »Structuration en paquetages –Aspects dynamiques du système (comportemental) »Diagramme de séquences (scénarios) »Diagramme de collaborations (entre objets) »Diagramme d’états-transitions (Harel) »Diagramme d’activités –Vision implantation »Diagramme de composants et de déploiement

80 16/08/ :59 80 Diagrammes de séquences (scénarios) n Dérivés des scénarios de OMT : –Montrent des exemples de coopération entre objets dans la réalisation de processus de l’application –Illustrent la dynamique d’enchaînement des traitements à travers les messages échangés entre objets –le temps est représenté comme une dimension explicite »en général de haut en bas n Les éléments constitutifs d’un scénario sont : –Un ensemble d’objets (et/ou d’acteurs) –Un message initiateur du scénario –La chronologie des messages échangés subséquemment –Les contraintes de temps (aspects temps réel)

81 16/08/ :59 81 Syntaxe graphique n Objets et messages Nom Objet1:NomClasse1 Nom Objet:NomClasse Objets = Instances de classes nom message (paramètres) Message nom message émis par Nom Objet vers Nom Objet1 Temps

82 16/08/ :59 82 Ligne de vie et activation n La «ligne de vie» représente l’existence de l’objet à un instant particulier –Commence avec la création de l’objet –Se termine avec la destruction de l’objet n L’activation est la période durant laquelle l’objet exécute une action lui-même ou via une autre procédure

83 16/08/ :59 83 Notation objet1:Classe1 objet2:Classe2 objet3:Classe3 Client op ( ) m1 ( ) m2 ( ) m3 ( ) Objet créé dans le scénario Activité de l’objet Objet existant avant et après l’activation du scénario Ligne de vie

84 16/08/ :59 84 Messages n Communication entre objets –Des paramètres –Un retour n Cas particuliers –Les messages entraînant la construction d’un objet –La récursion –Les destructions d’objets

85 16/08/ :59 85 Notations objet1:Classe1 op ( ) objet2:Classe2 m1 ( par ) Création d’objet Destruction d’objet Retour d’opération Envoi de message avec paramètre m2 ( ) Récursion

86 16/08/ :59 86 Aspects asynchrones et temps réel n Lecture du scénario et chronologie –Un scénario se lit de haut en bas dans le sens chronologique d’échange des messages. –Des contraintes temporelles peuvent être ajoutées au scénario :Nom classe2 Nom Objet1: demande réponse a b {b-a< 5 sec.} :Nom classe2Nom Objet1: demande d d’ {d’-d< 1 sec.}

87 16/08/ :59 87 Représentation de conditionnelles objet1:Classe1 op ( ) objet2:Classe2 [x<0] m1 ( x ) [x>0] m2 ( x ) Branchement conditionnel

88 16/08/ :59 88 Modélisation UML n Modélisation selon 4 points de vue principaux : –Vision utilisateur du système »Cas d’utilisation –Aspects statiques du système »Description des données et de leurs relations »Structuration en paquetages –Aspects dynamiques du système (comportemental) »Diagramme de séquences (scénarios) »Diagramme de collaborations (entre objets) »Diagramme d’états-transitions (Harel) »Diagramme d’activités –Vision implantation »Diagramme de composants et de déploiement

89 16/08/ :59 89 Diagrammes de collaboration n Les scénarios et diagrammes de collaboration: –Montrent des exemples de coopération des objets dans la réalisation de processus de l’application n Les scénarios : –Illustrent la dynamique d’enchaînement des traitements d’une application en introduisant la dimension temporelle n Les diagrammes de collaboration –Dimension temporelle représentée par numéros de séquence : définition d’un ordre partiel sur les opérations –Représentation des objets et de leurs relations –Utilisent les attributs et opérations

90 16/08/ :59 90 Utilisation des diagrammes de collaboration n Ils peuvent être attachés à : –Une classe –Une opération –Un use-case n Ils s’appliquent –En spécification –En conception (illustration de design patterns)

91 16/08/ :59 91 Eléments constitutifs n Un contexte contenant les éléments mis en jeu durant l’opération : –Un acteur –Un ensemble d’objets, d’attributs et de paramètres –Des relations entre ces objets n Des interactions –Des messages –Un message initiateur du diagramme provenant d’un »Acteur de l’application, »Objet de l’application. –Les numéros de séquence des messages échangés entre les objets de cet ensemble suite au message initiateur

92 16/08/ :59 92 Fred MariePierre pèremère 1:cashRequest($25) 2:cashReceived($25) Représentation d’une collaboration (niveau instance)

93 16/08/ :59 93 Equivalent au diagramme de séquence: cashRequest($25) cashReceived($25) MarieFred

94 16/08/ :59 94 Syntaxe graphique n Les messages »Opérations »Réception d’événements n Le séquencement »Les séquences consécutives »Les séquences imbriquées :Segment :Carré afficher ( ) 4 origine:Point 1 *(i=1..4):afficher ( ) destination:Point 1.1: position ( ) 1.2: position ( ) séquence imbriquée message initiateur numéro de séquence opération boucle

95 16/08/ :59 95 Questions auxquelles répondent les collaborations n Quel est l’objectif ? n Quels sont les objets ? n Quelles sont leurs responsabilités ? n Comment sont-ils interconnectés ? n Comment interragissent-ils ?

96 16/08/ :59 96 Collaboration : Niveau Spécification Définition du ClassifierRole A ClassifierRole is a named slot for an object participating in a Collaboration. Object behavior is represented by its participation in the overall behavior of the Collaboration. Object identity is preserved through this constraint: "In an instance of a collaboration, each ClassifierRole maps onto at most one object."

97 16/08/ :59 97 Collaboration de Niveau Spécification un exemple simple / Enfant / Mère/ Père pèremère 1:cashRequest($25) 2:cashReceived($25)

98 16/08/ :59 98 Modélisation UML n Modélisation selon 4 points de vue principaux : –Vision utilisateur du système »Cas d’utilisation –Aspects statiques du système »Description des données et de leurs relations »Structuration en paquetages –Aspects dynamiques du système (comportemental) »Diagramme de séquences (scénarios) »Diagramme de collaborations (entre objets) »Diagramme d’états-transitions (Harel) »Diagramme d’activités –Vision implantation »Diagramme de composants et de déploiement

99 16/08/ :59 99 Les diagrammes d’états n Attachés à une classe –Généralisation des scénarios –Description systématique des réactions d'un objet aux changements de son environnement n Décrivent les séquences d’états d’un objet ou d’une opération : –En réponse aux «stimulis» reçus –En utilisant ses propres actions (transitions déclenchées) n Réseau d’états et de transitions –Automates étendus –Essentiellement Diagrammes de Harel (idem OMT)

100 16/08/ : Syntaxe graphique: diagramme d’états Evt1 [cond] / m() ^Evt2 E1 E2 état transition événement reçu événement émis action condition de garde Syntaxe : EvénementReçu (param : type,...) [condition de garde] / Action ^EvénementsEmis Syntaxe : EvénementReçu (param : type,...) [condition de garde] / Action ^EvénementsEmis

101 16/08/ : Notion d’événements n Stimulis auxquels réagissent les objets –Occurrence déclenchant une transition d’état n Abstraction d'une information instantanée échangée entre des objets et des acteurs –Un événement est instantané –Un événement correspond à une communication unidirectionnelle –Un objet peut réagir à certains événements lorsqu'il est dans certains états. –Un événement appartient à une classe d'événements (classe stéréotypée «signal»).

102 16/08/ : Les événements «signal» IO_EVENT time «signal» USER_INPUT device «signal» NETWORK_EVENT «signal» MOUSE_EV «signal» KEYBD_EV n Les événements sont considérés comme des objets location character...

103 16/08/ : Typologie d’événements n Réalisation d’une condition arbitraire –transcrit par une condition de garde sur la transition n Réception d’un signal issu d’un autre objet –transcrit en un événement déclenchant sur la transition n Réception d’un appel d’opération par un objet –transcrit comme un événement déclenchant sur la transition n Période de temps écoulée –transcrit comme une expression du temps sur la transition

104 16/08/ : Notion d ’action n Action : opération instantanée (conceptuellement) et atomique (ne peut être interrompue) n Déclenchée par un événement –Traitement associé à la transition –Ou à l ’entrée dans un état ou à la sortie de cet état User_input / mise_sous_tension délai_mise_en_veille / passage_en_mode_veille Veille Allumé action

105 16/08/ : Notion d’états n Etat : situation stable d’un objet parmi un ensemble de situations pré-définies –conditionne la réponse de l’objet à des événements »programmation réactive / « temps réel » –Intervalle entre 2 événements, il a une durée n Peut avoir des variables internes –attributs de la classe supportant ce diagramme d’états

106 16/08/ : Structuration en sous-états n Problème d'un diagramme d'états plats –Pouvoir d'expression réduit, inutilisable pour de grands problèmes –Explosion combinatoire des transitions. n Structuration à l ’aide de super/sous états (+ hiérarchies d ’événements) –représentés par imbrication graphique

107 16/08/ : Notion d ’activité dans un état n Activité : opération se déroulant continuement tant qu ’on est dans l ’état associé –do/ action n Une activité peut être interrompue par un événement. Téléphone N° invalideTéléphone raccroché Invalide do / passer message activité

108 16/08/ : Exemple de diagramme d'états n un téléphone : Actif En composition connecté décroche combiné Repos Appelé raccroche DialogueSonnerie do/ sonne Réponse de l’appelé/ autorise parole Compose numéro (n) Appelant raccroche/ déconnexion Tonalité do/ joue tonalité Occupé do/ tonalité occupée occupé 15 sec Invalide do/ dit message Compose numéro (n) [n.isInvalid] Timeout do/ timeout tone 15 sec Compose numéro (n) Etablissement Occupé Libre Dernier numéro

109 16/08/ : Émission d’événements n Automate d’états d’une télécommande double : –TV + MAGNETOSCOPE Contrôle distant MAGNETOSCOPE TV contrôle TV contrôle MAGNETO bouton marche ^signal ON/OFF Télévision ArrêtMarche signal ON/OFF

110 16/08/ : Diagrammes d'états concurrents n Utilisation de sous-états concurrents pour ne pas à avoir à expliciter le produit cartésien d ’automates –si 2 ou plus aspects de l ’état d ’un objet sont indépendants –Activités parallèles n Sous-états concurrents séparés par pointillés –« swim lanes »

111 16/08/ : Exemple de concurrence Préparation d'un avion Remplissage Plein Maintenance Réservoir plein préparation Avion prêt Chargement nourriture Nourriture chargée Approvisionnement Compartiment plein Equipage absent Vérification avion Equipage Montée vérification OK

112 16/08/ : Etat-transition (résumé) n Format : –événement (arguments) [conditions] / action ^événements provoqués n Déclenchement : – par un événement (peut être nul). »Peut avoir des arguments. –Conditionné par des expressions booléennes sur l'objet courant, l'événement, ou d'autre objets. n Tir de la transition : –Exécute certaines actions instantanément. –Provoque d'autres événements ; globaux ou vers des objets cibles.

113 16/08/ : Modélisation UML n Modélisation selon 4 points de vue principaux : –Vision utilisateur du système »Cas d’utilisation –Aspects statiques du système »Description des données et de leurs relations »Structuration en paquetages –Aspects dynamiques du système (comportemental) »Diagramme de séquences (scénarios) »Diagramme de collaborations (entre objets) »Diagramme d’états-transitions (Harel) »Diagramme d’activités –Vision implantation »Diagramme de composants et de déploiement

114 16/08/ : Les diagrammes d’activité n Traitements effectués par une opération –Description d’un flot de contrôle procédural »Réseau d’actions et de transitions : automate dégénéré »La transition s’effectue lorsque l’opération est terminée –Pas de déclenchement par événement asynchrone »Sinon utilisation diagrammes d’états classiques n Attachés à –une classe, –une opération, –ou un use-case (workflow)

115 16/08/ : Etat-action et décision n Etat-action = raccourci pour un état où il y a : –une action interne –au moins une transition sortante »production d’un événement implicite : action accomplie –Pas de production/réaction à des événements explicites n Modélisation d’une étape dans l'exécution d’un algorithme –Notation : n Décision = branchement sur plusieurs transitions –Notation : obtenir un gobelet [coût<50] [coût>=50]

116 16/08/ : Exemple de diagramme d’activité déterminer boisson mettre le café dans le filtre mettre le filtre dans la machine obtenir une canette de soda boire verser café infuser obtenir un gobelet ajouter de l’eau dans le réservoir [demande café] [pas de café] [demande soda] [pas de soda] opération PréparerBoisson de la classe Personne

117 16/08/ : Stéréotypes optionnels n Emission de signal n Réception de signal n On obtient une syntaxe graphique proche de SDL –langage de description de spécifications –populaire dans le monde télécom Allumer cafetière Voyant s’éteint

118 16/08/ : Liens modèles statiques/dynamiques n Le modèle dynamique définit des séquences de transformation pour les objets –Diagramme d'état généralisant pour chaque classe ayant un comportement réactif aux événements les scénarios et collaborations de leurs instances »Les variables d'état sont des attributs de l'objet courant »Les conditions de déclenchement et les paramètres des actions exploitent les variables d'état et les objets accessibles –Diagrammes d’activités associés aux opérations/transitions/méthodes n Les modèles dynamiques d'une classe sont transmis par héritage aux sous-classes

119 16/08/ : Modélisation UML n Modélisation selon 4 points de vue principaux : –Vision utilisateur du système »Cas d’utilisation –Aspects statiques du système »Description des données et de leurs relations »Structuration en paquetages –Aspects dynamiques du système (comportemental) »Diagramme de séquences (scénarios) »Diagramme de collaborations (entre objets) »Diagramme d’états-transitions (Harel) »Diagramme d’activités –Vision implantation »Diagramme de composants et de déploiement

120 16/08/ : Diagrammes d’implantation n Diagrammes de composants –Dépendances entre composants logiciels »code source »binaires, DLL »exécutables n Diagrammes de déploiement –Configuration des composants –Localisation sur les noeuds d’un réseau physique

121 16/08/ : Exemples de composants Dictionnaire PlannerGUI Vérificateur Synonymes Interfaces Composants

122 16/08/ : Exemple de déploiement GUIDictionnairePlanner MachineServeur MachineClient1 MachineClient2 Noeuds

123 16/08/ : Modélisation UML n Modélisation selon 4 points de vue principaux : –Vision utilisateur du système »Cas d’utilisation –Aspects statiques du système »Description des données et de leurs relations »Structuration en paquetages –Aspects dynamiques du système (comportemental) »Diagramme de séquences (scénarios) »Diagramme de collaborations (entre objets) »Diagramme d’états-transitions (Harel) »Diagramme d’activités –Vision implantation »Diagramme de composants et de déploiement

124 16/08/ : Processus de développement avec UML ?


Télécharger ppt "16/08/2014 00:59 1 Jean-Marc Jézéquel IRISA/CNRS et Yves Le Traon IRISA/Ifsic Unified Modeling Language."

Présentations similaires


Annonces Google