.

Cadre d’utilisation d’UML

UML est un langage qui permet de représenter des modèles, mais il ne définit pas le processus
d'élaboration des modèles. UML n'est ni une méthode, ni un processus. Qualifier UML de
"méthode objet" n'est donc pas tout à fait approprié. Une méthode propose aussi un processus,
qui régit notamment l'enchaînement des activités de production d'une entreprise. Or UML n'a
pas été pensé pour régir les activités de l'entreprise. Un processus est adapté (donc très lié) au
domaine d'activité de l'entreprise ; même s'il constitue un cadre général, il faut l'adapter au
contexte de l'entreprise.
UML permet de modéliser des applications selon une vision objet. Son appréhension
est complexe car UML est à la fois :
• une norme,
• un langage de modélisation objet,
• un support de communication,
• un cadre méthodologique.

2.1. UML est une norme

UML est non seulement un outil intéressant mais aussi une norme qui s’impose en
technologie à objets et à laquelle se sont rangés tous les grands acteurs du domaine ; acteurs
qui ont d’ailleurs contribué à son élaboration. En effet en Novembre 1997, UML est devenu
une norme OMG (Object Management Group). Aujourd'hui, l'OMG fédère plus de 850
acteurs du monde informatique. Son rôle est de promouvoir des standards qui garantissent
l'interopérabilité entre applications orientées objet, développées sur des réseaux hétérogènes.
2.2. UML est un langage de modélisation objet
UML est un langage formel, défini par un métamodèle. Un métamodèle permet de
limiter les ambiguïtés et encourage la construction d'outils. Il permet aussi de classer les
différents concepts du langage (selon leur niveau d'abstraction ou leur domaine d'application)
et expose ainsi clairement sa structure. Le métamodèle d'UML décrit de manière très précise
tous les éléments de modélisation et la sémantique de ces éléments. En d'autres termes : UML
normalise les concepts objet. UML est donc un outil indispensable pour tous ceux qui ont
compris que programmer objet, c'est d'abord concevoir objet. UML n'est pas à l'origine des
concepts objets, mais il en constitue une étape majeure, car il unifie les différentes approches
et en donne une définition plus formelle.
 IAI
Cours Langage de Modélisation Unifié UML

2.3. UML est un support de communication

UML est avant tout un support de communication performant, qui facilite la
représentation et la compréhension de solutions objet. Sa notation graphique permet
d'exprimer visuellement une solution objet, ce qui facilite la comparaison et l'évaluation de
solutions. L'aspect formel de sa notation limite les ambiguïtés et les incompréhensions. Son
indépendance par rapport aux langages de programmation, aux domaines d'application et aux
processus, en font un langage universel.

2.4. UML est un cadre méthodologique

Une caractéristique importante d'UML, est qu'il cadre l'analyse. UML permet de
représenter un système selon différentes vues complémentaires : les 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. Chaque type de diagramme UML possède une
structure (les types des éléments de modélisation qui le composent sont prédéfinis) et véhicule
une sémantique précise (il 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. Les diagrammes permettent donc d'inspecter un modèle selon différentes
perspectives et guident l'utilisation des éléments de modélisation (les concepts objet), car ils
possèdent une structure.

Une autre caractéristique importante des diagrammes UML, est qu'ils supportent
l'abstraction. Cela permet de mieux contrôler la complexité dans l'expression et l'élaboration
des solutions objet.
3. Les points forts d’UML
o UML est un langage formel et normalisé. En effet :
 Avec UML comme langage de modélisation ; on a un gain de
précision ;
 UML est un gage de stabilité ;
 UML encourage l'utilisation d'outils.
 UML est un support de communication performant. En effet :
 Il cadre l'analyse
 Il facilite la compréhension de représentations abstraites
complexes
 Son caractère polyvalent et sa souplesse en font un langage
universel

Proposé par Mme. ANGA Orcelie Page 1

 IAI
Cours Langage de Modélisation Unifié UML

4. Les points faibles d’UML

o La mise en pratique d'UML nécessite un apprentissage et passe par une période
d'adaptation. En effet même si la nécessité de s'accorder sur des modes d'expression communs
est vitale en informatique ; UML n 'est pas à l'origine des concepts objets, mais en constitue
une étape majeure, car il unifie les différentes approches et en donne une définition plus
formelle.
o Le processus (non couvert par UML) est une autre clé de la réussite d'un projet.
Or, l'intégration d'UML dans un processus n'est pas triviale et améliorer un processus est une
tâche complexe et longue. Les auteurs d'UML sont tout à fait conscients de l'importance du
processus, mais l'acceptabilité industrielle de la modélisation objet passe d'abord par la
disponibilité d'un langage d'analyse objet performant et standard.

II. Rappels sur des notions liées à l’approche objet

Aujourd’hui l’approche objet occupe une place prépondérante dans le génie logiciel.
Cette approche 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 (i.e. une donnée
caractérisant l’état de l’objet), soit une entité comportementale de l’objet (i.e. une 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.
Comme nous venons de le dire, un objet est caractérisé par plusieurs notions :
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 (par exemple un produit pourra être repéré par un code,
une voiture par un numéro de série, etc.)
Les attributs – Il s’agit des données caractérisant l’objet. Ce sont des variables stockant des
informations sur l’état de l’objet.
Les méthodes – Les méthodes d’un objet caractérisent son comportement, c’est-à-dire
l’ensemble des actions (appelées opérations) que l’objet est à même de réaliser. Ces
opérations permettent de faire réagir l’objet aux sollicitations extérieures (ou d’agir sur les
autres objets). De plus, les opérations sont étroitement liées aux attributs, car leurs actions
peuvent dépendre des valeurs des attributs, ou bien les modifier.

Proposé par Mme. ANGA Orcelie Page 2

 IAI
Cours Langage de Modélisation Unifié UML

1. Concepts importants de l’approche objet

Nous avons dit que l’approche objet rapproche les données et leurs traitements. Mais
cette approche ne fait pas que ça, d’autres concepts importants sont spécifiques à cette
approche orientée objet et participent à la qualité du logiciel. Classe et Objet
Une classe est un type de données abstrait qui précise des caractéristiques (attributs et
méthodes) communes à toute une famille d’objets et qui permet de créer (instancier) des
objets possédant ces caractéristiques. On parle de caractéristiques ou de propriétés de classes.
Un objet est une instance de classe (une occurrence d'un type abstrait). Encapsulation
L’encapsulation consiste à masquer les détails d’implémentation d’un objet, en définissant
une interface. (L’interface est la vue externe d’un objet, elle définit les services accessibles
(offerts) aux utilisateurs de l’objet). L’encapsulation facilite l’évolution d’une application car
elle stabilise l’utilisation des objets : on peut modifier l’implémentation des attributs d’un
objet sans modifier son interface, et donc la façon dont l’objet est utilisé. L’encapsulation
garantit l’intégrité des données, car elle permet d’interdire, ou de restreindre, l’accès direct
aux attributs des objets.
Héritage (Spécialisation et Généralisation)
L’héritage est un mécanisme de transmission des caractéristiques d’une classe (ses attributs et
méthodes) appelée classe mère ou superclasse vers une autre classe appelée classe fille ou
sous-classe. Une classe peut être spécialisée en d’autres classes, afin d’y ajouter des
caractéristiques spécifiques ou d’en adapter certaines. Plusieurs classes peuvent être
généralisées en une classe qui les factorise, afin de regrouper les caractéristiques communes
d’un ensemble de classes.
Ainsi, la spécialisation et la généralisation permettent de construire des hiérarchies de classes.
L’héritage évite la duplication et encourage la réutilisation. L’héritage peut être simple ou
multiple.
Polymorphisme
Le polymorphisme représente la faculté d’une méthode à pouvoir s’appliquer à des objets de
classes différentes. C’est-à-dire la faculté d'une même opération (méthode) de s'exécuter
différemment suivant le contexte de la classe où elle se trouve.

Ainsi, une opération définie dans une superclasse peut s'exécuter de façon différente selon la
sous-classe où elle est héritée. Le polymorphisme augmente la généricité, et donc la qualité,
du code.

Agrégation et Composition

Proposé par Mme. ANGA Orcelie Page 3

 IAI
Cours Langage de Modélisation Unifié UML

Il s’agit d’une relation entre deux classes, spécifiant que les objets d’une classe sont des
composants de l’autre classe. Une relation d’agrégation permet donc de définir des objets
composés d’autres objets. L’agrégation permet donc d’assembler des objets de base, afin de
construire des objets plus complexes. Une composition est une agrégation forte.

2. Limites de l’approche objet o L'approche objet est moins intuitive que

l'approche fonctionnelle ! En effet, pour appliquer l’approche orientée objet, il faut pouvoir
répondre aux questions suivantes :
 Quels moyens utiliser pour faciliter l'analyse objet ?
 Quels critères identifient une conception objet pertinente ?  Comment
comparer deux solutions de découpe objet d'un système ?
o L'application des concepts objets nécessite une grande rigueur ! Avec l’approche objet, le
vocabulaire doit être est précis (risques d'ambiguïtés, d'incompréhensions). Ici, il faut
pouvoir répondre à la question suivante :
 Comment décrire la structure objet d'un système de manière pertinente?

3. Solutions pour remédier aux inconvénients de l’approche objet

Pour remédier aux inconvénients ci haut cités, il faut bénéficier d’un langage pour exprimer les
concepts objet qu'on utilise, afin de pouvoir :
 Représenter des concepts abstraits (graphiquement par exemple) ;

Proposé par Mme. ANGA Orcelie Page 4

 IAI
Cours Langage de Modélisation Unifié UML

 Limiter les ambiguïtés (parler un langage commun) ;

 Faciliter l'analyse (simplifier la comparaison et l'évaluation de solutions).
Il faut également une démarche d'analyse et de conception objet, pour :
 Ne pas effectuer une analyse fonctionnelle et se contenter d’une
implémentation objet, mais penser objet dès le départ ;
 Définir les vues qui permettent de couvrir tous les aspects d'un système,
avec des concepts objets.

1. Caractéristiques fondamentales des modèles

Le caractère abstrait d'un modèle doit notamment permettre :

 de faciliter la compréhension du système étudié : un modèle réduit la
complexité du système étudié.
 de simuler le système étudié : un modèle représente le système étudié et
reproduit ses comportements.

I. Comment modéliser avec UML ?

UML se décompose en plusieurs parties :

• Les vues : ce sont les observables du système. Elles décrivent le système d'un point
de vue donné, qui peut être organisationnel, dynamique, temporel, architectural,
géographique, logique, etc. En combinant toutes ces vues, il est possible de définir
(ou retrouver) le système complet.
• Les diagrammes : ce sont des ensembles d'éléments graphiques qui décrivent le
contenu des vues et qui sont des notions abstraites. Ils peuvent faire partie de
plusieurs vues.
• Les modèles d'élément : ce sont les éléments graphiques des diagrammes.

1. Proposition de la démarche
UML est un langage qui permet de représenter des modèles, mais il ne définit pas le
processus d'élaboration des modèles : UML n’est donc pas une méthode de modélisation.
Cependant, dans le cadre de la modélisation d'une application informatique, les auteurs
d'UML préconisent d'utiliser une démarche :
• itérative et incrémentale,
• guidée par les besoins des utilisateurs du système,

Proposé par Mme. ANGA Orcelie Page

 IAI
Cours Langage de Modélisation Unifié UML

• centrée sur l'architecture logicielle.

D'après les auteurs d'UML, un processus de développement qui possède ces qualités
devrait favoriser la réussite d'un projet.

1.1. Une démarche itérative et incrémentale

Pour modéliser (comprendre et représenter) un système complexe, il vaut mieux s'y

prendre en plusieurs fois, en affinant son analyse par étapes. Cette démarche doit aussi
s'appliquer au cycle de développement dans son ensemble, en favorisant le prototypage. Le
but est de mieux maîtriser la part d'inconnu et d'incertitudes qui caractérisent les systèmes
complexes.

1.2. Une démarche pilotée par les besoins des utilisateurs

Avec UML, ce sont les utilisateurs qui guident la définition des modèles : Le périmètre du
système à modéliser est défini par les besoins des utilisateurs (les utilisateurs définissent ce
que doit être le système). Le but du système à modéliser est de répondre aux besoins de ses
utilisateurs (les utilisateurs sont les clients du système).
Les besoins des utilisateurs servent aussi de fil rouge, tout au long du cycle de
développement (itératif et incrémental) :
• à chaque itération de la phase d'analyse, on clarifie, affine et valide les
besoins des utilisateurs.
• à chaque itération de la phase de conception et de réalisation, on veille à la
prise en compte des besoins des utilisateurs.
• à chaque itération de la phase de test, on vérifie que les besoins des
utilisateurs sont satisfaits.

1.3. Une démarche centrée sur l'architecture

Une architecture adaptée est la clé de voûte du succès d'un développement.

Elle décrit des choix stratégiques qui déterminent en grande partie les qualités du logiciel
(adaptabilité, performances, fiabilité...).

2. Les différentes vues d’UML

Proposé par Mme. ANGA Orcelie Page

 IAI
Cours Langage de Modélisation Unifié UML

Les vues sont des observables du système. Elles décrivent le système d’un point de
vue donné qui peut être organisationnelle, dynamique, temporelle, architecturelle,
géographique…
Ph. Kruchten propose différentes perspectives (vues), indépendantes et complémentaires,
qui permettent de définir un modèle d'architecture (publication IEEE, 1995). Ph. Kruchten
défend l’idée que l’architecture logicielle doit être une discipline à part entière. Il propose
que plusieurs perspectives concourent à l’expression de l’architecture d’un système et il
explique qu’il est nécessaire de garantir la séparation et l’indépendance de ces différentes
perspectives. L’évolution de l’une des perspectives ne doit pas avoir d’impact (sinon
limité) sur les autres.
La relation entre les différentes perspectives a été représentée par ph. Kruchten dans le
schéma suivant, dit « schéma 4+1 vues ».

En combinant ces vues, il est possible de définir le système complet. Ces vues
sont :

2.1. La vue logique

Cette vue concerne « l’intégrité de conception ». Cette vue de haut niveau se concentre sur
l'abstraction et l'encapsulation, elle modélise les éléments et mécanismes principaux du
système. Elle identifie les éléments du domaine, ainsi que les relations et interactions entre
ces éléments « notions de classes et de relations » :

• les éléments du domaine sont liés au(x) métier(s) de l'entreprise,

• ils sont indispensables à la mission du système,

• ils gagnent à être réutilisés (ils représentent un savoir-faire).

Cette vue organise aussi (selon des critères purement logiques), les éléments du domaine
en "catégories" :

Proposé par Mme. ANGA Orcelie Page

 IAI
Cours Langage de Modélisation Unifié UML

• pour répartir les tâches dans les équipes,

• regrouper ce qui peut être générique,

• isoler ce qui est propre à une version donnée, etc...

2.2. La vue des composants ou vue d’implémentation

Cette vue concerne « l’intégrité de gestion ». Elle exprime la perspective physique de
l’organisation du code en termes de modules, de composants et surtout des concepts du
langage ou de l’environnement d’implémentation. Dans cette perspective, l’architecte est
surtout concerné par les aspects de gestion du code, d’ordre de compilation, de
réutilisation, d’intégration et d’autres contraintes de développement pur. Pour représenter
cette perspective, UML fournit des concepts adaptés tels que les modules, les composants,
les relations de dépendance, l’interface …
Cette vue de bas niveau (aussi appelée « vue de réalisation »), montre ainsi :

• l'allocation des éléments de modélisation dans des modules (fichiers sources,

bibliothèques dynamiques, bases de données, exécutables, etc...). Cette vue
identifie les modules qui réalisent (physiquement) les classes de la vue logique.

• l'organisation des composants, c'est-à-dire la distribution du code en gestion de

configuration, les dépendances entre les composants...

• les contraintes de développement (bibliothèques externes...).

• l'organisation des modules en "sous-systèmes", les interfaces des sous-systèmes

et leurs dépendances (avec d'autres sous-systèmes ou modules).

2.3. La vue des processus

Cette vue concerne « l’intégrité d’exécution ». Cette vue est très importante dans les
environnements multitâches ; elle exprime la perspective sur les activités concurrentes et
parallèles. Elle montre ainsi :

• la décomposition du système en termes de processus (tâches).

• les interactions entre les processus (leur communication).

• la synchronisation et la communication des activités parallèles (threads).

2.4. La vue de déploiement

Proposé par Mme. ANGA Orcelie Page

 IAI
Cours Langage de Modélisation Unifié UML

Cette vue concerne « l’intégrité de performance ». Cette vue est très importante dans les
environnements distribués et décrit les ressources matérielles et la répartition du logiciel
dans ces ressources. Elle exprime la répartition du système à travers un réseau de
calculateurs et de nœuds logiques de traitements. Cette vue est particulièrement utile pour
décrire la distribution d’un système réparti. Elle montre :

• la disposition et nature physique des matériels, ainsi que leurs performances.

• l'implantation des modules principaux sur les nœuds du réseau.

• les exigences en termes de performances (temps de réponse, tolérance aux fautes

et pannes...).

2.5. La vue des cas d’utilisation

Cette vue est particulière en ce sens qu’elle guide toutes les autres. Cette vue permet :

• de trouver le « bon » modèle.

Les cas d’utilisation permettent de guider la modélisation. L’utilisation des scénarios et
des cas d’utilisation s’avère plus rigoureuse et plus systématique que les entretiens et
l’analyse des documents pour découvrir les abstractions du domaine.

• d’expliquer et de justifier ses choix.

Il est en effet nécessaire d’expliquer le système, de justifier les choix qui ont guidé sa
conception et son fonctionnement pour pouvoir le construire, le maintenir et le tester. Pour

cela UML offre des concepts adaptés tels que les scénarios et les cas d’utilisation. 3. Les

niveaux d’abstractions

3.1. Conceptualisation
L'entrée de l'analyse à ce niveau est le dossier d'expression des besoins client. A ce
niveau d'abstraction, on doit capturer les besoins principaux des utilisateurs. Il ne faut pas
chercher l'exhaustivité, mais clarifier, filtrer et organiser les besoins.
Le but de la conceptualisation est :
◦ de définir le contour du système à modéliser (de spécifier le "quoi"),
◦ de capturer les fonctionnalités principales du système, afin d'en fournir une
meilleure compréhension (le modèle produit sert d'interface entre les acteurs du
projet), ◦ de fournir une base à la planification du projet.

Proposé par Mme. ANGA Orcelie Page

 IAI
Cours Langage de Modélisation Unifié UML

3.2. Analyse du domaine

L'entrée de l'analyse à ce niveau, est le modèle des besoins clients (les "cas
d'utilisation" UML). Il s'agit de modéliser les éléments et mécanismes principaux du
système. On identifie les éléments du domaine, ainsi que les relations et interactions entre
ces éléments :
◦ les éléments du domaine sont liés au(x) métier(s) de l'entreprise,
◦ ils sont indispensables à la mission du système,
◦ ils gagnent à être réutilisés (ils représentent un savoir-faire).
A ce stade, on organise aussi (selon des critères purement logiques), les éléments du
domaine en "catégories", pour répartir les tâches dans les équipes, regrouper ce qui peut
être générique, etc...
3.3. Analyse applicative
A ce niveau, on modélise les aspects informatiques du système, sans pour autant
rentrer dans les détails d'implémentation. Les interfaces des éléments de modélisation sont
définis (cf. encapsulation). Les relations entre les éléments des modèles sont définies.
Les éléments de modélisation utilisés peuvent être propres à une version du système.

3.4. Conception

Ici, on y modélise tous les rouages d'implémentation et on détaille tous les éléments de
modélisation issue des niveaux supérieurs. Les modèles sont optimisés, car destinés à être
implémentés.

4. Utilisation des 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" car c’est par extension et abus
de langage qu’on traite un diagramme UML d’un modèle (un diagramme modélise un
aspect du modèle global).
Chaque type de diagramme UML possède une structure (les types des
éléments de modélisation qui le composent sont prédéfinis) et véhicule une sémantique
précise.
Combinés, les différents types de diagrammes UML offrent une vue complète des
aspects statiques et dynamiques d'un système.

Proposé par Mme. ANGA Orcelie Page 10

 IAI
Cours Langage de Modélisation Unifié UML

Les diagrammes UML supportent l'abstraction. Leur niveau de détail caractérise le niveau
d'abstraction du modèle. La structure des diagrammes UML et la notation graphique des
éléments de modélisation sont normalisées.

Proposé par Mme. ANGA Orcelie Page 11