U.M.L. - labs.ivoiretalents.com · ASSALE Adjé Louis UML 1 U.M.L. Généralités • UML (Unified...

ASSALE Adjé Louis UML 1

U.M.L.

Généralités

• UML (Unified Modeling Language) adopté par OMG

(Object Management Group) en 1997

• OMG définit le méta-modèle de UML

Syntaxe et interprétation en partie formalisées

• UML = Fusion de différentes méthodes objets

OOSE, OMT, BOOCH et autres

• Définition

Langage visuel dédié à la spécification, la construction et la documentation des artefacts d’un système logiciel

UML est un langage non une méthode


U.M.L.

Différents modèles UML

• Modèles descriptifs vs prescriptifs

Descriptifs : Décrire l’existant (domaine, métier)

Prescriptifs : Décrire le futur système à réaliser

• Modèles destinés à différents acteurs

Pour l’utilisateur : Décrire le quoi

Pour les concepteurs/développeurs : Décrire le comment

• Modèles statiques vs dynamiques

Statiques : Décrire les aspects structurels

Dynamiques : Décrire comportements et interactions

• Modèles sont décrits par des diagrammes (graphes)


U.M.L.

Diagrammes UML

• Dispose de 14 Diagrammes


U.M.L.

Diagrammes UML

• Version 2.2 dispose de 14 Diagrammes

• … et un langage pour exprimer les contraintes : OCL


U.M.L.

Concepts et notations générales

• Stéréotype et mot-clé

Définition d’utilisation particulière d’éléments de modélisation

Notation : <<NomStéréotype>> ou {NomMot-clé} ou icone

Nombreux stéréotypes ou mots-clés prédéfinis :

«interface», «invariant», «create», «actor», {abstract}, {bind}, {use}...

• Commentaires

Information en langue naturelle

Notation : o- - - - - - - - - - - - - - - - - -


U.M.L.


• Relations de dépendance :

lien de dépendance entre deux éléments de la modélisation

Notation : [source]- - - - - - - - - >[cible]

Modification source peut impliquer une modification cible

Nombreux stéréotypes prédéfinis : «bind», «realize», «use», «create», «call», ...

• Contraintes :

Relations entre éléments de modélisation

Propriétés qui doivent être vérifiées

Attention : les contraintes n’ont pas d’effet de bord


U.M.L.


• Contraintes :

Notation : o- - - - - - - -{ contrainte }

3 types de contraintes :

Contraintes prédéfinies : disjoint, ordered, xor, ...

Contraintes exprimées en langue naturelle Ex. : temps d’exécution inférieur à 10 ms

Contraintes exprimées avec OCL (Object ConstraintLanguage)Ex. : context Pile inv : self.nbElts >= 0

Stéréotypes : «invariant», «précondition», «postcondition»


U.M.L.


• Paquetages :

Découpage d’1 système en sous-systèmes ou paquetages

Découpage logique

Correspondant à des espaces de nommage homogène

Dépendance entre paquetage


U.M.L. : Modéliser la structure

Principe

• Point de vue statique du système

Décrire la structure du système en termes de :

Composants du système

Objets, Classes, Paquetages, Composants, ...

Relations entre ces composants

Spécialisation, Association, Dépendance, ...

Différents diagrammes statiques :

Diagramme d’objets

Diagramme de classes

Diagramme de paquetage

Diagramme de composants

Diagramme de déploiement



Structuration orientée objet

• Pourquoi une structuration orientée objet ?

Unicité et universalité du paradigme

Réduire le décalage entre monde réel et logiciel

Objets réels ) Objets conceptuels ) Objets logiciels

Réutilisabilité et évolutivité facilitées par différents mécanismes

Encapsulation, Modularité, Abstraction, Polymorphisme, Héritage

Faible couplage inter-objets / Forte cohésion intra-objet

Paradigme qui arrive à maturité

Bibliothèques de classes, Design patterns, UML, Méthodologies de développement (UP, Agile, XP, ...), ...

Environnements de développement intégrés (IDE)




• Qu’est-ce qu’un objet ?

Objet = Etat + Comportement + Identité

Etat d’un objet :

Ensemble de valeurs décrivant l’objet

Chaque valeur est associée à un attribut (propriété)

Les valeurs sont également des objets () liens entre objets)

Comportement d’un objet :

Ensemble d’opérations que l’objet peut effectuer

Chaque opération est déclenchée par l’envoi d’un message

Exécution d’une méthode




• Qu’est-ce qu’un objet ?

Identité d’un objet :

Permet de distinguer les objets indépendamment de leur état

2 objets différents peuvent avoir le même état

Attribuée implicitement à la création de l’objet

L’identité d’un objet ne peut être modifiée

Attention : identité ≠ nom de la variable qui référence l’objet




• Qu’est ce qu’une classe d’objets ?

Classe = regroupement d’objets similaires (appelés instances)

Toutes les instances d’une classe ont les mêmes attributs et opérations

Abstraction des caractéristiques non communes

Classes sans instance

Classes abstraites :

Certaines opérations peuvent être abstraites/virtuelles (non définies)

Interfaces :

Pas d’attribut et toutes les opérations sont abstraites/virtuelles





Relation de spécialisation/généralisation entre classes

Une classe A est une spécialisation d’une classe B si tout attribut/opération de B est également attribut/opération de A

Implémentation par héritage

Diagramme des objetsObjectif : Représenter les objets et leurs liens à un

instant donné

Utilisation : documenter des cas de test, analyser des exemples, ...





Relation de spécialisation/généralisation entre classes

Une classe A est une spécialisation d’une classe B si tout attribut/opération de B est également attribut/opération de A

Implémentation par héritage

Diagramme d’objetsObjectif : Représenter les objets et leurs liens à un

instant donné

Utilisation : documenter des cas de test, analyser des exemples, ...



Diagramme des classes

• Un diagramme de classes est un graphe :

Nœud du graphe = Classe

Abstraction d’un ensemble d’objets

Arc du graphe = Relation entre des classes :

Relation d’association

Abstraction d’un d’ensemble de liens entre objets

Relation de généralisation / spécialisation

Factorisation de propriétés communes à plusieurs classes

• Utilisations à différents niveaux :

Pendant la capture des besoins : Modèle du domaine

Classes = Objets du domaine




• Utilisations à différents niveaux :

Pendant la conception/implémentation : Modèle de conception

Classes = Objets logiciels

• Représentation UML des classes : 3 compartiments

Compartiment 1 : Nom de la classe (commence par une majuscule, en gras)

Compartiment 2 : Attributs

Compartiment 3 : Opérations

Possibilité d’ajouter des compartiments (exceptions, ...)




• Représentation UML des attributs

Format de description d’un attribut :

[Vis] Nom [Mult] [":" TypeAtt] ["=" Val] [Prop]

Vis : + (public), - (privé), # (protégé), (package)

Mult : "[" nbElt "]" ou "[" Min .. Max "]"

TypeAtt : type primitif (Entier, Chaîne, ...) ou classe

Val : valeur initiale à la création de l’objet

Prop : {gelé}, {variable}, {ajoutUniquement}, ...

Attributs de classe (statiques) soulignés

Attributs dérivés précédés de "/"




• Représentation UML des opérations

Format de description d’une opération :

[Visibilité] Nom ["(" Arg ")"] [":" Type]

Visibilité : + (public), - (privé), # (protégé)

Arg : liste des arguments selon le format [Dir] NomArgument: TypeArgument où Dir = in (par défaut), out, ou inout

Type : type de la valeur retournée (type primitif ou classe)

Opérations abstraites/virtuelles (non implémentées) en italique

Opérations de classe (statiques) soulignées




• Représentation UML des opérations

Possibilité d’annoter avec des contraintes stéréotypées

«precondition» et «postcondition»

Programmation par contrats

Possibilité de surcharger une opération :

même nom, mais paramètres différents

Stéréotypes d’opérations : «create» et «destroy»




• Association entre classes

Abstraction des relations définies par liens entre objets

Représentation schématique

Interprétation en français :

Un C1 Nom un C2 (ou un C2 Nom un C1 si sens lecture inverse)

Un C1 est rôle1 d’1 C2 et mult1 C1 peuvent jouer ce rôle pour un C2

Un C2 est rôle2 d’1 C1 et mult2 C2 peuvent jouer ce rôle pour un C1





Interprétation en langage de programmation objet

La classe C1 a un attribut de nom rôle2

Type = C2 si mult2 ϵ {1, 0..1}, ou collection de C2 sinon

La classe C2 a un attribut de nom rôle1

Type = C1 si mult1 ϵ {1, 0..1}, ou collection de C1 sinon

Exemple





Cardinalités multiplicités

Cardinalités Multiplicités

0,1 0..1

1,1 1 ou rien

0,N 0..* ou *

1,N 1..*

N,N N..N




• Exercice

Chaque étudiant du département IF suit un ensemble d’unités d’enseignement (UE).

Chaque UE a un coefficient et est constituée de cours, de travaux dirigés (TD) et de travaux pratiques (TP).

Chaque cours, TD ou TP a une date. Les cours sont faits en amphi, les TD en salle de classe et les TP en salle machine.

Pour les TP et TD, les étudiants sont répartis dans des groupes. Pour chaque TP, chaque étudiant est en binôme avec un autre étudiant.




• Exercice (suite)

Les cours et les TD sont assurés par un enseignant. Les TP sont assurés par deux enseignants.

Pour chaque UE, l’étudiant a une note de devoir surveillé; pour chaque TP, le binôme a une note de TP.




• Navigabilité d’une association entre C1 et C2

Capacité d’une instance de C1 (resp. C2) à accéder aux instances de C2 (resp. C1)

Par défaut :

Navigabilité dans les deux sens

C1 a un attribut de type C2 et C2 a un attribut de type C1

Spécification de la navigabilité :

Orientation de l’association

C1 a un attribut du type de C2, mais pas l’inverse

Attention :

Dans un diagramme de classes conceptuelles, toute classe doit être accessible à partir de la classe principale




• Propriétés et contraintes sur les associations

Propriétés sur extrémités d’associations

{variable} : instance modifiable (par défaut)

{frozen} : instance non modifiable

{addOnly} : instances ajoutables mais non retirables (si mult.>1)

Contraintes prédéfinies

Sur une extrémité : {ordered} (mult.>1), {unique}, ...

Entre 2 associations : {subset}, {xor}, ...




• Associations qualifiées

Restriction d’une relation / qualificateur :

Sélection d’un sous-ensemble d’objets à l’aide d’un attribut qualificatif (clé)

L’attribut qualificatif appartient à l’association

Exemple




• Classes-association

Association attribuée qui possède des attributs

Classe association peut participer à d’autres associations




• Associations n-aires (avec n>2)

Association entre n classes sans attributs

Un losange connecte les différentes classes




• Associations n-aires (avec n>2)

Association n-aires avec attributs

Soit on utilise une classe association

Soit on utilise un stéréotype

Avec contrainte d’unicité

Sans contrainte d’unicité




• Associations particulières

composition

Relation transitive et antisymétrique

La création (copie, destruction) du composite (container) implique la création (copie, destruction) de ses composants

Un composant appartient à au plus un composite

Agrégation

Simple regroupement de parties dans un tout




• Associations particulières : Généralisation /héritage

Niveau conceptuel : Généralisation

Relation transitive, non réflexive, et non symétrique

La sous-classe “est-une-sorte-de” la super classe : toute instance de la sous-classe est instance de la super classe

Niveau implémentation : Héritage (proposé par L.O.O.)

"B hérite de A" signifie que B possède : toutes les propriétés de A (attributs, op., assoc., contraintes)

Possibilité de redéfinir les opérations dans sous-classe (Polymorphisme)

Ainsi que des nouvelles propriétés qui lui sont propres

Permet de factoriser les propriétés communes à plusieurs classes

Une opération définie pour A est accessible aux sous-classes de A




• Associations particulières : Généralisation /héritage

Exemple




• Associations particulières : héritage vs composition

Problème :

Modéliser le fait qu’il y a des voitures bleues, des voitures rouges et des voitures vertes.

Solution 1 : Héritage

Créer une classe abstraite Voiture

Créer 3 classes VoitureBleue, VoitureRouge et VoitureVerte qui héritent de Voiture

Solution 2 : Composition

Créer une classe Voiture et une classe Couleur (énumération)

Créer une association entre Voiture et Couleur




• Associations particulières : héritage vs délégation

Problème :

Appeler dans une classe B une opération op() d’une classe A ?

Solution 1 : Héritage

Faire hériter B de A

op() peut être appelée depuis n’importe quelle instance de B

Solution 2 : Délégation

Ajouter une association de B vers A

Ajouter dans B un attribut a de type A

a.op() peut être appelée depuis n’importe quelle instance de B




• Associations particulières

Contraintes sur les relations de généralisation

{disjoint} ou {overlapping}

{complete} ou {incomplete}

{disjoint,complete} ) Partition

{leaf} ou {root}

Une partition complète stipule que Person peut être sous-type de soit Female Person soit Male Person

Une partition incomplète stipule que Person peut être aussi Employee ou non




• Classes génériques (Templates)

Classe paramétrée par d’autres classes

Factorisation de codeExemple de code C++template <class T> class Pile{

public:Pile() { ... }void empile(T e) { ... }...

private: ...};...Pile<float> p1;Pile<string> p2;p1.empile(2.5);p2.empile(’a’);...

Exemple de code Javapublic class Pile<T> {

public Pile() { ... }public void empile(T e) { ... }...private ...

};...Pile<Float> p1 = new Pile<Float>();Pile<String> p2 = new Pile<String>();p1.empile(2.5);p2.empile(’a’);...




• Classes abstraites

Classe qui ne peut être instanciée

Contient des opérations non définies :

Doit être spécialisée en une ou plusieurs classes non abstraites

Notation : mot clé {abstract} ou nom en italique

Pourquoi des classes abstraites ?

Spécifier un comportement commun à plusieurs classes

Manipuler instances de classes ≠tes de façon uniforme

Polymorphisme

Bonne pratique :

Dans une hiérarchie d’héritage, les classes qui ne sont pas des feuilles sont généralement abstraites




• Interface

Classe sans attribut dont toutes les opérations sont abstraites

Ne peut être instanciée

Doit être réalisée (implémentée) par des classes non abstraites

Peut hériter d’une autre interface

Pourquoi des interfaces ?

Utilisation similaire aux classes abstraites

En Java : une classe ne peut hériter de plus d’une classe, mais elle peut réaliser plusieurs interfaces




• Interface

Notations UML :

Nom : «interface» Itf1

Héritage : Itf1 —▷ Itf2

Réalisation : Class1 - - - -▷ Itf1 ou Class1——-O

Utilisation : Class2 - - «use» - -> Itf1 ou Class2——-C

Itf1

Itf1




• Interface : Exemple :




• Quelques stéréotypes et mots-clés {abstract} : classe abstraite (alternative : nom en italique)

«interface» : interface

«énumération» : instances ϵ à un ensemble fini de littéraux

«type primitif» : instances valeurs d’un type primitif

«classe implémentation» : implémentation d’une classe dans un langage de programmation

«utilitaire» : variables et procédures globales




• Résumé des différentes relations

Association

Navigable dans les 2 sens : ——————

Navigable dans un sens : ——————> ou –X—————>

Composition : ——————◆

Agrégation : ——————◇

Généralisation : ——————▷

Réalisation d’1 interface : —————O ou - - - - - - -▷

Utilisation d’1 interface : ————C ou - - - «use» - - - >

Intanciation classe générique : - - - «bind» (Type) - - - >

Dépendance : - - - - - - - - - - >




• Exercice : chercher l’erreur dans les diagrammes




• Génération de code en Java

Classes – Interface – classe abstraite

Associations




• Génération de code en Java

Agrégations - héritage

Réalisation d’interfaces




• Génération de code en SQL

Classes

Associations

héritages



Travaux Pratiques N°1

• Exercices 1 et 2 fiche de TD




• Définition : élément de modélisation qui

Contient d’autres éléments de modélisation (classes, autres paquetages, ...)

Possibilité de ne pas représenter tous les éléments contenus

Définit un espace de nom (namespace)




• Espace de nom et visibilité 2 éléments dans 2 paquetages différents sont différents

Nom complet = nom préfixé par les noms des paquetages englobants : Banque::Compte ≠ Commerce::Compte

Visibilité d’un élément E dans un package P :

Public (+) : Elément visible par tous (utiliser nom complet)

Privé (-) : Elément visible uniquement parles autres éléments de Ples éléments englobés par E (si E est un package)




• Dépendances entre paquetages

Une classe A dépend d’une classe B (noté A - - - - > B) si :

Il existe une association navigable de A vers B (ou A possède un attribut de type B)

Une méthode de A a un paramètre ou une variable locale de type B

Stéréotypes sur les dépendances inter-paquetage

A - - - «accède» - - - > B : tout élément public de B est accessible par son nom complet depuis A

A - - - «importe» - - - > B : tout élément public de B est accessible par son nom depuis A (création d’alias si nécessaire)

Valeur marquée {global} :

Paquetage visible par tous les autres paquetages




• Architectures logiques

Regroupement des classes logicielles en paquetages

Point de départ pour un découpage en sous-systèmes

Objectifs d’une architecture logique :

Encapsuler et décomposer la complexité

Faciliter le travail en équipes

Faciliter la réutilisation et l’évolutivité

Forte cohésion intra paquetage

Faible couplage inter paquetages

Exemples d’architectures logiques :

Architecture en couches

Architecture Modèle - Vue - Contrôleur (MVC)



Diagramme des composants

• Composant :

Encapsule l’état et le comportement d’un ensemble de classifiers (classes, composants...)

Spécifie les services fournis et requis :

Interfaces fournies : «provided interfaces» ou —–O

Interfaces requises : «required interfaces» ou ——C

Substituable à tout composant qui offre/requiert les mêmes interfaces



Diagramme des composants

• Relations entre composants :

Inclusion entre composants et fournitures ou utilisation d’interface



Diagramme de deploiementdéploiement du système sur architecture physique

Disposition des artefacts sur les noeuds physiques

Artefacts : instances de composants, processus, ...

Noeuds physiques : Ordinateur, Téléphone, Imprimante, ...

Moyens de communication entre les noeuds


U.M.L. : Modéliser le comportement

Objectifs décrire :

• Comportement du système en termes d’interactions

Système vu comme une boite noire :

Qui interagit avec le système, et dans quel but ?

Diagramme de cas d’utilisation

Comment interagit le système avec son environnement ?

Diagramme de séquence système

Système vu comme une boite blanche :

Comment interagissent les objets du système ?

Diagramme de séquence et/ou de communication

• Évolution du système dans le temps Comment évoluent les états des objets ?

Diagrammes d’états-transitions



Diagramme des cas d’utilisationPermettre au client de décrire ses besoins

Parvenir à un accord (contrat) entre clients et développeurs

Point d’entrée pour les étapes suivantes du développement

Définition d’un cas d’utilisation ?

Usage que des acteurs font du système

Acteur : Entité extérieure qui interagit avec le système

Une même personne peut jouer le rôle de différents acteurs

Un acteur peut être un autre système (SGBD, Horloge, ...)

Usage : Séquence d’interactions entre le système et les acteurs

Généralement composé de plusieurs scénarios (instances)

Scénario de base et ses variantes (cas particuliers)

Description des scénarios à l’aide de diagrammes de séquence



Diagramme des cas d’utilisationComment découvrir les cas d’utilisation ?

Délimiter le périmètre du système

Déterminer ce qu’il devra faire, services qu’il rendra

Mais pas comment il devra le faire

Point de vue de l’utilisateur

Identifier les acteurs interagissant avec le système :

rôles

Déterminer les grandes catégories d’utilisation

Cas d’utilisation

Nommer les cas d’utilisation : Nom = Verbe à l’infinitif + Groupe nominal

Décrire textuellement les interactions de chaque cas

scénarios



Diagramme des cas d’utilisationActeur

Entité (humain ou machine) située hors du système

Permet de déterminer les limites du système

Joue un rôle par rapport au système soit

déclenche un stimulus entrainant une réaction du système

est sollicité par le système au cours d’un scénario

Un acteur est décrit précisément en quelques ligne

Catégories d’acteurs

Acteurs principaux (fonctions principales du système)

Acteurs secondaires (administration/maintenance)

Matériel externe

Autres systèmes



Diagramme des cas d’utilisationCas d’utilisation

Ensemble de séquence d’actions réalisées par le système, produisant un résultat observable pour un acteur particulier

Exemple : s’identifier, retirer du liquide, répondre à un mail

Un cas d’utilisation

Définit un ensemble de scénarios d’exécutions impliquant le même acteur (déclencheur) avec le même objectif utilisateur

Recense les informations échangées et les étapes dans la manière d’utiliser le système, les différents points d’extension et tous les cas d’erreur


Diagramme des cas d’utilisationScénario

Séquence d’étapes dans la réalisation d’un cas d’utilisation

Séquence particulière de messages dans le cas d’utilisation pendant une interaction particulière

Tous les scénarios d’un cas d’utilisation sont issus du même acteur ont le même objectif

Description du cas d’utilisation

Ensemble de scénarios couvrant le cas d’utilisation

Documents avec flot d’événements : détaille ce qui se passe entre utilisateur et système quand le cas est exécuté

• flot nominal des événements

• flot d’événements alternatifs

• flots d’exceptions (terminaison incorrecte)

Serviront de base pour les jeux d’essais



Diagramme des cas d’utilisationExemple de diagramme de cas d’utilisation



Diagramme des cas d’utilisation

• Relations entre cas d’utilisation

Inclusion :

le cas A inclut le cas B (B est une partie obligatoire de A, comportement décrit par A inclut comportement de B)

Extension :

le cas B étend le cas A (B est une partie optionnelle de A, B peut être appelé au cours d’exécution de A)(préciser la condition)

Généralisation :

le cas A est une généralisation du cas B (B est une sorte de A).




• Dépendances d’inclusion et d’extension

Les inclusions et les extensions sont représentées par des dépendances.

Lorsqu'un cas B inclut un cas A, B dépend de A.

Lorsqu'un cas B étend un cas A, B dépend aussi de A.

On note toujours la dépendance par une flèche pointillée B --->A qui se lit « B dépend de A » .

Lorsqu'un élément A dépend d'un élément B, toute modification de B sera susceptible d'avoir un impact sur A.

Les « include » et les « extend » sont des stéréotypes (entre guillements) des relations de dépendance.

sens des flèches indique la dépendance, pas sens de la relation


Diagramme des cas d’utilisationReprésentation textuelle du cas d’utilisation

Associée à une représentation graphique (élément le plus utile)

Ensemble de champs de description (nom, préconditions…)

Lisible et informelle (langage naturel, pas trop long, …)

décrit

Un scénario nominal (suite d’étapes avec objectifs de l’acteur bien identifiés et menés à bien)

Des points d’extension et étapes d’extension

Des points d’échec

Des liens vers d’autres scénarios s’il y a trop d’étapes

Complément de description (permet de mieux comprendre le cas)

Diagramme de séquence

Diagramme d’activité, de machine d’états

Dessin, maquette d’interface ou documents quelconques




• Rédaction de cas d’utilisation

Généralités

Intérêts et intervenants

Portée de conception

Acteurs et objectifs

Préconditions, garanties et déclencheurs

Scénarios

Extension

Variantes de technologies et de données

Formats de cas d’utilisation

divers



Diagramme des cas d’utilisationPhases de rédaction de cas d’utilisation

Nom :<objectif sous forme de courte expression verbale infinitive exprimant une action>

Contexte d’utilisation : <formulation plus longue de l’objectif>

Portée :<quel système est considéré comme boite noir en cours de conception>

Niveau :<stratégie, objectif utilisateur, sous-fonction>

Acteur principal :<nom de rôle de l’acteur principal ou description>

Intervenants et intérêts :<liste d’intervenants et d’intérêts essentiels dans le CU>

Préconditions :<ce que doit être l’état du monde avant le début>

Garanties minimales :<mode de protection des intérêts quelle que soit l’issue>



Diagramme des cas d’utilisationPhases de rédaction de cas d’utilisation

Garanties en cas de succès : <état du monde si l’objectif est rempli>

Déclencheur :<ce qui démarre le CU; peut être un événement temporel>

Scénario nominal :<étapes du scénario du déclenchement à la réalisation de l’objectif><numéro étape><description de l’action>

Extensions : <extensions, une par une, chacune faisant référence à l’étape concernée du scénario nominal><numéro d’étape modifiée><condition> : <action ou sous cas d’utilisation>

Listes de variantes de technologies et de données

Informations connexes : <tout type d’information dont peut avoir besoin le projet>



Diagramme d’états-transitions

• Utilisé pour modéliser :

les états simples, les transitions et les états composites imbriqués

L’état d’un objet à un instant t peut changé à l’instant t+1

Le passage d’un état à un autre est une transition

La condition de passage est appelée «garde»

État-transition



Diagramme d’états-transitionsÉtat-transition : on peut préciser une action ou activité

Suite d’états et de transitions avec

Début:

Fin:

Ti : transition –Ci : condition –Ai : action




• Différents types d’événements

Signaux :

Q0 ————————————–> Q1

Appels d’opérations :

Q0 ————————————–> Q1

Les paramètres peuvent être typés ou non

Evénements temporels :

Q0 ————————————–> Q1

Passage dans l’état Q1 qté tps après l’arrivée dans l’état Q0

Evénements de changement :

Q0 ————————————–> Q1

Passage dans l’état Q1 quand cond devient vraie

nomSignal

nomOp(paramètres)

after(qté tps)

when(cond)




• États imbriqués ou composites

Un état peut contenir des sous-états

Permet de factoriser les transitions de sortie du composite

Chaque transition de sortie s’applique à tous les sous-états

Une seule transition d’entrée

Exemple




• États concurrents

Plusieurs sous-automates peuvent être concurrents :

Etat courant = n-uplet de sous-états

Etats de S = f(Z;A); (Z;B); (X;A); (X;B); (Y;A); (Y;B)g

Exécution indépendante des sous-automates

Un évt peut déclencher une transition dans plusieurs sous-auto.

Sortie possible quand tous les sous-auto. sont dans un état final




• Gardes et transitions composites

Conditions de gardes

Transition de A vers B réalisée si cond est vraie quand e1 arrive

Si cond est fausse alors e1 est perdu

Transitions composites

Factorisation de l’événement déclencheur validation

Les gardes doivent être mutuellement exclusives pour que l’automate soit déterministe




• Actions et activités

Actions (envoi de signaux, invocation d’opérations, ...) :

Peuvent être exécutées :

Lors d’une transition (ex. : action4)

En entrant dans un état (ex. : action1)

En sortant d’un état (ex. : action3)

Sont atomiques (ne peuvent être interrompues par un événement)

Activités :

Peuvent être exécutées dans un état (ex. : activité2)

Peuvent être continues ou non

Sont interrompues à l’arrivée d’un événement en sortie de l’état




• Actions et activités

Exemple

Ordre d’exécution : action1 - activité2 - action3 - action4




• Quelques conseils

Pas de transition sans événement

L’automate doit être déterministe (en général...)

Si plusieurs transitions partant d’un état ont le même événement, alors il doit y avoir des gardes qui garantissent le déterminisme

Tous les états doivent être accessibles depuis l’état initial

S’il y a des états terminaux alors, pour chaque état non terminal, il doit exister un chemin de cet état vers un état terminal (...en général)



Diagramme d’activités

• Objectifs

Permet de s’intéresser aux traitements

Modélisation du flot de contrôle et du flot de données

Permet de regrouper graphiquement

Le comportement d’une méthode

Le déroulement d’un cas d’utilisation

Offre une vision très proche des langages de programmation impératifs



• Action

Plus petit traitement exprimé en UML

Équivalent instruction d’un langage de programmation

Principales actions

Action appeler (call operation)

Action comportement (call behavior)

Action envoyer (send)

Action accepter événement (accept event)

Action accepter appel (accept call)

Action répondre (reply)

Action créer (create)

Action détruire (destroy)

Action lever exception (raise exception)




• Action

Graphiquement actions sont dans des nœuds actions

Rectangle avec bords arrondis

Notation spéciale pour action de communication




• Activité

Définit un comportement décrit par un séquencement organisé d’unités dont les éléments simples sont les actions

Le flot d’exécution est modélisé par des nœuds reliés par des arcs (transitions)

Groupe d’activités

Activité regroupant des nœuds et des arcs

Un diagramme d’activités est lui-même un groupe d’activités

Nœuds d’activités




• Transition

Passage d’une activité à une autre

2 types de transitions

Automatique : fin d’1 activité entraine début de l’autre

Gardée : le passage d’1 activité à l’autre n’est possible que si condition mentionnée est vérifiée




• exemple




• Nœuds de contrôle

Nœud initial (initial node)

Nœud de fin d’activité (final node)

Nœud de fin de flot (flow final)

Nœud de décision (decision node)

Nœud de fusion (merge node)

Nœud de bifurcation (fork node)

Nœud d’union (join node)




• Nœuds de contrôle




• Nœud d’objet

Permet de définir un flot de données

Dispose de pins d’entrée ou sortie

Flot d’objets

Permet de passer des valeurs d’une activité à une autre




• Nœud d’objet

Nœud tampon central

Nœud de stockage des données



Diagramme d’activitésPartitions

Permettent d’organiser les nœuds d’activités en des regroupements

Graphiquement, partitions délimitées par lignes continue

Appelées couloirs ou lignes d’eau




• Exercices 5, 6 et 7 fiche de TD



Diagrammes d’interaction

• Point de vue temporel sur les interactions

Pendant la capture des besoins (système = boite noire) :

Interactions entre acteurs et système

Décrire les scénarios des cas d’utilisation

Pendant la conception (système = boite blanche) :

Interactions entre objets

Réfléchir à l’affectation de responsabilités aux objets

Qui crée les objets - Qui permet d’accéder à un objet ?

Quel objet reçoit un message provenant de l’IHM ? ...

de façon à avoir un faible couplage et une forte cohésion

Elaboration en parallèle avec les diagrammes de classes

Contrôler la cohérence des diagrammes !




• Objectif

décrire scénarii nominaux de chq cas d’utilisation (description textuelle de cas d’utilisation)

Point de vue analyse : interaction entre acteurs et système global




• Objectif Point de vue conceptuelle : interaction entre acteurs et différents

objets du système




• Message

élément nommé qui définit une catégorie spécifique de communication entre des lignes de vie d’une interaction

Un message reflète

L’appel d’une opération (méthode) et le début de l’exécution

Envoi et réception d’un signal

Un message peut être

Un appel synchrone

Un appel asynchrone

Une création

Une destruction

Une réponse



Diagramme de séquenceAppel synchrone / Appel asynchrone

Représente un appel de méthode

- L’émetteur envoie un message- Il suspend son exécution durantl’attente de la réponse

- Flèche pleine à son extrémité

- L’émetteur envoie un message- Il continue son exécution sansattendre la réponse

- Flèche ouverte à son extrémité



Diagramme de séquenceMessage de création / Message de destruction

- Message envoyé à une ligne de vie- Flèche pointillée, ouverte à sonextrémité, pointant sur la tête d’uneligne de vie

- Message envoyé à une ligne devie pour la terminer

- La ligne de vie se termine parune croix



Diagramme de séquenceMessage de réponse /Message avec contrainte temporelle

- Message envoyé en réponse à un appel- Flèche pointillée avec extrémité

- Message envoyé avec une certaine durée- flèche oblique



Diagramme de séquenceDifférents événements liés à un message

Envoi du message / Réception du message

Début d’exécution / Fin d’exécution



Diagramme de séquenceObjet actif / objet passif

Objet actif

Initie et contrôle le flux d’activités

La ligne pointillée verticale est remplacée par un double trait vertical

Objet passif

À besoin d’un flux d’activité pour pouvoir exécuter méthode

Exécution d’une réaction représentée par rectangle blanc ou gris placé sur ligne de vie en pointillé



Diagramme de séquenceExécution simultanées sur la même ligne de vie

Messages réflexifs



Diagramme de séquencecadres




• Opérateurs pour fragments d’interactions combinés

Opérateurs de choix et boucle

Alternative

Option

Loop

Break

Opérateurs contrôlant l’envoi en parallèle de messages

Parallel

Critical region

Opérateurs fixant l’ordre d’envoi des messages

Strict sequencing

Weak sequencing




• Fragments d’interactions combinés

Opérateur alternative

Le fragment représente un choix

Similaire à un switch en C





Opérateur option

Équivalent à un opérateur alternative avec une seule condition





Opérateur loop

Permet de spécifier une boucle

Boucle qui s’exécute possiblement une infinité de fois

Boucle qui s’exécute 10 fois

Boucle s’exécute au minimum 5 fois et au maximum 10 foisSi condition est fausse, on sort de la boucle, quelque soit le nombre d’exécution de la boucle





Opérateur break

Si condition du break est vraie, on exécute fragment associé et on ignore le reste du fragment dans lequel break est inclus

Si condition du break est fausse on passe directement à la suite du fragment englobant





Opérateur parallel

Spécifie l’exécution en parallèle de plusieurs sous fragments





Opérateur strict sequencing

Les fragments s’exécutent les uns après les autres





Opérateur weak sequencing

Si les lignes de vie atteintes sont les mêmes exécution

séquentielle

Si les lignes de vie atteintes sont différentes exécution

parallèle

Google en parallèle avec bing et/ou yahoo

Bing puis yahoo




• Utilisation d’interactions

Possibilité de faire référence à une interaction dans la définition d’une autre interaction

Permet la réutilisation d’une définition dans des contextes différents



Diagramme de communication

• Diagrammes d’interactions

Les diagrammes de communication et les diagrammes de séquences sont deux types de diagramme d'interaction

Un diagramme de séquence montre des interactions sous un angle temporel, en mettant l'emphase sur le séquencement temporel de messages échangés entre des lignes de vie

Un diagramme de communication montre une représentation spatiale des lignes de vie. Ils représentent la même chose, mais sous des formes différentes.

UML 2.0 ajoute un troisième : le diagramme de timing.

usage limité à la modélisation des systèmes qui s'exécutent sous de fortes contraintes de temps, comme les systèmes temps réel.




• Diagrammes de séquence et de communication




• Rôles et connecteurs

Rôle permet de définir contexte d'utilisation de l'interaction.

Une rôle dans un diagramme de communication correspond à une ligne de vie dans un diagramme de séquences.

« connecteurs » relations entre les lignes de vie

Un connecteur se représente de la même façon qu'une association mais la sémantique est plus large : un connecteur est souvent une association transitoire.

Comme pour les diagrammes de séquence, la syntaxe d'une ligne de vie est :

<nomRole >[< selecteur >]: < nomClasseur >




• Types de messages

idem diagrammes de séquence, 2 types de messages :

Un message synchrone bloque l'expéditeur jusqu'à la réponse du destinataire. Le flot de contrôle passe de l'émetteur au récepteur.

Un message asynchrone n'est pas bloquant pour l'expéditeur. Le message envoyé peut être pris en compte par le récepteur à tout moment ou ignoré.




• Représentation des messages

Les flèches représentant les messages sont tracées à côté des connecteurs qui les supportent.

N.B. : Bien faire la distinction entre les messages et les connecteurs : on pourrait avoir un connecteur sans message, mais jamais l'inverse.




• Numéros de séquence des messages

Utiliser pour représenter aspects temporels

messages successifs ordonnés selon numéro croissant (1, 2, ... )

messages envoyés en cascade (appel de méthode à l'intérieur de méthode) ont numéro d'emboîtement avec une notation pointée (1.1, 1,2, …) Équivalent diagramme de séquence




• Messages simultanés

Lorsque des messages sont envoyés en parallèle, on les numérote avec des lettres

1.a, 1.b,... pour des messages simultanés envoyés en réponse à un message dont l'envoi portait le numéro 1



Diagramme de communicationSyntaxe générale des messages

synchronisation : les préalables à l’envoi du message;

n° du message : ordre chronologique du message;

condition du déclenchement de l’envoi;

type d’envoi: séquentiel ou parallèle;

résultat : valeur retournée…

Exemples :

[activitéprofessionnelle=Ok] 1: établir plan()

Un élève ne peut s’inscrire que si il a une activitéprofessionnelle

2 / || [j=1…n] 3 : inscrireUE()

Le message 3 ne sera envoyé qu’après le message 2 Envoi en // de n messages




• Contrat d’opérations

Réaliser via diagramme de séquence ou communication

Affinement diagramme des classes

Écriture de code

public void op(e :E) { C obj = Obj1.fonc(var) Obj2.op1()

…}

U.M.L. - labs.ivoiretalents.com · ASSALE Adjé Louis UML 1 U.M.L. Généralités • UML (Unified...

Documents

Transcript of U.M.L. - labs.ivoiretalents.com · ASSALE Adjé Louis UML 1 U.M.L. Généralités • UML (Unified...