Cours Modélisation UML 2

Cycle : BACHELOR
Niveau : 2
Support de cours
Modélisation UML 2
ANNEE ACADEMIQUE 2023-2024

PLANNING DE DEROULEMENT DU COURS
ENSEIGNANT
Nom (s) et prénom (s) : DIFFOUO TAZO Evariste
Grade ou Qualification : Ingénieur Informaticien & Doctorant
Téléphone : (+237) 697 481 969 / (+237) 677 268 237
Courriel : [email protected] / [email protected]
Quotas horaire semestriel prévus : 32 heures

Volume horaire hebdomadaire prévu : 4 heures
Jours hebdomadaires de cours : Vendredi
Période des enseignements : Novembre- Décembre 2023
Objectifs du cours
Ce cours a pour objectif d’initier à la maîtrise des concepts objets ainsi que des diagrammes du langage de modélisation unifié
(UML 2).
À la fin de cet enseignement, l’étudiant doit être capable de :

1. Comprendre les fondamentaux de l'approche objet ;
2. Comprendre les enjeux et les objectifs de la modélisation dans un processus d’automatisation des SI ;
3. Comprendre comment intégrer UML dans un processus de développement et comment modéliser avec UML ;
4. Maitriser les outils qui permettront à un analyste de représenter des systèmes entiers à partir des concepts objets en
utilisant UML : Les processus unifiés et les modèles de développement ;
5. Faire bon usage de tous les diagrammes UML.
CONTENU DE L’ENSEIGNEMENT
CHAPITRE I : Historique du langage de modélisation unifié UML et rappels sur des notions liées à
l’approche objet
CHAPITRE II : Démarche générale de modélisation avec UML
CHAPITRE III : Les différents types de diagrammes UML
CHAPITRE IV : Les processus unifiés et les modèles de développement logiciel (cycle de vie d’un
logiciel)
APPROCHE PEDAGOGIQUE
L’approche pédagogique est conçue pour impliquer l’étudiant dans la construction et l’utilisation des savoirs.
Ce planning transmis à l’étudiant lui permet de préparer chaque séance de cours. Des travaux à faire lui
sont donnés à la fin de chaque séance de cours afin de lui permettre d’assimiler l’unité d’enseignement.
Diverses stratégies sont utilisées dont : l’enseignement magistral interactif, les exercices pratiques, la mé-
thode des cas, l’apprentissage par problèmes, le réseau de concepts etc.
Déroulement des exercices / cas pratiques et Méthode d’évaluation
Hormis les exercices d’application une liste d’exercices est intégrée à l’annexe du cours.
A chaque séance l’étudiant a droit aux exercices / TP à faire en salle, à la maison ou en équipe.
Le(s) contrôle(s) continu(s) et l’examen final comptent chacun pour 50% de la note finale
Le contrôle continu est constitué de :
 La présence et participation en salle ;
 L’évaluation en salle ;
 Travaux à faire à la maison ;
 Les travaux d’équipes.
NB : Les travaux dirigés ou pratiques doivent être remis au début du cours ou envoyés par courrier élec-
tronique.
Cours Modélisation UML 2
Table des matières

Chapitre 1 : ................................................................................................................................................ 6
Historique du langage de modélisation unifié UML et rappels sur des notions
liées à l’approche objet ..................................................................................................................... 6
Introduction ................................................................................................................................................6
I. Les méthodes objets et la genèse du langage de modélisation unifié UML...................................6
1. Historique des méthodes d’analyse ..............................................................................................6
2. Cadre d’utilisation d’UML ...........................................................................................................7
3. Les points forts d’UML points faibles d’UML ............................................................................9
II. Rappels sur des notions liées à l’approche objet ...................................................................... 10
1. Concepts importants de l’approche objet ................................................................................. 10
2. Les limites de l’approche objet .................................................................................................. 11
3. . Solutions pour remédier aux inconvénients de l’approche objet.......................................... 12
Chapitre 2 : .............................................................................................................................................. 13
Démarche générale de modélisation avec UML .................................................................... 13
Introduction ............................................................................................................................................. 13
I. Modélisation objet........................................................................................................................... 13
1. Définition d’un modèle ............................................................................................................... 13
2. Rôle de la modélisation ............................................................................................................... 13
3. Caractéristiques fondamentales des modèles ........................................................................... 14
II. Comment modéliser avec UML ? .............................................................................................. 14
1. Proposition de la démarche ........................................................................................................ 14
2. Les différentes vues d’UML ....................................................................................................... 15
3. Les niveaux d’abstractions ......................................................................................................... 18
4. Utilisation des diagrammes ........................................................................................................ 19
Chapitre 3 : .............................................................................................................................................. 20
Les différents types de diagrammes UML ................................................................................ 20
Introduction ............................................................................................................................................. 20
I. Les vues statiques ............................................................................................................................ 21
1. Diagramme de cas d’utilisation ................................................................................................. 21
2. Diagramme de classe................................................................................................................... 27
3. Diagramme d’objet ..................................................................................................................... 33
4. Diagramme des composants ....................................................................................................... 34
5. Diagramme de déploiement ....................................................................................................... 35
6. Diagramme de paquetage ........................................................................................................... 36
PROPOSE PAR DIFFOUO TAZO EVARISTE 4
7. Diagramme de structure composite........................................................................................... 38

II. Les vues dynamiques .................................................................................................................. 39
1. Le diagramme de séquence ........................................................................................................ 39
2. Le diagramme d’état transition ................................................................................................. 41
3. Le diagramme d’activité............................................................................................................. 42
4. Le diagramme de communication ............................................................................................. 45
5. Le diagramme global d’interaction ........................................................................................... 46
6. Le diagramme de temps ............................................................................................................. 48
III. Modélisation et association des diagrammes ............................................................................ 49
IV. Les outils de modélisation .......................................................................................................... 49
V. Quelques langages de programmation orientés objet .................................................................. 50
....................................................................................................................................................................... 52
Chapitre IV : ............................................................................................................................................. 52
Les processus unifiés ........................................................................................................................ 52
Introduction ............................................................................................................................................. 52
I. Définition du processus unifié UP.................................................................................................. 52
1. Les caractéristiques d’UP........................................................................................................... 52
2. Le cycle de vie d’UP .................................................................................................................... 54
3. Exemple de processus de développement logiciel qui implémente le Processus Unifié : 2TUP
(Two tracks unified process) ................................................................................................................ 56

Chapitre 1 :
Historique du langage de modélisation unifié UML
et rappels sur des notions liées à l’approche objet
Introduction
Pour faire face à la complexité croissante des systèmes d’information, de nouvelles mé-
thodes et outils ont été créés. La principale avancée des dernières années réside dans la program-
mation orientée objet (P.O.O.).
Face à ce nouveau mode de programmation, les méthodes de modélisation classique (MERISE,
Axial, IE…) ont rapidement montré certaines limites et ont dû s’adapter (MERISE/2 par exemple).
De très nombreuses autres méthodes ont également vu le jour comme Booch, OMT, fusion …
Dans ce contexte et devant le foisonnement de nouvelles méthodes de conception « orientée objet
», l’Object Management Group (OMG) a eu comme objectif de définir une notation standard utili-
sable dans les développements informatiques basés sur l’objet. C’est ainsi qu’est apparu UML (Uni-
fied Modeling Language « langage de modélisation unifié »). C’est un langage standard de modéli-
sation des systèmes d’information. Il en est à ce jour à sa version 2.5. Son étude fera l’objet de ce
cours.
I. Les méthodes objets et la genèse du langage de modélisation unifié UML

1. Historique des méthodes d’analyse
Les méthodes utilisées dans les années 1980 pour organiser la programmation impérative ou struc-
turée ou fonctionnelles (notamment Merise) étaient fondées sur la modélisation séparée des données
et des traitements.
Lorsque la programmation par objets prend de l’importance au début des années 1990, la
nécessité d’une méthode qui lui soit adaptée devient évidente. Plus de cinquante méthodes apparais-
sent entre 1990 et 1995 (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE,
etc.) mais aucune ne parvient à s’imposer. En 1994, le consensus se fait autour de trois méthodes :
– OMT (Object Modeling Technique) de James Rumbaugh fournit une représentation gra-
phique des aspects statique, dynamique et fonctionnel d’un système ;
– OOD (Object-Oriented Design) ou encore Booch de Grady Booch, introduit le concept de
paquetage (package) ;
– OOSE (Object-Oriented Software Engineering) d’Ivar Jacobson fonde l’analyse sur la des-
cription des besoins des utilisateurs (cas d’utilisation, ou use cases).

Chaque méthode avait ses avantages et ses partisans. Le nombre de méthodes en compétition
s’était réduit, mais le risque d’un éclatement subsistait : la profession pouvait se diviser entre ces
trois méthodes, créant autant de continents intellectuels qui auraient du mal à communiquer. Évé-
nement considérable et presque miraculeux, les trois Acteurs 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. L’adjectif uni-
fied est là pour marquer qu’UML unifie, et donc remplace. En fait, UML n’a pas l’ambition d’être
exactement une méthode : c’est un langage. L’unification a progressé par étapes. En 1995, Booch
et Rumbaugh (et quelques autres) se sont mis d’accord pour construire une méthode unifiée, Unified
Method 0.8 ; en 1996, Jacobson les a rejoints pour produire UML 0.9. Les acteurs les plus importants
dans le monde du logiciel s’associent alors à l’effort (IBM, Microsoft, Oracle, DEC, HP, Rational,
Unisys etc.) et UML 1.0 est soumis à l’OMG1. L’OMG adopte en novembre 1997, UML 1.1 comme
langage de modélisation des systèmes d’information à objets. La dernière version diffusée par
l'OMG est UML 2.5 bêta 2 depuis septembre 2013. Ci-dessous présenté la genèse de UML.
Figure 1 : Genèse de UML
2. 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 no-
tamment l'enchaînement des activités de production d'une entreprise. Or UML n'a pas été pensé pour
1
L’OMG (Object Management Group) est une association américaine à but non-lucratif créée en 1989 dont l’objectif
est de standardiser et promouvoir le modèle objet sous toutes ses formes. L’OMG est notamment à la base des
spécifications UML, MOF, CORBA et IDL. L’OMG est aussi à l’origine de la recommandation MDA
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 techno-
logie à objets et à laquelle se sont rangés tous les grands acteurs du domaine ; acteurs qui ont d’ail-
leurs 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 informa-
tique. 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 ma-
jeure, car il unifie les différentes approches et en donne une définition plus formelle.
2.3. UML est un support de communication
UML est avant tout un support de communication performant, qui facilite la représenta-
tion 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éli-
sation 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 com-
plè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'abstrac-
tion. Cela permet de mieux contrôler la complexité dans l'expression et l'élaboration des solutions
objet.
3. Les points forts d’UML points faibles d’UML
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.
o 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.
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.
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 lan-
gage 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’ob-
jet), 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épen-
damment 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.
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 don-
né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 en-
semble 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
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. Les 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 vo-
cabulaire doit être 0pré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) ;
 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.

Chapitre 2 :
Démarche générale de modélisation avec UML
Introduction
I. Modélisation objet
1. Définition d’un modèle
Un modèle est une représentation abstraite et simplifiée (i.e. qui exclut certains détails), 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. Un modèle est une abstraction de la réalité. L'abstraction est un des piliers de l'ap-
proche objet : il s'agit d'un processus qui consiste à identifier les caractéristiques intéressantes d'une
entité, en vue d'une utilisation précise. 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 signi-
ficative. Il reflète ce que le concepteur croit important pour la compréhension et la prédiction du
phénomène modélisé.
2. Rôle de la modélisation
Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement

du système. C’est également un bon moyen de maîtriser sa complexité et d’assurer sa cohérence.
Un modèle est un langage commun, précis, qui est connu par tous les membres de l’équipe et il est
donc, à ce titre, un vecteur privilégié pour communiquer. Cette communication est essentielle pour
aboutir à une compréhension commune aux différentes parties prenantes (notamment entre la maî-
trise d’ouvrage et la maîtrise d’œuvre informatique) et précise d’un problème donné.
Dans le domaine de l’ingénierie du logiciel, le modèle permet de mieux répartir les tâches
et d’automatiser certaines d’entre elles. C’est également un facteur de réduction des coûts
et des délais.

3. 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.
II. 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, lo-
gique, 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,
• 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 plu-
sieurs 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 utilisa-
teurs 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 utilisa-
teurs.
• à 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

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 per-
mettent 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 perspec-
tives 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'abs-
traction 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" :
• 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’environ-
nement 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éa-
lisent (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

Cette vue concerne « l’intégrité de performance ». Cette vue est très importante dans les environne-
ments 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 docu-
ments 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'ex-
haustivité, 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.
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éfinies (cf. encap-
sulation). 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.
Les diagrammes UML supportent l'abstraction. Leur niveau de détail caractérise le niveau d'abs-
traction du modèle. La structure des diagrammes UML et la notation graphique des éléments de
modélisation sont normalisées.

Chapitre 3 :
Les différents types de diagrammes UML
Introduction
UML à partir de sa version 1.3 proposait neuf (9) diagrammes tandis qu’il en existe quatorze
(14) depuis UML 2.3.
Les 14 diagrammes UML sont dépendants hiérarchiquement et se complètent, de façon à permettre
la modélisation d'un projet tout au long de son cycle de vie. Ils sont regroupés en trois grandes vues :
 Diagrammes structurels ou statiques qui rassemblent :
 Diagramme de classes : il représente les classes intervenant dans le système ;
 Diagramme d’objets : il sert à représenter les instances de classes (objets) utilisées
dans le système ;
 Diagramme de composants : il permet de montrer les composants du système d'un
point de vue physique, tels qu'ils sont mis en œuvre (fichiers, bibliothèques, bases de
données…)
 Diagramme de déploiement : il sert à représenter les éléments matériels (ordinateurs,
périphériques, réseaux, systèmes de stockage…) et la manière dont
les composants du système sont répartis sur ces éléments matériels et interagissent
entre eux.
 Diagramme des paquetages : un paquetage étant un conteneur logique
permettant de regrouper et d'organiser les éléments dans le modèle UML, le dia-
gramme de paquetage sert à représenter les dépendances entre paquetages, c’est-à-dire
les dépendances entre ensembles de définitions.
 Diagramme de structure composite : depuis UML 2.x, permet de décrire sous forme
de boîte blanche les relations entre composants d'une classe.
 Diagramme de profils : depuis UML 2.2, permet de spécialiser, de personnaliser pour
un domaine particulier un meta-modèle de référence d'UML.
 Diagrammes comportementaux qui rassemblent :

 Diagramme des cas d'utilisation : il permet d'identifier les possibilités d'interaction
entre le système et les acteurs (intervenants extérieurs au système), c'est-à-dire toutes
les fonctionnalités que doit fournir le système.

 Diagramme états-transitions : permet de décrire sous forme de machine à états finis

le comportement du système ou de ses composants.
 Diagramme d'activité : permet de décrire sous forme de flux ou d'enchaînement d'ac-
tivités le comportement du système ou de ses composants.
 Diagrammes d'interaction ou dynamiques qui rassemblent :
 Diagramme de séquence : représentation séquentielle du déroulement des traite-
ments et des interactions entre les éléments du système et/ou de ses acteurs.
 Diagramme de communication : depuis UML 2.2, représentation simplifiée d'un
diagramme de séquence se concentrant sur les échanges de messages entre les objets.
 Diagramme global d'interaction : depuis UML 2.x, permet de décrire les enchaîne-
ments possibles entre les scénarios préalablement identifiés
sous forme de diagrammes de séquences (variante du diagramme d'activité).
 Diagramme de temps : depuis UML 2.3, permet de décrire les variations
d'une donnée au cours du temps.
I. Les vues statiques
Le but de la conceptualisation est de comprendre et structurer les besoins du client. Il ne faut pas
chercher l'exhaustivité, mais clarifier, filtrer et organiser les besoins. Une fois identifiés et structurés,
ces besoins :
- définissent le contour du système à modéliser (ils précisent le but à atteindre),
- permettent d'identifier les fonctionnalités principales (critiques) du système.
1. Diagramme de cas d’utilisation
A. Représentations graphiques
i. Les composants du diagramme de cas d’utilisation
 L’acteur :
La première étape de modélisation consiste à définir le périmètre du système, à définir le contour

de l’organisation et à le modéliser. Toute entité qui est en dehors de cette organisation et qui interagit
avec elle est appelé acteur selon UML.
Un acteur est un type stéréotypé représentant une abstraction qui réside juste en dehors du système
à modéliser.
Un acteur représente un rôle joué par une personne ou une chose (Bases de données, des équipe-
ments…) qui interagit avec le système (la même personne physique peut donc être représentée par
plusieurs acteurs en fonction des rôles qu’elle joue).
Pour identifier les acteurs, il faut donc se concentrer sur les rôles joués par les entités exté-
rieures au périmètre. Dans UML, il n’y a pas de notion d’acteur interne et externe. Par définition,
un acteur est externe au périmètre de l’étude, qu’il appartienne ou pas à la société. Enfin, un acteur
n’est pas nécessairement une personne physique : il peut être un service, une société, un système
informatique …
Il existe 4 catégories d’acteurs :
- les acteurs principaux : les personnes qui utilisent les fonctions principales du système
- les acteurs secondaires : les personnes qui effectuent des tâches administratives ou de
maintenance.
- le matériel externe : les dispositifs matériels incontournables qui font partie du domaine
de l’application et qui doivent être utilisés.
- les autres systèmes : les systèmes avec lesquels le système doit interagir.
Formalisme
 Les cas d’utilisations :

Un cas d'utilisation représente une fonctionnalité fournie par le système, typiquement décrite sous
la forme Verbe + objet. Il (use case) correspond à un objectif du système, motivé par un besoin d’un
ou plusieurs acteurs. L'ensemble des use cases décrit les objectifs (le but) du système. Les cas d'uti-
lisation sont représentés par une ellipse contenant leur nom.
Formalisme :
 Les associations :

Les associations sont utilisées pour lier des acteurs avec des cas d'utilisation. Elles indiquent
qu'un acteur participe au cas d'utilisation sous une forme quelconque. Les associations sont
représentées par une ligne reliant l'acteur et le cas d'utilisation.
Formalisme :
Représentation d’un diagramme de cas d’utilisation
ii. Les relations entre les cas d’utilisation



iii. La relation entre les acteurs
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 (comme nous l’avons déjà vu
pour la relation de généralisation entre cas d’utilisation).
Par exemple, la figure suivante montre que le directeur des ventes est un préposé aux com-
mandes avec un pouvoir supplémentaire : en plus de pouvoir passer et suivre une commande, il peut
gérer le stock. Par contre, le préposé aux commandes ne peut pas gérer le stock.
B. Représentation textuelle des cas d’utilisation

Chaque cas d'utilisation, est associé à une série d'actions représentant la fonctionnalité voulue, ainsi
que les stratégies à utiliser dans l'alternative où la validation échoue, ou des erreurs se produisent.
Un cas d’utilisation est donc une abstraction de plusieurs chemins d’exécution. Une instance de cas
d’utilisation est appelée : « scénario ». C’est un chemin particulier pris lors de l’exécution d’un cas
d’utilisation.
Le nombre d’instances pour un cas d’utilisation peut être très important, voire infini.
Les scénarios (scénarii) peuvent être classés en :
- scénario principal ou nominal : il correspond à l’instance principale du cas d’utilisation.
C’est le scénario typique de succès. C’est à dire le chemin « normal » d’exécution du cas d’utilisa-
tion qui n’implique pas d’erreurs.
- Scénarios secondaires : il peut être un cas alternatif (un choix), un cas exceptionnel ou une
erreur.

La description textuelle est constituée des éléments suivants :

Le pré-supposé : ce sont les actions qui doivent être remplies avant le lancement du cas
d’utilisation.
La pré-condition : ce sont les conditions qui doivent être remplies avant le lancement du
cas d’utilisation.
Le déclencheur : C’est l’élément qui déclenche le cas d’utilisation.
Le dialogue : C’est le scénario principal et le Scénario secondaire.
La post condition : Ce sont les différents mécanismes pouvant conduire à la fin de l’exécu-
tion du cas d’utilisation.
L’arrêt : C’est l’état du système à l’arrêt du cas d’utilisation.
Exercice d’application : Étude d'un système de réservation

Dans un établissement scolaire, on désire gérer la réservation des salles de cours ainsi que
du matériel pédagogique (ordinateur portable et / ou vidéo projecteur). Seuls les enseignants sont
habilités à effectuer des réservations (sous réserve de disponibilité de la salle ou du matériel). Le
planning des salles peut quant à lui être consulté par tout le monde (enseignant et étudiant). Par
contre, le récapitulatif horaire par enseignant (calculé à partir du planning des salles) ne peut être
consulté que par des enseignants. Enfin, il existe pour chaque formation un enseignant responsable
qui seul peut éditer le récapitulatif horaire pour l’ensemble de la formation. Le chef d’établissement
est le seul qui est habilité à gérer les comptes d’utilisateurs. Il est également responsable de la gestion
des salles de cours ainsi que du matériel pédagogique.
Travail à faire :
1- Proposez le diagramme de cas d’utilisation (Représentation graphique).
2- Proposez la représentation textuelle des différents cas d’utilisation.
2. Diagramme de classe
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 dia-
gramme de classe permet de représenter l’ensemble des informations finalisées qui sont gérées par
le domaine. Ces informations sont structurées, c’est-à-dire qu’elles ont regroupées dans des classes.
Le diagramme met en évidence d’éventuelles relations entre ces classes. Le diagramme de classes
comporte quelques concepts : classe, attribut, identifiant, opération (méthode) et relation
i. La classe

Une classe est un type abstrait caractérisé par des propriétés (attributs et méthodes) communes à un
ensemble d'objets et permettant de créer des objets ayant ces propriétés. Ou encore la description
d’un ensemble d’objets partageant la même sémantique, ainsi que les mêmes attributs, opérations et
relations.
Représentation :
Les classes sont représentées en UML par des rectangles divisés en trois compartiments :
• le 1er compartiment représente le nom de la classe qui n’est pas souligné ;
• le 2ème compartiment représente les attributs typés de la classe ;
• le 3ème compartiment représente les opérations (méthodes) de la classe.
ii. Les attributs

Une classe correspond à un concept global d’information et se compose d’un ensemble d’informa-
tions élémentaires, appelées attributs de classe. Un attribut représente la modélisation d’une infor-
mation élémentaire représentée par son nom et son format.
iii. L’identifiant de la classe

L’identifiant est un attribut particulier, qui permet de repérer de façon unique chaque objet, instance
de la classe.
iv. La notion d’opération (méthode)
L’opération représente un élément de comportement des objets, défini de manière globale dans la
classe. Une opération est une fonctionnalité assurée par une classe. La description des opérations
peut préciser les paramètres d’entrée et de sortie ainsi que les actions élémentaires à exécuter.
 Visibilité et portée des attributs et des opérations :

v. La notion de relation
S’il existe des liens entre objets, cela se traduit nécessairement par des relations qui existent entre
leurs classes respectives. Les liens entre les objets doivent être considérés comme des instances de
relations entre classes.
Il existe plusieurs types de relations entre classes : l’association, la généralisation/spécialisation et
la dépendance
 L’association
Une association représente une relation structurelle entre classes d’objets. La plupart des associa-
tions sont binaires, c’est à dire qu’elles connectent deux classes. On représente une association en
traçant une ligne entre les classes associées.

La multiplicité des associations

Elle définit le nombre d’instances de l’association pour une instance de la classe. La multiplicité
est définie par un nombre entier ou un intervalle de valeurs. La multiplicité est notée
sur le rôle (elle est notée à l’envers de la notation MERISE). Les valeurs de multiplicité expriment
les contraintes liées au domaine de l’application. Il est donc important de déterminer les valeurs de
multiplicité optimales pour trouver le bon équilibre entre complexité et efficacité. La multiplicité
est représentée sous la forme d’un couple de cardinalités.
Exemple : Considérons le diagramme de classe suivant :
Proposition de solution :
 Les classes-association
Les attributs d’une classe dépendent fonctionnellement de l’identifiant de la classe. Parfois, un
attribut dépend fonctionnellement de 2 identifiants, appartenant à 2 classes différentes ou il peut
arriver que l’on ait besoin de garder des informations (attributs ou opérations) propres à une asso-
ciation. Une classe de ce type est appelée classe association.

Exemple 1 :
L’attribut « quantité » dépend fonctionnellement du numéro de commande et du code produit. On

va donc placer l’attribut « quantité commandée » dans l’association « comporter ».
Exemple 2 :
 L’agrégation
Dans UML, l’agrégation n’est pas un type de relation mais une variante de l’association. 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é. L’agrégation se représente toujours avec un petit losange
du côté de l’agrégat.
Le choix d’une association de type agrégation traduit la volonté de renforcer la dépendance entre
classes. Les agrégations indiquent une relation de contenant contenu. Elle permet de modéliser des
relations de type maître et esclaves.
L’agrégation permet de modéliser une contrainte d’intégrité et de désigner l’agrégat comme
contrainte.
A travers une telle contrainte, il est possible de représenter par exemple :
• la propagation des valeurs d’attributs d’une classe vers une autre classe ;
• une action sur une classe qui implique une action sur une autre classe ;
• une subordination des objets d’une classe à une autre classe

Exemple :

 La composition
La composition est un cas particulier de l’agrégation dans laquelle la vie des composants est liée à
celle des agrégats. Elle fait souvent référence à une contenance physique. Dans la composition
l’agrégat ne peut être multiple.
La composition implique, en plus de l’agrégation, une coïncidence des durées de vie des composants
: la destruction de l’agrégat (ou conteneur) implique automatiquement la destruction de tous les
composants liés. La composition se représente par un losange noir.
Exemple 1 :
Exemple 2 :

Considérer les classes dossier et fichier (Un dossier contient 0 ou plusieurs fichiers. Un fichier est
dans un dossier).
 La généralisation / spécialisation
Le principe de généralisation / spécialisation permet d’identifier parmi les objets d’une classe (gé-
nérique) des sous-ensembles d’objets (des classes spécialisées) ayant des définitions spécifiques. La
classe plus spécifique (appelée aussi classe fille, classe dérivée, classe spécialisée, classe descen-
dante …) est cohérente avec la classe plus générale (appelée aussi classe mère, classe générale …),
c’est-à-dire qu’elle contient par héritage tous les attributs, les membres, les relations de la classe
générale, et peut contenir d’autres. Une relation de généralisation est indiquée par une flèche creuse
se dirigeant vers la classe "parent".
Exemple :
3. Diagramme d’objet
Un diagramme d’objets représente des objets (i.e. instances de classes) et leurs liens (i.e. instances
de relations). Ils modélisent des exemples de classes et sont employés pour décrire le système à un
instant particulier. A l’exception de la multiplicité, qui est explicitement indiquée, le diagramme
d’objets utilise les mêmes concepts que le diagramme de classes. Ils sont essentiellement utilisés
pour comprendre ou illustrer des parties complexes d’un diagramme de classes.
Représentation : Les diagrammes des objets représentent seulement les objets et les associations.
i. Les objets
Des objets sont identifiés en plaçant le nom d'instance suivi des deux points (:) devant le nom de la
classe, les deux soulignés. Les valeurs de propriété sont écrites comme des paires "nom=valeur".
L'icône représentant un objet est un rectangle divisé en sections.

ii. L’association
Les associations entre les objets sont représentées simplement en utilisant une ligne les joignant.
Exemple : diagramme de classes et de diagramme d’objets associé
4. Diagramme des composants

Le diagramme des composants est principalement employé pour décrire les dépendances entre les
divers composants logiciels tels que la dépendance entre les fichiers exécutables et les fichiers
source.
Représentation : Ils décrivent les composants et leurs dépendances dans l’environnement de réali-
sation.
i. Composants
Un composant représente une entité logicielle d'un système. Un composant est représenté par une
boîte rectangulaire, avec deux rectangles dépassant du côté gauche.
UML définit 5 stéréotypes aux composants :

- « « document » » : un document quelconque,
- « « exécutable » » : un programme qui peut s’exécuter,
- « « fichier » » : un document contenant un code source ou des données,
- « « bibliothèque » » : une bibliothèque statique ou dynamique,
- « « table » » : une table de base de données relationnelle.

ii. Dépendance
Une dépendance est utilisée pour modéliser la relation entre deux composants. La notation
utilisée pour cette relation de dépendance est une flèche pointillée, se dirigeant d'un compo-
sant donné au composant dont il dépend.
5. Diagramme de déploiement
Le diagramme de déploiement modélise les composants matériels utilisés pour implémenter

un système et l'association entre ces composants. Des diagrammes de déploiement peuvent
être mise en œuvre dès la phase de conception pour documenter l'architecture physique du
système.
Représentation : Les éléments utilisés dans des diagrammes de déploiement sont des com-
posants, comme dans les diagrammes des composants, et des nœuds, qui représentent les
ressources physiques de traitement du système, et leurs associations.
i. Composant
Un composant représente une entité logicielle du système. (Fichier de code source, pro-
grammes, documents, fichiers de ressource, etc.). Sur un diagramme de déploiement, les
composants sont placés dans des nœuds pour identifier l'endroit de leur déploiement.
ii. Nœud
Un nœud représente un ensemble d'éléments matériels du système. Cette entité est repré-
sentée par un cube tridimensionnel.
iii. Association
Une association, représentée par une ligne pleine entre deux nœuds, indique une ligne de
communication entre les éléments matériels.

Exemple2
6. Diagramme de paquetage
Un paquetage regroupe des éléments de la modélisation appelés aussi membres, portant sur
un sous-ensemble du système. Le découpage en paquetage doit traduire un découpage lo-
gique du système à construire qui corresponde à des espaces de nommage homogènes. Les
éléments d’un paquetage peuvent avoir une visibilité déclarée soit de type public (+) soit
privé (-).

Un paquetage peut importer des éléments d’un autre paquetage. Il peut être fusionné avec
un autre paquetage.
Le diagramme de paquetage sert à représenter les dépendances entre paquetages
Représentation : trois manières existent pour présenter un paquetage.
• Représentation globale : Le nom du paquetage se trouve à l’intérieur du grand
rectangle.
• Représentation détaillée : Les membres du paquetage sont représentés et le nom

du paquetage d’ensemble s’inscrit dans le petit rectangle.
• Représentation éclatée : Les membres du paquetage sont reliés par un lien connecté
au paquetage par le symbole⊕.
La figure suivante donne un exemple de représentation éclatée
i. Dépendance entre paquetages

La dépendance entre paquetages peut être qualifiée par un niveau de visibilité qui est soit
public soit privé. Par défaut le type de visibilité est public.

À chaque type de visibilité est associé un lien de dépendance. Les deux types de dépendances
entre paquetages sont :
• «import» – Ce type de dépendance permet, pour un paquetage donné, d’importer
l’espace de nommage d’un autre paquetage. Ainsi tous les membres du paquetage donné ont
accès à tous les noms des membres du paquetage importé sans avoir à utiliser explicitement
le nom du paquetage concerné. Ce type de dépendance correspond à un lien ayant une visi-
bilité « public ».
• « access » – Ce type de dépendance permet, pour un paquetage donné, d’avoir accès
à l’espace de nommage d’un paquetage cible. L’espace de nommage n’est donc pas importé
et ne peut être transmis à d’autres paquetages par transitivité. Ce type de dépendance cor-
respond à un lien ayant une visibilité « privé ».
Dans l’exemple suivant, les éléments de Clients externes sont importés dans Domaine client
et ensuite dans Domaine tiers. Cependant, les éléments de Clients internes sont seulement
accessibles par le paquetage Domaine client et donc pas à partir du paquetage Domaine tiers.
7. Diagramme de structure composite

Le diagramme de structure composite permet de décrire des collaborations d’instances (de
classes, de composants…) constituant des fonctions particulières du système à développer.
Une collaboration représente un assemblage de rôles d’éléments qui interagissent en vue de
réaliser une fonction donnée.
Représentation du diagramme de structure composite :
Cette représentation permet de montrer plus explicitement les éléments de la collaboration :
• la collaboration représentée par une ellipse en pointillé ;

• les éléments participant à la collaboration (classe, composant…) représentés à l’ex-

térieur de la collaboration ;
• les rôles considérés dans chaque participation représentés sur les liens entre les élé-
ments participants et la collaboration.
II. Les vues dynamiques

Les cas d’utilisation sont centrés sur les besoins des utilisateurs. Ils aident à construire le bon sys-
tème. Ils disent ce qu’un système doit faire, non comment il doit le faire. La vue des cas d’utilisation
est une description fonctionnelle des besoins, structurée par rapport à des acteurs. Le passage à
l’approche objet s’effectue en associant une collaboration à chaque cas d’utilisation.
Une collaboration décrit les objets du domaine, les connexions entre ces objets et les messages
échangés par les objets.
1. Le diagramme de séquence
Les diagrammes des séquences documentent les interactions à mettre en œuvre entre les classes
pour réaliser un résultat, tel qu'un cas d'utilisation. UML étant conçu pour la programmation orientée
objet, ces communications entre les classes sont reconnues comme des messages. Le diagramme
des séquences énumère des objets horizontalement, et le temps verticalement. Il modélise l'exécu-
tion des différents messages en fonction du temps.
Représentation : Dans un diagramme des séquences, les classes et les acteurs sont énumérés en
colonnes, avec leurs lignes de vie verticales indiquant la durée de vie de l'objet.
i. Objet
Les objets sont des instances des classes, et sont rangés horizontalement. La représentation gra-
phique pour un objet est similaire à une classe (un rectangle) précédée du nom d'objet (facultatif) et
des deux points (:).
ii. Acteur
Les acteurs peuvent également communiquer avec des objets, ainsi ils peuvent eux aussi être énu-
mérés en colonne. Un acteur est modélisé en utilisant le symbole habituel :
iii. Ligne de vie

Les lignes de vie, LifeLine, identifient l'existence de l'objet par rapport au temps. La notation utilisée
pour une ligne de vie est une ligne pointillée verticale partant de l'objet.
iv. Activation
Les activations, sont modélisées par des boîtes rectangulaires sur la ligne de vie. Elles indi-
quent quand l'objet effectue une action.
v. Message
Les messages, modélisés par des flèches horizontales entre les activations, indiquent les communi-
cations entre les objets.
L'exemple ci-dessous représente un diagramme des séquences qui utilise des objets par dé-
faut (aucun nom n'est spécifié).
Exemple

2. Le diagramme d’état transition
Les diagrammes d'état sont utilisés pour documenter les divers modes ("état") qu'une classe peut
prendre, et les événements qui causent une transition d'état. Ils ont pour rôle de représenter les trai-
tements (opérations) qui vont gérer le domaine étudié. Ils définissent l'enchaînement des états de
classe et font donc apparaître l'ordonnancement des travaux.
Représentation :
i. Etat :
Un état correspond à une situation durable dans laquelle se trouvent les objets d'une classe. On lui
associe les règles de gestion et les activités particulières.
Etat : objets d'une classe + règles de gestion + changements d'états
Elle est représentée par rectangle avec les coins arrondis, contenant le nom de l'état.
Exemples pour une commande : Etat "en préparation" et Etat "en cours"
ii. Transition ou événement
Une transition décrit le changement de l'état d'un objet, provoqué par un événement. Un objet passe
d'un état à un autre suite à un événement, certains événements pouvant ne pas provoquer de chan-
gement d'état. Une transition est une relation entre 2 états. Elle est orientée. Sa représentation sym-
bolique est une flèche sur laquelle est annoté l'événement qui concourt au changement d'état.

Ou
Exemple : Une commande passera dans l'état "En attente" dès lors qu'elle aura été expédiée.
iii. Etat initial

L’état initial est l'état d'un objet avant toutes transitions. L'état initial est représenté par un cercle
plein. Un seul état initial est autorisé sur un diagramme.
iv. Etat final
L’état final représente la destruction de l'objet que nous modélisons. Selon les événements, il peut
exister plusieurs états finaux. Ces états sont représentés par un cercle plein entouré d'un cercle.
Exemple 1 : Diagramme d'état qui modélise l'état du compte d'un utilisateur :
Exemple 2 : de diagramme d'état qui modélise l'état d’une commande :
3. Le diagramme d’activité
Les diagrammes d'activité sont utilisés pour documenter le déroulement des opérations dans un sys-
tème, du niveau commercial au niveau opérationnel (de haut en bas). En regardant un diagramme

d'activité, vous trouverez des éléments des diagrammes d'état. En fait, le diagramme d'activité est
une variante du diagramme d'état où les "états" représentent des opérations, et les transitions re-
présentent les activités qui se produisent quand l'opération est terminée. L'usage général des dia-
grammes d'activité permet de faire apparaître les flots de traitements induits par les processus in-
ternes par rapport aux évènements externes.
Représentation :
i. Etat d’activité ou une activité :
L’état d'activité marque une action faite par un objet. Il est représenté par un rectangle ar-
rondi.
ii. Transition
Quand un état d'activité est accompli, le traitement passe à un autre état d'activité. Les transitions
sont utilisées pour marquer ce passage. Les transitions sont modélisées par des flèches.
iii. Couloir
Le diagramme d'activités fait intervenir les acteurs de chaque activité. Chaque activité sera placée
dans une colonne (couloir) qui correspond à l'acteur. Les objets sont énumérés au-dessus de la co-
lonne, et les barres verticales séparent les colonnes pour former les couloirs d’activités.
iv. Etat initial
L’état initial marque le point d'entrée la première activité. Il est représenté, comme dans le dia-
gramme d'état, par un cercle plein. Il ne peut y avoir qu'un seul état initial sur un diagramme.
v. Etat final
L'état final marque la fin du déroulement des opérations modélisées. Il peut y avoir des états finaux
multiples sur un diagramme. Ils sont représentés par un cercle plein entouré d'un autre cercle.
vi. Barre de Synchronisation

Souvent, certaines activités peuvent être faites en parallèle. Pour dédoubler le traitement "Fork",
ou le reprendre quand des activités multiples ont été accomplies ("join"), des barres de synchroni-
sation sont utilisées. Celles-ci sont modélisées par des rectangles pleins, avec des transitions
multiples entrantes ou sortantes.
Formalisme du Diagramme
Exemple : Authentification d’un utilisateur

4. Le diagramme de communication
Le diagramme de communication constitue une autre représentation des interactions que

celle du diagramme de séquence. En effet, le diagramme de communication met plus l’ac-
cent sur l’aspect spatial des échanges que l’aspect temporel.
Représentation :
i. Rôle
Chaque participant à un échange de message correspondant à une ligne de vie dans le dia-
gramme de séquence se représente sous forme d’un rôle dans le diagramme de communica-
tion. Un rôle est identifié par :
<nom de rôle> : <nom du type>
Une des deux parties de cette identification est obligatoire ainsi que le séparateur « : ». Le
nom du rôle correspond au nom de l’objet dans le cas où l’acteur ou la classe ont un rôle
unique par rapport au système. Le nom du type correspond au nom de la classe lorsque l’on
manipule des objets.
Exemple : administrateur : utilisateur
Pour un utilisateur qui est vu au travers de son rôle d’administrateur.
ii. Message
Un message correspond à un appel d’opération effectué par un rôle émetteur vers un rôle
récepteur. Le sens du message est donné par une flèche portée au-dessus du lien reliant les
participants au message (origine et destinataire). Chaque message est identifié par : <nu-
méro> : nom ( )
Plus précisément l’identification d’un message doit respecter la syntaxe suivante :
[n° du message préc. reçu] «.» n° du message [clause d’itération] [condition]
«:» nom du message.
Formalisme :

Les rôles correspondent à des objets. Le lien entre les rôles est représenté par un trait maté-
rialisant le support des messages échangés. La figure suivante donne le formalisme de base
du diagramme de communication.
Un exemple de diagramme de communication est donné à la figure suivante
5. Le diagramme global d’interaction
Le diagramme global d’interaction permet de représenter une vue générale des interactions
décrites dans le diagramme de séquence et des flots de contrôle décrits dans le diagramme
d’activité.
Autrement dit, le diagramme global d’interaction est un diagramme d’activité dans lequel
on représente des fragments d’interaction ou des utilisations d’interactions. Ainsi, il est pos-
sible de représenter :
• des choix de fragments d’interactions (fusion) ;
• des déroulements parallèles de fragments d’interactions (débranchement et jonc-

tion) ;
• des boucles de fragments d’interaction.

Les lignes de vie concernées par le diagramme global d’interaction peuvent être citées dans
l’en-tête du diagramme mais ne sont pas à représenter graphiquement.
Concepts manipulés :
Le diagramme global d’interaction utilise les concepts du diagramme d’activité auquel on

ajoute deux compléments :
• Les fragments d’interaction du diagramme de séquence : Il s’agit comme le

montre la figure suivante de la notion de fragment d’interaction vue dans le diagramme de
séquence mais qui ne doit pas être détaillé à ce niveau.
• Les utilisations de fragments d’interaction : Il est aussi possible de faire appel à

des fragments d’interaction à l’aide de l’opérateur ref comme le montre la figure suivante.
Exemple :

6. Le diagramme de temps
Le diagramme de temps permet de représenter les états et les interactions d’objets dans un
contexte où le temps a une forte influence sur le comportement du système à gérer.
Autrement dit, le diagramme de temps permet de mieux représenter des changements d’états
et des interactions entre objets liés à des contraintes de temps.
Pour cela, le diagramme de temps utilise en plus des lignes de vie, les concepts suivants :
• Des états ou des lignes de temps conditionnées avec deux représentations gra-
phiques possibles.
• Des représentations propres aux aspects temporels : échelle de temps, contrainte de

durée, événements…
Concepts manipulés :
Le diagramme de temps utilise trois concepts de base :
• Ligne de vie : Elle représente l’objet que l’on veut décrire. Elle se dessine de ma-
nière horizontale. Plusieurs lignes de vie peuvent figurer dans un diagramme de temps.
• État ou ligne de temps conditionnée : Les différents états que peut prendre l’objet
d’étude sont listés en colonne permettant ainsi de suivre le comportement de l’objet ligne
par ligne (une ligne pour un état).
• États linéaires : Il s’agit du même concept que le précédent, mais la représentation

de la succession des états est faite de manière linéaire à l’aide d’un graphisme particulier.
Ces diagrammes d’UML 2, d’une utilité variable selon les cas, ne sont pas nécessai-
rement tous produits à l’occasion d’une modélisation. Les plus utiles pour la maîtrise d’ou-
vrage sont les diagrammes d’activités, de cas d’utilisation, de classes, d’objets, de séquence
et d’états-transitions.
Les diagrammes de composants, de déploiement et de communication sont surtout utiles

pour la maîtrise d’œuvre à qui ils permettent de formaliser les contraintes de la réalisation
et la solution technique.
III. Modélisation et association des diagrammes
UML étant un langage de modélisation, n’impose pas une méthode de travail. Pour la réalisation
d’un projet, l’utilisation de tous les diagrammes n’est pas obligatoire. Leur utilisation varie en fonc-
tion des exigences et des fonctionnalités du système étudié.
Le tableau ci-dessous résume l’utilisation de quelques diagrammes pour la réalisation de
chaque phase d’un projet.
Besoins des utilisateurs : spécifier le système en définis- Diagramme de cas d’utilisa-
sant les acteurs, les cas d’utilisation et les associations équi- tion
valentes)
Interactions entre objets : Modéliser les objets Diagramme de séquence
Communicants en identifiant et en nommant les instances Diagramme de collaboration
(objets physiques puis abstraits), on spécifie les liens entre
les objets et les messages transitant par ces liens.)
Structure statique : Modéliser la structure de l’application Diagramme de classes
Diagramme objet
Dynamique des objets : Modéliser le comportement des Diagramme états -transition
objets et les traitements. Diagramme d’activités
Réalisation et déploiement : Modéliser l’implantation de Diagramme de composants
l’application Diagramme de déploiement
IV. Les outils de modélisation
Voici une liste non exhaustive des logiciels de modélisation des diagrammes en UML.

Logiciels libres :
Neptune outil permettant de vérifier les modèles UML1.x via des règles OCL ;
ATL solution open source pour faire des transformations de modèles vers ou depuis UML
(entre autres);
ArgoUml un modeleur UML sous Licence BSD ;
Gaphorun modeleur UML sous GPL;
BOUML, un modeleur UML sous GPL pour Windows, Linux, MacOS X et Solaris ;
Eclipse UML2, Méta modèle UML2, sans interface graphique ;
Netbeans [1], logiciel open source de Sun;
Papyrus un modeleur UML2 open source pour la plateforme Eclipse Licence EPL;
Delphia Object Modeler (version personnelle), Outil de modélisation et de prototypage.
Logiciels propriétaires
Enterprise Architect, un outil de modélisation UML ;
MagicDraw, un éditeur de diagrammes UML ;
Objecteering d'Objecteering Software ;
Poseidon (version commerciale), basé sur ArgoUml (logiciel libre);
PowerAMC / PowerDesigner [3], de Sybase (un outil de modélisation complet intégrant
l'UML en plus des classiques MCD, MPD ...) ;
Rhapsody de Telelogic pour une modélisation PSM (Platform Specific Model) complète de
systèmes ou de logiciels embarqués ;
Rational Software Architect/ Rational Software Modeler (et toujours Rose/XDE), de IBM
Software Rational ;
SDE for Eclipse, un plugin UML pour Eclipse ;
Visual Paradigm for UML, de Visual Paradigm International Ltd;
Delphia Object Modeler (version commerciale), Outil de modélisation et de prototypage.
Diagrammes de classe et d'état. Langage objet intégré. Générateur de Java…
V. Quelques langages de programmation orientés objet
• Ada
• C++ (voir aussi la catégorie C++)
• C#
• Delphi (=Pascal orienté objet)
• Java
• Kylix

• Objective-C
• Objective Caml (ocaml)
• Perl
• PHP (Depuis la version 4)
• Python
• SmallTalk (totalement objet)
Etc.

Chapitre IV :
Les processus unifiés
Introduction
La maîtrise des processus de développement implique une organisation et un suivi

des activités : c’est ce à quoi s’attachent les différentes méthodes qui s’appuient sur l’utili-
sation du langage UML pour modéliser un système d’information. UP (Unified Process) est
une méthode générique de développement de logiciel. Générique signifie qu'il est nécessaire
d'adapter UP au contexte du projet, de l'équipe, du domaine et/ou de l'organisation (exemple
: RUP, XUP, 2 TUP, UP7…).
I. Définition du processus unifié UP

1. Les caractéristiques d’UP
Le processus unifié est un processus de développement logiciel : il regroupe les activités à mener
pour transformer les besoins d’un utilisateur en système logiciel.
Les caractéristiques essentielles du processus unifié sont :
- Il est à base de composants,
- Il utilise le langage UML (ensemble d'outils et de diagramme),
- Il est piloté par les cas d’utilisation,
- Il est centré sur l’architecture,
- Il est itératif et incrémental.
a) Le processus unifie est pilote par les cas d’utilisation
L’objectif principal d’un système logiciel est de rendre service à ses utilisateurs ; il faut par consé-
quent bien comprendre les désirs et les besoins des futurs utilisateurs. Le processus de développe-
ment sera donc centré sur l'utilisateur. Le terme utilisateur ne désigne pas seulement les utilisateurs
humains mais également les autres systèmes.

b) Le processus unifie est centre sur l’architecture
Dès le démarrage du processus, on aura une vue sur l'architecture à mettre en place. L’architecture
d’un système logiciel peut être décrite comme les différentes vues du système qui doit être construit.
L’architecture logicielle équivaut aux aspects statiques et dynamiques les plus significatifs du sys-
tème. L’architecture émerge des besoins de l’entreprise, tels qu’ils sont exprimés par les utilisateurs
et autres intervenants et tels qu’ils sont reflétés par les cas d’utilisation.
Elle subit également l’influence d’autres facteurs :
 la plate-forme sur laquelle devra s’exécuter le système ;
 les briques de bases réutilisables disponibles pour le développement ;
 les considérations de déploiement, les systèmes existants et les besoins non fonctionnels
(performance, fiabilité..).
c) Le processus unifie est itératif et incrémental
Le développement d’un produit logiciel destiné à la commercialisation est une vaste entreprise qui
peut s’étendre sur plusieurs mois. On ne va pas tout développer d’un coup. On peut découper le
travail en plusieurs parties qui sont autant de mini projets. Chacun d’entre eux représentant une
itération qui donne lieu à un incrément.
Une itération désigne la succession des étapes de l’enchaînement d’activités, tandis qu’un
incrément correspond à une avancée dans les différents stades de développement. Le choix de ce
qui doit être implémenté au cours d’une itération repose sur deux facteurs :
 Une itération prend en compte un certain nombre de cas d’utilisation qui ensemble, amélio-
rent l’utilisabilité du produit à un certain stade de développement.
 L’itération traite en priorité les risques majeurs.
Un incrément constitue souvent un additif. A chaque itération, les développeurs identifient et spé-
cifient les cas d’utilisations pertinents, créent une conception en se laissant guider par l’architecture
choisie, implémentent cette conception sous forme de composants et vérifie que ceux-ci sont con-
formes aux cas d’utilisation. Dès qu’une itération répond aux objectifs fixés le développement passe
à l’itération suivante. Pour rentabiliser le développement il faut sélectionner les itérations néces-
saires pour atteindre les objectifs du projet. Ces itérations devront se succéder dans un ordre logique.
Un projet réussi suivra un déroulement direct, établi dès le début par les développeurs et dont ils ne
s’éloigneront que de façon très marginale. L’élimination des problèmes imprévus fait partie des
objectifs de réduction des risques.
2. Le cycle de vie d’UP
Présentation

Description
Le processus unifié répète un certain nombre de fois une série de cycles. Tout cycle se conclut par
la livraison d’une version du produit aux clients et s’articule en 4 phases : création, élaboration,
construction et transition, chacune d’entre elles se subdivisant à son tour en itérations. Pour mener
efficacement le cycle, les développeurs ont besoin de construire toutes les représentations du produit
logiciel :

3. Exemple de processus de développement logiciel qui implémente le Pro-

cessus Unifié : 2TUP (Two tracks unified process)
Dans le processus 2TUP, les activités de développement sont organisées suivant 5 workflows qui
décrivent :
 La capture des besoins,

 L’analyse,
 La conception,
 L’implémentation
 Et le test.
Le processus 2TUP est une trame des meilleures pratiques de développement, il doit être utilisé
comme un guide pour réaliser un projet et non comme l’arme ultime et universelle de développe-
ment.
A. Le cycle de développement avec 2TUP
Le 2TUP propose un cycle de développement en Y, qui dissocie les aspects techniques des aspects
fonctionnels. Il commence par une étude préliminaire qui consiste essentiellement à identifier les
acteurs qui vont interagir avec le système à construire, les messages qu'échangent les acteurs et le
système. En suite à produire le cahier des charges et à modéliser le contexte. Le processus s'articule
autour de 3 phases essentielles : une branche technique ; une branche fonctionnelle et une phase de
réalisation.

i. La branche fonctionnelle
La branche fonctionnelle capitalise la connaissance du métier de l’entreprise. Cette branche

capture des besoins fonctionnels, ce qui produit un modèle focalisé sur le métier des utilisa-
teurs finaux.
ii. La branche technique
La branche technique capitalise un savoir-faire technique et/ou des contraintes techniques.

Les techniques développées pour le système le sont indépendamment des fonctions à réali-
ser.
iii. La phase de réalisation
La phase de réalisation consiste à réunir les deux branches, permettant de mener une con-
ception applicative et enfin la livraison d'une solution adaptée aux besoins.
iv. Représentation

Cours Modélisation UML 2

Transféré par

Droits d'auteur :

Formats disponibles

Cours Modélisation UML 2

Transféré par

Informations du document

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

Cours Modélisation UML 2

Transféré par

Droits d'auteur :

Formats disponibles

Cycle : BACHELOR

ANNEE ACADEMIQUE 2023-2024

Nom (s) et prénom (s) : DIFFOUO TAZO Evariste

Grade ou Qualification : Ingénieur Informaticien & Doctorant

Téléphone : (+237) 697 481 969 / (+237) 677 268 237

Courriel : [email protected] / [email protected]

Quotas horaire semestriel prévus : 32 heures

À la fin de cet enseignement, l’étudiant doit être capable de :

Table des matières

7. Diagramme de structure composite........................................................................................... 38

PROPOSE PAR DIFFOUO TAZO EVARISTE 5

I. Les méthodes objets et la genèse du langage de modélisation unifié UML

PROPOSE PAR DIFFOUO TAZO EVARISTE 6

Figure 1 : Genèse de UML

2. Cadre d’utilisation d’UML

2.1. UML est une norme

2.2. UML est un langage de modélisation objet

2.3. UML est un support de communication

PROPOSE PAR DIFFOUO TAZO EVARISTE 8

2.4. UML est un cadre méthodologique

3. Les points forts d’UML points faibles d’UML

Les points forts d’UML

o UML est un langage formel et normalisé. En effet :

Les points faibles d’UML

o La mise en pratique d'UML nécessite un apprentissage et passe par une période

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

1. Concepts importants de l’approche objet

PROPOSE PAR DIFFOUO TAZO EVARISTE 10

2. Les limites de l’approche objet

 Comment comparer deux solutions de découpe objet d'un système ?

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

PROPOSE PAR DIFFOUO TAZO EVARISTE 12

Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement

PROPOSE PAR DIFFOUO TAZO EVARISTE 13

3. Caractéristiques fondamentales des modèles

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

II. Comment modéliser avec UML ?

UML se décompose en plusieurs parties :

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

PROPOSE PAR DIFFOUO TAZO EVARISTE 14

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

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

2. Les différentes vues d’UML

PROPOSE PAR DIFFOUO TAZO EVARISTE 15

2.1. La vue logique

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

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

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

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

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

PROPOSE PAR DIFFOUO TAZO EVARISTE 16

2.3. La vue des processus

• les interactions entre les processus (leur communication).

2.4. La vue de déploiement

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

2.5. La vue des cas d’utilisation

PROPOSE PAR DIFFOUO TAZO EVARISTE 17

3. Les niveaux d’abstractions

3.2. Analyse du domaine

3.3. Analyse applicative