Cours UML G2 ESIS 2016-2017

ECOLE SUPERIEURE D’INFORMATIQUE SALAMA
G2 GENIE LOGICIEL ET RESEAUX AS
Par Patrick KASONGA
Avril 2017
Patrick KASONGA, Cours de Conception des systèmes d’informations avec UML, G2 ESIS 2016-2017 Page |1
Plan du cours
1. Intitulé du cours : Conception des systèmes d’informations

2. Année d’études : 2ème Graduat Génie logiciel et Réseaux AS
3. Heures théoriques : 45 H et Heures pratiques : 15 H
4. Titulaire du cours : Patrick KASONGA
E-mail : patrick.kasonga@esisalama.org
5. Objectifs du cours
5.1. Objectif général
Maitriser l’analyse et la conception des systèmes d’informations à l’aide des processus UML
5.2. Objectifs spécifiques
A l’issue de ce cours, l’étudiant doit être capable de :

- Décrire le langage UML
- Savoir élaborer les différents diagrammes UML
- Utiliser les processus UP et 2TUP pour l’analyse et la conception d’un système d’informations
6. Contenu de l’enseignement
INTRODUCTION GENERALE
0.1. Développement logiciel
0.2. Cycle de développement logiciel
0.3. Le Système d’Informations d’entreprise
CHAP I : LE LANGAGE UML

II.1. Historique
II.2. Présentation d’UML
II.3. Les diagrammes UML
CHAP III : LES PROCESSUS UML

III.1. Le Processus Unifié UP
III. 2. Le Processus 2TUP
CONCLUSION GENERALE
7. Méthodes d’enseignement :
- Exposé
- Discussion & Débat
- Etude de cas
8. Ressources : Tableau et Videoprojecteur
9. Travaux pratiques : travaux individuels et en groupes
10. Stratégies d’évaluation : épreuves écrites avec notes de cours
11. Notice bibliographique
1. BLANC X., MOUNIER L., UML 2 pour les développeurs, éd. Eyrolles, Paris, 2008
2. Christian SOUTOU, UML pour les bases de données, Ed. Eyrolles, Paris, 2008
3. GABAY J. & GABAY D., UML 2 Analyse et Conception, Ed. Dunod, Paris, 2009
4. Gilles ROY, Conception des bases de données avec UML, Presses de l’Université du
Québéc, Québéc, 2009
5. ROQUES P., UML 2 : modéliser une application web, éd. Eyrolles, Paris, 2008.
6. ROQUES P., UML 2 par la pratique étude de cas et exercices corrigés, éd. Eyrolles, Paris,
7. VALLEE F., ROQUES P., UML 2 en action : De l’analyse des besoins à la conception,
éd.Eyrolles, Paris, 2007.
INTRODUCTION
Depuis plusieurs décennies, l’informatique a fait d’énormes progrès. Actuellement,
plusieurs technologies informatiques naissent dans le but toujours d’alléger la tâche de l’homme.
Des opérations qui, autrefois prenaient trop de temps, ont vu leur temps d’exécution être réduit
grâce à l’outil informatique, en l’occurrence l’ordinateur. A cet effet, l ‘informatisation est le
phénomène le plus important de notre époque. Elle s’immisce maintenant dans la plupart des
objets de la vie courante et ce, que ce soit dans l’objet proprement dit ou bien dans le processus
de conception de la fabrication de cet objet.
Actuellement, l’informatique est au cœur de toutes les grandes entreprises. Le système

d’information d’une entreprise est composé de matériels et de logiciels. Plus précisément, les
investissements dans ce système d’information se répartissent généralement de la manière
suivante : 20% pour le matériel et 80% pour le logiciel.
0.1. Développement logiciel

Les logiciels sont conçus pour répondre aux besoins des utilisateurs. Mais comme le montre
la figure ci-dessous : Comment passer des besoins au code ?
? CODE
Besoins
Le génie logiciel est la branche de l’informatique pour développer des systèmes d’information
à forte pondération logicielle (et tournant autour d’une base de données). Le génie logiciel
englobe la démarche pour la mise au point d’un logiciel.
Sa démarche est : l’analyse, la conception, le codage et le test.
Dans le développement logiciel, les méthodologies sont une sous-partie du génie logiciel
qui vise à rassembler l’ensemble des méthodes, des techniques et des outils servant à la
production d’un logiciel.
Une méthodologie de développement logiciel doit tenir compte de la création du logiciel à
proprement parler mais aussi de tous les composants relatifs au cycle de vie d’un logiciel. Le
cycle de vie d’un logiciel commence à la définition des objectifs et dure jusqu’à la fin de son
exploitation.
Les méthodologies de développement logiciel peuvent donc être vues comme
l’assemblage de techniques et de méthodes permettant la gestion de toutes les phases du cycle
de développement logiciel.
Une méthodologie de développement logiciel doit être couplée à un outil permettant son
suivi. Les méthodologies sont donc une alternative au développement dit « chaotique » où la
caractéristique principale est « coder et déboguer ». Elles imposent un processus discipliné
permettant de rendre le développement logiciel plus prévisible et plus efficace. Les méthodologies
quant à elles couvrent bien évidemment la modélisation mais aussi tout le cycle de
développement de logiciel.
0.2. Cycles de développement logiciel

Le cycle de développement d’un logiciel ne se résume pas à la seule phase de codage mais
peut être considéré comme toute la période partant de la définition des besoins et allant jusqu’à
l’arrêt de l’exploitation du logiciel. Mais dans tous les cas de figure, certaines phases sont
inévitables :
1. Expression des besoins : Description informelle des besoins exprimés par l’utilisateur.
Cela permet de définir le cahier des charges.
2. Spécification : Description formelle du problème par l’équipe de développement.
Cela permet de définir le quoi en fonction du cahier des charges.
3. Analyse et conception : Recherche de solutions tenant compte de l’architecture
technique. Cela permet de définir le comment. La conception est souvent découpée en
deux phases : la conception préliminaire et la conception détaillée. La conception
détaillée représente la conception du système global, composant par composant.
4. Implémentation : Production du code en se référant à l’analyse et la conception mais
sans avoir besoin de remettre ceux-ci en question. Permet aussi la mise en place des
tests unitaires.
5. Test/recette : Validation par le client des fonctionnalités du système.
6. Déploiement/maintenance.
Souvent, certaines de ces activités sont regroupées, mais elles sont toujours présentes et se
déroulent presque toujours dans l’ordre précité. L’ordre est souvent respecté mais cela
n’empêche pas d’organiser le déroulement de ces phases de nombreuses manières. Les deux
grandes familles d’organisation sont les cycles séquentiels et les cycles itératifs.
* Cycle en cascade (séquentiel)

C’est l’un des premiers modèles apparu en 1966 et formalisé aux alentours de 1970 par W.
Royce. Il est issu de la construction du bâtiment où les fondations sont construites avant le reste
de la maison. Les activités y sont exécutées les unes après les autres de manière
totalement successive. Dans sa version de base ce modèle était basé sur le principe de non
retour.
Avantages :
· Modèle simple
· Tests entre chaque phase
· Gestion des phases en temps et ressources
· Définition des tâches et des livrables
Inconvénients :
· Effet tunnel (identification tardive des problèmes, preuve tardive du bon fonctionnement).
· Difficulté de cerner les besoins dès le début, refus de tout changement.
· Frustration de l’attente de la première version (lenteur).
· Les projets informatiques sont rarement séquentiels.
* Cycle en V (séquentiel)
Mc Dermid et Ripkin proposèrent ce modèle en 1984. Il découle d’une amélioration du modèle en
cascade où chaque phase du projet a une phase de test qui lui est associée. Cette association
découle de l’idée que chaque phase en amont du développement doit préparer une phase
correspondante de vérification en aval de la production du logiciel.
Elle est basée sur les deux approches (Top-Down et Bottom-Up). Dans les premières phases
descendantes, on décompose le projet pour faciliter la partie développement (Top-Down). Tandis
que dans les secondes phases, on recompose l’ensemble du logiciel en le testant du détail vers
l’ensemble (Bottom-Up).
Avantages
· Réactivité accrue vis-à-vis du modèle en cascade (évite d’énoncer une propriété non vérifiable
objectivement une fois le logiciel réalisé).
· Modèle industriel classique éprouvé.
· Validation systématique de chaque étape avec retour en arrière possible.
· Mise en place de la vérification lors de la conception obligeant à une réflexion supplémentaire
très utile.
Inconvénients
· Pas de prototypage (code/validation tardive) et risque d’effet tunnel.
· Prise en compte des modifications du cahier des charges difficile.
· Obligation de définir la totalité des besoins au départ.
· Projet rarement séquentiel
* Cycle incrémental
Le principe de base du modèle par incréments est de découper l’expression des besoins
en sous-parties (lots ou incréments). Chaque lot sera réalisé successivement ou en se
chevauchant selon un modèle en cascade ou en V.
Avantages
· Diminution de la durée d’un cycle et donc de l’effet tunnel.
· Diminution de la complexité (vision uniquement d’un incrément).
· Les intégrations sont progressives par incrémentation.
Inconvénients :
· Difficulté de l’intégration
· Difficulté de la conception globale
· Inadapté aux besoins d’évolution en cours de projet, problème en cas de remise en cause du
noyau.
* Cycle en spirale (incrémental)

Ce modèle a été proposé par Barry W. Boehm en 1988. Il reprend les différentes étapes
du cycle en V. Il est basé sur des incréments. Par l'implémentation de versions successives (une
version par cycle), le cycle recommence en proposant un produit de plus en plus complet. Chaque
nouvelle phase permet d’ajuster ce qui a déjà été réalisé durant le cycle précédent et d’ajouter
de nouvelles fonctionnalités. Il est grandement basé sur une analyse des risques pouvant à tout
moment remettre en cause le développement.
Avantages
· Retour plus tôt sur l’avancée du projet donc meilleure estimation des budgets
· Gestion du changement (les besoins sont affinés à chaque cycle)
· Mise en œuvre d’une analyse des risques.
Inconvénient
· Les cycles peuvent être indépendants les uns des autres, ce qui peut provoquer un big-bang
lors de l’intégration.
* Cycle itératif
Le principe de base du modèle itératif est assez simple, à chaque nouveau besoin un
cycle de type « roue de Deming » est appliqué. La roue de Deming représente le principe « Plan
Do Check Ack » (PDCA). Ce cycle est effectué de manière itérative où à chaque itération sont
présentes : l’étude de la faisabilité, l’élaboration, la fabrication et la livraison. L’idée principale
étant de pouvoir livrer au plus tôt une version qui puisse être testée par le client. Donc les
itérations se doivent d’être les plus courtes possibles. Puis à chaque nouvelle itération les
nouveaux besoins sont examinés et les erreurs de l’itération précédente sont corrigées. Cela
signifie que la version livrée au client n’est pas une version finale et qu’il peut manquer beaucoup
de fonctionnalités mais il a au moins la possibilité de vérifier et de valider rapidement.
Avantages
· Adaptation au changement (retour plus rapide)
· Prototype (plus simple de voir que de lire de la documentation)
· Plus forte intégration du client (meilleure expression des besoins)
· Motivation de l’équipe par des objectifs proches
Inconvénient
Difficulté de traiter les gros projets : possibilité d’erreur dans la conception et refactoring difficile
0.3. Système d'information d'entreprise

La décomposition d'une Entreprise en sous-systèmes permet de situer son système d'information
de la manière suivante :
Cette présentation du système d'information peut être discutée :

- il est défini par différence, "coincé" entre 2 autres sous-systèmes, pilotage et opérant. Or, il
existe des systèmes d'information de pilotage (aide à la décision) ainsi que des systèmes
d'information de l'opérant.
- il ne rend pas compte de l'aspect représentation, pourtant essentiel dans la notion d'information,
ce qui expliquerait que différentes vues puissent cohabiter.
- En tout état de cause, un système d'information est plus qu'un système informatique avec
lequel il ne doit pas être confondu
0.3.1. Système d’information et Système informatique

C’est une erreur couramment commise que de considérer les termes informatique et
système d’information comme étant des synonymes.
L’angle de vue système d’information est celui du manager, qui a des besoins de
traitement de données et qui est en position de maîtrise d’ouvrage ou client.
A l’opposé, l’angle de vue informatique est celui de la maîtrise d’œuvre ou fournisseur, qui offre
des outils techniques (biens et services), qui doivent être capables de satisfaire les besoins de la
maîtrise d’ouvrage.
Ce concept de système d’information, loin d’être né avec l’informatique, a son origine dans
un courant de pensée de la systémique.
Un système d’information peut être défini comme « la partie du réel constituée d’informations
organisées et d’acteurs qui agissent sur ces informations ou à partir de ces informations, selon
des processus visant une finalité de gestion et utilisant les technologies de l’information ».
Un système informatique est « un ensemble organisé d’objets techniques – matériels,
logiciels, applicatifs – qui représente l’infrastructure d’un système d’information ».
Patrick KASONGA, Cours de Conception des systèmes d’informations avec UML, G2 ESIS 2016-2017 P a g e | 10
Système d’informations
Acteurs Informations
Processus
s
S’appuie sur Permet
Système informatique
Matériels Logiciels
Applicatifs
0.3.2. Pourquoi modéliser ?

Le recours à la modélisation est depuis longtemps une pratique indispensable au
développement logiciel, car un modèle est prévu pour arriver à anticiper les résultats du codage.
Un modèle est en effet une représentation abstraite d’un système destiné à en faciliter l’étude et
à le documenter.
C’est un outil majeur de communication entre les différents intervenants au sein d’un
projet. Chaque membre de l’équipe, depuis l’utilisateur jusqu’au développeur, utilise et enrichit le
modèle différemment.
En outre, les systèmes devenant de plus en plus complexes, leur compréhension et leur
maîtrise globale dépassent les capacités d’un seul individu. La construction d’un modèle abstrait
aide à y remédier. Le modèle présente notamment l’atout de faciliter la traçabilité du système, à
savoir la possibilité de partir d’un de ses éléments et de suivre ses interactions et liens avec
d’autres parties du modèle.
Associé au processus de développement, un modèle représente l’ensemble des vues sur
une expression de besoins ou sur une solution technique. Pris à un niveau de détail pertinent, il
décrit ou conçoit la cible de l’étape en cours. Le modèle sert donc des objectifs différents suivant
l’activité de développement et sera construit avec des points de vue de plus en plus détaillés :
• Dans les activités de spécification des exigences, il convient premièrement de considérer le
système comme une boîte noire à part entière afin d’étudier sa place dans le système métier plus
global qu’est l’entreprise. On développe pour cela un modèle de niveau contexte, afin de tracer
précisément les frontières fonctionnelles du système.
• Dans les activités d’analyse, le modèle commence à représenter le système vu de l’intérieur. Il
se compose d’objets représentant une abstraction des concepts manipulés par les utilisateurs.
Le modèle comprend par ailleurs deux points de vue, la structure statique et le comportement
dynamique. Il s’agit de deux perspectives différentes qui aident à compléter la compréhension du
système à développer.
• Dans les activités de conception, le modèle correspond aux concepts informatiques qui sont
utilisés par les outils, les langages ou les plates-formes de développement. Le modèle sert ici à
étudier, documenter, communiquer et anticiper une solution. Il est en effet toujours plus rentable
de découvrir une erreur de conception sur un modèle, que de la découvrir au bout de milliers de
lignes codées sans méthode. Pour la conception du déploiement enfin, le modèle représente
également les matériels et les logiciels à interconnecter.
Le modèle en tant qu’abstraction d’un système s’accorde parfaitement bien avec les
concepts orientés objet. Un objet peut en effet représenter l’abstraction d’une entité métier utilisée
en analyse, puis d’un composant de solution logicielle en conception. La correspondance est
encore plus flagrante lorsque les langages de développement sont eux-mêmes orientés objet.
Cela explique le succès de la modélisation objet ces dernières années pour les projets de plus
en plus nombreux utilisant C++, Java ou C#.
Chapitre II : LE LANGAGE UML

Pour faire face à la complexité croissante des systèmes d’information, de nouvelles
méthodes et outils ont été créées. La principale avancée des quinze dernières années réside
dans la programmation orientée objet (P.O.O.). Face à ce nouveau mode de programmation,
les méthodes de modélisation classique (telle MERISE) ont rapidement montré certaines
limites et ont dû s’adapter (cf. MERISE/2).
II.1. Historique
Les méthodes utilisées dans les années 1980 pour organiser la programmation impérative
(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
apparaissent 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 de James Rumbaugh (General Electric) fournit une représentation graphique des aspects
statique, dynamique et fonctionnel d’un système ;
– OOD de Grady Booch, définie pour le Department of Defense, introduit le concept de paquetage
(package) ;
– OOSE d’Ivar Jacobson (Ericsson) fonde l’analyse sur la description 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 gourous qui régnaient
chacun sur l’une des trois méthodes se mirent d’accord pour définir une méthode commune qui
fédérerait leurs apports respectifs (on les surnomme depuis « the Amigos »). UML (Unified
Modeling Language) est né de cet effort de convergence. L’adjectif unified est là pour marquer
qu’UML unifie, et donc remplace.
En fait, et comme son nom l’indique, UML n’a pas l’ambition d’être exactement une méthode : c’est
un langage.
L’unification a progressé par étapes. 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 (notez le remplacement du mot méthode par le mot langage).
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’OMG. L’OMG adopte
en novembre 1997 UML 1.1 5 comme langage de modélisation des systèmes d’information à
objets.
La version d’UML en cours à la fin 2006 est UML 2.0 et les travaux d’amélioration se
poursuivent. UML est donc non seulement un outil intéressant, mais 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.
II.2. Présentation d’UML
Issu du terrain et fruit d'un travail d'experts reconnus, UML est le résultat d'un large
consensus. De très nombreux acteurs industriels de renom ont adopté UML et participent à
son développement. En l'espace d'une poignée d'années seulement, UML est devenu un
standard incontournable.
UML, ainsi que les méthodes dont il est issu, s'accordent sur un point : une analyse objet
passe par une modélisation objet.
UML permet donc de modéliser une application selon une vision objet.
L’appréhension d’UML est complexe car UML est à la fois :

- une norme,
- un langage de modélisation objet,
- un support de communication,
- un cadre méthodologique.
UML est une norme

Fin 1997, UML est devenu une norme OMG (Object Management Group).
L'OMG est un organisme à but non lucratif, créé en 1989 à l'initiative de grandes sociétés
(HP, Sun, Unisys, Oracle, American Airlines, Philips...). 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.
UML est un langage de modélisation objet

Pour penser et concevoir objet, il faut savoir "prendre de la hauteur", jongler avec des
concepts abstraits, indépendants des langages d'implémentation et des contraintes purement
techniques. Les langages de programmation ne sont pas un support d'analyse adéquat pour
"concevoir objet". Ils ne permettent pas de décrire des solutions en termes de concepts
abstraits et constituent un cadre trop rigide pour mener une analyse itérative.
Pour conduire une analyse objet cohérente, il ne faut pas directement penser en terme
de pointeurs, d'attributs et de tableaux, mais en terme d'association, de propriétés et de
cardinalités...
L’approche objet nécessite une analyse réfléchie, qui passe par différentes phases
exploratoires. Bien que raisonner en terme d'objets semble naturel, l'approche fonctionnelle
reste la plus intuitive pour nos esprits cartésiens... Voilà pourquoi il ne faut pas se contenter
d'une implémentation objet, mais se discipliner à "penser objet" au cours d'une phase
d'analyse préalable.
UML comble une lacune importante des technologies objet. Il permet d'exprimer et d'élaborer
des modèles objet, indépendamment de tout langage de programmation. Il a été pensé pour
servir de support à une analyse basée sur les concepts objet.
UML est un langage formel, défini par un métamodèle .
Le métamodèle d'UML décrit de manière très précise tous les éléments de modélisation
(les concepts véhiculés et manipulés par le langage) et la sémantique de ces éléments
(leur définition et le sens de leur utilisation).
En d'autres termes, UML normalise les concepts objet.
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.
La notation graphique d'UML n'est que le support du langage. La véritable force d'UML,
c'est qu'il repose sur un métamodèle. En d'autres termes : la puissance et l'intérêt d'UML, c'est
qu'il normalise la sémantique des concepts qu'il véhicule !
Le métamodèle UML apporte une solution à ce problème fondamental. UML est donc bien plus
qu'un simple outil qui permet de "dessiner" des représentations mentales... Il permet de
parler un langage commun, normalisé mais accessible, car visuel.
UML est un cadre méthodologique pour une analyse objet

Une autre 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.
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.
UML opte en effet pour l'élaboration des modèles, plutôt que pour une approche qui impose
une barrière stricte entre analyse et conception. Les modèles d'analyse et de conception
ne diffèrent que par leur niveau de détail, il n'y a pas de différence dans les concepts
utilisés.
UML permet donc non seulement de représenter et de manipuler les concepts objet, il sous-
entend une démarche d'analyse qui permet de concevoir une solution objet de manière itérative,
grâce aux diagrammes, qui supportent l'abstraction.
UML n'est pas une méthode !

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. 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 est juste un langage graphique et textuel et
non une succession d’étapes de modélisation.
On peut tout de même recourir à un processus ou une démarche basée sur la notation UML, mais
cette démarche doit être :
- guidée par les besoins des utilisateurs du système,
- centrée sur l'architecture logicielle,
- itérative et incrémentale.
1. 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 besoins des utilisateurs servent aussi de fil rouge, tout au long du cycle de
développement :
- à 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.
2. Centrée sur l’architecture

L’architecture est conçue pour satisfaire les besoins exprimés par les utilisateurs, mais
aussi pour prendre en compte les évolutions futures liées aux changements technologiques et
systémiques et les contraintes de réalisation. La mise en place d’une architecture adaptée
conditionne le 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é...).
Ph. Kruchten propose différentes perspectives, indépendantes et complémentaires, qui

permettent de définir un modèle d'architecture (publication IEEE, 1995).
Cette vue ("4+1") a fortement inspiré UML :
 La vue logique
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.
o Elle 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).
o 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...
 La vue des composants

Cette vue de bas niveau (aussi appelée "vue de réalisation"), montre :
o L'allocation des éléments de modélisation dans des modules (fichiers sources,
bibliothèques dynamiques, bases de données, etc...).
o En d'autres termes, cette vue identifie les modules qui réalisent (physiquement)
les classes de la vue logique.
o L'organisation des composants, c'est-à-dire la distribution du code en gestion de
configuration, les dépendances entre les composants...
o Les contraintes de développement (bibliothèques externes...).
o La vue des composants montre aussi 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).
 La vue des processus

Cette vue est très importante dans les environnements multitâches ; elle montre :
o La décomposition du système en terme de processus (tâches).
o Les interactions entre les processus (leur communication).
o La synchronisation et la communication des activités parallèles (threads).
 La vue de déploiement
Cette vue très importante dans les environnements distribués, décrit les ressources
matérielles et la répartition du logiciel dans ces ressources :
o La disposition et la nature physique des matériels, ainsi que leurs performances.
o L'implantation des modules principaux sur les nœuds du réseau.
o Les exigences en termes de performances (temps de réponse, tolérance aux
fautes et pannes...).
 La vue des besoins des utilisateurs

Cette vue (dont le nom exact est "vue des cas d'utilisation"), guide toutes les autres.
o Dessiner le plan (l'architecture) d'un système informatique n'est pas suffisant, il
faut le justifier!
o Cette vue définit les besoins des clients du système et centre la définition de
l'architecture du système sur la satisfaction (la réalisation) de ces besoins.
o A l'aide de scénarios et de cas d'utilisation, cette vue conduit à la définition d'un
modèle d'architecture pertinent et cohérent.
o Cette vue est la "colle" qui unifie les quatre autres vues de l'architecture.
o Elle motive les choix, permet d'identifier les interfaces critiques et force à se
concentrer sur les problèmes importants.
3. Itérative et incrémentale
Une itération prend en compte un certain nombre de cas d'utilisation et traite en priorité
les risques majeurs.
Qu'est-ce qu'une démarche itérative et incrémentale ?
 L'idée est simple : 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 devrait 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.
D'après les auteurs d'UML, un processus de développement qui possède ces qualités
fondamentales "devrait" favoriser la réussite d'un projet.
UML permet tout à fait de modéliser les activités (c'est-à-dire la dynamique) d'un processus, de
décrire le rôle des acteurs du processus, la structure des éléments manipulés et produits, etc...
II.3. Les diagrammes UML

UML 2 s’articule autour de treize types de diagrammes, chacun d’eux étant dédié à la
représentation des concepts particuliers d’un système logiciel. Ces types de diagrammes sont
répartis en deux grands groupes :
a) Six diagrammes structurels ou statiques :

– Diagramme de classes : Il montre les briques de base statiques : classes, associations,
interfaces, attributs, opérations, généralisations, etc.
– Diagramme d’objets : Il montre les instances des éléments structurels et leurs liens à
l’exécution.
– Diagramme de packages : Il montre l’organisation logique du modèle et les relations entre
packages.
– Diagramme de structure composite : Il montre l’organisation interne d’un élément statique
complexe.
– Diagramme de composants : Il montre des structures complexes, avec leurs interfaces
fournies et requises.
– Diagramme de déploiement : Il montre le déploiement physique des « artefacts » sur les
ressources matérielles.
b) Sept diagrammes comportementaux ou dynamiques :

– Diagramme de cas d’utilisation : Il montre les interactions fonctionnelles entre les acteurs et
le système à l’étude.
– Diagramme de vue d’ensemble des interactions : Il fusionne les diagrammes d’activité et de
séquence pour combiner des fragments d’interaction avec des décisions et des flots.
– Diagramme de séquence : Il montre la séquence verticale des messages passés entre objets
au sein d’une interaction.
– Diagramme de communication : Il montre la communication entre objets dans le plan au sein
d’une interaction.
– Diagramme de temps : Il fusionne les diagrammes d’états et de séquence pour montrer
l’évolution de l’état d’un objet au cours du temps.
– Diagramme d’activité : Il montre l’enchaînement des actions et décisions au sein d’une activité.
– Diagramme d’états-transitions : Il montre les différents états et transitions possibles des
objets d’une classe.
Le diagramme de cas d’utilisation est utilisé dans l’activité de spécification des besoins. Il
montre les interactions fonctionnelles entre les acteurs et le système à l’étude.
Le diagramme de classes est le point central dans un développement orienté objet.

En analyse, il a pour objet de décrire la structure des entités manipulées par les utilisateurs.
En conception, le diagramme de classes représente la structure d’un code orienté objet.
Le diagramme de packages montre l’organisation logique du modèle et les relations entre
packages. Il permet de structurer les classes d’analyse et de conception, mais aussi les cas
d’utilisation.
Les diagrammes de séquence et les diagrammes de communication sont tous deux des
diagrammes d’interactions UML.
Ils représentent des échanges de messages entre éléments, dans le cadre d’un fonctionnement
particulier du système. Les diagrammes de séquence servent d’abord à développer en analyse
les scénarios d’utilisation du système. Plus tard, les diagrammes de séquence et de
communication permettent de concevoir les méthodes des classes.
Le diagramme d’états-transitions représente le cycle de vie commun aux objets d’une même
classe. Ce diagramme complète la connaissance des classes en analyse et en conception en
montrant les différents états et transitions possibles des objets d’une classe à l’exécution.
Le diagramme d’activité représente les règles d’enchaînement des actions et décisions au sein
d’une activité. Il peut également être utilisé comme alternative au diagramme d’états pour décrire
la navigation dans un site web.
Le diagramme d’objets est un instantané, une photo d’un sous-ensemble des objets d’un
système à un certain moment du temps.
C’est probablement le diagramme le moins utilisé d’UML et nous n’en verrons pas d’illustration.
Le diagramme de composants montre les unités logicielles à partir desquelles on a construit le

système informatique, ainsi que leurs dépendances.
Le diagramme de déploiement montre le déploiement physique des artefacts (éléments

concrets tels que fichiers, exécutables, etc.) sur les ressources matérielles.
Le diagramme de vue d’ensemble des interactions fusionne les diagrammes d’activité et de
séquence pour combiner des fragments d’interaction avec des décisions et des flots.
Le diagramme de temps fusionne les diagrammes d’états et de séquence pour montrer

l’évolution de l’état d’un objet au cours du temps et les messages qui modifient cet état.
Le diagramme de structures composites montre l’organisation interne d’un élément statique

complexe sous forme d’un assemblage de parties, de connecteurs et de ports.
L’ensemble des treize types de diagrammes UML peut ainsi être résumé sur la figure ci-après.
CHAPITRE III : ETUDE DE QUELQUES DIAGRAMMES UML
III.1. DIAGRAMME DES CAS D’UTILISATION
Le diagramme de cas d’utilisation permet de recueillir, d’analyser et d’organiser les

besoins, et de recenser les grandes fonctionnalités d’un système. Il modélise les services rendus
par le système aux utilisateurs. Il met en évidence ce que l’utilisateur peut faire l’utilisateur par
rapport au système.
Les cas d’utilisation permettent de structurer les besoins des utilisateurs et les objectifs
correspondants d'un système. Ils centrent l'expression des exigences du système sur ses
utilisateurs. Ils identifient les utilisateurs du système (acteurs) et leurs interactions avec le
système.
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.
Les cas d’utilisation permettent donc d’exprimer le besoin des utilisateurs d’un système, ils sont
donc une vision orientée utilisateur de ce besoin.
III.1.1. Concepts de base
a) Acteur
Un acteur est un rôle joué par une personne externe, un processus ou une chose qui interagit avec
un système. Ce n’est pas nécessairement une personne physique : il peut être un service,
une société, un système informatique …
Il se représente par un petit bonhomme avec son nom (i.e. son rôle) inscrit dessous.
ou
Il est également possible de représenter un acteur sous la forme d’un classeur stéréotypé «Actor».
Dans UML, il n’y a pas de notion d’acteur interne et externe. Par définition, un acteur est toujours
externe au périmètre de l’étude, qu’il appartienne ou pas à l’entreprise.
b) Cas d’utilisation
Un cas d’utilisation est une unité cohérente d’une fonctionnalité visible de l’extérieur. Il
réalise un service de bout en bout, avec un déclenchement, un déroulement et une fin, pour l’acteur
qui l’initie. Un cas d’utilisation modélise donc un service rendu par le système, sans imposer le
mode de réalisation de ce service.
Un cas d’utilisation se représente par une ellipse contenant le nom du cas (un verbe à
l’infinitif), et optionnellement, au-dessus du nom, un stéréotype.
c) Représentation d’un diagramme de cas d’utilisation
La frontière du système est représentée par un cadre appelé « Borne interactive du système ». Le
nom du système figure à l’intérieur du cadre, en haut. Les acteurs sont à l’extérieur et les cas
d’utilisation à l’intérieur.
System
Passer commande
CLIENT
Payer facture
Etablir facture
FACTURATION
Vérifier stock
Valider facture
CAISSE
II.1.2. Relations entre acteurs et cas d’utilisation

La relation entre un acteur et un cas d’utilisation est l’association. Une relation d’association
est le chemin de communication entre un acteur et un cas d’utilisation et est représentée par un
trait continu.
II.1.3. Relations entre les cas d’utilisation

Il existe principalement deux types de relations :
– les dépendances stéréotypées, qui sont explicitées par un stéréotype (l’inclusion et l’extension),
– et la généralisation/spécialisation.
Une dépendance se représente par une flèche avec un trait pointillé. Le symbole utilisé
pour la généralisation est une flèche avec un trait plein dont la pointe est un triangle fermé
désignant le cas le plus général.
a) Relation d’inclusion
Une relation d’inclusion est une dépendance entre deux cas d’utilisation symbolisée par le
stéréotype « include ».
Un cas d’utilisation A inclut un cas d’utilisation B si l’exécution du cas A nécessite d’abord
l’exécution du cas B : le cas A dépend de B. Lorsque A est sollicité, B l’est obligatoirement, comme
une partie de A.
Par exemple, l’accès aux e-mails d’un compte de messagerie inclut nécessairement une phase
d’authentification avec un login et un mot de passe.
Les inclusions permettent essentiellement de factoriser une partie de la description d’un
cas d’utilisation qui serait commune à d’autres cas d’utilisation. Elles permettent également de
décomposer un cas complexe en sous-cas plus simples.
Notez également que les cas d’utilisation ne s’enchaînent pas, car il n’y a aucune représentation
temporelle dans un diagramme de cas d’utilisation.
<<include>>
Consulter e-mail s'authentifier
b) Relation d’extension
La relation d’extension est une dépendance entre deux cas d’utilisation symbolisée par le
stéréotype « extend ».
On dit qu’un cas d’utilisation A étend un cas d’utilisation B lorsque le cas d’utilisation A peut être
appelé au cours de l’exécution du cas d’utilisation B. Exécuter B peut éventuellement entraîner
l’exécution de A. L’extension indique que le cas d’utilisation A peut ajouter son comportement
au cas d’utilisation B : contrairement à l’inclusion, l’extension est optionnelle.
L’extension peut intervenir à un point précis du cas étendu. Ce point s’appelle le point d’extension.
Une extension est souvent soumise à une condition exprimée sous la forme d’une note.
<<extend>>
Consulter résultats Introduire recours
c) Relation de généralisation
La généralisation est une relation non stéréotypée déterminée par une flèche en trait plein
pointant vers le cas général. Un cas A est une généralisation d’un cas B si B est un cas particulier
de A. Par exemple, le paiement d’un article par carte de crédit est un cas particulier du paiement
de cet article. Cette relation de généralisation/spécialisation est présente dans la plupart des
diagrammes UML et se traduit par le concept d’héritage dans les langages orientés objet.
Payer facture
Payer au comptant Payer par carte de crédit

II.1.4. Relations entre 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.
ouvrir session
Utilisateur
Signaler panne
Activer compte utilisateur
Admin
II.1.5. Description textuelle des cas d’utilisation

Le diagramme de cas d’utilisation décrit les grandes fonctions d’un système du point de vue des
acteurs, mais n’expose pas de façon détaillée le dialogue entre les acteurs et les cas d’utilisation.
Bien que de nombreux diagrammes d’UML permettent de décrire un cas, il est recommandé de
rédiger une description textuelle car c’est une forme souple qui convient dans bien des situations.
Une description textuelle couramment utilisée se compose de rubriques ci-après :
1. Nom du cas : Utiliser un verbe à l’infinitif (ex : Réceptionner un colis).
2. Objectif du cas : c’est l’intention principale du cas d’utilisation.
3. Acteur principal : c’est l’acteur qui réalise le cas d’utilisation
4. Acteur (s) secondaire (s) : ce sont ceux qui ne font que recevoir des informations à l’issue de
la réalisation du cas d’utilisation
5. Les préconditions : elles décrivent dans quel état doit être le système (l’application) avant la
réalisation du cas d’utilisation
6. Des scénarii (scenarios) : Ces scénarios sont décrits sous la forme d’échanges d’évènements
entre l’acteur et le système. On distingue :
- le scénario nominal, qui se déroule normalement quand il n’y a pas d’erreur,
- des scénarios alternatifs qui sont les variantes du scénario nominal et enfin
- les scénarios d’exception qui décrivent les cas d’erreurs.
7. Des postconditions : Elles décrivent l’état du système à l’issue des différents scénarios.
Exemple
1. Nom du cas : Etablir facture
2. Objectif du cas : matérialiser la commande d’un client
3. Acteur principal : Facturation
4. Acteurs secondaires : Client et Caisse
5. Préconditions : Commande passée et Stock disponible
6. Des scénarii (scenarios) :
- le scénario nominal :
* saisir nom client
* sélectionner produit et saisir quantité
* valider
- des scénarios alternatifs :
* annuler facture
* modifier facture
- scénario d’exception : afficher message d’erreur si la quantité est inférieure ou égale à 0
7. Postcondition : Facture
II.2. DIAGRAMME DE CLASSES

Le diagramme de classes exprime la structure statique du système en termes de
classes et de relations entre ces classes. L’intérêt du diagramme de classe est de modéliser les
entités du système d’information.
Le diagramme de classes 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 est considéré comme le plus important de la modélisation orientée objet,
il est le seul obligatoire lors d’une telle modélisation car tout système orienté objet est organisé
autour des classes. Il montre la structure interne d’une application. Il permet de fournir une
représentation abstraite des objets du système qui doivent interagir ensemble pour réaliser les cas
d’utilisation.
II.2.1. Concepts de base

a) Classe
Une classe est une abstraction d’un ensemble d’objets ayant les mêmes caractéristiques :
elle définit leur structure, leur comportement et leurs relations.
C’est donc un type d’objets ou encore la description formelle d’un ensemble d’objets ayant une
sémantique et des propriétés communes.
Un objet est une instance d’une classe. C’est une entité discrète dotée d’une identité, d’un
état et d’un comportement que l’on peut invoquer. Les objets sont des éléments individuels dç’un
système en cours d’exécution.
Par exemple, Etudiant est une classe, Muvumbi est une instance ou un objet de la classe Etudiant.
b) Représentation graphique d’une classe
Une classe définit un jeu d’objets dotés de propriétés statiques (attributs) et dynamiques
(opérations). Les attributs permettent de spécifier son état et les opérations décrivent son
comportement. Graphiquement, on a :
Nom_classe
Attribut1 : string
Attribut2 : int
…
Operation1() : void
Operation2() : void
…
c) Attribut
Une classe correspond à un concept global d’information et se compose d’un
ensemble d’informations élémentaires, appelées attributs de classe.
Un attribut représente la modélisation d’une information élémentaire représentée par son
nom et son format. Ils représentent les données encapsulées dans les objets de cette classe. Par
commodité de gestion, on choisit parfois de conserver dans un attribut le résultat d’un calcul
effectué à partir d’autres classes : on parle alors d’attribut dérivé. Pour repérer un attribut
dérivé : on place un / devant son nom.
d) Opération ou méthode
L’opération ou méthode 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. Une méthode de classe ne peut manipuler que
des attributs de classe et ses propres paramètres.
II.2.2. Encapsulation et visibilité

L’encapsulation est un mécanisme consistant à rassembler les données et les méthodes
au sein d’une structure en cachant l’implémentation de l’objet, c’est-à-dire en empêchant l’accès
aux données par un autre moyen que les services proposés. Ces services accessibles (offerts)
aux utilisateurs de l’objet définissent ce que l’on appelle l’interface de l’objet (sa vue externe).
L’encapsulation permet donc de garantir l’intégrité des données contenues dans l’objet.
L’encapsulation permet de définir des niveaux de visibilité des éléments d’un conteneur.
La visibilité déclare la possibilité pour un élément de modélisation de référencer un élément qui se
trouve dans un espace de noms différents de celui de l’élément qui établit la référence. Elle fait
partie de la relation entre un élément et le conteneur qui l’héberge, ce dernier pouvant être un
paquetage, une classe ou un autre espace de noms. Il existe quatre visibilités prédéfinies.
- public (+) : l’élément est visible pour tous les clients de la classe
- protégé (#) : l’élément est visible pour les sous-classes de la classe
- privé (-) : l’élément n’est visible que par les objets de la classe dans laquelle il est déclaré.
- package (~) ou rien : seul un élément déclaré dans le même paquetage peut voir l’élément.
II.2.3. Relations entre classes

a) Généralisation
La généralisation décrit une relation entre une classe générale (superclasse ou classe
parent ou classe générique) et une classe spécialisée (sous-classe ou classe fille). La classe
spécialisée est intégralement cohérente avec la classe de base, mais comporte des informations
supplémentaires (attributs, opérations, associations). Un objet de la classe spécialisée peut être
utilisé partout où un objet de la classe de base est autorisé.

Dans le langage UML, ainsi que dans la plupart des langages objet, cette relation de
généralisation se traduit par le concept d’héritage. On parle également de relation d’héritage.
Le symbole utilisé pour la relation d’héritage ou de généralisation est une flèche avec un trait plein
dont la pointe est un triangle fermé désignant le cas le plus général.
PERSONNE
ETUDIANT PROF
b) Association
Une association est une relation entre deux classes (association binaire) ou plus
(association n-aire), qui décrit les connexions structurelles entre leurs instances.
Une association binaire est représentée par un trait continu avec ou sans nom sur
l’association, une association n-aire a pour symbole un losange.
CLIENT FACTURE
II.2.4. Multiplicité ou cardinalité

La multiplicité, appelée aussi cardinalité, représente le minimum et le maximum de fois
qu’une instance de classe participe à l’association. Autrement dit, elle définit le nombre
d’instances de l’association pour une instance de la classe. Elle est définie par un nombre
entier ou un intervalle de valeurs. En UML, la multiplicité est placée à l’envers par rapport à
MERISE. Voici ces multiplicités :
– exactement un : 1 ou 1..1 CLIENT FACTURE
1 1..*
– plusieurs : * ou 0..* -idcl -numfac
-nomcl -datefac
– au moins un : 1..* -telcl
– au plus un : 0..1
II.2.5. Navigabilité
La navigabilité indique s’il est possible de traverser une association. On représente
graphiquement la navigabilité par une flèche du côté de la terminaison navigable et on empêche
la navigabilité par une croix du côté de la terminaison non navigable. Par défaut, une association
est navigable dans les deux sens.
.
II.2.6. Classe-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.
Dans ce cas, on dit que cette association est porteuse de propriétés et ces propriétés seront
placées dans une classe-association représentée par un rectangle suspendu à l’association par
des pointillés.
PRODUIT
FACTURE
* 1..* -codeprod
-numfac -nomprod
-datefac -prixunit
-stockprod
DETAIL
-quantite
II.2.7. Associations particulières entre classes

a) L’agrégation
Une agrégation est une association qui représente une relation d’inclusion structurelle ou
comportementale d’un élément dans un ensemble. Graphiquement, on ajoute un losange vide (
) du côté de l’agrégat.
b) La composition
La composition, également appelée agrégation composite, décrit une contenance
structurelle entre instances. Ainsi, la destruction de l’objet composite implique la destruction de
ses composants. Une instance de la partie appartient toujours à au plus une instance de l’élément
composite. Graphiquement, on ajoute un losange plein ( ) du côté de l’agrégat.
ENTREPRISE CAMION MOTEUR
II.2.8. Types de diagrammes de classes

Il existe 3 types de diagrammes de classes :
- Le diagramme de classes du domaine appelé simplement modèle du domaine
- Le diagramme de classes participantes
- Le diagramme de classes de conception
a) Le modèle du domaine
C’est un diagramme de classes qui modélise les concepts-clés du domaine étudié. Il s’agit de
l’ensemble des objets qui concourent à la réalisation des activités du métier du domaine ;
c’est la structure interne du domaine qui conduira à la création de la base de données ou des
fichiers. C’est donc une première version du diagramme de classes qui est établie comme suit :
- Identifier les concepts ou entités du domaine en tant que classes
- Y rattacher des attributs
- Ajouter les associations et les multiplicités
- Simplifier le modèle en utilisant l’héritage
- Structurer éventuellement les classes en paquetages selon les principes de cohérence
et d’indépendance.
PRODUIT
FACTURE CATEGORIE
* 1..* -codeprod 1..* 1
-numfac -nomprod -codecat
-datefac -prixunit -nomcat
-nomcli -stockprod
DETAIL
-quantite
b) Le diagramme de classes participantes

Le modèle du domaine doit être indépendant des utilisateurs et des interfaces graphiques.
Ainsi, l’application doit être découpée en couches : Présentation, Logique applicative et Données.
Le diagramme de classes participantes modélise justement l’ensemble de classes d’analyse qui
concourent à la réalisation d’un cas d’utilisation. Ces 3 types de classes d’analyse sont :
- Les classes de dialogues : elles représentent les interactions entre les utilisateurs et les
IHM (Interfaces Homme-Machine). Il y a au moins un dialogue pour une association entre
un acteur et un cas d’utilisation.
- Les classes de contrôles : elles modélisent la cinématique ou le métier ou encore la
logique applicative de l’application pour manipuler les informations détenues par un objet
métier et font la jonction entre les dialogues et les entités.
- Les classes Entités : elles sont persistantes en ce sens qu’elles survivent à l’exécution
des cas d’utilisation. Elles proviennent du modèle du domaine et permettent le stockage
des données dans des fichiers ou dans des bases de données.
Exemple : Cas d’utilisation « Etablir facture »
Entité CLIENT
-numclient
Dialogue Etablir facture -nomclient
-telclient
-numfac
-datefac Ctrl Etablir Facture
-nomclient
-nomprod +Créer() Entité FACTURE
-prixunit +modifier()
-quantite +afficher() -numfac
+annuler() -datefac
+créer()
+modifier()
+afficher()
+annuler() DETAIL
-quantite
Entité PRODUIT
-codeprod
-nomprod
-prixunit
-stockprod
c) Le diagramme de classes de conception

Il s’agit de la dernière version du diagramme de classes qui servira à l’implémentation de
l’application. Dans ce diagramme, on modélise tous les objets nécessaires à la mise en œuvre
de l’application en ajoutant aussi les opérations. Il faut garder à l’esprit qu’il sied de garder un
couplage faible, c’est-à-dire un nombre faible de classes auxquelles une classe est connectée
afin d’obtenir une application plus évolutive et plus facile à maintenir.
II.3. LE DIAGRAMME D’ACTIVITES

Le diagramme d’activités est un diagramme comportemental qui modélise
particulièrement le cheminement des flots de contrôle et de flots de données de toute l’activité.
Il permet de décrire l’enchaînement des cas d’utilisation. Il peut comporter des synchronisations
pour représenter les déroulements parallèles.

a) Action
Une action est le plus petit traitement qui puisse être exprimé en UML et a une incidence
sur l’état du système ou en extrait une information. Il peut s’agir par exemple de la création d’un
nouvel objet, l’émission ou la réception d’un signal, l’affectation de valeur à un attribut, etc.
b) Activité
Une activité définit un comportement décrit par un séquencement organisé d’unités dont
les éléments simples sont les actions. Le flot d’exécution est modélisé par des nœuds reliés par
des arcs (appelés transitions).
c) Nœuds d’activités
Un nœud d’activité est un type d’élément abstrait permettant de représenter les étapes le
long du flot d’une activité. Il existe trois familles de nœuds d’activités :
– les nœuds d’exécutions (ou nœuds exécutables);
– Les nœuds de contrôles

– les nœuds objets ;
c1. Les nœuds d’exécution

Il s’agit de :
- nœud d’action
- nœud d’activité structurée
* Nœud d’action
Un nœud d’action est un nœud d’activité exécutable qui modélise une action comme une
unité fondamentale de fonctionnalité exécutable dans une activité.
Graphiquement, un nœud d’action est représenté par un rectangle aux coins arrondis qui contient
sa description textuelle.
Passer commande Saisir facture
Le passage d’une action à une autre est appelé Transition et est représenté par une flèche.
* Nœud d’activité structurée

Un nœud d’activité structurée est un nœud d’activité exécutable qui représente une portion
structurée d’une activité donnée qui n’est partagée avec aucun autre nœud structuré, à l’exception
d’une imbrication éventuelle.
C2. Nœud de contrôle

Un nœud de contrôle est un nœud d’activité abstrait utilisé pour coordonner les flots entre
les nœuds d’une activité.
Il existe plusieurs types de nœuds de contrôle :
– nœud initial
– nœud de fin d’activité
– nœud de fin de flot
– nœud de décision
– nœud de fusion
– nœud de bifurcation
– nœud d’union
* Nœud initial
Un nœud initial est un nœud de contrôle à partir duquel le flot débute lorsque l’activité
enveloppante est invoquée. Une activité peut avoir plusieurs nœuds initiaux. Un nœud initial
possède un arc sortant et pas d’arc entrant.
Graphiquement, un nœud initial est représenté par un petit cercle plein :
* Nœud de fin d’activité

Il marque la fin de l’activité et de tous les flots actifs au sein de cette activité.
Graphiquement, il est représenté par
* Nœud de fin de flot

Il marque la fin d’un flot sans pour autant avoir une incidence sur les autres flots actifs de
l’activité. Graphiquement, il est représenté par un cercle barré
* Nœud de décision
Un nœud de décision est un nœud de contrôle qui permet de faire un choix entre plusieurs
flots sortants. Graphiquement, il est représenté par un losange
* Nœud de fusion
Un nœud de fusion est un nœud de contrôle qui rassemble plusieurs flots alternatifs
entrants en un seul flot sortant. Il n’est pas utilisé pour synchroniser des flots concurrents (c’est le
rôle du nœud d’union) mais pour accepter un flot parmi plusieurs.
Graphiquement, il est représenté comme le nœud de décision par un losange
* Nœud de bifurcation
Un nœud de bifurcation, également appelé nœud de débranchement est un nœud de
contrôle qui sépare un flot en plusieurs flots concurrents.
Graphiquement, on le représente par un trait plein
* Nœud d’union ou de jointure

Un nœud d’union, également appelé nœud de jointure est un nœud de contrôle qui
synchronise des flots multiples. Un tel nœud possède donc plusieurs arcs entrants et un seul arc
sortant. Lorsque tous les arcs entrants sont activés, l’arc sortant l’est également.
Graphiquement, on représente un nœud d’union, comme un nœud de bifurcation, par un trait plein
d) Les partitions
Appelées aussi Lignes d’eau ou Couloirs, elles permettent d’opérer des regroupements
pour mieux organiser les activités. Chaque couloir correspond à un niveau de responsabilité d’un
certain nombre d’actions.
Gérant Pompiste Client
Enregister bon d'entrée
Affecter pompiste Solliciter carburant
Percevoir argent Payer carburant
Servir carburant
Non
Fin journée
Oui
Valider bordereau Etablir bordereau de vente
Mettre à jour stock
II.4. Diagramme de séquences

Le diagramme de séquences modélise les échanges entre les objets de manière
chronologique. Il est établi pour chaque cas d’utilisation à partir de la description textuelle du cas
d’utilisation.

a. Ligne de vie
La ligne de vie représente l’ensemble des opérations exécutées par l’objet. On la
représente par un rectangle auquel est attachée une ligne en pointillés. Un message reçu par un
objet déclenche l’exécution d’une opération. Le retour d’information peut être implicite ou explicite
par un message de retour en pointillés.
b. Message
Un message incarne une communication entre deux lignes de vie. Le message peut être
synchrone ou asynchrone
- Le message synchrone est celui qui oblige son émetteur d’attendre la réponse, qui prend
un peu de temps, avant de poursuivre ses actions. Il est représenté par une flèche avec
extrémité pleine.
- Le message asynchrone est celui qui n’a pas de réponse, il est représenté par une flèche
avec une extrémité non pleine.
Facturation Système
Message
synchrone
1 : OuvrirFormulaireFacture()
Déroulement
temporel
2 : Formulaire Facture
Message
3 : SaisirFacture
asynchrone
4 : Valider()
5 : Facture validée
II.4.2. Fragments d’interaction et opérateurs

Dans un diagramme de séquence, on peut trouver des sous-ensembles d’interactions
qu’on appelle fragments d’interaction auxquels on associe généralement des opérateurs. Les 13
opérateurs définis dans UML sont : alt (alternative), opt (option), loop, ref (reference), par
(parallele), ignore, consider, critical, break, weak, negative, assertion et strict.
Client Système
LOOP
1 : IntroduireCarte
2 : VérifierCode()
[non ok]
ALT
[ok]
3 : Code non valide
4 : Code valide
5 : SaisirMontant
6 : VérifierMontant()
ALT
7 : Montant insuffisant
8 : Pompe déclenchée
Chapitre III : LES PROCESSUS UML

III.1. Processus de développement
Un processus définit une séquence d’étapes, partiellement ordonnées, qui concourent à
l’obtention d’un système logiciel ou à l’évolution d’un système existant. L’objet d’un processus de
développement est de produire des logiciels de qualité qui répondent aux besoins de leurs
utilisateurs dans des temps et des coûts prévisibles.
Plus simplement, un processus doit permettre de répondre à la question fondamentale : « Qui fait
quoi et quand ? ».
Bien qu’UML ne soit pas une méthode, ses auteurs précisent néanmoins qu’une méthode
(ou processus) basée sur l’utilisation UML doit être :
 Pilotée par les cas d’utilisation

La principale qualité d’un logiciel étant son utilité, c’est-à-dire son adéquation avec les besoins
des utilisateurs, toutes les étapes, de la spécification des besoins à la maintenance, doivent être
guidées par les cas d’utilisation qui modélisent justement les besoins des utilisateurs.
 Centrée sur l’architecture
L’architecture est conçue pour satisfaire les besoins exprimés dans les cas d’utilisation, mais
aussi pour prendre en compte les évolutions futures et les contraintes de réalisation. La mise en
place d’une architecture adaptée conditionne le succès d’un développement. Il est important de
la stabiliser le plus tôt possible.
 Itérative et incrémentale
L’ensemble du problème est décomposé en petites itérations, définies à partir des cas d’utilisation
et de l’étude des risques. Les risques majeurs et les cas d’utilisation les plus importants sont
traités en priorité. Le développement procède par des itérations qui conduisent à des livraisons
incrémentales du système.
Dans ce cours, nous allons présenter deux processus UML : UP et 2TUP.
III.2. Le Processus Unifié UP (Unified Process)

III.2.1. Présentation
Pendant plusieurs décennies, le monde informatique a toujours rêvé d'un
processus qui puisse garantir le développement efficace des logiciels de qualité, valable quel que
soit la grandeur et la complexité du projet, et présentant de bonnes pratiques adaptées à la
méthode en question, surtout que, de nos jours, les logiciels demandés sont de plus en plus
imposants et exigeants qu'auparavant.
Le processus unifié semble être la solution idéale pour remédier à l'éternel

problème des développeurs. En effet, il regroupe les activités à mener pour transformer les
besoins d'un utilisateur en un système logiciel quel que soit la classe, la taille et le domaine
d'application de ce système.
Le processus est dit « Unifié » pour être amené à l'unité, se fondre en un tout. En fait, les
méthodes d'analyse et de conception orientées objet, étaient variées jusqu'à ce que Rambaugh,
Jacobson et Booch eurent l'idée de les unifier.
Le processus unifié UP est un processus de développement logiciel itératif, centré sur
l'architecture, piloté par des cas d'utilisation et orienté vers la diminution des risques.
C'est un patron de processus pouvant être adaptée à une large classe de systèmes logiciels, à
différents domaines d'application, à différents types d'entreprises, à différents niveaux de
compétences et à différentes tailles de l'entreprise.
III.2.2. Caractéristiques d’UP

* UP est itératif et incrémental
Une itération prend en compte un certain nombre de cas d'utilisation et traite en priorité
les risques majeurs.
 L'idée est simple : 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 devrait 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.
* UP est centré 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é...). La définition d’une bonne architecture garantit une application qui peut
être facilement adaptée à l’évolution de l’environnement et des technologies.
* UP est piloté par les cas d'utilisation

Le but principal d'un système informatique est de satisfaire les besoins du client. Le
processus de développement sera donc axé sur l'utilisateur.
Les cas d'utilisation permettent d'illustrer ces besoins. Ils détectent puis décrivent les besoins
fonctionnels (du point de vue de l'utilisateur), et leur ensemble constitue le modèle de cas
d'utilisation qui dicte les fonctionnalités complètes du système.
* Piloté par les risques

Les risques majeurs du projet doivent être identifiés au plus tôt, mais surtout levés le plus
rapidement possible. Les mesures à prendre dans ce cadre déterminent l’ordre des itérations.
III.2.3. Phases d’UP

L'objectif d'un processus unifié est de maîtriser la complexité des projets informatiques en
diminuant les risques.
UP est un ensemble de principes génériques adapté en fonctions des spécificités des projets. UP
répond aux préoccupations suivantes :
- QUI participe au projet ?
- QUOI, qu'est-ce qui est produit durant le projet ?
- COMMENT doit-il être réalisé ?
- QUAND est réalisé chaque livrable ?
a. L'architecture bidirectionnelle
UP gère le processus de développement par deux axes.
L'axe vertical représente les principaux enchaînements d'activités, qui regroupent les activités
selon leur nature. Cette dimension rend compte l'aspect statique du processus qui s'exprime en
termes de composants, de processus, d'activités, d'enchaînements, d'artefacts et de travailleurs.
L'axe horizontal représente le temps et montre le déroulement du cycle de vie du processus;
cette dimension rend compte de l'aspect dynamique du processus qui s'exprime en terme de
cycles, de phases, d'itérations et de jalons.
 Incubation (analyse des besoins)

C'est la première phase du processus unifié. Il s'agit de délimiter la portée du
système, c'est-à-dire tracer ce qui doit figurer à l'intérieur du système et ce qui doit rester à
l'extérieur, identifier les acteurs, lever les ambiguïtés sur les besoins et les exigences nécessaires
dans cette phase. Il s'agit aussi d'établir une architecture candidate, c'est-à-dire que pour une
première phase, on doit essayer de construire une architecture capable de fonctionner. Dans
cette phase, il faut identifier les risques critiques susceptibles de faire obstacles au bon
déroulement du projet.
 Elaboration
C'est la deuxième phase du processus. Après avoir compris le système, dégagé
les fonctionnalités initiales, précisé les risques critiques, le travail à accomplir maintenant consiste
à stabiliser l'architecture du système. Il s'agit alors de raffiner le modèle initial de cas d'utilisation,
voire capturer de nouveaux besoins, analyser et concevoir la majorité des cas d'utilisation
formulés, et si possible implémenter et tester les cas d'utilisation initiaux.
 Construction
Dans cette phase, il faut essayer de capturer tous les besoins restants car il n'est
pratiquement plus possible de le faire dans la prochaine phase. Ensuite, continuer l'analyse, la
conception et surtout l'implémentation de tous les cas d'utilisation. A la fin de cette phase, les
développeurs doivent fournir une version exécutable du système.
 Transition
C'est la phase qui finalise le produit. Il s'agit au cours de cette phase de vérifier si
le système offre véritablement les services exigés par les utilisateurs, détecter les défaillances,
combler les manques dans la documentation du logiciel et adapter le produit à l'environnement
(mise en place et installation).
b. Les activités du Processus Unifié

b1. Expression des besoins
L'expression des besoins comme son nom l'indique, permet de définir les différents
besoins principaux et fournir une liste de leurs fonctions. UP distingue 2 types de besoins :
- les besoins fonctionnels (du point de vue de l'utilisateur) qui conduisent à l'élaboration des
modèles de cas d'utilisation,
- les besoins non fonctionnels (techniques) et livrer une liste des exigences.
b2. Analyse
L'objectif de l'analyse est d'accéder à une compréhension des besoins et des exigences
du client. Il s'agit de livrer des spécifications pour permettre de choisir la conception de la solution.
Un modèle d'analyse livre une spécification complète des besoins issus des cas d'utilisation et
les structures sous une forme qui facilite la compréhension (scénarios), la préparation (définition
de l'architecture), la modification et la maintenance du futur système.
Il s'écrit dans le langage des développeurs et peut être considéré comme une première ébauche
du modèle de conception.
b3. Conception
La conception permet d'acquérir une compréhension approfondie des contraintes liées au
langage de programmation, à l'utilisation des composants et au système d'exploitation.
Elle détermine les principales interfaces et les transcrit à l'aide d'une notation commune.
Elle constitue un point de départ à l'implémentation :
- elle décompose le travail d'implémentation en sous-système,

- elle créée une abstraction transparente de l'implémentation,
b4. Implémentation
L'implémentation est le résultat de la conception pour implémenter le système sous
formes de composants, c'est-à-dire, de code source, de scripts, de binaires, d'exécutables et
d'autres éléments du même type.
Les objectifs principaux de l'implémentation sont de planifier les intégrations des composants
pour chaque itération, et de produire les classes et les sous-systèmes sous formes de codes
sources.
b5. Test
Les tests permettent de vérifier des résultats de l'implémentation en testant la
construction. Pour mener à bien ces tests, il faut les planifier pour chaque itération, les
implémenter en créant des cas de tests, effectuer ces tests et prendre en compte le résultat de
chacun.
III.2.4. Les Etapes du Processus Unifié

1. Identification des besoins et spécification des fonctionnalités
- Identification et représentation des besoins : diagramme de cas d’utilisation
Dans un premier temps, on crée les cas d’utilisation pour identifier et modéliser les besoins des
utilisateurs. Ces besoins sont déterminés à partir des informations recueillies lors des rencontres
entre informaticiens et utilisateurs. Il faut impérativement proscrire toute considération de
réalisation lors de cette étape.
Durant cette étape, vous devrez déterminer les limites du système, identifier les acteurs et
recenser les cas d’utilisation. Si l’application est complexe, vous pourrez organiser les cas
d’utilisation en packages.
- Dans le cadre d’une approche itérative et incrémentale, il faut affecter un degré d’importance et
un coefficient de risque à chacun des cas d’utilisation pour définir l’ordre des incréments à
réaliser.
- Les interactions entre les acteurs et le système (au sein des cas d’utilisation) seront explicitées
sous forme d’une description textuelle des cas d’utilisation. L’objectif de cette étape et des deux
suivantes est justement de formuler et formaliser les besoins.
2. Spécification détaillée des besoins : diagrammes de séquence système
- Dans cette étape, on cherche à détailler la description des besoins par la description textuelle
des cas d’utilisation et la production de diagrammes de séquence système illustrant cette
description textuelle. Cette étape amène souvent à mettre à jour le diagramme de cas d’utilisation
puisque nous sommes toujours dans la spécification des besoins.
Les scénarii de la description textuelle des cas d’utilisation peuvent être vus comme des instances
de cas d’utilisation et sont illustrés par des diagrammes de séquence système. Il faut, au
minimum, représenter le scénario nominal de chacun des cas d’utilisation par un diagramme de
séquence qui rend compte de l’interaction entre l’acteur, ou les acteurs, et le système. Le système
est ici considéré comme un tout et est représenté par une ligne de vie. Chaque acteur est
également associé à une ligne de vie.
N.B. Lorsque les scénarii alternatifs d’un cas d’utilisation sont nombreux et importants, l’utilisation
d’un diagramme d’états-transitions ou d’activités peut s’avérer préférable à une multitude de
diagrammes de séquence.
3. Maquette de l’IHM de l’application (non couvert par UML) : Ecran général

Une maquette IHM est un produit jetable donnant aux utilisateurs une vue concrète mais non
définitive de la future interface de l’application (Ecran du menu général). Cela peut consister en
un ensemble de dessins réalisés avec des outils spécialisés tels que Dreamweaver, Adobe
Illustrator ou plus simplement avec Powerpoint ou même Word. Par la suite, la maquette intégrera
des fonctionnalités de navigation pour que l’utilisateur puisse tester l’enchaînement des écrans,
même si les fonctionnalités restent fictives.
La maquette est développée rapidement afin de provoquer des retours de la part des utilisateurs.
Elle permet ainsi d’améliorer la relation développeur-client. La plupart du temps, la maquette est
considérée comme jetable, c’est-à-dire que la technologie informatique employée pour la réaliser
n’est pas forcément assez robuste et évolutive pour être intégrée telle quelle.
4. Phases d’analyse
* Analyse du domaine : modèle du domaine
La modélisation des besoins par des cas d’utilisation s’apparente à une analyse fonctionnelle
classique. L’élaboration du modèle des classes du domaine permet d’opérer une transition
vers une véritable modélisation objet. L’analyse du domaine est une étape totalement dissociée
de l’analyse des besoins. Elle peut être menée avant, en parallèle ou après cette dernière.
La phase d’analyse du domaine permet d’élaborer la première version du diagramme de classes

appelée modèle du domaine. Ce modèle doit définir les classes qui modélisent les entités ou
concepts présents dans le domaine (on utilise aussi le terme de métier) de l’application. Il s’agit
donc de produire un modèle des objets du monde réel dans un domaine donné. Ces entités ou
concepts peuvent être identifiés directement à partir de la connaissance du domaine ou par des
entretiens avec des experts du domaine. Il faut absolument utiliser le vocabulaire du métier pour
nommer les classes et leurs attributs. Les classes du modèle du domaine ne doivent pas contenir
d’opération, mais seulement des attributs. Les étapes à suivre pour établir ce diagramme sont :
 identifier les entités ou concepts du domaine ;
 identifier et ajouter les associations et les attributs ;
 simplifier le modèle en éliminant les classes redondantes et en utilisant l’héritage ;
 le cas échéant, structurer les classes en paquetage selon les principes de cohérence et
d’indépendance.
L’erreur la plus courante lors de la création d’un modèle du domaine consiste à modéliser un
concept par un attribut alors que ce dernier devait être modélisé par une classe. Si la seule chose
que recouvre un concept est sa valeur, il s’agit simplement d’un attribut. Par contre, si un concept
recouvre un ensemble d’informations, alors il s’agit plutôt d’une classe qui possède elle-même
plusieurs attributs.
* Diagramme de classes participantes
Le diagramme de classes participantes est particulièrement important puisqu’il effectue la jonction

entre, d’une part, les cas d’utilisation, le modèle du domaine et la maquette, et d’autre part, les
diagrammes de conception logicielle que sont les diagrammes d’interaction et le diagramme de
classes de conception. Les diagrammes de conception logicielle n’apparaissent pas encore à ce
niveau.
Il n’est pas souhaitable que les utilisateurs interagissent directement avec les instances des
classes du domaine par le biais de l’interface graphique. En effet, le modèle du domaine doit être
indépendant des utilisateurs et de l’interface graphique. De même, l’interface graphique du
logiciel doit pouvoir évoluer sans répercussion sur le cœur de l’application. C’est le principe
fondamental du découpage en couches d’une application. Ainsi, le diagramme de classes
participantes modélise trois types de classes d’analyse, les dialogues ou travailleurs d’interface
(Interface Workers), les contrôles ou travailleurs internes (Internal workers) et les entités ainsi
que leurs relations.
- Les classes de dialogues (Travailleurs d’interface)

Les classes qui permettent les interactions entre l’IHM ou le système et les utilisateurs sont
qualifiées de dialogues. Ces classes sont directement issues de l’analyse de la maquette. Il y a
au moins un dialogue pour chaque association entre un acteur et un cas d’utilisation du
diagramme de cas d’utilisation de l’analyse du métier. En général, les dialogues vivent seulement
le temps du déroulement du cas d’utilisation concerné.
- Les classes de contrôles (Travailleurs internes)
Les classes qui modélisent la cinématique de l’application sont appelées contrôles ou travailleurs
internes dans le métier. Elles font la jonction entre les dialogues et les classes métier en
permettant aux différentes vues de l’application de manipuler des informations détenues par un
ou plusieurs objets métier. Elles contiennent les règles applicatives et les isolent à la fois des
dialogues et des entités.
- Les classes entités (Objets métiers)
Les classes métier, qui proviennent directement du modèle du domaine, sont qualifiées d’entités.
Ces classes sont généralement persistantes, c’est-à-dire qu’elles survivent à l’exécution d’un cas
d’utilisation particulier et qu’elles permettent à des données et des relations d’être stockées dans
des fichiers ou des bases de données. Lors de l’implémentation, ces classes peuvent ne pas se
concrétiser par des classes mais par des relations, au sens des bases de données relationnelles.
Lors de l’élaboration du diagramme de classes participantes, il faut veiller au respect des

règles suivantes :
 Les entités, qui sont issues du modèle du domaine, ne comportent que des attributs.
Les entités ne peuvent être en association qu’avec d’autres entités ou avec des contrôles,
mais, dans ce dernier cas, avec une contrainte de navigabilité interdisant de traverser une
association d’une entité vers un contrôle.
 Les contrôles ne comportent que des opérations. Ils implémentent la logique applicative
(i.e. les fonctionnalités de l’application), et peuvent correspondre à des règles transverses à
plusieurs entités. Chaque contrôle est généralement associé à un cas d’utilisation, et vice versa.
Mais rien n’empêche de décomposer un cas d’utilisation complexe en plusieurs contrôles: les
opérations système.
Les contrôles peuvent être associés à tous les types de classes, y compris d’autres contrôles.
Dans le cas d’une association entre un dialogue et un contrôle, une contrainte de navigabilité doit
interdire de traverser l’association du contrôle vers le dialogue.
 Les dialogues comportent des attributs et des opérations. Les attributs représentent des
informations ou des paramètres saisis par l’utilisateur ou des résultats d’actions. Les opérations
réalisent (généralement par délégation aux contrôles) les actions que l’utilisateur demande par le
biais de l’IHM. Les dialogues peuvent être en association avec des contrôles ou d’autres
dialogues, mais pas directement avec des entités.
 Il est également possible d’ajouter les acteurs sur le diagramme de classes participantes
en respectant la règle suivante : un acteur ne peut être lié qu’à un dialogue.
* Diagrammes d’activités de navigation
Les IHM modernes facilitent la communication entre l’application et l’utilisateur en offrant toute
une gamme de moyens d’action et de visualisation comme des menus déroulants ou contextuels,
des palettes d’outils, des boîtes de dialogues, des fenêtres de visualisation, etc. Cette
combinaison possible d’options d’affichage, d’interaction et de navigation aboutis aujourd’hui à
des interfaces de plus en plus riches et puissantes.
UML offre la possibilité de représenter graphiquement cette activité de navigation dans l’interface
en produisant des diagrammes dynamiques. On appelle ces derniers des diagrammes de
navigation. Le concepteur a le choix d’opter pour cette modélisation entre des diagrammes
d’états-transitions et des diagrammes d’activités. Les diagrammes d’activités constituent peut-
être aussi un choix plus souple et plus judicieux.
Les diagrammes d’activités de navigation sont à relier aux classes de dialogue du diagramme de
classes participantes. Les différentes activités du diagramme de navigation peuvent être
stéréotypées en fonction de leur nature : « fenêtre », « menu », « menu contextuel », « dialogue »,
etc. La modélisation de la navigation à intérêt à être structurée par acteur.
5. Phase de conception
* Diagrammes d’interaction
Maintenant, il faut attribuer précisément les responsabilités de comportement, dégagée par les
diagrammes de séquence système aux classes d’analyse du diagramme de classes
participantes. Les résultats de cette réflexion sont présentés sous la forme de diagrammes
d’interaction UML. Inversement, l’élaboration de ces diagrammes facilite grandement la réflexion.
Parallèlement, une première ébauche de la vue statique de conception, c’est-à-dire du

diagramme de classes de conception, est construite et complétée. Durant cette phase, l’ébauche
du diagramme de classes de conception reste indépendante des choix technologiques qui seront
faits ultérieurement.
Pour chaque service ou fonction, il faut décider quelle est la classe qui va le contenir. Les
diagrammes d’interactions (i.e. de séquence ou de communication) sont particulièrement utiles
au concepteur pour représenter graphiquement ces décisions d’allocations des responsabilités.
Chaque diagramme va représenter un ensemble d’objets de classes différentes collaborant dans
le cadre d’un scénario d’exécution du système.
Dans les diagrammes d’interaction, les objets communiquent en s’envoyant des messages qui
invoquent des opérations sur les objets récepteurs. Il est ainsi possible de suivre visuellement les
interactions dynamiques entre objets, et les traitements réalisés par chacun d’eux. Avec un outil
de modélisation UML (comme StarUML ou PowerAMC), la spécification de l’envoi d’un message
entre deux objets crée effectivement une opération publique sur la classe de l’objet cible. Ce type
d’outil permet réellement de mettre en œuvre l’allocation des responsabilités à partir des
diagrammes d’interaction.
Par rapport aux diagrammes de séquences système, nous remplaçons ici le système, vu comme
une boîte noire, par un ensemble d’objets en collaboration. Ces objets sont des instances des
trois types de classes d’analyse du diagramme de classes participantes, à savoir des dialogues,
des contrôles et des entités. Les diagrammes de séquences élaborés dans cette section doivent
donc toujours respecter les règles édictées plus haut. Ces règles doivent cependant être
transposées car, pour que deux objets puis interagir directement, il faut que :
 les classes dont ils sont issus soient en association dans le diagramme de classes
participantes ;
 l’interaction respecte la navigabilité de l’association en question.
* Diagramme de classes de conception
L’objectif de cette étape est de produire le diagramme de classes qui servira pour
l’implémentation. Une première ébauche du diagramme de classes de conception a déjà été
élaborée en parallèle du diagramme d’interaction. Il faut maintenant le compléter en précisant les
opérations privées des différentes classes. Il faut prendre en comptes les choix techniques,
comme le choix du langage de programmation, le choix des différentes librairies utilisées

(notamment pour l’implémentation de l’interface graphique), etc.
Pour une classe, le couplage est la mesure de la quantité d’autres classes auxquelles elle est
connectée par des associations, des relations de dépendances, etc. Durant toute l’élaboration du
diagramme de classes de conception, il faut veiller à conserver un couplage faible pour obtenir
une application plus évolutive et plus facile à maintenir. L’utilisation des design patterns est
fortement conseillée lors de l’élaboration du diagramme de classes de conception.
Pour le passage à l’implémentation, les classes du type entités ont intérêt à être implémentées
dans une base de données relationnelle. Ensuite, l’implémentation est complétée par l
diagramme de composants et/ou de déploiement.
III.3. LE PROCESSUS 2TUP

III.3.1. Définition
2TUP signifie « 2 Track Unified Process ». C’est un processus UP. Le processus 2TUP
apporte une réponse aux contraintes de changement continuel imposées aux systèmes
d’information de l’entreprise. En ce sens, il renforce le contrôle sur les capacités d’évolution et de
correction de tels systèmes. « 2 Track » signifie littéralement que le processus suit deux chemins.
Il s’agit des chemins « fonctionnels » et « d’architecture technique », qui correspondent aux deux
axes des changements imposés au système informatique.
La branche gauche (fonctionnelle) capitalise la connaissance du métier de l’entreprise. Elle

constitue généralement un investissement pour le moyen et le long terme. Les fonctions du
système d’information sont en effet indépendantes des technologies utilisées. Cette branche
comporte :
• la capture des besoins fonctionnels, qui produit un modèle des besoins focalisé sur le métier
des utilisateurs.
• l’analyse, qui consiste à étudier précisément la spécification fonctionnelle de manière à obtenir
une idée de ce que va réaliser le système en termes de métier. Les résultats de l’analyse ne
dépendent d’aucune technologie particulière.
La branche droite (architecture technique) capitalise un savoir-faire technique. Elle constitue un

investissement pour le court et moyen terme. Les techniques développées pour le système
peuvent l’être en effet indépendamment des fonctions à réaliser. Cette branche comporte les
étapes suivantes :
• la capture des besoins techniques, qui recense toutes les contraintes et les choix dimensionnant
la conception du système. Les outils et les matériels sélectionnés ainsi que la prise en compte de
contraintes d’intégration avec l’existant conditionnent généralement des pré- requis d’architecture
technique ;
• la conception générique, qui définit ensuite les composants nécessaires à la construction de
l’architecture technique. Cette conception est la moins dépendante possible des aspects
fonctionnels. Elle a pour objectif d’uniformiser et de réutiliser les mêmes mécanismes pour tout
un système. L’architecture technique construit le squelette du système informatique et écarte la
plupart des risques de niveau technique.
La branche du milieu : à l’issue des évolutions du modèle fonctionnel et de l’architecture

technique, la réalisation du système consiste à fusionner les résultats des 2 branches. Cette
fusion conduit à l’obtention d’un processus en forme de Y. Cette branche comporte les étapes
suivantes :
• la conception préliminaire, qui représente une étape délicate, car elle intègre le modèle
d’analyse dans l’architecture technique de manière à tracer la cartographie des composants du
système à développer ;
• la conception détaillée, qui étudie ensuite comment réaliser chaque composant ;
• l’étape de codage, qui produit ces composants et teste au fur et à mesure les unités de code
réalisées ;
• l’étape de recette, qui consiste enfin à valider les fonctions du système développé.
III.3.2. Caractéristiques de 2TUP

* Un processus piloté par les exigences des utilisateurs
Les cas d’utilisation sont justement des outils construits pour définir les besoins, développant
de surcroît le point de vue des utilisateurs. Il convient par la suite de montrer comment s’établit la
traçabilité entre les cas d’utilisation et le modèle de conception.
Les cas d’utilisation influencent l’analyse et la conception d’architecture du système.
• Sur la branche gauche, pour la capture des besoins fonctionnels, les cas d’utilisation portent
uniquement sur la plus-value métier des fonctions du système. Chaque cas d’utilisation met en
évidence des classes d’analyse qui sont les concepts utilisés par l’utilisateur et des scénarios qui
établissent les comportements attendus du système.
• Sur la branche droite, pour la capture des besoins techniques, la nature des cas d’utilisation est
adaptée en fonction des plus-values opérationnelles du système pour ses exploitants. Chaque
cas d’utilisation technique structure des spécifications d’architecture que l’on peut par la suite
décomposer par couche logicielle. Les cas d’utilisation techniques permettent de concevoir les
classes qui vont offrir une réponse aux contraintes opérationnelles du système. Les interactions
entre ces classes permettent par ailleurs d’étudier les échanges entre classes, de consolider et
de vérifier la conception des cas d’utilisation techniques.
• Lors de la conception préliminaire, les classes obtenues naissent de la distribution des classes
d’analyse sur les couches logicielles. Les interactions entre classes de conception permettent de
consolider et de vérifier à terme la conception des cas d’utilisation fonctionnelle tenant compte
des contraintes opérationnelles.
* Un processus par niveaux d’abstraction
Chaque niveau d’abstraction du modèle s’inscrit dans une étape du processus et fixe un objectif
de description du modèle.
Pour la capture des besoins fonctionnels :

• le niveau du contexte a pour objet de définir la frontière fonctionnelle entre le système considéré
comme une boîte noire et son environnement ;
• le niveau des cas d’utilisation définit ensuite les activités attendues des différents utilisateurs
par rapport au système toujours envisagé comme une boîte noire. Ce modèle permet de contrôler
la bonne adéquation des besoins avec les utilisateurs.
Pour l’analyse :
• on ouvre le système pour établir la structure des objets utilisés. Le modèle d’analyse du domaine
définit la structure et le comportement des objets connus dans le métier des utilisateurs du
système ;
• le modèle d’analyse de l’application y rajoute, suivant le même processus, les objets qui sont
connus des utilisateurs, dans le cadre de la mise en application de leurs besoins.
Pour la capture des besoins techniques :
• le modèle d’analyse technique établit des couches logicielles et y spécifie les activités
techniques attendues.
Pour la conception générique :

• le modèle de conception technique définit les composants qui, délivrant des services techniques,
assurent la réponse aux exigences opérationnelles du système.
Pour la conception préliminaire :

• le modèle de conception système organise le système en composants, délivrant les services
techniques et fonctionnels. Ce modèle regroupe les informations des branches fonctionnelle et
technique. Il peut être considéré comme la transformation du modèle d’analyse par projection des
classes d’analyse sur les couches logicielles.
Pour la conception des classes :

• le modèle de conception des composants fournit l’image « prêt à fabriquer » du système
complet.
Notons que, préalablement au développement, un modèle métier peut établir le contexte

organisationnel dans lequel vient s’insérer le système informatique.
Ce modèle éventuellement objet constitue un point d’entrée possible au processus en Y.
III.3.3. Les Etapes de 2TUP

1. Etude préliminaire
Cette étude préliminaire permet de recenser les besoins fonctionnels et les besoins techniques
et représente l’expression des besoins du système.
- Les besoins fonctionnels

Les besoins fonctionnels listent les opérations réalisables de notre application. Ce sont
des besoins spécifiant un comportement d'entrée/sortie du système.
Les besoins opérationnels représentent les besoins non fonctionnels, qui caractérisent le
système comme la performance, la sécurité et l’ergonomie du système. Ces besoins peuvent être
énoncés suivant des plans de classifications.
- Les besoins techniques

Il s’agit de toutes les contraintes techniques liées aux fonctionnalités de l’application, par exemple
:
 La sécurité à travers la gestion des droits d’accès,
 L’accès souple et rapide à la base de données,
 Application toujours fonctionnelle,
 Espace de stockage des données suffisant,
 Temps de réponse minimum,
 Communication des données entre deux environnements hétérogènes : Protocole de
Communication, format des données...
1.1. Capture des besoins fonctionnels
On va s’intéresser à la branche gauche du cycle en Y qui est « la capture des besoins fonctionnels
» en décrivant les différentes façons qui seront disponible pour permettre les acteurs d’utiliser la
future application.
- identification des messages émis et reçus

- diagramme de contexte du système
- DCU système
- classement des cas d’utilisation par priorité et par risque
- description textuelle des cas d’utilisation
- organisation des cas d’utilisation en packages
- Diagramme des classes participantes par packages
1.2. Capture des besoins Techniques
La spécification technique est une activité de la branche droite du Y ; parce qu’elle est
primordiale dans la conception de l’architecture. Dans cette étape, nous abordons :
 la construction d’un modèle d’analyse technique avec UML,
 les avantages d’une organisation en couches logicielles,
 l’emploi des cas d’utilisation pour décrire les comportements techniques du système,
 la description des cas d’utilisation techniques.
1.2.1. Configuration matérielle du système

Les choix des prérequis techniques déjà mentionnés dans l’étude préliminaire, lors de
l’expression des besoins opérationnels, impliquent des contraintes relatives à la configuration du
réseau matériel, les performances d’accès aux données ainsi que la sécurité du système,
l’intégration des applications, la volumétrie et le mode d’utilisation du système
Ex : architecture n-tiers ou autre
1.2.2. Spécification d’architecture

Sur le plan logique, l’architecture est mise en œuvre suivant un modèle spécifique,
par exemple MVC (Modèle-Vue-Contrôleur) ou En couches. La spécification d’une architecture
à composants métier implique la répartition des composants d’exploitation suivant les
responsabilités.
1.2.3. Elaboration du diagramme des cas d’utilisation techniques

Une fois que les spécifications techniques et d’architecture sont exprimées, on peut
s’intéresser aux fonctionnalités propres du système technique en procédant à une spécification
logicielle. Dans ce cadre, on propose d’utiliser les cas d’utilisation de manière différente que pour
la spécification fonctionnelle. C’est pourquoi nous avons introduit le concept d’exploitant et de
cas d’utilisation technique.
Tout système informatique possède au minimum un exploitant qui est « l’utilisateur du
système ». Il s’agit ici de l’utilisateur dans son sens le plus général, indépendamment des
fonctions ou du métier qu’il réalise au travers de l’application.
Exploitant : c’est un acteur qui s’appuie sur des concepts techniques pour accéder aux services
de l’application.
Cas d’utilisation technique : un cas d’utilisation technique est destiné à l’exploitant. C’est une
séquence d’actions produisant une valeur ajoutée opérationnelle ou purement technique. Le
choix de l’architecture physique a été effectué selon l’environnement adopté.
Les cas d’utilisation techniques sont absolument distincts des cas d’utilisation de la
branche gauche : ils ne produisent aucune valeur ajoutée fonctionnelle. La branche droite
recouvre en effet tous les services techniques dont un utilisateur bénéficie, parfois même sans
s’en rendre compte.
1.2.4. Définition des détails techniques

Ce sont les détails techniques du matériel sur lequel sera implémentée l’application. Il
s’agit de dresser un listing général non exhaustif des concepts techniques à manipuler.
2. Analyse
La phase d’analyse qui représente la deuxième étape de la branche gauche du cycle en
Y. Au cours de cette étape, on va représenter une vue statique du système par la modélisation
de diagrammes de classe puis, et une vue dynamique par la modélisation des diagrammes de
séquence.
2.1. Découpage en paquetages

Le découpage en paquetages constitue la première activité de l’étape d’analyse, il
s’affine bien sûr de manière itérative au cours du projet. Il se situe sur la branche gauche du cycle
en Y et succède à la capture des besoins fonctionnels.
Une catégorie consiste en un regroupement logique de classes à forte cohérence interne
et faible couplage externe.
2.2. Développement du modèle statique
Cette partie va nous permettre d’illustrer les principales constructions du diagramme de classes
du domaine
Le diagramme de classes a toujours été le diagramme le plus important dans toutes les méthodes
orientées objet. C’est également celui qui contient la plus grande gamme de notations et de
variantes. UML a réussi à unifier le vocabulaire et les concepts sans perdre la richesse et les
apports des différentes méthodes existantes.
Le développement du modèle statique constitue la deuxième activité de l’étape d’analyse. Elle se
situe sur la branche gauche du cycle en Y et succède au découpage en catégories.
Le modèle de domaine représente l’ensemble de classes qui modélisent le métier. Il s’agit des
classes statistiques et dépourvues de leurs méthodes.
2.3. Développement du modèle dynamique

Le développement du modèle dynamique constitue la troisième activité de l’étape d’analyse.
Elle se situe sur la branche gauche du cycle en Y. Il s’agit d’une activité itérative, fortement
couplée avec l’activité de modélisation statique.
- A partir de la description textuelle des cas d’utilisation, on dresse les diagrammes de
séquence système
- On les complète par un diagramme d’interaction globale, qu’on peut remplacer par un
diagramme d’états-transitions ou un diagramme d’activités.
3. Conception Générique
La conception générique consiste à développer la solution qui répond aux
spécifications techniques. Cette conception est qualifiée de générique car elle est entièrement
indépendante des aspects fonctionnels spécifiés en branche gauche. La conception générique
reste donc une activité de la branche droite.
Nous pouvons considérer que la conception générique développe le squelette
technique d’un projet. Nous utiliserons le formalisme UML pour effectuer notre conception
générique.
L’intégralité de conception s’exprime sous la forme d’un ensemble de classes techniques que
les concepteurs vont par la suite réutiliser pour développer les différentes composantes
fonctionnelles du système.
3.1. Framework technique

C’est un réseau de classes qui collaborent à la réalisation d’une responsabilité qui
dépasse celle de chacune des classes qui y participent. Un problème très récurrent chez les
utilisateurs c’est l’audit des opérations effectuées les postes clients et serveurs. Pour cela, il
faut par exemple surveiller les erreurs qui peuvent survenir sur les postes et les consigner dans
un fichier journal. Un framework technique est proposé à cet effet, par exemple :
3.2. Le modèle d’exploitation de la conception technique

Le modèle de d’exploitation de la conception technique n’est autre que le diagramme de
composants UML. Chaque composant est une entité logicielle qui s’installe à part entière sur un
poste client ou serveur.
Navigateur
SGBD
«Interface»
Socket de réception
Site Web
+ Proticole = "HTTP"
+ Port = 80
<<Interface>> «Interface»
Socket d'émission Socket MySQL
+ Protocole= "HTTP" + Protocole = "TCP"

+ Port = 80 + Port = 3306
Serveur Web
4. Conception préliminaire
La conception préliminaire est certainement l’étape la plus délicate du processus 2TUP
car elle en représente le cœur. C’est en effet à cette occasion que s’effectue la fusion des études
fonctionnelles et techniques. En conséquence, plusieurs activités doivent coexister.
4.1. Développement du modèle de déploiement

Le déploiement d’une solution client/serveur se construit sur la définition des postes de
travail. Le diagramme de déploiement illustre bien ce modèle. Exemple :
Terminal Serveur d'application Serveur Web Serveur de BD
Internet TCP HTTP <<artifact>>

<<artifact>> <<artifact>> Mysql
<<artifact>> php
Telephone Interface
4.2. Développement du modèle d’exploitation

La distribution d’un composant facilite sa réutilisation, puisque les mêmes services sont
accessibles depuis différentes applications. La première façon d’identifier les composants
distribués consiste donc à recenser les catégories d’analyse partagées par plusieurs applications.
Exemple :
4.3. Développement du modèle logique

Jusqu’ici, les modèles de déploiement et d’exploitation ont été définis en déterminant
les postes de travail et les composants de la solution visée. Il faut cependant développer les
classes nécessaires au codage. Le modèle logique est précisément celui de la représentation
des classes organisées en catégories. Ce modèle dérive du modèle structurel d’analyse d’une
part et du modèle logique de conception technique d’autre part. Exemple :
5. Conception détaillée
La conception détaillée est une activité qui s’inscrit dans l’organisation définie par la
conception préliminaire. Le modèle logique y est particulièrement important dans la mesure où
c’est en conception détaillée que l’on génère le plus gros volume d’informations. Il est ainsi
possible de confier les catégories à des personnes différentes, qui pourront travailler
indépendamment les unes des autres. La conception détaillée s’appuie donc sur les catégories
de conception organisées à la fois suivant les Framework techniques et les regroupements
propres au métier. Les concepteurs construisent alors les classes, les vues d’IHM, les
interfaces, les tables et les méthodes qui vont donner une image « prête à coder » de la solution.
5.1. Le micro-processus de conception logique

Le micro-processus de conception logique concerne la définition des classes à

implémenter. C’est donc une activité centrée sur le modèle logique, qui combine les diagrammes
UML suivants :
• principalement les diagrammes de classes de conception pour préciser la structure des
classes de développement,
• mais aussi les diagrammes d’interactions pour préciser les communications entre objets.
5.2. Elaboration du modèle logique de données relationnel

A ce stage, il faut transformer le modèle du domaine en modèle logique de données
(MLD). Un MLD spécifie un schéma pour une base de données relationnelle soit : les tables, les
champs de chaque table et leurs propriétés, la clé primaire des tables, les clés étrangères
assurant les liaisons entre les tables et les contraintes d’intégrité portant sur ces liaisons
(Relational Data model).
CONCLUSION GENERALE
UML utilise l'approche objet en présentant un langage de description universel. Il
permet grâce à un ensemble de diagrammes très explicites, de représenter l'architecture et le
fonctionnement des systèmes informatiques complexes en tenant compte des relations entre les
concepts utilisés et l'implémentation qui en découle.
UML est donc bien plus qu'un simple outil qui permet de "dessiner" des
représentations mentales... Il permet de parler un langage commun, normalisé mais accessible,
car visuel. Il représente un juste milieu entre langage mathématique et naturel, pas trop complexe
mais suffisamment rigoureux, car basé sur un méta modèle. Une autre 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.
Les processus de développement logiciel reposant sur la notation UML, en

l’occurrence UP et 2TUP demeurent de véritables démarches méthodologiques permettant
d’analyser et de concevoir des logiciels.
Notons tout de même que la force d’une méthode ne réside pas dans la méthode,
mais plutôt dans le chef de la personne qui utilise la méthode !
TABLE DES MATIERES
INTRODUCTION ............................................................................................................................................. 0
0.1. Développement logiciel ................................................................................................................ 3
0.2. Cycles de développement logiciel ................................................................................................. 4
0.3. Système d'information d'entreprise .................................................................................................. 8
0.3.1. Système d’information et Système informatique ....................................................................... 9
0.3.2. Pourquoi modéliser ? ................................................................................................................ 10
Chapitre II : LE LANGAGE UML .................................................................................................................... 12
II.1. Historique......................................................................................................................................... 12
II.2. Présentation d’UML ......................................................................................................................... 13
II.3. Les diagrammes UML ....................................................................................................................... 17
a) Six diagrammes structurels ou statiques : ...................................................................................... 18
b) Sept diagrammes comportementaux ou dynamiques : ................................................................. 18
CHAPITRE III : ETUDE DE QUELQUES DIAGRAMMES UML .......................................................................... 21
III.1. DIAGRAMME DES CAS D’UTILISATION ............................................................................................ 21
III.1.1. Concepts de base ..................................................................................................................... 21
II.1.2. Relations entre acteurs et cas d’utilisation............................................................................... 22
II.1.3. Relations entre les cas d’utilisation .......................................................................................... 22
II.1.4. Relations entre acteurs ............................................................................................................. 24
II.1.5. Description textuelle des cas d’utilisation ................................................................................ 24
II.2. DIAGRAMME DE CLASSES ................................................................................................................ 25
II.2.1. Concepts de base ...................................................................................................................... 25
II.2.2. Encapsulation et visibilité ......................................................................................................... 26
II.2.3. Relations entre classes .............................................................................................................. 26
II.2.4. Multiplicité ou cardinalité ......................................................................................................... 27
II.2.5. Navigabilité ............................................................................................................................... 27
II.2.6. Classe-association ..................................................................................................................... 28
II.3. LE DIAGRAMME D’ACTIVITES ........................................................................................................... 30
II.4. Diagramme de séquences ................................................................................................................ 33
II.4.1. Concepts de base ...................................................................................................................... 33

II.4.2. Fragments d’interaction et opérateurs..................................................................................... 34
Chapitre III : LES PROCESSUS UML .............................................................................................................. 35
III.1. Processus de développement ......................................................................................................... 35
III.2. Le Processus Unifié UP (Unified Process)........................................................................................ 35
III.2.1. Présentation ............................................................................................................................. 35
III.2.2. Caractéristiques d’UP ............................................................................................................... 36
III.2.3. Phases d’UP .............................................................................................................................. 37
III.2.4. Les Etapes du Processus Unifié ................................................................................................ 39
III.3. LE PROCESSUS 2TUP........................................................................................................................ 47
III.3.1. Définition ................................................................................................................................. 47
III.3.2. Caractéristiques de 2TUP ......................................................................................................... 48
III.3.3. Les Etapes de 2TUP .................................................................................................................. 50
CONCLUSION GENERALE ............................................................................................................................. 60
TABLE DES MATIERES .................................................................................................................................. 61

Cours UML G2 ESIS 2016-2017

Transféré par

Informations du document

Copyright

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 :

Cours UML G2 ESIS 2016-2017

Transféré par

Droits d'auteur :

ECOLE SUPERIEURE D’INFORMATIQUE SALAMA

G2 GENIE LOGICIEL ET RESEAUX AS

Par Patrick KASONGA

1. Intitulé du cours : Conception des systèmes d’informations

5.2. Objectifs spécifiques

A l’issue de ce cours, l’étudiant doit être capable de :

CHAP I : LE LANGAGE UML

CHAP III : LES PROCESSUS UML

8. Ressources : Tableau et Videoprojecteur

9. Travaux pratiques : travaux individuels et en groupes

10. Stratégies d’évaluation : épreuves écrites avec notes de cours

11. Notice bibliographique

Actuellement, l’informatique est au cœur de toutes les grandes entreprises. Le système

0.1. Développement logiciel

0.2. Cycles de développement logiciel

* Cycle en cascade (séquentiel)

* Cycle en spirale (incrémental)

0.3. Système d'information d'entreprise

Cette présentation du système d'information peut être discutée :

0.3.1. Système d’information et Système informatique

S’appuie sur Permet

0.3.2. Pourquoi modéliser ?

Chapitre II : LE LANGAGE UML

Chaque méthode avait ses avantages et ses partisans. Le nombre de méthodes en

II.2. Présentation d’UML

L’appréhension d’UML est complexe car UML est à la fois :

UML est une norme

UML est un langage de modélisation objet

UML est un support de communication

UML est un cadre méthodologique pour une analyse objet

UML n'est pas une méthode !

1. Pilotée par les besoins des utilisateurs

2. Centrée sur l’architecture

Ph. Kruchten propose différentes perspectives, indépendantes et complémentaires, qui

 La vue des composants

 La vue des processus

 La vue des besoins des utilisateurs

 L'idée est simple : pour modéliser (comprendre et représenter) un système complexe, il

II.3. Les diagrammes UML

a) Six diagrammes structurels ou statiques :

b) Sept diagrammes comportementaux ou dynamiques :

Le diagramme de classes est le point central dans un développement orienté objet.

Le diagramme de composants montre les unités logicielles à partir desquelles on a construit le

Le diagramme de déploiement montre le déploiement physique des artefacts (éléments

Le diagramme de temps fusionne les diagrammes d’états et de séquence pour montrer

Le diagramme de structures composites montre l’organisation interne d’un élément statique

CHAPITRE III : ETUDE DE QUELQUES DIAGRAMMES UML

III.1. DIAGRAMME DES CAS D’UTILISATION

Le diagramme de cas d’utilisation permet de recueillir, d’analyser et d’organiser les

III.1.1. Concepts de base

c) Représentation d’un diagramme de cas d’utilisation

II.1.2. Relations entre acteurs et cas d’utilisation

II.1.3. Relations entre les cas d’utilisation

désignant le cas le plus général.

Payer au comptant Payer par carte de crédit

II.1.4. Relations entre acteurs

Activer compte utilisateur

II.1.5. Description textuelle des cas d’utilisation

II.2. DIAGRAMME DE CLASSES

II.2.1. Concepts de base

II.2.2. Encapsulation et visibilité

II.2.3. Relations entre classes

utilisé partout où un objet de la classe de base est autorisé.

II.2.4. Multiplicité ou cardinalité

II.2.7. Associations particulières entre classes

ENTREPRISE CAMION MOTEUR

II.2.8. Types de diagrammes de classes