ENSGI 2 A MSI UML version 1 a

  • Slides: 22
Download presentation
ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 UML : Unified Modelling Language Historique : Références : Object Management Group http: //www. omg. org en France Pierre Alain Muller (U-Mulhouse) et Valtech Outils : Objecteering http: //www. objecteering. com/us/produits_pe. php Rational ROSE plus de 30 outils de modélisation et de CASE (Computer Aided Software Engineering) 1 Michel Tollenaere

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 UML : • modelling information systems • at conceptual level • at logical level 2 Michel Tollenaere

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 Creating the UML 1. 3 OMG Acceptance, Nov 1997 UML 1. 1 Final submission to OMG, Sep ‘ 97 public feedback First submission to OMG, Jan ´ 97 UML 1. 0 UML partners UML 0. 9 Web - June ´ 96 OOPSLA ´ 95 Other methods Unified Method 0. 8 Booch method OMT OOSE 3 Michel Tollenaere

Contributions to the UML ENSGI 2 A MSI - UML version 1. a du

Contributions to the UML ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 Harel Meyer Before and after conditions Statecharts Gamma, et al Frameworks and patterns, HP Fusion Booch Operation descriptions and message numbering Booch method Embley Rumbaugh Singleton classes and high-level view OMT Jacobson Wirfs-Brock OOSE Responsibilities Shlaer - Mellor Object lifecycles Odell Classification 4 Michel Tollenaere

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 Diagrammes UML • diagramme de classes • diagramme de cas d’utilisation • diagramme de séquence • diagramme de collaboration • diagramme d’objets • diagramme d’états-transitions • diagramme d’activités • diagramme de composants • diagramme de déploiement 5 Michel Tollenaere

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 Légende Système (VEGA 2) Cas d’utilisation une fonctionnalité attendue du système (VEGA 2) par les différents acteurs. Diagramme de Classes : acteur (intéragissant avec VEGA 2) message Diagramme de séquence Chaque cas d'utilisation apparaît comme un scénario, décrit par un ou plusieurs diagrammes de séquence. Un diagramme de séquences montre les interactions entre les acteurs et le système selon un point de vue temporel pour accomplir une fonctionnalité attendue du système (un cas d ’utilisation). C’est une ensemble de messages échangés entre les acteurs et le système, ordonnés chronologiquement. 6 Michel Tollenaere

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 Diagramme de cas d’utilisation Représente les fonctions du système de point de vue de l ’utilisateur. relation Acteur Cas d ’utilisation Eléments du diagramme : • acteur : un rôle joué par une personne, un service, etc. qui interagit avec le système étudié • cas d’utilisation : manière spécifique d ’utiliser un système. Image d’une fonctionnalité attendue, déclenchée en réponse à la stimulation d’un acteur • relations entre cas d’utilisations et acteurs 7 Michel Tollenaere

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 Diagramme de cas d’utilisation Relations entre cas d ’utilisations Trois types de relations : • relation de communication : entre un acteur et un cas d’utilisation. Exprime l’échange d’informations entre l’acteur et le système. déclenche client virement • relation d’utilisation : entre deux cas d ’utilisation. Exprime que le cas d’utilisation source comprend également le comportement décrit par le cas d’utilisation destinataire (utile pour la factorisation de cas). « use » virement identification • relation d’extension : entre deux cas d’utilisation. Exprime que le cas d’utilisation source étend le comportement du cas d’utilisation cible (utile pour la spécialisation de cas). « extend » Virement par Internet virement 8 Michel Tollenaere

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 Diagramme de Séquences Un cas d’utilisation apparaît comme un scénario, décrit par un diagramme de séquences. Diagramme de séquence : exprime la séquence des interactions entre objets du système selon un point de vue temporel, pour réaliser le cas d’utilisation. Objet 1 Objet 2 1 : [condition A] message 2 : message synchrone 3 : message de création Evénement / Communication entre objets 5 : message Objet 3 4 : message 6 : [condition B] message Période d’activité de l’objet 7 : message réflexif 9 : message asynchrone 8 : message de destruction 9 Michel Tollenaere

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 Diagramme de Séquences Cas particuliers • message synchrone: l’émetteur est bloqué et attend que l’appelé ait fini de traiter le message (message 1) message asynchrone: l’émetteur n’est pas bloqué et peut continuer son exécution (message 6) • Un message réflexif indique souvent un point d ’entrée dans une activité de plus bas niveau qui s ’exerce entre objets contenus par l ’objet composite (message 7) • Un message dont les délais de transmission sont non négligeables est matérialisé par une flèche oblique (message 4) • Messages conditionnés : flèches prenant leur origine au même instant avec des conditions mutuellement exclusives (messages 1 et 6) • Possibilité de compléments d ’informations sous forme de texte libre ou de pseudo-code à côté du diagramme • Période d ’activité : temps pendant lequel un objet effectue une action, directement ou par l ’intermédiaire d ’un autre objet sous-traitant • Des contraintes temporelles peuvent être exprimées en graduant la ligne de vie (pour dire par exemple: « 10 secondes plus tard » ) 10 Michel Tollenaere

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 Diagramme de Séquences Exemple Ligne téléphonique Appelant Appelé décroche tonalité numérotation indication de sonnerie décroche allô 11 Michel Tollenaere

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 Diagramme de Collaboration Comme les diagrammes de séquence : interactions entre objets du système avec un accent particulier sur la structure spatiale statique des objets (contexte des objets). Les messages sont numérotés pour indiquer l ’ordre des envois. Message: Simple, Asynchrone, Synchrone, , Minuté : ascenseur Objet 1 1 : message 1 : monter 2 : message : cabine 4 : message Objet 2 3 : fermer 5 : message : porte 3 : message Objet 3 2 : allumer : lumière 12 Michel Tollenaere

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 Diagramme de classes Structure statique d’un système, en termes de classes et de relations (3 types) entre ces classes. Motocyclette Couleur Nom de classe Attributs exemple : Opérations () Cylindrée Vitesse max Démarrer () Accélérer () Syntaxe: Freiner () • nom_attribut : type_attribut = valeur initiale • nom_opération (nom_argument : type_argument = valeur_par_défaut, …) : type_retourné Visibilité : trois niveaux de visibilité pour les attributs les opérations: • public (+) : élément visible à tous les clients de la classe • protégé ( #) : élément visible aux sous-classes de la classe • privé (-) : élément visible à la classe seule 13 Michel Tollenaere

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 Diagramme de classes Relations entre classes Agrégation : quand une classe fait partie d’une autre classe (agrégat - composant) Généralisation : factorisation des éléments communs d’un ensemble de classes dits sousclasses dans une classe plus générale dite super-classe. Elle signifie que la sous-classe est un ou est une sorte de la super-classe. Le lien inverse est appelé spécialisation classe 2 i classe 1 oc ass généralisation on ati spécialisation Association : toute relation structurelle entre classes, autre que l ’agrégation et la généralisation constructeur 1 1. . * véhicule 1 1. . * moteur classe 3 agrégation classe 4 voiture camion avion 14 Michel Tollenaere

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 Diagramme de classes Agrégation: Relations • Relation transitive : si voiture est composée de moteur et si moteur est composé de courroie alors voiture est composée de courroie • Relation non systémique: si voiture est composée de moteur, moteur ne peut pas être composé de voiture • Relation réflexive : une fonction peut être composée d ’autres fonctions Généralisation : • Relation non réflexive : une classe ne peut dériver d’elle-même • Relation non symétrique : si une voiture est une sorte de véhicule, alors le véhicule ne peut pas être une sorte de voiture • Relation transitive : si voiture est une sorte de véhicule terrestre qui elle même est une sorte de véhicule alors voiture est une sorte de véhicule Association : • Une classe a un rôle dans une association. constructeur 1 construire 1. . * véhicule construit par • Les rôles portent une information de multiplicité précisant le nombre d ’instances qui participent dans la relation. Les multiplicités les plus courantes sont : 1 / 0. . 1 / m. . n / * /0. . * / 1. . * 15 Michel Tollenaere

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 Diagramme d’Objets Structure statique d’un système, en termes d’objets et de liens entre ces objets. Un objet est une instance de classe et un lien est une instance de relation. Nom de l ’objet : Classe Attributs = valeurs Etienne : personne Personne âge : entier âge = 35 collaborateur patron * patron 1 Jan-Luc : personne âge = 25 Diagramme de classes Diagramme d ’objets 16 Michel Tollenaere

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 Diagramme d ’états-Transition Description des séquences possibles d’états et d ’actions par lesquelles un objet peut passer tout au long de sa vie. Ces séquences résultent de sa réaction à des événements discrets. Eléments du diagramme : • état : situation d’un objet à un moment donné • transition : connexion entre deux états, permettant le passage d’un état à l’autre • événement : occurrence d ’une situation donné dans le domaine du système qui déclenche la transition • garde : condition booléenne qui valide ou non le déclenchement d’une transition lors de l’occurrence d’un événement (cas de plusieurs transitions exclusives déclenchées par le même événement) • action : opération exécutée pendant que l’objet est dans un état donné ou lorsque une transition est déclenchée (correspondant à des opérations déclarées dans la classe de l’objet destinataire). Une action d’un état est dite activité quand l’opération associée a un temps d’exécution négligeable (do : nom_opération) Etat A …. état initial action do: opération Evénement [garde] / Action Etat B …. état final 17 Michel Tollenaere

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 Diagramme d ’états-Transition Exemple En activité do: travailler Perte d ’emploi Personne âge Plus de 60 ans 1. . * 0. . 1 Société Au chômage Diagramme de classes A la retraite Embauche Plus de 60 ans Diagramme d ’états-transitions Les personnes ne possèdent pas toutes un emploi et se trouvent, à un moment donné, dans un des états suivants : en activité, au chômage, à la retraite L’état d ’une personne donnée est déterminé selon son âge et la présence ou non d’un lien vers une société. 18 Michel Tollenaere

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 Diagramme d ’Activités on peut aussi utiliser IDEF 0 ou IDEF 3 Variante des diagrammes d’états-transition, organisé par rapport aux actions et destiné à représenter le comportement interne d’une opération ou d’un cas d ’utilisation. Mesurer température [trop froid] [trop chaud] Chauffer Refroidir « synchronisation » Arrêter chauffage Aérer 19 Michel Tollenaere

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 Diagrammes de composants et de déploiement Diagramme de composants : • représente l’architecture logicielle • décrit les spécifications des modules qui vont contenir le code des classes ainsi que le programme principal. L’identification des modules est réalisée pour chaque sous-système du système global. Diagramme de déploiement : • représente l’architecture matérielle • décrit la disposition physique des différents nœuds (processeurs) dans la composition d’un système et la répartition des programmes principales du diagramme des composants, sur ces processeurs. 20 Michel Tollenaere

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 Mécanismes UML : Paquetage • Regroupement d’éléments de modélisation. Une façon d’organiser les modèles de la même manière que les répertoires organisent les fichiers. Un paquetage contient divers diagrammes. • Un paquetage peut contenir d’autres paquetages, sans limite d ’emboîtement. • Un élément contenu par un paquetage peut apparaître dans un autre paquetage sous forme d ’élément importé. • Un seul type de relations entre paquetages : les dépendances (au moins un élément du paquetage client utilise les services offerts par les éléments du paquetage fournisseur. 21 Michel Tollenaere

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002

ENSGI 2 A MSI - UML version 1. a du 1 er Octobre 2002 Mécanismes UML : Stéréotype • Un mécanisme d’extensibilité d ’UML. • Il spécialise les éléments de modélisation d’UML, pour un métier donné : cas d’utilisation, lien, classe, …. • Il permet la classification des éléments de modélisation (méta-modélisation). • Chaque élément de modélisation d’UML a au plus un stéréotype, lorsque la sémantique de base est insuffisante. Exemple : dans le domaine de la gestion des données techniques, les liens de composition entre articles sont stéréotypés selon leur nature : « nomenclature BE » / « nomenclature BM » / etc. 22 Michel Tollenaere