Unified Modeling Language

1
Unified Modeling Language
Jean-Marc Jézéquel IRISA/CNRS et Yves Le Traon
IRISA/Ifsic
2
PLAN

• Introduction à la modélisation selon UML
• historique, intérêts de la modélisation
• cycles de vie
• Les 9 vues dun 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

3
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)
4
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 à lOMG. 2Q99 gtVersion 1.4

5
La consécration des méthodes fondées sur la
modélisation

• Lapproche par modélisation facilite
• Communication (et sa précision)
• avec donneur dordre
• 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é ltgt isomorphique ou
  plongement/projection

6
Un peu de Méthodologie...

• Une méthode de développement de logiciels, cest
  
• 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 dactivité
• Informatique de gestion
• Systèmes réactifs temps-réels
• Shrink-wrap software (PC)

7
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é

• Lorganisation de ces activités et leur
  enchaînement définit le cycle de développement du
  logiciel

8
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
Réalisation
 Codage
 Mise au point
 Tests unitaires
Variante US Cycle en  cascade 
9
Problèmes avec le processus classique...
10
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 ltgt cycle développement
• linéarité implicite
• temps d approbation des documents gt effet
  tampon
• coût de la (non-) modification d un document
   final 
• irréaliste pour un projet innovant, donc à
  risques

11
Cycle de vie en  spirale 
Synergie avec approche par objets
12
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é gt 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)

13
Vision générique dun 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 dimplantation
CONSTRUCTION
ELABORATION

• 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)

14
Modélisation UML

• Modélisation selon 4 points de vue principaux
• Vision utilisateur du système
• Cas dutilisation
• 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 dactivités
• Vision implantation
• Diagramme de composants et de déploiement

15
Température des diagrammes UML
Température

• Diagramme de cas dutilisations
• Diagramme de classes
• Diagramme de paquetages
• Diagramme de séquences
• Diagramme de collaborations
• Diagramme détats-transitions
• Diagramme dactivités
• Diagramme dimplantation

16
Modélisation UML

• Modélisation selon 4 points de vue principaux
• Vision utilisateur du système
• Cas dutilisation
• 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 dactivités
• Vision implantation
• Diagramme de composants et de déploiement

17
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

18
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

19
Les moyens

• Les acteurs UML
• Les use-cases UML
• Utilisation dun dictionnaire du domaine

20
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.

21
Exemple de dictionnaire

• Dictionnaire d'un simulateur de vol

Notion
Nom informatique
Traduit en ...
Définition
Action de piloter un avion en enchaînant des
manoeuvres élémentaires
Pilotage
Pilotage
Package
Classe abstraite
Instrument
Instrument
Organe d'interaction entre le pilote et l'avion
ou entre l'avion et le pilote
Manette des gaz
Instrument qui permet d'agir sur la quantité de
carburant injectée dans le moteur
Manette_gaz
Classe
Action
Nom informatique
Traduit en ...
Définition
Action qui permet dinjecter le maximum de
carburant pour atteindre la vitesse maximale
Mettre les gaz à fond
Mettre_a_fond
Opération
22
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

23
Acteurs notations
Système de vente par correspondance (VPC)
Actor SUPERVISEUR
24
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 sexpriment 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

25
Cas d'utilisation exemple et notation
VPC

Traiter commande
CLIENT
Etablir crédit
26
Relations sur les use-cases

• Communication
• Lien entre le use case et lacteur.
• De type  association 
• Utilisation (uses)
• Utilisation dautres 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 

27
Relations sur les use-cases notation

Commander échantillon
includes
extends
includes
Lire données client
Consulter Catalogue
includes
Sélectionner produit
28
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

29
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
• ...

includes
includes
includes
includes
30
Utiles pour létablissement de scénarios

• Modélisation dexemples issus des use-cases

Domaine de lapplication
service1
service1()
besoin1
service3
service3()
service1()
service4
besoin2
service2()
service3()
scénario du use case besoin 2
service3
service4()
service5()
service5()
service2
besoin3
service6()
service1()
service5
service6()
besoin4
service2()
31
Modélisation UML

• Modélisation selon 4 points de vue principaux
• Vision utilisateur du système
• Cas dutilisation
• 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 dactivités
• Vision implantation
• Diagramme de composants et de déploiement

32
Notations UML pour classes et objets

• Représentation dune classe

Représentation simplifiée
Représentation des objets
Nom de la classe
CL805699 Compte
Compartiment des Attributs
Nom de lobjet
Compartiment des Opérations
33
Constituants dune 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

34
Représentation des attributs

• Caractérisation des attributs

ATTRIBUTS
Type de l'attribut
Nom de l'attribut
35
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é

36
Représentation des opérations

• Vues graphiques

Nom de lopération
Nom de paramètre
Classe du paramètre
37
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 gt plancher

38
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 OCL _at_pre

39
Etre abstrait et précis avec UML
Compte soldegtplancher
solde Somme plancher Somme
créditer (montant Somme) pre montant gt 0
post solde solde _at_pre montant débiter (s
Somme) pre montant gt 0 and montantltsolde-plan
cher post solde solde _at_pre - montant
Analyse précise ou analyse par contrat
40
Relation entre classes

• Deux points de vue
• Une relation met en correspondance des éléments
  densembles
• Une relation permet la description d'un concept à
  laide dautres concepts
• Une contrainte
• Une relation est un lien stable entre deux objets

41
Relation entre classes

• Notation
• Vue ensembliste Graphe de la relation

1
Voiture
Personne
Possession
Une association met en correspondance des
éléments densembles
42
Représentation des relations

• Relation, direction, rôle, cardinalité

direction de relation
Rôle
Nom de relation
passager
transporte
Voiture
Personne
moyen_de_transport

Rôle
Cardinalité précisée
43
Cardinalité d'une relation
1
Exactement une
Classe

Plusieurs (0 à n)
Classe
0,1
Optionnelle (0 ou 1)
Classe
1,2,4
Classe
Cardinalité spécifiée
1-10
Intervalle
Classe
44
Cas particuliers de relations

• Relations réflexives

encadre
chef
1
Personne
sous-fifre
1..
Une relation réflexive lie des objets de même
classe
45
Composition et Agrégation

• Cas particuliers de relations
• Notion de tout et parties

1
1
1
Composition
roulement gt
Roue
4,6
1
structure gt
Agrégation
Chassis
46
Autre vues de la composition/agrégation

• Différentes formes suggérant linclusion

roulement 4-6
Roue
structure 1
Chassis
47
Relations n-aires

• Relations entre plus de 2 classes (à éviter si
  possible)

Enseignement

1..
MATIERE
PROFESSEUR
Enseignée
Enseignant
Destinataire
1..
CLASSE
48
Relations attribuées

• L'attribut porte sur le lien

épreuve
candidat
n..k
Etudiant
Matière
objet_épreuve
Note
49
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..
Répertoire
Nom du fichier
Répertoire
Nom du fichier
Relation non qualifiée
Relation qualifiée
Un répertoire un nom de fichier
identifient de façon unique un fichier
50
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
AVION
AVION
51
Interfaces et  lollipop 
 interface 
MOBILE
MOBILE
Raffinement
AVION
AVION
52
Héritage des relations

• Les relations sont héritées par les sous classes

motorisation
VEHICULE
MOTEUR
1..2
VOITURE
CAMION
lien logique
REPERTOIRE
FICHIER
1..

DRIVER
FICHIER_TEXTE
FICHIER_BINAIRE
53
Représentation de classes abstraites

• Classes sans instances immédiates

Forme abstract
Carre
Cercle
Une instance de Forme est obligatoirement une
instance de la classe Carre ou de la classe
Cercle
54
Représentation des opérations abstraites

• Opération sans corps dune classe abstraite

Forme abstract
calculer_surface () abstract
Carre
Cercle
calculer_surface()
calculer_surface()
55
Visibilité

• Différentes visibilités des membres d'une classe

public
usager
protégé
Interface
héritier
privé -
implémenteur
corps
56
Visibilité

• Représentation
• Pas de sens en analyse...

Classe
a1 T1 -a2 T2
m1 (p1,P2,p3)
m2 (p1,P2,p3)
57
Classes paramétrées (Généricité)
Classe générique
T , Entier Integer
Tableau
element T taille Entier
paramètres génériques
ltltbindgtgt ltPoint, 3gt
Tableau
paramètres effectifs
Classe effective
58
Les relations en tant que classes

• Pratique dans certains cas
• Relations ternaires.
• La relation a des opérations appelées classe de
  liaison

station de travail

autorisation sur
utilisateur
autorisation
priorité privilèges
session de démarrage

home directory
répertoire
59
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 lutilisateur)
• Peuvent être attachés aux éléments de
  modélisations et aux diagrammes
• Classes, objets, opérations, attributs,
  généralisations, relations, acteurs, uses-cases,
  événements, diagrammes de collaboration ...

60
Notations pour les stéréotypes

stéréotype
persistent CLIENT

persistent CLIENT
nom string adresse string
nom string adresse string
CLIENT
nom string adresse string
61
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

employé
employeur
chef
PERSONNE

0..1
0..1
PERSONNE.employeur PERSONNE.chef.employeur
62
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 limplémentation raisonner
  objets, classes, messages, relations, attributs,
  opérations
• ne pas sinquiéter si les possibilités de la
  notation ne sont pas toutes exploitées

63
Conseils pratiques (suite)

• Approche incrémentale
• Itérer
• Confronter ses modèles aux autres
• Savoir s'arrêter avant datteindre 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 nest pas un modèle où lon ne peut
  plus rien ajouter, mais un modèle où on ne peut
  plus rien enlever. (daprès A. de St-Exupéry)

64
Modélisation UML

• Modélisation selon 4 points de vue principaux
• Vision utilisateur du système
• Cas dutilisation
• 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 dactivités
• Vision implantation
• Diagramme de composants et de déploiement

65
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
  lapplication
• Il référence ou se compose dautres packages
• Un package réglemente la visibilité des classes
  et des packages quil 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 dune classe

66
Représentation dun package

• Vue graphique externe
• Vue graphique externe et interne

P1
67
Partitionnement dune application

•   Définition de vues partielles d'une
  application

SYNTHÈSE EN PACKAGES
ENSEMBLE DES CLASSES DE L'APPLICATION
N.B. une classe appartient à un et un seul
package
68
Visibilité dans un package

• Réglementation de la visibilité des classes
• Classes de visibilité publique
• classes utilisables par des classes dautres
  packages
• Classes de visibilité privée
• classes utilisables seulement au sein dun
  package
• Représentation graphique

69
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 quune classe dun package p1 puisse
  utiliser une classe dun package p2, il doit y
  avoir au préalable une déclaration explicite de
  lutilisation du package p2 par le package p1
• Représentation graphique

70
Utilisation entre packages

• Exemple (vue externe du package livraisons)

LIVRAISONS
LIVREURS
VEHICULES
COLIS
71
Héritage entre packages

• Exemples

72
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

73
Structuration par packages (vs)décomposition
hiérarchique

• Pour les grands systèmes, il est nécessaire de
  disposer dune unité de structuration
• À un niveau supérieur,
• Plus souple que
• La composition de classe
• Le référençage de packages

gt domaines de structuration Packages
décomposables en packages
74
Exemple Package entreprise

• Exemple de composition

ENTREPRISE
COMMERCIAL
COMPTABILITÉ
LIVRAISON
75
Exemple Package entreprise

• Ensemble des packages terminaux de lapplication

Véhicules
Livraisons
Facturation
Livreurs
Clientèles
Bilan
Colis
Commerciaux
Personnel
76
Exemple Package entreprise

• Composition des packages en sous-packages

ENTREPRISE
COMPTABILITÉ
LIVRAISONS
Véhicules
Facturation
Livraisons
Bilan
TenueComptes
Livreurs
Personnel
COMMERCIAL
77
Modélisation UML

• Modélisation selon 4 points de vue principaux
• Vision utilisateur du système
• Cas dutilisation
• 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 dactivités
• Vision implantation
• Diagramme de composants et de déploiement

78
Aspects dynamiques du système

• Jusquici, 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
  lapplication doit réaliser
• Il faut maintenant décrire comment le système
  évolue dans le temps

79
Modélisation UML

• Modélisation selon 4 points de vue principaux
• Vision utilisateur du système
• Cas dutilisation
• 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 dactivités
• Vision implantation
• Diagramme de composants et de déploiement

80
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 lapplication
• Illustrent la dynamique denchaî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 dun scénario sont
• Un ensemble dobjets (et/ou dacteurs)
• Un message initiateur du scénario
• La chronologie des messages échangés
  subséquemment
• Les contraintes de temps (aspects temps réel)

81
Syntaxe graphique

• Objets et messages

Objets Instances de classes
Nom Objet1NomClasse1
Nom ObjetNomClasse
nom message (paramètres)
Message nom message émis par Nom Objetvers Nom
Objet1
Temps
82
Ligne de vie et activation

• La ligne de vie représente lexistence de
  lobjet à un instant particulier
• Commence avec la création de lobjet
• Se termine avec la destruction de lobjet
• Lactivation est la période durant laquelle
  lobjet exécute une action lui-même ou via une
  autre procédure

83
Notation
Objet existant avant et après lactivation du
scénario

objet2Classe2
Objet créé dans le scénario
op ( )
objet1Classe1
m1 ( )
m2 ( )
objet3Classe3
m3 ( )
Activité de lobjet
Ligne de vie
84
Messages

• Communication entre objets
• Des paramètres
• Un retour
• Cas particuliers
• Les messages entraînant la construction dun
  objet
• La récursion
• Les destructions dobjets

85
Notations

objet2Classe2
Création dobjet
Envoi de message avec paramètre
op ( )
objet1Classe1
m1 ( par )
m2 ( )
Récursion
Destruction dobjet
Retour dopération
86
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 classe2
Nom Objet1
Nom classe2
Nom Objet1
demande
d
a
demande
b-alt 5 sec.
réponse
d
b
d-dlt 1 sec.
87
Représentation de conditionnelles

objet2Classe2
Branchement conditionnel
op ( )
objet1Classe1
xlt0 m1 ( x )
xgt0 m2 ( x )
Branchement conditionnel
88
Modélisation UML

• Modélisation selon 4 points de vue principaux
• Vision utilisateur du système
• Cas dutilisation
• 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 dactivités
• Vision implantation
• Diagramme de composants et de déploiement

89
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 lapplication
• Les scénarios
• Illustrent la dynamique denchaînement des
  traitements dune application en introduisant la
  dimension temporelle
• Les diagrammes de collaboration
• Dimension temporelle représentée par numéros de
  séquence définition dun ordre partiel sur les
  opérations
• Représentation des objets et de leurs relations
• Utilisent les attributs et opérations

90
Utilisation des diagrammes de collaboration

• Ils peuvent être attachés à
• Une classe
• Une opération
• Un use-case
• Ils sappliquent
• En spécification
• En conception (illustration de design patterns)

91
Eléments constitutifs

• Un contexte contenant les éléments mis en jeu
  durant lopération
• Un acteur
• Un ensemble dobjets, dattributs et de
  paramètres
• Des relations entre ces objets
• Des interactions
• Des messages
• Un message initiateur du diagramme provenant dun
  
• Acteur de lapplication,
• Objet de lapplication.
• Les numéros de séquence des messages échangés
  entre les objets de cet ensemble suite au message
  initiateur

92
Représentation dune collaboration (niveau
instance)
Marie
Pierre
père
mère
Fred
93
Equivalent au diagramme de séquence
Marie
Fred
cashRequest(25)
cashReceived(25)
94
Syntaxe graphique

• Les messages
• Opérations
• Réception dévénements
• Le séquencement
• Les séquences consécutives
• Les séquences imbriquées

séquence imbriquée
originePoint
message initiateur
1.1 position ( )
4
Segment
1 (i1..4)afficher ( )
numéro de séquence
1.2 position ( )
boucle
destinationPoint
opération
95
Questions auxquelles répondent les collaborations

• Quel est lobjectif ?
• Quels sont les objets ?
• Quelles sont leurs responsabilités ?
• Comment sont-ils interconnectés ?
• Comment interragissent-ils ?

96
Collaboration Niveau Spécification Définition
du ClassifierRole

• A ClassifierRole is a named slot for an object
  participating in a Collaboration.
• Object behavior is represented by its
  participation in the overall behavior of the
  Collaboration.
• Object identity is preserved through this
  constraint
• "In an instance of a collaboration, each
  ClassifierRole maps onto at most one object."

97
Collaboration de Niveau Spécification un exemple
simple
/ Mère
/ Père
père
mère
/ Enfant
98
Modélisation UML

• Modélisation selon 4 points de vue principaux
• Vision utilisateur du système
• Cas dutilisation
• 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 dactivités
• Vision implantation
• Diagramme de composants et de déploiement

99
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 dun objet ou
  dune 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)

100
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
101
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).

102
Les événements

• Les événements sont considérés comme des objets

signal IO_EVENT time
signal USER_INPUT device
signal NETWORK_EVENT
...
...
...
signal MOUSE_EV
signal KEYBD_EV
location
103
Typologie dévénements

• Réalisation dune condition arbitraire
• transcrit par une condition de garde sur la
  transition
• Réception dun signal issu dun autre objet
• transcrit en un événement déclenchant sur la
  transition
• Réception dun appel dopé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

104
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
User_input / mise_sous_tension
Veille
Allumé
délai_mise_en_veille / passage_en_mode_veille
action
105
Notion détats

• Etat situation stable dun objet parmi un
  ensemble de situations pré-définies
• conditionne la réponse de lobjet à 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

106
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

107
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
Téléphone raccroché
activité
108
Exemple de diagramme d'états

• un téléphone

Timeout do/ timeout tone
Compose numéro (n)
Actif
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é
Libre
Dialogue
Sonnerie do/ sonne
Appelant raccroche/ déconnexion
Réponse de lappelé/ autorise parole
109
Émission dévénements

• Automate détats dune télécommande double
• TV MAGNETOSCOPE

Contrôle distant
MAGNETOSCOPE
contrôle TV
contrôle MAGNETO
TV
bouton marche signal ON/OFF
signal ON/OFF
Télévision
Arrêt
Marche
110
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 

111
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
Montée
112
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.

113
Modélisation UML

• Modélisation selon 4 points de vue principaux
• Vision utilisateur du système
• Cas dutilisation
• 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 dactivités
• Vision implantation
• Diagramme de composants et de déploiement

114
Les diagrammes dactivité

• Traitements effectués par une opération
• Description dun flot de contrôle procédural
• Réseau dactions et de transitions automate
  dégénéré
• La transition seffectue lorsque lopé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)

115
Etat-action et décision

• Etat-action raccourci pour un état où il y a
• une action interne
• au moins une transition sortante
• production dun événement implicite action
  accomplie
• Pas de production/réaction à des événements
  explicites
• Modélisation dune étape dans l'exécution dun
  algorithme
• Notation
• Décision branchement sur plusieurs transitions
• Notation

obtenir un gobelet
coûtlt50
coûtgt50
116
Exemple de diagramme dactivité
opération PréparerBoisson de la classe Personne

pas de café
pas de soda
déterminer boisson
demande café
demande soda
obtenir une canette de soda
ajouter de leau dans le réservoir
mettre le café dans le filtre
obtenir un gobelet
mettre le filtre dans la machine
infuser
boire
verser café
117
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
118
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 dactivités associés aux
  opérations/transitions/méthodes
• Les modèles dynamiques d'une classe sont transmis
  par héritage aux sous-classes

119
Modélisation UML

• Modélisation selon 4 points de vue principaux
• Vision utilisateur du système
• Cas dutilisation
• 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 dactivités
• Vision implantation
• Diagramme de composants et de déploiement

120
Diagrammes dimplantation

• 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 dun réseau physique

121
Exemples de composants
Synonymes
Dictionnaire
Vérificateur
Interfaces
Composants
122
Exemple de déploiement
MachineServeur
MachineClient1
Noeuds
MachineClient2
123
Modélisation UML

• Modélisation selon 4 points de vue principaux
• Vision utilisateur du système
• Cas dutilisation
• 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 dactivités
• Vision implantation
• Diagramme de composants et de déploiement

124
Processus de développement avec UML
?