UML-jamil.pptx

U.M.L
Dr Jamil Dimassi
jamildimassi@topnet.tn

Objectifs du cours
• Les objectifs de ce cours sont :
– Rendre les étudiants en mesure de lire, comprendre et de
produire les modèles d’un système d’information
développés avec la notation UML.
– Rendre les étudiants capables d’implémenter ces modèles
dans une Base de données ou avec un langage de
programmation OO ( Java, C++, …).
– Familiariser les étudiants avec un AGL .
mardi 15 novembre 2022 J. Dimassi 2

Les Systèmes d’Information 2000’s
et leur impact sur les Méthodes
d’Ingénierie

Systèmes d’Information 2000’s
La dimension développement des applications
• Des infrastructures technologiques, Des
architectures applicatives plus flexibles, plus
modulaires, plus facilement intégrables et
maintenables.

Systèmes d’Information 2000’s
À base de patrons, motifs,
composants, cadres, ERPs….
En 2003, 50 % des nouveaux
développements résultent
d’assemblage de « blocs »
(Gartner Group)
La dimension développement des applications

La Jungle des Modèles
Données
Traitements
Dynamique
Approches
temporelles et
dynamiques
Approches par les
données
Approches orientées
objet
CIAM
ERAE
REMORA
OOA
Approches structurées
Trois perspectives : Données, Traitements, Dynamique
E/R
NIAM
MERISE
O*
UML
SHM
OMT OOA&D SADT
IE
SART

Les Approches Centrées ‘Fonctions’
Données
Traitements
Dynamique
Informatiser le système
de réservation
Gérer les réservations Gérer les ressources
Créer
réservations
Modifier
réservations

Les Approches Centrées ‘Données’
Données
Traitements
Dynamique
Réservation
de
Chambre Hôtel
dans
1,N 1,N
1,N 1,1

Les Approches Centrées ‘Evénements’
Données
Traitements
Dynamique
Arrivée d'une
demande
Faire
Reservation
Mettre
en attente
Demande
Disponibilité
Prendre
Prendre
Faire
Accroissement
dispo

Les Approches ‘Objets’
Données
Traitements
Dynamique
Créer
Fermer
Prendre
dispo
Hôtel
Chambre
M.A.J
dispo
Créer
Reservation
Annuler
Remettre
dispo
Client

Les Limites des Approches Classiques
1 projet sur deux échoue dans 80% des cas parce que
le système d’information ne répond pas à l’attente
de ses usagers
. Besoins supposés connus et stables
. Processus centré sur ‘la’ solution technologique
trop peu participatif
. Notations trop abstraites
. Une maîtrise d’ouvrage trop ‘informaticienne’
Constat
Raisons

Les approches à base de scénarios
PRIVILEGIER LE POINT DE VUE DES UTILISATEURS
Chaque acteur décrit son ‘scénario’
d’usage, d’interaction, etc., avec le
système futur
Scénario 1
Système
Acteur A
Acteur B
Scénario2
ENSEMBLE DES
BESOINS
Acteur C
Acteur A
Acteur B
Chaque acteur a son ‘point de
vue’ sur le système futur

Les approches à base de scénarios
Un scénario est une description d'un
• Acteur individuel
• En interaction avec des facilités technologiques
• Pour atteindre un but
• Dans certaines circonstances
• Dans un certain intervalle de temps
Exemples : Usager d’un distributeur d'argent
Agent de voyage utilisant INTERNET

Unified Modeling Language

Introduction Générale
• Historique
Le développement d'UML a commencé 1994 quand G. Booch et J.
Rumbaugh ont débuté leur travail sur l'unification des méthodes
Booch et OMT (Object Modeling Technique).
Ces deux méthodes se développaient déjà indépendamment l'une
de l'autre et étaient mondialement reconnues comme les
principales méthodes orientées objet, Booch et Rumbaugh ont
joint leurs forces pour réaliser une unification complète de leurs
méthodes.

• Pourquoi utiliser UML ?
Unified Modeling Language n'est pas un éloignement radical des méthodes Booch,
OMT ou OOSE c'est une succession légitime de celles-ci
 Si vous utilisez Booch, OMT, ou OOSE, votre formation, votre expérience et vos
outils seront préservés
 UML est plus expressif, plus propre et plus uniforme
 UML permet aux projets de modéliser des choses qui n'auraient pas pu l'être
avant
 UML supprime toutes les différences non nécessaires de notation et de
terminologie qui obscurcissent les similarités de bases de ces différentes
approches.

• I-2- Définition
 UML est un ensemble de notations orientées objet dont la syntaxe et la
sémantique sont précisément définis
 Il permet de modéliser tout type de système et peut être utilisé à toute étape
d’un cycle de vie
 UML est un langage de modélisation objet et non une méthode
 C’est un langage formel (ou pseudo formel) basé sur un métamodèle qui
permet de définir :
les concepts et éléments de modélisation
la sémantique de ces éléments

Meyer
Before and after
conditions
Harel
Statecharts
Gamma, et al
Frameworks and patterns,
HP Fusion
Operation descriptions and
message numbering
Embley
Singleton classes and
high-level view
Wirfs-Brock
Responsibilities
Odell
Classification
Shlaer - Mellor
Object lifecycles
Rumbaugh
OMT
Booch
Booch method
Jacobson
OOSE

• L’évolution d'UML
UML 1.0
Version bêta OOPSLA'96
Soumission à l'OMG- janvier 97
Standardisation par l'OMG -NOV 97 UML 1.1
Autres méthodes Booch'91 OMT-1
Méthode unifiée 0.8
OMT-2
Booch'93
Commentaires
OOPSLA'95
(octobre 95)
OOSE Partenaires
UML 0.9
WWW juin 96
Jeu de documentation
UML 1.4
UML 2.0
UML 1.3
Standardisation par l'OMG -JUIN 99

II- Le Concept Objet
• II-1- La Notion d’Objet
 La POO consiste à modéliser conceptuellement un ensemble d'éléments d'une
partie du monde réel en un ensemble d'entités informatiques
 Ces entités sont appelées objets. Il s'agit de données informatiques regroupant
les principales caractéristiques des éléments du monde réel
 La difficulté de cette modélisation consiste à créer une représentation
abstraite, sous forme d'objets, d'entités ayant une existence matérielle (chien,
voiture, ampoule, ...) ou bien virtuelle (sécurité sociale, temps,...).

• Définition d’un objet
Un objet est défini par :
1. Un état : Ensemble de valeurs associées à des propriétés
qui permettent de décrire un objet à un instant t.
2. Un comportement : Ensemble de services ou d’opérations
que peut rendre un objet ou qui modifient son état.
3. Une identité : Propriété qui permet de distinguer un objet
des autres objet.

• II-2- Formalisme
Un objet est caractérisé par plusieurs notions:
 Les attributs ou propriétés : Il s'agit des données caractérisant l'objet. Ce sont
des variables stockant des informations d'état de l'objet
 Les méthodes ou fonctions membres : Les méthodes d'un objet caractérisent
son comportement, c'est-à-dire l'ensemble des actions ou opérations que
l'objet est à même de réaliser. elles permettent de faire réagir l'objet aux
sollicitations extérieures (ou d'agir sur les autres objets)
 Les opérations sont étroitement liées aux attributs, car leurs actions peuvent
dépendre des valeurs des attributs, ou bien les modifier

L'identité: L'objet possède une identité, qui permet de le
distinguer des autres objets, indépendamment de son état
On construit généralement cette identité grâce à un identifiant
découlant naturellement du problème (un produit pourra être
repéré par un code, une voiture par un numéro
d'immatriculation, ...)

Porsche: Voiture
Immatriculation = 45789
Modèle = 911
Poids = 1500
Capacité = 32
Démarrer()
Arrêter()
Rouler()
Allumer_jauge()
Représentation d'un objet avec UML :
Nom de l'objet
Propriétés
Méthodes

• Les liens entre objets
 Les objets ne sont pas des corps isolés, même s'ils possèdent leurs
caractéristiques propres par l'intermédiaire des valeurs de leurs attributs, ils
ont la possibilité d'interagir entre eux grâce à leurs méthodes.
 UML propose de représenter les liens qui existent entre les objets grâce à un
trait continu.
 Il est possible d'ajouter des commentaires sur le modèle sous forme de notes
 Une note est représentée par un rectangle dont le coin supérieur droit est
replié. Pour relier une note à un objet il faut utiliser un trait discontinu (en
pointillés).

Exemple d’objets ayant des liens entre eux :
Mourad
Kamel
Mohamed
unsiteWeb
Visiteurs du
site

• Modélisation d'une classe
Une classe est la structure d'un objet, c'est-à-dire la déclaration
de l'ensemble des entités qui composeront un objet.
Un objet est donc "issu" d'une classe, c'est le produit qui sort d'un
moule.
En réalité on dit qu'un objet est une instanciation d'une classe
On peut parler indifféremment d'objet ou d'instance
(éventuellement d'occurrence)

• Modélisation d'une classe
Une classe est composée:
D'un nom qui caractérise une classe d'une manière unique dans
un modèle.
D'un ou plusieurs attributs: il s'agit des données ainsi que leur
visibilité
De méthodes : il s'agit des opérations applicables aux objets de la
classe

Une classe se représente avec UML sous forme d'un rectangle divisé
en trois sections:
Le premier contient le nom donné à la classe (non souligné)
 Les attributs d'une classe sont définis par un nom, un type
(éventuellement une valeur par défaut, c'est-à-dire une valeur
affectée à la propriété lors de l'instanciation) dans le second
compartiment
 Les opérations sont répertoriées dans le troisième volet du
rectangle.

Porsche:Voiture
Peugeot:Voiture
Niveau Classe
Niveau Objet
Fiat:Voiture

Représentation d'une classe
• 1 à 4 champs :
– nom de la classe : obligatoire
– 0 ou n attributs
– 0 ou n opérations
– 0 ou n invariants de classe,
exceptions, …
Classe B
Classe A
Classe C
name : type = initval
opname( )

Les attributs
• Sémantique : constitue un élément de l'état de l'objet
• Visualisé ou pas, selon le niveau de détail souhaité
• 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

Les opérations
• Représente un service spécifique offert par un
objet
• Visibilité : +, -, #
• Direction : in, out, inout (in est la valeur par
défaut)

Identification des classes, attributs et
opérations
• C'est lors de la construction des diagrammes d'interaction
(séquences et/ou collaboration) que les objets (ceux qui
par abstraction donneront lieu à des classes ) sont
identifiés
• Ils sont transformés :
– en classes s'il y a des messages échangés
– en attribut
• Les opérations des classes correspondent aux messages
échangés entre objets réels

opérations
• Exercice 1:
Une personne possède un ncin, un nom, un prénom,
une date de naissance. La personne peut travailler,
et communiquer
Déduire la classe possible
Donner une instance possible

opérations
• Solution exercice 1
P1: Personne
Ncin : 084566554
Nom : Ben Salah
Prenom : Mohamed
Date_de_naissance : 5/04/75
Travailler()
Communiquer()

Les relations entre les classes
• Elles sont de 3 types et traduisent :
– l'association entre une (réflexivité) ou plusieurs classes
– la notion d'assemblage/composition
– le concept de spécialisation/généralisation
• Elles représentent des liens statiques / structurels entre
objets et à longue durée de vie

Les relations (Associations)
• Représente une propriété statique
• Lie une ou plusieurs classes : arité 2 ou plus
• Toute association doit être nommée par un verbe d’état
• Toute association peut être navigable
• Présence de rôle aux extrémités ( rôle de chaque classe dans
l'association )
• Multiplicité :
– 0
– 0..1
– N
– M..N
– *, 0..*
– 1..*

Multiplicités et contraintes
• Multiplicité : Contraintes valables durant toute
l'existence des objets
– une et une seule
– plusieurs (0 ou plus)
– optionnelle (0 ou 1)
– 1 ou plus
– de m à n
• Autres contraintes sur association
– {ordonné},{sous-ensemble},{ou-exclusif},
CLASSE
CLASSE
CLASSE
CLASSE
CLASSE
1..*
m..n
1..1
ou 1
0..*
ou *
0..1

Les relations (Association)
Personne Commande
0..*
1..1
passe>
•Une personne peut passer plusieurs commandes
•Une commande est toujours passée par une et une
seule personne
Youssef:Personne C1:Commande
C2:Commande
Mourad:Personne

Exercice 2:
Description d’un système de fichiers
–Un utilisateur possède au moins un répertoire
–Un répertoire appartient à un et un seul utilisateur
–Un répertoire peut contenir d ’autres répertoires
–Un utilisateur peut accéder à au moins un répertoire
–Un répertoire peut être accédé par au moins un
utilisateur autorisé

Solution Exercice 2 :
Répertoire
Utilisateur
Est propriétaire de>
1..1
1..*
0..*
<Contient
Contenant
Contenus
0..1
utilisateur autorisé
1..*
1..* Peut accéder à>

Les relations
Agrégation/composition
• Relation non symétrique
• Une extrémité supporte la notion de responsabilité :
– toute opération / attribut du responsable peut se propager aux éléments
contraints
• Agrégat / agrégé : durée de vie des agrégés indépendante de
l'agrégat
• Composite / composant : durée de vie des composants
dépendante du composite / conteneur - on parle
d'embarquement

Les relations (Agrégation)
Association avec une sémantique spécifique
– Relation "made of" "part of"
– Transitive
– Antisymétrique
– Propagation des propriétés avec modifications locales éventuelles
– Agrégations récursives
– Propagation des opérations
Micro ordinateur
U.C.
0..1
Souris Clavier
0..*
Moniteur
CPU
0..1
Ventilateur Châssis
0..*
RAM

Agrégation
• Agrégation
– Relation binaire de type tout-parties
– Relation d'appartenance faible : le composant peut être
partagé entre plusieurs composites : multiplicité
Composite Composant

Composition
• Composition
– Agrégation avec relation d'appartenance forte et coïncidence des
durées de vie
– Les composants peuvent être créés après le composite, mais
après création ils ont la même durée de vie
– Les composants peuvent être enlevés avant la mort du composite
– Chaque composant appartient à, au plus, un composite
– Propagation composite vers composant
Contrat Clause
1..1
1..1
Composite Composant
0..*
0..1

Généralisation/spécialisation
• Relation de classification entre un élément plus général et des
éléments spécialisés
• L'élément spécialisé hérite des propriétés (attributs +
opérations + relations) et des contraintes de l'élément dont il
est la spécialisation
• L'élément spécialisé peut avoir ses propres attributs,
opérations, relations
• Spécialisation simple ou multiple
• La spécialisation peut être contrainte à l'aide d'un stéréotype

Généralisation
• Généralisation
– Au niveaux des concepts
– Relation "is a" ou "a kind of" (Classification)
– Généralisation/Spécialisation
– Relation entre une classe (super-classe) et une ou
plusieurs spécialisations (sous-classes)
– Une instance d'une sous-classe est également une instance
de la super-classe
– Classe concrète et classe abstraite

Héritage
– Au niveau de le mise en œuvre (programmation OO)
– N'est pas la seule technique d'implantation d'une
généralisation
– Héritage : Relation transitive sur un nombre arbitraire
de niveaux
– Relation statique à couplage fort
– Réduire la complexité du code
– Maximiser la réutilisation

Généralisation et Héritage
Figure
couleur
position du centre
épaisseur du trait
type de trait
déplacer
sélectionner
pivoter
afficher
Point
afficher
Dimension 2
orientation
type de remplissage
redimensionner
remplir
Dimension 1
orientation
Dimension 0
redimensionner
dimension
Polygones
nb cotés
sommets
afficher
Cercles
diamètre
pivoter
afficher
Ligne
bornes
afficher
Arc
angle
angle départ
angle fin
afficher
Spline
Pts de contrôle
afficher

Généralisation et Héritage
Héritage multiple :
Eleve Surveillant
Eleve-Surveillant

Remarques sur les Associations
• Ne prendre en compte que des associations
binaires ! Si ce n'est pas possible, il faut
privilégier les classes associations
• Le nommage est indispensable quand il y a
plusieurs associations entre 2 classes
• Importance des contraintes !
– Sous-ensemble, et/ou, etc.
– {ordonné}, ...

Remarques sur les Associations
Ouvrage
Lecteur
Nom
Prénom
Adresse
0..1 0..3
Emprunter
Prêt
durée
date
Prolonger()
Exemple de Classe association

Exercice 3
 Une personne peut travailler pour plusieurs sociétés
 Une société a un et un seul PDG
 Une personne peut être PDG de plusieurs sociétés
 Une personne peut posséder plusieurs voitures
 Une voiture a un seul propriétaire
 Une personne peut avoir des enfants
 Une personne peut être le maire d’une commune
 Une personne peut être le député d’une
circonscription
 Une commune appartient à une circonscription

Exercice 3
1..1
Voiture
0..*
<a pour propriétaire
Personne Société
Travaille pour> 0..*
Employé Employeur
1..*
<a pour PDG
1..1 0..*
0..2
Enfants
Parents
0..*
Circonscription
1..1 1..*
<appartient
<a
pour
maire
Commune
1
0..1
<a
pour
député
1
0..1
{ou-exclusif}

Récapitulons !
• Un objet est une représentation valuée et
abstraite du monde réel
• Les objets de même type sont représentés par
une seule classe
• 3 types de relations entre les classes :
– Association
– Agrégation/Composition
– Généralisation/Héritage

III- La Modélisation avec UML
• III-1- Notions de Base
III-1-a- Les Modèles UML
Un modèle est une abstraction de la réalité :
L'abstraction est un des piliers de l'approche objet
un processus qui consiste à identifier les caractéristiques intéressantes
d'une entité, en vue d'une utilisation précise
 L'abstraction désigne aussi le résultat de ce processus, c'est-à-dire
l'ensemble des caractéristiques essentielles d'une entité, retenues par un
observateur.

• Un modèle est une vue subjective mais pertinente de la réalité
• Un modèle définit une frontière entre la réalité et la perspective de
l'observateur
• Ce n'est pas "la réalité", mais une vue très subjective de la réalité
III-1-b- Rédaction d’un Diagramme
UML est un langage qui permet de définir et de visualiser un modèle, à l'aide de
diagrammes.
Un diagramme UML est une représentation graphique, qui s'intéresse à un aspect
précis du modèle ; c'est une perspective du modèle, pas "le modèle".

• Chaque type de diagramme UML possède une structure (les types des éléments
de modélisation qui le composent sont prédéfinis).
• Un type de diagramme UML véhicule une sémantique précise (un type de
diagramme offre toujours la même vue d'un système).
• Combinés, les différents types de diagrammes UML offrent une vue complète
des aspects statiques et dynamiques d'un système.
• Par extension et abus de langage, un diagramme UML est aussi un modèle (un
diagramme modélise un aspect du modèle global).

La Modélisation avec UML
• UML se base sur une notation graphique et propose neuf types de diagrammes. Ces
derniers représentent d’une part les aspects statiques et dynamiques et couvrent
d’autre part l’ensemble des phases de développement.
Specs.
Fonctionnelles
Analyse
Conception
préliminaire
Specs.
Techniques
Conception
détaillée
Implém.
Diag.
cas d’util.
Diag.
classes.
Diag.
séq.
Diag.
déploi.
Diag.
compos.
Diag.
d’objets
Diag.
coll.
Diag.
États/tran.
Diag.
activi.
Statique Dynamique

• III-1-c- Les différents types de diagrammes UML :
Vues statiques du système :
diagrammes de cas d'utilisation
diagrammes d'objets
diagrammes de classes
diagrammes de composants
diagrammes de déploiement

• III-1-c- Les différents types de diagrammes UML :
Vues Dynamiques du système :
diagrammes de collaboration
diagrammes de séquence
diagrammes d'états-transitions
diagrammes d'activités

• III-2- Modélisation des Vues Statiques du système
III-2-a- Diagrammes De Cas D’utilisation (use cases) :
Représentation du modèle conceptuel
Structuration des besoins des utilisateurs
Structuration des objectifs correspondants d'un système
Expression des exigences du système sur ses
utilisateurs
Limitation des préoccupations "réelles" des utilisateurs
Pas de présentation de solutions d'implémentation

III- La Modélisation Statique
• Ils identifient les utilisateurs du système (acteurs) et leur interaction
avec le système
• Ils permettent de classer les acteurs et structurer les objectifs du
système
• Les Use Case servent de base à la traçabilité des exigences d'un système
dans un processus de développement intégrant UML

• Éléments de base des cas d'utilisation :
 Acteur : entité externe qui agit sur le système (opérateur, autre système...)
– L'acteur peut consulter ou modifier l'état du système
– En réponse à l'action d'un acteur, le système fournit un service qui
correspond à son besoin
– Les acteurs peuvent être classés (dans une hiérarchie)
• On distingue :
• les acteurs primaires : ceux sont les utilisateurs du système
• les acteurs secondaires : ceux qui administrent le système

• Use case : ensemble d'actions réalisées par le système, en
réponse à une action d'un acteur.
– Les uses cases peuvent être structurés
– Les uses cases peuvent être organisés en paquetages
(packages)
– L'ensemble des use cases décrit les objectifs, les fontionnalités
(le but) du système

• Formalisme de représentation des cas d'utilisation avec UML :
GAB
Consulter compte
Client
Retirer argent

• Formalisme textuel des cas d'utilisation avec UML :
Use Case nom
Initiateur Acteur qui lance le cas
Receveur Liste des objets qui vont réagir à ce cas d'utilisation
Participants Acteurs,
Paramètres Les flux de données échangés
Pré Condition préalable à l'exécution du cas
Post Condition à vérifier après l'exécution du cas
Exceptions

Décrire d'une manière textuelle un use case

« Un cas d’utilisation spécifie une séquence d’interactions, avec
ses variantes, entre les acteurs et le système, produisant un
résultat satisfaisant pour un acteur particulier »
 un cas d’utilisation est une abstraction de plusieurs chemins
d’exécution d’une utilisation du système
 Pour décrire un cas d’utilisation, il faut décrire un maximum de
chemins d’exécution possibles pour la séquence d’actions
correspondant à ce cas. On étudiera donc un certain nombre de
scénarios d’un cas d’utilisation
Un scénario est donc une instance de cas d’utilisation

• Relations entre cas d’utilisation :
Trois types de relations
a – utilisation : indique que le cas d’utilisation
source contient aussi le comportement décrit
dans le cas d’utilisation destination.
virement identification
« use »

b – extension : indique que le cas d’utilisation
source étend (précise) les objectifs (le
comportement) du cas d’utilisation destination.
Virement par
Internet
virement
« extend »

c - Généralisation / héritage : La relation d'héritage
ou de généralisation entre cas est à prendre au
sens classique de spécialisation, inhérent à
l'héritage
Réserver
voyage
Réserver voyage
par téléphone
Réserver voyage
par Internet
<<Inherits>>

• Relations entre les acteurs:
 De la communication
 De la généralisation/spécialisation
 Règle de validité : tout ce que fait le père, le fils peut le faire !
NB : la communication entre 2 acteurs est extérieure au système
Utilisateur
Superviseur

• Les paquetages ou Packages :
– Servent à délimiter le système et les sous-systèmes
– Les paquetages sont des éléments d'organisation des
modèles
– Ils regroupent des éléments de modélisation, selon des
critères purement logiques
– Ils servent de "briques" de base dans la construction d'une
architecture
– Ils représentent le bon niveau de granularité pour la
réutilisation

Package de gestion des commandes
Client
Commander un produit
Agent de
recouvrement
Gerer le paiement

Exercice 4 :
Identifier les cas d'utilisation d'un futur site web offrant la
fonctionnalité de mail la fonctionnalité de météo et la
fonctionnalité de dialogue en ligne:
1) Identifier les acteurs
2) Identifier les cas d'utilisation
3) Classer les cas d'utilisation en packages
4) Construire le diagramme de cas d'utilisation

• III-2-b- Diagrammes d’objets
– Illustration des objets (instances de classes dans un état
particulier) et des liens entre ces objets
– Les diagrammes d'objets s'utilisent pour montrer un contexte
(avant ou après une interaction entre objets par exemple)
– Sert essentiellement en phase exploratoire, car il possède un
très haut niveau d'abstraction
– Il a pour but de décrire schématiquement les relations entre
classes et de servir comme support pour les diagrammes de
collaboration
– Faciliter la compréhension des structures complexes

• Exemple de
diagramme
d’Objet :
: Voiture
: Roue : Roue : Roue : Roue
: Moteur
Voiture
Roue
Moteur
1 1
1
4

• Exemple de diagramme d’Objet :
 Relations réflexives
Personne
0..*
0..1
Chef
Subordonné
:Fenêtre
:Zone de Dessin
:Ascenseur :Ascenseur
Tyty:Personne
Toto:Personne
Titi:Personne
Chef
Tata:Personne
Chef
Tutu:Personne
Chef
Tyty:Personne
Chef
Subordonné Subordonné
Subordonné
Subordonné
Toto:Personne
Chef
Subordonné
 Objets composites

Stéréotypes
• Définition :
stéréotype. Un nouveau type d'élément de modélisation qui étend la
sémantique du méta-modèle. Les stéréotypes doivent être basés sur
des types ou classes existant dans le méta-modèle.
Un stéréotype élargit le vocabulaire d'UML, en permettant de créer de
nouvelles sortes de briques de base qui dérivent des concepts
adaptées à un problème donné.

Les stéréotypes
• Extension contrôlée des classes du méta-modèle
• <<Nom du stéréotype>>
• Possibilité de modifier l’icône
«datatype»
Integer
«subsystem»
User Interface
«utility»
Maths
«traces» «refines»
«exception»
Overflow

• III-2-c- Diagrammes de Classe
– Une classe est un type abstrait caractérisé par des propriétés (attributs et
méthodes) et permettant de créer des objets ayant ces propriétés.
Classe = attributs + méthodes + instanciation
– Un diagramme de classes est une collection d'éléments de modélisation
statiques (classes, paquetages...), qui montre la structure d'un modèle
– Il fait abstraction des aspects dynamiques et temporels
– Pour un modèle complexe, plusieurs diagrammes de classes
complémentaires doivent être construits.

• III-2-c- Diagrammes de Classe

• On peut par exemple se focaliser sur :
– les classes qui participent à un cas d'utilisation
– les classes associées dans la réalisation d'un scénario précis,
– les classes qui composent un paquetage,
– la structure hiérarchique d'un ensemble de classes.
• Pour représenter un contexte précis, un diagramme de classes peut être
instancié en plusieurs diagrammes d'objets.
• UML permet de définir trois types de stéréotypes pour les classes :
a) les classes « frontière »(interface): classes qui servent à modéliser les
interactions entre le système et ses acteurs.
b) les classes « contrôle » : classes qui servent à représenter la coordination, le
séquencement, les transactions et le contrôle d’autres objets.
c) les classes « entité » : classes qui servent à modéliser les informations
durables et persistantes.

Buts du diagramme de classe:
1. Structurer l’application - Relations entre classes
2. Base pour générer le code
3. Base pour générer la structure de données

Etapes de construction d’un diagramme de classe :
• Identification des concepts,
• Ajout des associations,
• Ajout des attributs, et des operations
• Enregistrement des termes dans un glossaire.

• Exemple récapitulatif
Client
+ retirerBillets( ): void
+ reserverBillets( ): void
+ annulerReservation( ): void
+ identifier(numRes) : void
Réservation
- numReservation : entier
- dateReservation : entier
+ retraitBillets( ): void
+ reserverBillets( ): void
+ annulerReservation( ): void
Trajet
- dateDepart : Date
- dateArrivée : Date
- train : Train
- lieuDepart : Gare
- lieuArrivée : Gare
+fixerDateDep(d : Date) : void
+fixerDateArr(d : Date ) : void
+fixerTrain(t : Train ) : void
+ ...
1
30..300
<<utilise>>

EXERCICES

Le futur logiciel de gestion des réparations de la société Motul
est destiné en priorité au chef d'atelier, il devra lui permettre
de saisir les fiches de réparations et le travail effectué par les
divers mécaniciens de l'atelier.
Pour effectuer leur travail, les mécaniciens de l'atelier vont
chercher des pièces de rechange au magasin. Lorsque le
logiciel sera installé, les magasiniers ne fourniront des pièces
que pour les véhicules pour lesquels une fiche de réparation
est ouverte via le système; ils saisiront directement les pièces
fournies depuis un terminal installé au magasin.
Lorsqu'une réparation est terminée, le chef d'atelier va essayer
la voiture. Si tout est en ordre, il met la voiture sur le parc
clientèle et bouclera la fiche de réparation informatisée. Les
fiches de réparations bouclées par le chef d'atelier devront
pouvoir être importées par le comptable dans le logiciel
comptable. Par ailleurs ces mêmes fiches vont être utilisées
par le logiciel de facturation. Ces deux logiciels existent déjà
et sont en cours d’utilisation.
Exercice : Use case

Elaborer le diagramme de classes
On souhaite modéliser le fonctionnement d’un SGBD OO (Système de
gestion de base de données orienté objets). Dans un tel système, une
base de données est caractérisée par un nom d’une BD unique, un
propriétaire et une date de création. Plusieurs classes composent cette
base de données. Chaque classe possède un nom de classe unique. Les
classes sont liées entre elles par un lien d’héritage, chaque classe
pouvant hériter de plusieurs classes mères. Chaque classe est composée
d’objets caractérisés par un OID (object identifier) unique et une taille.
Un objet appartient à une et une seule classe.
Les classes sont stockées dans des pages du disque dur à une date donnée.
Une classe peut être stockée sur plusieurs pages et une page peut
accueillir plusieurs classes. Chaque page es caractérisée par un numéro
de page unique et l’espace libre dans cette page.
Finalement, chaque page appartient à un segment du disque dur. Chaque
segment est caractérisé par un identifiant segment, un numéro de
disque et un numéro de cylindre. Un segment contient plusieurs pages.

• III-2-d- Diagrammes de Composants
– Ils permettent de décrire l'architecture physique et statique
d'une application en terme de modules : fichiers sources,
librairies, exécutables, etc.
Ils montrent la mise en œuvre physique des modèles de la vue
logique avec l'environnement de développement
– Les dépendances entre composants permettent notamment
d'identifier les contraintes de compilation et de mettre en
évidence la réutilisation de composants
– Le composants peuvent être organisés en paquetages, qui
définissent des sous-systèmes. Les sous-systèmes organisent la
vue des composants (de réalisation) d'un système. Ils
permettent de gérer la complexité, par encapsulation des
détails d'implémentation.

• Les composants représentent les éléments de
conception réutilisables :
– ils contiennent des classes
– ils présentent des interfaces
– et leurs interdépendances
• Propriétés importantes :
– au sein d’un composant couplage fort
– entre composants, couplage lâche
• Paquetage = ensemble de composants

• Exemples de diagramme de Composants :
Cours
Programmation
Cours
Profes
seur
Etudiant
Interfaces
Université
Gestion des
Erreurs
Base de
Données

Différences entre composants et classes:
– Les classes représentent des abstractions logiques alors que les
composants représentent des abstractions physiques
– Les composants représentent le regroupement physique de ce qu’on
pourrait appeler des composants logiques et se situent à un niveau
d’abstraction différent.
– Les classes peuvent avoir directement des attributs et des opérations.
En général, les composants comportent seulement des opérations que
l’on peut atteindre uniquement par leur interface.

UML définit cinq stéréotypes standards qui s’appliquent
aux composants:
– « document »
– « exécutable »
– « fichier »
– « bibliothèque »
– « Base»

Les relations de dépendance sont utilisées dans les
diagrammes de composants pour indiquer qu’un élément
d’implémentation d’un composant fait appel aux services
offerts par les éléments d’implémentation d’un autre
composant.

Les diagrammes de composants sont des vues
statiques de l’implémentation des systèmes qui
montrent les choix de réalisation. En général, ils ne
sont utilisés que pour des systèmes complexes.

III-2-e- Diagrammes de Déploiement :
• Ils montrent la disposition physique des matériels qui composent le système et
la répartition des composants sur ces matériels.
• Les ressources matérielles sont représentées sous forme de nœuds:
– Les noeuds sont connectés entre eux, à l'aide d'un support de communication.
La nature des lignes de communication et leurs caractéristiques peuvent être
précisées
• Les diagrammes de déploiement peuvent montrer des instances de noeuds (un
matériel précis), ou des classes de nœuds
• Les diagrammes de déploiement correspondent à la vue de déploiement d'une
architecture logicielle .

• Exemple de diagramme de Déploiement :

• III-3- Modélisation des Vues Dynamiques du système
III-3-a- Diagrammes De Séquences :
Les diagrammes de séquences permettent de représenter des collaborations entre
objets selon un point de vue temporel, on y met l'accent sur la chronologie des
envois de messages ainsi que sur la création et la destruction des objets.
la représentation se concentre sur l'expression des interactions.
Les diagrammes de séquences peuvent servir à illustrer un scénario d’un cas
d'utilisation.

III- La Modélisation Dynamique
L'ordre d'envoi d'un message est déterminé par sa position sur l'axe vertical du
diagramme ; le temps s'écoule "de haut en bas" de cet axe.
La disposition des objets sur l'axe horizontal n'a pas de conséquence pour la
sémantique du diagramme.
Les diagrammes de séquences constituent une partie des vues dynamiques les
plus importantes d'UML.
• Buts :
1. décrire les cas d’utilisation (scénarios)
2. décrire les interactions entre objets
3. Identifier des objets, et donc des classes potentielles
4. identification des échanges entre objets, issus des scénarios et donc des
opérations ainsi que des attributs des classes

• III-3-a- Diagrammes De Séquences

• Types de messages :
message simple (synchrone par défaut):
Message dont on ne spécifie aucune caractéristique d'envoi ou de réception
particulière.
message avec durée de vie ou minuté (timeout) :
Bloque l'expéditeur pendant un temps donné (qui peut être spécifié dans
une contrainte), en attendant la prise en compte du message par le
récepteur. L'expéditeur est libéré si la prise en compte n'a pas eu lieu
pendant le délai spécifié.

message synchrone :
Bloque l'expéditeur jusqu'à prise en compte du message par le destinataire. Le
flot de contrôle passe de l'émetteur au récepteur (l'émetteur devient passif et
le récepteur actif) à la prise en compte du message.
message asynchrone :
N'interrompt pas l'exécution de l'expéditeur. Le message envoyé peut être pris
en compte par le récepteur à tout moment ou ignoré (jamais traité).
message dérobant :
N'interrompt pas l'exécution de l'expéditeur et ne déclenche une opération
chez le récepteur que s'il s'est préalablement mis en attente de ce message.

• Chaque réception de message donne lieu à une
durée d'activation : le temps de traitement du
message
• La durée d'activation de l'émetteur recouvre
celle du récepteur
• Un message correspond à une invocation de
méthodes de l’objet receveur ou une réponse
donnée par un objet à un objet demandeur
d’une méthode

Exemple 1

Exemple 2

Opérateurs Alt et loop

Imbrication et opérateurs ref

Exercice
La société PromoMag spécialisée dans la vente des produits alimentaire dans ses
plusieurs points de vente à travers toute la Tunisie souhaite concevoir un système
d'information centralisé. Le magasinier de chaque point de vente pourra à travers le
nouveau système lancer la commande de produit. Afin de lancer une commande, le
magasinier consulte pour chaque produit la quantité du produit. Si elle est inférieure
à un seuil fixé à l'avance. Le magasinier crée une commande contenant le code du
produit, la date de la commande ainsi que la quantité désirée. Le responsable de
chaque point de vente doit faire un reporting des ventes des produits. Ce reporting
peut être par produit ou pour la totalité des produits. Le directeur
d'approvisionnement de la société PromoMag consulte régulièrement les
commandes des différents points de vente afin de lancer une commande globale
auprès du fournisseur concerné. Le directeur financier de la société PromoMag
utilise les différents reportings de vente pour l'élaboration des états financiers de la
société. L'administrateur du futur système est responsable des opérations de
sauvegarde (sauvegarde des commandes et des reportings). Tous les acteurs internes
de ce système doivent s'authentifier avec un nom utilisateur et un mot de passe pour
pouvoir utiliser le système.
1-diagramme de cas d’utilisation et diagrammes de séquences (analyse et
conception) pour lancer la commande

Exercice : UC + Séquence + classe
MockTruster est une chaîne internationale de clubs vidéo qui désire développer un
système de gestion des locations de clubs vidéo en Tunisie. Les fonctionnalités du
système en question sont liées à la location des différents articles du club (cassettes,
disques vidéo numériques, jeux vidéo sur CD-ROM).
les clients, via des guichets automatiques (ou terminaux) a accès libre, peuvent louer
des articles, rapporter les articles loués ou encore déposer de l’argent dans leur
compte. Pour devenir client une personne doit d’abord s’abonner et se voir attribuer un
nom d’utilisateur et un mot de passe qui peut être changer si besoin. Le club possède
plusieurs titres et à chaque titre peut correspondre plusieurs articles. Les articles
individuelles sont identifiées chacun par son propre code (les exemplaires d'un même
titre portent des codes, les titres sont aussi immatriculés); les locations, les différentes
formes de location et pénalité sont enregistrées dans le système ainsi que les clients.
La consultation du catalogue du club vidéo est sans restriction, c'est-à-dire, les clients
(abonnés ou non) peuvent faire des recherches sans identification. La location d’un
item ne peut se faire qu’à la suite d’une identification de l’abonné (sans lecteur de carte
magnétique ou autre, seulement en introduisant le nom d’utilisateur et le mot de
passe). Le retour est sans identification, par contre, si au moment du retour le système
trouve que l’abonné n’a pas assez d’argent dans son compte pour payer la location
effectuée, il lui suggère d’alimenter immédiatement son compte.
Le gérant peut ajouter/supprimer des abonnés (en leurs demandant des informations
de contact telles que le nom, le prénom, l’adresse et le téléphone) et des items au
catalogue, changer les prix des différents items, ou encore configurer les différentes
formules de location et de pénalités.

• III-3-b- Diagrammes de Collaboration
Les collaborations sont des interactions entre objets, dont le but est
de réaliser un objectif du système (c'est-à-dire aussi de répondre à
un besoin d'un utilisateur).
Ils permettent de représenter le contexte d'une interaction, car on
peut y préciser les états des objets qui interagissent.

• Buts :
1. Décrire l’interaction des objets entre eux
2. Illustrer les scénarios des use cases
3. Valider les choix d’analyse et de conception
(prototypage)
4. Aider à élaborer des diagrammes de classes de
conception

• Exemple de Diagramme de Collaboration :
x : ClasseA
y : ClasseB
z : ClasseB
1 : message
2 : message
: Client
: Menu
[validation]
: Loggin
[Interrogation]
1 : retraitBillets( )
2 : afficher ( )
3 : indentifier(numClient)
4.1 : accepter(numClient)
4.2 : refuser(numClient)

Exemple de Diagramme de
Collaboration

• III-3-c- Diagrammes d’Etats Transitions
Ce diagramme sert à représenter des automates d'états finis, sous forme de
graphes d'états, reliés par des arcs orientés qui décrivent les transitions.
Les diagrammes d'états-transitions permettent de décrire les changements d'états
d'un objet ou d'un composant, en réponse aux interactions avec d'autres
objets/composants ou avec des acteurs.
Un état se caractérise par sa durée et sa stabilité, il représente une représentation
instantanée des valeurs des attributs d'un objet.
Une transition représente le passage instantané d'un état vers un autre

Une transition est déclenchée par un événement. En d'autres termes : c'est
l'arrivée d'un événement qui conditionne la transition.
Les transitions peuvent aussi être automatiques, lorsqu'on ne spécifie pas
l'événement qui la déclenche.
En plus de spécifier un événement précis, il est aussi possible de conditionner une
transition, à l'aide de "gardes" : il s'agit d'expressions booléennes, exprimées
en langage naturel (et encadrées de crochets).
• Buts :
1. Illustrer les cas d’utilisation
2. Décrire en détail le comportement des classes

• Les états :
– Un objet est à tout moment dans un état donné
– L'état d'un objet est constitué des valeurs instantanées de ses
attributs.
– L'objet passe d'un état à un autre par les transitions.
– Ces états sont représentés par des rectangles au coin arrondi
– L'état initial se représente par un point noir et l'état final par un
point noir encerclé
état Final
état initial
état

• Exemple de Diagramme d’Etats Transition :

• Les transitions
– Déclenché par un événement, les transitions permettent le passage
d'un état à un autre instantanément. La syntaxe d'un événement dans
un diagramme est la suivante :
Nom_événement ( Nom_paramètre : type, ...)[condition]
– " condition " est la garde qui valide ou non le déclenchement d'une
transition quand l'événement s'est produit.
– Il est possible de préciser les actions à exécuter lorsque l'on est dans un
état donné, en entrant ou en sortant. Pour cela UML donne plusieurs
mots-clés :
entry : action à exécuter dès l'entrée dans l'état
exit : action à exécuter lors de la sortie de l'état
on : action interne provoquée par un événement qui ne provoque pas le
passage à un nouvel état.
Do : activité à exécuter ( une activité est une action dont le temps
d'exécution est non négligeable )

• généralisation d'état
Pour plus de clarté, la notation UML permet la généralisation d'état.
Les états les plus généraux sont appelés les super états et les
états les plus spécifiques sont appelés les sous états. Un état peut
être décomposé en sous état.

L'historique
• Il peut sembler nécessaire de mémoriser les sous-états qui ont
été actifs dans une agrégations d'états. On parle alors d'histoire.
En mettant le symbole " H " dans un super état, on indique que
l'on voudrait mémoriser les sous états qui ont été actifs. " H* "
indique que l'on veut mémoriser les sous états actifs quel que soit
la profondeur de l'imbrications des sous états.

Construire le diagramme d'état de l'objet
Exemplaire_de_livre dans un système
d’information d’une bibliothèque
Disponible
Entrer_en_bibliothèque
Prêté
Demande_prêt
reprise
hors-Etat

• Le tamagushi est un animal virtuel vivant dans
une console de jeux. Le tamagushi dort
pendant deux heures puis se réveille. Dès son
réveil le tamagushi doit être mis à table et
manger sinon il pleure. Après avoir mangé
(2minutes) le tamagushi pleure.il faut le sortir
de table et le mettre pour jouer. Il joue
pendant 2 heures puis il pleure tant qu’il n’est
pas mis au lit pour dormir. Si le tamagushi
pleure pendant 3 minutes il s’évanoui et s’il
est évanoui pendant 2 minutes il meure

III-3-d- Diagrammes d’ Activités
UML permet de représenter graphiquement le comportement d'une méthode ou
le déroulement d'un cas d'utilisation, à l'aide de diagrammes d'activités (une
variante des diagrammes d'états-transitions).
Une activité représente une exécution d'un mécanisme, un déroulement d'étapes
séquentielles.
Le passage d'une activité vers une autre est matérialisé par une transition.

Les transitions sont déclenchées par la fin d'une activité et provoquent le début
immédiat d'une autre (elles sont automatiques).
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.
• Buts :
1. Décrire le comportement générique d’un use case
2. Décrire en détail le comportement d’une opération
3. Modéliser les processus métiers

• Exemple de Diagramme d’Activité :

Récapitulons
• UML : Langage pour conception OO
• 2 types de diagrammes : Statiques et
dynamiques
– Statique : DCU, D classe, D composant, D
déploiement, D objets
– Dynamique : D seq , D Etats-transitions, D Activité,
D collaboration

UML : Règles de passage
De UML vers LMD
De UML à java

Adéquation aux BD « objet » comme O2
Non adéquation aux BD « classiques »
Il faut des règles de passage et de
transformation
-Perte du côté traitement
Du modèle objet ... aux BD

Classes
Attributs
Ajout de l’identifiant
Schéma relationnel
ADRESSE
N°
Rue
CP
Ville
Attribut Domaine Non Null
Id_adresse Identifiant Oui
N° Entier Non
Rue String(30) Non
…..
Schéma Adresse
Clé primaire
Id_adresse

Classes
Attributs
Ajout de l’identifiant
Schéma relationnel
PERSONNE
CIN {unique}
Nom
Prénom
Date-naissance
Id_Pers Identifiant Oui
CIN String(13) Oui
Prénom String(30) Non
Date-nais Date Non
Schéma Personne
Clés primaires
candidates
Id_adresse
CIN
On préfère CIN

Associations
PERSONNE ADRESSE
CIN
....
N°
Rue
CP
Ville
1 1
a
CIN String(13) ID Oui
Nom String(35) Oui
Id_adresse Identifiant Oui
Schéma Personne
Clé primaire
CIN
Clé étrangère
Id_adresse

Associations
PERSONNE COMPTE
CIN
....
N°
Type
1 0..*
possède
Id_compte Identifiant Oui
N° String(35) Id Oui
CIN Identifiant Oui
Schéma Compte
Clé primaire
Id-compte
N°
On choisit N°
Clé étrangère
CIN

Associations
PERSONNE BIBLIOTHEQUE
CIN
....
nom
0..*
adhère->
0..*
date adhésion
type adhésion (mensuelle, annuelle)
Schéma Adhère
Clé primaire
CIN
Id_bibliothèque
Rque :
Date
Type
CIN Id String(13) Oui
Id_bibliothèque Identifiant Oui
Date_adhésion Date Oui
Type_adhésion String(10) Oui

Spécialisation
PERSONNE
NSS
....
ETUDIANT
num
....
ENSEIGNANT
grade
....
Plusieurs choix
- « aplatir vers le haut »
Schéma Personne
Clé primaire
CIN
- « aplatir vers le bas »
Schémas Etudiant, Enseignant
Clé primaire CIN
- conserver les niveaux

Déduire le schéma de la base de données

Projection vers la programmation

Du modèle objet ... à la programmation
Classes
- adresse : String = 'adresse inconnue'
- numeroBib[6] : Integer
# changeAdresse(nouvelleAdresse : String)
+ cotisationAJour() : Boolean
Adhérent
type d'attribut
valeur initiale
type de
paramètre
type du résultat
de l'opération
privé
protégé
public
adhérent de la
bibliothèque

Classes
Attributs, Opérations ------> Champs, Méthodes
Accesseurs L/E (convention get/set en Java)
Constructeurs (Java, C++), Destructeurs (Java)
Proposer un service et réagir aux messages

Classe Adhérent en Java (extrait)
public class Adherent
{
private String adr = ``adresse inconnue``;
private int[] numeroBib;
public Adherent(){numeroBib=new int[6];}
public Adherent(String na, int[] ni)
{adr=na; numeroBib=ni;}
public String getAdr(){return adr;}
protected void setAdr(String nouvelleAdresse)
{adr=nouvelleAdresse;}
public int[] getNumeroBib(){return numeroBib;}
protected void setNumeroBib(int[] ni){numeroBib=ni;}
public boolean cotisationAjour(){…….}
}
Constructeurs
Accesseurs
Méthodes
Champs

Opérations
Données
Messages
Encapsulation
Objet
Retour sur la notion d’encapsulation

Liste GestionPersonnel
ajoute
retire
applique(fct)
 Confiner les modifs de Liste dans la classe Liste …
Utilité de l’encapsulation

Protection en Java
public class Adherent
{
private String adr = ``adresse inconnue``;
private int[] numeroBib;
public Adherent(){numeroBib=new int[6];}
public Adherent(String na, int[] ni)
{adr=a; numeroBib=ni;}
public String getAdr(){return adr;}
protected void setAdr(String nouvelleAdresse)
{adr=nouvelleAdresse;}
public int[] getNumeroBib(){return numeroBib;}
protected void setNumeroBib(int[] ni){numeroBib=ni;}
public boolean cotisationAjour(){…….}
}
Accessible aussi dans
toute méthode du
package et dans toute
méthode d’une sous-
classe C sur un objet
dont le type est C ou une
sous-classe de C
Accessible partout
Accessible seulement dans les
autres méthodes de la classe

Variables et méthodes de classe (en Java)
public class Produit
{
private static float tauxTVA;
………..
public static void fixeTauxTVA(float f){…..}
}
Produit
référence : String
prixHT : float
tauxTVA : float
setPrixHT(f:float)
affichePrix()
……..
fixeTauxTVA(f:float)

Classes abstraites, méthodes abstraites
abstract public class Figure
{
abstract public void dessine();
……..
}
Java

Traduction des interfaces en Java
Héritage par réalisation
Spécification de services (sans implémentation)

interface Ipolygon
{float perimeter(); …}
interface Iquadrilateral ….
{static const int sideNb = 4; ….}
interface Isquare ….
{float getCote(); …..}
public class Square implements Isquare
{public float getCote(){….} ….}
public class x
{…. public void meth(Isquare i) {…} …..}
Interfaces en Java
Ipolygon
Iquadrilateral
Isquare
Square

interface Ipolygon
interface Iquadrilateral ….
interface Isquare ….
public class x
Interfaces en Java
méthodes abstraites et
publiques (par défaut)
variables de classe
publiques et constantes
(par défaut)
type à implémenter
type de Java
(écriture de code
générique)

Associations
PERSONNE ADRESSE
nom
....
N°
Rue
CP
Ville
1 1
a
class PERSONNE
{
private :
string nom;
ADRESSE adr;
....
}
rien de spécial dans ADRESSE
Attribut complexe
Navigabilité dans un seul sens
adr
Utilisation
du nom de rôle

Associations
PERSONNE COMPTE
nom
....
N°
Type
1 0..n
possède
class PERSONNE
{private :
string nom;
list <COMPTE> comptes;....}
class COMPTE
{private :
PERSONNE possesseur;....}
Conteneur
Référence
Navigabilité dans les deux sens
comptes
possesseur

Associations
PERSONNE BIBLIOTHEQUE
nom
....
nom
0..n
adhère
class PERSONNE {private : string nom;....}
class BIBLIOTHEQUE {private : ....}
class ADHESION
{private :
PERSONNE adhérent;
BIBLIOTHEQUE biblio;
DATE dateadhésion;
String typeAdhesion; ....}
0..n
date adhésion
type adhésion (mensuelle, annuelle)
Classe d’association

Personne
nom
adresse
Gestionnaire
num
adresse
L’héritage traduit la généralisation/spécialisation
C++
class Personne{};
class Gestionnaire
: virtual public Personne
Java
public class Personne{}
public class Gestionnaire
extends Personne

Héritage
• adéquation des deux relations
• représentation et traitement des conflits
• spécialisation des attributs
• représentation de la surcharge et du masquage
• utilisation de l’héritage à des fins d’implémentation ?
Implémentation de la relation de spécialisation par
l’héritage, quelques problèmes ....

Héritage : adéquation des deux relations
Spécialisation multiple (possible en C++, impossible entre classes Java)
Flot
good()
eof()
...
FlotEcriture
écrire(blocOctets)
...
FlotLecture
lire(nbOctets)
...
FlotLectureEcriture

interface Ipolygon
interface Iquadrilateral extends Ipolygon
interface Isquare extends Irectangle,Irhombus
public class x
Adéquation des deux relations (cas de Java)
héritage multiple
entre interfaces
spécialisation
implémentation

Cas de Java : héritage simple pour l’implémentation, multiple pour les interfaces
... côté classes, ...
les méthodes de FlotLecture et FlotEcriture doivent être réécrites dans FlotLectureEcriture
Héritage : adéquation des deux relations (Java)
interface Flot
interface FlotEcriture
interface FlotLecture
interface FlotLectureEcriture
classe Flot
classe FlotLecture
classe FlotLectureEcriture
classe FlotEcriture
extends
implements

Spécialisation/Généralisation ....
Conflit portant sur le nom des propriétés
Il y a clairement deux propriétés
Objet
couleur (rouge, vert ...)
Elément de jeu
Pion Dé
Carte à jouer
couleur (coeur, trèfle, ...)

Spécialisation/Généralisation ....
multiples
Conflit portant sur les valeurs ou le domaine d’une propriété
Le pédalo n’a qu’une propriété zoneNav, mais quelle sera son domaine ?
ObjetNautique
Bateau EnginPlage
Pedalo
zoneNav
{zoneNav
sup. à 100}
{zoneNav
inf. à 10}
{zoneNav ?}

Héritage : représentation et traitement d’un conflit de
nom Java
pas d’accès possible à couleur d’objet
autre qu’avec “super” (dans les méthodes)
mieux vaut donner deux noms différents

Héritage : surcharge statique et redéfinition
Redéfinition
coexistence de méthodes de même nom
dans des classes comparables
appel déterminé par le type de l’objet (dynamique)
Surcharge statique
coexistence de méthodes de même nom
dans des classes différentes
appel déterminé par le type de la variable (statique)

Héritage : redéfinition Java
redéfinition seulement si les signatures
sont strictement identiques,
C++
redéfinition si les types des paramètres
sont identiques, le type de retour peut
être spécialisé
Magnitude
<(Magnitude)
Time
<(Time)
heure
minute
secondes
Date
<(Date)
jour
mois
année
Java, C++ : on ne peut pas
représenter directement une
spécialisation des paramètres
cas de surcharge statique
Magnitude
<(Magnitude)
Time
<(Magnitude)
heure
minute
secondes
Date
<(Magnitude)
jour
mois
année
cas de redéfinition

Héritage : à chacun sa surcharge
Personne
Princesse
habiller(Vêtement)
habiller(Vêtement, Chaussure)
habiller(Vêtement, Bijou)
Vêtement
Chaussure
Bijou
QuiSePorte
En Java : correctement interprété comme de la surcharge statique
En C++ : habiller(Vêtement, Bijou) cache les deux autres

Héritage : l’utiliser pour des raisons d’implémentation ?
Liste
ajoutFin
Pile
push
pop
top
A éviter dans tous les cas ...
même si les livres en sont pleins ...

A partir du modèle dynamique - diagrammes de séquence
jim:Etudiant
afficheResultats()
afficheMoyenneEtMention()
[moyenne<10]
afficheModulesObtenus()
public class Etudiant
{
public void afficheResultats()
{
afficheMoyenneEtMention();
if (getMoyenne()<10)
afficheModulesObtenus();
}
}

cnam03:Promotion
A partir du modèle dynamique - diagrammes de collaboration
:Etudiant
*[i:=0..nbEtudiants-1]:moyenne()
public class Promotion
{
private Vector listeEtudiants;
……….
public float moyenneGenerale()
{
double mg=0;
for (int i=0; i<listeEtudiants.size(); i++
mg+=((Etudiant)(listeEtudiants.get(i))).moyenne();
return mg;
}
}

Processus Unifié (Unified Process)
• Cycle de vie itératif et incrémental Méthode générique
• Générique signifie qu'il est nécessaire d'adapter UP au contexte
du projet, de l'équipe, du domaine et/ou de l'organisation
(exemple: X.UP). C'est, entre parenthèses, plus ou moins vrai pour
toute méthode, qu'elle se définisse elle-même comme générique
ou pas.
• Le processus unifié est piloté par les cas d’utilisation

Unified Process
• UP (Unified Process) est une méthode générique de
développement de logiciel
– Il existe donc un certain nombre de méthodes issues de UP
• UP est une méthode itérative et incrémentale
– Une itération désigne la succession des étapes de
l’enchaînement d’activités
– Un incrément correspond à une avancée dans les
différents stades de développement.

Unified Process (cadre générale)
• Le processus unifié est un processus de
développement logiciel : il regroupe les activités à
mener pour transformer les besoins d’un
utilisateur en système logiciel
• Caractéristiques essentielles du processus
unifié :
- UP est à base de composants,
- UP utilise le langage UML,
- UP est piloté par les cas d’utilisation,
- UP est centré sur l’architecture,
- UP est itératif et incrémental

Les avantages d'un processus itératif
• Coûts :Permet de limiter les coûts, en termes de risques, aux
strictes dépenses liées à une itération.
• Délais : Permet de limiter les risques de retard de mise sur le
marché du produit développé (identification des problèmes
dès les premiers stades de développement et non en phase de
test comme avec l’approche « classique »)
• Rapidité : Permet d’accélérer le rythme de développement
grâce à des objectifs clairs et à court terme.
• Qualité : Permet de prendre en compte le fait que les besoins
des utilisateurs et les exigences correspondantes ne peuvent
être intégralement définis à l’avance et se dégagent peu à peu
des itérations successives

Le cycle de vie de UP
• Le processus unifié répète un certain nombre de fois
une série de cycles
• Tout cycle se conclut par la livraison d’une version du
produit aux clients et s’articule en 4 phases :
– création,
– élaboration,
– construction et
– transition
Chacune d’entre elles se subdivisant à son tour en itérations.

Le cycle de vie de UP

Phase de création
• Traduit une idée en vision de produit fini et présente une étude
de rentabilité pour ce produit
- Que va faire le système pour les utilisateurs ?
- A quoi peut ressembler l’architecture d’un tel système ?
- Quels sont l’organisation et les coûts du développement de ce
produit ?
On fait apparaître les principaux cas d’utilisation
• L’architecture est provisoire, identification des risques majeurs
et planification de la phase d’élaboration.

Phase d'élaboration
• Permet de préciser la plupart des cas d’utilisation et
de concevoir l’architecture du système
• L’architecture doit être exprimée sous forme de vue
de chacun des modèles.
• Émergence d’une architecture de référence.
• A l’issue de cette phase, le chef de projet doit être en
mesure de prévoir les activités et d’estimer les
ressources nécessaires à l’achèvement du projet.

Phase de construction
• Moment où l’on construit le produit. L’architecture de
référence se transforme en produit complet, elle est
maintenant stable. Le produit contient tous les cas
d’utilisation que les chefs de projet, en accord avec les
utilisateurs ont décidé de mettre au point pour cette
version. Celle ci doit encore avoir des anomalies qui
peuvent être en partie résolue lors de la phase de
transition

Phase de transition
• Le produit est en version bêta.
• Un groupe d’utilisateurs essaye le produit et détecte
les anomalies et défauts.
• Cette phase suppose des activités comme :
– la fabrication,
– la formation des utilisateurs clients,
– la mise en œuvre d’un service d’assistance et
– la correction des anomalies constatées.(où le report de leur
correction à la version suivante)

Modèle des cas d’utilisation Expose les cas d’utilisation et leurs relations avec les
utilisateurs
Modèle d’analyse
Détaille les cas d’utilisation et procède à une première
répartition du comportement du système entre divers
objets
Modèle de conception
Définit la structure statique du système sous forme de
sous système, classes et interfaces ;
Définit les cas d’utilisation réalisés sous forme de
collaborations entre les sous systèmes les classes et les
interfaces
Modèle d’implémentation
Intègre les composants (code source) et la
correspondance entre les classes et les composants
Modèle de déploiement
Définit les nœuds physiques des ordinateurs et
l’affectation de ces composants sur ces nœuds.
Modèle de test Décrit les cas de test vérifiant les cas d’utilisation
Représentation de l’architecture Description de l’architecture

Modèle des cas d’utilisation
Expose les cas d’utilisation et leurs relations avec les utilisateurs
Modèle d’analyse
Détaille les cas d’utilisation et procède à une première répartition du
comportement du système entre divers objets
Modèle de conception
Définit la structure statique du système sous forme de sous
système, classes et interfaces ;
Définit les cas d’utilisation réalisés sous forme de collaborations
entre les sous systèmes les classes et les interfaces
Modèle d’implémentation
Intègre les composants (code source) et la correspondance entre
les classes et les composants
Modèle de déploiement
Définit les nœuds physiques des ordinateurs et l’affectation de ces
composants sur ces nœuds.
Modèle de test
Décrit les cas de test vérifiant les cas d’utilisation
Représentation de l’architecture
Description de l’architecture

VI- UML et les AGL
• Critères de sélection :
- Nombre de diagrammes supportés
- Génération automatique de diagrammes
- Génération de code – langages supportés
- Rétro ingénierie (reverse engineering )
- Prototypage
- Synchronisation du code avec modification extérieures
- API
- Echange avec d’autres AGL UML
- Utilisation pratique (schéma de qualité,convivialité,générer des images...)
- Pattern de conception – et création de patterns

VI- UML et les AGL
• Quelques AGL :
- Rational ROSE (Rational corp.) http://www.rational.com
- Together ( Togethersoft) http://www.togethersoft.com
- Paradigm (Platinium) http://www.platinium.com
- Magic Draw UML (NoMagic) http://www.nomagic.com
- DOM (ObjetDirect) http://www.objetdirect.com
- Objecteering (SoftTeam) http://www.objecteering.com
- Aonix Life Cycle Desktop (Aonix) http://www.aonix.com, .fr
- UML Studio (Pragsoft) http://www.pragsoft.com

UML-jamil.pptx

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à UML-jamil.pptx

Similaire à UML-jamil.pptx (20)

Dernier

Dernier (15)

UML-jamil.pptx