Unified Modeling Language - PowerPoint PPT Presentation

Loading...

PPT – Unified Modeling Language PowerPoint presentation | free to view - id: 2a873f-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Unified Modeling Language

Description:

Les 9 vues d'un mod le UML. Use Cases, diagrammes de classes, mod les dynamiques, packages... Un acteur peut repr senter un tre humain, un autre syst me, ... – PowerPoint PPT presentation

Number of Views:195
Avg rating:3.0/5.0
Slides: 125
Provided by: iri5
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
?
About PowerShow.com