2. Plan du cours
Objectifs de la formation
Introduction
Les cas d’utilisation
Concepts Objet
Le cœur d’UML
Diagramme de classe
Diagramme de séquence
Diagramme d’activité
Les packages
Diagramme états – transitions
Diagramme de composants
Diagramme de déploiement
Les activités de la méthode avec UML
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 2
3. Plan du cours
Objectifs de la formation
Introduction
Les cas d’utilisation
Concepts Objet
Le cœur d’UML
Diagramme de classe
Diagramme de séquence
Diagramme d’activité
Les packages
Diagramme états – transitions
Diagramme de composants
Diagramme de déploiement
Les activités de la méthode avec UML
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 3
4. Objectifs
Apprécier les intérêts de la modélisation visuelle
Savoir quels sont les diagrammes UML disponibles
Comprendre les objectifs de chaque diagramme UML
Comprendre comment sont modélisés les aspects statiques et
dynamiques d’un système informatique
Comprendre comment est organisé un modèle UML
Comprendre la syntaxe UML
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 4
5. Plan du cours
Objectifs de la formation
Introduction
Les cas d’utilisation
Concepts Objet
Le cœur d’UML
Diagramme de classe
Diagramme de séquence
Diagramme d’activité
Les packages
Diagramme états – transitions
Diagramme de composants
Diagramme de déploiement
Les activités de la méthode avec UML
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 5
6. Une certaine vision du monde…
Maison
+ superficie
1..* 1..*
Et age Por t e
+ numéro + largeur
Public class Maison {
private Vector etages;
private Vector portes;
private float superficie;
public Maison() { … }
…
}
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 6
7. Une certaine vision du monde…
Une maison est constituée de plusieurs étages. Chaque maison
possède au moins un étage. Une maison comporte un certain
nombre de portes, au moins une. Une maison est caractérisée par sa
superficie, chaque étage possède un numéro et chaque porte
comporte une largeur précise.
Maison
+ superficie
1..* 1..*
Et age Por t e
+ numéro + largeur
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 7
8. Objectifs d’une modélisation
Comprendre le fonctionnement du système
Maîtriser la complexité et la cohérence du système
Communiquer sans ambiguïté au sein de l’équipe
Permettre l’automatisation de certaines tâches
Accroître la qualité du produit livré
Faciliter la maintenance
Etre un outil de travail permettant de
Organiser les travaux de l’équipe de réalisation
Contrôler l’avancement des travaux
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 8
9. Points de vue – Niveau de détail
Plan de Modèle
circulation d’urbanisme
Ville
Modèle
Modèle d’équipement
de la population
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 9
10. Un langage commun
Nécessité de définir un langage commun pour modéliser
Sémantique précise des différents concepts
Notation graphique
Règles d’utilisation des concepts du langage
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 10
11. Origines d’UML
UML
Unification des concepts et des notations
Intégration des « meilleures pratiques »
Booch
OMT - 2 OOSE
’93
Standard géré par l’OMG
Version utilisée UML 1.5
Dernière version UML 2.0
http://www.omg.org
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 11
12. A quoi sert UML ?
UML est un langage pour
Comprendre et décrire un besoin de manière non ambiguë
Spécifier un système (simple ou complexe)
Concevoir une solution
Documenter la solution
Communiquer au sein d’une équipe
UML est à usage général
Système logiciel, matériel, organisation,..
Domaine bancaire, assurance, avionique, télécommunication…
Processus de développement en cascade, itératif…
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 12
13. Vision générale d’UML
Fonctionnel
Description des services
rendus par le système
Modéliser le problème
suivant 3 axes
Description comportementale Description structurelle du système
du système
Statique
Dynamique
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 13
14. Vision générale d’UML
Fonctionnel
Diagramme des cas d’utilisation
Modéliser le problème
suivant 3 axes
Diagramme d’objets
Diagramme de séquence Diagramme de classes
Diagramme de collaboration Diagramme de composants
Diagramme d’activité Diagramme de déploiement
Diagramme états - transitions
Statique
Dynamique
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 14
15. Plan du cours
Objectifs de la formation
Introduction
Les cas d’utilisation
Concepts Objet
Le cœur d’UML
Diagramme de classe
Diagramme de séquence
Diagramme d’activité
Les packages
Diagramme états – transitions
Diagramme de composants
Diagramme de déploiement
Les activités de la méthode avec UML
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 15
16. Les cas d’utilisation
A quoi servent-ils ? Pour quoi faire ?
Déterminer les frontières du système
Comprendre le fonctionnement du système du point de vue de
l’utilisateur
Représenter les interactions entre les utilisateurs et le système
Préparer la phase d’analyse des exigences
UML n’est pas suffisant ici, il est nécessaire d’ajouter:
Des descriptions textuelles
Détail du cas d’utilisation
Ajout des exigences non-fonctionnelles
Ajout des règles de gestion
Compléments aux éléments modélisés avec UML
Les besoins de restitution
Les écrans
L’éditique
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 16
17. Les cas d’utilisation
Les concepts UML manipulés sont
Diagramme de cas d’utilisation
Acteur
Déclencheur UC1
Acteur A
Récepteur
Act eur UC2
Cas d’utilisation Acteur B
UC3
Cas d' ut ilisat ion
Acteur C
Diagramme de contexte
Acteur A
Système
Acteur Y
Acteur X
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 17
18. Les cas d’utilisation
Définition : Acteur
Un acteur est une entité externe au système
Qui interagit avec le système
Qui attend des services de la part du système
Qui est une personne physique ou un autre système informatique
Un acteur est nommé par le rôle qu’il joue vis-à-vis du système
Les interactions avec le système sont représentées par des cas
d’utilisation
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 18
19. Les cas d’utilisation
Définition : Cas d’utilisation
Un cas d’utilisation modélise un service rendu par le système
Décrit des interactions entre un acteur et le système
Est déclenché par un événement émis par un acteur
Correspond à une unité d’intention complète de la part de l’acteur vis-à-
vis du système
Apporte une valeur ajoutée notable à l’acteur
Créer
compte
Chargé de Clientèle Créer un
client
Autoriser
Responsable d’agence crédit
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 19
20. Les cas d’utilisation
Contenu d’un cas d’utilisation
Le déroulement d’un cas d’utilisation est contrôlé par les acteurs
Les cas d’utilisation ne s’enchaînent pas !
Plusieurs acteurs peuvent participer à un cas d’utilisation
La dynamique d’un cas d’utilisation est décrite par une série de
scénarios
Scénario nominal ou scénarios alternatifs
Scénarios d’exception
Un scénario est une succession d’événements envoyés par l’acteur
au système et de réponses de la part du système
Fin anormale
Début Fin normale
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 20
21. Les cas d’utilisation
La Fiche Cas d’Utilisation
Un cas d’utilisation est
décrit textuellement par
une « Fiche Cas
d’Utilisation »
Dans le cadre d’Harmonie
un modèle de document
formalise la « Fiche Cas
d’Utilisation »
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 21
22. Les cas d’utilisation
Contenu de la Fiche Cas d’Utilisation
Nom du cas d’utilisation: Nom décrit sous forme de verbe à l’infinitif, suivi d’un
complément.
Résumé : Résume l’intention du cas d’utilisation. Peut être utilisé au début du
processus d’identification des cas d’utilisation.
Valeur ajoutée : Ce qu’apporte les cas d’utilisation pour l’acteur (les acteurs)
déclencheur d’un point de vue métier.
Acteurs : Acteurs participant (déclencheurs et récepteurs) à la réalisation du cas
d’utilisation
Pré-conditions : Ce qui doit être vrai au niveau du système pour pouvoir
déclencher le cas d’utilisation
Scénarios : Description textuelle des échanges entre acteurs et système
Post-conditions : Ce qui a changé dans le système une fois le cas d’utilisation
terminé avec succès ou échec
Vision synthétique : Diagramme d’activité résumant le cas d’utilisation
Règles de gestion : Règles applicables au cas d’utilisation
Contraintes opérationnelles : Exigences non fonctionnelles associées au cas
d’utilisation
Besoins de restitution : éléments de restitution (écrans ou rapports d’édition)
associés au cas d’utilisation
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 22
23. Les cas d’utilisation
Exemple : GAB
Cas d’utilisation : Retirer de l’argent
Retirer de
Acteur : Porteur de carte l’argent
Porteur de carte
Pré-conditions
Aucune carte n’est dans le lecteur
De l’argent est disponible
Post-conditions de succès
Le GAB a été débité du nombre de billets correspondant
au montant retiré
Post-conditions d’échec
Le GAB n’a pas délivré les billets demandés par le porteur
de carte
Le GAB a avalé la carte du porteur
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 23
24. Les cas d’utilisation
Exemple : GAB
Scénario nominal
1- Le porteur de carte introduit sa carte dans le lecteur de cartes du GAB
2- Le GAB vérifie que la carte introduite est bien une carte
3- Le GAB demande au porteur de carte de saisir son code d’identification
4- Le porteur de carte saisit son code d’identification
5- Le GAB compare le code d’identification avec celui codé sur la puce de la
carte
6- Le GAB demande une autorisation au système d'autorisation
7- Le système d'autorisation donne son accord et indique le solde
hebdomadaire.
8- Le GAB demande au porteur de carte de saisir le montant désiré du retrait
9- Le porteur de carte saisit le montant désiré du retrait.
10- Le GAB contrôle le montant demandé par rapport au solde hebdomadaire
11- Le GAB demande au porteur de carte s'il veut un ticket
12- Le porteur de carte demande un ticket
13- Le GAB rend sa carte au porteur de carte
14- Le porteur de carte reprend sa carte
15- Le GAB délivre les billets et un ticket
16- Le porteur de carte prend les billets et le ticket
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 24
25. Les cas d’utilisation
Exemple : GAB
Scénarios alternatifs
A1 : code d’identification erroné
L’enchaînement A1 démarre au point 5 du scénario nominal.
5.1 Le GAB indique au client que le code est erroné, pour la première ou deuxième fois
5.2 Le GAB enregistre l’échec sur la carte
Le scénario nominal reprend au point 3
A2 : montant demandé supérieur au solde hebdomadaire
L’enchaînement A2 démarre au point 10 du scénario nominal.
10.1 Le GAB indique au client que le montant demandé est supérieur au solde
hebdomadaire
Le scénario nominal reprend au point 3
Scénario d’exception
E1 : code d’identification erroné
L’enchaînement A1 démarre au point 5 du scénario nominal.
5.1 Le GAB indique au client que le code est erroné, pour son troisième essai
5.2 Le GAB enregistre l’échec sur la carte
5.3 Le GAB avale la carte.
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 25
26. Plan du cours
Objectifs de la formation
Introduction
Les cas d’utilisation
Concepts Objet
Le cœur d’UML
Diagramme de classe
Diagramme de séquence
Diagramme d’activité
Les packages
Diagramme états – transitions
Diagramme de composants
Diagramme de déploiement
Les activités de la méthode avec UML
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 26
27. Concepts Objets
Pourquoi une approche objet ?
Approche Fonctionnelle Approche Objet
Fonction Conduire
Pilote
principale
Avion
Sous-fonction 1 Sous-fonction 2
Dirige atterrisage
Sous-fonction Sous-fonction Sous-fonction Sous-fonction Tour de
1.1 1.2 2.1 2.2
contrôle
• Besoin d’identifier toutes les fonctions dès le • Approche par « morceau »
début
• Décomposition du problème
• La « fonction » induit la structure (difficulté
• Adaptation / Évolution du système plus facile
de faire évoluer l’architecture)
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 27
28. Concepts Objets
Les avantages d’une approche objet
Décomposition du « problème » en morceaux plus facilement
gérables
Décomposer / diviser pour comprendre
Composer / réunir pour construire
Intégration/Tests
Intégration de composants élémentaires
Cohérence des éléments intégrés
Facilité d’évolution et de maintenance
Ajout/Evolution de fonctionnalités plus faciles à intégrer
Etude d’impact plus facile
Les points forts:
Construction du complexe à partir de l’élémentaire
Capacité à regrouper ce qui est séparé
Intégrer statiquement et dynamiquement les constituants du système
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 28
29. Concept objet
Définition: Objet
Exemple d’objets:
Pierre Duval Sophie Durand
Les caractéristiques communes qui les qualifient diffèrent selon le domaine d’étude.
Une représentation physique
Taille Une représentation sociale
Pointure Métier
Couleur des yeux Fonction
… Salaire
…
Mais ces personnes physiques ont une identité propre. Ce sont des objets de leur domaine d’étude
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 29
30. Concept objet
Définition: classe
Une classe est une représentation abstraite d’un concept qui existe dans un domaine modélisé
Une classe est un descripteur d’objet
Le monde Entreprise
Salarié
Personne
Est une classe
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 30
31. Concepts objet
Définition : Objet
Un objet est caractérisé par
Une identité (unique)
Un état (porté par la valeur de ses attributs et ses liens
avec les autres objets)
Un comportement
L’exécution d’un système repose sur la collaboration
entre les objets qui le composent
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 31
32. Concepts objet
Définition : Classe
Abstraction = modèle
Concessionnaire
Domaine d’étude = Monde réel
Modélisation
Voiture
Est une classe
Voiture
Modélisation
Moteur Réservoir
Production
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 32
33. Concepts objet
Définition : Classe
Les objets d’une même classe (on parle d’instances de la classe)
possèdent la même définition
Attributs (valorisés par chaque objet)
Opérations
Relations
De manière individuelle, chaque objet
Possède ses propres valeurs pour les différents attributs
Possède ses propres liens avec les autres objets
Peut réaliser telle ou telle opération en fonction de son propre état
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 33
34. Concepts objet
Classe et Objets
La classe Voiture Des objets Voiture
Nom de la classe
Voiture la voiture de Paul
- couleur: bleu
- couleur - marque: Renault
Attributs - marqu - vitesse: 0
- vitesse
e
la voiture de Pierre
+ demarrer ( ) - couleur: verte
+ tourner ( ) - marque: Peugeot
- vitesse: 45
Opérations + accelerer ( )
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 34
35. Concepts objet
Classification
Objectif
Factoriser des données ou des traitements communs
Rendre spécifique un comportement
Classification = généralisation et spécialisation
Généralisation : regroupement des caractéristiques communes à plusieurs classes dans
une super-classe plus générale
Spécialisation : Ajout de caractéristiques spécifiques dans une sous-classe ou
adaptation des caractéristiques transmises
Moyen de transport
- vitesse maximum
- nombre de passagers
+ démarrer ( )
Vélo Bateau
- nombre de vitesses - tirant d'eau
+ changer de vitesse ( ) + jeter l'ancre ()
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 35
36. Les diagrammes UML
Diagramme de cas d’utilisation Diagramme de séquence Diagramme de classes
<<interface>> implements <<maître>> <<caractéristiques>>
uc1 I_composant M_composant Classe C
Objet 1 Objet 2 Objet 3 Objet 4 +Service A -Attribut a
-Attribut b
Acteur 1 +Service B
+Service C
+Service D
-Attribut c
-Attribut d
Classe A Classe B
Acteur 1 -Attribut e -Attribut f
uc2 <<rôle>>
R_classe G
+Opération a
+Opération b
-Attribut g
+Opération c
+Opération h 0..1 nom m 1..* nom n
uc3 <<rôle>>
R_classe E
<<rôle>>
R_classe F nom o * Classe D
uc4
Acteur 2 Acteur 3 /Attribut i
+Opération d -Attribut h
+Opération i +Opération f +Opération g
Etat 4
entry/ action
exit/ action
Etat 5
Diagramme d’activités Diagramme d’objets
Diagramme d’états
Activité 1
Etat 2
entry/ action
Objet 1 nom a Objet 2 : classe a
do/ activity
Etat 3
nom b
nom c
Activité 2 Activité 3 décision Activité 4 Objet 3 : classe a
Objet 4 nom d
Activité 5 Activité 6 nom e nom f Objet 5
Acteur 1
Objet 6
message 3
Etat 1
Etat 6
Diagramme de collaboration
Diagramme de composants Diagramme de déploiement
Composant 1
Objet 3 message 4 Objet 2
Nœud 1 « base de données »
message 1
BD 1
Composant 1
Composant 2
message 5
message 2
Noeud 2
Composant 3
Objet 4
Objet 1
Composant 2
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 36
message
37. Plan du cours
Objectifs de la formation
Introduction
Les cas d’utilisation
Concepts Objet
Le cœur d’UML
Diagramme de classe
Diagramme de séquence
Diagramme d’activité
Les packages
Diagramme états – transitions
Diagramme de collaboration
Diagramme de composants
Diagramme de déploiement
Les activités de la méthode avec UML
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 37
38. Diagramme de classes
Objectifs
A quoi cela sert ? Pour quoi faire ?
Modéliser les données (étape préparant la réalisation du MLD et MPD)
Définir les traitements applicables aux objets d’une classe
Objectifs
Modéliser les relations structurelles entre les classes
Obtenir un diagramme statique des entités impliquées
Représenter un point de vue sur le modèle
Diagramme de classes
<<interface>> implements <<maître>> <<caractéristiques>>
I_composant M_composant Classe C
-Attribut a
+Service A
-Attribut b
+Service B
-Attribut c
+Service C
-Attribut d
+Service D Classe A Classe B
-Attribut e -Attribut f
-Attribut g
<<rôle>> +Opération a
R_classe G +Opération b +Opération c
+Opération h nom m nom n
0..1 1..*
<<rôle>> <<rôle>>
*
R_classe E R_classe F nom o Classe D
/Attribut i -Attribut h
+Opération d
+Opération i +Opération f +Opération g
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 38
39. Diagramme de classe
association 1 Banque
- nom
Client
- nom *
- adresse 1
< appartient à
titulaire 1..* Compte
- numero
- solde
rôle
+ crediter()
+ débiter()
Entreprise Particulier
- numeroSiret - prenom
- /age
- ageMajorite multiplicité
•1 Nombre d’instances d’une
•0..1 classe qui peuvent être
•0..* ou * mises en relation avec une
seule instance de la classe
•1..*
associée
•1..4, 8
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 39
40. Plan du cours
Objectifs de la formation
Introduction
Les cas d’utilisation
Concepts Objet
Le cœur d’UML
Diagramme de classe
Diagramme de séquence
Diagramme d’activité
Les packages
Diagramme états – transitions
Diagramme de composants
Diagramme de déploiement
Les activités de la méthode avec UML
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 40
41. Diagramme de séquence
Objectifs
A quoi cela sert ? Pour quoi faire ?
Identifier les traitements (quoi faire)
Identifier l’appelant et l’appelé de chaque traitement (qui appelle qui)
Objectifs
Permet de décrire une interaction entre des objets
Objets = acteurs, système, instance de classe
Les objets s’envoient des messages afin de réaliser une tâche déterminée
Met en avant l’enchaînement chronologique des messages
Objet 1 Objet 2 Objet 3 Objet 4
Acteur 1
Diagramme de séquence
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 41
42. Diagramme de séquence
Object1 : Actor1 Object2 Object3 Object4
Axe du temps
1 : message1
Objet
2 : message2
3 : message3
Message 4 : message4
Retour
Note permettant de
commenter des séquences
optionnelles 5 : destroy « self »
Message
S'il le faut 6 : message5 ( param1 )
Objet détruit
Ligne de vie
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 42
44. Plan du cours
Objectifs de la formation
Introduction
Les cas d’utilisation
Concepts Objet
Le cœur d’UML
Diagramme de classe
Diagramme de séquence
Diagramme d’activités
Les packages
Diagramme états – transitions
Diagramme de composants
Diagramme de déploiement
Les activités de la méthode avec UML
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 44
45. Diagramme d’activités
Objectifs
A quoi cela sert-il ? Pour quoi faire ?
Décrit le comportement interne d’une opération
Donne une vision procédurale d’activités
Utiliser pour décrire:
un algorithme
une règle de gestion
la vision synthétique des scénarios d’un cas d’utilisation
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 45
46. Début du « workflow » Diagramme d’activités
Représentation UML
Rôle 2 Rôle 1 Rôle 3
Possibilité de
« Swimlane » Activité 1 Une activité décomposer des activités
Permet de préciser les responsables
des activités
Activité 2
« Fork »
Activité 3 Activité 3bis
« Join »
Condition
Décision [ Résultat OK]
Activité 4
Dossier X Objet résultat de l’activité
ou modifié par l’activité
Fin du « workflow»
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 46
47. Diagramme d’activités
Exemple: « Achat d’un café dans un distributeur »
Début du « workflow » Choisir une boisson
Mettre le café dans le Remplir le réservoir
Prendre une tasse
Une activité filtre d'eau
Mettre le filtre dans
la machine
Mettre la machine en
marche
Mélanger le café
Verser café
Fin du « workflow»
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 47
48. Plan du cours
Objectifs de la formation
Introduction
Les cas d’utilisation
Concepts Objet
Le cœur d’UML
Diagramme de classe
Diagramme de séquence
Diagramme d’activité
Les packages
Diagramme états – transitions
Diagramme de composants
Diagramme de déploiement
Les activités d’analyse et de conception avec UML
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 48
49. Packages
A quoi cela sert-il ? Pour quoi faire ?
Organiser la modélisation
Faciliter la maintenance et les évolutions
Faciliter l’analyse d’impact
Faciliter le travail en équipe
Objectifs
Permettre d’organiser les éléments d’un modèle en les
regroupant
(Similaire au classement de fichiers dans des répertoires sur un disque)
Découper la problématique du système à réaliser en grands
« domaines »
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 49
50. Packages – Règles de construction
Chaque package doit posséder des critères d’appartenance
précis et non ambigus (critères fonctionnels souvent retenus)
Un élément de modélisation appartient à un et un seul package
Le nom complet d’un élément d’un modèle est nomPackage::nomElement
Un package peut contenir d’autres packages
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 50
51. Packages
Package « Client » contenant
les éléments de modélisation
UML relatifs au concept Client.
client
Dépendance inter-packages
contrat compte
Préférer des packages faiblement couplés et fortement cohérents
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 51
52. Packages
Un « bon » découpage d’un modèle en package permet de mieux
Planifier le travail
Organiser la modélisation (l ’architecture !)
Faire de l’analyse d’impact
Isoler des anomalies
Faciliter la maintenance et les évolutions
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 52
53. Plan du cours
Objectifs de la formation
Introduction
Les cas d’utilisation
Concepts Objet
Le cœur d’UML
Diagramme de classe
Diagramme de séquence
Diagramme d’activité
Les packages
Diagramme états – transitions
Diagramme de composants
Diagramme de déploiement
Les activités de la méthode avec UML
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 53
54. Diagramme états-transitions
Un diagramme d’états-transitions est une représentation du cycle
de vie d’un objet
Etat 4
Etat 5
entry/ action
exit/ action
Etat 3
entry/ action
do/ activity
Diagramme d’états
Etat 1
Etat 6
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 54
55. Diagramme états-transitions
Il permet de spécifier entre autres :
Les différents états de la vie d’un objet
Etat = une période durant la vie d’un objet caractérisée par :
– Valeur des différents attributs
– Attente par l’objet d’un certain nombre d’événements
– Réalisation éventuelle d’une activité
Les événements pouvant être reçus dans chaque état
Ils matérialisent le flot d’informations échangé
Les transitions d’état à état autorisées
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 55
56. Diagramme d’états: exemple
Diagramme d’états de la classe Cours
Début du cycle de vie
Etat
Ouvert aux inscriptions
Initialisé ouverture aux inscriptions /
Proposer cours sur le site entry/ Initialiser com pteur
entry/ Initialiser cours event dem ande d'inscription/ Inscrire ; incrémenter compteur
annulation du cours
[ Com pteur = Max ou Date lim ite atteinte ]
annulation du cours
Activité
Fermé aux inscriptions
Annulé
entry/ Cloturer les inscriptions
entry/ Avertir étudiants inscrits annulation du cours
do/ Finalis er cours
Etat final Transition
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 56
57. Plan du cours
Objectifs de la formation
Introduction
Les cas d’utilisation
Concepts Objet
Le cœur d’UML
Diagramme de classe
Diagramme de séquence
Diagramme d’activité
Les packages
Diagramme états – transitions
Diagramme de composants
Diagramme de déploiement
Les activités de la méthode avec UML
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 57
58. Diagramme de composants
A quoi cela sert-il ? Pour quoi faire ?
Décrire les éléments physiques dans l’environnement de réalisation
Montrer les choix de réalisation
Un composant UML peut être :
Programme (Cobol, C++, C, Java, EAR, WAR…)
Librairie (DLL, JAR, EJB-JAR, Assembly…)
Fichier (.h, .cpp, .cbl, .java, jcl…)
Diagramme de composants
Composant 1
Composant 2
Composant 3
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 58
59. Diagramme de composants
Composant de type Pr og. Cobol 1
programme COBOL
Dépendance entre
composants
Pr og. Cobol 2
Composant de « haut
niveau » (Ex: ejb-jar dans le
monde J2EE)
Big Jav a Component
Interface du composant
I nt er f ace du composant
«reside»
«reside»
Fichier contenant la
Composant 1 Composant 2 définition d’une classe en
Java
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 59
60. Plan du cours
Objectifs de la formation
Introduction
Les cas d’utilisation
Concepts Objet
Le cœur d’UML
Diagramme de classe
Diagramme de séquence
Diagramme d’activité
Les packages
Diagramme états – transitions
Diagramme de composants
Diagramme de déploiement
Les activités de la méthode avec UML
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 60
61. Diagramme de déploiement
A quoi cela sert-il ? Pour quoi faire ?
Décrire l’infrastructure d’accueil d’un système (architecture physique)
Nœuds et liaisons entre les nœuds (type de lien, protocoles)
Répartir les différents composants sur les noeuds
Diagramme de déploiement
Noeud 1
« base de données »
BD 1
Composant 1
Noeud 2
Composant 2
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 61
63. Plan du cours
Objectifs de la formation
Introduction
Les cas d’utilisation
Concepts Objet
Le cœur d’UML
Diagramme de classe
Diagramme de séquence
Diagramme d’activité
Les packages
Diagramme états – transitions
Diagramme de composants
Diagramme de déploiement
Les activités de la méthode avec UML
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 63
64. Les activités de la méthode avec UML
UML est un langage et non une méthode
UML n’impose donc pas un usage particulier des différents
éléments présentés précédemment
C’est la méthode qui définit comment seront utilisés les différents
éléments UML au cours du cycle de vie d’un projet
Définition des différents niveaux de détail des différents modèles
produits (on parle de niveaux d’abstractions)
Définition des différents éléments d’UML à utiliser à chaque étape du
cycle de vie projet
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 64
65. Les activités de la méthode avec UML
La plupart des méthodes s’appuyant sur le formalisme UML
définissent 3 niveaux d’abstraction
Niveau « Exigences »
Niveau « Analyse »
Niveau « Conception »
Ces niveaux permettent une expression graduelle des exigences
En partant d’une expression proche de l’utilisateur
Pour aller vers une expression proche du code
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 65
66. Les activités de la méthode avec UML
Modèle fonctionnel
Modèle d’analyse
La modélisation devient de plus en Modèle de conception
plus précise et proche du code final
Code
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 66
67. Les activités de la méthode avec UML
Niveau fonctionnel « Exigences »
Utilisation des cas d’utilisation et diagrammes de cas d’utilisation
Détermination du besoin
Niveau « Analyse »
Modélisation des concepts « métier »
Classes représentant uniquement des concepts manipulés par le
métier
Pas d’introduction de classes « techniques » ou d’éléments
provenant du langage d’implémentation
Détermination de la solution fonctionnelle
Niveau « Conception »
Modèle faisant intervenir l’architecture technique en vigueur sur le
projet
Utilisation de « modèles de conception » type (Design Patterns)
Détermination de la solution technique
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 67
68. Les activités de la méthode avec UML
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 68
69. Les activités de la méthode avec UML
Modélisation
métier
Découverte du
processus métier
Exigences NewActivity
Définition des
exigences utilisateur
... NewActivity2
NewActivity3
NewActivity4 Décision
NewActivity6
NewActivity5
NewActivity7
vis-à-vis du système
Cas d’utilisation 1 Cas d’utilisation n
Diagramme d’activités
Analyse - banque
Banque
Object1 : Actor1
1 : message1
Object2 Object3 Object4
Etat_1 [condition]/action Etat_2
Modélisation de la create
2 : message2
possède
evenement «Destroy»
3 : message3
*
- client Compt e 4 : message4 Do/activité
+ numero
solution fonctionnelle
Client
1 - compte
+ nom + crediter ( )
- titulaire appartient à 1..* + debiter ( )
5 : destroy
+ adresse
+ / age + solde ( ) S'il le faut 6 : message5 ( param1)
+ ageMajorite
Diagramme d’états-transition
Diagramme de classes Diagramme de séquence
Conception - banque
Banque Etat_1 [condition]/action Etat_2 NewActivity
create Do/activité evenement «Destroy»
Modélisation de la *
Client
possède
- client Compt e
+ numero
NewActivity2 NewActivity4 Décision NewActivity5
solution technique + nom
+ adresse
1
- titulaire appartient à
- compte
+ crediter ( )
1..* + debiter ( ) NewActivity3 NewActivity6 NewActivity7
+ /age + solde ( )
Diagramme d’états-transitions
+ ageMajorite
Object1 : Actor1 Object2 Object3 Object4
Diagramme d’activités MLD + MPD
Diagramme de classes 1 : message1
2 : message2
3 : message3
4 : message4
5 : destroy
Diagramme de composants +
diagramme de déploiement
S'il le faut 6 : message5 ( param1 )
Diagramme de séquences
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 69
70. Les activités de la méthode avec UML
Les modèles
Modélisation Chaîne de Processus - Recherche des activités métier qui définissent un processus
métier
Modèle de
Evènementiel processus
métier - Organisation de ces activités dans un flux métier
- Découverte des exigences fonctionnelles et non fonctionnelles
Exigences Diagramme de contexte Modèle de
Diagramme de cas d’utilisation - Élaboration en collaboration avec la MOA de la cinématique des cas cas d’
d’utilisation du système utilisation
Diagramme d’activités
-Description des activités d’une exigence
Analyse Diagramme de classes
- Recherche des concepts métiers, de leurs propriétés et des
relations structurelles qui les lient -> modélisation de l’aspect
statique du cas d’utilisation
Diagramme de séquence - Recherche des messages échangés entre objets (flux Modèle
d’événements) -> modélisation de la dynamique du cas d’utilisation d’analyse
Diagramme d’états transition
-Recherche des différents états possibles d’un objet ->
Diagramme d’activités modélisation du cycle de vie
-Description détaillée d’une exigence
Conception Diagramme de classes
Modèle de
Diagramme de séquence conception
- Prise en compte des contraintes techniques et des exigences non
fonctionnelles sur le modèle d’analyse
Diagramme d’états transition
Diagramme d’activités
Diagramme de composants - Organisation des composants
Diagramme de déploiement
-Détermination du schéma de BD
Modèle Logique de Données et
Modèle Physique de Données
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 70
71. Les activités de la méthode avec UML
Discipline Exigences
Diagramme de Diagramme
Dossier des Fiche de Fiche cas d’utilisation d’activités
exigences cas d’utilisation Exigence
Discipline Analyse & Conception
Dossier
d’architecture
Dossier
Diagramme de Diagramme de Diagramme
d’analyse
classes séquence d’états transitions
Dossier Diagramme de Diagramme de
de conception composants déploiement
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 71
73. Maîtrise Documentaire
Informations sur le document
Nom Modèle utilisé PRHA-NOS-PR-0244 Modele de support cours T1.1.ppt
Nom Harmonie PRHA-UML-FO-0719-Sensibilisation-UML-V1.ppt
Revue du présent document Validation du présent document
Nom Fonction Date Nom Fonction Date
Formateurs harmonie Comité de lecture Dominique Marichal Directeur de mission 2/11/05
Formateurs harmonie Formation des formateurs 31/05/05 Thierry Meyer SEPG Manager 08/02/06
Versions
Version Date Responsable Nature des modifications
V 91 2/11/05 PLU Création V91
T1 07/02/06 TDE Rectification Diag Etat classe Cours p 56
V1 08/02/06 APH Diffusion
PRHA-UML-FO-0719-Sensibilisation-UML
08/02/2006 73
Notas del editor
Explication sur le plan: les cas d’utilisation ne sont pas dans le « cœur UML », ils ne portent pas de spécificités objet. Ils pourraient être utilisés dans une approche « fonctionnelle ». les concepts objets permettent de comprendre le « cœur d’UML » qui emploie des concepts et une terminologie objet.
Attention: la sensibilisation UML n’est pas un cours UML Tous les concepts UML ne seront pas étudiés, la syntaxe ne sera pas vu en détail.
Objectif: comprendre l’intérêt de modéliser
Maison selon un architecte en batiment Maison selon un analyste/concepteur informatique Maison selon un développeur L’idée est ici de dire qu’ il n’y a pas une seule manière de représenter un concept manipulé par l’utilisateur et que tout ce que l’on fait en informatique ne revient finalement qu’à proposer une représentation du monde réel afin de pouvoir ensuite manipuler les concepts du monde réel. La modélisation UML n’est donc qu’un autre mode d’expression du réel. Avec UML on va faire un dessin comme l’architecte
Bien que la connaissance d’UML est un pré-requis à la lecture du schéma ici présent, demandez quelle représentation est la plus facile à comprendre en « un clin œil » ?
Comprendre le fonct. du système: avoir une vision du système qui suffit à la compréhension (global pour un niveau de compréhension général, détaillé pour un niveau de compréhension fin et précis) Maîtriser la complexité: gérer des complexites de manière atomique plutôt que de manière globale et avoir une approche de modélisation top-down (en partant du besoin jusqu’au code) Communiquer: avoir un langage commun Automatiser: faciliter le passage au code (langage d’implémentation et SQL) à partir des modèles Accroitre la qualité: mieux identifier et cerner les problèmes , les étudier avant de les réaliser Faciliter la maintenance: faciliter l’analyse d’impact Etre un outil permettant d’organiser et de contrôler: Définir un cadre dans lequel les éléments de modélisation s’inscrivent Donner à modéliser des éléments particuliers à des rôles spécifiques
Dire qu’ un modèle n’est pas intrinsèquement exact. Tout dépend de l’intention à l’origine de la modélisation. Chaque modèle correspond à un point de vue par rapport au concept/sujet modélisé. Même par rapport à un même point de vue, le niveau de détail attendu d’un modèle doit être défini. On peut aussi donner l’exemple de la modélisation d’un avion. La vision sera certainement différente si on s’adresse au service de restauration, service de réparation de l’avion, service en charge des réservations…
Sémantique: (adjectif) Qui a rapport à la signification, au sens (nom féminin) Etude du langage et des signes linguistiques (mots, expressions, phrases) du point de vue du sens (du grec semantikis « qui signifie »). Ici, il s’agit de définir de manière précise certains concepts dans le contexte UML
Expliquer le trigramme UML: Unified Modeling Language Expliquer l’apport de chacun des méthodes: Booch-93 (Grady Booch): couverture complète du sycle de vie orienté sur la construction OMT-2 (James Rumbaugh): couverture complète du cyle de vie orienté sur l’analyse et l’abstraction OOSE (Ivar Jacobson): apport des cas d’utilisation pour la découverte et l’analyse des besoins
Expliquer que: UML couvre tout le cycle de vie projet UML peut être utilisé quelque soit le nature de l’information à modéliser
Axe fonctionnel: quel sont les besoins ? Axe statique: quelles informations sont nécessaires ? Axe dynamique: comment le système doit-il réagir ?
Système: ce qui est construit pour répondre au besoin
Le diagramme de contexte permet de positionner les acteurs qui interagissent avec le système.
Si le système a pour objectif d’informatiser les services clients rendus dans une agence bancaire. Un acteur pourra être le « Charge de Clientèle » à cause de son rôle qu’il joue vis-à-vis de ce système. Remarque: en aucun cet acteur sera nommé par son nom propre (Jean Dupond).
Un cas d’utilisation peut correspondre à : Un processus métier complet informatisé Une activité métier informatisée Un ensemble d’activités métiers informatisées La correspondance dépend du niveau de granularité dans la décomposition des processus métier
Pour expliquer la notion de scénario, faire un parallèle avec un reseau routier. Pour aller d’un point A à un point B, plusieurs chemins sont possibles. L’ensemble des scénarios ayant une fin normale (nominal + alternatifs) représentent tous les chemins possibles pour aller de A à B. Les scénarios d’exception sont des sorties anormales du scénario nominal ou des scénarios alternatifs.
Préciser que tous ces éléments sont des éléments contenus dans la Fiche Cas d’Utilisation.
Les pré-conditions étant les conditions nécessaires à l’exécution du système, elles définissent ce qui est à l’intérieur du cas d’utilisation de ce qui est à l’extérieur du cas d’utilisation.
Un scénario est décrit sous forme d’actions-réactions: actions de la part de l’acteur (le porteur de carte), réactions de la part du système. En noir: les actions de l’acteur En rouge: les réactions du système
Les numéros d’étape sont indentés par rapport au point de branchement.
Chaque objet possède ses propres caractéristiques. Suivant le domaine d’étude, les caractéristiques auxquelles on va s’intéresser peuvent différer.
Dans le domaine d’étude « Le Monde », on s’intéresse à la représentation physique. Dans le domaine d’étude « Entreprise », on s’intéresse à la représentation sociale.
Attributs: définit l’état Opérations: définit le comportement Remarque: inutile de parler de visibilté.
Préciser que la spécialisation/généralisation est un cas particulier de l’héritage. Autre forme d’héritage: la délégation
Diagramme de collaboration: identique au diagramme de séquence avec une représentation spatiale alors que le diag de séquence a une représentation temporelle. Diagramme d’objet = diagramme de classe avec une vue « instance »
Préciser qu’un diagramme de classes se rapproche d’un MCD en Merise L’objectif est avant tout de modéliser la manière sont sont structurées les données: attributs à l’intérieur d’une classe et relations entres les classes.
Préciser qu’un sens de lecture du nom de l’association peut être défini en ajoutant une flèche à côté du nom. Cette possibilité dépend malheureusement des capacités des outils. Ce qu’est un rôle, une multiplicité, une relation Que différents types de relations existent selon la nature du lien entre les objets (agrégation, composition, généralisation/spécialisation)
On pourra préciser que le diagramme peut faire intervenir des objets et des sous-systèmes. Diagrammes boite noire: peut être utilisé pour décrire la dynamique d’un cas d’utilisation (on n’entre pas dans les détails du système) Diagramme boite blanche: utilisé pour décrire le contenu d’une fonctionnalité (au cœur du système) Diagramme d’interaction entre sous-systèmes ..
Un diagramme d’activités peut se comparer à un MCT ou MOT en Merise
Swimlane ou ligne d’eau positionne les activités effectuées par un rôle « Fork » indique que plusieurs activités se déclenchent en même temps « Join » indique que le résultat des 2 activités (3 et 3 bis) sont nécessaires pour exécuter l’activité 4
Bien préciser qu’un élément appartient à un seul package. Il peut cependant être représenté dans des diagrammes définis dans d’autres packages. « La photo n’est pas l’objet »
Bien préciser qu’un élément appartient à un seul package. Il peut cependant être représenté dans des diagrammes définis dans d’autres packages. « La photo n’est pas l’objet »
Le package Client est indépendant. Le package Contrat dépend d’élements du package Client et Compte. Le package Compte dépend d’éléments du package Client. Eviter les dépendances cycliques, bi-directionnelles…
Expliquer que dans la MCIP l’utilisation des diagrammes d’E/T n’est préconisée que pour la modélisation de cycle de vie d’objets.
On suppose que l’état du cours n’est représenté que pour l’inscription d’étudiants à un cours
Dire qu’un composant est un module qui représente toutes sortes d’éléments physiques qui entrent dans la fabrication des applications informatiques. Un module peut être un simple fichier, un package ou des bibliothèques chargés dynamiquement. Le terme composant peut également représenter une famille de composants. Ex dans le cas d’une application web: - composant IHM statique (pages html) - composant IHM dynamique (pages jsp) - composant fonctionnel métiers (classes java) - accesseurs physiques (code cobol) - contrôleur (servlet) - ...
Faire le lien entre les packages et les composants Préciser qu’une relation de dépendances indique qu’un composant fait référence aux services offerts par un autre composant. Ce type de dépendance reflète un choix de réalisation. Une relation de dépendance est une flèche pointillée qui pointe de l’utilisateur vers le fournisseur. La relation de dépendance peut être spécialisée par un stéréotype afin de préciser la nature des choix de réalisation qui entraînent la relation de dépendance.
Objectif: Montrer la disposition physique des différents matériels (nœuds du système) Positionner les composants dans les nœuds Un nœud est un « composant » physique, il est représenté par un cube. En général, un seul diagramme de déploiement suffit pour modéliser l’équipement d’un système. Les relations entre les nœuds symbolisent des supports de communication « a priori » bidirectionnel. Une relation peut-être stéréotypée. Ce stéréotype permet généralement de préciser le protocole de communication entre es nœuds (TCP/IP, RMI, RNIS…)
Un nœud correspond à une machine physique. Sur chaque nœud, on positionne les différents composants.
Exigences: définition du besoin et déclinaison du besoin en exigences Analyse: détermination de la solution fonctionnelle Conception: détermination de la solution technique
Niveau analyse=Modélisation d’une solution fonctionnelle Niveau conception= Modélisation d’une solution technique
Parler du caractère obligatoire des diagrammes: Aucun diagramme est obligatoire (fonction de la nature du projet, de son contexte, des exigences) D’une manière générale: Les diagrammes fortement recommandés sont: Diagramme de cas d’utilisation pour l’identification des exigences fonctionnelles Diagrammes de classes pour la modélisation des données Diagrammes de séquence pour l’identification des messages échangés entre acteurs Les diagrammes à usage contextuel (à utiliser si nécessaire): Diagrammes d’activités pour modéliser les règles de gestion et les algos complexes Diagrammes d’états-transition pour modéliser le cycle de vie d’un objet Diagramme de composants pour spécifier l’architecture physique Diagramme de déploiement pour définir les nœuds du système et positionner les composants sur les noeuds