013 mediha cgi - sensibilisation uml

Programme Harmonie
Sensibilisation UML

1

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

Plan du cours

 Introduction
 Concepts Objet
 Les packages


08/02/2006 3

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

08/02/2006 4

Plan du cours

 Introduction
 Concepts Objet
 Les packages

08/02/2006 5

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() { … }
…
}

08/02/2006 6

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

08/02/2006 7

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

08/02/2006 8

Points de vue – Niveau de détail

Plan de Modèle
circulation d’urbanisme

 
Ville

 
Modèle
Modèle d’équipement
de la population

08/02/2006 9

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

08/02/2006 10

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

08/02/2006 11

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…

08/02/2006 12

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

08/02/2006 13

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

08/02/2006 14

Plan du cours

 Introduction
 Concepts Objet
 Les packages

08/02/2006 15

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

08/02/2006 16


 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

08/02/2006 17

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

08/02/2006 18

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

08/02/2006 19

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

08/02/2006 20

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 »

08/02/2006 21

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

08/02/2006 22

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

08/02/2006 23

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

08/02/2006 24

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

08/02/2006 25

Plan du cours

 Introduction
 Concepts Objet
 Les packages

08/02/2006 26

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)

08/02/2006 27

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

08/02/2006 28

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

08/02/2006 29

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

08/02/2006 30

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

08/02/2006 31

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

08/02/2006 32

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

08/02/2006 33

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

08/02/2006 34

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

08/02/2006 35

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

08/02/2006 36
message

Plan du cours

 Introduction
 Concepts Objet
 Les packages
 Diagramme de collaboration

08/02/2006 37

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

08/02/2006 38

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

08/02/2006 39

Plan du cours

 Introduction
 Concepts Objet
 Les packages


08/02/2006 40

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


08/02/2006 41

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

08/02/2006 42

Exemple: « achat d’un livre »

unClient : Client LeStock : Stock livre : Livre unArticle : Article monPanier : Panier

manager : StockManager
1 : create

2 : DonneListeLivre

3 : ChoixLivre ( livre )
4 : EnleveLivre (livre )

5 : create

6 : Associe ( livre )

7 : DemandePrixUnitaire
8 : Ajoute ( article )
9 : CalculSolde

08/02/2006 43

Plan du cours

 Introduction
 Concepts Objet
 Diagramme d’activités
 Les packages


08/02/2006 44

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

08/02/2006 45

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»

08/02/2006 46

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»

08/02/2006 47

Plan du cours

 Introduction
 Concepts Objet
 Les packages

 Les activités d’analyse et de conception avec UML

08/02/2006 48

Packages
 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 »

08/02/2006 49

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

08/02/2006 50

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

08/02/2006 51

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

08/02/2006 52

Plan du cours

 Introduction
 Concepts Objet
 Les packages


08/02/2006 53

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

08/02/2006 54

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

08/02/2006 55

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

08/02/2006 56

Plan du cours

 Introduction
 Concepts Objet
 Les packages


08/02/2006 57

Diagramme de composants
 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…)

Composant 1

Composant 2

Composant 3

08/02/2006 58

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

08/02/2006 59

Plan du cours

 Introduction
 Concepts Objet
 Les packages


08/02/2006 60

Diagramme de déploiement

 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


Noeud 1
« base de données »
BD 1
Composant 1

Noeud 2

Composant 2

08/02/2006 61

Exemple

DMZ1 DMZ2

iiop : 1402
http : 80 Serveur
Mainframe
Serveur Web Firewall Application
Firewall DMZ2 WAS5.1
DMZ1 Apache iiop : 1402

sqlnet

Serveur
Serveur DB2
Oracle YYY
XXX

08/02/2006 62

Plan du cours

 Introduction
 Concepts Objet
 Les packages


08/02/2006 63

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

08/02/2006 64


 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

08/02/2006 65


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

08/02/2006 66

 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

08/02/2006 67





08/02/2006 68


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

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

08/02/2006 69

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

08/02/2006 70


 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

08/02/2006 71

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

08/02/2006 73

013 mediha cgi - sensibilisation uml

Contenu connexe

Tendances

En vedette

Similaire à 013 mediha cgi - sensibilisation uml

013 mediha cgi - sensibilisation uml

Notes de l'éditeur