Vous êtes sur la page 1sur 198

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
Les différents systèmes d’une organisation

MATIERES PRODUITS
SYSTÈME ACTIVITE
PREMIERES FINIS
OPÉRANT

SYSTÈME
D’INFORMATION INFORMATION

SYSTÈME DE
PILOTAGE DECISION

5
Les différents systèmes d’une organisation

6
Les différents systèmes d’une organisation

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
FONDEMENTS SYSTEMIQUES

ENVIRONNEMENT

EVOLUTION STRUCTURE ACTIVITE

FINALITES

9
FONDEMENTS SYSTEMIQUES

- 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
FONDEMENTS SYSTEMIQUES

- 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
FONDEMENTS SYSTEMIQUES

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
Evolution des applications informatiques

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
Evolution des applications informatiques

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
Evolution des applications informatiques

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
Evolution des applications informatiques

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
Historique des méthodes d’analyse et de conception

19
Historique des méthodes d’analyse et de conception

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
Historique des méthodes d’analyse et de conception

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
Historique des méthodes d’analyse et de conception

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
Historique des méthodes d’analyse et de conception

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
Historique des méthodes d’analyse et de conception

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
Historique des méthodes d’analyse et de conception

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
Maître de Conférences
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
Concepts orientés objet
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
Concepts orientés objet

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
Concepts orientés objet

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
Concepts orientés objet

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
Concepts orientés objet

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
Concepts orientés objet

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
Démarche Orientée objet

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
Démarche Orientée objet

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
Démarche Orientée objet

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
Démarche Orientée objet

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
Démarche Orientée objet
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
Démarche Orientée objet

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
Maître de Conférences
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
Introduction & Remarques Générales

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
Introduction & Remarques Générales

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
Introduction & Remarques Générales

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
Introduction & Remarques Générales

Un besoin d’unification:

Unified …

Pour la modélisation :
Modelling …

Sous forme de langage :


Language …

UML
Remarque : Pourquoi langage et non méthode ?
47
Introduction & Remarques Générales

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
Introduction & Remarques Générales

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
Introduction & Remarques Générales

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
Introduction & Remarques Générales

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
Introduction & Remarques Générales

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
Introduction & Remarques Générales

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
Introduction & Remarques Générales

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
UML : Unified Modelling Language

Diagrammes de Cas d’utilisation


Uses Cases

Faïez GARGOURI
Maître de Conférences
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

Les cas d’utilisation :


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
Concepts de base : les acteurs

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
Concepts de base : les acteurs

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

Les cas d’utilisation :


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
Concepts de base : relations entre cas d’utilisation

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 :
Entre cas d'utilisation
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
Concepts de base : relations entre cas d’utilisation

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
Concepts de base : relations entre cas d’utilisation

Relation de généralisation :
Entre cas d'utilisation
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
Description des cas d’utilisation

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
Description des cas d’utilisation

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
Exemple de Cas d’utilisation

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
Exemple de Cas d’utilisation

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
Exemple de Cas d’utilisation

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
Exemple de Cas d’utilisation
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
Exemple de Cas d’utilisation

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
Exemple de Cas d’utilisation

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

Les cas d’utilisation :


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
UML : Unified Modelling Language

Diagrammes de Collaboration
Faïez GARGOURI
Maître de Conférences
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
UML : Unified Modelling Language

Diagrammes de Séquence
Faïez GARGOURI
Maître de Conférences
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

Les diagrammes de séquence :


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

Les diagrammes de séquence :


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

Les diagrammes de séquence :


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

Les envois de messages :


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

Les envois de messages :


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

Les envois de messages :


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 envois de messages :


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
Expéditeur Destinataire
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 structures de contrôle :


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

Les structures de contrôle :


Exemple de boucle While :

Expéditeur Destinataire

While X loop Remarque:


Message
X : condition(s)
End loop

OU Expéditeur Destinataire

*[X] Message

118
Concepts de base

Les structures de contrôle :


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

Les diagrammes de séquence :


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
UML : Unified Modelling Language

Diagrammes d’objets
Faïez GARGOURI
Maître de Conférences
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
UML : Unified Modelling Language

Diagrammes de classes
Faïez GARGOURI
Maître de Conférences
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

Les associations : Contraintes


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

Les associations : Contraintes


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
UML : Unified Modelling Language

Diagrammes d’Etats - Transitions


Faïez GARGOURI
Maître de Conférences
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
UML : Unified Modelling Language

Diagrammes d’activités
Faïez GARGOURI
Maître de Conférences
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