Transcript UML - Free

Unified Modeling Language
Plan du cours
Caractéristiques de l’objet
1.
1.
Modes de développement
Les activités du projet
Généralités sur UML
Diagrammes Cas d’utilisation
2.
3.
4.
1.
2.
Etude d’opportunité
Analyse des besoins
Modélisation logique structurelle
5.
1.
2.
3.
Objets
Classes
Architecture
2
Plan du cours
Modélisation de la dynamique
6.
1.
2.
3.
4.
Diagramme
Diagramme
Diagramme
Diagramme
de séquence
de communication
d’activité
Etat-Transition
Modélisation de l’implémentation et du déploiement
7.
1.
2.
Diagramme de composant
Diagramme de déploiement
3
Caractéristiques de l ’objet
PPourquoi le développement objet?
CComment atteindre ces buts?
QQuelles répercussions sur les méthodes
de développement?

4
Caractéristiques de l ’objet
Pourquoi le développement objet?
Pourquoi le développement objet?
Comment atteindre ces buts?
Quelles répercussions sur les
méthodes de développement?
RRéutilisation
DDiminution des coûts de développement et
de maintenance
FFlexibilité et robustesse du logiciel
QQualité
5
Caractéristiques de l ’objet
Comment atteindre ces buts?
Pourquoi le développement objet?
Comment atteindre ces buts?
Propriétés de l’objet
Quelles répercussions sur les
méthodes de développement?
Encapsulation
Abstraction
Héritage
Polymorphisme
6
Caractéristiques de l ’objet


La brique de base d’un logiciel objet est la classe
Cette classe est un module qui contient des données
(attributs) et les traitements qui manipulent ces
données (opérations = méthodes)
classe
Commande
7
Caractéristiques de l ’objet
Il existe des contraintes de visibilité entre les classes,
donc entre les objets
Un objet ne peut avoir accès aux
propriétés d’un autre objet que
selon certaines conditions définies
dans le programme
retour
8
Caractéristiques de l ’objet
Un objet est une instance de classe
Tous les objets d’une même classe se décrivent
avec les mêmes attributs et ils ont le
même comportment
Commande
Référence
Date cde
Ref devis
Créer
Modifier Ref devis
9
Quelles répercussions sur
Les méthodes de développement?
Pourquoi le développement objet?
Comment atteindre ces buts?
Quelles répercussions sur les
méthodes de développement?
LLe développement incrémental
LLe développement agile
LLa réutilisation
10
Modèle de développement
Modèle en cascade
Modèle incrémental
Analyse des
besoins
Analyse des besoins
Analyse du
problème
Analyse du problème
Conception de la solution
Implémentation
Déploiement
Implémentation
Déploiement
retour
Conception de
la solution
11
Modèle de développement
Avantages du modèle incrémental



L’implication et la satisfaction de
l’utilisateur
La gestion des risques
L’intégration progressive
12
Les activités du projet
Elles sont identiques quelque soit le
modèle:
Cascade, incrémental….
14
Activités du projet
Opportunité
Analyse
du besoin
Analyse du problème
Conception de la
solution
UML est un langage de modélisation
Toutes ces activités du projet ont
une part de modélisation.
Modélisation
•Du problème
•De la solution
Implémentation
15
Activités du projet
Gestion de projet
Opportunité
Analyse
du besoin
Analyse du problème
Conception de la
solution
Implémentation
Chaque activité donne lieu a un
rapport qui contient les modèles
et des commentaires.
Chaque rapport est écrit ou validé
par le client
Le rapport d’étude d’opportunité +
rapport d’analyse des besoins
+ la V1 du plan projet
constituent le cahier des charges
Le cahier des charges est un
élément essentiel du contrat
16
Activités du projet
Documents fondamentaux
Gestion de projet
Rapport
d’ Étude d’opportunité
Plan
projet
Cahier
des
charges
Rapport
d’Analyse du besoin
17
Les activités du projet
Etude d’opportunité
On souhaite construire un système
informatique pour répondre à un besoin
 Qui a ce besoin?
 Quel est-il?
 Est-il justifié?
 Bilan gains-coûts estimés
On modélise le périmètre du projet et
son contexte
Opportunité
Analyse
du besoin
Analyse du problème
Conception de la
solution
Implémentation
18
Les activités du projet
Etude d’opportunité
Diagramme de contexte
Etudes
Gestion des stocks
Gestion de
production
Client
L’ellipse représente le périmètre du projet
Les acteurs représentent les systèmes ou
les personnes qui échangent des
informations avec le projet
Commercial
19
Les activités du projet
Analyse des besoins
Opportunité
Analyse
du besoin
Analyse du problème
Exprimer les
fonctionnalités demandées
au système d’information
+autres besoins (performance,
sécurité, flexibilité…)
Conception de la
solution
Implémentation
20
Les activités du projet
Analyse des besoins
On modélise l’architecture de l’expression des besoins
et les acteurs
Le domaine de l’étude est découpé selon les fonctions
requises par les acteurs
Cas d’utilisation
Ma gestion des
commandes
Ma gestion des
stocks
Pour chaque cas d’utilisation, on rédige un texte qui
énonce les exigences de la maîtrise d’ouvrage
21
Les activités du projet
Analyse du problème
Opportunité
Analyse
du besoin
Analyse du problème
Conception de la
solution
Exprimer la structure
(Entités; données)
et la dynamique
( Processus detraitements)
du système désiré
Indépendamment de la technologie
Implémentation
22
Les activités du projet
Analyse du problème
Modéliser le
métier
Entités
Acteurs
Commande
Chef des
ventes
Client
Ventes
Entrepôt
Enregistrer
la commande
Contrôler Commande
Processus
Préparer
commande
Expédier Commande
Commande annulée
Commande expédiée
23
Les activités du projet
Conception de la solution
Opportunité
Analyse
du besoin
Analyse du
problème
Conception
de la solution
Implémentation
Déterminer l’architecture
technique.
Prendre en compte la
technologie (conception
structurelle et dynamique)
Ne jamais concevoir avant
d’analyser
24
Les activités du projet
Conception de la solution
Modélisation logique structurelle
Modéliser l’architecture technique (structurer le logiciel)
Isoler les solutions techniques qui évoluent indépendamment
Paquetage
IHM
Métier
Accès
Réseau
Accès
Base D
25
Les activités du projet
Modélisation logique structurelle
Architecture technique




Le découpage du logiciel est représenté par des
paquetages
Les paquetages contiennent des classes, des composants
ou d’autres paquetages.
La visibilité entre les paquetages est limitée (classe façade)
Une bonne architecture permet la fiabilité et la flexibilité
du logiciel
26
Les activités du projet
Modélisation logique dynamique
Que fait le système informatique?
C Comportement des objets
D
C
Demandes de service
Conditions
Objet
Commande
[s’il y a du stock]
Réserver un article
Contrôle stock
Article
réservation
J’ai réservé
27
Les activités du projet
Chronologie
Etude d’opportunité ou Initialisation

Définition et opportunité du projet






Diagramme de contexte
Recueil et spécification des besoins.
Fonctionnalités du système d’information

Cas d’utilisation
Analyse du problème
Étude de la logique du système d’information
(Indépendant des technologies)

Modélisation métier (vue logique)
Activité de gestion de projet
pendant toute la durée du projet
Conception de la solution
Décisions technologique

Affinement de la vue logiques
Implémentation (Programmation, diagramme de composants)
Déploiement (Diagramme de déploiement)
28
Généralités sur UML

Origine

Standard

Objectifs

Outils

Contenu
.
30
Généralités sur UML
Origine
Origine
Standard
Objectifs
Issue des méthodes objet de:
 Grady Booch
 OMT de James Rumbaugh
 OOSE d’Ivar Jacobson
Contenu
31
Généralités sur UML
Standard
Origine
Standard
Objectifs




UML est une notation standard
Contenu
Elle a été acceptée par l’OMG (Object Management
Group), en novembre 97
Un dispositif est en place à l’OMG qui permet
d’améliorer UML de façon continue
L’OMG est un consortium international, il réunit
environ 800 entreprises. Son but est de définir des
standards pour le développement orienté objet
32
Généralités sur UML
Objectifs
Origine
Standard


Modélisation des systèmes informatiques
 Analyse des besoins
 Analyse du problème
 Conception de la solution
 Implémentation , Déploiement
Objectifs
Contenu
UML est une notation graphique.
Une notation permet de décrire le système
informatique avec des concepts adaptés et non ambigus.
33
Généralités sur UML
Objectifs
UML est une notation non une méthode


Une méthode contient non seulement une notation
mais aussi une démarche de projet
Plusieurs démarches peuvent être associées à la
notation UML.
Nota: Ne pas confondre les concepts de
démarche et les concepts UML
34
Généralités sur UML
Objectifs
UML est bien adapté à la démarche itérative
Analyse des
besoins
Implémentation
Déploiement
Analyse
du problème
Conception
de la solution
35
Généralités sur UML
Objectifs
UML permet la modélisation du système d’information et du
système informatique
Et il aide:
 à la réalisation
 à la réflexion
 À la documentation
Un modèle est une représentation
schématique de la réalité
destiné à montrer son fonctionnement
Il deviendra peut-être un langage
de réalisation (MDA)
36
Généralités sur UML
Objectifs

Outils UML





Rational Rose
Together
Objectory (Softeam)
Visio …
Les outils






Permettent la modélisation (dessin et contrôle)
Gèrent un référentiel
Produisent le squelette des programmes
Produisent les DDL des SGBDR
Produisent les interfaces des ORB (Object Request Broker)
Se relient à d’autres outils de développement
37
Généralités sur UML
Contenu: Éléments
Origine
Standard


UML propose des éléments
de modélisation qui ont une définition
sémantique et un graphisme
Objectifs
Contenu
Exemples
Composant
Acteur
Gestion
articles
Client
Classe
raisonSociale
calculerRemise
Paquetage
Métier
38
Généralités sur UML
Contenu: Diagrammes
UML propose 9 types de diagrammes (règles de
combinaison des élément standards):
Cas d’utilisation
Classes
Objets
Séquence
Collaboration
Activité
États-Transitions
Composants
Déploiement
39
Généralités sur UML Contenu:
Diagrammes
Exemple: Diagramme de classe
Commande
1..*
1
Client
facturer()
ClientDétaillant
ClientGrossiste
40
Généralités sur UML Contenu:
Extension de la notation: stéréotypes




UML est une méthode ouverte
Les stéréotypes permettent l’extension
Un stéréotype est une variante d’un élément standard,
il hérite de sa sémantique, il spécifie souvent un rôle.
Exemple:
Une façade,un acteur sont des stéréotypes de classe
Client
Client
«Entité »
Représentation
graphique
Représentation
textuelle
Chef des ventes
« Acteur »
41
Diagrammes:
Cas d’utilisation
Étude
d’opportunité
Représentation du contexte du système

Définir les Limites du système à développer

Relations entre le système et son environnement.
Gestion de
production
Gestion
financière
Gestion
commerciale
Direction
Bureau
d’étude
43
Diagrammes:
Cas d’utilisation



Étude
d’opportunité
Gestion commerciale représente le périmètre de l’étude
Les acteurs sont des personnes ou des systèmes en
relation avec le domaine de l’étude.
Les acteurs sont extérieurs au domaine de l’étude.
Gestion de
production
Gestion
financière
Gestion
commerciale
Direction
Bureau
d’étude
44
Diagrammes:
Cas d’utilisation
Analyse
des
besoins
Pour:
 Structurer fonctionnellement le domaine pour décrire les
exigences

Répartir le travail et les responsabilités pour la
spécification et la validation des besoins.
Analyse
marges
des
Directeur
commercial
Fidélisation
Commissions
Chef des
ventes
Responsable
CRM
45
Les cas d’utilisation
Validation
Contrat
Les cas d’utilisation guident la
MOE dans l’analyse, la
conception, la réalisation et les
tests.
Ils sont sous la
responsabilité de la MOA,
ils sont la référence des
validations et recettes.
Recette
46
Les cas d’utilisation
Opportunité
Analyse
Périmètre du projet
du besoin
Analyse
L’analyse des besoins
du problème
de la solution
Conception
Validation
de la solution
La conception du système
Implémentation
Mise en oeuvre
Tests
47
Cas d’utilisation



Chaque cas d’utilisation est accompagné d’un
texte et éventuellement de diagrammes
Ceux-ci expriment les exigences du client
Les exigences constituent une partie du
contrat entre le client (maîtrise d’ouvrage) et
les développeurs (maîtrise d’œuvre)
48
Cas d’utilisation
Exemple de rédaction










Titre: Préparation de la commande fournisseur
But: Déterminer la date de passation de commande
Version, date de rédaction
Auteur de la rédaction
Acteurs du cas d’utilisation: acheteur
Préconditions:
Les demandes d’achat sont valides, elles ont été affectées à l’acheteur
qui initialise le processus.
Postcondition:
La date de passation de commande de la DA est prévue
Événement initial:
Affectation des DA nouvellement arrivées à un acheteur
Description du scénario de base
Description des flots alternatifs
49
Diagrammes:
Cas d’utilisation. Acteurs
Commissions




Chef des
ventes
Le domaine du projet est découpé en cas d’utilisation
Chaque cas d’utilisation représente une fonction du
système informatique dont un acteur métier a besoin
Un acteur métier est un rôle.
Dans la démarche: on recherche d’abord les acteurs
métier puis les fonctions dont ils ont besoin.
50
Diagrammes:
Cas d’utilisation. Acteurs
Chef des ventes
51
Diagrammes:
Cas d’utilisation.

Le cas d’utilisation spécifie la façon dont le
système est utilisé pour aider un client ou un
utilisateur à atteindre ses objectifs. Il décrit
un processus.
52
Cas d’utilisation
Spécifications de besoins, exigences
Chaque cas d’utilisation donne lieu à une
description en texte




Le texte doit être bien structuré
Il est sous la responsabilité de l’utilisateur
Il peut être accompagné de diagrammes UML
Il décrit ce que doit faire le système et non
comment
Rédaction des exigences
53
Cas d’utilisation
Spécifications de besoins, exigences

Le cas d’utilisation décrit un processus métier

Le processus est déclenché par un événement métier


Il se termine par un résultat intéressant pour l’utilisateur ou
par un échec
Il comporte souvent plusieurs scénarios
Evénement
Tâches
Résultat
54
Diagrammes:Cas d’utilisation



Chaque cas d’utilisation est accompagné d’un
texte et éventuellement de diagrammes
Ceux-ci expriment les exigences du client
Les exigences constituent une partie du
contrat entre le client (maîtrise d’ouvrage) et
les développeurs (maîtrise d’œuvre)
55
Cas d’utilisation
Exemple de rédaction










Titre: Passation de la commande au fournisseur
But: Transmettre une commande valide au fournisseur
Version, date de rédaction
Auteur de la rédaction
Acteurs du cas d’utilisation: acheteur
Préconditions:
Les demandes d’achat sont valides, elles ont été affectées à l’acheteur
qui initialise le processus.
Postcondition:
La commande est transmise, sa transmission est enregistrée
Événement initial:
Affectation des DA nouvellement arrivées à un acheteur
Description du scénario de base
Description des flots alternatifs
56
Diagramme de cas d’utilisation
Relations
Les cas d’utilisation peuvent être fractionnés.
Puis reliés.
 relation « include »
 relation « extend »
 relation « generalise »
Nota: Les flux d’informations sont
indiqués dans d’autres diagrammes
57
Cas d’utilisation
Relation « include »
Permet d ’identifier des sous-ensembles
communs à plusieurs cas d ’utilisation
comptable
« include »
« include »
Contrôle adhérent
Règlement cotisations
Accueil
Inscription activité
Contrôle adhérent est extrait de « Règlement cotisation » et de
« Inscription activité » afin de ne le décrire qu’une fois
58
Cas d’utilisation
Relation « include »
Gestion des
notes de frais
« include »
Gestion force
de vente
Chef des
ventes
Gestion des notes de frais est aussi utilisé dans une autre application,
on ne le décrit qu’une fois
La relation entre les 2 cas d’utilisation est exprimée dans le texte de
Gestion des forces de vente
Include est un stéréotype d’un autre élément: la dépendance
59
Cas d’utilisation
Relation « extend »
Accueil
« include »
contrôle adhérent
Inscription activité
Permet de décrire séparément
certaines partis alternatives,
optionnelles ou exceptionnelles
« extend »
extension
Inscription activité inexistante
60
Cas d’utilisation
Relation « extend »
L‘extension ne peut être
activée directement
Texte: La relation est indiquée
dans le cas extension, ici
inscription activité inexistante
L‘extension peut être planifiée
dans un autre incrément que
le cas d’utilisation de base
« include »
contrôle
adhérent
Accueil
Inscription activité
« extend »
Inscription
activité inexistante
61
Cas d’utilisation
Relation généralisation

Plusieurs cas d’utilisation ont le même but

Ils ont des fonctionnements différents, Ce
sont les variantes d’une même fonction.
62
Cas d’utilisation
Relation Généralisation
comptable
Règlement cotisations
« Généralisation »
Règlement par courrier
Règlement par Internet
adhérent
63
Exercice
Faire le modèle de cas d’utilisation
correspondant aux fonctions suivantes:


Contrôle des commandes client (la saisie des
commandes est faite chez le client par le
commercial ou au siège à partir d’un formulaire)
Réception des règlements
Dans ces 2 cas l’identité du client est contrôlée

Traitement des anomalies commandes
Le contrôle des commandes est sous la responsabilité
du commercial ou de l’administration des ventes.Le
comptable est responsable de la réception des
règlements
Exercice
Modèle de cas d’utilisation
Commercial
Prise de commande
chez client
Contrôle identité client
<<include>>
<<généralisation>>
<<include>>
Contrôle commande
Réception règlement
Comptable
<<extend>>
Administration
ventes
Saisie commande
au siège
Traitement anomalies
commandes
66
Cas d’utilisation
Traiter le passage en caisse
exemple
Traiter le passage en caisse
Caissier
Titre : Traiter le passage en caisse
Résumé : un client arrive à une caisse avec des articles qu’il souhaite
acheter. Le caissier enregistre les achats et récupère le paiement. A la fin
de l’opération, le client part avec les articles.
Acteurs : principal caissier, secondaire client.
Pré conditions : la caisse est ouverte (donc en service) ; un caissier y est
connecté
Post conditions: Le client a payé, la vente est enregistrée, le ticket de
caisse a été donné au client.
67
Description du flot de base :
1.
Ce cas d’utilisation commence quand un client arrive à la caisse avec des articles
qu’il souhaite acheter.
2.
Le caissier enregistre chaque article. S’il y a plus d’un exemplaire par article, le
caissier indique également la quantité.
3.
La caisse détermine le prix de l’article et ajoute les informations sur l’article, à
la vente en cours. La caisse affiche la description et le prix de l’article en
question.
4.
Après avoir enregistré tous les articles, le caissier indique que la vente est
terminée. La caisse calcule et affiche le montant total de la vente.
5.
Le caissier annonce le montant total au client.
6.
Le client choisit le type de paiement :
En cas de paiement cash, calculer la monnaie à rendre
7.
La caisse enregistre la vente effectuée et imprime un ticket.
8.
Le caissier donne le ticket de caisse au client.
9.
Le client s’en va avec les articles qu’il a achetés.
retour
Pour éviter les Si dans le flot de base
Les flots alternatifs sont décrits à part
Flot alternatif 1: numéro d’identification inconnu
Cette alternative démarre au point 2 du flot de base.
- La caisse indique au caissier que le numéro d’identification de
l’article est inconnu. L’article ne peut alors être pris en compte dans la
vente en cours.
Le flot de base reprend au point 2.
Flot alternatif 2 : client ne pouvant pas payer
Cette alternative démarre au point 6 du flot de base.
- Le client ne peut payer le total avec aucun moyen de paiement
autorisé.
- Le caissier annule l’ensemble de la vente et le cas d’utilisation se
termine en échec (post condition non réalisée)
Flot alternatif 3: client payant par chèque
Cette alternative remplace le point 6 de la version de base.
Le chèque est mis par le caissier dans le lecteur de chèque qui imprime le
montant et la date
Le caissier fait signer le chèque.
Le flot de base reprend au point 7
Les pointeurs sont écrits dans les flots
alternatifs et non dans le flot de base
Exercice
Faire le cas d’utilisation de paiement par carte en créant un cas
d’utilisation extension
71
Cas d’utilisation paiement par carte
Ce cas d’utilisation remplace le point 6 du cas d’utilisation: « Traiter le
passage en caisse ». En cas de succès, le flot reprend au point 7; en cas d’échec
il reprend au point 6 de « Traiter le passage en caisse »
Flot de base
1. Le client insère la carte dans le lecteur de carte et saisit son code
Flot alternatif échec: Le code saisit est faux 3 fois de suite
à la suite du point 1
« extend »
Traiter le passage en caisse
Caissier
Payer par carte
Exemple
Diagramme cas d’utilisation
Le diagramme de cas d’utilisation montre le comportement d’un
système, les services visibles de l’extérieur, fournis par le système
dans le contexte de son environnement
Exemple: Téléphone mobile
Passer appel
téléphonique
Réseau
mobile
Recevoir appel
« extend »
« extend »
Passer appel
conversation à 3
Recevoir nouvel
appel
Utiliser
agenda
Utilisateur
74
Modélisation logique structurelle
Diagramme de classe
Architecture
du système d’information
du système informatique
Objets
Classes
Paquetages

75
Modélisation structurelle
Les objets
Un objet est « une chose »
qui peut être parfaitement
identifiée; une personne
précise, une organisation,
une machine ou un
événement peuvent être
considérés comme des
objets.
76
Modélisation structurelle
Les objets


Un objet peut sauvegarder des valeurs,
ces valeurs ont un nom (nom d’attribut)
.Ces valeurs constituent l’état de l’objet.
l’état de l’objet peut changer
77
Modélisation structurelle
Les objets
Un objet offre des
opérations (son
comportement)
qui permettent
d’examiner ou de
modifier son
état.
L’état d’un objet
garde le souvenir de
l’exécution des
opérations
78
Modélisation structurelle
Les objets
Un objet est une instance de classe
3 représentations possibles d’un objet:
Valérie
Valérie: Personne
: Personne
Date embauche =12-07-76
nom de l’objet
nom de l’objet ,
nom de la classe
Objet anonyme
79
Modélisation structurelle
Les Classes
Les objets sont groupés en ensembles appelés classes.
Les objets sont des instances de classe.
Salarié
nom
Poste
salaire
Lili:Salarié
Instance de
nom:Lili
poste:DRH
3000 euros
payer()
80
Modélisation structurelle
Les classes
Une classe est une
abstraction qui
représente l’idée ou la
notion générale que l’on
peut avoir d’un
ensemble d’objets
similaire
Par exemple tous les
salariés d’une
entreprise appartiennent
à la classe « Salarié »
Tous les objets d’une classe
partagent les mêmes
attributs, le même
comportement et les
mêmes associations.
Tous les salariés ont un
salaire, chaque mois ils
touchent leur salaire, ils
travaillent pour une
entreprise.

81
Modélisation structurelle
Les Classes



Pendant la phase d’analyse une classe est un
concept du monde réel (ex : salarié, adhérent, prime)
Pendant la phase de conception elle peut être un
concept technique (ex : pilote d’imprimante,
fenêtre…) elle est affinée par des notions techniques
(ex: visibilité)
Pendant la phase d’implémentation une classe est un
élément du logiciel
82
Modélisation structurelle
Les Classes
Chaque classe est représentée sous la forme d’un
rectangle divisé en 3 compartiments. Le 1er
compartiment contient le nom de la classe, le second
les attributs et le 3ème les opérations
Personne
adressePrincipale
nom
facturer ()
Analyse
Conception
83
Modélisation structurelle
Les Attributs


Chaque nom d’attribut peut être accompagné de
détails facultatifs tels que le type ou la valeur par
défaut.
Le type et la valeur par défaut seront généralement
mentionnés à partir de la phase de conception.
Personne
Nom : chaine
Age : entier
Solvabilité : Booléen=1
Conception
84
Modélisation structurelle
Les attributs dérivés
Un attribut dérivé peut être calculé à partir
d’autres attributs
On le trouve:

soit dans le compartiment attribut précédé
d’une barre oblique
 soit dans le compartiment opération
C’est un choix de conception
Rectangle
Longueur
Largeur
/ Surface
85
Modélisation structurelle
Les opérations
Une opération spécifie une action qu’un objet doit exécuter
Une méthode est une procédure qui implémente une opération
Généralement

En phase d’analyse, on écrit seulement le nom de l’opération

En phase de conception on écrit




La visibilité
Les paramètres
Le type de retour
La portée
86
Modélisation structurelle
Les opérations
« entité »
Portée de
classe
Personne {auteur=Rémi}
adresse
nom
solde
Portée
d’instance
créer
Facturer ( remise : Int = 0, montant : Int ) : montantDu
87
Modélisation structurelle
La visibilité
UML définit 3 niveaux de visibilité pour les attributs et les
opérations



+
Public qui rend l’élément visible à tous les clients de
la classe ·
#
Protégé qui rend l’élément visible aux sous-classes
de la classe
—
Privé qui rend l’élément visible aux opérations de
la classe seule
88
Modélisation structurelle
La visibilité
Client
— nom
— adressePrincipale
— enregistrer()
#
facturer()
+ consulter nom()
89
Modélisation structurelle
Les relations




L’association
La généralisation
La dépendance
La réalisation
90
Modélisation structurelle
L’association
Il existe des liens entre les objets
Exemple:
Les commandes sont liées aux clients
Client
raisonSociale
Commande
Passe >
1
*
dateCommande
91
Modélisation structurelle
Multiplicité
Un objet peut être relié à plusieurs objets:
Un client peut être relié à plusieurs commandes.
Mais une commande ne peut être reliée qu’a un seul
client
et elle est nécessairement reliée à un client.
Ces contraintes expriment la multiplicité d’une
classe dans sa relation avec une autre ou avec
elle-même
92
Modélisation structurelle
La multiplicité s’écrit :
1
0..1
* ou 0..*
1..*
m..n
toujours 1
0 ou 1
0 à plusieurs
1 à plusieurs
de m à n (entiers naturels)
93
Modélisation structurelle
Classes d’association


Chaque lien de l’association est relié à un objet de la classe association.
Chaque objet de la classe association est identifié par les références aux
classes reliées ; Il ne peut y avoir plusieurs liens entre les mêmes objets

On indique cette classe si le lien est porteur d’attributs ou d’opérations .

Une classe d’association peut être associée à d’autres classes
Personne
nom
*
**
Diplôme
niveau
DiplômeObtenu
date obtention
exercice
94
Modélisation structurelle
Rôle


Un rôle décrit la part prise par une classe dans une
association, il est écrit sur l’association du coté de la
classe correspondante
Le rôle permet de distinguer plusieurs associations
entre les 2 même classes
Personne
nom
résident
1
*
Ville
travailleur
*
*
95
Modélisation structurelle
Associations qualifiées
Le qualificatif permet de retrouver 1 ou n objets à l’autre
bout de l’association il sélectionne certains objets)
Nom de fichier est un identifiant relatif pour Fichier
Sans le qualificatif la
multiplicité serait *
Répertoire
Banque
1
Nom de fichier
*
1
1
compte
Fichier
Personne
96
Modélisation structurelle
Associations qualifiées
Exercice
Comment modéliser les chambres d’une
chaîne d’hôtels en indiquant que les hôtels
ont la liberté de leur numérotation
97
Hôtel
1
N°Chambre
1
Chambre
1
Personne
Autre exemple
Société
*
Matricule
Emploi
Salaire
Modélisation structurelle
Contraintes d’intégrité sur association
Les contraintes d’intégrité sont de format
libre, elles sont écrites entre accolades
Statue
{ ou
Musée
exclusif }
Site
Commune *
1
*
habitant
Personne
*
Conseiller
municipal
Sous-ensemble
100
Modélisation structurelle
Association réflexives
Un objet d’une classe peut être associé à
un autre objet de la même classe
chef
Personnel
1
collaborateur 1..*
101
Modélisation structurelle
Associations n-aires
Des associations peuvent relier plus de 2 classes
Joueur
Année
Équipe
Record
Gain
Un record est identifié par
une équipe, un joueur,
une année
102
Exercice : Gestion des représentations d’un théâtre
Construire un diagramme de classes à partir des données
suivantes :
N° place
Nom catégorie
Prix place
Date de représentation
Nom spectacle
Nom du metteur en scène
Nom acteur principal
Nom agence
Adresse de l’agence
N° de téléphone agence
N° billet
Nom du pompier de service
Heure de représentation
Date prise réservation
Suite
Respecter les règles de gestion suivantes
•Le théâtre propose des spectacles joués en une ou plusieurs
représentations.
Pour chaque spectacle, sont annoncés le nom du metteur en scène et du ou
des acteurs principaux.
•Le théâtre peut offrir plusieurs représentations le même jour.
•Plusieurs spectacles peuvent être joués le même jour.
En revanche, un seul spectacle est joué par représentation.
•
Suite
•Les agences de spectacles sont contractuellement autorisées à
réserver des places par avance. Les autres clients doivent faire des
achats fermes.
•Pour chaque place, à chaque représentation est attribué un billet lors
de la vente.
•Le prix de la place est fonction de la catégorie de la place, et de la
représentation
Représentation
Tarif
Prix place
*
Billet
num billet
metteur en scène
1
0..*
Acteur
1..*
*
*
réserver
Réservation
vendre
1..*
Date réservation
*
*
Catégorie
Place
1
principal
Spectacle
Date représentation
Heure représentation *
*
Agence
0..*
1
Modélisation structurelle
L’agrégation


L’agrégation est une forme particulière d’association
qui exprime un couplage plus fort entre classes.
L’agrégation permet de représenter les relations de
type maître esclave, tout et partie, ou composé et
composant.
Mission
*
Développeur
Agrégation simple
108
Modélisation structurelle
Agrégation de composition



L’agrégat « possède » ses parties,
Les partie sont « à l’intérieur » de l’agrégat ; Un
objet ne peut être l’élément de plusieurs agrégats.
La destruction de l’agrégat entraîne la destruction
des parties
Commande
datCom
1
1..*
LigneDeCommande
quantitéCommandée
Article
*
1 référenceArticle
préparer
Agrégation de composition
109
Exercice
Un médecin veut modéliser des
informations concernant ses patients,
leurs consultations, leurs maladies.
110
Exercice
Patient
1
Nom
0..*
Consultation
Date
0..*
Atteint de
0..*
Maladie
Nom
112
Modélisation structurelle
Généralisation et spécialisation
La généralisation consiste à factoriser les éléments
communs (attributs, opérations, relations) d’un
ensemble de classes dans une classe plus générale
appelée super-classe.
Les sous-classes héritent des caractéristiques de leur
super-classe
113
Modélisation structurelle
Généralisation et spécialisation
Exemple:
Super-classe
Sous-classe
Banque
Code
Tiers
raisonSociale
Client
facturer()
Fournisseur
régler()
Fournisseur et client héritent de raison sociale et de l’association à banque
facturer est spécifique à Client; régler est spécifique à Fournisseur
114
Modélisation structurelle
Généralisation et spécialisation
Tiers
raisonSociale
Exemple:
Client
Code
Fournisseur
facturer()
ClientNat
Banque
régler()
ClientExport
Devise
TypeCrédit
115
Modélisation structurelle
Généralisation et spécialisation
Exercice
Une société d’archéologie vous demande de faire son diagramme de
classe
Elle étudie des objets archéologiques, ces objets appartiennent à
une nation; ils peuvent être des bâtiments, des statues ou des
bijoux.
Tous ces objets peuvent se trouver dans un site, les statues et les
bijoux peuvent se trouver dans un musée.
Les bijoux peuvent aussi se trouver chez un particulier.
On dispose d’informations sur les nations, les sites et les particuliers.
116
Exercice
Site
Objet
0..1
Nation
*
1
ObjetMobile
Bâtiment
Statue
Code
Musée
*
0..1
Bijou
*
0..1
Particulier
Modélisation structurelle
Contrainte d’intégrité sur généralisation
Objet
Objet
{Ou exclusif}
Statue
{complétude}
Bijou
Un objet archéologique ne
peut pas être à la fois une
statue et un bijou
Statue
Bijou
Un objet archéologique ne
peut être qu’une statue ou un
bijou
119
Modélisation structurelle
Classe abstraite
Une classe abstraite ne peut être instanciée, ses sous-classes sont
concrètes
Classe abstraite
Activité
nom activité
montant
Toutes les classes ont des
propriétés spécifiques
planifier ()
Classe concrète
{complétude}
Tennis
lieu
planifier()
Foot
Entraineur
planifier()
120
Modélisation structurelle
Représentation de l’architecture
L’architecture est la description des différentes
parties du système et de leurs relations
Une bonne architecture doit permettre:
 La réutilisation
 La répartition du travail entre équipes
 L’étude d’impact lors des changements fonctionnels,
techniques et d’explitation
121
Modélisation structurelle
Représentation de l’architecture
UML offre des notations destinées
 à découper



Le système d’information
Le logiciel
À isoler les éléments du logiciel
122
Représentation de l’architecture
Les Paquetages
Un paquetage est un conteneur
il permet de représenter l’organisation
du système d’information
et du logiciel.
Il peut contenir tous les éléments
de modélisation :
des classes, des interfaces,
des composants, des nœuds,
des cas d’utilisation, des diagrammes,
d’autres paquetages…
123
Représentation de l’architecture
Les Paquetages
Chaque élément est la propriété directe d’un
paquetage unique.
Le paquetage forme un espace de nommage

Les paquetages sont représentés dans le
diagramme de classe

124
Modélisation structurelle
Représentation de l’architecture
Architecture technique
 1 paquetage= n éléments
 1 composant=1 ou n classes
Métier
paquetage
Commande
classe
Gestion
articles
composant
125
Modélisation structurelle
Représentation de l’architecture
Les Paquetages
livraison
Classe livraison
appartient à vente
Le paquetage vente
appartient à commercial
Classe non visible
à l’extérieur du
paquetage
commercial
article
(from stock)
(from vente)
Commercial::Vente
+ commande
+ client
— livraison
stock
+stockFaçade
_article
_ entrepôt
dépendance
java.io
Paquetages leur contenu et leurs dépendances
126
Modélisation de la dynamique
du système

Diagrammes d’interaction


Diagramme de séquence
Diagramme de communication

Diagramme d’activité

Diagramme État-Transition
127
Modélisation de la dynamique
du système
Les diagrammes d’interaction et d’activité
précisent le texte du cas d’utilisation
Lors de l’analyse des besoins,ils
expriment les interactions entre les
utilisateurs (acteurs) et le système.
Lors de l’analyse-conception,
ils expriment les interactions
entre les objets du système
Texte
Cas d’utilisation
flot de base
Flots alternatifs
n diagrammes
de séquence
n diagrammes
d’activité
Diagramme
de classe
128
Modélisation de la dynamique
Diagramme de séquence


Un diagramme de séquence représente un ou
plusieurs scénarios d’un cas d’utilisation (cas
d’utilisation parent)
Pour un cas d’utilisation, il peut y avoir autant de
diagrammes de séquence qu’il y a de scénarios
129
Modélisation de la dynamique
Diagramme de séquence




Le diagramme de séquence transforme la structure
fonctionnelle, décrite par le cas d’utilisation en une
structure objet
Il représente les messages que les objets doivent
s’échanger pour réaliser la fonction.
Ces messages sont des appels d’opérations ou de
groupes d’opérations. Ils sont effectués par des objets
vers des objets.
Les objets sont des acteurs ou des objets logiciels.
130
Modélisation de la dynamique
Diagramme de séquence
Un objet de la classe
activité
Acteur
: activité
: adhérent
: Accueil
Message
La flèche est dans le sens du
flux de contrôle
Demande inscription activité
inscription
Demande supplément cotisation
Période d’activité de
l’objet
Paiement
Ligne de vie de l’objet
retour
131
Modélisation de la dynamique
Diagramme de séquence
Un objet ou un participant peut être anonyme,
identifié, qualifié
: adhérent
Anonyme
Martin : adhérent
adhérent actif
Identifié
Qualifié
: adhérent
L’objet adhérent appartient
à la classe adhérent
Adhérent est
ici un objet du
logiciel
132
Modélisation de la dynamique
Diagramme de séquence, concepts
Scénario
Un diagramme de séquence représente un ou
plusieurs scénarios
(flot de base, flots alternatifs).
On peut représenter l’ensemble des scénarios d’un cas
d’utilisation avec 1 ou plusieurs diagrammes de
séquence
Acteur
Un acteur déclenche un scénario (il a été identifié
dans le cas d’utilisation parent)
133
Modélisation de la dynamique
Diagramme de séquence, concepts
Événements (ou messages)
Un diagramme de séquence montre les messages
que les objets s’échangent.
 Ces messages sont des événements :
 Ils déclenchent des opérations sur les objets
destinataires

Ligne de vie

La durée de vie d’un objet est matérialisée
par une ligne verticale pointillée.
134
Modélisation de la dynamique
Diagramme de séquence
Exercice
Faire le diagramme de séquence correspondant à cet extrait du cas
d’utilisation Règlement cotisations
Suite à un appel de cotisation (qui a été fait longtemps avant et qui, par
conséquent est décrit dans un autre cas d’utlisation) les adhérents paient leur
cotisation, le paiement est enregistré, les appels de cotisation correspondants
sont mis à jour, un accusé de réception est retourné à l’adhérent
Paiement
Adhérent
Règlement cotisations
AppelCotisation
Quelles interactions
doit-il y avoir entre
les objets de ces
classes pour réaliser
le cas d’utilisation:
Règlement de
cotisation?
135
Modélisation de la dynamique
Diagramme de séquence
unPaiement
: Adhérent
paiement
unAppel
Cotisation
cotisation
accuséRéception
137
Client
: Client
théatre :
Activité
: Spectacle
:
Représentation
: Place
Paiement
Contrôle client
[client pas OK]
Contrôle
activité
[activité pas OK]
Flot de contrôle
Flot d’informations
[Réservation
OK]
Le flot d’informations est facultatif
Il revient par le chemin inverse du flot de contrôle
Les messages sont synchrones par défaut
retour
Diagramme de séquence
Représentation des paramètres
: Client
Client
Paramètres
Client est un
objet logiciel
stéréotype
entité
Opération
Demande réservation(code client,code activité)
Le nom de l’opération peut être accompagné de ses paramètres
139
Diagramme de séquence,
Représentation de plusieurs scénarios
Par un cadre d’interaction
Un appel cotisation
Un paiement
adhérent
paiement
cotisation
Qualité du montant
Alt
Accusé réception
Avis solde
[Si montant OK]
[Else]
140
Diagramme de séquence,
Représentation de plusieurs scénarios
Exercice
Found message=
la source du message est indéterminée
A la réception de la commande:
le service commercial doit la contrôler
Si elle n’est pas correcte, l’annuler
Si elle est correcte,
Faire le bon de livraison
Faire la facture
Dans tous les cas mémoriser son état
service
commercial
Recevoir la
commande
141
service
commercial
Recevoir la
commande
Commande
Livraison
Facture
Contrôler
Alt
Refuser
[Commande pas OK]
Livrer
[else]
Facturer
Enregistrer l’état
Diagramme de séquence,
Représentation d’une itération
Par un cadre d’interaction
Jardinier
Plantoir
Sol
15 octobre
Prendre
loop
[Pour chaque bulbe]
Creuser
Placer
Ranger
Bulbe
Diagramme de séquence,
Représentation d’une itération
A la réception de la commande:
le service commercial doit la contrôler
Il saisit la commande
Il contrôle que chaque article est en stock
Sinon, il annule l’article
Si la commande est OK
Il fait la facture
145
service
commercial
Recevoir la
commande
Commande
Article
Saisir
loop
[Pour chaque article]
En stock?
Annuler l’article
[Article pas OK]
Facturer [Commande OK]
Facture
Modélisation de la dynamique
Diagramme de communication
1. paiement
:Paiement
2:cotisation
: Adhérent
: Appel cotisation
Le diagramme de communication
est une autre forme de
diagramme d’interaction
148
Modélisation de la dynamique
Diagramme de communication
1. paiement
: Adhérent
Lien
:Paiement
2:cotisation
Correspondance avec
le diagramme de classe
Flux de contrôle
association
Message
: Appel cotisation
adhérent
nom adhérent
*
*
activité
nom activité
montant
séquence
149
Modélisation de la dynamique
Diagramme de communication
1. paiement
: Adhérent
Lien
Flux de contrôle
Message
: Appel cotisation
:Paiement
2:cotisation
Un lien est une connexion entre
objets, qui indique qu’une
forme de navigation et de
visibilité entre eux est possible,
c’est une intance d’association
150
Modélisation de la dynamique
Diagramme de communication
2: Contrôle client
1: Demande réservation
4: Contrôle activité
Client
théatre :
Activité
3: [client pas OK]
5: [activité pas OK]
: Client 15: [Réservation OK]
12:
14:
13:
6:
: Spectacle
11:
Paiement
10:
7:
: Représentation
9:
8:
: Place
Représentation proche du diagramme de classe
seqence
151
Diagrammes d’interaction
et démarche

Diagramme de séquence



Interactions entre les acteurs et le système (Analyse des
classe système
besoins)
Interactions entre les objets logiciels (Analyse du problème
et conception)
Diagramme de communication



Interaction entre les acteurs (Analyse des besoins)
Diagramme de flux (Analyse des besoins)
Interaction entre les objets logiciels
(Analyse du problème et conception)
(surtout s’il n’y a pas de chronologie ou si on veut montrer les liens
entre les objets)
152
Modélisation de la dynamique
Diagramme d’activité
Permet de représenter une logique
procédurale, un processus métier, un
workflow
On peut représenter le déroulement des
actions dans des chemins alternatifs ou
parallèles
153
Modélisation de la dynamique
Diagramme d’activité
Nœud initial
Enregistrer
la commande
Déroulement
séquentiel des
actions
d’’un processus
métier
Contrôler Commande
Action
Sortir article
Expédier Commande
Nœud final
154
Diagramme d’activité
Partitions
Client
Ventes
Entrepôt
Ressource
Enregistrer
la commande
Contrôler Commande
Workflow
Sortir article
Les partitions
représentent les
ressources qui
réalisent les actions
Expédier Commande
155
Diagramme d’activité
Décisions
Client
Ventes
Entrepôt
Contrôler Commande
OU
[OK]
Sortir article
Sortir article
[Pas OK]
Annuler
Commander
la commande
Expédier Commande
Chemins alternatifs
OU
Pour que l’action Enregistrer état
commande s’exécute, il suffit
q’une des actions précédentes soit
terminée
Enregistrer état
Commande
156
Modélisation de la dynamique
Diagramme d’activité
Exercice
Lorsque le réveil sonne, prendre le petit
déjeuner puis préparer le cartable (sauf
le mercredi) puis, dans tous les cas, se
laver
157
Sonnerie réveil
Déjeuner
mercredi?
oui
Se laver
non
Préparer
cartable
Les diagrammes d’activité
Barre de synchronisation
administration
Chemins
parallèles
Ventes
Entrepôt
Contrôler Commande
Contrôler Commande
Barre de
synchronisation
(fork)
[Pas OK]
[OK]
ET
Préparer
bon
Préparer
bon livraison
livraison
Barre de
synchronisation
(joint)
Préparer Commande
Commande expédiée
160
Les diagrammes d’activité
Barre de synchronisation
Chemins
parallèles
Explication du schéma précédent

Si le contrôle de la commande est satisfaisant (OK) on peut faire le bon de
livraison et préparer la commande, dans n’importe quel ordre successivement ou
parallèlement

Pour expédier la commande il faut que sa préparation soit terminée et que le
bon de livraison soit fait
161
Exercice lorsque le réveil sonne





Lorsque le réveil sonne, l’homme commence par prendre sa
douche.
Au sortir de la douche, il réveille sa femme et effectue sa
gymnastique
Ensuite, il prépare le petit déjeuner pour sa famille, et enfin
prépare la voiture pour le départ
La femme, à son réveil, fait sa toilette matinale, puis prépare les
cartables des enfants – sauf le mercredi – et enfin prend son
petit déjeuner avec les enfants.
Tout le monde se retrouve ensuite en voiture l’homme fait
l’inspection finale et la mise en route.
162
Homme
Femme
Sonnerie réveil
Exercice
Douche
Gym
Toilette
Mercredi?
[ Non ]
Préparation
petit déjeuner
Préparation
voiture
Famille en route
Inspection et
mise en route
Préparation
cartable
Petit
déjeuner
[ Oui ]
Les diagrammes d’activité
Décomposition d’une action
Les actions peuvent être décomposées
en sous-activités.
On peut ainsi décrire un processus
globalement puis l’affiner
progressivement
165
Réception
commande
Exécution
commande
Envoi facture
Livrer
Le rateau signifie
que l’action est
décomposable en
sous activités
Traitement
paiement
Clore
l'ordre
Livrer
Livraison
normale
Exécution
commande
Clore
l'ordre
Livraison
urgente
Exercice
Détailler l’exercice: « lorsque le réveil
sonne »
Pour préparer le petit déjeuner l’homme sort les
ingrédients
Si le café manque, il prend du thé.
Il prépare soit le thé soit le café
Il dresse la table
Gym
Homme en forme
Préparation petit déjeuner
Sortir
ingrédients
Préparer
café
Préparer thé
Dresser la
table
Préparation
voiture
Petit
déjeuner
Les diagrammes d’activité
Invocation d’une méthode
Dans une action, on peut invoquer une
méthode
Livrer
Livraison
normale
Clore
l'ordre
Exécution
commande
Ordre::SuppressOrder
Livraison
urgente
Nom de
la
classe
Nom de
la
méthode
170
Les diagrammes d’activité
Signaux

Signal temporel
Une activité écoute ces signaux en
permanence, ils constituent un
événement d’un processus extérieur, le
diagramme définit comment l’activité
réagit à ces événements
171
Signal
temporel
2 heures
avant le vol
Faire les
bagages
Partir pour
l'aéroport
Signal
accepté
Taxi
arrive
Je ne pars à l’aéroport que si mes bagages sont faits et si le taxi
est arrivé
L’action Partir pour l’aéroport accepte le signal Taxi arrive
Une action peut aussi émettre des signaux
Réserver
l’itinéraire
Signal
accepté
Itinéraire
confirmé
Retenir
itinéraire
Envoyer
l’itinéraire
Signal
émis
Annuler
itinéraire
Attendre 48 heures
Exercice
Une commande Fournisseur est rédigée
puis envoyée
A la réception de l’accusé de réception,
la commande est validée.
Si 2 semaines après l’envoi de la
commande, l’accusé de réception du
fournisseur n’est toujours pas parvenu,
la commande est annulée
Rédiger
commande
Accusé de
réception
Commande
validée
Envoyer
commande
Annuler
commande
Attendre
2 semaines
Région d’expansion
Une région d’expansion délimite dans
un diagramme d’activité une zone ou
les actions s’exécutent une fois pour
chaque élément d’une collection
177
Choisir un
thème
Ecrire
l’article
Région
d’expansion
Relire
l’article
« concurrent »
On écrit n article, chacun est relu.
Les différents articles peuvent être écrits en même temps
Publier
la revue
Exercice
Contrôle d’une commande:
On contrôle le client
On contrôle l’existence et la présence en stock de chaque article
Si tout est correct, on établit une facture
Sinon on refuse la commande
Contrôle client
Existence de
l’article
Contrôle stock
de l’article
Etablir
la facture
Modélisation de la dynamique
Les diagrammes d’activité

Activités et flot d’objets


Dans un diagramme d’activité, il est possible de
faire apparaître clairement les objets créés,
détruits ou modifiés, par une activité. .
Les objets modifiés sont indiqués par des flèches
en pointillé.
Etablir Devis
D : Devis
[établi]
Commander
181
Modélisation de la dynamique
Les diagrammes d’activité
Activités et flots d’objets
Client
Ventes
Entrepôt
Enregistrer
la commande
commande
[contrôlée]
Contrôler Commande
[OK]
Décision
Préparer
commande
commande
[préparée]
[Pas OK]
Expédier Commande
Commande annulée
Commande expédiée
182
Modélisation de la dynamique
Diagramme État-Transition Concepts

État



Un objet passe par différents états au cours de
son existence
Un état est une situation au cours de la vie d’un
objet pendant la quelle il satisfait certaines
conditions, exécute certaines activités ou répond à
certains événements
L’état d’un objet est matérialisé par la valeur de
certains de ses attributs et par ses liens
184
Modélisation de la dynamique
Diagramme État-Transition Concepts
Transitions
Une transition
représente le passage
d’un état à un autre
Événements
Un événement est
un stimulus qui
peut déclencher
une transition
d’état
185
Modélisation de la dynamique
Diagramme état-transition
Le diagramme d’états-transitions représente:



Les différents états possibles d’un objet
Les opérations qui peuvent être exécutées dans cet
état
Les événements qui provoquent des transitions d’un
état à un autre.
186
Diagramme état-transition
commande
Etat initial
Evénement déclencheur
prise en compte commande
Opération longue
Durée de l’état
commande en enregistrement
Événement qui ne change
pas l’état
entry: contrôle client
do: contrôle article
Urgence / priorité
exit: décision
Opération courte
pendant l’état
condition
[ non ]
[oui ]
Activité
commande invalide
Envoi d’événement
commande valide
entry: mise en attente
exit/^: bon de préparation
[ stock OK ] / ordre de servir
Opération courte pendant
la transition
Commande refusée
commande servie
Etat final
Modélisation de la dynamique
Diagramme état-transition
Plusieurs types d’opérations:

Une opération longue ou activité
se prolonge autant que dure l’état
est précédée de la mention do:

Opérations courtes ou actions
pratiquement sans durée:
188
Modélisation de la dynamique
Diagramme état-transition
Opérations courtes ou actions, pratiquement sans
durée:



Précédées de entry lorsqu’elles s’exécutent au
moment ou l’objet entre dans le nouvel état
Précédées de exit lorsqu’elles s’exécutent au moment
ou l’objet sort d’un état
Précédées de:

/ lorsqu’elles sont déclenchées par un événement
189
Modélisation de la dynamique
Diagramme état-transition Conditions


Les conditions sont encadrées par des
crochets
Une condition peut avoir une certaine durée
alors qu’un événement est instantané
Condition:Je sors si le temps est beau
Événement: s’il se met à pleuvoir, je
rentre
190
Modélisation de la dynamique
Diagramme état-transition
Exercice
Monter le diagramme d’états-transitions
représentant les différents états que
peut prendre, au sens de l’état civil, la
classe INDIVIDU
191
Exercice
Jugement de divorce
Contrat de
mariage signé
MARIÉ
DIVORCÉ
Contrat de mariage signé
Décès
individu
Décès conjoint
VEUF
Contrat de mariage signé
Naissance
CÉLIBATAIRE
iDécès individu
Contrat PACSE signé
Contrat PACS
signé
Contrat PACSE signé
PACSÉ
Rupture contrat
DÉCÉDÉ
Modélisation de la dynamique
Diagramme état-transition Sous- état


Un sous- état est un état emboîté dans
un autre état.
Un état composé peut contenir soit des
sous-états concurrents, soit des sousétats séquentiels
194
Modélisation de la dynamique
Diagramme état-transition Sous-état
Sous-état séquentiel
Plante en croissance
do: Arroser
Plante non mure
Plante à maturité
on
Disponibilité[
Disponibilité[
temps
temps
favorable
favorable
] / ]:
Récolter
Récolter
Plante récoltée
195
Modélisation de la dynamique
Diagramme état-transition Sous-état
Plante semée
Plante en hibernation
Plante en croissance
Plante récoltée
Bonne pratique
On fait d’abord un diagramme global, pour avoir une vision d’ensemble,
puis on affine en recherchant les états emboîtés.
196
Modélisation de la dynamique
Diagramme d’états concurrents et synchronisation
Emission
Préparation
For
k
do: Distribuer billets
exit: billets pris
do: éjecter carte
exit: carte prise
Prêt à initialiser
join
t
Ce distributeur de billets fournit les billets ou la carte dans un ordre
indifférent
197
La modélisation de l’implémentation
Les Composants



Les composants sont des éléments physiques comme
les exécutables, les composants Com, les EJB, les
bibliothèques, les tables, les fichiers et les documents
Un composant peut réaliser une interface définie
dans le modèle logique
Généralement, les services d’un composant sont
disponibles uniquement à travers leur interface
198
La modélisation de l’implémentation
Les Composants, organisation



On peut regrouper les composants en
paquetages
Les composants sont des éléments de la
gestion de configuration.
On détermine les composants à partir des cas
d’utilisation et des postes de travail. Les
composants sont distribués sur les postes de
travail
199
La modélisation de l’implémentation
Les Composants
La distribution des composants permet un
découplage entre les applications et le métier
et facilite

La réutilisation

La maintenance

La flexibilité
200
La modélisation
……………….…...
de
l’implémentation
Développement par composants
On créé un système à partir de composants,
On le fait évoluer


En ajoutant de nouveaux composants
En remplaçant les anciens
Sans avoir à reconstruire le système
grâce aux interfaces
201
La modélisation de l’implémentation
Diagramme de composants
Livraison
Servir
Le composant Servir
contient les classes
Article et Entrepôt
disponibilité
<<Interface>>
disponibilité
Article
+contrôle stock()
+préparation()
+contrôle stock()
livraison
Entrepôt
+préparation()
interfaces
202
Modélisation du déploiement
Nœud
 Un nœud représente une ressource de calcul
 Un composant peut être déployé par un ou
plusieurs nœud
203
Diagramme de déploiement
Serveur
Client 1
« support »
Client 2
Livraison
Description des processus
De l’analyse des besoins à la conception
système
systè
: client
: végétal
: client
: sol
Le diagramme
de séquence
: plante
: commande
: client
client
: cotiser
Acheter
effectuez votre choix
type de végétal
pourquoi?(de l'ombre?des fruits?des fleurs?)
des arbres
nature du sol
idem
ensoleillement
idem
réponse
idem
Planche de fruits
des fruits
choix de fruit
idem
planche de fleurs
des fleurs
choix de fleurs
idem
planche de silhouettes
de l'ombre
choix de silhouette
idem
liste de choix possibles
retour
Diagramme de
séquence objet logiciel
Diagramme de
séquence système
206
Cas d’utilisation
1
1
1..*
Scénario
1..*
0..*
0..1
DiagrammeSéquence
Opération
système
système
systè
: client
effectuez votre choix
type de végétal
Diagramme
séquence système
Diagr. séquence
objets logiciel
pourquoi?(de l'ombre?des fruits?des fleurs?)
des arbres
nature du sol
idem
ensoleillement
idem
réponse
idem
Planche de fruits
des fruits
choix de fruit
idem
planche de fleurs
des fleurs
choix de fleurs
idem
planche de silhouettes
de l'ombre
choix de silhouette
idem
liste de choix possibles
Représentation du dialogue entre
l’acteur et le système.
On représente les flux de données
•Quelles données sont saisies
•Quelles données sont affichées.
•Eventuellement les traitements
importants effectués par le système.
Les opérations système
Exemple
: RespFormation
gestion Catalogue
:système
: RespFormation
creerFormation( )
initialiserFormation (titre, durée, prix)
Opérations système
creerContenu( )
creerContenu( audience, prerequis, objectifs, outils, plan )
creerSession()
creerSession(date debut, lieu)
Conseil
Un diagramme de séquence par fonction
(Créer, Modifier, Supprimer, Editer, ../)
Identifier les opérations système
:système
: Utilisateur
creerFormation( )
initialiserFormation (titre, durée, prix)
creerContenu( )
creerContenu( audience, prerequis, objectifs, outils, plan )
creerSession
creerSession(date debut, lieu)
:Système
creerFormation()
creerContenu()
creerSession()
creerFiliere()
modifierFormation()
modifierContenu()
modifierSession()
modifierFiliere()
…..
retour
209
210
Description des
données
Référence matière,
 Adresse de l'élève,
 Nombre d'heures,
 Nom de la classe,
 Nom de l'élève,
 Nom du professeur,
 Valeur de la note,
 Numéro de salle,
 Prénom de l'élève

retour
Règles de gestion
A
chaque classe est attribuée une
seule salle de cour
 Chaque
matière est enseignée par
un seul professeur
 Pour
chaque classe et chaque
matière est défini un nombre fixe
d'heures de cours
A
chaque élève est attribuée une
seule note par matière
 L'établissement
scolaire gère les
emplois du temps des
professeurs, des élèves et le
contrôle des connaissances.
212
Elève
nomElève
prénom élève
adresseElève *
appartient
1
0..*
*
Elève/Matière
ValeurNote
Classe
nomClasse
numéroSalle
1..*
Matière
référenceMatière
nomProfesseur
*
Classe/Matière
NombreDheures
214