Uml PDF

Introduction aux Systèmes d’information
Conception orientée objet des systèmes

d’information
Faïez GARGOURI
Maître de Conférences
ISIM – Sfax
faiez.gargouri@fsegs.rnu.tn
1
Introduction
On peut décomposer le terme Système d'Information en :

- Système : ensemble de composants travaillant en collaboration pour
accomplir une tâche particulière partant de données initiales.
- Information : . collecte, vérification, validation, représentation, ...
. codage, affinage, stockage, manipulation, ...
Le Système d'Information (SI) englobe donc deux aspects :
- les méthodes d'analyse et de conception (MCD, …) et
- les environnements de programmation (Modèle relationnel, …).
Dans [Galacsi 1984], un système d'information est défini comme :
'l'ensemble des moyens, humains et matériels, et les méthodes se
rapportant au traitement des différentes formes d'information
rencontrées dans les organisations'.
Système d’information ou système d’informations
2
Introduction
Un système d'information doit permettre les fonctions suivantes :

- Le captage : collecter et saisir l'information sous toutes les
représentations pertinentes pour le domaine concerné.
- La modélisation : donner une représentation structurée et formalisée
à l'information dans un langage cohérent à sa bonne gestion pour
les utilisateurs et les moyens utilisés,
- Le stockage : toute information pertinente à la survie de l'organisme
doit être sauvegardée dans des supports pour des utilisations
futures,
- L’ajustement : présenter un ensemble d'opérateurs permettant de
manipuler l'information et éventuellement de modifier son codage
et/ou son stockage pour une meilleure utilisation,
- L’affichage : apporter les réponses souhaitées de l'utilisateur sous la
forme la plus appropriée.
3
Les différents systèmes d’une organisation
Le système opérant :
Responsable de l’exécution des tâches
Détenteur "du métier" de l’organisation
Le « savoir faire »….
Le système de pilotage :
Décider
Planifier ,
…
Le système d’information :
Relation entre les deux autres systèmes
Faire circuler l’information,
…
4
MATIERES PRODUITS
SYSTÈME ACTIVITE
PREMIERES FINIS
OPÉRANT
SYSTÈME
D’INFORMATION INFORMATION
SYSTÈME DE
PILOTAGE DECISION
5
6
Mode de fonctionnement:
Suivi :
DECISIONS Système de
PILOTAGE COMPTES RENDUS
ORDRES
BILAN
….
….
Système D’INFORMATION
Système OPÉRATIONNEL
7
FONDEMENTS SYSTEMIQUES
Le système :
C’EST QUELQUE CHOSE (n’importe quoi mais identifiable)
QUI FAIT QUELQUE CHOSE (activité, fonction)
QUI EST DOTE D’UNE STRUCTURE (structuré et non aléatoire)
QUI EVOLUE DANS LE TEMPS (n’est pas statique)
DANS QUELQUE CHOSE (environnement)
POUR QUELQUE CHOSE (finalités).
J.L. LEMOIGNE
Un système :
Est un ensemble d’éléments
En interaction dynamique
Organisés en fonction d’un but.
J. de ROSNY
8
ENVIRONNEMENT
EVOLUTION STRUCTURE ACTIVITE
FINALITES
9
- Salaires
-Règlement fournisseur,
-…
} Sortie 1
Flux PRODUITS
{- Acompte Client
- Règlements Client
Flux FINANCIER FINANCIERS

Entrée 1
SYSTEME
OPERANT
Flux MATIERES
} {
Flux PRODUITS
- Energie à distribuer FINIS - Energie distribuée
Entrée 2 Sortie 2
- Câbles électriques, … - Pylônes, …
Exemple de Système opérant

10
- Contrôle opérationnel
DIRECTION DE
LA PRODUCTION { - Ordonnancement
- Approvisionnement
- Expédition, Livraison, …
DIRECTION
COMMERCIALE { - Conditions de distribution
- Action commerciale, …
DIRECTION
FINANCIERE { -Objectifs financiers
- Budgétisation
- Contrôle de gestion, …
Exemple de Système de pilotage

11
Système de Pilotage
- Impayés - Ordonnancement Production
-Demande -Commandes
d’abonnement fournisseurs
- Règlements, ..
SYSTEME - Règlements, ..
- Factures D’INFORMATION - Bon de

livraison
- Relances, …
- Factures, …
Clients
Fournisseurs
- Plan de relève - Relevé de consommation

Système Opérant
12
Evolution des applications informatiques
Les applications informatiques ont subi d’importantes évolutions :

- Quantitatives :
. le nombre d’informations à traiter, . le nombre d’utilisateurs,
. les sources d’information, . les données à stocker, ...
Exemple1:
Comparer les deux applications suivantes :
Résoudre ax2 + bx + c = 0 et gérer les stocks, ...
- Qualitatives :
. les services offerts, . les utilisateurs . la performance,
. la fiabilité, . l’ergonomie, ...
Exemple2:
Les menus C et ceux de VB, ...
13
Années Données Correspondance : Processus de Langage/SGBD

Manipulées Réel / Physique Modélisation
50 Mono-type Bijective Fonctionnel ......
Numérique S.G.F.
Caractères...
60 - 70 Structures (1,N) Systèmique Réseau/Hiéra/

Simples D
Relationnel
record T Navigationnel
enregistrement Déclaratif
Conception
80 - .. Complexes Identité Objets Objets
Combinant la
Evolutives conception des
Hiérarchisées Hybriqde
données et des Puriste
traitements
14
Plus fonctionnalités ++ complexité ++

Avec la vulgarisation de l'informatique dans divers domaines et la
complexité croissante des applications à informatiser un nouveau besoin a
émergé :
Une représentation intermédiaire (RI) entre le réel et son implantation
Le Réel RI
Le Modèle L'implantation
H F
H(......)
F (......)
V(......)
Modélisation V Implantation
La RI :
- Réduit l'écart entre le réel à informatiser et son implantation informatique.
- Utilise un modèle(s) permettant un passage progressif : Réel vers Implantation.
15
Un modèle :
- est une abstraction du réel à informatiser.
- utilise un ensemble de concepts et un ensemble de règles
d’utilisation :
- Les concepts fournissent le moyen de représenter les entités du
monde réel et les relations qui existent entre elles.
- Les règles d’utilisation sont définies sur les concepts du modèle
et régularisent leurs utilisations.
Remarque:
Pour assister le concepteur afin d’élaborer le(s) modèle(s)
on a besoin d’une méthode.
16
Une méthode :
- Guide la transition du réel à sa perception (RI) et de cette dernière
vers l’implantation (Programmes).
- Composée de :
+ Un ensemble d’étapes successives : une démarche.
+ Un ensembles de modèles exprimant des points de vue
différents.
+ Un ensemble de concepts (et leurs règles d’utilisation)
permettant la représentation des modèles.
Une méthode = un langage (modèles+concepts+règles

d’utilisation) + une démarche
17
Historique des méthodes d’analyse et de conception
Les approches fonctionnelles
Inputs Outputs
....
Le SI
Première génération de méthodes d’analyse et de conception des

logiciels (1960 – 1970).
Analyser les traitements d'un système en termes d'Entrées / Sorties.
Décomposer un problème en sous-problèmes, …, un sous problème
en fonctions
Découper chaque fonction en sous-fonctions, …, une instruction
codifiable dans un langage de programmation.
LCS de Warnier; SADT, MCX de Castellani, Structured Analysis de
Jackson ...
18
19
Points forts :
- Simplicité du processus de conception.
- Simplicité de la démarche intellectuelle.
- Affinage progressif.
- Répond plus vite aux besoins ponctuels des utilisateurs
(applications simples).
Points faibles :
- Pas de limites précises pour les décompositions.
- Concentration sur les traitements.
- Redondance possible des données.
- Non intégration des traitements.
20
Les approches systémiques
D T
Deuxième génération de méthodes d’analyse et de

conception des SI (197x – 198x).
Traitent le système comme un ensemble d'entités
communicant entre elles et avec l'extérieur.
Une double approche de modélisation : des données et des
traitements (influence de la dichotomie D/T).
Axial; SSADM; Merise; ...
21
Points forts :
- Approche globale.
- Introduction des niveaux d'abstraction dans le processus de
conception :
- Conceptuel - Logique et - Physique.
- Bonne adaptation à la modélisation des données et la conception des
BD.
- Les étapes du processus de conception sont bien délimitées.
Points faibles :
- Double démarche de conception : les données et les traitements.
- MCD - MCT
- MLD - MLT, …
- Pas de règles précises pour la fusion des deux aspects.
22
Les approches orientées objet
D D
T T
D D
T T
Dernière génération de méthodes d’analyse et de conception

des SI (198x – ….).
Emergence de la philosophie Objet.
Inclure les concepts objet dans la démarche d'analyse et de
conception des SI.
HOOD; GOOD; OMT, OOSE; O*, MCO ..., UML
23
Exemples de méthodes objet

- Les méthodes inspirées et dédiées à un langage de programmation :
HOOD [Heitz 1989] pour ADA
OOD [Booch 1991] pour Smalltalk.
- Les méthodes inspirées et dédiées aux applications temps réel :
OOAD [Shlear 1991];
OOSE [Jacobson 1992].
- Les extensions de méthodes classiques :
OMT [Rumbaugh 1991]
OOM [Bouzeghoub 1994], [Morejon 1994].
- Les méthodes purement orientées objets :
O* [Brunet 1993]
MCO [Castellani 1993].
Remarques :
1. Les premières propositions sur la base des LP
2. Les dernières propositions
24
Les différents points de perception d’un systèmes :

La vision statique :
Description des entités représentant l’univers de discours et de leurs relations.
La vision dynamique :
Description des évolutions, dans le temps, des entités représentant l’univers de
discours.
La vision fonctionnelle :
Description du fonctionnement (des différentes fonctionnalités) du système.
25
UML
Concepts & Démarches orientés objet

Faïez GARGOURI
ISIM – Sfax
26
Concepts orientés objet
L’OBJET
Est un élément du réel à modéliser :
La facture 100567, la personne Faïez Gargouri, le cours COOSI
Posséde sa propre identité : OID (Object Identifier) :
OID : est une valeur indépendante des valeurs des prorpriétés de l’objet
Attribuée par le système et elle est totalement transparante à l’utilisateur
Peut avoir plusieurs états durant son cycle de vie :
Etat d’un objet : situation significative que peut prendre un objet,
déterminée en fonction des valeurs des différents attributs et liens de l’objet
Cycle de vie : les états que peut prendre un objet, entre sa création et sa
suppression (et les conditions de passage d’un état à un autre).
Exemples :
La facture 100567 : {100567, 27/1/2005, ...}
Les états que peut prendre la facture : {saisie, livrée, en attente de livraison,
soldée, …}
27
La CLASSE
Regroupe un ensemble d'objets semblables :
les mêmes propriétés structurelles (attributs);
le même comportement (opérations, méthodes);
les mêmes liens avec les autres objets;
et ayant un intérêt pour l'application.
Encapsule les données et les traitements :
La classe Facture : {NumFacture, DateFacture, …,
Imprimer(), Solder(), ...}
Exemple :
CLASSE Personne
Attributs
Nom : Chaîne; Prénom : Chaîne; Age : [1..132]
Opérations
Créer(); Supprimer()
FIN CLASSE Personne.
28
L’ENCAPSULATION
Est un principe qui consiste à :
cacher les données et les détails d'implantation (algorithmes) et
laisser visible la partie interface (signatures des opérations
publiques) des classes
Approche classique Approche objets
Interface
Encapsulation Interface
Interface
Données Traitements Echange de messages
29
Conséquences de L’ENCAPSULATION :
☺ Tout objet n'est accessible qu'à travers les opérations de l’interface de sa classe.
☺ Protéger les données et les codes des opérations.
☺ Dégager l’utilisateur des détails d’implémentation.
☺ Faciliter les MAJ du code des opérations.
Exemple :
Considérons la classe COMPTE suivante:
CLASSE Compte
PROPRIETES Programme utilisateur:
Numéro : Integer ... a = Lire(NuméroCompte);
Solde : Integer b = CalculerIntérêt(a);
METHODES Partie invisible à l’utilisateur:
Créer() CalculerIntérêt(x: integer){
CalculerIntérêt() return (x.solde*4%) }
FIN CLASSE Compte
En cas de changement du taux d’intérêt, le programme utilisateur reste identique
30
L’HERITAGE
Est un mécanisme permettant le partage des caractéristiques d’une classe
(généralisation) par une ou plusieurs autres classes (spécialisations).
Personne Nom, Prénom, Adresse, ...

Héritage simple
Cours, Diplôme, ... Enseignant Etudiant Année, ...
Héritage multiple
Etudiant_Enseignant Numéro, TD, ...
31
Remarques concernant L’HERITAGE

Les caractéristiques héritées :
Les attributs
Les liens
Les méthodes
Les d’états.
Les spécialisations ont :
des caractéristiques héritées et d’autres spécifiques.
L’héritage au niveau conceptuel vs l’héritage au niveau implantation.
Classe A
Mais aussi : Transitivité de l’héritage.
Classe B
Classe C
32
LE POLYMORPHISME
Est la capacité d’une méthode héritée à être appliquée sur des objets de
types différents.
Afficher() Objet
Personne Fenêtre
L’opération Afficher() s’applique à une fenêtre et à une personne
Utilités (au niveau implantation) :

☺ La lisibilité des programmes résultats
☺ L’assouplissement du typage.
☺ La réutilisation des méthodes définies au niveau de la généralisation.
☺ La liaison dynamique
33
Démarche Orientée objet
Principales étapes de conception objet

Le cycle de vie du logiciel suivant une approche objet est Itératif et Incrémental.
Itératif : l’architecture subit plusieurs cycles d’analyse, de conception et
d’implémentation.
Incrémental : les décisions sont raffinées à chaque cycle d’analyse / conception /
implémentation, menant à un système qui répond plus aux exigences.
Dans chaque itération, on s’intéresse aux activités suivantes :
Identifier les classes et les objets à un niveau donné d’abstraction
Identifier les relations entre classes
Spécifier l’interface des classes.
Phase Conception
Phase aly se
e A n
Implémentation s
Pha
34
Principales étapes de conception objet

L’analyse :
Délimiter le champ de l’étude
Etudier et critiquer l’existant
Les Principales étapes de conception :
Identification des objets et des classes;
Identification des relations entre classes;
Identification des sous-systèmes.
35
Identification des objets et des classes :

Définir les classes dans l'esprit de les intégrer dans une bibliothèque (de
classes réutilisables) et non pour satisfaire un besoin ponctuel,
Utiliser les classes prédéfinies dans la bibliothèque de classes.
Adapter les classes prédéfinies au contexte de l'application à développer.
Ne pas hésiter à diviser une méthode en deux si elle devient

encombrante.
Chaque méthode d’une classe doit assurer une fonction élémentaire.
Réduire au maximum le nombre de méthodes dans une même classe;
36
Identification des liens entre les classes :

d’héritage
de composition
d’agrégation
d’association
d’utilisation,
lien de référence, ...
Remarques :
Les interactions entre les classes doivent être réduites au stricte minimum.
Les liens par rapport à ceux du modèle E/A.
37
Identification des sous-systèmes :

Un sous-système est une entité conceptuelle.
un sous-système (Framework ou package) est une collection d'objets (ou
de classes) qui collaborent pour accomplir une tâche particulière ou
un ensemble de services cohérents
Utilités des sous-systèmes :
Favoriser la modularité du logiciel résultat.
Permettre la création de composants réutilisables.
Faciliter la réutilisation.
Améliorer l’extensibilité du logiciel, ...
38
Les différents points de perception d’un système :
La vision statique :
Description des entités représentant l’univers de discours et de leurs
relations.
De quoi est fait le système ?
La vision dynamique :
Description des évolutions, dans le temps, des entités représentant l’univers
de discours.
Comment il peut évoluer ?
La vision fonctionnelle :
Description du fonctionnement (des différentes fonctionnalités) du système.
Comment il fonctionne ?
Exemple :
OMT utilise trois visions différentes et complémentaires du même SI
39
Modèle statique
Décrire les objets : Contrôler les

. structures de données évolutions, dans le
. opérations temps, des objets du
. liens entre les classes système
Modèle
dynamique
Modèle fonctionnel Décrire le fonctionnement

du système
40
UML : Unified Modelling Language
Introduction à UML
Faïez GARGOURI
ISIM – Sfax
41
PLAN
1. Introduction et Remarques Générales
2. UML - l’historique
3. UML - les diagrammes
4. UML - les concepts de base
5. Comment concevoir avec UML ?
42
Introduction & Remarques Générales
L’approche objet est la dernière proposition dans l’A et la C des SI,

elle permet :
- Intégrer dans l'objet des données et des traitements.
- Profiter des avantages des concepts objet pour la conception.
- Prendre en compte une plus large gamme d'applications.
- Favoriser la conception et la réutilisation des composants.
- Améliorer la productivité et la rentabilité des concepteurs.
- Faciliter le prototypage.
- Simplifier le passage Conceptuel / Physique
43
L’approche objet permet de :

améliorer la productivité des concepteurs / développeurs et
réduire le coût de revient des applications.
Investissement
(Homme-mois) Approche Classique
Approche Objet
Investissement initial
Taille ou fonctionnalité
Coût de production d’une application informatique

en fonction de sa taille et de ses fonctionnalités
44
Durant les dernières décennies plus que cinquante méthodes objet ont
été proposées :
Les méthodes inspirées et dédiées à un langage de programmation :
HOOD [Heitz 1989] pour ADA.
OOD [Booch 1991] pour Smalltalk.
Les méthodes inspirées et dédiées aux applications temps réel :
OOAD [Shlear 1991].
OOSE [Jacobson 1992].
Les extensions de méthodes classiques :
OMT [Rumbaugh 1991].
OOM [Bouzeghoub 1994], [Morejon 1994].
Les méthodes purement orientées objets :
O* [Brunet 1993].
MCO [Castellani 1993].
45
Suite à cette multitude de propositions:

divers concepts sont utilisés,
divers modèles proposés,
diverses démarches suivies,
diverses notations graphiques supportées,
diverses sémantiques accordées aux mêmes concepts.
UNE JUNGLE MÉTHODOLOGIQUE
Plusieurs propositions de méthodes unifiées :

Fusion, Eurométhode, …
Le résultat : une nouvelle méthode et non une méthode unifiée
46
Un besoin d’unification:
Unified …
Pour la modélisation :
Modelling …
Sous forme de langage :

Language …
UML
Remarque : Pourquoi langage et non méthode ?
47
UML :
regroupe les plus récentes propositions dans :
Concepts de modélisation des données.
Modélisation des processus d’affaires (WorkFlow).
Modélisation objet.
Modélisation des composants.
peut être associé à toute démarche de conception :
à n’importe quelle étape de la démarche.
avec différents environnements de programmation.
Unification des concepts et des modèles de principalement trois

méthodes connues de :
OOD (Object-Oriented Design) de Grady BOOCH.
OMT (Object Modelling Techniques) de James RUMBAUGH.
OOSE (OO Software Engineering) Ivar JACOBSON.
48
Nombreux partenaires IBM, Microsoft, DEC, HP, Unisys, Oracle, ...
Un standard des notations graphiques et du vocabulaire utilisés pour

l’ACOO des SI.
N’est pas une méthode de conception mais un ensemble de notations

unifiées.
n’est pas une méthode, mais un langage !!!!!!

n’est pas une méthode, mais un langage !!!!!!!!!!!!!!!
n’est pas une méthode, mais un langage !!!!!!!!!!!!!!!!!!!!
49
Pourquoi utiliser UML :

Est le standard pour la ACOO des SI.
Est un langage semi-formel basé sur la notion de méta-modèle.
Couvre le cycle de développement des logiciels :
de la spécification des besoins à l’implantation.
Les représentations prévues par UML couvrent différents niveaux
d’abstraction
Est un support de communication :
conséquence de la standardisation
On peut faire travailler des équipes différentes avec des méthodes
différentes sur les parties d’une même application.
UML évolue mais reste stable :
Un noyau stable : concepts de base
Des mécanismes d’extension des concepts de base
50
La Genèse d’UML
Historique :
1993-1994 1995 1996 01 - 1997 11 - 1997

Soumission à Adoption par
l’OMG l’OMG
Booch’93
Autres Unified Method 0.8 UML 0.9 UML 1.0 UML 1.1
OMT - 2 Partenaires
OOSE Normalisation
en 1999
1995 : Autres tentatives d’unification de
méthodes : Fusion et Eurométhode UML 1.3
UML 2.0
51
Neuf diagrammes représentant chacun un aspect particulier du SI à

modéliser :
de cas d’utilisation : décrit les vues utilisateurs du système,
de classes : décrit les classes et les liens qui les relient,
d’objets : représente des instances de diagrammes de classes,
d’états-transitions : décrit les cycles de vie des objets,
de collaboration : décrit les interactions entre les objets,
de séquence : représente un diagramme de collaboration ordonné dans le
temps,
d’activités : décrit la sémantique des méthodes en termes d’actions,
de composants: décrit les dépendances de compilation ou d’exécution
entre les différents modules constituant un logiciel,
de déploiement: décrit les unités de programmes et leurs processus
d’affectation.
52
Chaque type de diagramme UML :

possède une structure :
les types des éléments de modélisation (concepts) qui le composent sont
prédéfinis
véhicule une sémantique précise :
un type de diagramme offre toujours la même vue d'un système
UML permet de définir et de visualiser un modèle, à l'aide de

diagrammes.
53
Les 9 diagrammes d’UML :

5 diagrammes structurels (Vue (modèle) statique du système) :
de cas d'utilisation,
}
d'objets,
de classes,
de composants et de quoi est fait le système ?
de déploiement.
4 diagrammes comportementaux (Vue ou modèle dynamique) :
}
de collaboration,
de séquence,
d'états-transitions et comment se comporte le système ?
d'activités.
(on peut avoir : vue statique, vue dynamique et vue fonctionnelle)
54
Les différents types de diagrammes UML combinés :

offrent une vue complète des aspects statiques et dynamiques d'un système.
Les diagrammes UML supportent l'abstraction :

Leur niveau de détail caractérise le niveau d'abstraction du modèle
La structure des diagrammes UML et la notation graphique des

éléments de modélisation:
sont normalisées (document "UML notation guide").
La sémantique des éléments de modélisation et de leur utilisation

est définie par le métamodèle UML (document "UML semantics").
WWW. omg.org ou www.rational.com
55
Bibliographie
Livres :
Modélisation objet avec UML
JA Muller, N. Gaertner. Editions Eyrolles.
UML par la pratique
UML en action
De Merise à UML, …
Sur le Web :
http://www.omg.org/uml/
http:// www.rational.com
http://www.uml.free
Sous google :
UML
français
56
Diagrammes de Cas d’utilisation

Uses Cases
Faïez GARGOURI
ISIM – Sfax
57
Définitions
Les use cases (UC) ont été initialement proposé par OOSE de
Jacobson pour :
délimiter le système étudié,
améliorer la compréhension du fonctionnement du système et
définir les relations entre le système et son environnement.
Décrivent le comportement d’un système (action/réaction) du point de
vue utilisateurs :
L’user modélise ses besoins et non l’analyste (comme avec Merise
Position des UC dans un processus de modélisation :
Spécifications
Use Cases
Analyse Tests
58
Définitions
Définition 1:
Un cas d’utilisation (use case) modélise une interaction
entre le système informatique à développer et un
utilisateur ou acteur interagissant avec le système.
Définition 2:
Un cas d’utilisation décrit un ensemble d’actions réalisées
par le système qui produit un résultat observable pour un
acteur.
Constatations:
- Modélise : pas de détails (pas d’algorithme des interactions)
- les actions représentées par les CU sont automatisées et non
manuelles
59
Définitions
Les cas d’utilisation :

servent de base à la traçabilité des exigences d'un système dans un
processus de développement intégrant UML.
se limitent aux préoccupations "réelles" des utilisateurs :
ne présentent pas de solutions d'implémentation et
ne forment pas un inventaire fonctionnel du système.
Un cas d’utilisation avec UML :
est la solution pour représenter au niveau conceptuel, les besoins des
utilisateurs (Merise ne permet pas cette modélisation).
permet de structurer les besoins des utilisateurs et les objectifs
(fonctionnalités) correspondants d'un système.
identifie les utilisateurs du système (acteurs) et leurs interactions avec le
système.
permet de classer les acteurs et structurer les objectifs du système.
60
Définitions

Recentrent l’expression des besoins sur les utilisateurs
ne doivent pas chercher l'exhaustivité, mais clarifier, filtrer et organiser
les besoins
Partitionnent l’ensemble des besoins d’un système.
Les besoins:
définissent le contour du système à modéliser
ils précisent le but à atteindre,
permettent d'identifier les fonctionnalités principales (critiques) du
système.
61
Définitions
Commencer par établir le diagramme des cas permet de :

mener un développement orienté utilisateur et
de découper le système global en grandes tâches qui pourront être
réparties entre les équipes de développement.
Une fois obtenu, le diagramme des cas d’utilisation est un support

privilégié de communication entre les équipes, ainsi qu’avec les
clients.
62
Concepts de base : les acteurs
Définition 1 :
Représente un rôle joué par une entité externe (utilisateur humain,
dispositif matériel, ou autre système) qui interagit directement avec le
système étudié
Définition 2 :
Une entité externe agissant sur le système qui peut :
Échanger de l’information avec ce système
consulter ou modifier l'état du système,
Les acteurs sont :
Déterminés en examinant les :
Utilisateurs directs du système
Responsables de l’exploitation et/ou de la maintenance
Autres systèmes interagissant avec le système
Représentés sous forme de petits personnages ou sous forme de
rectangle avec le mot clé <<acteur>>
63
Un acteur peut être :

Principal :
Utilise les fonctions principales du système
Secondaire :
Effectue des tâches administratives ou de maintenance
Matériel externe:
Les dispositifs matériels :
Autres que les machines où s’exécute l’application
faisant partie du domaine de l’application et
nécessaires au fonctionnement du système
Les autres systèmes avec qui le système doit interagir.
Exemple d’un distributeur de billets bancaires:
Client, personne rechargeant le distributeur, imprimante, groupement
bancaire
64
Les acteurs :
Doivent être décrits d’une manière simple et précise
Avec des phrases en langage naturel
Peuvent être reliés par des liens de généralisation/spécialisation
Utilisateur / Administrateur
Exemple d’acteurs :
Humains :
les utilisateurs du logiciel à travers son interface graphique
Logiciels :
déjà disponibles qui communiquent avec le système grâce à une interface
logicielle
Matériels :
robots et automates qui exploitent les données du système ou qui sont
pilotés par le système
65
Concepts de base : les cas d’utilisation
Définition 1 :
Un ensemble d'actions réalisées par le système, en réponse à une action
d'un acteur
Définition 2 :
Modélise une fonctionnalité d’un système ou d’une classe

sont représentés par des ellipses
Peuvent être contenus dans un rectangle (représentant le système)
Sont déterminés en observant et en précisant
Acteur par acteur les scénarios du point de vue utilisateur
Sont décrits en termes :
d’informations échangées et
d’étapes d’utilisation du système.
66
Concepts de base : les cas d’utilisation
Un cas d’utilisation :
Regroupe une famille de scénarios d’utilisation
Est une abstraction du dialogue système/utilisateurs
Quand un acteur interagit avec le système:

Le cas d’utilisation instancie un scénario
L'ensemble des cas d’utilisation décrit les objectifs du système

Utilité des cas d’utilisation pour :
les utilisateurs : exprimer les besoins
Les analystes : comprendre
Les programmeurs : réaliser
Les testeurs : vérifier
67
Concepts de base : relations entre cas d’utilisation
Association :
Relation entre un acteur et un cas d’utilisation
Un acteur déclenche un cas d’utilisation :
CasUtilisation
Acteur
Relation d’inclusion :
Entre cas d'utilisation
L’instance du CU source contient aussi le comportement décrit par le CU
destination.
<<inclut>>
CasUtilisation1 CasUtilisation2
68
Relation d’inclusion (suite) :

La relation d’inclusion a un caractère obligatoire:
La source doit indiquer à quel endroit le CU cible doit être inclus
Permet de :
Décomposer les comportements et
Définir des comportements partageables entre plusieurs CU.
Relation d’extension :
L’instance du CU source ajoute son comportement au CU destination (si
la condition est réalisée).
Le CU destination étend son comportement par l’ajout de celui du CU
source, si la condition est vérifiée.
<<étend>>
[con ditio n d'extens i on]
Cas Utilis ation1 Cas Utilis ation2

69
Relation d’extension (suite) :

Peut être soumise à une condition :
Le comportement ajouté est inséré au niveau d’un point d’extension
Ce point d’extension est défini dans le CU destination
Permet de modéliser des variantes de comportement d’un CU
Selon les interactions des acteurs et l’environnement du système
la condition d’extension peut être spécifiée
à côté du mot-clés <<étend>>
Point d’extension :
Possède un nom
Décrit :
Un emplacement dans le CU destination où le comportement du CU source
sera inséré.
UML ne définit aucun format de description de point d’extension
70
Relation de généralisation :
Le cas d’utilisation Fils est une spécialisation du cas d’utilisation Parent
CasUtilisationParent Virement
CasUtilsationEnfant Vi rem ent ParInte rnet
Exemple : On désire représente par un diagramme de CU les virements bancaires effectués

par des clients:
Un client peut être local ou distant
Un client peut effectuer un virement via Internet ou direct (banque)
Dans tous les cas, on doit procéder à une identification du client
Dans le cas d’un virement dont le montant dépasse 500, on procède à une vérification du solde du
compte du client.
71
Exemple
Virement Client Local

Client Distant
<<étend>>
Montant > 500
<<Inclut>>
VirementInternet
Identification Vérification solde compte
72
Exemple
Et voici le point d’extension :
Virement
Points d’extension
• Vérification supplémentaire:
après identification
73
Description des cas d’utilisation
Il n’existe pas de norme (UML) établie pour la description textuelle

des cas d’utilisation.
Généralement, on y trouve pour chaque cas d’utilisation :

son nom,
un bref résumé de son déroulement,
le contexte dans lequel il s’applique,
les acteurs qu’il met en jeu,
une description détaillée :
le déroulement nominal de toutes les interactions,
les cas nécessitant des traitements d’exception,
les effets du déroulement sur l’ensemble du système,
etc.
74
Sommaire d’identification
Titre : ……………….. Type : …………………
Résumé :………………………………………………………………………………
Acteurs :
Date de création : Date de mise à jour :…………………………………
Version : Auteur(s) :
Description des Enchaînements :

Pré conditions :
Scénario nominal :
1.
2.
…
Enchaînements alternatifs :
A1…
A2…
Contraintes
….
75
Quelques conseils :
Un cas d’utilisation doit être :
Simple
Décrit de manière claire et concise
Le nombre d’acteurs interagissant avec le CU doit être limité
Lors de la construction d’un CU, il faut se demander :
Quelles sont les tâches de l’acteur ?
Quelles informations l’acteur doit-il créer, sauvegarder, modifier, détruire
ou simplement lire ?
L’acteur devra-t-il informer le système des changements externes ?
Le système devra-t-il informer l’acteur des conditions internes ?
Modélisation objet avec UML

P.A. Muller, N. Gaertner
76
Exemple de Cas d’utilisation
Fonctionnement des caisses enregistreuses d’un super marché :

Un client arrive à la caisse avec des articles à payer.
Le caissier enregistre le numéro d’identification de chaque article, ainsi
que la quantité si elle est > 1.
La caisse affiche le prix de chaque article et son libellé.
Quand tous les achats sont enregistrés, le caissier signale la fin de la
vente.
La caisse affiche alors la fin des achats et le prix total à payer.
Après la saisie des articles, le client peut présenter des coupons de
réduction pour certains articles
Le client choisit son mode de paiement :
Liquide : le caissier encaisse l’argent reçu, la caisse indique le montant à
rendre au client.
77
Un système de caisse enregistreuses de super marché :

Chèque : le caissier vérifie la solvabilité du client en transmettant une
requête à un centre d’autorisation via la caisse.
Carte de crédit : un terminal bancaire fait partie de la caisse et transmet une
demande d’autorisation en fonction du type de la carte.
La caisse enregistre la vente et imprime le ticket.
Le caissier donne le ticket au client.
Quand le paiement est terminé, la caisse transmet l’information sur le
nombre d’articles vendus au système de gestion des stocks.
chaque matin, le responsable du magasin initialise les caisses pour la
journée.
78
Responsable Initialier la caisse

Magasin
<<étend>>
Prendre en compte coupons

Caissier Traiter le passage en caisse
<<Acteur>>
<<inclut>> Gestion des stocks
Client <<Acteur>>
Traiter le Paiement Centre autorisation
cartes
<<Acteur>>
Centre autorisation
Paiement Liquide Paiement Chèque Paiement Carte
chèques
79
Sommaire d’identification
Titre : Traiter le passage en caisse
Résumé : un client arrive à une caisse avec des articles à 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 : Caissier (P), Client (S), Gestion des stock (S)
Date de création : Date de mise à jour :…………………………………
Version : 1 Auteur(s) : FG
Description des Enchaînements :
Pré conditions : La caisse est en service : un caissier y est connecté
Scénario nominal :
Représente le déroulement normal d’un cas d’utilisation : les différentes interactions
utilisateur / système permettant l’exécution réussie du traitement
(voir suite)
80
1. Ce CU commence quand un client arrive à la
caisse avec des articles qu’il veut acheter.
2. Le caissier enregistre chaque article. S’il y a 3. La caisse détermine le prix de l’article et ajoute
plus d’un exemplaire par article, le caissier des informations sur l’article à la vente en cours.
indique également la quantité. La caisse affiche la description et le prix de
l’article en question.
4. Après avoir enregistré tous les articles, le 5. La caisse calcule et affiche le montant total de
caissier indique que la vente est terminée. la vente.
6. Le caissier annonce le montant total au client.
7. Le client choisit le type de paiement :

a. En cas de paiement …
b. En cas de …
c. En cas …
8. La caisse enregistre la vente et imprime …
9. Le caissier donne le ticket de caisse au client.
81
Enchaînement alternatif :
Quand l’enchaînement précisé par le scénario nominal ne peut pas se
dérouler comme prévu :
Le cas d’utilisation converge tout de même.
Exemple:
Numéro d’identification d’un article est inconnu
l’enchaînement démarre au point 2 du scénario nominal.

3. La caisse indique que le numéro d’identification de l’article est inconnu.
L’article ne peut alors pas être pris en compte dans la vente encours.
Le scénario reprend au point 2.
82
Enchaînement d’erreur :
Quand l’enchaînement précisé par le scénario nominal ne peut pas se
dérouler :
Le cas d’utilisation se termine par un échec.
Exemple:
Client ne pouvant payer (ou le centre d’autorisation refuse le payement)
l’enchaînement démarre au point 6 du scénario nominal.
7. Le client ne peut pas payer le total avec aucun des moyens autorisés.
8. Le caissier annule l’ensemble de la vente et le cas d’utilisation se termine
en échec :
la vente ne peut pas avoir lieu
83
Conclusion

Sont de bons moyens pour modéliser les besoins des utilisateurs par les
utilisateurs.
Les avantages :
Un formalisme simple :
Les concepts proposés sont faciles à comprendre et à utiliser.
Les modélisations résultats (UC):
Faciles à comprendre, à lire et à interpréter.
Un bon moyen de communication : client/concepteur et
concepteur/concepteur
Les limitations :
Subjectifs, dépendant de l’utilisateur :
Peuvent être peu précis, ne reflétant pas les besoins majeurs de
l’utilisateur ou interprétés différemment.
Pas formels : pas de vérification automatique possible ni de génération des
autres diagrammes, …
84
Diagrammes de Collaboration
Faïez GARGOURI
ISIM – Sfax
85
Introduction
Les cas d’utilisation ont permis :

aux utilisateurs d’exprimer leurs besoins.
De dresser une première liste des objets et des acteurs constituant le
système.
Les besoins :
Un ensemble de traitements demandés par l’utilisateur
Il faut maintenant détailler ces besoins par les informaticiens
Les détails de ces traitements :

Préciser comment les objets et les acteurs doivent travailler ensemble pour
réaliser chacun de ces besoins (les ellipses)
Les objets et les acteurs composant le système doivent:
Collaborer ensemble pour réaliser les besoins exprimés par les cas
d’utilisation
Les diagrammes de collaboration.
86
Sémantique
Les diagrammes de collaboration :

représentent :
le contexte d'une interaction en y précisant les états des objets en
collaboration (interaction).
présentent :
des rôles joués par des objets dans un contexte particulier et
les liens entre ces objets.
montrent :
des interactions entre objets (instances de classes et acteurs).
les interactions entre ces objets par des envois de messages
87
Sémantique
Les diagrammes de collaboration :

permettent :
une représentation (structure) spatiale des objets, des liens et des
interactions (graphe dont les nœuds = intervenants et les arcs = les
interactions).
Une dimension temporelle (ordre de déclenchement) par l’ajout de numéros
de séquence des messages échangés (on ne représente pas le t de
déclenchement ni la durée).
L’objectif est de construire un modèle expliquant la coopération entre
les objets utilisés pour la réalisation d’une fonctionnalité.
Autrement :
Décrire le comportement collectif d’un ensemble d’objets
En vue de réaliser une opération
en décrivant leurs interactions modélisées par des envois
(éventuellement numérotés) de messages
88
Sémantique
Dans un diagramme de collaboration :

les interactions sont représentées par les échanges de messages.
l’ordre des messages peut être indiqué par leur énumération.
Plusieurs types de messages existent : simples, synchrones, asynchrones
et minutés.
Conventions graphiques :
les objets sont représentés par un rectangle dont le nom et la classe sont
soulignés.
Nom Objet Nom Objet : Classe :Classe
89
Sémantique
Représentation Générale :
3: opération (paramètre)
2 : opération
1 : événement
Objet1 : nom classe Objet 2
4 : opération
5 : opération (paramètres)
Objet 3 :nom de la classe

Nom acteur :
Nom de la classe
Flux de données
90
Concepts de base
Une collaboration :
Est la réalisation d’une opération ou d’un cas d’utilisation dans un
contexte particulier.
Possède deux types de descriptions :
Une description générale au niveau spécification, donnant:

Les rôles joués par les intervenants et les rôles des associations
Une interaction : une séquence de messages partiellement ordonnés
échangés entre les rôles des intervenants
Une description spécifique au niveau instance, représentant :

Une instance particulière d’une interaction avec les objets et les liens
respectant les rôles définis au niveau spécification, et les stimulus
(instances des messages) échangés entre ces objets.
PA Muller, N. Gaertner
91
Concepts de base
La notion de rôle :
Les objets et les associations jouent des rôles particuliers dans une
collaboration.
Exemples :
:C Un rôle anonyme de la C :C Objet anonyme, instance de C
/R:C Un rôle R de la classe C /R:C O. anonyme de C jouant le rôle R
/R Un rôle R /R O. anonyme jouant le rôle R
O/R:C Objet O, instance de la classe C, jouant le rôle R
92
Concepts de base
Représentation au niveau spécification:

Forme un graphe de rôles des intervenants (nœuds) liés à des rôles
d’association (arcs)
Exemple :
Collaboration représentant le fait qu’une maison peut être louée à un ou
plusieurs locataires pour un loyer donné.
/Locataire : Personne
* +habitant
1 +habitation
/Maison : Logement *
1 1
1 + adresse 1 +loyer 1 +loueur
:Lieu :Coût /Propriétaire : Personne
93
Concepts de base
Représentation au niveau instance :

Forme un graphe d’instances qui se conforment aux rôles des intervenants et des
associations définis au niveau spécification
On peut y ajouter des instances de messages échangés
Les objets et les liens utiles pour réaliser une action sont ajoutés
Exemple :
Une instance du diagramme précédent avec :
Un acteur qui déclenche l’opération et des
Stimuli (communication entre objets)
1: revenuDeLocation(pourLesMaisons)
Loueur / Propriétaire :
Personne
:Client
1.1 *[i:=1..n]:loyer()
:Coût 1.1.i : valeur() /Maison:Logement
94
Concepts de base
Représentation au niveau instance :

Généralement :
Les rôles ne sont pas indiqués
Les objets, les liens et les stimuli sont représentés
Exemple :
1:total:=valeurStock()
:Entreprise
1.1.1 : Créer(0,0) :SRéel
:C lie n t
2:afficher(total)
1.1.2.i : ajout(p)
1.1 : calculValeur()
:Stock :Produit
:Afficheur
1.1.2 * [i:=1..n]:p:=ValeurP()
95
Concepts de base
Les messages :
Le terme Stimulus désigne :
Une communication entre objets invoquant une opération ou
L’émission d’un signal ou
la création et destruction d’un objet
Le terme message :
Un message est la spécification d’un stimulus définissant :
Le rôle des objets émetteur et récepteur
L’action qui envoie un stimulus quand elle s’exécute.
Un message est l’avènement d’une communication permettant :
La transmission de certaines informations et
Éventuellement avoir des résultats.
Un envoi de message entre un émetteur et un récepteur nécessite que le
dernier puisse réaliser l’activité définie par le message.
96
Exemple
Considérons le diagramme de cas d’utilisation suivant :
<<Inclut>>
<<Inclut>>
<<Inclut>>
Affectation
lecteurs
97
Exemple
Le diagramme de collaboration correspondant est :

2.1 : Rédiger
2.2 : Envoi de papier
Auteur 1 : Appel à communication Comité

d'organisation
3 : Adresser le papier
Comité 5 : Papier enregistré

programme
6 : Affecter Lecteur
4 : Enregistrer()
7.1 : Evaluer
Lecteur RAPPORT
PAPIER 7.2 : Noter
98
Exemple
Remarques :
Les acteurs du diagramme de cas d’utilisation sont aussi présents au
niveau du diagramme de collaboration
Les cas d’utilisation se transforment en un ou plusieurs messages
échangés entre les intervenants du diagramme de collaboration
Il y a plus d’intervenants et de liens au niveau du diagramme de
collaboration qu’au niveau du diagramme de cas d’utilisation
99
Diagrammes de Séquence
Faïez GARGOURI
ISIM – Sfax
100
Introduction
Les diagrammes de cas d’utilisation ont permis :

aux utilisateurs d’exprimer leurs besoins.
De dresser une première liste des objets et des acteurs constituant le
système.
Les diagrammes de collaboration ont permis de :

détailler les diagrammes de cas d’utilisation.
Préciser comment les objets et les acteurs doivent collaborer ensemble
pour réaliser chacun de ces cas d’utilisation.
Les diagrammes de séquence :

Ajoutent une dimension temporelle aux diagrammes de collaboration.
Se concentrent sur la séquence des interactions selon un point de vue
temporel (durée, arrivée, séquencement, …)
101
Sémantique

permettent de représenter des collaborations entre objets selon un point
de vue temporel :
on s’occupe de la chronologie des envois de messages (durée et instant).
on n'y décrit pas le contexte ou l'état des objets : la représentation se
concentre sur l'expression des interactions
servent à illustrer un cas d'utilisation.
Représentent les aspects dynamiques d’un système.
Représentation Générale :
Objet 1 Objet 2 : classe Objet 3 : classe de l’objet

de l’objet
Opération 2 (paramètres)
Annotations [x] Opération 1
While Y loop Evt 1
End loop
[non x] opération 3
102
Concepts de base
Remarques :
Les objets étudiés sont placés sur la première ligne
Tout objet a une ligne de vie : une barre verticale en pointillée
L’axe temps, dans chaque diagramme, est représenté (implicitement) de haut
vers le bas
L'ordre d'envoi d'un message est déterminé par sa position sur l'axe vertical du
diagramme
Les messages sont représentés par des flèches orientées : émetteur – destinataire.
La disposition des objets sur l'axe horizontal n'a pas de conséquence pour la
sémantique du diagramme.
Les branchements conditionnels sont indiqués par un pseudo-code ou par [ ]
On peut aussi placer en pseudo –code les boucles d’itération.
103
Sémantique

Peuvent être utilisés de deux manières, selon la phase du cycle de vie et
le niveau de détail désiré :
Comme documentation des cas d’utilisation :
Concentration sur la description des interactions
Les flèches indiquent les différents événements échangés entre les
objets et sans entrer dans les détails (au sens implantation)
Appelant Ligne Téléphonique Appelé

Décroche
Remarque : l’intérêt est plus porté sur l’ordre des
Tonalité envois: on ne représente pas les paramètres des
Numérotation échanges, ni la durée, …
Indication sonnerie Sonnerie
Décroche
Début Conversation allo
104
Concepts de base

Peuvent être utilisés de deux manières, selon la phase du cycle de vie et
le niveau de détail désiré :
Avec un usage plus informatique en détaillant :
les différentes interactions entre les objets
La répartition des flots de contrôle
Les messages échangés (procédure, événement, …)
Utilisent les concepts :

Les interactions
Les périodes d’activité
Les envois de messages
Les contraintes temporelles
Les lignes de vie des objets
Les structures de contrôle.
105
Concepts de base
Interaction :
est définie dans le contexte d’une collaboration.
Modélise un comportement dynamique entre objets
Se traduit par l’envoi de messages entre objets
Un objet Un autre objet Encore un objet
Un message
Un autre message
106
Concepts de base
Période d’activation :
Correspond au temps pendant lequel un objet effectue une action
est représentée par une bande rectangulaire :
Le long de la ligne de vie de l’objet
Dont les extrémités représentent le début et la fin de l’activité.
Un objet Objet 1 Objet 2
Durée
d’activation
Remarque : souvent quand l’objet est en activité continue, on néglige la

représentation de cette période d’activation
107
Concepts de base
Les envois de messages :

Le nom de l’opération invoquée ou du signal envoyé
est indiqué sur la flèche représentant le message
Les arguments peuvent être précisés
La numérotation des messages échangés est remplacée par l’ordre
d’apparition des messages (ligne verticale)
Objet 1 Objet 2
t1 Message() Remarque:
t2 > t1 t2
à ti : envoi(Message()) =
réception (Message())
Opération(Arg.)
Temps
108
Concepts de base

Trois catégories de messages sont distinguées :
Les flots de contrôle à plat.
Appel de procédure ou flot de contrôle emboîté.
Retour d’un appel de procédure.
Les flots de contrôle à plat :
Indiquent la progression vers la prochaine étape d’une séquence
Les messages de cette catégorie sont asynchrones (décalés) signalés par une
flèche simple
Expéditeur Destinataire
FC Acquit.
FC : flot de contrôle à plat
109
Concepts de base

Appel de procédure ou flot de contrôle emboîté:
La séquence appelante ne reprend le contrôle que si celle emboîtée se
termine
Les messages de cette catégorie sont signalés par une flèche pleine
Commande Produit Fournisseur
Objet 2 récupère le Objet 1 Objet 2 Objet 3
contrôle quand l’objet 3
Procédure
a fini sa tâche Sous procédure
Objet 1 récupère le Commande Client Catégorie

contrôle quand l’objet
2 a fini sa tâche La fin de la sous-procédure est signalée par la fin de la durée de
l’activation de objet3
110
Concepts de base

Retour d’un appel de procédure
Est implicite à la fin de l’activation de l’objet receveur.
Dans certains cas (messages asynchrones parallèles), il est nécessaire de
montrer ce retour (A)
Cette notation est utilisée aussi pour représenter les retours de paramètres
(résultats d’une exécution). (B)
Les messages de cette catégorie sont signalés par une flèche en pointillé.
Expéditeur Destinataire Expéditeur Destinataire
M. asynchrone Calculer()
Val
(A) (B)
111
Concepts de base

Les messages récursifs
Un objet ENTIER
n!
Les messages réflexifs

Un objet Compte
VérifierSolde()
112
Concepts de base
Les contraintes temporelles :

La flèche représentant un message peut être représentée obliquement :
les délais de transmission non négligeables
Délais de t
transmission t’
Peuvent être présentées dans la marge en nommant les instants

d’émission des messages
Objet 1 Objet 2 Objet 3
X
{y-x < 2s}
Y
113
Concepts de base
Les contraintes temporelles :

On peut utiliser des :
Annotations temporelles (temps : message)
Fonctions temporelles (TempsEnvoi, TempsRéception, …)
Exemple :
: Ascenseur : Porte
:usager
Appel extérieur
Déplacement vers l’étage déplacement
d’appel (pas d’autres appels) a:ouverture
{b.TempsRéception- Ouvrir()
b:ouverte
a.TempsEnvoi < 5 s.}
L’usager peut prendre fermeture { < 8s }
l’ascenseur
Préciser l’étage fermée Fermer()
déplacement
114
Concepts de base
Les lignes de vie des objets :

La ligne de vie d’un objet :
Est représentée par une ligne en pointillée
Peut débuter et s’interrompre dans un diagramme de séquence :
Si l’objet est créé et/ou détruit pendant la durée définie par le
diagramme spécifié
Un objet
Créer Un autre objet

…
Détruire
X
Temps X : La fin de vie
115
Concepts de base
Les structures de contrôle :

Contrôle centralisé (A) et contrôle décentralisé (B)
A B C D A B C D
(A) (B)
116
Concepts de base

Les diagrammes de séquence peuvent être complétés par :
des indications textuelles exprimées :
sous forme de texte libre ou pseudo-code.
A B C
Message1
x
Message2
(y-x <2s) y
Message3
(z-y<1s) z
Message4
t
(t’-t<2s) t’
117
Concepts de base

Exemple de boucle While :
While X loop Remarque:

Message
X : condition(s)
End loop
OU Expéditeur Destinataire
*[X] Message
118
Concepts de base

Exemple de branchements conditionnels :
A B C
If X Message1
else
Message2
End If
OU A B C
[X] Message1
[non X] Message2
119
Conclusion & remaruqes

Sont un bon moyen pour représenter les interactions, organisées dans le
temps, entre les objets
S’approchent plus de l’implémentation avec l’utilisation des boucles,
des structures de contrôles, …
Un des avantages :
Détecter les erreurs qu’on ne voit d’habitude qu’au niveau implémentation
: interblockage d’appels, …
Toutefois :
• Remarque : Ces diagrammes sont plus appropriés pour les
applications critiques et temps réel plus que les applications de
gestion (le temps n’est pas un paramètre fort)
120
Exemple
Reprenons l’exemple suivant :

2.1 : Rédiger
2.2 : Envoi de papier
Auteur Comité
1 : Appel à communication
d'organisation
3 : Adresser le papier
Comité
5 : Papier enregistré
programme
6 : Affecter Lecteur
7.1 : Evaluer
4 : Enregistrer
Lecteur RAPPORT
7.2 : Note
PAPIER
121
Exemple
Comité Auteur PAPIER Lecteur Comité de RAPPORT

d'organisation programme
Appel( )
Rédiger( )
Envoi
Adresser le papier
Enreg_papier(true)
Papier enregistré
Affecter_lecteur( )
Evaluer( )
Noter( )
Papier évalué
122
Diagrammes d’objets
Faïez GARGOURI
ISIM – Sfax
123
Introduction
Servent durant la phase exploratoire de l’analyse

Représentent la structure statique du système modélisé.
Montrent :
des objets (instances de classes) dans un état particulier et
des liens (relations sémantiques) entre ces objets.
Position des diagrammes objets dans un processus de modélisation :
Use Cases Spécifications
Diag. objet
Conception Modèles dynamiques
124
Concepts de base
Un diagramme d’objets:
est une instance d’un diagramme de classes
Montre un contexte particulier (objet + lien)
facilite la compréhension des structures de données complexes.
Représentation des objets :
Un objet est représenté par un rectangle qui contient :
le nom de l'objet ou,
le nom et la classe de l'objet ou
la classe de l'objet.
Objet anonyme
Nom Objet Nom Objet : Classe :Classe
Mohamed Mohamed : PERSONNE :PERSONNE
125
Concepts de base
Représentation des objets :

Un groupe d’objets :
:Personne
Le rectangle représentant un objet peut comporter une partie contenant

les valeurs des attributs de l’objet :
Ahmed : ADHERENT : VOITURE

Nom = Mohamed Couleur = rouge
Prénom = Ahmed Puissance = 4
Adresse = Sfax Marque = Peugeot
126
Concepts de base
Représentation des liens entre objets :

Les liens entre objets sont :
Des instances des associations entre les classes des objets participants
Permettent une représentation plus concrète que celle produite par les
diagrammes de classes.
Exemple :
1 1
V1:Voiture :Moteur Voiture Moteur
1
4
R1:Roue R3:Roue R2:Roue R4:Roue Roue
Diagramme d’objets Diagramme de Classes
Remarque : le problème se complique avec les camions !!! illisible

127
Concepts de base
Représentation des liens entre objets :

Les liens entre objets peuvent être naires.
Exemple :
: Professeur
: Salle : Etudiant
On peut indiquer les noms des objets et des liens :
Ahmed : ADHERENT
Nom = Mohamed emprunter
Soukaria : EXEMPLAIRE
Prénom = Ahmed
Adresse = Sfax
128
Concepts de base
Représentation des objets composites :

Un objet composite est composé d’autres objets (sous-objets)
Le nombre d’instances du composant peut être spécifié
Un Composite
:Partie1 :Partie2
Exemple:
Eau : Molécule
Hydrogène : Atome 2
Oxygène : Atome 1
Remarque :
Ces diagrammes ne sont utiles que durant la phase exploratoire d’un
domaine.
Ils deviennent vite compliqués et illisibles
129
Diagrammes de classes
Faïez GARGOURI
ISIM – Sfax
130
Introduction
Les diagrammes d’objets montrent :

des objets (instances de classes dans un état particulier) et
des liens (relations sémantiques) entre ces objets.
Les diagrammes de classes expriment la structure statique d’un
système en termes :
De classes et de relations entre elles et
Un ensemble d’interfaces et de paquetages ainsi que leurs relations.
Est une instance de
1,N 0,N
Lien Objet Relation Classe
1, N 1, N
Est une instance de

131
Introduction
Les interfaces :
comment on voit/utilise le système modélisé
les paquetages :
comment on peut abstraire le système en macro-composants
Les classes :
classes réelles
classes paramétrables/génériques
classes abstraites
classes interfaces
Les relations :
associations binaires
associations n-aires
agrégation/composition
généralisation/spécialisation
132
Concepts de base
Avec UML, une classe :

est un type abstrait avec des caractéristiques (P et M) communes à un
ensemble d'objets.
permet de créer des objets ayant ces caractéristiques.
A un nom unique dans son paquetage
Est représentée par un rectangle avec:
Propriétés
Méthodes et Nom de Classe
Exceptions / Conditions. Propriétés
Méthodes
Exceptions
Classe = propriétés + méthodes + instanciation
133
Concepts de base
Pour une classe :

on peut ne pas :
Représenter ses propriétés ou ses méthodes sur un diagramme,
un filtre visuel pour donner un certain niveau d'abstraction à son
modèle.
Spécifier les niveaux de protection des membres d'une classe
ne veut pas dire qu'on ne représente que les membres publics.
Représenter les trois compartiments, en se limitant à son nom :
Généralement seuls les deux premiers sont utilisés.
Le nom de la classe, selon la norme UML est en gras, mais on peut se
limiter à l’écrire en majuscule.
Une propriété d’une classe constitue un élément de l'état de l'objet
((permet de caractériser l’objet)
Une opération représente un service spécifique offert par un objet
134
Concepts de base
Les attributs et les opérations :

Sont décrits dans le deuxième et troisième compartiments
Peuvent être précisés par : attributs et opérations
Nom de Classe
NomAttribut [: type = valeur
initiale]
Opération ()
les ( ) indiquent que la liste des opérations n’est pas complète

Remarques :
L’ordre opération / attribut = attribut / opération
Opération = méthode = fonction-membre, …
Attribut = propriété = donnée-membre, …
135
Concepts de base
La syntaxe de description des attributs est :
Visibilité NomAttribut [[Multiplicité] :

Type [=ValeurInitiale] [{Propriété}]]
Visibilité = type d'accessibilité :

+ : public, visible et modifiable par tout objet du même paquetage
-: private, seulement visible et modifiable par les opérations de l'objet
auquel il appartient.
# : protected, seulement accessible et modifiable par les opérations des
classes descendantes
Multiplicité : intervalle ou nombre
Propriété : mutabilité (gelé, variable, ajout Uniquement, …)
136
Concepts de base
Le type des attributs peut être :

Un type primitif : Entier, chaîne, …
Une classe (type utilisateur) : Etudiant, Rectangle, …
Expression complexe non supportée par UML
Multiplicité : intervalle ou nombre

Multiplicité :=(Intervalle|nombre)[,Multiplicité]
La mutabilité :
Gelé : attribut non modifiable (const de C++)
Variable : propriété par défaut, précise que l’attribut est modifiable
Ajout Uniquement : seul l’ajout est possible (multiplicité >1)
137
Concepts de base
Un attribut peut être dérivé (/Attribut) :

peut être déduit par application d’une formule sur d’autres attributs.
qui conduit en implémentation à une opération
RECTANGLE RECTANGLE
OU
Longueur Longueur
Largeur Surface = Largeur
/Surface
longueur * largeur
Opérations Surface ()
Remarque générale :
Une opération : un service qu’une instance de la classe peut réaliser.
Une méthode est l’implémentation d’une opération.
Dans le cadre de ce cours : opération = méthode
138
Concepts de base
Exemple :
CANAL
}
TELEVISION
-on/off : BOUTON HAUT-
-couleur : énum {gris,noir} PARLEUR Classes
-marque :Chaîne
-télétexte : Boolean = Vrai
-chaînes [2..*] : CANAL
BOUTON
-prix : Réel
-hautparleur [2..6] : HAUT-PARLEUR <<énumération>>
-type : TypeTV{gelé} … TypeTV
- 16 / 9
- 3/4
Les stéréotypes : des mécanismes d’extension prévus par UML. Appliqués aux
classes, ils permettent d’avoir des classes particulières répondant à un besoin donné.
Exemples: énumération, interface, utilitaire, …
139
Concepts de base
La syntaxe de description des opérations est :

Visibilité NomOpération [[Arguments] :
TypeRetourné [{Propriété}]]
Visibilité : +, -, #
Arguments :
Direction NomArgument : TypeArgument
[= ValeurDefaut]
Direction : in, out, inout (in est la valeur par défaut)

In : argument est un paramètre en entrée seule ; non modifié par
l’exécution de cette opération
Out : argument est un paramètre en sortie seule; l’appelant peut
récupérer les informations
inOut : argument est un paramètre en entrée-sortie; passé à l’opération et
modifiable
140
Concepts de base
Propriété :
requête,
concurrence,
abstrait,
estFeuille,
estRacine
Visibilité et portée des attributs et des opérations:
Classe
+Attributpublic
#Attributprotégé Attribut de classe
-Attributprivé
AttributDeClasse Visibilité globale: l’attribut est
considéré comme un objet partagé
Idem pour les par les instances d’une classe
opérations
141
Concepts de base
Les compartiments Exceptions et Responsabilité :

Ne sont pas obligatoires
Pas de syntaxe standard pour la définition de ces compartiments
Exemple :
GAB
Attributs
- état
Responsabilité
{
Consultation de compte
Retraits et dépôts d’argent
Use cases Impression de relevé de compte
Exceptions
Carte non valide
Code secret incorrect
142
Concepts de base
Constatations :
Les cas d’utilisation nous ont permis de définir les acteurs du système
Lors de la construction des diagrammes d'interaction (séquences et/ou
collaboration) que les objets réels sont identifiés
Au niveau du diagramme de classes :
Les objets réels sont transformés en classes s'il y a des messages échangés
(si non en attribut)
Les opérations publiques des classes correspondent aux messages échangés
entre objets réels
143
Concepts de base
Les interfaces :
Décrivent le comportement visible de certaines classes :
fournit une vue totale ou partielle d'un ensemble de services offerts par une
classe, un paquetage ou un composant.
Peuvent être vues comme des classes particulières :

ne figurent que des opérations publiques
pas d'attributs
présence du stéréotype <<interface>>
Les éléments qui utilisent l'interface peuvent l’exploiter totalement

(préciser le code de toutes les méthodes) ou en partie (ne pas préciser
tout le code).
Une Classe
A DEPLACER
Une interface
144
Concepts de base
Exemple d’interface :
<<Interface>> CollectionOrdonnée
Comparable
contenu : liste de Un objet
L’interface SupérieurA() Comparable de type
InférieurA() interface
égaleA()
différentDe()
CollectionOrdonnée contient des objets comparables
CollectionOrdonnée
comparable contenir
EntierNaturel A DEPLACER
EntierNaturel implémente Comparable
145
Concepts de base
Classe paramétrable = classe template (C++) classe générique

Un modèle de classes
classe sans instances
Ne peut être utilisée telle quelle :
Il faut lier les paramètres formels à des paramètres effectifs
classe surtout utilisée en implémentation
les paramètres de généricité sont identifiés dans le rectangle à traits
tiretés
une classe instance est liée à une classe paramétrique par une flèche
tiretée
Paramètres
formels
Classe paramétrable A DEPLACER
146
Concepts de base
Exemple de classe paramétrable

Element, NbLignes,
Tableau NbColonnes
A DEPLACER -éléments[NbLignes, NbColonnes] de Type
+Elément(ligne,colonne):Type
+Elément(t:Type, ligne,colonne)
<<lie>>(Case,8,8)
Un objet Tableau<Réel, 3, 3>
Une classe Echiquier
Remarque : une classe paramétrable peut être considérée comme généralisation du

concept d’interface : en donnant le comportement et la structure de données « communs
» à plusieurs autres classes
147
Concepts de base
Classe utilitaire = représente des bibliothèques

joue un rôle d'élément global contenant des opérations et/ou des attributs
présence du stéréotype <<utilitaire>>
Une classe utilitaire permet de grouper des éléments au sein d’un
module sans en construire une classe complète.
font partie des mécanismes d’extensibilité, prévus dans UML
<<utility>> Encapsuler des constantes et des fonctions dans une

Math classe utilitaire
Pi
sin() Remarque :
cos() Au concept de classe correspondent les stéréotypes :
...
interface, énumération et utilitaire.
A DEPLACER
148
Concepts de base
Les relations entre classes :

Association Remarque : par rapport au modèle E/A de base
Agrégation
RC UML + riches sémantiquement et + proches de la réalité
Composition
Héritage
Les associations :
Une association exprime une connexion sémantique bidirectionnelle entre
n classes (n>=1).
Une association est instanciable dans un diagramme d'objets ou de
collaboration sous forme de liens entre objets issus des classes associées.
ADHERENT
Nom emprunter
EXEMPLAIRE
Prénom
Adresse
149
Concepts de base
Constatations :
Association
Diagramme de classes C1 C2
Lien
:C1 :C2 :C1 :C2
Diagramme d’objets Diagramme de collaboration
150
Concepts de base
Les associations :
représentent des liens statiques/conceptuels entre objets et à longue
durée de vie (n’est pas un lien instantané ni passager).
Relient une ou plusieurs classes : arité 1 ou plus
Par rapport au modèle Entité / Association :
Entité 1 Entité 2
Card1 Card2
Diag. Entité / P11, Ass P21,
Association P12 P22
… …
Card2 Card1
Diag. De CEntité1 CEntité2
classes
151
Concepts de base
Arités des associations :

Une association peut être binaire ou naire (à éviter).
Exemple : on désire représenter le fait suivant : un Professeur enseigne
dans une salle des étudiants.
PROFESSEUR
Enseigner
SALLE ETUDIANT
Si on veut matérialiser le cours

COURS
Association porteuse de données
152
Concepts de base
Les associations : Nommage

Une association peut être nommée
[ Nom Association ]
Classe1 Classe2
Comment justifier la non obligation du nom de l’association :

Aux niveaux conception et implantation
Sens de lecture d’une association :

Association en forme verbale active (ou passive) :
précise le sens principal de lecture d'une association (> ou <).
Est Employée Par>
HÔTEL héberge> PERSONNE PERSONNE SOCIÉTÉ
Association en forme verbale active Association en forme verbale Passive
153
Concepts de base
Association à navigabilité restreinte :

Par défaut, une association est navigable dans les deux sens.
On peut la limiter à un seul sens dans un modèle (et non lors de
d'implémentation).
indique que les instances d'une classe ne "connaissent" pas les
instances d'une autre. ELECTEUR vote CANDIDAT
Connaître
ETUDIANT ENSEIGNANT
Les associations : Notion de rôle
Rôle des associations (utilisé pour les associations ambiguës) :
spécifie la fonction d'une classe pour une association donnée
Client Parents
HÔTEL PERSONNE PERSONNE
Directeur Enfants
154
Concepts de base
La notion de rôle :
[ Nom Association ]
Classe1 Classe2
[Rôle1] [Rôle2]
Rôle 1 : le rôle joué par Classe 1 dans l’association

Rôle 2 : le rôle joué par Classe 2 dans l’association
Professeur Etudiant
Enseigne Est Enseigné
155
Concepts de base
Les associations : Cardinalités

précisent le nombre d'instances qui participent à une relation.
Combien d’objets de la classe considérée peuvent être liés à un objet de
l’autre classe?
1 Un et un seul
0 .. 1 Zéro ou un
N N (entier naturel)
M .. N De M à N (entiers naturels)
* De 0 à plusieurs
0 .. * De 0 à plusieurs
1 .. * De 1 à plusieurs
156
Concepts de base
Les associations : Contraintes

des expressions qui précisent le rôle ou la portée d'un élément de
modélisation
permettent d'étendre ou de préciser la sémantique
permettent de restreindre le nombre d'instances visées
peuvent s'exprimer en :
Langage Naturel ou
graphiquement avec un {texte} ou
En OCL (Object Constraint Language)
Les types de contraintes exprimables sur les associations :
Ordonné;
Sous-ensemble;
Ou-exclusif, …
157
Concepts de base

Ordonné :
PERSONNE 1 0..* COMPTE

{ordonné}
La collection des comptes d’une personne est triée
Sous-ensemble :
SERVICE 1 affecter 1..* EMPLOYE

Numéro_S Numéro
{sous-ensemble} Nom
Nom_S
... ....
0..1 diriger 1
158
Concepts de base

Ou-exclusif :
Indique que pour un objet donné, une seule association est valide
BATTERIE
PORTABLE {Ou-exclusif}
Alimenter SECTEUR
Cette contrainte permet d’éviter l’introduction de classes artificielles
Alimenter ENERGIE
PORTABLE
SECTEUR BATTERIE
159
Concepts de base
Classe d'association :
est une classe qui réalise la navigation entre les instances d'autres
classes.
représente les associations porteuses de données.
Passe >
ETUDIANT EXAMEN
NOTE
Remarque : classe d’association (Cde, Client, Facture)& attribut de lien
(Cde, produit, QteCdée)
Qualification :
permet de sélectionner un sous-{} d'objets, parmi ceux participant à une
association.
est définie par une clé, qui permet de sélectionner les objets ciblés.
Personne 0..1 E-mail Réseau
160
Concepts de base
L’agrégation :
Est une association non symétrique,
Exprime un couplage fort et une relation de subordination.
Représente une relation de type "ensemble/élément".
Peut notamment (mais pas nécessairement) exprimer :
qu'une classe (un "élément") fait partie d'une autre ("l'agrégat"),
qu'un changement d'état d'une classe, entraîne un changement d'état d'une
autre,
qu'une action sur une classe, entraîne une action sur une autre.
Une instance d'élément agrégé peut :
être liée à plusieurs instances d'autres classes :
l'élément agrégé peut être partagé (dans le temps)
exister sans agrégat (et inversement)
les CV de l'agrégat et de ses éléments agrégés peuvent être indépendants :
La création de l’un n’implique pas celle de l’autre
161
Concepts de base
L’agrégation
Relation entre les CV des objets:
CV de l’agrégat1 CV de l’agrégat2
CV élément 1
CV élément 2
CV élément 3
CV élément 4
Temps
Créer() Supprimer()
162
Concepts de base
Composition :
La composition est une agrégation forte.
Les cycles de vie des éléments (les "composants") et du composé
coïncident :
si le composé est détruit (ou copié), ses composants le sont aussi.
une instance de composant ne peut être liée qu'à un seul composé.
Les "objets composites" sont des instances de classes
composées.
COUVERTURE LIVRE CHAPITRE
Agrégation Composition
Remarque : toutes les conventions relatives aux cardinalités restent
valables pour les Agrégations et les compositions
163
Concepts de base
La composition :
Relation entre les CV des objets:
CV du composé
CV composant 1
CV composant 2
CV composant 3
CV composant 4
Temps
Créer() Supprimer()
164
Concepts de base
La généralisation :
L’héritage, avec UML, est désigné par GENERALISATION
La généralisation peut être
Simple ou
GENARALISATION
Est Un
SPECIALISATION
Multiple :
La spécialisation a plus qu’une généralisation
Remarque : une classe généralisée peut être spécialisée selon ≠ critères
165
Concepts de base
Contraintes et propriétés de la généralisation :

La contrainte exprimée par le mot-clé {disjoint}
Tout objet est au plus instance d’une seule sous-classe
La généralisation, par défaut, symbolise une décomposition exclusive.
La contrainte exprimée par le mot-clé {chevauchement}
Une classe descendante ∈ au produit cartésien de ses classes généralisées
VEHICULE
Premier Deuxième
critère critère
Motorisation Milieu
{10/06} {chevauchement}
A VOILE A MOTEUR TERRSETRE MARIN
LES DEUX
166
Concepts de base
Contraintes et propriétés de la généralisation :

La contrainte exprimée par le mot-clé {complet}
Indique que la généralisation est terminée :
Il n’est pas possible d’ajouter d’autres sous-classes
La contrainte exprimée par le mot-clé {incomplet}
Indique que la généralisation est extensible : elle peut avoir d’autres
spécialisations
COURS
{incomplet}
COOSI IA GL BDA
167
Concepts de base
Les packages :
regroupent des éléments de modélisation (EM) : classes, associations et
packages.
encapsulent des EM correspondant à une fonctionnalité particulière.
servent de "briques" de base dans la construction d'une architecture
logicielle (par réutilisation)
représentent le bon niveau de granularité pour la réutilisation.
CLIENT Vision Micro. Vision Macro.
Client
Commande CLIENT FACTURATION
*
concerner 1
1 acheter
Facturation:: * Relation
Facture Produit d’utilisation
COMPTABILITE
Utiliser la classe Facture du package Facturation
168
Diagrammes d’Etats - Transitions

Faïez GARGOURI
ISIM – Sfax
169
Introduction
Jusqu’à présent :
On a étudié le système comme « un tout » :
Cas d’utilisation du système
Diagrammes d’interaction du système
Diagramme des objets du système
Diagramme de classes du système
Une vue d’ensemble sur le système
On veut s’occuper maintenant de chaque classe du système :

Selon des points de vue différents
Aspect dynamique de chaque classe :
• Diagramme états – transitions de cette classe
170
Introduction
Les objets d’une classe ne sont pas figés :

Ils peuvent évoluer et changer d’états au cours de leur CV.
CV : cycle de vie = durée de vie : depuis sa création jusqu’à sa
suppression
Un DET d’une classe est une description des évolutions possibles de
ses objets donnant :
la liste des états que peut prendre l’objet durant son CV ;
les événements déclenchant les changements d’états;
les éventuelles conditions qu’il doit vérifier avant de changer d’états et
les opérations qui le font passer d'un état à un autre.
Un DET est une description des changements d'états d'un objet (ou
d'un composant) :
en réponse aux interactions avec d'autres objets/composants ou avec des
acteurs.
171
Sémantique
Une classe n’a pas obligatoirement un DET, mais peut en avoir

plusieurs.
L'ensemble des diagrammes DET forme une partie du modèle
dynamique du SI modélisé.
Les conventions graphiques représentant un changement (une
transition) d’états sont :
Evt([Att]) [Condition(s)]/Action
Etat i Etat j
Ti Tj
A l’instant Ti, suite à l’arrivée d’un événement Evt, ayant les attributs
Att et sous certaines conditions, l’objet passe de l’Etat i à l’Etat j par
l’activation de l’action Action
172
Concepts de base
ETAT D’UN OBJET

est la valeur de l’objet durant le laps de temps séparant la réception de
deux événements;
la valeur d'un objet est déterminée par l’ensemble des valeurs de ses
caractéristiques (Propriétés, Méthodes,Liens).
Un état :
se caractérise par sa durée et sa stabilité,
est une conjonction instantanée des valeurs des caractéristiques d'un objet.
Dans un DET, on distingue deux états particuliers :
- L’état initial :état avant la création de l’objet et
- L’état final :état après la destruction de l’objet.
Utilité de ces états particuliers (l’état initial et l’état final)
173
Concepts de base
ETAT D’UN OBJET

Remarques :
1- La seule opération possible, partant de l’état initial est ................
2- L’état final correspond à un état ............... à partir duquel l’objet ne peut plus
..........
3- Aucune ............. ne peut avoir comme origine l’état ................
4- Les opérations conduisant à un état final sont, par exemple ......... ou ......... ou
.........
5- Dans un DET on peut ne pas avoir des états particuliers (initial ou final),
comme on peut avoir plusieurs.
Une opération sur un objet est soit une action ou une activité :
une action est une méthode faisant passer l'objet d'un état à un autre;
une activité est un ensemble d'actions.
174
Concepts de base
EVENEMNT
Permet les échanges de données entre les objets;
N'a pas de durée déterminée;
Les événements sont groupés par classes.
Typologie des événements :
Evénements externes
Evénements internes;
Evénements temporaires.
La spécification complète d’un événement comprend :
Le nom de l’événement
La liste des paramètres éventuels
L’objet expéditeur
L’objet destinataire
La description de la signification de l’événement.
175
Concepts de base
TRANSITION
représente le passage instantané d'un état vers un autre.
Evt([Att]) [Condition(s)]/Action
est déclenchée par un événement : l'arrivée d'un événement qui

conditionne la transition.
peut aussi être automatique, lorsqu'on ne spécifie pas l'événement qui la
déclenche.
peut être conditionnée à l'aide de "gardes" :
expressions booléennes, exprimées en langage naturel
et encadrées par des crochets.
Entrée Stock [QteDispo<QteMin]
Disponible ¬ Disponible
Sortie Stock
176
Concepts de base
TRANSITION
Une garde (ou condition de garde) :
Est une condition booléenne dont dépend le déclenchement d’une transition
lors de l’occurrence d’un événement.
Evt [Condition]
Etat A Etat B
Est évaluée dès l’arrivée de l’événement de déclenchement.
Etat A
Il fait trop chaud Il fait trop chaud
[été] [hiver]
Climatiser Aérer
177
Concepts de base
TRANSITION
Les transitions composites :
Factorisent et partagent des connexions :
Plusieurs transitions peuvent se rejoindre puis partager des actions
Une transition peut se séparer en des connexions mutuellement
exclusives
Pré-traitement Pré-traitement
OU validation
Validation Validation
[nb-éléments=1] [nb-éléments>1]
[nb-éléments=1]
[nb-éléments>1]
Traitement Traitement Traitement Traitement

individuel Par lot individuel Par lot
178
Concepts de base
TRANSITION
Les points de jonction statique :
Les gardes notées après le point d’interaction sont évaluées avant que la
transition ne soit empruntée
Les points de jonction dynamique :
Les gardes situées en aval du point de jonction sont évaluées quand le point
de jonction est atteint
Commande
Validation/ somme := Prix()
[somme=0] [sinon]
[somme<500]
Annulation Traitement Vérifier Appro. compte
179
Concepts de base
PLUS SUR LES ETATS

On peut préciser les actions à exécuter quand l’objet est à un état donné :
Entrée : action à exécuter dès l’entrée à l’état.
Sortie : action à exécuter lors de la sortie de l’état.
Faire : activité à exécuter (activité = opération dont le temps d’exécution est
important) pendant que l’objet est dans un état particulier.
inclure : introduit une invocation d’un sous-automate
action interne provoquée par un évènement sans provoquer un
changement d’état.
Nom de l’état
AJOUTER EXEMPLES Entrée / action en entrée

Sortie / action à la sortie
Faire / une activité
Inclure / sous-automate
180
Concepts de base
PLUS SUR LES ETATS

Pour plus de clarté des RC, UML permet la généralisation des états d’un
objet :
l’état le plus générique : super-état et l’état le plus spécifique : sous-état.
un état peut être composé en sous-états.
Représentation générale :
Etat initial du
super-état
Super-état Marche
Etat A Sous-état 1 Arrêt Première
Sous-état 2 Deuxième
DET d’une voiture

181
Exemple
Gestion commerciale :
Quand on gère un stock de produits, il est nécessaire de prévoir, à tout
moment, les différents états possibles de notre stock et ce, pour chaque
produit stocké. Généralement, quand on crée un nouveau produit il est
automatiquement mis "en rupture de stock". Il ne sera disponible que s’il
y a une entrée (une livraison d’une commande de ce produit). Pour bien
gérer les commandes de ce produit en cas de rupture de stock, on se fixe
une quantité minimale (QteMin) au dessous de laquelle on commande
systématiquement le produit. QteMin servira à comparer la quantité
disponible (QteDispo) du produit et à lancer la commande du produit si
elle est inférieure à QteDispo. Une fois commandé, on doit attendre la
livraison du produit pour qu’il redevienne disponible. Quand un produit
est disponible, toute opération de retrait ou d’ajout ne le fait pas changer
d’état. Donner, en utilisant les conventions UML, le diagramme d’états-
transitions de l’objet Produit.
182
Exemple
Entrée Sortie
[QteDispo < QteMin]

Disponible En rupture
MAJProduit(QteDeMAJ)
CommanderProduit(QteCdée)
Livré Commandé
LivrerProduit(QteLivrée)
183
Diagrammes d’activités
Faïez GARGOURI
ISIM – Sfax
184
Introduction
Norme OMG-UML 1.4 page 3.156 : Le diagramme d’activités

est une variante du diagramme d’états dans lequel un état peut
être caractérisé par une action ou une activité.
Un diagramme d’activités peut être rattaché à un use case, à un

paquetage ou à l’implantation d’une méthode.
Il s’agit de diagramme d’états vu sous forme « procédurale »

avec une mise en évidence des actions/activités (d’où son nom).
185
Introduction
Les diagrammes d’activités :

Permettent de représenter graphiquement, en termes d’action :
le comportement d'une méthode ou
le déroulement d'un cas d'utilisation.
Représentent l’état d’exécution d’une méthode sous la forme d’un
déroulement d’étapes :
Ils sont considérés comme une variante des diagrammes d'états-transitions.
Une activité est :

une exécution d'un mécanisme:
un déroulement d'étapes séquentielles.
un automate à deux états
la transition entre les états est conditionnée par une fin d’activité.
186
Concepts de base
Une transition peut être automatique ou gardée.

Une transition automatique est :
représentée par une flèche simple,
franchie quand l’activité précédente est finie.
Une transition gardée est :
représentée par une flèche avec une condition entre crochets,
franchie si la condition est vérifiée.
OU
Activité Mesurer la température Mesurer la température
[trop froid] [trop chaud] [trop froid] [trop chaud]
Autre Activité Chauffer Refroidir

Chauffer Refroidir
Transition automatique Transition conditionnée
187
Concepts de base
Remarques :
Une transition est déclenchée par la fin d‘une activité et provoque le
début immédiat d'une autre.
En théorie, tous les mécanismes dynamiques pourraient être décrits par
un diagramme d'activités, mais seuls les mécanismes complexes ou
intéressants méritent d'être représentés (faisant intervenir plusieurs
objets, créant ou modifiant divers objets, …).
Synchronisation :
Il est possible de synchroniser les transitions à l'aide de barres de
synchronisation (BS)
Une BS permet d'ouvrir et/ou de fermer des branches parallèles au sein
d'un flot d'exécution.
Les transitions qui partent d'une barre de synchronisation ont lieu en
même temps.
Activité 1
La fin de A1 engendre les
débuts simultanés de A2 et A3
Activité 2 Activité 3
188
Concepts de base
Synchronisation :
On ne franchit une barre de synchronisation qu'après réalisation de
toutes les transitions qui s'y rattachent.
Activité 1 Activité 2 Le début de A3 ne se fait que

si A2 et A1 soient terminées
Activité 3
Exemples :
Arrêter le Aérer Décider de

chauffage refroidir
Mesurer la Arrêter Aérer

température chauffage
189
Concepts de base
Un diagramme d’activité sert à modéliser :

les flots de contrôle
les flots de données
Conséquence :
les états représentent des calculs
il n’y a pas d ’événements externes mais des attentes

de fins de calculs
il peut y avoir de la concurrence entre activités
Un diagramme d ’activité traduit un organigramme avec en

plus de la concurrence
190
Concepts de base
Expression des tests : Etat initial

Turn<10
menu
[highscore] [start] [exit]
view Start
Highscore turn=0
Etat final
Rol lDice
turn++
[true]
Turn<10
[false]
Source : Internet: WWW. …
Update
highscore
191
Concepts de base
Source : Internet …
192
Concepts de base
Couloirs d'activités :
Les diagrammes d’activités peuvent être découpés en couloirs d'activités.
Un couloir d'activité visualise la responsabilité des objets au sein du système
modélisé.
Les couloirs d’activité permettent d'organiser un diagramme d'activités
Consommateur Vendeur Stock

Demande
Service
Prendre Cde
Délivrer
Payer
Colis
Délivrer
facture
Prendre
Colis
193
Concepts de base
194
Concepts de base
Ligne de vie :
On peut visualiser clairement les objets dans un diagramme d’activité
On peut associer à chaque objet :
Une ligne de vie et
Ses activités.
La manipulation d’un objet peut modifier son état.
Sur un diagramme d’activités, on peut :
Indiquer l’état d’un objet :
dans le symbole de l’objet avec des crochets [état]
Visualiser les objets créés par les activités
À travers une flèche en pointillé reliant :
L’objet à l’activité qui l’a crée. (l’a modifié ????)
195
Concepts de base
Client Vendeur Stock
Demande service
D. ET + D. Séquence
Commander
Commande = D. Activités
[passée]
Facturer
Payer Commande
Livrer colis
[payée]
Bon de
livraison
196
Remarques
Dans un diagramme d’activité on représente :

Les intervenants.
Les activés de chaque intervenant.
Les transitions et synchronisations nécessaires entre activités.
Les états engendrés (crées ou modifiés) par les activités.
L’ordonnancement des activités (temps ).
Les contraintes dynamiques.
197
Remarques
Remarques générales sur les diagrammes d’activités :
Niveau global :
donne une vue macroscopique de l’enchaînement des fonctionnalités
correspond à la traditionnelle décomposition hiérarchique fonctionnelle
Niveau simple :
permet, pour un objet donné, d’exprimer graphiquement une activité du
diagramme d’états transitions sous forme d’un algorithme
traduction directe possible dans un langage de programmation OO (Java,
C++, …)
198

Uml PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Uml PDF

Transféré par

Droits d'auteur :

Formats disponibles

Introduction aux Systèmes d’information

Conception orientée objet des systèmes

On peut décomposer le terme Système d'Information en :

Un système d'information doit permettre les fonctions suivantes :

EVOLUTION STRUCTURE ACTIVITE

Flux FINANCIER FINANCIERS

Exemple de Système opérant

Exemple de Système de pilotage

- Factures D’INFORMATION - Bon de

- Plan de relève - Relevé de consommation

Les applications informatiques ont subi d’importantes évolutions :

Années Données Correspondance : Processus de Langage/SGBD

60 - 70 Structures (1,N) Systèmique Réseau/Hiéra/

Plus fonctionnalités ++ complexité ++

Une méthode = un langage (modèles+concepts+règles

Les approches fonctionnelles

Première génération de méthodes d’analyse et de conception des

Les approches systémiques

Deuxième génération de méthodes d’analyse et de

Les approches orientées objet

Dernière génération de méthodes d’analyse et de conception

Exemples de méthodes objet

Les différents points de perception d’un systèmes :

Concepts & Démarches orientés objet

Données Traitements Echange de messages

Personne Nom, Prénom, Adresse, ...

Cours, Diplôme, ... Enseignant Etudiant Année, ...

Remarques concernant L’HERITAGE

L’opération Afficher() s’applique à une fenêtre et à une personne

Utilités (au niveau implantation) :

Principales étapes de conception objet

Principales étapes de conception objet

Identification des objets et des classes :

Utiliser les classes prédéfinies dans la bibliothèque de classes.

Adapter les classes prédéfinies au contexte de l'application à développer.

Ne pas hésiter à diviser une méthode en deux si elle devient

Chaque méthode d’une classe doit assurer une fonction élémentaire.

Réduire au maximum le nombre de méthodes dans une même classe;

Identification des liens entre les classes :

Identification des sous-systèmes :

Décrire les objets : Contrôler les

Modèle fonctionnel Décrire le fonctionnement

1. Introduction et Remarques Générales

3. UML - les diagrammes

4. UML - les concepts de base

5. Comment concevoir avec UML ?

L’approche objet est la dernière proposition dans l’A et la C des SI,

L’approche objet permet de :

Coût de production d’une application informatique

Suite à cette multitude de propositions:

UNE JUNGLE MÉTHODOLOGIQUE

Plusieurs propositions de méthodes unifiées :

Sous forme de langage :

Unification des concepts et des modèles de principalement trois

Nombreux partenaires IBM, Microsoft, DEC, HP, Unisys, Oracle, ...

Un standard des notations graphiques et du vocabulaire utilisés pour

N’est pas une méthode de conception mais un ensemble de notations

n’est pas une méthode, mais un langage !!!!!!

Pourquoi utiliser UML :

1993-1994 1995 1996 01 - 1997 11 - 1997

Neuf diagrammes représentant chacun un aspect particulier du SI à

Chaque type de diagramme UML :

UML permet de définir et de visualiser un modèle, à l'aide de