3ISIL Chapitre 1 : Introduction au GL/ concepts de base de l’OO et Modélisation avec UML GL

Chapitre1 : Introduction au GL/ concepts de base de l’approche par

objets et la modélisation avec UML

1. Introduction

L’informatique s’est glissée dans la plupart de nos activités quotidiennes. Nombreux sont les appareils
qui utilisent des applications logicielles et qui deviennent complexes et couteuses avec le temps. La
demande de logiciels sophistiqués alourdit considérablement les contraintes imposées aux équipes de
développement. Les informaticiens sont confrontés à une complexité croissante, à cause de la nature
des applications, des environnements distribués et hétérogènes, de la taille des logiciels, de la
composition des équipes de développement, et des attentes des utilisateurs. Pour surmonter ces
difficultés, les informaticiens doivent apprendre à faire, à expliquer et à comprendre. C’est pour ces
raisons qu’ils ont et auront besoin de méthodes d’analyse et de conception pour leur guider dans les
différentes phases de conception.
L’approche objet est incontournable dans le cadre du développement de systèmes logiciels complexes,
capables de suivre les évolutions incessantes des technologies et des besoins applicatifs que la
programmation fonctionnelle. La modélisation apporte une grande rigueur, offre une meilleure
compréhension des logiciels, et facilite la comparaison des solutions de conception avant leur
développement. Cette étape permet de s’affranchir des langages d’implémentation. Plusieurs
méthodes orienté objet sont disponibles qui chacune utilise ses propres notation et spécifications. Une
unification des trois méthodes dominantes : Booch, OOSE (Object Oriented Software Engineering),
d’Ivan Jacobson et OMT (Object Modeling Technique), de James Rumbaugh, sont à l’origine de la
création du langage UML (Unified Modeling Language).
Ce chapitre se trouve partagé en quatre parties. Dans la première partie, une introduction au domaine
GL est faite. Dans la deuxième méthode, une présentation des méthodes d’analyse et de conception est
faite avec des définitions reliées comme la modélisation, le modèle…etc. Dans la troisième partie, une
présentation des concepts de base de l’orienté objet et dans la quatrième partie, une introduction au
langage de modélisation UML est faite.

2. Introduction au GL
2.1. Définitions
Le Génie Logiciel (GL) est un domaine des sciences de l’ingénieur dont l’objet d’étude est la
conception, la fabrication, et la maintenance des systèmes informatiques complexes.

Le génie logiciel est une branche de l'ingénierie associée au développement de logiciels utilisant des
principes, méthodes et procédures scientifiques bien définis. Le résultat de l'ingénierie logicielle est
un produit logiciel efficace et fiable.

IEEE définit le génie logiciel comme l'application d'une approche systématique, disciplinée et
quantifiable au développement, à l'exploitation et à la maintenance des logiciels.

Le génie logiciel est considéré comme étant un ensemble d’activités de conception et de mise en
œuvre des produits et des procédures tendant à rationaliser (normaliser) la production du logiciel et
3ISIL Chapitre 1 : Introduction au GL/ concepts de base de l’OO et Modélisation avec UML GL

son suivi. Autrement dit, le génie logiciel est l’art de produire de bons logiciels, au meilleur rapport
qualité prix.

L’objectif du GL est de répondre à un problème qui s’énonçait en deux constatations :

1. D’une part le logiciel n’était pas fiable,

2. De l’autre part, il était incroyablement difficile de réaliser dans des délais prévus des
logiciels satisfaisant leur cahier des charges.

Crise de l’industrie du logiciel (1970):

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

2.2. Cycle de vie d’un logiciel

Le Cycle de vie d’un logiciel (software lifecycle): ensemble d’étapes de développement d’un logiciel de
sa conception, sa réalisation, sa maintenance jusqu’à sa disparation. C’est la période de temps s’étalant
du début à la fin du processus du logiciel. L’origine du découpage provient du constat que les erreurs
ont un coût d’autant plus élevé qu’elles sont détectées tardivement dans le processus de réalisation.
Le cycle de vie permet de détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du logiciel, les
délais de sa réalisation et les coûts associés.
Il existe de nombreux modèles de cycle de vie du développement d’un logiciel. Les plus courants
comportent les phases suivantes:
1. Faisabilité: Déterminer si le développement proposé vaut la peine d’être mis en œuvre;
2. Spécifications: déterminer les fonctionnalités que doit assurer le logiciel:
1. Collecte des exigences: obtenir de l’utilisateur ses exigences pour le logiciel
2. Analyse du domaine: déterminer les taches et les structures qui se répètent dans le
problème
3. Organisation du projet: déterminer la manière dont développer le logiciel
1. Analyse des couts: établir une estimation du prix du projet
2. Planification: établir un calendrier pour le développement;
3. Assurance qualité du logiciel: déterminer les actions qui permettront de s’assurer de la
qualité du produit fini;
4. Répartition des taches: hiérarchiser les taches et sous-taches nécessaires au
développement du logiciel;

4. Conception: déterminer la façon dont le logiciel fournit les différentes fonctionnalités

recherchées;
1. Conception architecturale: déterminer la structure du système;
2. Conception des interfaces: déterminer la façon dont les différentes parties du système
agissent entre elles;
3. Conception détaillée: déterminer les algorithmes pour les différentes parties du système;
Qualité d’une conception:

Dr. Ouarda ZEDADRA 2

3ISIL Chapitre 1 : Introduction au GL/ concepts de base de l’OO et Modélisation avec UML GL

1. Cohésion: un composant devrait implémenter une seule fonction logique ou une seule
entité logique. Elle signifie que chaque unité ne représente qu’une partie de la résolution
du problème. Il faut une forte cohésion dans le composant;
2. Couplage: c’est une indication de la force d’interconnexion des différents composants d’un
système. En règle générale, des modules sont fortement couplés lorsqu’ils utilisent des
variables partagées ou lorsqu’ils échangent des informations de contrôle. Il faut un faible
couplage;
3. Compréhensibilité: pour modifier un composant dans une conception, il faut comprendre
l’opération effectuée par ce composant;
4. Adaptabilité: si une conception est maintenable a, alors elle est facilement adaptable. Il
faut que les composants soient faiblement couplés, la conception doit être bien
documentée et la documentation doit être facilement compréhensible et consistante avec
l’implémentation et cette dernière doit être écrite de manière lisible;
5. Implémentation: écrire le code du logiciel. La conception détaillée est traduite dans un
langage de programmation dans cette phase;
6. Tests: essayer le logiciel sur des données d’exemple pour s’assurer qu’il fonctionne
correctement par les développeurs et par le client. Il existe des tests unitaires, et des test
d’intégration;
7. Livraison: fournir au client une solution logicielle qui fonctionne correctement (installation,
formation et assistance)
8. Maintenance: mettre à jour et améliorer le logiciel pour assurer sa pérennité
1. Corrective: une maintenance qui corrige les erreurs et les défauts d’utilisabilité, de
fiabilité…identifie aussi les défaillances et les dysfonctionnements;
2. Adaptative: pour adapter le logiciel à une un nouvel environnement. C’est par exemple
le changement de SGBD, de machine…;
3. Perfective et d’extension: pour répondre à des nouveaux besoins…

2.3. Modèles de cycle de vie d’un logiciel

2.3.1. Le modèle séquentiel linéaire (en cascade)
C’est la première modélisation d’une suite de taches standard. Le projet est découpé en phases
successives dans le temps et à chaque phase correspond une activité principale bien précise
produisant un certain nombre de livrables et on ne passe à l’étape suivante que si les résultats de
l’étape précédente sont jugés satisfaisants. L’élaboration des spécifications est une phase
particulièrement critique, les erreurs de spécifications sont généralement détectées au moment des
tests, voire au moment de la livraison du logiciel à l’utilisateur. Leur correction nécessite alors de
reprendre toutes les phases du processus.
Les interactions ont lieu seulement entre étapes successives: on s’autorise des retours en arrière
uniquement sur l’étape précédente.
Ce modèle est mieux adapté aux petits projets ou ceux dont les spécifications sont bien connues et
fixes.
Il existe plusieurs versions de ce modèle, qui ne comprennent pas les mêmes étapes spécifiques du
développement, mais qui les regroupent en phases différemment. Vous remarquerez que dans la
version présentée, les activités de faisabilité et de planification du projet sont comprises dans la phase
d’analyse et de spécification des besoins.

Dr. Ouarda ZEDADRA 3

3ISIL Chapitre 1 : Introduction au GL/ concepts de base de l’OO et Modélisation avec UML GL

2.3.2. Le modèle en V
Ce modèle précise la conception des tests:
– Les tests système sont préparés à partir de la spécification;
– Les tests d’intégration sont préparés à partir de la conception architecturale;
– Les tests unitaires sont préparés à partir de la conception détaillée des composants.
Il est souvent adapté aux projets de taille et de complexité moyenne. Sa première branche correspond
à un modèle en cascade classique. La seconde branche correspond à des tests effectifs effectués sur
des composants réalisés.

2.3.3. Le modèle par prototypage

Des fois il est difficile de dégager correctement les besoins, surtout lorsque l’on connait peu le
domaine. Dans ce cas, on ne peut pas espérer de manière réaliste définir les besoins de manière
définitive avant le début du développement du logiciel.
Lorsqu’il est difficile d’établir une spécification détaillée, on a recours au prototypage. Il s’agit d’écrire
une première spécification et de réaliser un sous-ensemble du produit logiciel final. Ce sous ensemble
est alors raffiné incrémentalement et évalué jusqu’à obtenir le produit final.
Ce modèle consiste à produire une version d’essai du logiciel (prototype), utilisé pour tester les
différents concepts et exigences. Il sert à montrer aux clients les fonctionnements que l’on se propose
de mettre en œuvre. Après que le client donne son accord, le développement du logiciel suit
généralement les phases du modèle en cascade. Les efforts consacrés à la réalisation du prototype
sont le plus souvent compensés par ceux gagnés à ne pas développer de fonctions inutiles.
Il existe deux types de prototypage:
– Jetable: le squelette est créé dans un but et dans une phase particulière du développement;
– Évolutif: on conserve tout, au long du cycle de développement. Il est amélioré et complété
pour obtenir le logiciel final;

Dr. Ouarda ZEDADRA 4

3ISIL Chapitre 1 : Introduction au GL/ concepts de base de l’OO et Modélisation avec UML GL

2.3.4. Le modèle incrémental (par incrément)

Son principe c’est de concevoir et de livrer au client un sous ensemble minimal du système
global qui soit fonctionnel (incrément: consiste en un petit nombre de fonctionnalités). Le
processus se répète durant l’ensemble du cycle de vie par l’ajout d’incréments minimaux.
Dans un premier temps, un logiciel noyau est développé, puis successivement, les incréments
sont développés et intégrés. Chaque incrément est développé selon l’un des modèles
précédents, et les intégrations sont progressives et il peut y avoir des livraisons et des mises
en services après chaque intégration d’incrément.
Ce modèle présente l’avantage de fournir rapidement au client un système utilisable. Chaque
développement est moins complexe.

3. Les méthodes d’analyse et de conception

3.1. A quoi sert une méthode

Une méthode définit une démarche reproductible qui fournit des résultats fiables. Elle permet de
construire des modèles à partir d’éléments de modélisation qui constituent des concepts
fondamentaux pour la représentation de système ou de phénomènes.
Les méthodes définissent également une représentation, souvent graphique, elle définit des règles de
mise en œuvre qui décrivent l’articulation des différents points de vue, l’enchainement des actions,
l’ordonnancement des tâches et la répartition des responsabilités. Une méthode d’élaboration de
logiciels décrit comment modéliser et construire des systèmes logiciels de manière fiable et
reproductible.

3.2. Un modèle ?
Un modèle est une représentation abstraite et simplifiée, d’une entité (phénomène, processus,
système, etc.) du monde réel en vue de le décrire, de l’expliquer ou de le prévoir.
Concrètement, un modèle permet de réduire la complexité d’un phénomène en éliminant les détails
qui n’influencent pas son comportement de manière significative. Il reflète ce que le concepteur croit
important pour la compréhension et la prédiction du phénomène modélisé.
Voici quelques exemples de modèles :
Modèle météorologique – à partir de données d’observation (satellite, …), il permet de prévoir les
conditions climatiques pour les jours à venir.
Plans – Les plans sont des modèles qui donnent une vue d’ensemble du système concerné.

3.3. Pourquoi modéliser (modélisation)?

Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement du
système. Le modèle est indispensable pour assurer un bon niveau de qualité et une maintenance
efficace. En effet, une fois mise en production, l’application va devoir être maintenue, probablement
par une autre équipe et, qui plus est, pas nécessairement de la même société que celle ayant créée
l’application.
La modélisation n’est pas un problème à solution unique. Bien souvent le même problème analysé par
des personnes différentes conduit à des modèles différents. Ces variations correspondent
généralement à des points de vue distincts et seul une confrontation de ces points de vue permet une

Dr. Ouarda ZEDADRA 5

3ISIL Chapitre 1 : Introduction au GL/ concepts de base de l’OO et Modélisation avec UML GL

convergence (ou une acceptation) de ces modèles. Il n’y a pas de bons ou de mauvais modèles, il y a en
revanche, des modèles plus élégants que d’autres, des solutions plus générales ou adaptables que
d’autres.

3.4. Méthodes d’analyse et de conception

Les méthodes d’analyse et de conception fournissent une méthodologie et des notations standards qui
aident à concevoir des logiciels de qualité. Il existe différentes manières pour classer ces méthodes,
dont :
 La distinction entre composition et décomposition : Elle met en opposition d’une part les méthodes
ascendantes qui consistent à construire un logiciel par composition à partir de modules existants
et, d’autre part, les méthodes descendantes qui décomposent récursivement le système jusqu’à
arriver à des modules programmables simplement.

 La distinction entre fonctionnel (dirigée par le traitement) et orientée objet : Dans la stratégie
fonctionnelle (structurée) un système est vu comme un ensemble hiérarchique d’unités en
interaction, ayant chacune une fonction clairement définie. Les stratégies orientées objet
considèrent qu’un système est un ensemble d’objets interagissant. Chaque objet dispose d’un
ensemble d’attributs décrivant son état et l’état du système est décrit (de façon décentralisée) par
l’état de l’ensemble.

3.4.1. Méthodes fonctionnelles ou structurées

Les méthodes fonctionnelles (structurées) trouvent leur origine dans les langages procéduraux.
Elles mettent en évidence les fonctions à assurer et proposent une approche hiérarchique
descendante et modulaire. Ces méthodes utilisent intensivement les raffinements successifs
pour produire des spécifications dont l’essentiel est sous forme de notation graphique en
diagrammes de flots de données. Le plus haut niveau représente l’ensemble du problème (sous
forme d’activité, de données ou de processus, selon la méthode). Chaque niveau est ensuite
décomposé en respectant les entrées/sorties du niveau supérieur. La décomposition se poursuit
jusqu’à arriver à des composants maîtrisables. L’approche fonctionnelle dissocie le problème de
la représentation des données, du problème du traitement de ces données.

En résumé, l’architecture du système est dictée par la réponse au problème (la fonction du
système).

3.4.2. Méthodes orientée objet

L’approche orientée objet considère le logiciel comme une collection d’objets dissociés,
identifiés et possédant des caractéristiques. Une caractéristique est soit un attribut, soit une
entité comportementale de l’objet (fonction). La fonctionnalité du logiciel émerge alors de
l’interaction entre les différents objets qui le constituent. L’une des particularités de cette
approche est qu’elle rapproche les données et leurs traitements associés au sein d’un unique
objet. 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, personne, …)
ou bien virtuelle (client, temps, …). La Conception Orientée Objet (COO) est la méthode qui
conduit à des architectures logicielles fondées sur les objets du système, plutôt que sur la
fonction qu’il est censé réaliser.

En résumé, l’architecture du système est dictée par la structure du problème.

Dr. Ouarda ZEDADRA 6

3ISIL Chapitre 1 : Introduction au GL/ concepts de base de l’OO et Modélisation avec UML GL

4. Concepts importants de l’approche par objets

La modélisation orienté objet repose sur un ensemble de concepts tirant leur origine du monde des
mathématiques entre autres les algèbres et les ensembles. UML est un langage de modélisation
graphique mettant en œuvre les principes de la modélisation par objet dont nous allons décrire les
fondements dans cette section :
1) Abstraction : c’est la représentation des caractéristiques essentielles d’un objet en omettant les
détails non essentiels. L’abstraction peut concerner aussi bien des phénomènes concrets
qu’abstraits. Au fait, l’abstraction est une technique que nous utilisons couramment pour décrire
les phénomènes de la vie courante.
Exemple :
 Une carte géographique est une abstraction d’un territoire ou d’une zone.
 Un tableau de peinture représente une abstraction faite par le peintre sur un sujet ou un
thème.
2) Objet : l’objet est une unité atomique formée de l’union d’un état et d’un comportement. Chaque
objet possède des propriétés (attributs) qui décrivent son état, et des opérations qui décrivent
son comportement (tout aspect dynamique ou fonctionnel d’un objet).
Notation graphique:
Nom de l’objet
Attributs de l’objet
Opérations de l’objet
Exemple: voici une représentation de l’objet employé « AZIZ» habitant « ALGER », recruté le
23/02/2006 et ayant le profil « Ingénieur d’état ». Le profil de l’employé évolue durant sa carrière
(promotions, rétrogradations,…) et on lui comptabilise ses absences. Ces deux caractéristiques sont
prises en charge par les opérations « modifier le profil de l’employé » et « calculer le nombre
d’absences ».
EMPLOYE AZIZ
Nom de l’employé: AZIZ
Adresse : ALGER
Date de Recrutement : 23/02/2006
Grade Actuel : Ingénieur d’état
Modifier le profil de l’employé (…)
Calculer le nombre d’absences (…)
3) Encapsulation : dans les méthodes systémiques (Merise), les données sont séparées des
traitements. Ceci implique que tout changement dans la structure d’une donnée doit être effectué
au niveau de tous les programmes l’utilisant. Cette duplication des données est évitée dans
l’approche objet grâce au concept d’encapsulation. Cette propriété fait que tout objet renferme en
son sein ses attributs et opérations. Ces derniers sont cachés aux autres objets du système. Tout
accès à un service offert par un objet (attribut ou opération) ne peut se faire que par le biais
d’envoi de message qui va déclencher l’exécution d’une opération.
4) Communication entre objets : les objets communiquent entre eux par envoi de message. Un
message présente l’appel d’une opération d’un objet destination par un objet source.
Message ()
Notation graphique: Objet1 Objet2

Exemple: une demande du prix d’une formation représenté par un message demanderprix () entre
l’objet Ahmed et l’objet Formation Bureautique.
DemanderPrix ()
Aziz : Employé Bureautique : Formation

Dr. Ouarda ZEDADRA 7

3ISIL Chapitre 1 : Introduction au GL/ concepts de base de l’OO et Modélisation avec UML GL

5) Classification : lorsque le système comporte un ensemble d’objets partageant les mêmes

caractéristiques et le même comportement, ces derniers sont regroupés sous un même type ou
classe. On dit que chaque objet est une réalisation ou instanciation de la classe.
Notation graphique:
Nom de la classe
Liste de ses Attributs
Liste de ses Opérations
Exemple: l’exemple suivant décrit la classe d’objets EMPLOYE cite dans les exemples précédents:
EMPLOYE
Nom de l’employé
Adresse
Date de Recrutement
Grade Actuel
Modifier le profil de l’employé (…)
Calculer le nombre d’absences (…)
6) Association : c’est un lien statique entre plusieurs objets (classes). Les liens peuvent être étiquetés
par des verbes ou expressions permettant d’en saisir le sens. Il est possible aussi d’exprimer les
cardinalités sur le lien d’association. La cardinalité minimale est comprise entre 0 et 1 et la
cardinalité maximale allant de 1 à * (* représente un nombre entier >=1).
Exemple: un employé est affecté à un seul service mais un service peut accueillir plusieurs
employés à la fois. Est Affecté
Employé Service
à 1

7) Agrégation : c’est un cas particulier d’association où un tout est relié à ses parties. Elle exprime un
couplage plus fort entre classes. Le tout (la classe du côté du losange) est appelé agrégat et la
classe en opposé est appelé agrégée.
Notation graphique: Classe 1 Classe 2

8) Composition : lorsque le lien d’agrégation est fort, c'est-à-dire que la suppression de l’objet agrégat
mène à la suppression des objets agrégés, on parle alors de composition.
Notation graphique: Classe 1 Classe 2

9) Héritage : L’héritage est mis en œuvre grâce à deux propriétés qui sont : la généralisation et la
spécialisation. La généralisation décrit le fait de pouvoir regrouper un ensemble de classes
partageant des éléments en commun en une seule superclasse (classe mère). Tandis que la
spécialisation représente le phénomène inverse, c'est-à-dire pouvoir dériver à partir d’une classe
ou superclasse des sous classes (classe fille) ayant des propriétés spécifiques les distinguant les
unes des autres.
Notation graphique: Classe Mère Généralisation

Classe Fille 1 Classe Fille 2 Spécialisation

10) Polymorphisme: c’est le fait d’utiliser la même expression pour dénoter différentes opérations.
En effet, une même opération peut être définie pour plusieurs classes. Ceci ne signifie pas que
cette opération est implémentée exactement de la même manière. Au contraire, on peut lui
associer, selon la classe à laquelle elle appartient une méthode différente. Ainsi, un même message
vers une opération donnée peut produire des résultats différents selon la classe invoquée.

Dr. Ouarda ZEDADRA 8

3ISIL Chapitre 1 : Introduction au GL/ concepts de base de l’OO et Modélisation avec UML GL

5. Modélisation avec UML (Unified Modeling Language)

5.1. Définition
UML est une notation graphique conçue pour représenter, spécifier, construire et documenter les
systèmes logiciels. UML permet de construire plusieurs modèles d’un système, chacun mettant en
valeur des aspects différents: fonctionnels, statiques, dynamiques et organisationnels.
UML est la forme contractée d’Unified Modeling Language, qui peut se traduire en français par langage
unifié pour la modélisation. En tant que tel, facilite l’expression et la communication de modèles en
fournissant un ensemble de symboles (notation) et de règles qui régissent l’assemblage de ces
symboles (la syntaxe et la sémantique).
UML permet de modéliser de manière claire et précise la structure et le comportement d’un système
indépendamment de toute méthode ou de tout langage de programmation. Les créateurs d’UML
insistent tout particulièrement sur le fait qu’UML est un langage de modélisation et non une méthode.
Plusieurs processus de développement complets fondés sur UML existent, comme le Rational Unified
Process (RUP), de Booch, Jacobson et Rumbaugh, ou l’approche MDA (Model Driven Architecture).

5.2. Un bref historique

La technologie orienté objet est issue du monde de la programmation pour répondre à des besoins
dans l’industrie du logiciel tel que la rapidité du développement, la réutilisation et la modularité. Ainsi
des langages tels que SMALTALK, C++, ADA ont eu du succès dans ce domaine.
Dès lors, aux années 80 on commença à réfléchir à des langages de modélisation ou conception
graphique. Parmi ces méthodes on peut citer :
1) GRADY BOOCH : méthode OOAD « Object Oriented Analysis and Design » en français « Analyse
et modélisation orienté objet ».
2) PETER HOOD : méthode OOD « Object Oriented Design » en français « Modélisation Orienté
Objet ».
3) IVAR JACOBSON : Méthode OOSE « Oriented Object Software Engineering » en français « Génie
Logiciel Orienté Objet ».
4) JAMES RUMBAUGH : Méthode OMT « Object Modeling Technic » en français « Techniques de
Modélisation Objet ».
Événement considérable et presque miraculeux, les trois gourous qui régnaient chacun sur l’une des
trois méthodes se mirent d’accord pour définir une méthode commune qui fédérerait leurs apports
respectifs. UML (Unified Modeling Language) est né de cet effort de convergence. En fait, et comme
son nom l’indique, UML n’a pas l’ambition d’être exactement une méthode : c’est un langage.
L’unification a progressé par étapes. Cette progression des versions d’UML peut être récapitulée dans
le tableau suivant :
OMG : Object Management Group, est une organisation fondée en 1989. Son but est de mettre au point des
standards garantissant la compatibilité entre applications programmées en orienté objet et fonctionnant sous
réseaux hétérogènes.
Années Versions
1995 Méthode unifiée UML 0.8 (intégrant la méthode de Booch) puis UML 0.9 (intégrant les
méthodes OOSE et OMT)
1996 UML 1.0 proposé à l’OMG.
1997 UML 1.0 standardisé par l’OMG.
1998 UML 1.2
1999 UML 1.3
2000 UML 1.4
2004 UML 2.0
Dr. Ouarda ZEDADRA 9
3ISIL Chapitre 1 : Introduction au GL/ concepts de base de l’OO et Modélisation avec UML GL

5.3. Présentation générale des diagrammes UML

Les utilisateurs regardent et manipulent les modèles au moyen de vues graphiques, véritables
projections au travers des éléments de modélisation contenus dans un ou plusieurs modèles. UML
permet d’exprimer les modèles objets à travers un ensemble de diagrammes. Ces derniers sont des
moyens de description des objets ainsi que des liens qui les relient. Un diagramme est une
représentation graphique qui s’intéresse à un aspect précis du modèle. UML offre 9 types de
diagrammes (cinq pour des vues statiques et quatre pour des vues dynamiques). Chaque type de
diagramme offre une vue d’un système. Combinés, les différents types de diagrammes offrent une vue
complète du système.

5.3.1. Les diagrammes fonctionnels

Cherche à appréhender les interactions entre les différents acteurs/utilisateurs et le système, sous
forme d’objectif à atteindre d’un côté et sous forme chronologique de scénarios d’interaction typiques
de l’autre. Le digramme de cas d’utilisation représente une vue fonctionnelle du système à modéliser.
1. Les diagrammes de cas d’utilisation : les cases d’utilisation constituent une technique qui
permet de déterminer les besoins d’utilisateurs et de capturer les exigences fonctionnelles d’un
système. En d’autres termes, ils décrivent le comportement d’un système du point de vue de
ses utilisateurs. Les diagrammes de cas d’utilisation permettent de représenter graphiquement
les cas d’utilisation.

5.3.2. Les diagrammes de structure ou statique

Les diagrammes de structure décrivent l’aspect statique du système. Ils permettent de représenter les
éléments d’analyse : classes et objets ainsi que les composants, les structures composites, les
déploiements et les package. Dans ces diagrammes, on ne s’intéresse pas aux interactions entre les
éléments représentés, mais plutôt à leurs relations statiques. Ils sont au nombre de six :
1. Les diagrammes de classes : ils décrivent les types des objets qui composent un système et les
différents types de relations statiques qui existent entre eux. Ils font l’abstraction du
comportement du système.
2. Les diagrammes d’objets : représente un instantané des objets d’un système à un moment
donné. Ces diagrammes sont souvent appelés diagrammes d’instance car ils représentent des
instances et non pas des classes.
3. Les diagrammes de composants : ils décrivent l’architecture interne d’une classe. Ils sont très
utilisés pour représenter l’architecture physique et statique d’une application.
4. Les diagrammes de déploiement : représentent l’agencement physique d’un système montrant
sur quels composants matériels les différents composants logiciels s’exécutent.
5.3.3. Les diagrammes de comportement (dynamique)
Permettent de représenter le comportement des objets grâce aux diagrammes de machine d’état et les
diagrammes d’activité et les interactions entre les objets grâce aux diagrammes de séquence, de
communication, de vue d’ensemble des interactions et des diagrammes de timing:
1. Les diagrammes d’activité : décrivent le comportement d’une méthode, le déroulement d’un cas
d’utilisation, les enchainements d’activités (une activité désigne une suite d’actions).

Dr. Ouarda ZEDADRA 10

3ISIL Chapitre 1 : Introduction au GL/ concepts de base de l’OO et Modélisation avec UML GL

2. Les diagrammes de machine d’état : appelé aussi diagramme d’état transition, il permet de
décrire les changements d’état d’un objet, en réponse aux interactions avec d’autres objets
ou acteurs.
3. Les diagrammes de séquence : permettent de représenter les interactions entre objets selon un
point de vue temporel. L’accent est mis sur la chronologie des envois de messages.
4. Les diagrammes de communication (collaboration) : décrivent l’interaction en mettant l’accent
sur les liaisons des données entre les différents participants à l’interaction.

Dr. Ouarda ZEDADRA 11