CoursUml PartieI

Institut Supérieur des Sciences Appliquées et de Technologie de Sousse
1 0
0 2
2 0
2 Méthodologies d’analyse
et de conception O.O
Enseignant : Dr. Mhamed Saidane
Plan
Introduction Générale
Analyse et Conception orientée objet

Langage UML 2.x (Unified Modeling Language)
Démarches associées
La démarche 2TUP (Processus UP)
Une démarche minimaliste
Les patrons de conception
Dr. Mhamed Saidane 1ème Ing - A.U. 2019 - 2020 2
1
1 0
0 2
2 0
Introduction
2
Le développement
d’applications aujourd’hui…
Langage UML
Démarche Associée
Les patrons de conception Enseignant : Dr. Mhamed Saidane
Un peu d’histoire
En 1995, une étude du Standish Group dressait un tableau
accablant de la conduite des projets informatiques. Reposant
sur un échantillon représentatif de 365 entreprises, totalisant
8380 applications, cette étude établissait que :
16,2% des projets conformes aux prévisions initiales.
52,7% ont subi des dépassements en coût et délai avec diminution

du nombre des fonctions.
31,1% ont été purement abandonnés durant leur développement.
2
Un peu d’histoire
Pour les grandes entreprises (qui lancent proportionnellement
davantage de gros projets) :
Le taux de succès est de 9% seulement,
Le taux d’échec des projets (arrêt en cours de réalisation) est de

37%,
Le taux d’aboutissement hors délai et hors budget est de 50%.
Un peu d’histoire
Les causes d’échecs :
L’informatique (Non)
Le client
Pour ces raisons, le développement de logiciels dans un contexte

professionnel doit suivre :
Des règles strictes encadrant la conception

Des règles permettant le travail en groupe
Des règles de maintenance du code.
Ainsi, une nouvelle discipline est née : le génie logiciel.
3
Le Génie Logiciel Pourquoi ?
L’objectif du génie logiciel est d’optimiser le coût de

développement du logiciel.
Il remédie à :
L’augmentation des coûts.
Les difficultés de maintenance et d’évolution.
La non fiabilité.
Le non respect des spécifications.
Le non respect des délais.
Le Génie Logiciel Quand ?
Le génie logiciel touche au cycle de vie du logiciel :
L’analyse du besoin,
L’élaboration des spécifications,
La conceptualisation,
Le développement,
La phase de test,
La maintenance.
4
Le Génie Logiciel Comment ?
Qu’est ce qu’un modèle ?
Un modèle est une représentation abstraite et simplifiée d’une entité du monde réel en vue
de le décrire, de l’expliquer ou de le prévoir. Il reflète ce que le concepteur croit important
pour la compréhension et la prédiction du phénomène modélisé.
Pourquoi modéliser ?
Mieux comprendre le fonctionnement du système.
Maîtriser sa complexité
Assurer sa cohérence.
Quel est l’utilité

Support de communication et compréhension : Un modèle est un langage commun, précis,
qui est connu par tous les membres de l’équipe.
Répartition des taches et leurs automatisation.
Réduction des coûts et délais
Meilleur qualité et maintenance efficace.
Finalité
Le choix du modèle a donc une influence capitale sur les

solutions obtenues.
Selon les modèles employés, la démarche de modélisation

n’est pas la même.
5
1 0
0 2
2 0
Qualités du logiciel
2
Langage UML
Démarche Associée
Unified Modeling Language
Bibliographie
– Booch G., Rumbaugh J., Jacobson I., UML Semantics, Version 1.1, Rational Software
Corporation, Santa Clara, CA, 1 Septembre 1997
– Booch G., Rumbaugh J., Jacobson I., Unified Modeling Language User Guide, Addison-
Wesley, 1998 (traduction française : Le guide de l’utilisateur UML, Edition Eyrolles, 2000).
– Jacobson I., Booch G., Rumbaugh J., The Unified Software Development Process, Addison-
Wesley, 1999.
– Larman C., "Applying UML and Patterns", Prentice Hall, 1998.
– Muller P.A., Nathalie Gaertner "Modélisation objet avec UML",2ème édition, Eyrolles,
février 2000, Paris
– Rumbaugh J., Jacobson I., Booch G., Unified Modeling Language Reference Manual,
Addison-Wesley, 1999
– Joseph Schmuller, Teach Yourself UML in 24 Hours, Sams Publishing, 1999.
6
Netographie
Pour avoir des informations sur UML

http://www.omg.org/uml/
http://www.rational.com/uml/global
Historique
Les premières méthodes d'analyse (années 70)

Découpe cartésienne (fonctionnelle et hiérarchique) d'un système.
L'approche systémique (années 80)

Modélisation des données + modélisation des traitements (Merise, Axial,...).
L'émergence des méthodes objet (1990-1995)

Prise de conscience de l'importance d'une méthode spécifiquement objet :comment
structurer un système sans centrer l'analyse uniquement sur les données ou
uniquement sur les traitements (mais sur les deux) ?
Plus de 50 méthodes objet sont apparues durant cette période (Booch, Classe-
Relation, Fusion, OMT, OOA, OOD, OOM, OOSE...) !
Aucune méthode ne s'est réellement imposée.
7
Historique
Les premiers consensus (1995)

OMT (James Rumbaugh) : Object Modeling Techniques a pour vues :
Statiques : ne modifie pas l’objet
Dynamiques : peut modifier l’objet
Fonctionnelles : séquences d’appels de fonctions d’une utilisation
OOD (Grady Booch) : Oriented Object Design a pour vues :

Logique : décomposition logicielle
Physiques : décomposition matérielle
OOSE (Ivar Jacobson) : Oriented Object Software Engineering a des vues basées sur
le cycle vie logiciel
Analyse
Conception
Réalisation/Implémentation
Test/Maintenance
La genèse d’UML (Unified Modeling

Language
97 (novembre): adopté par l’OMG UML 1.1 UML 1.2 UML 1.3 UML 1.4 UML 1.5 UML 2.0
97 (janvier) : soumission OMG UML 1.0 industrialisation
96 : soumission à un UML 0.9

consortium de partenaires standardisation
95 : spécification Méthode unifiée 0.8

sur internet
unification
Booch 93 OMT-2
Autres méthodes Booch 91 OMT-1 OOSE Partenaires fragmentation

(Rational, IBM, HP,…)
8
UML : Vue générale
L'unification et la normalisation des méthodes (1995-1997)

UML (Unified Modeling Langage), la fusion et synthèse des méthodes dominantes
Cycle de vie logiciel
UML couvre toutes les phases du cycle de vie
Indépendance
UML est indépendant du domaine d’application et des langages d’implémentation
Standard
Intégré dans de nombreux outils de modélisation (Rational Rose, Objecteering,
TogetherSoft, Visio, …)
Format d’échange
Utilise XML pour échanger les modèles UML
Introduction à l’UML
UML (Unified Modeling Language) permet aux constructeurs de

systèmes de créer des modèles représentant leur vision du réel
d’une façon standard, facile à comprendre et à communiquer.
UML fournit l’organisation qui permet aux analystes, aux clients,

aux programmeurs et à toute personne impliquée dans le
développement du système, de comprendre et de s’entendre sur la
modélisation du système.
Un potentiel d’erreurs liées à la communication existe dans chaque

étape du développement du système. UML en tant que langage
unifié permet de réduire la marge d ’erreur.
9
1 0
0 2
2 0
2
Modéliser avec UML
Les concepts de base
Langage UML
Démarche Associée
Qu’est-ce qu’un modèle ?
Un modèle est une représentation semi formelle, formelle ou

abstraite d’un problème posé en langage naturel
Un modèle se réalise à travers un langage de modélisation
Selon le découpage des informations un modèle peut être orienté

objet ou fonction
Un modèle objets fait ressortir les objets du langage naturel
Le produit final d'une modélisation (utilisation d’un modèle) est un

diagramme.
10
Les diagrammes UML
Diagramme
Objets Séquence Collaboration Activités

Classes
Cas d'utilisation Etats-Transitions Composants Déploiement
Modéliser différentes vues du Système d’Information
Vues classiques de modélisation

Trois axes de modélisation
Fonctionnel
Diagramme de cas d’utilisation
Statique Dynamique
Diagramme de classes Diagramme de séquence
Diagramme des objets Diagramme des collaboration
Diagramme d’états-transitions
Diagramme d’activités
11
Vues classiques de modélisation
Aspects implantation
diagramme de composants : implantation
diagramme de déploiement : structure matérielle et distribution des objets et des

composants
Les diagrammes UML 2.0

UML 2.0 déposée à l’OMG en 2003 13 digrammes…
12
Utilisation des diagrammes UML
Étapes de développement Diagrammes et langages utilisés
Expression des besoins Cas d’utilisation

Diagramme de séquences
Analyse Cas d’utilisation
Diagrammes de classes
Conception Diagrammes de classes
Langage de conception
Implantation Java
1 0
0 2
2 0
2 Diagramme de Cas
d’utilisation
Langage UML
Démarche Associée
13
Diagrammes de cas d’Utilisation
But : assurer une communication aisée entre les

utilisateurs et les experts du domaine et les informaticiens
Graphisme simple et langue naturelle
Détermination des besoins du système par catégorie
d’acteurs (utilisateurs).
Les concepts utilisés pour les cas d’utilisation sont utilisés
pour définir le comportement du système sans spécifier sa
structure interne.
Cas d’Utilisation
Un cas d’utilisation se représente

par une ellipse contenant le nom Système
du cas, et optionnellement, au-
dessus du nom, un stéréotype. cas d’utilisation
u
La frontière du système est Acteur A
représentée par un cadre.
cas d’utilisation
Le nom du système figure à x
l’intérieur du cadre, en haut.
cas d’utilisation
Les acteurs sont à l’extérieur et les Acteur A
y
cas d’utilisation à l’intérieur.
14
Cas d’utilisation : exemple
Créer compte
Guichetier
Consulter compte
Retrait compte Client
Retrait
Directeur
distributeur
régional
Gérer prêts
Cas d’Utilisation
Les use cases, permettent de modéliser les besoins des clients d'un
système et doivent aussi posséder ces caractéristiques. Ils ne doivent
pas chercher l'exhaustivité, mais clarifier, filtrer et organiser les
besoins !
Dernière remarque : Utilisez les use cases tels qu'ils ont été pensé par
leurs créateurs ! UML est issu du terrain. Si vous utilisez les use cases
sans avoir en tête la démarche sous-jacente, vous n'en tirerez aucun
bénéfice.
15
Cas d’utilisation : concepts
L’acteur
Le cas d’utilisation
Relation entre acteur et cas d’utilisation
Relation entre cas d’utilisation
« Etend» (« extends »)
« Inclut » (« includes »)
Relation entre acteurs

L’évènement
Le sénario
Cas d’utilisation : les acteurs
Représente un rôle joué par une personne ou une chose qui interagit
avec un système.
Néanmoins, il ne faut pas raisonner que sur des personnes

physiques, car c'est plus dans le rôle, qu'il convient de rechercher
l'acteur :
Un acteur définit un ensemble de rôles cohérents que les

utilisateurs de ce système peuvent jouer en interagissant avec le
système.
16
Exemple :
Un garagiste passe le plus clair de son temps dans le rôle du mécanicien, mais peut à
l’occasion jouer le rôle de vendeur. Le dimanche, il joue le rôle de client et entretient sa
voiture personnelle.
Conduire
Client
Entretenir
Vendre vendeur
réparer
mécanicien

Il existe quatre grandes catégories d’acteurs :
Les acteurs principaux : les personnes qui utilisent les fonctions principales du
système. Dans le cas d’un distributeur de billets, il s’agit des clients.
Les acteurs secondaires : les personnes qui effectuent des tâches

administratives ou de maintenance. Dans le cas d’un distributeur de billets, il
s’agit de la personne qui recharge la caisse contenue dans le distributeur.
Le matériel externe : les dispositifs matériels incontournables qui font partie

du domaine de l’application et qui doivent être utilisés. Dans le cas d’un
distributeur de billets, il s’agit de l’imprimante.
Les autres systèmes : les systèmes avec lesquels le système doit interagir.
Dans le cas d’un distributeur de billets, le système de groupement bancaire qui gère
un parc de distributeurs est un acteur.
17
Cas d’utilisation
Analyse de ce que l’utilisateur attend du système : consulter-compte,

retrait-distributeur,…
Un cas d’utilisation décrit une interaction entre l’utilisateur et le

système.
Un cas d’utilisation est une manière d’utiliser le système «un besoin

utilisateur». Une façon générale d’utiliser une partie de la
fonctionnalité du système.
Un cas d’utilisation est une séquence de transactions offertes par le

système.
Les cas d’utilisation
Les cas d’utilisation servent de fil conducteur tout au long du projet.
Utilisateur Exprime Comprend Analyste
Cas d'utilisation
Réalise
Conçoit Vérifie
Programmeur Testeur
Architecte
18
Relation entre acteur et cas d’utilisation
La relation entre cas d’utilisation et acteur est une relation

d’association. C’est le chemin de communication entre un acteur et
un cas d’utilisation et est représenté par un trait continu
Un acteur est qualifié de principal pour un cas d’utilisation lorsque

ce cas rend service à cet acteur. Un acteur principal obtient un
résultat observable du système.
Tandis qu’un acteur secondaire est sollicité pour des informations

complémentaires.
UML définit trois types de relations entre cas d’utilisation :
Inclusion (formalisé par le stéréotype « include »): permet à un cas d’utilisation de faire appel
aux services d’un autre cas. Cette relation permet de « factoriser » une fonctionnalité invocable
dans plusieurs cas d’utilisation.
Exemple
« inclut »
Retrait Identification
distributeur client
19
Extension (formalisé par le stéréotype « extends ») : La relation d’extension permet de

définir un cas d’utilisation comme l’extension d’un autre cas. En particulier, elle permet
de décrire des processus exceptionnels ou optionnels.
Exemple
« Etend » Retrait compte

Consultation Si demande du solde
solde Point d’extension:
Après le retrait
Consultation solde étend le comportement de Retrait compte sous condition (facultatif)
Généralisation : La relation de généralisation permet de définir un cas d’utilisation

comme la généralisation d’un ou plusieurs autres cas.
Exemple
Modification
article
Supprimer un Ajouter un
composant d’un composant d’un
article article
20
La seule relation possible entre deux acteurs est la

généralisation : un acteur A est une généralisation d’un
acteur B si l’acteur A peut être substitué par l’acteur B.
Dans ce cas, tous les cas d’utilisation accessibles à A le
sont aussi à B, mais l’inverse n’est pas vrai.
Le symbole utilisé pour la généralisation entre acteurs est

une flèche avec un trait plein dont la pointe est un triangle
fermé désignant l’acteur le plus général
Exemple
Passer une commande

Préposer au
commande
Suivre commande
Gérer le stock
Directeur
des ventes
21
Description détaillée de chaque cas d’utilisation
Chaque cas d ’utilisation doit être décrit en détail
Commencer par les CU prioritaires
Description utile pour la suite du développement
Description détaillée plus où moins formelle

langue naturelle mais structurée, vocabulaire précis
Description détaillée de chaque cas d’utilisation
Information à décrire :
Quand le CU commence, pré-conditions

Quand le CU se termine, post-conditions
Le chemin correspondant au déroulement normal
Les variantes possibles et les cas d’erreurs
Les interactions entre le système et les acteurs
Les informations échangées
Les éventuels besoins non fonctionnels
22
Exemple de description détaillée d’un CU
Précondition :
Le distributeur contient des billets, il est en attente d ’une
Retirer opération, il n’est ni en panne, ni en maintenance
DeLArgent
AuDistributeur Début : lorsqu ’un client introduit sa carte bancaire dans le
distributeur.
Fin : lorsque la carte bancaire et les billets sont sortis.
Postcondition :
Si de l ’argent a pu être retiré la somme d’argent sur le
compte est égale à la somme d ’argent qu’il y avait avant,
moins le montant du retrait. Sinon la somme d ’argent sur
le compte est la même qu’avant.
Déroulement normal :
(1) le client introduit sa carte bancaire
(2) le système lit la carte et vérifie si la carte est valide
Retirer (3) le système demande au client de taper son code
DeLArgent
AuDistributeur
(4) le client tape son code confidentiel
(5) le système vérifie que le code correspond à la carte
(6) le client choisi une opération de retrait
(7) le système demande le montant à retirer
…
Variantes :
(A) Carte invalide : au cours de l ’étape (2) si la carte est
jugée invalide, le système affiche un message d ’erreur,
rejète la carte et le cas d ’utilisation se termine.
(B) Code erroné : au cours de l ’étape (5) ...
23
Contraintes non fonctionnelles :
Retirer (A) Performance : le système doit réagir dans un délai

DeLArgent inférieur à 4 secondes, quelque soit l ’action de
AuDistributeur l ’utilisateur.
(B) Résistance aux pannes : si une coupure de courant ou

une autre défaillance survient au cours du cas d ’utilisation,
la transaction sera annulée, l ’argent ne sera pas distribué.
Le système doit pouvoir redémarrer automatiquement
dans un état cohérent et sans intervention humaine.
...
Cas d’utilisation : scénario
Un scénario est une exécution particulière d’un cas d’utilisation.

Un scénario est instancié dès qu’un acteur déclenche un cas d’utilisation.
Description d’un scénario :

Scénario principal : description du chemin « normal » d’exécution
du cas d’utilisation;
Exemple : Retrait-distributeur pour un client existant et fiable,
Scénarios secondaires :description de cas alternatifs (plusieurs
choix), de cas exceptionnels ou de cas d’erreur.
Exemple retrait-distributeur pour un client donnant un code errone
24
1 0
0 2
2 0
2
Langage UML
Démarche Associée
Dans la phase de conception, les diagrammes d’activités sont particulièrement adaptés à la

description des cas d’utilisation. Ils viennent illustrer et consolider la description textuelle des cas
d’utilisation.
Un diagramme d’activités donne une vue simplifiée de ce qui se passe durant une opération ou
un processus en présentant l’algorithme correspondant.
Un diagramme d’activités visualise un graphe d’activités qui modélise le comportement interne

d’une méthode ou d’un objet ou d’un cas d’utilisation :
Ils ne sont pas spécifiquement rattachés à un classeur particulier. On peut attacher un diagramme
d’activités à n’importe quel élément de modélisation afin de visualiser, spécifier, construire ou
documenter le comportement de cet élément.
25
Cas d’utilisation : concepts
Nœud d’activité
Transition
Nœud initial et nœud final
Nœud de décision
Nœud de bifurcation / d’union
Les Travées (Partition)
Nœud d’activité
Un noeud d’activité est un type d’élément abstrait permettant
de représenter les étapes le long du flot d’une activité.
Il existe trois familles de noeuds d’activités :

les noeuds d’exécutions (executable node)
les noeuds objets (object node)
les noeuds de contrôle (control nodes)
26
Nœud d’activité
Nœud action Nœud d’objet
Nœud initial
Nœud Objet
Nœud final
un noeud de bifurcation ou d’union

Nœud décision
le noeud représentant une action, qui
est une variété de noeud exécutable
Transition
Le passage d’une activité vers une autre est matérialisé par une transition.
Graphiquement les transitions sont représentées par des flèches en traits pleins qui
connectent les activités entre elles.
Elles sont déclenchées dès que l’activité source est terminée et provoquent
automatiquement et immédiatement le début de la prochaine activité à déclencher
(l’activité cible).
Les transitions spécifient l’enchaînement des traitements.
Nom de l’activité Nom de l’activité
27
Nœud initial / Nœud final
Nœud initial
Un noeud initial est un noeud de contrôle à partir duquel le flot
débute lorsque l’activité enveloppante est invoquée.
Un noeud initial possède un arc sortant et pas d’arc entrant.
Nœud final
Lorsque l’un des arcs d’un noeud de fin d’activité est activé,
l’exécution de l’activité enveloppante se termine.
Nœud de décision
Un noeud de décision est un noeud de contrôle qui permet de faire un choix entre
plusieurs flots sortants.
Il possède un arc entrant et plusieurs arcs sortants.
Les nœuds de décision sont généralement accompagnés de conditions de garde pour

conditionner le choix.
Si, quand le noeud de décision est atteint, aucun arc en aval n’est franchissable , c’est que
le modèle est mal formé.
L’utilisation d’un garde [else] est recommandée après un noeud de décision car elle
garantit un modèle bien formé.
Dans le cas où plusieurs arcs sont franchissables, seul l’un d’entre eux est retenu et ce
choix est non déterministe.
28
Nœud de décision
Vérifier
Nœud de décision
solde
Transition gardée
Garde
[Solde
Suffisant] [else]
Donner Refuser
argent au de donner
client l’argent
Nœud de bifurcation et d’union

Une transition peut être séparée en deux chemins
concurrents qui s’exécutent simultanément et qui se
joignent en fin d’exécution.
Nœud de bifurcation
Décision de
refroidir
La séparation et la réunion (ouverture/fermeture)
sont représentées par des barres de synchronisation
appelées :
Arrêter le Aérer
Noeud de bifurcation. Un tel noeud possède chauffage
un arc entrant et plusieurs arcs sortants.

Un nœud d’union est un noeud de contrôle qui
synchronise des flots multiples. Un tel noeud
possède donc plusieurs arcs entrants et un seul Mesurer la
température
arc sortant.
Nœud d’union
29
Barre de synchronisation
Desserrer Lancement de 2 transitions
frein à main simultanées
Noeud Appuyer sur Enclencher

embrayage 1ère vitesse
Barre de synchronisation
synchronisation de 2 transitions
relâcher
embrayage
Les travées
• Les diagrammes d’activités peuvent être découpés en travées pour

montrer les différentes responsabilités au sein d’un processus.
• Les partitions n’ont pas de signification bien arrêtée, mais

correspondent souvent à des unités d’organisation du modèle.
30
Les travées : Exemple
Il est possible de
faire apparaître
clairement les
objets dans un
diagramme
d’activité.
Diagramme d’activités : Synthèse
UML permet de représenter graphiquement le comportement d'une méthode ou le

déroulement d'un cas d'utilisation, à l'aide des diagrammes d'activités.
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.
31
Exemple : Description des scénarii du UC « Retirer-
Argent »
1 0
0 2
2 0
2 Diagramme de classes
Langage UML
Démarche Associée
32
Diagramme de Classes
Le diagramme de classes exprime la structure statique du système en termes de
classes et de relations entre ces classes.
L’intérêt du diagramme de classe est de modéliser les entités du système

d’information.
Le diagramme de classe permet de représenter l’ensemble des informations qui sont

gérées par le domaine. Ces informations sont structurées, c’est-à-dire qu’elles sont
regroupées dans des classes. Le diagramme met en évidence d’éventuelles relations
entre ces classes.
Le diagramme de classes comporte 6 concepts :

classe
attribut
Méthode
relation
Agrégation
généralisation / spécialisation, etc.
Les diagrammes de classes

Classe & Objet
Regroupement d’un ensemble d’objets qui se ressemblent (qui

partagent les mêmes attributs, opérations, méthodes, relations et
contraintes) et pour lesquels on veut gérer de l’information.
Une classe est la description formelle d’un ensemble d’objets ayant

une sémantique et des caractéristiques communes.
Un objet est une instance d’une classe. C’est une entité dotée d’une
identité, d’un état et d’un comportement que l’on peut invoquer.
33
Classe & Objet
Représentée par un rectangle composée de 3 parties :
le nom de la classe,
les attributs,
les opérations
Classe détaillée :
Les attributs sont typés, les méthodes sont spécifiées et le niveaux
de protection des membres sont renseignés.
Classe documentée
Voiture
Voiture
Attribut public +marque : String
(Ici, noms symboliques) marque +immatriculation : String
attributs immatriculation +propriétaire : String
propriétaire Attribut protégé #puissanceFiscale : entier
#poidsVide : entier
(Ici, noms symboliques) démarrer #/Age : entier
méthodes conduire Attribut privé -dateFabrication : Date
arrêter -proprietaire : Personone
Méthode publique +demarrer ( )

Méthode privée -arreter ( )

Attributs
Un attribut est une propriété d’une classe ; il décrit une gamme de valeurs que la propriété
peut prendre à l’intérieur d’un objet (instance) d’une classe.
La notation UML permet d’ajouter des informations complémentaires aux attributs ; il est
possible de spécifier le type de valeur de chaque attribut ( chaîne de caractères, nombre
entier, booléen…). On peut aussi donner une valeur par défaut à un ATTRIBUT.
Le nom de l’attribut doit être unique dans la classe. La syntaxe de la déclaration d’un
attribut est la suivante :
visibilité nom : type = valeur initiale
Remarque : On appelle Attribut dérivé tout attribut qui peut être déduit d’un ou plusieurs
autres attributs (représenté par le symbole /)
34
Une Méthode est un service que l ’on peut demander à un objet pour
réaliser un comportement.
Dans une classe, une opération (même nom et même types de

paramètres) doit être unique.
Quand le nom d’une opération apparaît plusieurs fois avec des

paramètres différents, on dit que l’opération est surchargée.
La déclaration d’une opération contient les types des paramètres et le

type de la valeur de retour, sa syntaxe est la suivante :
visibilité nom (paramètres) : type retour

Remarque :
En pratique, on modélise souvent plusieurs classes ; il n’est alors pas toujours

utile d’afficher tous les attributs et les méthodes. Cela rendrait le modèle illisible.
Il est possible de ne pas visualiser les attributs et méthodes ou d’en indiquer

seulement certains en les faisant suivre par 3 points.
Si la liste des attributs ou opérations est très longue, l’usage de stéréotypes

permettra de l’organiser et de la rendre plus compréhensible en créant de
nouveaux éléments spécifiques au problème à résoudre.
Exemple :
Lave Linge
nomModèle
…
ajouterVêtement()
…
35
Rappel
Public ou + : l’accès est possible de tous les objets de toutes les

autres classes.
Private ou - : l’accès n’est possible que depuis l’intérieur des

objets. Seules les opérations définies dans la classe peuvent
manipuler l’attribut.
Protected ou # : l’accès est possible pour les objets d’une sous

classe. (héritage)

Résumé de la notation
Nom-de-classe CLASSE
Visibilité : nom-attribut1 [: type-de-donnees1] [= valeur-défaut1]
+ ..… Attribut
-
#
nom-opération1 [(liste-argument1)] [: type-resultat1]

..… Méthode
Nom-objet : Nom-de-classe
OBJET
nom-attribut1 = valeur1
....
36
Résumé de la notation : Exemple Nom de la Classe
Initialisation
Fenetre
Visibilité + taille : Rectangle = 100,100
}
- visible : B oolean = true
couleur : C olor = blue Attributs
#$ tailleMax : Rectangle
Static #$ tailleMin : Rectangle
/#$ tailleMoyenne : Rectangle
Dérivé + afficher() : P osition

+ cacher()
# setTaille(taille : Rectangle)
} Méthodes
Retour
Paramètre

Association
Exprime une connexion sémantique bi-directionnelle entre classes

Abstraction des liens qui existent entre objets
Le sens d ’une association peut-être précisé par une flèche
Association binaire = Association entre deux classes.
Elle est représentée par une ligne connectant les deux classes et portant le nom de
l’association au dessus de la ligne.
Il est utile de représenter l’orientation de l’association à l’aide d’un triangle plein

pointant vers la direction voulue.
Exemple :
Joueur Joue dans Equipe
37
Multiplicité des Associations binaires
Précise combien d’objets d’une classe peuvent se rattacher à un seul objet d’une
classe associée,
Association binaire est bi-directionnelle : multiplicité des deux côtés
Exemple :
Multiplicités conventionnelles
1 Un et un seul
Client A-pour-compte 1..* Compte
1 0..1 Zéro ou un
nom n°compte M..N De M à N (entiers naturels)
* De zéro à plusieurs
1,1 0..* De zéro à plusieurs
1..* De un à plusieurs

Rôle
Quand une classe est associée à une autre, chacune des classes joue généralement un rôle précis
dans l’association.
le nom du rôle est écrit à côté de la classe jouant ce rôle :

une personne assume le rôle d’employé pour sa société
une société joue le rôle d’employeur pour une personne
Exemple
chef 1..* Travaille-pour 1 Société

Personne
0..1 employés employeur
Dirige
* subordonnés
38
Association : Exemple récapitulatif
Rôle
Personne Nom Entreprise

-employé emploie -employeur Raison Sociale
Nom
Prénom Activité
1..* 0..1
Classe
Multiplicité
Association réflexives
Association réflexives
Une classe peut être en association avec elle-même ; ce cas se produit

lorsqu’une classe possède des objets pouvant jouer différents rôles (c’est une
association qui s’applique a des objets d’une même classe).
Exemple :
conduit
Chauffeur 1
Occupant voiture
0..4
Passager
39
Associations n-aire
C’est une association parmi trois classes ou plus. Chaque instance de l’association est un n-
tuple de valeurs des classes respectives.
Exemple :
Un joueur peut jouer pour
plusieurs équipes une année donnée
plusieurs années pour la même équipe
Chaque équipe a plusieurs joueurs la même année
Un bilan annuel est associé à chaque joueur dans une équipe
Equipe
joueur Année JOUEUR EQUIPE ANNEE V D
dupont louvetaux 96 6 2
durand louvetaux 96 3 4
victoires dupont totoche 96 4 5
défaites dupont totoche 97 5 3

Associations ternaire : Exemple 2
Salle
lieu 1
Cours
Professeur 1 Elève
1..*
Heure de début
Heure de fin
40
Agrégation : Association particulière : «composé-composant», «partie-de»,

«agrégat, composant».
Une agrégation représente une association non symétrique dans laquelle une des
extrémités joue un rôle prédominant par rapport à l’autre extrémité.
Dans les opérations l’agrégat est souvent un objet traité comme un tout
On représente une agrégation comme une hiérarchie représentant la classe "agrégat"
en haut du diagramme avec une ligne finissant par un losange vide du côté de la
classe "agrégat"
Exemple :
Ordinateur
Haut-parleur Clavier
CPU
Ecran Souris
Agrégation : Pourquoi :
Elle définit un point de contrôle unique pour l’objet représentant l’assemblage.
Si une instruction affecte l’ensemble de l’assemblage, l’objet détenant le contrôle
dicte la façon dont les membres répondent.
Exemple : Accélération de la voiture : si on appuie sur la pédale d’accélération on a

un ensemble d’objet qui vont interagir pour accélérer.
1
Carrosserie
1
Voiture Moteur
4
Roues
41
Composition : une Agrégation particulière
le composant n’appartient qu’à un seul composé. Autrement dit, une instance de la partie
appartient toujours à au plus une instance de l’élément composite : la multiplicité du côté
composite ne doit pas être supérieure à 1 (i.e. 1 ou 0..1).
le composant peut naître hors de son composé, par contre il meurt avec son composé.
Autrement dit le cycle de vie des parties lié à celui du composite
le composant n’intervient pas dans d ’autres association de composition ni agrégation.
le plus souvent pas d ’«accès» direct (les demandes de services « passent » par le composé)
Exemple :
* Division * Service
Société
0..1 ou 1..1 Le cycle de vie d ’une

division est inclus
dans celui de sa société
Composition : Exemple 2
Composition : si le livre est détruit
alors chapitre n’existe plus
1..1 1..*
Livre Chapitre
1 64
Échiquier Case
42
Généralisation
Relation ente un élément plus général et un élément plus spécifique qui est entièrement
conforme avec le premier élément, et qui ajoute de l ’information supplémentaire
Les attributs et les opérations hérités ne sont pas représentés dans les classes filles.
Une classe fille peut ajouter des attributs et des opérations à ceux qui sont hérités. On parle
de spécialisation.
Elle peut redéfinir une propriété héritée :
- surcharge du code d’une méthode
- redéfinition des valeurs par défaut d’un attribut
- restriction des types des attributs ou des paramètres d’une méthode
Animal
- expression des contraintes supplémentaires.…
Reptile Mammifère
Cheval
Rappel : Classe Article

attributs
référence
prixHT Dans Article :
quantité : entier prixTTC() : retourner 1,06 * prixHT
Factorisation méthodes
prixTTC() Dans Article-Luxe :
prix-net() prixTTC() : retourner 1,33 * prixHT
prix-transport()
Classe Électroménager
attributs Classe Article-Luxe
duréegarantie : entier attributs
poids : réel quantité : [0..100]
méthodes méthodes
valider() prixTTC()
garantie()
43
Héritage multiple
Une classe dite de jointure admet plusieurs super-classes
Héritage multiple de classes appartenant à deux généralisations distinctes
Véhicule
Véhicule Terrestre Véhicule Marin
.... Voiture Véhicule Amphibie Bateau

Contraintes…
Les concepts de base des Diagrammes de Classes permettent d’exprimer un certain
nombre de contraintes : multiplicité, qualification, etc.
Les autres sont exprimées entre {..} dans une note
Exemple de contraintes sur les objets
{âge = date courante - date naissance} Employé chef

0..1
/age
salaire
date-naissance *
{[self].salaire < {[self]. chef.salaire}
44
Contraintes…
Exemple de contraintes sur les liens : {ordonné}, {pas de répétition}...
Exemple de contraintes inter-liens (contraintes ensembliste)
Entreprise
Membre de
0..* 0..*
Compte {or}
{inclus}
Personne Comité
Personne
1 0..*
Président du
La méta-modélisation
Qu’est-ce qu’un méta-modèle ?

Modèle d’un ensemble de modèles
Grammaire décrivant un langage de modélisation
Définit la syntaxe abstraite des modèles
Pourquoi des méta-modèles ?

Pour éditer et valider les modèles
Pour transformer des modèles
Règles de transformation entre méta-modèles
45
Hiérarchie de modélisation à 4 niveaux
L’OMG définit 4 niveaux de modélisation :

M0 : système réel, système modélisé
M1 : modèle du système réel défini dans un certain langage

M2 : méta-modèle définissant ce langage
M3 : méta-méta-modèle définissant le méta-modèle
Le niveau M3 est le MOF
Dernier niveau, il est méta-circulaire : il peut se définir lui-même
Le MOF est – pour l'OMG – le méta-méta-modèle unique servant

de base à la définition de tous les méta-modèles
M3 MOF
M2 MétaModèle GestionEntreprise
MétaModèle SystèmesTechniques
M1 Modèle 1 Modèle 2 Modèle 3 Modèle 4
M0 Système Système Système

Facturation
d’information embarqué Télécom
46
Hiérarchie à 4 niveaux existe en dehors du MOF et d'UML, dans

d'autres espaces technologiques que celui de l'OMG
Langage de programmation
M0 : l'exécution d'un programme
M1 : le programme
M2 : la grammaire du langage dans lequel est écrit le programme
M3 : le concept de grammaire EBNF
XML
M0 : données du système
M1 : données modélisées en XML
M2 : DTD / Schéma XML
M3 : le langage XML
M2 : Méta-modèle UML (très simplifié)
47
Lien éléments modèle / méta-modèle
Le langage OCL
Diagrammes UML insuffisants
Pour spécifier complètement une application
Diagrammes UML seuls sont généralement insuffisants
Nécessité de rajouter des contraintes
Comment exprimer ces contraintes ?
Langue naturelle mais manque de précision, compréhension , pouvant être ambigüe
Langage formel avec sémantique précise : par exemple OCL
OCL : Object Constraint Language
Langage de contraintes orienté-objet
Langage formel (mais simple à utiliser) avec une syntaxe, une grammaire, une
sémantique (manipulable par un outil)
S'applique entre autres sur les diagrammes UML
48
Le langage OCL : exemple
M1 : spécification du système + contraintes OCL
context Mur inv: fenetre -> union(porte) -> size() <= 1

-- un mur a soit une fenêtre soit une porte (soit rien)
context Piece inv:

mur.fenetre -> size() = 2 -- 2 murs de la pièce ont une fenêtre
mur.porte -> size() = 1 -- 1 mur de la pièce a une porte
Exercice 1
Un répertoire possède un nom et des droits de lecture, d’exécution et d’écriture.
Proposer une modélisation sous forme de classe de cette notion de répertoire.
Un fichier possède un nom et des droits de lecture, d’exécution et d’écritures

Proposer une modélisation sous forme de classe de cette notion de fichier.
Fusionner ces deux notions sur un même diagramme.
Un répertoire peut contenir des répertoires et des fichiers.

Proposer une modélisation de ces relations.
Les fichiers et les répertoires possèdent :

une méthode pour l’effacement et le renommage.
Un répertoire possède également :

une méthode permettant d’accéder au répertoire parent,
une méthode permettant de lister son contenu et
une méthode permettant de se rendre dans l’un de ses sous-répertoires en précisant son nom.
Compléter votre diagramme de classes en conséquence.
Toutes les propriétés structurelles des répertoires et des fichiers sont privées.
Compléter votre diagramme de classes en précisant les méthodes d’accès.
49
Exercice 2
Un répertoire contient des fichiers.
Une pièce contient des murs.
Les modems et claviers sont des périphériques d’entrée / sortie.
Une transaction boursière est un achat ou une vente.
Un compte bancaire peut appartenir à une personne physique ou

morale.
1 0
0 2
2 0
2 Diagramme d’Objets
Le Langage UML
La démarche RUP

50
Diagrammes d’objets
Représentation d’un ensemble d’objets et de liens, exprimant
la structure statique.
Un diagramme d’objets est une instance d’un diagramme de

classes et illustre l’état d’un système à un moment donné.
Les diagrammes d’objets s’utilisent principalement :

pour montrer un contexte (par exemple avant ou après une
interaction),
pour faciliter la compréhension des structures de données
complexes.
Le diagramme objet est simplement constituer de deux

éléments :
Les objets
Les liens entre objets
51
Objet : correspond a une instance de la classe.

Un objet est représenter par deux compartiment :
Le nom de l’objet avec le nom de sa classe.
NomObjet : NomClasse
La valeur des attributs avec leurs nom.
nomAttribut = valeur
Personne
foulen : Personne
- Nom : String
- Prenom : String Nom = Ben Foulen
-Age : int Prenom = Foulen
Age = 25
+ getAge() : int
+getNom() : String
Un objet
…
Objet (Suite)
Un objet peut ne pas avoir de nom

on parle d’objet anonyme
: Personne
Un objet anonyme
On utilise les objets anonymes dans le cas ou n’importe quel objet

se comporte de la même façon.
52
Objet : Exemples de représentation
Lien
Les objets sont reliés par des instances d’associations : les liens.
Un lien représente une relation entre objets à un instant donné.
ATTENTION : la multiplicité des extrémités des liens est toujours de 1.
Exemple : représentation de la structure générale d’une voiture :
1
Voiture Moteur :Voiture :Moteur
4
Roue :Roue :Roue :Roue :Roue
D. classes D. Objets
53
Synthèse
Tracer un diagramme de classe et supposer qu’il est

correct est un piège dans lequel il est facile de tomber.
Le diagramme objet est un des diagramme qui permet

de tester la validité du diagramme de classe
D. classes Vs D. Objets
D. Classe D. Objet
1. Les classes ont 3 compartiments 1.Les objets ont deux
: nom, attributs et méthodes compartiments : nom et attributs
2.Le nom de la classe est seul 2.Le format du nom de l’objet est
dans le compartiment du nom. NObj : NClass.
On peut parfois omettre le nom de
l’objet objet anonyme.
54
D. Classe D. Objet
3. Le compartiment des attributs 3. Les objets définissent les
définit les propriétés de l’attribut. valeurs des attributs.
4. Les opérations sont présentes 4. Les opérations ne sont pas

dans la classe. incluses car elle seront identiques
pour tous les objets.
D. Classe D. Objet
5.Les objets sont connectés avec
5. Les classes sont connectées par
des liens qui ont des noms et pas
des associations avec un nom et
de multiplicité. Les objets
une multiplicité, contrainte, rôle,
représentent des entités uniques et
…
les liens sont un-a-un c’est
pourquoi la multiplicité est non
relevante. Tandis qu’on peut
utiliser la notion de rôle dans les
liens.
55
Exemple 2
L’exemple partiel qui suit est extrait du livre “Instant UML” (Pierre-Alain Muller)
Il s’agit d’un système de sécurité limitant les accès à des parties d’un bâtiment à l’aide de
cartes magnétiques.
Exemple 2 (suite)
Le système gère un seul bâtiment contenant trois portes.
Le système peut être géré par une personne nommée « Tolkien ».
Deux utilisateurs peuvent accéder au bâtiment :
« Gandalf » a accès à la première (8h-18h) et seconde porte (12h-24h)
« Bilbon » a accès `a la troisième porte toute la journée.
56
Le système gère un seul
bâtiment contenant trois
portes.
Le système peut être géré
par une personne nommée
« Tolkien ».
Deux utilisateurs peuvent
accéder au bâtiment :
« Gandalf » a accès à la
première (8h-18h) et
seconde porte (12h-24h)
« Bilbon » a accès `a la
troisième porte toute la
journée.
Exercice
Une expression binaire est constituée de deux termes (1er opérande et

2ème opérande) et caractérisée par un opérateur. Un terme est une
expression, une constante ou une variable.
Exemples :
(x + y/2) / (x/3 + y),
(x + y/2), etc.
1.Proposer un diagramme de classes pour les expressions binaires.

2.Proposer un diagramme d’objets pour l’expression suivante : (x + 2)-3
57

CoursUml PartieI

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

CoursUml PartieI

Transféré par

Droits d'auteur :

Formats disponibles

Institut Supérieur des Sciences Appliquées et de Technologie de Sousse

Enseignant : Dr. Mhamed Saidane

Analyse et Conception orientée objet

Les patrons de conception

Dr. Mhamed Saidane 1ème Ing - A.U. 2019 - 2020 2

Les patrons de conception Enseignant : Dr. Mhamed Saidane

16,2% des projets conformes aux prévisions initiales.

52,7% ont subi des dépassements en coût et délai avec diminution

31,1% ont été purement abandonnés durant leur développement.

Dr. Mhamed Saidane 1ème Ing - A.U. 2019 - 2020 4

Le taux de succès est de 9% seulement,

Le taux d’échec des projets (arrêt en cours de réalisation) est de

Le taux d’aboutissement hors délai et hors budget est de 50%.

Dr. Mhamed Saidane 1ème Ing - A.U. 2019 - 2020 5

Pour ces raisons, le développement de logiciels dans un contexte

Des règles strictes encadrant la conception

Ainsi, une nouvelle discipline est née : le génie logiciel.

Dr. Mhamed Saidane 1ème Ing - A.U. 2019 - 2020 6

L’objectif du génie logiciel est d’optimiser le coût de

Dr. Mhamed Saidane 1ème Ing - A.U. 2019 - 2020 7

Le Génie Logiciel Quand ?

Le génie logiciel touche au cycle de vie du logiciel :

Dr. Mhamed Saidane 1ème Ing - A.U. 2019 - 2020 8

Quel est l’utilité

Dr. Mhamed Saidane 1ème Ing - A.U. 2019 - 2020 9

Le choix du modèle a donc une influence capitale sur les

Selon les modèles employés, la démarche de modélisation

Dr. Mhamed Saidane 1ème Ing - A.U. 2019 - 2020 10

Dr. Mhamed Saidane 1ème Ing - A.U. 2019 - 2020 12

Pour avoir des informations sur UML

Dr. Mhamed Saidane 1ème Ing - A.U. 2019 - 2020 13

Les premières méthodes d'analyse (années 70)

L'approche systémique (années 80)

L'émergence des méthodes objet (1990-1995)

Dr. Mhamed Saidane 1ème Ing - A.U. 2019 - 2020 14

Les premiers consensus (1995)

OOD (Grady Booch) : Oriented Object Design a pour vues :

Dr. Mhamed Saidane 1ème Ing - A.U. 2019 - 2020 15

La genèse d’UML (Unified Modeling

97 (janvier) : soumission OMG UML 1.0 industrialisation

96 : soumission à un UML 0.9

95 : spécification Méthode unifiée 0.8

Autres méthodes Booch 91 OMT-1 OOSE Partenaires fragmentation

Dr. Mhamed Saidane 1ème Ing - A.U. 2019 - 2020 16

L'unification et la normalisation des méthodes (1995-1997)

Dr. Mhamed Saidane 1ème Ing - A.U. 2019 - 2020 17

UML (Unified Modeling Language) permet aux constructeurs de

UML fournit l’organisation qui permet aux analystes, aux clients,

Un potentiel d’erreurs liées à la communication existe dans chaque

Dr. Mhamed Saidane 1ème Ing - A.U. 2019 - 2020 18

Les patrons de conception Enseignant : Dr. Mhamed Saidane

Qu’est-ce qu’un modèle ?

Un modèle est une représentation semi formelle, formelle ou

Un modèle se réalise à travers un langage de modélisation

Selon le découpage des informations un modèle peut être orienté

Un modèle objets fait ressortir les objets du langage naturel

Le produit final d'une modélisation (utilisation d’un modèle) est un

Dr. Mhamed Saidane 1ème Ing - A.U. 2019 - 2020 20

Objets Séquence Collaboration Activités

Cas d'utilisation Etats-Transitions Composants Déploiement

Modéliser différentes vues du Système d’Information

Dr. Mhamed Saidane 1ème Ing - A.U. 2019 - 2020 21

Vues classiques de modélisation