Unified Modeling Language

Unified Modeling Language
Jean-Marc Jézéquel IRISA/CNRS et Yves Le Traon IRISA/Ifsic 05/04/ :21

PLAN Introduction à la modélisation selon UML
historique, intérêts de la modélisation cycles de vie Les 9 vues d’un modèle UML Use Cases, diagrammes de classes, modèles dynamiques, packages... 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 05/04/ :21

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

De OMT à UML 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 1995 : Version préliminaire de UML extensions et améliorations, publications JOOP, ... inspirées par les auteurs eux-mêmes et par Booch 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 l’OMG devrait adopter à la mi-97 UML comme un standard. L’industrialisation d’UML dans les outils et son utilisation par les méthodologistes devrait suivre. 05/04/ :21

La consécration des méthodes fondées sur la modélisation
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 Il est nécessaire que l'on puisse exprimer tous les problèmes, avec un niveau de précision et de cohérence maximal pour obtenir une traduction immédiate en code applicatif. Le modèle devient un véritable langage de représentation de problème (on n'ose pas encore parler de L5G). 05/04/ :21

Un peu de Méthodologie... 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é : Informatique de gestion Systèmes réactifs temps-réels Shrink-wrap software (PC) 05/04/ :21

Activités du développement de logiciels
Valider le logiciel Assembler les composants Développer un des composants Définir comment il sera développé Définir ce qui sera développé Le processus de développement se décompose en plusieurs phases qui sont généralement formalisées dans le cycle de vie du logiciel. Le processus de développement doit également permettre de mesurer le travail réalisé par l'équipe projet depuis l'expression des besoins par le client jusqu'à la recette du produit final. Il existe plusieurs types de cycle de vie, cependant dans tous les cycles de vie les phases sont liées entre elles pour former une séquence d'activités. L’organisation de ces activités et leur enchaînement définit le cycle de développement du logiciel 05/04/ :21

Processus «classique»
Cycle de vie normalisé AFNOR Analyse Validation • Expression du besoin • Validation • Analyse détaillée • Mise en œuvre Conception Intégration • Etude technique préalable • Intégration • Conception préliminaire • Tests d'Intégration • Conception détaillée DEFINITION GENERALE DE CHAQUE PHASE Définir la compréhension du besoin, le cadre du développement par rapport au système existant mais aussi la liste des contraintes. A ce stade, il faut aussi définir les utilisateurs externes au logiciel et ses grands packages de service. analyse détaillée permet de spécifier précisément l'ensemble des services fournis par le logiciel. En phase d'analyse il faut toujours rester dans une vision externe du logiciel. Conception Cette phase se décompose en étude technique initiale permettant de définir l'architecture technique du logiciel et les principes d'implémentation. conception préliminaire permettant de formaliser l'architecture technique avec l'ensemble des concepts techniques. conception détaillée permettant de préciser les services techniques et de préparer la phase de développement. Développement des composants Cette phase regroupe les activités de codage (ou implémentation des services), de mise au point des composants et leur test unitaire. Intégration Cette phase regroupe les activités d'assemblage des composants et de tests des sous-ensembles du logiciel afin de valider l'architecture technique. Validation Cette phase permet de vérifier la conformité du logiciel à ses spécifications. Réalisation • Codage • Mise au point • Tests unitaires Variante US : Cycle en « cascade » 05/04/ :21

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

Problèmes du processus classique
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 cycle management <> cycle développement 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 05/04/ :21

Cycle de vie en « spirale »
Intégration Réalisation Conception Analyse détaillée Analyse préliminaire « (de risque) » V1 V2 Validation CYCLES DE VIE TRADITIONNELS le cycle "en cascade" (ou "waterfall") définit les phases d'analyse (décrire le "quoi"), de conception (définir "comment" le système sera réalisé et comment il se décompose) de codage (réalisation de chaque composant), de test unitaire (validation de chaque composant), d'intégration (assemblage des composants), de validation (vérification de la conformité du produit par rapport à sa spécification). le cycle en "V" est une variante du cycle "en cascade", il fait la distinction entre les phases de construction du logiciel et les phases de vérification. Il établit également les liens entre ces phases de construction et les phases de vérification. En général, ces types de cycle de vie mettent l'accent sur les liens entre phases et les moyens de passage de l'une à l'autre, y compris lors de retour arrière. CYCLE EN SPIRALE Les cycles de vie traditionnels ne garantissent pas totalement les incohérences entre phases et n'assurent pas que le cycle de vie puisse être appliqué intégralement (par exemple, si l'analyse est trop vague ou incohérente, la phase de conception sera difficile à réaliser ce qui nécessitera de nombreux retours en phase d'analyse. De plus, cette situation engendre des impossibilités dans le contrôle du déroulement du projet. Pour palier ces manques, Barry Boehm a défini le cycle en spirale qui ponctue chaque phase par une analyse des risques encourus sur la phase suivante. Si les risques sont importants, l'équipe aura recourt à du prototypage. L'objectif étant de se lancer dans un développement traditionnel seulement lorsque tous les risques sont maîtrisés. APPROCHE ORIENTEE OBJET Avec une opération telle que UML, l'équipe formalise le problème avec le même modèle tout au long du cycle de vie. Ceci nécessite évidemment de proposer une solution méthodologique complète. Synergie avec approche par objets 05/04/ :21

Cycle de vie en « spirale »
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 Moins simple à manager difficile à gérer en situation contractuelle mal contrôlé => on retombe dans le hacking 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) 05/04/ :21

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

Modélisation UML 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 05/04/ :21

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

Expression des besoins et OOAD
Sujet longtemps négligé (e.g. OMT) Question de l'expression des besoins pourtant fondamentale Et souvent pas si facile (cible mouvante) cf. syndrome de la balançoire 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 De manière générale, les méthodes orientées-objet sont faibles sur l'aspect "expression des besoins", en particulier lorsqu'il s'agit de tenir compte du point de vue de l'utilisateur et pas seulement de celui de l'informaticien. Classiquement (cf. OMT), la phase "analysis" a pour objectif de décrire le système d'un point de vue externe, à l'aide de classes. Il s'agit d'un bon outil pour l'informaticien, mais pas complètement satisfaisant pour l'utilisateur Seules les méthodes de P. Desfray et celle de I. Jacobson traitent explicitement la question. Les deux approches sont plus complémentaires que concurrentes. UML dans sa version 1.0 intègre la méthode OOSE de I.Jacobson en définissant les «use case». 05/04/ :21 1

Quatre objectifs Se comprendre Représenter le système
Exprimer le service rendu Décrire la manière dont le système est perçu L'expression des besoins est un travail difficile, peut-être le plus difficile en pratique. C'est la qualité de ce travail qui détermine quel sera au bout du compte le coût du système développé. Il faut tout d'abord se comprendre, c'est-à-dire être certain que les utilisateurs et les informaticiens ont la même vision des concepts du domaine à informatiser (qu'est-ce qu'une image de télévision numérique? qu'est-ce qu'une facture? qu'est-ce qu'un missile, qu'est-ce qu'un client? ...) et de la manière dont ils sont liés les uns aux autres. Ensuite, il faut s'accorder sur l'organisation générale du système : quelles en sont les grandes parties, quels en sont les utilisateurs, quels rôles jouent-ils exactement, quels sont les grand flots d'informations entre utilisateurs et parties du système? Il faut enfin spécifier les différentes manières d'utiliser le système, du point de vue de l'utilisateur, et la manière dont le système est perçu par son environnement (interfaces). 05/04/ :21 2

Les moyens Les acteurs UML Les use-cases UML
Utilisation d’un dictionnaire du domaine 05/04/ :21

Intérêt du dictionnaire
Outil de dialogue Informel, évolutif, simple a réaliser 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. Le dictionnaire est un outil méthodologique important. Il permet de réunir utilisateurs et informaticiens autour d'un objectif commun. La communication et donc la qualité de l'expression des besoins s'en trouvent améliorées. La terminologie issue du cahier des charges doit être reprise et précisée, afin d'en extraire le dictionnaire. Les concepts de ce dictionnaire (noms communs) sont candidats à être des classes, relations ou attributs, alors que les actions (verbes) sont candidats à être des opérations. Le cahier des charges peut comporter des manques et des incohérences. Un premier objectif du dictionnaire est de clarifier ces aspects. Le dictionnaire est un document de référence, qui fait foi au cours du projet. Les définitions précises des termes du dictionnaire doivent permettre de régler les cas des synonymes (plusieurs termes ont la même définition) et des polysémies (un même terme à plusieurs sémantiques). 05/04/ :21 5

Exemple de dictionnaire
Dictionnaire d'un simulateur de vol Notion Définition Traduit en ... Nom informatique Pilotage Action de piloter un avion en enchaînant des manoeuvres élémentaires Package Pilotage Instrument Organe d'interaction entre le pilote et l'avion ou entre l'avion et le pilote Classe abstraite Instrument Manette des gaz Instrument qui permet d'agir sur la quantité de carburant injectée dans le moteur Classe Manette_gaz En tant que référentiel, le dictionnaire doit être mis à jour, afin de garantir la traçabilité entre les besoins exprimés et le système développé. Action Définition Traduit en ... Nom informatique Action qui permet d’injecter le maximum de carburant pour atteindre la vitesse maximale Mettre les gaz à fond Opération Mettre_a_fond 05/04/ :21 6

Acteurs Entité externe au système et amenée à interagir avec lui. Un acteur «joue un rôle» vis-a-vis du système Un acteur est une classe Un acteur peut représenter un être humain, un autre système, ... L'identification des acteurs permet de délimiter le système Un acteur est une classe, ayant le stéréotype «Actor», qui représente ses instances potentielles. L'ensemble des utilisateurs de même nature pour un système (tous les comptables) sera représenté par un seul acteur. Un même utilisateur physique peut jouer successivement plusieurs rôles logiques vis-à-vis d'un système. Par exemple un garagiste peut faire une vidange mais aussi conduire la voiture. Il est successivement l'instance de deux acteurs différents Un acteur primaire est celui pour lequel le système est directement prévu (le conducteur dans le cas de la voiture). Un acteur secondaire n'existe qu'en raison des acteurs primaires (le garagiste dans le cas de la voiture). Cette distinction permet de structurer l'expression des besoins, et par exemple de spécifier des exigences de qualité plus ou moins fortes en fonction du type d'acteur. 05/04/ :21 6

Acteurs : notations CLIENT Système de vente par correspondance (VPC)
«Actor» EXPEDITEUR «Actor» SUPERVISEUR Un acteur se représente soit sous la forme d’une classe avec le stéréotype «Actor» où le nom de l’acteur apparaît à la place du nom de la classe, soit sous la forme d’une figure stylisée d’un homme avec le nom de l’acteur en dessous, soit encore comme un combiné des deux. Le conducteur est un acteur primaire Le garagiste est un acteur secondaire La notion de système se représente par un rectangle vide incluant son nom (nom de l’application ou du système). Les acteurs sont extérieurs au système, ils ne font qu’interargir avec. 05/04/ :21 6

Les cas d'utilisation (use-cases)
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 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 Les cas d'utilisation sont nommes en utilisant la terminologie décrite dans le dictionnaire Un cas d'utilisation "use-case" est une manière particulière d'utiliser le système. Les cas d'utilisation permettent d'exprimer rapidement et simplement les besoins fondamentaux d'un point de vue complètement externe au système. On définit une relation entre l’acteur et chacun de ses use-cases (relation comme entre 2 classes). L’acteur communique avec le use-case, il participe au cas d’utilisation. Un use-case peut être relié à plusieurs acteurs. 05/04/ :21 6

Cas d'utilisation : exemple et notation
VPC Commander Consulter EXPEDITEUR Traiter commande CLIENT SUPERVISEUR MAJ catalogue La notation pour un use-case est une ellipse entourant le nom du cas d’utilisation. Etablir crédit 05/04/ :21 6

Relations sur les use-cases
Communication Lien entre le use case et l’acteur. De type « association » 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 Héritage (« Generalization » L’relation "uses" indique une lien d’utilisation sur d’autres use-cases. Comme le use-case utilisateur a besoin des autres uses cases pour se définir, on peut parler de use-case abstrait L’relation "extends" indique l’relation avec une séquence d'interactions qui peut être considérée en tant que telle comme un cas d'utilisation concret. Le cas d’utilisation qui est étendu est inclus dans les comportements du cas d’utilisation «extenseur». Il y a une notion voisine de la généralisation. 05/04/ :21

Relations sur les use-cases : notation
Commander Commander échantillon «includes» «extends» Lire données client «includes» Consulter Catalogue «includes» Sélectionner produit La représentation d’une généralisation ou d’une utilisation est une flèche (comme l’héritage entre classes) avec une précision de type «stéréotype». La représentation de la communication entre l’acteur et le use-case est une ligne reliant les 2. Le stéréotype «extend» précise que la relation est de type généralisation. La réparartion d’une Ferrari est un cas particulier de la réparation automobile. Le stéréotype «uses» précise que la relation est de type utilisation. La réparation automobile peut se décomposer, entre autres, en divers autres cas d’utilisation que sont, réparer la carrosserie, vérifier l’allumage, faire la vidange, ... Organiser paiement 05/04/ :21

Exprimer le service rendu
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 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 Pour la description du service rendu par le système, on peut se placer à deux niveaux de détail. Un niveau général où l'on décrit les besoins fondamentaux, et un niveau plus détaillé permettant de décrire les besoins opérationnels Les besoins fondamentaux peuvent être associés à un use-case de haut-niveau qui pourra être attaché à un diagramme de collaboration grossier permettant d’isoler les premiers concepts. Les besoins opérationnels peuvent eux-aussi être exprimés à partir de use-cases. Le use-case de haut niveau utilisera ces use-case plus détaillés pour préciser son comportement. Les use-case correspondant aux besoins opérationnels pourront être décrits à partir de scénarios ou de diagrammes de collaboration mettant en jeu des classes, opérations, ... 05/04/ :21 6

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

Utiles pour l’établissement de scénarios
Modélisation d’exemples issus des use-cases Objet1 Objet2 Objet3 Domaine de l’application service1 service1() besoin1 service3 service3() Utilisateur 1 Utilisateur 2 service1() service4 besoin2 service2() service3() service3 scénario du use case «besoin 2» service4() service5() service5() service2 On organise concrètement la démarche par représentation des acteurs extérieurs au système et d'un ou plusieurs domaines applicatifs. Un lien très informel entre les uses-cases et les opérations des classes applicatives peut être exprimé sous forme d’une note purement textuelle précisant comment le besoin utilisateur se traduit en terme de service dans les classes d’interface. Le lien entre les uses-cases et les objets du diagramme structurel s’effectue par les digrammes d’interaction (diagramme de séquence et/ou diagramme de collaboration). Le scénario (ou diagramme de séquence) permet de montrer les objets du système et leurs interactions mis en séquence. Les interactions seront les services répondants aux besoins opérationnels des utilisateurs. Ce scénario montrera comment ces besoins sont réalisés à l’aide des objets du système. besoin3 service6() service1() service5 service6() besoin4 service2() 05/04/ :21

Notations UML pour classes et objets
Représentation d’une classe Représentation simplifiée Compte solde: Somme plancher: Somme créditer (Somme) débiter (Somme) Compte Nom de la classe Représentation des objets CL : Compte Compartiment des Attributs Les objets sont représentés par un rectangle, avec leur nom suivi de : puis le nom de leur classe, le tout souligné. Les objets, instances des classes, sont manipulés dans les «collaboration diagramm» Les classes d'objets, ou plus simplement classes, possèdent des attributs et des opérations. Les attributs peuvent avoir un type et une valeur par défaut. Les opérations peuvent avoir des paramètres, typés ou non, et une valeur de retour. Dans un souci de clarté des diagrammes, on peut considérer que telle ou telle information n'est pas importante à ce niveau de l'analyse et donc décider de ne pas la faire apparaître. Pour la même raison, les zones des attributs et des opérations sont optionnelles. Une ellipse à la fin d’une liste d’attributs ou d’opérations signifie qu’il existe d’autres éléments dans le modèle, mais qu’ils dépendent de critères de sélection qui ne les font pas apparaître. Nom de l’objet Compartiment des Opérations 05/04/ :21

Constituants d’une classe
Concept représenté (nom) Classes héritées (concepts précisés) Relations avec autres classes Attributs (classe, nom, visibilité) Opérations (paramètres) Contraintes, invariants Généricité (classes paramétrées) Stéréotypes Les moyens que nous offrent le modèle objet pour décrire un concept sont : son nom (commun), les concepts précisés (généralisation), les liens avec d’autres concepts (relations), les propriétés du concept (attributs et opérations), son prototype. Le prototype d’un concept est l’image par défaut que l’on visualise par celui-ci (par exemple une table avec un plateau et 4 pieds). 05/04/ :21

Représentation des attributs
Caractérisation des attributs Compte solde: Somme plancher: Somme créditer (Somme) débiter (Somme) ATTRIBUTS Type de l'attribut Les attributs possèdent : un nom, un type (dépendant du langage d’implémentation choisi pour exprimer le type), éventuellement une valeur par défaut. Les attributs peuvent être des types simples (entiers, booléens, string, ...) ou des classes. Il y a équivalence sémantique entre attribut et relation de composition sur la classe de l’attribut. Nom de l'attribut 05/04/ :21

Attributs dérivés 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 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é 05/04/ :21

Représentation des opérations
Vues graphiques Compte solde: Somme plancher: Somme créditer (montant: Somme) débiter (montant: Somme) Nom de l’opération Dans le modèle structurel, la vue graphique présente : le nom des opérations, le nom des paramètres, la classe d'appartenance des paramètres (dépendante du langage choisi pour exprimé le type), optionnellement la valeur par défaut des paramètres, éventuellement le type de retour (dépendant du langage choisi pour exprimé le type) Les modes de passage (in, out, inout) des paramètres sont prévus par UML, mais ils ne font l’objet d’aucun formalisme graphique. Cependant il est conseillé de les définir pour chaque paramètre (par exemple à l’aide d’une «property»). Nom de paramètre Classe du paramètre 05/04/ :21

Représentation des invariants
Des contraintes peuvent être ajoutées aux éléments du modèle UML notation entre { } 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) Les attributs, opérations, relations et généralisations ne suffisent pas à définir avec précision l’ensemble des instances possibles. On appelle invariant d’une classe l’ensemble des conditions et des propositions, appelées contraintes en UML, qui doivent être vérifiées durant la vie d’une instance. Les conséquences du non respect de ces contraintes sortent du cadre d’UML . 05/04/ :21

Représentation des pré/post conditions
Préconditions {«precondition» expression booléenne OCL} Abrégé en: {pre: expression booléenne OCL} Postconditions {«postcondition» expression booléenne OCL} Abrégé en: {post: expression booléenne OCL} Operateur « valeur précédente » (idem old Eiffel): expression 05/04/ :21

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” 05/04/ :21

Relation entre classes
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 Une contrainte : Une relation est un lien stable entre deux objets Les relations entre classes permettent d’exprimer les liens stables entre les objets de ces classes. Elles permettent de préciser la définition des classes au même titre que les attributs. 05/04/ :21

Relation entre classes
Notation Vue ensembliste = Graphe de la relation Personne Voiture propriétaire propriété possession 1 * Personne Voiture L’relation entre classes correspond purement et simplement à l'relation entre ensembles. On retrouve, selon les cardinalités, les fonctions d’ injection, surjection et bijection. Possession Une association met en correspondance des éléments d’ensembles 05/04/ :21

Représentation des relations
Relation, direction, rôle, cardinalité direction de relation Rôle Nom de relation transporte passager Voiture Personne moyen_de_transport * Les relations UML sont définies par : le nom de l'relation, une direction : qui indique dans quel sens lire l’relation (elle n’a aucune sémantique et peut être omise) deux rôles (terminaisons de l’relation), deux cardinalités, une orientation : qui permet, en UML, la navigation dans les classes destinatrices de la flèche (si elle est omise aucune navigation n’est possible). Rôle Cardinalité précisée 05/04/ :21

Cardinalité d'une relation
1 Classe Exactement une * Classe Plusieurs (0 à n) 0,1 Classe Optionnelle (0 ou 1) 1,2,4 Classe Cardinalité spécifiée La cardinalité joue un rôle essentiel dans la sémantique de l'relation. La sémantique de l'relation change totalement si la cardinalité évolue. 1-10 Classe Intervalle 05/04/ :21

Cas particuliers de relations
Relations réflexives encadre chef 1 Personne sous-fifre 1..* Dans ce cas, les rôles sont très importants pour préciser la signification de l'relation. Dans l'exemple, un HUMAIN peut être à la fois Parent et Enfant. Une relation réflexive n’est pas obligatoirement orientée dans les deux sens. Une relation réflexive lie des objets de même classe 05/04/ :21

Composition et Agrégation
Cas particuliers de relations : Notion de tout et parties 1 Voiture Personne * passager moyen_de_transport transporte 1 1 Composition roulement > Roue 4,6 Une relation de type agrégation a pour objectif d’exprimer qu’un ensemble d’objets fait partie intégrante d’un autre objet. Une agrégation renforce ainsi la sémantique de la notion d’relation. Les agrégations peuvent êtres de 2 types : simple ou de composition l’agrégation exprime une composition faible, alors que la composition exprime une composition forte. Composition : la destruction d’un dossier entraîne la destruction de tous les documents contenus dans le dossier, de même la destruction d’une ville déclenche la destruction de tous les immeubles de la ville. Agrégation : même si une équipe de basket est dissoute, les joueurs de cette équipe sont toujours licenciés auprès de la fédération et existent en tant que tels. Il ne s’agit donc pas d’une composition. structure > 1 Agrégation Chassis 05/04/ :21

Autre vues de la composition/agrégation
Différentes formes suggérant l’inclusion Voiture roulement[4-6]: Roue structure: Chassis Voiture roulement 4-6 Roue structure 1 Chassis L’objet composite ne peut vivre sans ses composants. Les objets composants doivent être créés avant l’objet composite. La destruction de l’objet composite entraîne la destruction des composants. Les objets composants ne sont pas partagés. 05/04/ :21

Relations n-aires Relations entre plus de 2 classes (à éviter si possible) Enseignement * 1..* PROFESSEUR MATIERE Enseignant Enseignée Destinataire 1..* CLASSE 1..* Enseignant Enseignée Destinataire 1 PROFESSEUR MATIERE Enseignement CLASSE 0..* Toute relation N-aire peut être transformée en relation binaire, par application de règles systématiques illustrées ici. 05/04/ :21

Relations attribuées L'attribut porte sur le lien épreuve candidat
n..k Etudiant Matière objet_épreuve Note Dans cet exemple, l'attribut "Note" ne peut pas porter sur "Etudiant", car il dépend de la matière. A l'inverse, il ne peut pas porter sur "Matière", car il dépend de l'étudiant. Il porte effectivement sur le couple Etudiant/Matière. 05/04/ :21

Qualifieurs de relations
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. 0..* 0..* Fichier Fichier Répertoire Répertoire Nom du fichier Un qualifieur est matérialisé par un petit rectangle. Il est attaché non à la source mais à la fin de l’relation. Dans l’exemple la clef de recherche des fichiers dans le répertoire se fait sur la base du nom du fichier. Nom du fichier Relation non qualifiée Relation qualifiée Un répertoire + un nom de fichier identifient de façon unique un fichier 05/04/ :21

Représentation de la généralisation (héritage)
Héritage simple et multiple Héritage simple Héritage multiple AEROPLANE AEROPLANE VEHICULE_DE_TRANSPORT La généralisation peut-être simple ou multiple, la généralisation simple signifie qu'une classe hérite d'une seule super-classe alors que dans la généralisation multiple une classe peut hériter de plusieurs super-classes (au moins deux). AVION AVION 05/04/ :21

Interfaces et « lollipop »
MOBILE MOBILE Raffinement AVION AVION 05/04/ :21

Héritage des relations
Les relations sont héritées par les sous classes : VEHICULE motorisation MOTEUR 1..2 VOITURE CAMION lien logique REPERTOIRE FICHIER 1..* * La factorisation apportée sur la généralisation apparaît graphiquement pour les relations. Imaginons le nombre de relations qui devraient être représentées sans généralisation. Les Voitures et les Camions ont tous un ou deux moteurs. Un répertoire peut contenir des drivers, des fichiers sources ou des fichiers binaires. DRIVER FICHIER_TEXTE FICHIER_BINAIRE 05/04/ :21

Représentation de classes abstraites
Classes sans instances immédiates Forme {abstract} Carre Cercle Les carrés et les cercles ont toutes les propriétés des objets graphiques, cependant une forme graphique est obligatoirement un carré ou un cercle. Le mot clef abstract entre accolades indique graphiquement qu’une classe est abstraite. Une instance de «Forme» est obligatoirement une instance de la classe Carre ou de la classe Cercle 05/04/ :21

Représentation des opérations abstraites
Opération sans corps d’une classe abstraite Forme {abstract} calculer_surface () {abstract} Carre Cercle Le calcul de la surface d’une forme graphique nécessite de connaître sa nature exacte car la formule de calcul va dépendre de cette nature (L2 pour un carré, PxR2 pour un cercle). Cependant on sait calculer la surface de toute forme graphique. Le mot clef abstract entre accolades indique graphiquement qu’une opération est abstraite. calculer_surface() calculer_surface() 05/04/ :21

Visibilité Différentes visibilités des membres d'une classe public = +
usager Interface protégé = # héritier privé = - Trois visibilités sont disponibles pour les attributs et opérations d'une classe (pas sur les relations) : Public : accessible pour tout utilisateur d’une classe, y compris la classe elle-même. Protégé : accessible seulement par la classe elle-même, et par ses héritiers. Privé : accessible seulement par la classe elle-même. Les visibilités sont fondamentales en phase de conception technique. implémenteur corps 05/04/ :21

Visibilité Classe Représentation Pas de sens en analyse... +a1 : T1
#m1 (p1,P2,p3) +m2 (p1,P2,p3) 05/04/ :21

Classes paramétrées (Généricité)
Classe générique T , Entier : Integer Tableau element : T taille : Entier paramètres génériques <<bind>> <Point, 3> Tableau Les intervalles sur les cardinalités exprime le domaine des valeurs admises pour une relation. Il est préférable qu’il soient ordonnés.1..4,7,10 est préférable à 7,1..4,10. La contrainte {or} sur les relations exprime qu’une seule des deux relations sera instanciée sur l’objet Compte en effet un compte est soit celui d’une Societe soit celui d’un particulier. Les templates ou classes génériques expriment leurs paramètres formles non bornés à travers un rectangle pointillé situé en haut et à gauche de la classe. paramètres effectifs Classe effective 05/04/ :21

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

Les stéréotypes 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) 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 ... UML définit des stéréotypes de base sur les éléments de modélisation tels que : «constructor» ou «destructor» qui permettent de «typer» certaines opérations particulières. «utility» pour préciser qu’une classe est une classe utilitaire d’un package. «event» pour préciser qu’une classe est de type événement. «actor» pour préciser q’une classe est de type acteur. «extends» ou «uses» pour préciserle type de relations entre uses-cases «friends» ou «instanciates» pour préciser les liens d’utilisation entre classes «local», «global», «transient» ... pour qualifier des objets ... Les stéréotypes peuvent être hiérarchiques. La hiérarchie sera celle des classes du méta modèles sur lesquelles, ils se basent. 05/04/ :21

Notations pour les stéréotypes
«persistent» CLIENT «persistent» CLIENT nom : string adresse : string nom : string adresse : string CLIENT CLIENT nom : string adresse : string 05/04/ :21

Les notes 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 employé employeur chef ENTREPRISE PERSONNE * La notation utilisée pour les notes est un rectangle corné contenant du texte. 0..1 0..1 {PERSONNE.employeur = PERSONNE.chef.employeur} 05/04/ :21

Conseils pratiques Réfléchir au problème avant de commencer
Soigner le nommage, insister sur le nommage des relations et des rôles 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 05/04/ :21

Conseils pratiques (suite)
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 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) 05/04/ :21

Notion de package É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 Un package regroupe des classes et les encapsule au même titre que l'on encapsule des opérations et des attributs dans une classe. Chaque classe appartient à un et un seul package. On peut découper le package en deux parties : une interface contenant les packages et classes accessibles depuis les packages utilisateurs ou composés, correspondant à une visibilité publique, et une partie corps contenant les packages et classes seulement accessibles depuis le package les définissant ou les référençant, correspondant à une visibilité pirvée. Aucun formalisme graphique n’est proposé pour différencier les éléménts par rapport à leur visibilité. On peut cependant exprimer cette visibilité à l’aide des «properties», mot clef entre accolades : {public} ou {private}. 05/04/ :21

Représentation d’un package
Vue graphique externe Vue graphique externe et interne P1 P1 P2 P3 C1 C2 05/04/ :21

Partitionnement d’une application
Définition de vues partielles d'une application SYNTHÈSE EN PACKAGES ENSEMBLE DES CLASSES DE L'APPLICATION Chaque package constitue une vue restreinte de l'application finale, obtenue par la mise en œuvre des mécanismes de synthèse UML. Chacune des vues restreintes peut posséder ses propres définitions ou s'appuyer sur celles des autres. Cette décomposition, plus souple qu'une décomposition hiérarchique, permet toujours de procurer un accès direct entre classes lorsque le besoin existe. N.B.: une classe appartient à un et un seul package 05/04/ :21

Visibilité dans un package
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 Représentation graphique {public } Classe {private } Package::Classe Les classes représentées dans le contexte d’un package ont suivant leur nature une représentation graphique différente : la représentation des classes d’interface , la représentation des classes de corps , la représentation des classes externes comprend le nom du package d’appartenance. CLASSE D'INTERFACE CLASSE DE CORPS CLASSE EXTERNE 05/04/ :21

Utilisation entre packages
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 Représentation graphique La déclaration de l’utilisation d’un package par un autre se fait graphiquement par une flèche issue du package utilisateur en direction du package utilisé. P2 P1 Vue externe du package P1 05/04/ :21

Utilisation entre packages
Exemple (vue externe du package livraisons) LIVRAISONS LIVREURS VEHICULES Pour sa définition, le package Livraisons utilise les packages Livreurs, Vehicules et Colis. COLIS 05/04/ :21

Héritage entre packages
Exemples JeuPlateau JeuDame JeuEchec Windowing System Motif MicrosoftWindows Il peut advenir qu’il y ait héritage entre packages. Dans ce cas, nous dirons que le domaine représenté par le package hérité est un cas particulier de celui représenté par le package parent. 05/04/ :21

Utilité des packages 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 Un package permet de fournir le contexte de définition d'une classe. En effet, les classes sophistiquées (autres que string, Boolean) s'appuient sur d'autres classes pour leur définition et ne peuvent être exploitées en dehors du contexte de leur package. De ce fait, un package définit, plutôt qu'une classe, une unité de réutilisation. Nous verrons également que les packages sont exploités pour la production de logiciel, car ils constituent un regroupement ayant un lien direct avec la production de code final (librairie, stockage de sources, "Makefiles", etc…). Du fait qu'une classe est fréquemment liée à d'autres classes, l'unité de développement d'une personne n'est pas la classe, trop petite et trop dépendante, mais bien plutôt le package. 05/04/ :21

Structuration par packages (vs) décomposition hiérarchique
Pour les grands systèmes, il est nécessaire de disposer d’une unité de structuration : À un niveau supérieur, Plus souple que : La composition de classe Le référençage de packages La représentation externe des dépendances entre packages ne fournit pas une vision globale hiérarchique de l’application à développer; il devient nécessaire de structurer les packages par des unités de structuration d’un niveau supérieur. Cette unité de regroupement hiérarchique est le package lui-même en exploitant sa capacité de décomposition en packages. Un système entier peut ainsi être vu comme un seul package de très haut niveau qui sera décomposé en sous-domaines suivant les grands domaines traités par l’application. => domaines de structuration : Packages décomposables en packages 05/04/ :21

Exemple : Package entreprise
Exemple de composition ENTREPRISE COMMERCIAL COMPTABILITÉ Le package ENTREPRISE référence trois packages qui correspondent chacun à un département de l’application : département COMPTABILITÉ département COMMERCIAL département LIVRAISON Le package COMPTABILITÉ utilise le fichier clientèle du package COMMERCIAL. Les packages COMMERCIAL et LIVRAISON utilisent le fichier PERSONNEL du package COMPTABILITÉ. LIVRAISON 05/04/ :21

Ensemble des packages terminaux de l’application Véhicules Livraisons Facturation Livreurs Clientèles Bilan Colis L’application est découpée en plusieurs packages, l’ensemble de ces packages forme une partition de l’application. Commerciaux Personnel Tenue Comptes 05/04/ :21

Composition des packages en sous-packages ENTREPRISE COMPTABILITÉ LIVRAISONS Facturation Bilan Livraisons Véhicules Colis Tenue Comptes Personnel Livreurs Un package peut être référencé (utilisé) par plusieurs packages différents. Le package Personnel est utilisé à la fois par le sous-package Livreurs et le sous-package Commerciaux. Bien que déconseillées, les utilisations mutuelles entre packages sont tolérées COMMERCIAL Clientèles Commerciaux 05/04/ :21

Aspects dynamiques du système
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 Il faut maintenant décrire comment le système évolue dans le temps Les modèles statiques et opératoire ne montrent pas la décomposition des fonctionnalités importantes d’une application en opérations des classes. A partir de ces modèles, il est impossible de tracer les messages échangés par les objets de l’application suite à une sollicitation externe. Il est important de recomposer les processus principaux d’une application à partir des opérations pour : valider la couverture du besoin par le modèle statique, donner une vue fonctionnelle synthétique de l’application future. 05/04/ :21

Diagrammes de séquences (scénarios)
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 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) Suivant son état une application ne va pas réagir de la même façon à une solliciation externe : les objets sollicités ne sont pas obligatoirement les mêmes, les messages échangés sont modifiés, ... L’état d’une application à un instant donné est défini par la réunion de l’état de chacun de ses objets. Le nombre d’états possibles d’une application est donc quasiment infini. Il est impossible matériellement de construire exhaustivement tous les scénarios décrivant les inter-actions possibles entre les objets de l’application suite à une sollicitation externe de l’application. Un scénario a comme principale qualité son exemplarité. 05/04/ :21

Syntaxe graphique Objets et messages Temps
Objets = Instances de classes Nom Objet:NomClasse Nom Objet1:NomClasse1 nom message (paramètres) Temps Message nom message émis par Nom Objet vers Nom Objet1 Les objets sont représentés par des barres verticales au dessus desquelles figure l’objet et sa classe d’appartenance (même formalisme que dans les diagrammes d’objets). Le nom de la classe ou de l’objet peut être omis. Les messages entre objets sont représentés par des flêches partant d’un objet et arrivant à un autre objet. 05/04/ :21

Ligne de vie et activation
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 L’activation est la période durant laquelle l’objet exécute une action lui-même ou via une autre procédure Un objet qui existe préalablement à l’activation du premier message a une ligne de vie qui commence au sommet du diagramme. La boite représentant l’objet doit se situer au dessus de la flèche représentant du premier message. Un objet qui existe encore après l’activation du dernier message a une ligne de vie qui se poursuit jusqu’après la flèche représentant le dernier message. 05/04/ :21

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

Messages Communication entre objets Cas particuliers Des paramètres
Un retour Cas particuliers Les messages entraînant la construction d’un objet La récursion Les destructions d’objets Si un objet est créé à l’intérieur du diagramme, le message entrainant sa création doit arriver sur la boîte représentant l’objet. Cet objet n’a pas de ligne de vie préalable à cet envoi de meesage. Si un objet est détruit au cours du déroulement du scénario, la fin de l’activation de cet objet se double de la présence d’une croix spécifiant sa destruction. 05/04/ :21

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

Aspects asynchrones et temps réel
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 Objet1: :Nom classe2 Nom Objet1: :Nom classe2 demande d a demande {b-a< 5 sec.} La chronologie des envois de messages est indiquée par le positionnement de haut en bas des flêches. Le message initiateur doit se trouver en haut du graphique. On peut mentionner des contraintes temporelles sur : la durée séparant l’échange de deux messages par deux objets (une demande et une réponse par exemple) la durée séparant l’émission d’un message de sa réception. Une flêche horizontale est synonyme d’un envoi de message instantané alors qu’une flêche inclinée indique le temps entre l’émission du message et a reception par l’objet receveur ne peut être considéré comme nul. L’instant auquel est émis le message est noté par une lettre alorsque l’instant de réception est noté avec la même lettre et le signe «prime» :d et d’. réponse d’ b {d’-d< 1 sec.} 05/04/ :21

Représentation de conditionnelles
objet2:Classe2 Branchement conditionnel op ( ) objet1:Classe1 [x<0] m1 ( x ) [x>0] m2 ( x ) Branchement conditionnel Aucun formalisme n’est proposé pour les boucles. Un ensemble d’opérations peuvent être «marquées» comme faisant partie d’une itération, c’est à dire qu’ils peuvent survenir plusieur fois. La condition de continuation de l’itération peut être spécifiée au bas de l’itération. 05/04/ :21

Diagrammes de collaboration
Les scénarios et diagrammes de collaboration: Montrent des exemples de coopération des objets dans la réalisation de processus de l’application Les scénarios : Illustrent la dynamique d’enchaînement des traitements d’une application en introduisant la dimension temporelle 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 Les diagrammes de collaboration ne montrent pas la dimension temporelle, ils ne montrent que le séquencement. La numérotation des séquences devient obligatoire. Les diagrammes de collaboration montrent les relations entres objets (comme les relations entre classes du modèle strructurel). Ils sont un modèle structurel, avec ce qu’il comporte d’attributs, opérations et relations, auquels on ajoute les échanges entre objets. la partie structure est appelée «contexte» la partie séquence est appelée «interaction» Le diagramme de collaboration est un prototype, il ne fixe pas de valeurs aux attributs, paramètres et au contenu des relations. C’est à «l’exécution» d’un diagramme de colaboration que seront assignées des valeurs aux objets. 05/04/ :21

Utilisation des diagrammes de collaboration
Ils peuvent être attachés à : Une classe Une opération Un use-case Ils s’appliquent En spécification En conception (illustration de design patterns) Suivant la phase à laquelle ils s’appliquent, la granularité du diagramme sera plus ou moins fine. En spécification, ils seront le moyen «d’implémenter» un use-case. En conception, ils pourront être utilisés pour décrire le fonctionnement interne d’une opération. Un diagramme de collaboration peut être redéfini pour montrer la collaboration des objets à un niveau de granularité plus fin. 05/04/ :21

Eléments constitutifs
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 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 Tout comme pour un scénario, et c’est encore plus vrai pour un diagramme de séquence, il sera bon de limiter le nombre d’objets, de relations et d’opérations mises en jeu dans un seul diagramme. Il sera préférable de décomposer en plusieurs diagrammes. La richesse et la complexité des notations intervenant dans ce type de diagrammes amène très vite à la confusion ou à la perte des informations fondamentales. 05/04/ :21

Représentation d’une collaboration (niveau instance)
Pierre Marie père mère 1: cashRequest($25) 2: cashReceived($25) Fred 05/04/ :21

Equivalent au diagramme de séquence:
Fred Marie cashRequest($25) cashReceived($25) 05/04/ :21

Syntaxe graphique Les messages Le séquencement séquence imbriquée
Opérations Réception d’événements Le séquencement Les séquences consécutives Les séquences imbriquées séquence imbriquée origine:Point message initiateur 1.1: position ( ) 4 :Carré afficher ( ) :Segment La numérotation des séquences est pratiquement obligatoire pour donner l’ordre d’envoi des messages dès que le diagramme s’enrichit. Une séquence s’exprime par un nombre. Ce nombre s’incrémente au gré de la progression dans le diagramme de collaboration. Une séquence imbriquée représente l’ensemble des opérations mise en jeu pour réaliser une opération de plus haut niveau. En spécification, un point de vue macroscopique suffira, on se contentera d’un seul niveau. En conception, si on raffine ou redéfinit le diagramme, on pourra enrichir la compréhension d’une opération en explicitant comment elle est réalisée, alors des sous-niveaux pourront être nécessaires. le symbolisme des messages asynchrones des scénarios est repris dans les diagrammes de collaboration. 1 *(i=1..4):afficher ( ) numéro de séquence 1.2: position ( ) boucle destination:Point opération 05/04/ :21

Questions auxquelles répondent les collaborations
Quel est l’objectif ? Quels sont les objets ? Quelles sont leurs responsabilités ? Comment sont-ils interconnectés ? Comment interragissent-ils ? 05/04/ :21

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." 05/04/ :21

Collaboration de Niveau Spécification un exemple simple
/ Père / Mère père mère 1: cashRequest($25) 2: cashReceived($25) / Enfant 05/04/ :21

Les diagrammes d’états
Attachés à une classe Généralisation des scénarios Description systématique des réactions d'un objet aux changements de son environnement 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) Réseau d’états et de transitions Automates étendus Essentiellement Diagrammes de Harel (idem OMT) La notation et la sémantique des diagrammes d’états sont empruntées aux «states charts» de David Harel. De manière général, un stimulus est un événement. 05/04/ :21

Syntaxe graphique: diagramme d’états
condition de garde action événement émis événement reçu Evt1 [cond] / m() ^Evt2 E2 E1 état transition Syntaxe : EvénementReçu (param : type, ...) [condition de garde] / Action ^EvénementsEmis La manière dont les objets réagissent aux événements est déterminée par le diagramme d’états. On spécifie que dans certains états, l'occurrence de tel événement provoque telle transition. La méthode m() est déclenchée suite à la réception de l’événement Evt1 par un objet de la classe C dans l’état E1 L’événement Evt2 est alors émis par l’objet après exécution de l’action.. 05/04/ :21

Notion d’événements Stimulis auxquels réagissent les objets
Occurrence déclenchant une transition d’état 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»). Exemples d’événements sur la classe MISSILE: [cible accrochée] entraîne le passage dans l’état «prêt à tirer» tir entraîne le passage dans l’état «tir en cours» 60s est le temps au delà duquel la batterie doit se remettre en charge, entraîne le passage dans l’état «en recharge» D’autres exemples d’événements : appuyer sur le bouton gauche de la souris, autorisation d’atterrissage, départ du vol 714 pour Sydney ... 05/04/ :21

Les événements Les événements sont considérés comme des objets ... ...
«signal» IO_EVENT time «signal» USER_INPUT device «signal» NETWORK_EVENT Un événement est un objet. Une classe événement a pour seule particularité d’être stéréotypée «event». De ce fait, les événements peuvent être porteurs de données (attributs, et de services sophistiqués : opérations). Un événement peut être émis ou reçu avec des paramètres. Ces paramètres seront des attributs de cet événement afin de rendre cohérent le modèle dynamique et le modèle structurel. ... «signal» MOUSE_EV «signal» KEYBD_EV ... ... location character 05/04/ :21

Typologie d’événements
Réalisation d’une condition arbitraire transcrit par une condition de garde sur la transition Réception d’un signal issu d’un autre objet transcrit en un événement déclenchant sur la transition Réception d’un appel d’opération par un objet transcrit comme un événement déclenchant sur la transition Période de temps écoulée transcrit comme une expression du temps sur la transition Le diagramme d’états permet de décrire les réactions systématiques d'un objet lorsque son environnement change. Une transition décrit une activation systématique, dans certains états, sous certaines conditions, ou l'occurrence de certains appels ou signaux. Un événement à comme portée le package dans lequel il est défini et peut être utilisé dans les diagrammes d’états des classes ayant la visibilité sur ce package. Un événement n’est pas local à une classe. 05/04/ :21

délai_mise_en_veille / passage_en_mode_veille
Notion d ’action Action : opération instantanée (conceptuellement) et atomique (ne peut être interrompue) Déclenchée par un événement Traitement associé à la transition Ou à l ’entrée dans un état ou à la sortie de cet état action Les actions permettent de décrire l’aspect comportemental d’un objet en réponse aux événements. Exemples d’actions : l’événement «combiné raccroché» entraîne le déclenchement de l’action «déconnecter ligne» l’événement «touche valide et numéro complet» entraîne le déclenchement de l’action «connecter ligne» l’événement «appui touche main libre» entraîne le déclenchement de l’action «mise en marche haut parleur» ... User_input / mise_sous_tension Veille Allumé délai_mise_en_veille / passage_en_mode_veille action 05/04/ :21

Notion d’états 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 Peut avoir des variables internes attributs de la classe supportant ce diagramme d’états Dans un soucis de cohérence avec le modèle structurel, les variables internes des états seront en fait des attributs de la classe suportant ce diagramme d’états. 05/04/ :21

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

Notion d ’activité dans un état
Activité : opération se déroulant continuement tant qu ’on est dans l ’état associé do/ action Une activité peut être interrompue par un événement. Téléphone N° invalide Invalide do / passer message Téléphone raccroché Le mot clef spécifiant l’opération à réaliser est do (A faire) suivi de / et de l’activité. Les activités peuvent être de natures différentes : continue : la sonnerie du téléphone persiste dans l’état «en sonnerie» tant que le destinataire ne décroche pas. L’activité lié à cet état est donc «sonner» séquentielle : lorsque la personne fait un faux numéro, l’activité liée à l’état «invalide» est «envoyer le message : il n’y a pas d’abonné au numéro que vous avez demandé». Une activité séquentielle se termine d’elle même après exécution. Plusieurs activités peuvent être liées à un même état. Par exemple, on peut imaginer dans le cas des activités liées à l’état «invalide» d’ajouter l’activité «jouer tonalité occupée» qui sera exécutée après l’envoi du message. Elle ne sera interrompue que par un événement «combiné raccroché». Les activités peuvent utiliser les attributs et/ou relations liés à l’objet détenteur de l’automate de déclenchement. activité 05/04/ :21

Exemple de diagramme d'états
un téléphone : Actif Timeout do/ timeout tone Compose numéro (n) 15 sec 15 sec Tonalité do/ joue tonalité Compose numéro (n) En composition décroche combiné Dernier numéro Invalide do/ dit message Compose numéro (n) [n.isInvalid] Repos Etablissement occupé connecté Occupé do/ tonalité occupée Appelé raccroche Occupé On notera l’événement particulier «15 sec» qui est une période de temps qui déclenche automatiquement la transition quand le temps est écoulé. En effet au bout du quinzaine de secondes, si l’opérateur n’a pas composé de numéro, le téléphone envoie le son «occupé». On notera aussi l’événement «compose numéro» porteur d’un paramètre qui est le code de la touche tapée par l’opérateur. La classe représentative de cet événement aura un attribut qui spécifiera le code touche. Cet événement a aussi la particularité d’avoir une condition de garde qui exprime que tant que le numéro composé est incomplet (numéros tapés inférieurs à 10 chiffres) et que la touche tapée est valide, l’appareil doit rester dans l’état «En composition». Cette condition est une expression booléenne pouvant impliquer des paramètres de l’événement (le code de la touche tapée) et/ou des attributs (le nomdre de chiffres composants un numéro de téléphone) ou relations de la classe supportant le diagramme d’états. Libre Dialogue Sonnerie do/ sonne Appelant raccroche/ déconnexion Réponse de l’appelé/ autorise parole 05/04/ :21

Émission d’événements
Automate d’états d’une télécommande double : TV + MAGNETOSCOPE Contrôle distant MAGNETOSCOPE contrôle TV contrôle MAGNETO TV bouton marche ^signal ON/OFF Les événements peuvent être émis vers : l’objet courant un autre objet un ensemble d’objets à la cantonnade suivant la syntaxe : ^objet_destinataire ‘.’ evenement_emis (paramètres ...) Si l’objet destinataire n’est pas précisé, c’est l’objet courant qui réceptionnera cet événement dans le même automate ou un autre. signal ON/OFF Télévision Arrêt Marche 05/04/ :21

Diagrammes d'états concurrents
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 Sous-états concurrents séparés par pointillés « swim lanes » 05/04/ :21

Exemple de concurrence
Préparation d'un avion Maintenance Remplissage Plein Réservoir plein préparation Avion prêt Approvisionnement Chargement nourriture Nourriture chargée Compartiment plein vérification OK Equipage Equipage absent Vérification avion Une autre manière de présenter aurait pu être de faire 3 diagrammes d’états indépendants émettant chacun un événement lors de la transition vers respectivement plein, nourriture chargée, vérification avion et de faire un autre automate à quatre état qui se déclencherait sur réception de chacun de ces événements jusqu’à arriver dans l’état «avion prêt» lorsque les 3 événements des autres diagrammes ont été reçus. Montée 05/04/ :21

Etat-transition (résumé)
Format : événement (arguments) [conditions] / action ^événements provoqués 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. Tir de la transition : Exécute certaines actions instantanément. Provoque d'autres événements ; globaux ou vers des objets cibles. 05/04/ :21

Les diagrammes d’activité
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 Attachés à une classe, une opération, ou un use-case (workflow) Par analogie avec les diagrammes d’états, l’achèvement d’une opération emet un pseudo-événement interne qui déclenche la transition. La différence fondamentale avec les diagrammes d’états est que les «états» représentent des opérations 05/04/ :21

Etat-action et décision
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 Modélisation d’une étape dans l'exécution d’un algorithme Notation : Décision = branchement sur plusieurs transitions obtenir un gobelet [coût<50] [coût>=50] 05/04/ :21

Exemple de diagramme d’activité
opération PréparerBoisson de la classe Personne [pas de café] [pas de soda] déterminer boisson [demande café] [demande soda] mettre le café dans le filtre ajouter de l’eau dans le réservoir obtenir un gobelet obtenir une canette de soda mettre le filtre dans la machine La fourche issue de l’opération «obtenir une boisson» précise que les opérations peuvent être exécutées dans n’importe quel ordre. Les fourches arrivant sur les opérations «infuser» et «verser café» expriment un point de synchronisation. Il faudra en effet attendre que le gobelet, que l’eau, le café et le filtre soient présent pour commencer à faire infuser le café. infuser verser café boire 05/04/ :21

Stéréotypes optionnels
Emission de signal Réception de signal 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 05/04/ :21

Liens modèles statiques/dynamiques
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 Les modèles dynamiques d'une classe sont transmis par héritage aux sous-classes 05/04/ :21

Diagrammes d’implantation
Diagrammes de composants Dépendances entre composants logiciels code source binaires, DLL exécutables Diagrammes de déploiement Configuration des composants Localisation sur les noeuds d’un réseau physique 05/04/ :21

Exemples de composants
Synonymes Dictionnaire Vérificateur Interfaces Planner Composants GUI 05/04/ :21

Exemple de déploiement
MachineServeur Dictionnaire MachineClient1 GUI Noeuds MachineClient2 Planner 05/04/ :21

Processus de développement avec UML
? 05/04/ :21

Unified Modeling Language

Présentations similaires

Présentation au sujet: "Unified Modeling Language"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Unified Modeling Language

Présentations similaires

Présentation au sujet: "Unified Modeling Language"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back