1

INSTITUT SUPERIEUR TECHNIQUE

CATHOLIQUE DE KIKWIT
(ISTCK)

Destines aux étudiants de L2 LMD Informatique de Gestion

L2 LMD Informatique de Gestion

Peter SAMANO
Analyste Concepteur.
« Le savoir est une arme qui libère »

Peter SAMANO 0812440646 [email protected]

 2

PLAN DU COURS

 INTRODUCTION

 CHAPITRE 1. UML & LES CONCEPTS DE L’APPROCHE PAR OBJETS

 CHAPITRE 2. PROCESSUS ET ARCHITECTURE

 CHAPITRE 3. LA MODELISATION DES EXIGENCES

 CHAPITRE 4. LA MODELISATION DE LA DYNAMIQUE

 CHAPITRE 5. LA MODELISATION DES OBJETS

 CHAPITRE 6. LES TRAVAUX PRATIQUES

Peter SAMANO 0812440646 [email protected]

 3

INTRODUCTION

Cette partie est orientée d’une part, l’approche orienté objet, la genèse d’UML
(l'anglais Unified Modeling Language) et d’autre part à deux approches connexes à
UML :
 RUP (Rational Unified Process ou processus unifié de Rational) processus de
développement et d’évolution de logiciels ;
 l’architecture MDA (Model Driven Architecture ou architecture guidée par les
modèles) destinée à la réalisation de systèmes en faisant abstraction de la
plate-forme physique et de ses aspects technologiques.
 Approche orienté objet

La programmation orientée objet (POO), ou programmation par objet, est un paradigme

de programmation informatique. Elle est incontournable dans le cadre du
développement de systèmes logiciels complexes, capables de suivre les évolutions
incessantes des technologies et des besoins applicatifs. Cependant, la programmation
objet est moins intuitive que la programmation fonctionnelle. En effet, il est plus naturel
de décomposer les problèmes informatiques en termes de fonctions qu’en termes
d’ensembles d’objets en interaction. De ce fait, l’approche objet requiert de modéliser
avant de concevoir. La modélisation apporte une grande rigueur, offre une meilleure
compréhension des logiciels, et facilite la comparaison des solutions de conception
avant leur développement. Cette démarche se fonde sur des langages de modélisation,
qui permettent de s’affranchir des contraintes des langages d’implémentation.
La programmation orientée objet est facilitée par un ensemble de techniques dédiées :
 Les langages de programmation ;
 les outils de modélisation qui permettent de concevoir sous forme de schémas
semi-formels la structure d'un programme ;
 les ateliers de génie logiciel ;
Notons que, la programmation par objets n'a cessé d'évoluer aussi bien dans son aspect
théorique que pratique et différents métiers et discours mercatiques à son sujet ont vu le jour :
 l'analyse objet (AOO ou OOA en anglais) ;
 la conception objet (COO ou OOD en anglais) ;
 les bases de données objet (SGBDOO) ;
 les langages objets avec les langages à prototypes ;
 ou encore la méthodologie avec MDA (Model Driven Architecture).
Aujourd'hui, la programmation par objets est vue davantage comme un paradigme.

Peter SAMANO 0812440646 [email protected]

 4

Avantages du développement à l’aide des langages objet

Par rapport à une approche fonctionnelle associée à un développement classique
mené à l’aide de langages procéduraux, on est en droit de s’interroger sur les avantages
qu’apporte réellement le développement à l’aide d’un langage objet comme par
exemple C++, C# ou Java, PHP, Python… En fait, deux avantages prépondérants sont
mis en général en avant lorsque l’on choisit une approche objet :
 La modularité : Par construction, étant donné que l’on conçoit des classes
représentant une entité de taille limitée en données et en opérations, il est
plus aisé de construire des systèmes modulables que si l’on élabore une seule
base de données d’une part et un seul logiciel d’autre part.
 La réutilisabilité : La définition d’un système à l’aide de classe ayant chacune
la responsabilité d’un sous-ensemble de données et des opérations associées
favorise fortement la potentialité de trouver des classes réutilisables. La réutilisation
de classe se réalise soit sur le plan métier à l’intérieur d’une même
entreprise dans des applications différentes, soit sur le plan technique à
l’échelle de tous les développements réalisés à l’aide d’un même langage. Sur
ce dernier aspect, c’est toute l’approche du développement par composant qui
est en jeu.
Au-delà de ces deux avantages majeurs et compte tenu de la plus grande modularité dans
la construction d’une application à l’aide d’objets, la maintenance élémentaire de chaque
classe est en soi plus simple à réaliser que celle d’un logiciel unique
traitant toutes les données d’un système. Il importe bien entendu dans l’approche
objet de construire son système en veillant à minimiser le nombre de relations entre
classes.
 La genèse d’UML : Unified Modeling Language
Rappelons ici que plus de 50 méthodes d’analyse et de conception orientée objet qui
existaient vers les années 90, seulement trois d’entre elles se sont détachées nettement
au bout de quelques années. En effet, la volonté de converger vers une méthode unifiée
était déjà bien réelle et c’est pour cette raison que les méthodes
OMT, BOOCH et OOSE se sont démarquées des autres. OMT (Object Modeling
Technique) de James Rumbaugh et BOOCH de Grady Booch ont été les deux méthodes
les plus diffusées en France durant les années 90. Par ailleurs, OOSE de Ivar Jacobson
s’est aussi imposée dans le monde objet pour la partie formalisation des besoins.
Pour aller plus loin dans le rapprochement, James Rumbaugh et Grady Booch se
sont retrouvés au sein de la société Rational Software et ont été ensuite rejoints par
Ivar Jacobson en se donnant comme objectif de fusionner leur méthode et créer
UML (Unified Methode Language). Il est important de noter que contrairement à ce qui
avait été envisagé au départ, le processus de développement a été sorti du champ couvert
par le projet de norme. UML est donc une norme du langage de modélisation objet qui
a été publiée, dans sa première version, en novembre 1997 par l’OMG (Object
Management Group), instance de normalisation internationale du domaine de l’objet.
En quelques années, UML s’est imposée comme standard à utiliser en tant que
langage de modélisation objet. Par ses différentes versions nous sommes partie de la

Peter SAMANO 0812440646 [email protected]

 5

version UML, UML1, UML 2 jusqu’à 2.5 avec ses 14 diagrammes dont sept structurels
et sept comportementaux.
 Les deux approches connexes à UML
Rappelons qu’UML est une notation destinée à la modélisation par objets de systèmes
et de processus. UML ne contient pas un guide méthodologique mais constitue un
support de modélisation. Ainsi notons qu’une méthode de développement définit à la
fois un langage de modélisation et la marche à suivre lors de la conception. Le langage
UML propose uniquement une notation dont l’interprétation est définie par un
standard, mais pas une méthodologie complète. Plusieurs processus de développement
complets fondés sur UML existent, comme le Rational Unified Process (RUP), de
Booch, Jacobson et Rumbaugh, et l’approche MDA (Model Driven Architecture)
proposée par l’OMG, mais ils ne font pas partie du standard UML.

 RUP : Rational Unified Process

UP est un processus de réalisation ou d’évolution de logiciels entièrement basé sur
UML, d’où l’intérêt de le présenter dans cet ouvrage. RUP est constitué d’un ensemble
de directives permettant de produire un logiciel à partir du cahier des charges
(exigences). Chaque directive définit qui fait quoi et à quel moment. Un processus
permet donc de structurer les différentes étapes d’un projet informatique.
L’utilisation d’UML n’impose pas celle de RUP. On peut employer un autre processus
ou même aucun processus.
RUP est incrémental. Un projet est divisé en une suite de sous projets. Chaque sous
projet est une brique ajoutée au sous projet précédent qui doit donc avoir été
préalablement réalisé. Quand le dernier sous projet est réalisé, le projet dans son
intégralité est donc achevé.
RUP est itératif. Chaque sous projet est réalisé avec les mêmes activités. À l’issue de
chaque sous projet, une livraison partielle est évaluée. Les créateurs de RUP proposent
cette approche incrémentale et itérative pour éviter de traiter un projet important dans
sa globalité avec une livraison intervenant longtemps après la rédaction du cahier des
charges. En effet, dans un tel cas, il est facile d’imaginer que les besoins du client auront
évolué et qu’il n’aura guère de souvenirs de ce qu’il avait demandé dans le cahier des
charges. Un conflit peut alors se produire alors qu’une approche incrémentale et itérative
aurait permis de l’éviter.
 MDA : Model Driven Architecture

MDA est une nouvelle proposition de l’OMG dont l’objectif est la conception de
systèmes basée sur la seule modélisation du domaine, en faisant abstraction des
aspects technologiques. À partir de cette modélisation, MDA propose d’obtenir par
transformation les éléments techniques capables de fonctionner au sein d’une
plateforme logicielle comme Java ou .NET. Dans MDA, le modèle des objets du
domaine s’appelle PIM, c’est-à-dire Platform Independent Model ou modèle
indépendant de la plateforme.

Peter SAMANO 0812440646 [email protected]

 6

CHAPITRE 1. UML & LES CONCEPTS DE L’APPROCHE

PAR OBJETS
1.1. Introduction

Ce chapitre a pour objectif de vous faire découvrir les différents concepts et

principes de l’approche objet qui sont à la base d’UML. Leur connaissance est
indispensable pour comprendre les éléments utilisés dans la panoplie des
diagrammes d’UML qui seront abordés dans les chapitres suivants.

Par définition, UML est un langage de modélisation graphique et textuel destiné

à comprendre et décrire les besoins, spécifier et documenter des systèmes
esquisser des architectures logicielles, concevoir des solutions et communiquer
des points de vue tout en unifiant des notations et les concepts orientés objets.
UML est une notation graphique conçue pour représenter, spécifier, construire et
documenter les systèmes logiciels. Ses deux principaux objectifs sont la modélisation
de systèmes utilisant les techniques orientées objet, depuis la conception jusqu’à la
maintenance, et la création d’un langage abstrait compréhensible par l’homme et
interprétable par les machines.
UML s’adresse à toutes les personnes chargées de la production, du déploiement et du
suivi de logiciels (analystes, développeurs, chefs de projets, architectes…), mais peut
également servir à la communication avec les clients et les utilisateurs du logiciel. Il
s’adapte à tous les domaines d’application et à tous les supports. Il permet de construire
plusieurs modèles d’un système, chacun mettant en valeur des aspects différents :
fonctionnels, statiques, dynamiques et organisationnels. UML est devenu un langage
incontournable dans les projets de développement.

1.2. Pourquoi faudra-t-il utiliser UML ?

Tout simplement parce que la majorité des nouveaux projets industriels utilisent la
notation UML. Pour convaincre les récalcitrants, je pourrais citer le nom des entreprises
appartenant au consortium ayant mis en place UML : DEC, HP, IBM, Microsoft, Oracle
et Unisys pour parler des plus connues. Tous les cursus universitaires informatique,
qu’ils soient théoriques ou plus techniques, incluent l’étude d’UML. Je pourrais enfin
évoquer le nombre d’ouvrages et d’articles parus sur le sujet… Cela ne signifie pas
qu’UML soit la panacée, mais que cette notation est devenue incontournable.

UML 2 reprend les concepts du modèle entité-association et propose en plus des artifices
pour améliorer la sémantique d’un schéma conceptuel (contraintes, classe-association,
stéréotype…). De ce fait, cette notation est très complète et puissante et peut s’adapter
parfaitement à la description statique d’une base de données.
Le problème qui se pose aux concepteurs d’applications sous UML est le pourquoi et le
comment de la transcription d’un diagramme de classes.

Peter SAMANO 0812440646 [email protected]

 7

1.3. Règles générales

Afin d’assurer un bon niveau de cohérence et d’homogénéité sur l’ensemble des
modèles, UML propose d’une part un certain nombre de règles d’écriture ou de
représentations graphiques normalisées et d’autre part des mécanismes ou des
concepts communs applicables à l’ensemble des diagrammes.
Certains éléments, comme les stéréotypes, sont spécifiquement prévus pour assurer une
réelle capacité d’adaptation et d’évolution de la notation notamment pour prendre en
compte les particularités des différentes situations à modéliser.
Les principaux éléments généraux d’UML que nous présentons sont : le stéréotype, la
valeur marquée, la note, la contrainte, et la relation de dépendance. En outre UML
propose un méta-modèle de tous les concepts et notations associées utilisés dans les
quatorze diagrammes du langage de modélisation.
1.3.1. Méta-modèle
Le langage de modélisation UML respecte un certain nombre de règles sur les
concepts manipulés (classes, attributs, opérations, paquetages…) ainsi que sur la
syntaxe d’écriture et le formalisme de représentation graphique. L’ensemble de ces
règles constitue en soi un langage de modélisation qui a fait l’objet d’un métamodèle
UML. L’intérêt de disposer d’un méta-modèle UML permet de bien maîtriser la
structure d’UML et de faciliter son évolution. Cette approche a été généralisée par
l’OMG en normalisant la représentation des méta-modèles par la définition en 1997 d’un
méta méta-modèle défini dans le MOF (Meta-Object Facility). Le MOF représente ainsi
un super langage de définition des méta-modèles et se retrouve au sommet d’une
architecture de description à quatre niveaux :
 M3, Niveau du MOF ;
 M2, niveau des méta-modèles (UML est un des méta-modèles) ;
 M1, constitué par les modèles (les diagrammes d’UML sont des instances de
ce niveau) ;
 M0, constitué par les instances (les réalisations de diagrammes pour une
situation donnée sont des instances de ce niveau).
Le méta-modèle d’UML est complètement décrit dans la norme.
1.3.2. Stéréotype
Un stéréotype constitue un moyen de classer les éléments de la modélisation. Mais
d’autres valeurs de stéréotypes peuvent être ajoutées si cela est nécessaire soit à
l’évolution générale d’UML, soit à la prise en compte de situations particulières propres
aux entreprises. Les stéréotypes peuvent s’appliquer à n’importe quel concept d’UML.
Cette possibilité d’extension pour les classes, se définit donc au niveau méta-classe.
Formalisme et exemple
Le nom du stéréotype est indiqué entre guillemets. Un acteur peut être vu comme un
stéréotype particulier d’une classe appelée acteur.

Peter SAMANO 0812440646 [email protected]

 8

1.3.3. Valeur marquée

UML permet d’indiquer des valeurs particulières au niveau des éléments de
modélisation et en particulier pour les attributs de classe. Une valeur marquée se
définit au niveau méta-attribut.
Formalisme et exemple : La valeur marquée est mise entre accolades avec indication
du nom et de la valeur : {persistance : string} si l’on veut ajouter ce type d’attribut
dans une classe.
1.3.4. Profil
Afin de donner la possibilité de spécialiser chaque application d’UML à son propre
contexte, UML propose de définir un profil d’utilisation caractérisé principalement
par la liste des stéréotypes, la liste des valeurs marquées et les contraintes spécifiées
pour un projet donné.
1.3.5. Note
Une note correspond à un commentaire explicatif d’un élément d’UML.
Formalisme et exemple

1.4. Présentation générale des diagrammes

UML 2 dispose de quatorze diagrammes pouvant être utilisés dans la description d’un
système. Ces diagrammes sont regroupés dans deux grands ensembles dont sept
structurels et sept comportementaux.
1.4.1. Les diagrammes structurels
 Diagramme de Classe
 Diagramme de Composants :
 Diagramme de Déploiement
 Diagramme d’Objets
 Diagramme de Paquetage
 Diagramme de Profil
 Diagramme de Structure composite
1.4.2. Les diagrammes comportementaux
 Cas d’utilisation
 Activité
 État
 Séquence
 Communication
 Présentation des interactions
 Diagramme de temps

Peter SAMANO 0812440646 [email protected]

 9

1.5. Les concepts objets et sa modélisation en UML.

Dans un premier temps, nous aborderons le concept d’objet, puis nous verrons, par
abstraction, comment le modéliser en UML.
La notion de classes, représentation commune d’un ensemble d’objets similaires, sera
introduite.
Nous évoquerons ensuite le principe d’encapsulation, masquage d’informations
internes et propres au fonctionnement de l’objet.
Les relations de spécialisation et de généralisation introduisant les hiérarchies de
classes seront décrites, ainsi que l’héritage, les classes concrètes et abstraites puis nous
aborderons le polymorphisme, conséquence directe de la spécialisation.
Enfin, nous évoquerons la composition d’objets avant de terminer sur une notion plus
spécifique à UML, la spécialisation des éléments du diagramme par les stéréotypes.
1.5.1. L’objet
Un objet est une entité identifiable du monde réel. Il peut avoir une existence physique
(un cheval, un livre) ou ne pas en avoir (un texte de loi). Identifiable signifie que
l’objet peut être désigné.

Exemple :
 mon téléphone
 Mon livre sur UML
 L’article 15 de la constitution
 Etc.
En UML, tout objet possède un ensemble d’attributs (sa structure) et un ensemble de
méthodes (son comportement).
 Un attribut est une variable destinée à recevoir une valeur.
 Une méthode est un ensemble d’instructions prenant des
valeurs en entrée et modifiant les valeurs des attributs ou produisant un résultat.
Même un objet statique du monde réel est toujours perçu comme dynamique.
Ainsi en UML, un livre est perçu comme un objet capable de s’ouvrir lui-même à la
énième page. Tout système conçu en UML est composé d’objets interagissant entre eux
et effectuant les opérations propres à leur comportement.
Exemple :
 Un troupeau de chevaux est un système d’objets interagissant entre eux,
chaque objet possédant son propre comportement.
 Un auditoire des étudiants …
 Etc.
Le comportement global d’un système est ainsi réparti entre les différents objets. Dans
notre exemple, il suffit de faire le parallèle avec le monde réel pour le comprendre.

Peter SAMANO 0812440646 [email protected]

 10

1.5.2. L’abstraction
L’abstraction est un principe très important en modélisation. Elle consiste à retenir
uniquement les propriétés pertinentes d’un objet pour un problème précis. Les objets
utilisés en UML sont des abstractions d’objets du monde réel.
Exemple. :
On s’intéresse aux chevaux pour l’activité de course. Les propriétés d’aptitude de
vitesse, d’âge et d’équilibre mental ainsi que l’élevage d’origine sont pertinentes pour
cette activité et sont retenues. On s’intéresse aux chevaux pour l’activité de trait. Les
propriétés d’âge, de taille, de force et de corpulence sont pertinentes pour cette activité
et sont retenues.
N.B : L’abstraction est une simplification indispensable au processus de modélisation. Un
objet UML est donc une abstraction de l’objet du monde réel par rapport aux besoins
du système, dont on ne retient que les éléments essentiels.

1.5.3. Les classes d’objets

Un ensemble d’objets similaires, c’est-à-dire possédant la même structure et le même
comportement et constitués des mêmes attributs et méthodes, forme une classe d’objets.
La structure et le comportement peuvent alors être définis en commun au niveau de la
classe. Chaque objet d’une classe, encore appelé instance de classe, se distingue par son
identité propre et possède des valeurs spécifiques pour ses attributs.
Exemple :
L’ensemble des chevaux constitue la classe Cheval qui possède la structure et le
comportement décrits à la figure ici présent :

Le cheval ayant par exemple le nom jack est une instance de la classe Cheval
dont les attributs et leurs valeurs sont :

Peter SAMANO 0812440646 [email protected]

 11

Le nom d’une classe apparaît au singulier. Il est toujours constitué d’un nom commun
précédé ou suivi d’un ou plusieurs adjectifs qualifiant le nom. Ce nom est significatif de
l’ensemble des objets constituant la classe.
1.5.4. L’encapsulation
L’encapsulation consiste à masquer des attributs et des méthodes de l’objet vis à vis des
autres objets. En effet, certains attributs et méthodes ont pour seul objectif des
traitements internes à l’objet et ne doivent pas être exposés aux objets
extérieurs. Encapsulés, ils sont appelés les attributs et méthodes privés de l’objet.
L’encapsulation est une abstraction puisque l’on simplifie la représentation de l’objet
vis à vis des objets extérieurs. Cette représentation simplifiée est constituée des attributs
et méthodes publiques de l’objet. La définition de l’encapsulation se fait au niveau de la
classe. Les objets extérieurs à un objet sont donc les instances des autres classes.
Exemple : Lorsqu’il court, un cheval va effectuer différents mouvements comme lever
les jambes, lever la tête, lever la queue. Ces mouvements sont internes au
fonctionnement de l’animal et n’ont pas à être connus à l’extérieur. Ce sont de méthodes
privées. Ces opérations accèdent à une partie interne du cheval : ses muscles, son
cerveau et sa vue. Cette partie interne est représentée sous la forme d’attributs privés.
L’ensemble de ces attributs et méthodes est illustré à la figure ici :

Dans la notation UML, les attributs et méthodes publics sont précédés du signe plus
tandis que les attributs et méthodes privés (encapsulés) sont précédés du signe moins.
1.5.5. La spécialisation et la généralisation
Jusqu’à présent, chaque classe d’objets est introduite séparément des autres classes. Une
classe peut également être définie comme un sous ensemble d’une autre classe, ce sous
ensemble devant toujours constituer un ensemble d’objets similaires. Il s’agit alors d’une
sous-classe d’une autre classe. Elle constitue ainsi une spécialisation de cette autre
classe.
Exemple : La classe des chevaux est une sous classe de la classe des mammifères.
La généralisation est la relation inverse de la spécialisation. Si une classe est une
spécialisation d’une autre classe, cette dernière est une généralisation de la première.
Elle en est sa surclasse. La relation de spécialisation peut s’appliquer à plusieurs
niveaux, donnant lieu à une hiérarchie de classes.

Peter SAMANO 0812440646 [email protected]

 12

Exemple : La classe des chevaux

est une sous-classe de la classe des
mammifères, elle même sous-
classe de la classe des animaux.
La classe des chiens est une autre
sous- classe de la classe des
mammifères. La hiérarchie
correspondante des classes est
représentée à la figure ici :

1.5.6. L’héritage

L’héritage est la propriété qui fait bénéficier à une sous-classe de la structure et du

comportement de sa surclasse. L’héritage provient du fait qu’une sous-classe est un
sous-ensemble de sa surclasse. Ses instances sont également instances de sa surclasse.
En conséquence, elles bénéficient de la structure et du comportement définis dans cette
surclasse, en plus de la structure et du comportement introduits au niveau de la sous--
classe.
Exemple : Soit un système où la classe Cheval est une sous-classe directe de la classe
Animal, un cheval est alors décrit par la combinaison de la structure et du comportement
issus des classes Cheval et Animal, c’est à dire avec les attributs âge, taille, poids, nom
et élevage ainsi que les méthodes manger et courir. Cet héritage est illustré à la figure
ici :

L’héritage est une conséquence de

la spécialisation. Cependant, les
informaticiens emploient beaucoup
plus souvent le terme hérite que
spécialise pour désigner la relation
entre une sous-classe et sa
surclasse.

1.5.7. Les classes abstraites et concrètes

 Classe abstrait
Une classe abstraite est une classe qui n’a pas d’instance directe mais dont les classes
descendantes ont des instances. Dans une relation d’héritage, la super-classe est par
définition une classe abstraite. Une classe abstraite contient au moins une méthode
abstraite.
 Classe concrète
Un ensemble d’objets similaires, c’est-à-dire possédant la même structure et le même
comportement et constitués des mêmes attributs et méthodes, forme une classe
d’objets.

Peter SAMANO 0812440646 [email protected]

 13

1.6. Le polymorphisme
C’est la capacité donnée à une même opération de s’exécuter différemment suivant le
contexte de la classe où elle se trouve. Ainsi une opération définie dans une super-classe
peut s’exécuter de manière différente selon la sous-classe où elle est héritée. EX. La
méthode caresser a un comportement différent selon que le cheval est instance de
Cheval Sauvage ou de Cheval Domestiqué.

1.7. La composition
Un objet peut être complexe et composé d’autres objets. L’association qui unit alors ces
objets est la composition. Elle se définit au niveau de leurs classes mais les liens sont
bâtis entre les instances des classes. La composition, appelée également « agrégation
composite ». EX. Un cheval est un exemple d’objet complexe. Il est constitué de ses
différents organes

La composition peut prendre deux formes : La composition faible ou agrégation et la

composition forte. Dans la composition faible, les composants peuvent être partagés
entre plusieurs objets complexes. Dans la composition forte, les composants ne peuvent
être partagés et la destruction de l’objet composé entraîne la destruction de ses
composants. Une composition se distingue d’une association par l’ajout d’un losange
plein du côté de l’agrégat. La multiplicité du côté de l’agrégat ne peut prendre que deux
valeurs : 0 ou 1. Par défaut, la multiplicité vaut 1.

1.8. DÉPENDANCE
Une dépendance est une relation unidirectionnelle exprimant une dépendance
sémantique entre les éléments du modèle. Elle est représentée par un trait discontinu
orienté. Elle indique que la modification de la cible implique le changement de la source.

Peter SAMANO 0812440646 [email protected]

 14

CHAPITRE 2. PROCESSUS ET ARCHITECTURE

2.1. Introduction aux processus unifiés

UML a ouvert le terrain de l’unification en fusionnant les notations et en apportant

précision et rigueur à la définition des concepts introduits. L’introduction d’UML a
apporté un élan sans précédent à la technologie objet, puisqu’elle y propose un standard
de niveau industriel. Il reste cependant à définir le processus pour réellement capitaliser
des règles dans le domaine du développement logiciel.

2.2. Processus de développement logiciel

Un processus définit une séquence d’étapes, en partie 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. En conséquence, le
processus peut se décomposer suivant deux axes de contrôle sur le développement :
 L’axe de développement technique, qui se concentre principalement sur la qualité
de la production ;
 L’axe de gestion du développement, qui permet la mesure et la prévision des
coûts et des délais.
1) Processus unifié (Unified Process)
Un processus unifié est un processus de développement logiciel construit sur
UML; il est itératif et incrémental, centré sur l’architecture, conduit par les cas
d’utilisation et piloté par les risques. La gestion d’un tel processus est organisée d’après
les 4 phases suivantes: préétude (inception), élaboration, construction et transition.
Ses activités de développement sont définies par 6 disciplines fondamentales si après :
La modélisation métier, la capture des besoins, l’analyse et la conception,
l’implémentation, le test et le déploiement.

2) La définition d’un processus UP

Est donc constituée de plusieurs disciplines d’activité de production et de contrôle de
cette production. Tout processus UP répond aux caractéristiques ci-après.
Il est itératif et incrémental. La définition d’itérations de réalisation est en
effet la meilleure pratique de gestion des risques d’ordre à la fois technique et
fonctionnel. On peut estimer qu’un projet qui ne produit rien d’exécutable dans
les 9 mois court un risque majeur d’échec. Chaque itération
garantit que les équipes sont capables d’intégrer l’environnement technique pour
développer un produit final et fournit aux utilisateurs un résultat
tangible de leurs spécifications. Le suivi des itérations constitue par
ailleurs un excellent contrôle des coûts et des délais.

Peter SAMANO 0812440646 [email protected]

 15

Il est piloté par les risques. Dans ce cadre, les causes majeures d’échec d’un projet
logiciel doivent être écartées en priorité. Nous identifions une première cause provenant
de l’incapacité de l’architecture technique à répondre aux contraintes opérationnelles, et
une seconde cause liée à l’inadéquation du développement aux besoins des utilisateurs.

Il est construit autour de la création et de la maintenance d’un modèle, plutôt que

de la production de montagnes de documents. Le volume d’informations de ce
modèle nécessite une organisation stricte qui présente les différents points de vue
du logiciel à différents degrés d’abstraction. L’obtention de métriques sur le
modèle fournit par ailleurs des moyens objectifs d’estimation.
Il est orienté composant. Tant au niveau modélisation que production,
c’est une garantie de souplesse pour le modèle lui-même et le logiciel qu’il
représente. Cette pratique constitue le support nécessaire à la réutilisation
logicielle et offre des perspectives de gains non négligeables.
Il est orienté utilisateur, car la spécification et la conception sont construites à
partir des modes d’utilisation attendus par les acteurs du système.
2.3. Le processus 2TUP
2TUP signifie « 2 Track Unified Process ». C’est un processus UP qui répond
aux caractéristiques que nous venons de citer. 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 de changement imposés au système
informatique.
 Le système d’information soumis à deux natures de contraintes

L’axiome fondateur du 2TUP consiste à constater que toute évolution imposée

au système d’information peut se décomposer et se traiter parallèlement, suivant un axe
fonctionnel et un axe technique. Pour illustrer cet axiome, prenons les trois exemples
suivants :
1. une agence de tourisme passe des accords avec une compagnie aérienne de
sorte que le calcul des commissions change. En l’occurrence, les résultats
issus de la branche fonctionnelle qui évoluent pour prendre en compte la
nouvelle spécification ;

Peter SAMANO 0812440646 [email protected]

 16

2. cette même entreprise décide d’ouvrir la prise de commande sur le Web. Si

rien ne change fonctionnellement, en revanche, l’architecture technique du
système évolue ;
3. Cette entreprise décide finalement de partager son catalogue de prestations
avec les vols de la compagnie aérienne. D’une part, la fusion des deux
sources d’informations imposera une évolution de la branche fonctionnelle, d’autre part,
les moyens techniques de synchronisation des deux systèmes conduiront à étoffer
l’architecture technique du système. L’étude de ces évolutions pourra être menée
indépendamment, suivant les deux branches du 2TUP. À 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 deux branches. Cette fusion conduit à l’obtention d’un
processus de développement en forme de Y, comme illustré si dessous.
 Le processus de développement en Y

2.3.1. La branche gauche (fonctionnelle) comporte :

 La capture des besoins fonctionnels, qui produit un modèle des besoins focalisé
sur le métier des utilisateurs. Elle qualifie au plus tôt le risque de produire un système
inadapté aux utilisateurs. De son côté, la maîtrise d’œuvre consolide les spécifications
et en vérifie la cohérence et l’exhaustivité 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.
2.3.2. La branche droite (architecture technique) comporte :

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

Peter SAMANO 0812440646 [email protected]

 17

L’architecture technique construit le squelette du système informatique et écarte la

plupart des risques de niveau technique. L’importance de sa réussite est telle qu’il est
conseillé de réaliser un prototype pour assurer sa validité.
2.3.3. La branche du milieu comporte :
 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é.
2.4. Les branches du “y” produisent des modèles réutilisables
La branche gauche 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’informations sont en effet indépendantes des technologies utilisées.
La branche droite capitalise quant à elle un savoir-faire technique. Elle constitue un
investissement pour le court et le moyen terme. Les techniques développées pour le
système peuvent l’être en effet indépendamment des fonctions à réaliser. L’architecture
technique est d’ailleurs de moins en moins la préoccupation des services informatiques
dont l’entreprise n’a pas vocation à produire du code. L’existence de produits tels que
les serveurs d’application ou la standardisation des services Web reflète cette tendance
à pouvoir disposer sur le marché d’architectures techniques « prêtes à intégrer ». Une
architecture technique est en effet immédiatement réutilisable pour les différentes
composantes fonctionnelles d’un même système d’entreprise.
Un processus piloté par les exigences des utilisateurs
Un bon nombre de risques proviennent de la non-adéquation technique et fonctionnelle
du système aux besoins des utilisateurs. Les exigences des utilisateurs sont donc
prioritairement traitées dans les deux branches du processus en Y en considérant deux
types d’acteurs différents du système informatique :
 l’utilisateur consommateur des fonctions du système, qui correspond
généralement à un poste, un rôle ou un métier dans l’entreprise. Il convient
dans ce cadre de se focaliser sur la plus-value que lui apporte le système dans l’exercice
de sa profession ;
 l’utilisateur exploitant le système, qui correspond plutôt à un rôle technique
et opérationnel commun à la plupart des systèmes informatiques. Dans le domaine
client/serveur, les utilisateurs, considérés au sens large, attendent des performances, une
tenue à la charge, une sécurité d’accès, etc. L’axe technique permet également
d’introduire le point de vue des exploitants et des administrateurs souvent oubliés dans
la livraison finale d’un produit. L’enjeu du processus en Y est donc de développer le
point de vue utilisateur et de construire la spécification puis la conception objet à partir
des concepts maniés par les acteurs du système.

Peter SAMANO 0812440646 [email protected]

 18

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.

 Influence des cas d’utilisation dans le processus en

Au travers des cas d’utilisation, le point de vue utilisateur a donc bien le rôle
d’initiation souhaité pour une conception. Vous noterez par ailleurs que
l’orientation métier imposée par les cas d’utilisation de la branche gauche
renforce la plus-value apportée par le système et introduit une dimension
d’analyse de la valeur. Le pilotage par les cas d’utilisation consiste justement à ordonner
les cas d’utilisation par priorité, de manière à organiser les itérations par valeur ajoutée.
En phase de construction notamment, c’est une bonne pratique d’inclure les cas
d’utilisation les plus prioritaires en réalisation des premières itérations, puis de continuer
par ordre de priorité. En apportant au plus tôt le maximum de valeur ajoutée au système,
on rentabilise plus rapidement le développement, ce qui est encore une manière de
réduire les risques.

CHAPITRE 3. LA MODELISATION DES EXIGENCES

Ce chapitre a pour objectif de vous faire découvrir les cas d’utilisation employés pour
décrire les exigences fonctionnelles attendues, lors de la rédaction du cahier des charges
d’un système, ou les fonctionnalités d’un système existant. L’ensemble des cas
d’utilisation d’un système contient les exigences fonctionnelles attendues ou existantes,
les acteurs (utilisateurs du système) ainsi que les relations qui unissent acteurs et
fonctionnalités. Cet ensemble détermine également les frontières du système, à savoir
les fonctionnalités remplies par le système et celles qui lui sont externes.
Les cas d’utilisation servent de support pour les étapes de modélisation, de
développement et de validation. Ils constituent un référentiel du dialogue entre les
informaticiens et les clients et, par conséquent, une base pour l’élaboration au niveau
fonctionnel du cahier des charges.

Peter SAMANO 0812440646 [email protected]

 19

3.1. Cas d’utilisation ou Diagramme de cas d’utilisation

Les cas d’utilisation décrivent sous la forme d’actions et de réactions, le comportement

du système étudié du point de vue des utilisateurs. Ils définissent les limites du système
et ses relations avec son environnement. Ils constituent un moyen de recueillir et de
décrire les besoins des acteurs du système. Ils peuvent être aussi utilisés ensuite comme
moyen d’organisation du développement du logiciel, notamment pour la structuration et
le déroulement des tests du logiciel. Un cas d’utilisation permet de décrire l’interaction
entre les acteurs (utilisateurs du cas) et le système. La description de l’interaction est
réalisée suivant le point de vue de l’utilisateur. La représentation d’un cas d’utilisation
met en jeu trois concepts : l’acteur, le cas d’utilisation et l’interaction entre l’acteur et le
cas d’utilisation.

3.2. Acteur

Un acteur est un utilisateur type qui a toujours le même comportement vis-à-vis d’un
cas d’utilisation. Ainsi les utilisateurs d’un système appartiennent à une ou plusieurs
classes d’acteurs selon les rôles qu’ils tiennent par rapport au système. Une même
personne physique peut se comporter en autant d’acteurs différents que le nombre de
rôles qu’elle joue vis-à-vis du système. Ainsi par exemple, l’administrateur d’un
système de messagerie peut être aussi utilisateur de cette même messagerie. Il sera
considéré, en tant qu’acteur du système, dans le rôle d’administrateur d’une part et dans
celui d’utilisateur d’autre part. Un acteur peut aussi être un système externe avec lequel
le cas d’utilisation va interagir.

Formalisme et exemple
Un acteur peut se représenter symboliquement par un « bonhomme » et être identifié
par son nom. Il peut aussi être formalisé par une classe stéréotypée « acteur »

Acteur non
humain

Un cas d’utilisation correspond à un certain nombre d’actions que le système devra

exécuter en réponse à un besoin d’un acteur. Un cas d’utilisation doit produire un résultat
observable pour un ou plusieurs acteurs ou parties prenantes du système. Une interaction
permet de décrire les échanges entre un acteur et un cas d’utilisation.

Peter SAMANO 0812440646 [email protected]

 20

Relation de communication

La relation qui lie un acteur à un cas d’utilisation

S’appelle la relation de communication. Cette relation supporte différents modèles de
communication, par exemple :
 Les services que le système doit fournir à chacun des acteurs du cas d’utilisation ;
 Les informations du système qu’un acteur peut introduire, consulter ou modifier ;
 Les changements intervenant dans l’environnement dont un acteur informe le
système ;
 Les changements intervenant au sein du système dont ce dernier informe un acteur.
Le formalisme de base de représentation d’un cas d’utilisation

Chaque cas d’utilisation doit être décrit sous forme textuelle afin de bien identifier les
traitements à réaliser par le système en vue de la satisfaction du besoin exprimé par
l’acteur. Exemple d’un diagramme de cas d’utilisation modélisant une borne d’accès à
une banque

Peter SAMANO 0812440646 [email protected]

 21

3.3. Un classeur
Est un élément de modélisation qui décrit une unité comportementale ou structurelle.

Exemple un internaute qui télécharge plusieurs morceaux de musique sur Internet

3.4. Scénario

Un scénario est une instance d’un cas d’utilisation dans laquelle toutes les conditions
relatives aux différents événements ont été fixées. Il n’y a donc pas d’alternatives lors
du déroulement. À un cas d’utilisation donné correspondent plusieurs scénarios. Comme
une classe qui détient les aspects communs de ses instances, un cas d’utilisation décrit
de façon commune l’ensemble de ses scénarios en utilisant des branchements
conditionnels pour représenter les différentes alternatives.

Peter SAMANO 0812440646 [email protected]

 22

3.5. Les relations entre les cas d’utilisation

 La relation d’inclusion

Sert à enrichir un cas d’utilisation par un autre cas d’utilisation. Cet enrichissement est
réalisé par une inclusion impérative, il est donc systématique. Le cas d’utilisation inclus
existe uniquement dans ce but. En effet, il ne répond pas à un objectif d’un acteur
primaire. Un tel cas d’utilisation est une sous­fonction. L’inclusion sert à partager une
fonctionnalité commune entre plusieurs cas d’utilisation Elle peut également être
employée pour structurer un cas d’utilisation en décrivant ses sous­fonctions.

Exemple

 Une relation d’extension

Comme la relation d’inclusion, la relation d’extension enrichit un cas d’utilisation par
un cas d’utilisation de sous­fonction. Cet enrichissement est analogue à celui de la
relation d’inclusion mais il est optionnel.

 La spécialisation et la généralisation des cas d’utilisation

3.6. La représentation textuelle des cas d’utilisation
À chaque cas d’utilisation doit être associée une description textuelle des interactions
entre l’acteur et le système et les actions que le système doit réaliser en vue de produire
les résultats attendus par les acteurs
 Le nom du cas d’utilisation ;
 L’acteur primaire ;
 Le système concerné par le cas d’utilisation ;
 Les intervenants (ensemble des acteurs) ;
 Le niveau du cas d’utilisation pouvant être soit :
 Un objectif utilisateur ;
 Ou une sous­fonction ;

Peter SAMANO 0812440646 [email protected]

 23

 Les préconditions qui sont les conditions à remplir pour que le cas d’utilisation
puisse
 être exécuté ;
 Les opérations du scénario principal ;
 Les extensions.

Exemple
Une bibliothèque universitaire souhaite automatiser sa gestion. Cette bibliothèque est
gérée par un gestionnaire chargé des inscriptions et des relances des lecteurs quand ceux-
ci n’ont pas rendu leurs ouvrages au-delà du délai autorisé. Les bibliothécaires sont
chargés de gérer les emprunts et la restitution des ouvrages ainsi que l’acquisition de
nouveaux ouvrages.

Il existe trois catégories d’abonné. Tout d’abord les étudiants qui doivent seulement
s’acquitter d’une somme forfaitaire pour une année afin d’avoir droit à tous les services
de la bibliothèque. L’accès à la bibliothèque est libre pour tous les enseignants. Enfin,
il est possible d’autoriser des étudiants d’une autre université à s’inscrire
exceptionnellement comme abonné moyennant le versement d’une cotisation. Le
nombre d’abonné externe est limité chaque année à environ 10 % des inscrits. Un
nouveau service de consultation du catalogue général des ouvrages doit être mis en
place. Les ouvrages, souvent acquis en plusieurs exemplaires, sont rangés dans des
rayons de la bibliothèque. Chaque exemplaire est repéré par une référence gérée dans le
catalogue et le code du rayon où il est rangé Chaque abonné ne peut emprunter plus de
trois ouvrages. Le délai d’emprunt d’un ouvrage est de trois semaines, il peut cependant
être prolongé exceptionnellement à cinq semaines. Il est demandé d’élaborer le
diagramme des cas d’utilisation (DCU).

Corrigé
Cas d’utilisation peuvent être identifiés :
 Inscription à la bibliothèque,
 Consultation du catalogue,
 Emprunt d’ouvrages,
 Restitution d’ouvrages,
 Approvisionnement d’ouvrages,
 Relance emprunteur.
Cinq types d’acteurs peuvent être identifiés :
 Etudiant,
 Externe,
 Emprunteur,
 Gestionnaire,
 Bibliothécaire

Peter SAMANO 0812440646 [email protected]

 24

 Conclusion
Les cas d’utilisation servent à :

 Exprimer les exigences fonctionnelles conférées au système par les utilisateurs

lors de la rédaction du cahier des charges ;
 Vérifier que le système répond à ces exigences lors de la livraison ;
 Déterminer les frontières du système ;
 Ecrire la documentation du système ;
 Construire les jeux de test.
Les cas d’utilisation offrent une technique de représentation qui convient au dialogue
avec l’utilisateur car son formalisme reste proche du langage naturel. Il est conseillé d’y
adjoindre un lexique pour éviter les risques de confusion. Nous étudierons par la suite
comment découvrir les objets en utilisant les diagrammes de séquence associés aux cas
d’utilisation.

Peter SAMANO 0812440646 [email protected]

 25

 CHAPITRE 4. LA MODELISATION DE LA DYNAMIQUE

Ce chapitre a pour objectif de vous faire découvrir comment UML représente les
interactions entre les objets. UML propose deux diagrammes pour répondre à ce
besoin de représentation des interactions entre objets :

 Le diagramme de séquence se focalise sur les aspects temporels.

 Le diagramme de communication se focalise sur la représentation spatiale
Nous examinerons ensuite comment découvrir progressivement les objets
composant un système. Cette découverte sera basée sur les interactions entre objets
intervenant dans les cas d’utilisation du système. Pour représenter ces interactions,
nous ferons le choix du diagramme de séquence, cette option ayant très souvent la
faveur des personnes chargées de la modélisation d’un projet.

Le diagramme de communication porte ce nom depuis UML 2. En UML 1, il

s’appelait diagramme de collaboration.

4.1. Le diagramme de séquence

Le diagramme de séquence décrit les interactions entre un groupe d’objets en montrant,
de façon séquentielle, les envois de message qui interviennent entre les objets. Le
diagramme peut également montrer les flux de données échangées lors des envois de
message.
Pour interagir entre eux, les objets s’envoient des messages. Lors de la réception d’un
message, un objet devient actif et exécute la méthode de même nom. Un envoi de
message est donc un appel de méthode.
Un diagramme de séquence se représente globalement dans un grand rectangle avec
indication du nom du diagramme en haut à gauche comme indiqué ici :

Peter SAMANO 0812440646 [email protected]

 26

4.1.1. Ligne de vie

Une ligne de vie représente l’ensemble des opérations exécutées par un objet. Un
message reçu par un objet déclenche l’exécution d’une opération. Le retour
d’information peut être implicite (cas général) ou explicite à l’aide d’un message de
retour
4.1.2. Message synchrone et asynchrone
Dans un diagramme de séquence, deux types de messages peuvent être distingués :
 Message synchrone : Dans ce cas l’émetteur reste en attente de la réponse à son
message avant de poursuivre ses actions. La flèche avec extrémité pleine
symbolise ce type de message. Le message retour peut ne pas être représenté car
il est inclus dans la fin d’exécution de l’opération de l’objet destinataire du
message.
 Message asynchrone : Dans ce cas, l’émetteur n’attend pas la réponse à son
message, il poursuit l’exécution de ses opérations. C’est une flèche avec une
extrémité non pleine qui symbolise ce type de message.

Formalisme et exemple

 Il existe différents types d’envois de message.

Peter SAMANO 0812440646 [email protected]

 27

4.1.3. Opérations particulières

 Création et destruction d’objet

Si un objet est créé par une opération, celui-ci n’apparaît qu’au moment où il est créé.
Si l’objet est détruit par une opération, la destruction se représente par « X ». Par
exemple :

4.1.4. L’envoi de message

Les envois de message sont représentés par des flèches horizontales reliant la ligne de
vie de l’objet émetteur à la ligne de vie de l’objet destinataire.

4.2. Le diagramme de communication

Le diagramme de communication est une alternative au diagramme de séquence. Il se

focalise sur une représentation spatiale des objets. Chaque objet intervient dans ce
diagramme de la même façon que dans le diagramme de séquence. Il n’est pas associé
à une ligne de vie mais relié graphiquement aux objets avec lesquels il interagit.
Les envois de messages sont placés le long des liens interobjets. Les messages sont
obligatoirement numérotés, la numérotation composée étudiée dans le cadre des
diagrammes de séquence pouvant également être employée. Les diagrammes de
communication vous permettent d'explorer le fonctionnement des objets dans un

Peter SAMANO 0812440646 [email protected]

 28

système ou une application. Ils peuvent identifier les aspects suivants d'une interaction
ou d'une tâche :
 Les objets qui participent à l'interaction
 Les interfaces que les classes participantes requièrent
 Les changements de structure requis par une interaction
 Les données transmises entre les objets dans une interaction

Les diagrammes de communication ressemblent aux diagrammes d'objets dans lesquels

une ligne de vie représente les objets de l'interaction et les flèches représentent les
messages transmis entre les lignes de vie. Les pointes de flèches indiquent la direction
des messages et les numéro de séquence indiquent l'ordre de transmission des messages.

Exemple de la connexion à site web

Peter SAMANO 0812440646 [email protected]

 29

CHAPITRE 5. LA MODELISATION DES OBJETS

L’objectif de ce chapitre est de vous faire découvrir les techniques UML de modélisation
statique des objets. Cette modélisation est statique car elle ne décrit pas les interactions
ou le cycle de vie des objets. Les méthodes sont introduites d’un point de vue statique,
sans description de leur enchaînement. Nous découvrirons le diagramme des classes. Ce
diagramme contient les attributs, les méthodes et les associations des objets.

Le diagramme de classe est central lors d’une modélisation par objets d’un système.
De tous les diagrammes UML, il est le seul obligatoire lors d’une telle modélisation.
Nous étudierons comment le langage OCL (Object Constraint Language ou langage de
contraintes objet) peut étendre le diagramme des classes pour exprimer de façon plus
riche les contraintes. Enfin, le diagramme des objets nous montrera comment illustrer la
modélisation réalisée dans le diagramme des classes.
L’emploi d’OCL ou du diagramme des objets est optionnel. Leur utilisation dépend des
contraintes du projet de modélisation

5.1. Diagramme de classe

Le diagramme de classes est considéré comme le plus important de la modélisation

orientée objet. Alors que le diagramme de cas d’utilisation montre un système du point
de vue des acteurs, le diagramme de classes en montre la structure interne. Il contient
principalement des classes. Une classe contient des attributs et des opérations. Le
diagramme de classes n’indique pas comment utiliser les opérations : c’est une
description purement statique d’un système. L’aspect dynamique de la modélisation est
apporté par les diagrammes d’interactions. La description du diagramme de classe est
fondée sur :
 Le concept d’objet,
 Le concept de classe comprenant les attributs et les opérations,
 Les différents types d’association entre classes.
5.1.1. La représentation des classes

Peter SAMANO 0812440646 [email protected]

 30

 La première partie contient le nom de la classe.

Rappelons que le nom d’une classe est au singulier. Il est toujours constitué d’un nom
commun précédé ou suivi d’un ou plusieurs adjectifs qualifiant le nom. Ce nom est
significatif de l’ensemble des objets constituant la classe. Il représente la nature des
instances d’une classe.
 La deuxième partie contient les attributs.
Ceux-ci contiennent l’information portée par un objet. L’ensemble des attributs forme
la structure de l’objet.
 La troisième partie contient les méthodes.
Celles-ci correspondent aux services offerts par l’objet. Elles peuvent modifier la valeur
des attributs. L’ensemble des méthodes forme le comportement de l’objet.
Le nombre d’attributs et de méthodes est variable selon chaque classe. Toutefois, un
nombre élevé d’attributs et/ou de méthodes est déconseillé. Il ne reflète pas, en général,
une bonne conception de la classe.
5.1.2. Objet
Nous allons donner une première définition du concept d’objet avant de traiter le concept
de classe. La description d’un objet sera complétée simultanément à la présentation du
concept de classe. Un objet est un concept, une abstraction ou une chose qui a un sens
dans le contexte du système à modéliser. Chaque objet a une identité et peut être
distingué des autres sans considérer a priori les valeurs de ses propriétés. Ainsi l’objet
peut être concret ou abstrait et doit tirer son existant du monde réel.

Un objet est caractérisé par les valeurs de ses propriétés qui lui confèrent des états
significatifs suivant les instants considérés.

5.1.3. Attribut et Opération

 Attribut

Un attribut est une propriété élémentaire d’une classe. Pour chaque objet d’une classe,
l’attribut prend une valeur (sauf cas d’attributs multivalués).

Peter SAMANO 0812440646 [email protected]

 31

 Opération

Une opération est une fonction applicable aux objets d’une classe. Une opération permet
de décrire le comportement d’un objet. Une méthode est l’implémentation d’une
opération.

5.1.4. Caractéristiques

Le nom de la classe peut être qualifié par un « stéréotype ». La description complète des
attributs d’une classe comporte un certain nombre de caractéristiques qui doivent
respecter le formalisme suivant :
Visibilité/Nom attribut : type [= valeur initiale {propriétés}]
 Visibilité : se reporter aux explications données plus loin sur ce point.
 Nom d’attribut : nom unique dans sa classe.
 Type : type primitif (entier, chaîne de caractères…) dépendant des types disponibles
dans le langage d’implémentation ou type classe matérialisant un lien avec une autre
classe.
 Valeur initiale : valeur facultative donnée à l’initialisation d’un objet de la classe.
{propriétés} : valeurs marquées facultatives (ex. : « interdit » pour mise à jour interdite).

5.1.6. Visibilité des attributs et opérations

Chaque attribut ou opération d’une classe peut être de type public, protégé, privé ou
paquetage. Les symboles + (public), # (protégé), - (privé) et ~ (paquetage) sont
indiqués devant chaque attribut ou opération pour signifier le type de visibilité autorisé
pour les autres classes. Les droits associés à chaque niveau de confidentialité sont :
 Public (+) : Attribut ou opération visible par tous.
 Protégé (#) : Attribut ou opération visible seulement à l’intérieur de la classe et
pour toutes les sous-classes de la classe.
 Privé (-) : Attribut ou opération seulement visible à l’intérieur de la classe.
 Paquetage (~) : Attribut ou opération ou classe seulement visible à l’intérieur
du paquetage où se trouve la classe.

Peter SAMANO 0812440646 [email protected]

 32

5.1.7. Association, multiplicité, navigabilité et contraintes

 Lien et association
Un lien est une connexion physique ou conceptuelle entre instances de classes donc entre
objets. Une association décrit un groupe de liens ayant une même structure et une même
sémantique. Un lien est une instance d’une association. Chaque association peut être
identifiée par son nom. Une association entre classes représente les liens qui existent
entre les instances de ces classes.
Formalisme et exemple

Rôle d’association
Le rôle tenu par une classe vis-à-vis d’une association peut être précisé sur l’association.
 Multiplicité

La multiplicité indique un domaine de valeurs pour préciser le nombre d’instance d’une

classe vis-à-vis d’une autre classe pour une association donnée.
 Valeur indéterminée notée * – Exemple : 1..*.

Dans le cas où l’on utilise seulement *, cela traduit une multiplicité 0..*.
Dans le cas de multiplicité d’associations, il faut indiquer les valeurs minimale et
maximale d’instances d’une classe vis-à-vis d’une instance d’une autre classe.

Peter SAMANO 0812440646 [email protected]

 33

 Navigabilité

La navigabilité indique si l’association fonctionne de manière unidirectionnelle ou

bidirectionnelle, elle est matérialisée par une ou deux extrémités fléchées. La non
navigabilité se représente par un « X ».

Par défaut, on admet qu’une navigabilité non définie correspond à une navigabilité
implicite.
 Contraintes

D’autres propriétés particulières (contraintes) sont proposées dans UML pour préciser
la sémantique d’une association.
Ordre de tri
Pour une association de multiplicité supérieure à 1, les liens peuvent être :
 Non ordonnés (valeur par défaut),
 Ordonnés ou triés lorsque l’on est au niveau de l’implémentation (tri sur une
valeur interne).
Dans cet exemple, pour une entreprise donnée, les personnes seront enregistrées suivant
un ordre qui correspondra à un des attributs de Personne.

Propriétés de mise à jour de liens

Il est possible d’indiquer des contraintes particulières relatives aux conditions de mise à
jour des liens.

Peter SAMANO 0812440646 [email protected]

 34

 {interdit} : interdit l’ajout, la suppression ou la mise à jour des liens.

 {ajout seul} : n’autorise que l’ajout de liens.

5.1.8. Association de dimension supérieure à 2 et classe-association

Une association de dimension supérieure à 2 se représente en utilisant un losange
permettant de relier toutes les classes concernées. Une classe-association permet de
décrire soit des attributs soit des opérations propres à l’association. Cette classe-
association est elle-même reliée par un trait en pointillé au losange de connexion. Une
classe-association peut être reliée à d’autres classes d’un diagramme de classes.
Un exemple d’une association de dimension 3 comprenant une classe-association «
Affectation ». La classe-association Affectation permet de décrire les attributs propres
à l’association de dimension 3 représentée.

5.1.9. Agrégation et composition entre classes

 Agrégation

L’agrégation est une association qui permet de représenter un lien de type « ensemble »
comprenant des « éléments ». Il s’agit d’une relation entre une classe représentant le
niveau « ensemble » et 1 à n classes de niveau « éléments ». L’agrégation représente un
lien structurel entre une classe et une ou plusieurs autres classes.

Peter SAMANO 0812440646 [email protected]

 35

Un exemple de relation d’agrégation. Dans cet exemple, nous avons modélisé le fait
qu’un ordinateur comprend une UC,

 Composition

La composition est une relation d’agrégation dans laquelle il existe une contrainte de
durée de vie entre la classe « composant » et la ou les classes « composé ». Autrement
dit la suppression de la classe « composé » implique la suppression de la ou des classes
« composant ». Formalisme et exemple

5.1.10 Association qualifiée, dépendance et classe d’interface

 Qualification

La qualification d’une relation entre deux classes permet de préciser la sémantique de

l’association et de qualifier de manière restrictive les liens entre les instances. Seules les
instances possédant l’attribut indiqué dans la qualification sont concernées par
l’association. Cet attribut ne fait pas partie de l’association.

Peter SAMANO 0812440646 [email protected]

 36

Formalisme et exemple

 Dépendance

La dépendance entre deux classes permet de représenter l’existence d’un lien

sémantique. Une classe B est en dépendance de la classe A si des éléments de la classe
A sont nécessaires pour construire la classe B.
Formalisme et exemple

 Interface

Une classe d’interface permet de décrire la vue externe d’une classe. La classe
d’interface, identifiée par un nom, comporte la liste des opérations accessibles par les
autres classes. Le compartiment des attributs ne fait pas partie de la description d’une
interface. L’interface peut être aussi matérialisée plus globalement par un petit cercle
associé à la classe source. La classe utilisatrice de l’interface est reliée au symbole de
l’interface par une flèche en pointillé. La classe d’interface est une spécification et non
une classe réelle. Une classe d’interface peut s’assimiler à une classe abstraite.

Peter SAMANO 0812440646 [email protected]

 37

Formalisme et exemple

5.1.11. Généralisation et spécialisation et l’héritage simple

 La généralisation

est la relation entre une classe et deux autres classes ou plus partageant un sous-ensemble
commun d’attributs et/ou d’opérations. La classe qui est affinée s’appelle super-classe,
les classes affinées s’appellent sous-classes. L’opération qui consiste à créer une super
classe à partir de classes s’appelle la généralisation. Inversement la spécialisation
consiste à créer des sous-classes à partir d’une classe.
Formalisme et exemple
 La sous-classe A1 hérite de A, c’est une spécialisation de A ;
 La sous-classe A2 hérite de A, c’est une spécialisation

L’héritage permet à une sous-classe de disposer des attributs et opérations de la classe

dont elle dépend. Un discriminant peut être utilisé pour exploiter le critère de
spécialisation entre une classe et ses sous-classes. Le discriminant est simplement
indiqué sur le schéma, puisque les valeurs prises par ce discriminant correspondent à
chaque sous-classe.

Peter SAMANO 0812440646 [email protected]

 38

 Classe abstraite

Une classe abstraite est une classe qui n’a pas d’instance directe mais dont les classes
descendantes ont des instances. Dans une relation d’héritage, la super-classe est par
définition une classe abstraite. C’est le cas de la classe Employé dans l’exemple présenté
ici :

 L’héritage avec recouvrement

Par défaut, les sous-classes ont des instances disjointes les unes par rapport aux autres.
Dans certains cas, il existe un recouvrement d’instances entre les sous-classes. D’une
manière générale, quatre situations peuvent se rencontrer et se représentent sous forme
de contraintes :
 {chevauchement} : deux sous-classes peuvent avoir, parmi leurs instances, des
instances identiques ;
 {disjoint} : les instances d’une sous-classe ne peuvent être incluses dans une
autre sous-classe de la même classe ;
 {complète} : la généralisation ne peut pas être étendue ;
{incomplète} : la généralisation peut être étendue.
Dans certains cas, il est possible de ne pas citer toutes les sous-classes mais d’indiquer
seulement des points de suspension (…).

Peter SAMANO 0812440646 [email protected]

 39

Formalisme et exemple
Exemple d’héritage avec recouvrement d’instances entre les classes Étudiant et
Employé. En effet, une même personne peut être à la fois étudiante dans une université
et employée dans une entreprise.

Extension et restriction de classe

L’ajout de propriétés dans une sous-classe correspond à une extension de classe. Le

masquage de propriétés dans une sous-classe correspond à une restriction de classe.

L’héritage multiple

Dans certains cas, il est nécessaire de faire hériter une même classe de deux classes «
parentes » distinctes. Ce cas correspond à un héritage multiple.
Exemple d’héritage avec extension et restriction de propriétés

Peter SAMANO 0812440646 [email protected]

 40

Exemple de relation d’héritage multiple

5.2. Diagramme de composant

Le diagramme de composant permet de représenter les composants logiciels d’un
système ainsi que les liens existant entre ces composants. Les composants logiciels
peuvent être de deux origines : soit des composants métiers propres à une entreprise soit
des composants disponibles sur le marché.
5.2.1 Composant
Chaque composant est assimilé à un élément exécutable du système. Il est caractérisé
par :
 Un nom ;
 Une spécification externe sous forme soit d’une ou plusieurs interfaces requises1,
soit d’une ou plusieurs interfaces fournies ;
 Un port de connexion.

Le port d’un composant représente le point de connexion entre le composant et une

interface. L’identification d’un port permet d’assurer une certaine indépendance entre le
composant et son environnement extérieur.
Formalisme général

Deux types de représentation sont disponibles pour modéliser les composants : une
représentation « boîte noire » et une représentation « boîte blanche ». Pour chaque
représentation, plusieurs modélisations des composants sont proposées.

Peter SAMANO 0812440646 [email protected]

 41

 Représentation « boîte noire »

C’est une vue externe du composant qui présente ses interfaces fournies et requises sans
entrer dans le détail de l’implémentation du composant. Une boîte noire peut se
représenter de différentes manières.
Connecteur d’assemblage
Une interface fournie se représente à l’aide d’un trait et d’un petit cercle et une interface
requise à l’aide d’un trait et d’un demi-cercle. Ce sont les connecteurs d’assemblage.

 Connecteur d’interfaces
Une autre représentation peut être aussi utilisée en ayant recours aux dépendances
d’interfaces utilise et réalise :
 Pour une interface fournie, c’est une relation de réalisation partant du composant
et allant vers l’interface ;
 Pour une interface requise, c’est une dépendance avec le mot-clé « utilise »
partant du composant et allant vers l’interface.

5.2.2. Compartiment
Une dernière manière de modéliser un composant avec une représentation boîte noire
est de décrire sous forme textuelle les interfaces fournies et requises à l’intérieur d’un
second compartiment.

Un exemple de modélisation avec les compartiments

Peter SAMANO 0812440646 [email protected]

 42

 Représentation « boîte blanche »

C’est une vue interne du composant qui décrit son implémentation à l’aide de
classificateurs (classes, autres composants) qui le composent. Plusieurs modélisations
sont possibles pour la représentation boîte blanche.

Compartiment

Une manière de modéliser un composant avec une représentation boîte blanche est de
décrire sous forme textuelle les interfaces fournies et requises à l’intérieur d’un
compartiment, les classificateurs (classes, autres composants) dans un autre
compartiment, les artefacts (élément logiciel : jar, war, ear, dll) qui représentent
physiquement le composant dans un dernier compartiment.

Un exemple de modélisation avec les compartiments

Dépendance
Une autre représentation interne du composant peut être aussi utilisée en ayant recours
aux dépendances. Ainsi, les classificateurs qui composent le composant sont reliés à
celui-ci par une relation de dépendance. Les relations entre les classificateurs
(association, composition, agrégation) sont aussi modélisées. Néanmoins, si elles sont
trop complexes, elles peuvent être représentées sur un diagramme de classe relié au
composant par une note.

Peter SAMANO 0812440646 [email protected]

 43

5.3. DIAGRAMME DE DÉPLOIEMENT (DPL)

Le diagramme de déploiement permet de représenter l’architecture physique supportant

l’exploitation du système. Cette architecture comprend des nœuds correspondant aux
supports physiques (serveurs, routeurs…) ainsi que la répartition des artefacts logiciels
(bibliothèques, exécutables…) sur ces nœuds. C’est un véritable réseau constitué de
nœuds et de connexions entre ces nœuds qui modélise cette architecture.
5.3.1. Nœud
Un nœud correspond à une ressource matérielle de traitement sur laquelle des artefacts
seront mis en œuvre pour l’exploitation du système. Les nœuds peuvent être
interconnectés pour former un réseau d’éléments physiques.
Formalisme et exemple

 Compléments sur la description d’un nœud

Il est possible de représenter des nœuds spécialisés. UML propose en standard les deux
types de nœuds suivants :
 Unité de traitement : Ce nœud est une unité physique disposant de capacité de
traitement sur laquelle des artefacts peuvent être déployés. Une unité de
traitement est un nœud spécialisé caractérisé par le mot-clé « device ».
 Environnement d’exécution : Ce nœud représente un environnement
d’exécution particulier sur lequel certains artefacts peuvent être exécutés.
Un environnement d’exécution est un nœud spécialisé caractérisé par le mot clé «
execution Environment ».

 Artefact
Un artefact est la spécification d’un élément physique qui est utilisé ou produit par le
processus de développement du logiciel ou par le déploiement du système. C’est donc
un élément concret comme par exemple : un fichier, un exécutable ou une table d’une
base de données. Un artefact peut être relié à d’autres artefacts par notamment des
liens de dépendance.
Formalisme et exemple

Deux compléments de description sont proposés par UML pour la représentation des
artefacts.

Peter SAMANO 0812440646 [email protected]

 44

 Spécification de déploiement
Une spécification de déploiement peut être associée à chaque artefact. Elle permet de
préciser les conditions de déploiement de l’artefact sur le nœud sur lequel il va être
implanté.
 Représentation et exemples

Le diagramme de déploiement représente les nœuds de l’architecture physique ainsi que

l’affectation des artefacts sur les nœuds conformément aux règles de déploiement
définies.

Diagramme de déploiement pour un serveur Web qui présente des nœuds.

5.4. La transformation du modèle objet vers le modèle relationnel

 La transformation des classes

Les classes deviennent des tables (encore appelées relations) dans le schéma
relationnel.
5.4.1. La transformation des associations
 La transformation des associations
a. Notion de clef étrangère
Dans le modèle relationnel, les clefs primaires sont utilisées comme support pour
construire les associations. Pour qu’une ligne d’une table A puisse référencer une
ligne d’une table B, une clef étrangère est introduite dans la table A. Cette clef
étrangère est constituée d’attributs prenant les mêmes valeurs que les attributs de la

Peter SAMANO 0812440646 [email protected]

 45

clef primaire de la table B. La valeur de la clef étrangère doit correspondre à l’une

des valeurs de la clef primaire pour l’une des lignes de la table B.
b. Associations dont une extrémité a pour cardinalité 0..1 ou 1..1
Les associations dont une extrémité a pour cardinalité 0..1 ou 1..1 sont traduites par
l’introduction d’une clef étrangère dans la table située à l’autre extrémité.

c. Autres associations
Les autres associations (pour lesquelles la cardinalité maximale aux deux extrémités
est supérieure à un) nécessitent la création d’une table supplémentaire pour être
transformées dans le schéma relationnel. Celle-ci est constituée de deux clefs
étrangères correspondant chacune à la clef primaire des tables situées aux
extrémités.

Peter SAMANO 0812440646 [email protected]

 46

5.4.2. La transformation de l’héritage

a. Mécanisme de transformation

La relation d’héritage est transformée en une association dont la clef primaire se

situe au niveau de la table correspondant à la surclasse et les clefs étrangères
correspondantes au niveau des tables correspondant aux sous-classes.

Une instance d’une sous­classe donne lieu à une ligne de la table issue de cette
sous-classe. Cette ligne référence la ligne qui lui correspond dans la table de sa surclasse.
Une table propose autant de clés étrangères de ce type qu’elle possède de surclasses.
Pour retrouver l’ensemble des valeurs de l’instance, il faut procéder à une opération de
jointure. De ce fait, cette transformation n’est pas très pratique dans le cas de hiérarchies
complexes.

b. Prise en compte des contraintes liées à la relation d’héritage

Nous avons vu au chapitre La modélisation des objets qu’il existait quatre contraintes
pouvant être exprimées au niveau des sous-classes :

 La contrainte {incomplete} signifie que l’ensemble des sous-classes est

incomplet et qu’il ne couvre pas la surclasse.
 La contrainte {complete} signifie au contraire que l’ensemble des sous­classes
est complet et qu’il couvre la surclasse.
 La contrainte {disjoint} signifie que les sous­classes n’ont aucune instance en
commun.
 La contrainte {overlapping} signifie que les sous-classes peuvent avoir une ou
plusieurs instances en commun.

Peter SAMANO 0812440646 [email protected]

 47

Ces quatre contraintes offrent quatre possibilités différentes détaillées dans le tableau
suivant. Ce symbole apparaît au sein du triangle qui représente la relation d’héritage.

DB­MAIN est un outil CASE qui s’inscrit dans le cadre de l’approche MDA. Le
PIM peut être le modèle objet d’UML ou le modèle Entite-Association étendu à
l’héritage. Le PSM est le modèle relationnel. Ce dernier peut être automatiquement
transformé en SQL. Il existe d’autres PSM tels que les fichiers standards ou les
schémas XML. DB-MAIN présente l’avantage de réaliser cette transformation de
façon approfondie, notamment en prenant en compte les contraintes liées à
l’héritage.

Peter SAMANO 0812440646 [email protected]

 48

 CHAPITRE 6. UTILISATION DES QUELQUES DIAGRAMMES ET

LES CAS PRATIQUES

6.1. Diagramme d’états-transitions

Les diagrammes d’états-transitions (ou statecharts) d’UML décrivent le comportement

interne d’un objet à l’aide d’un automate à états finis. Ils présentent les séquences
possibles d’états et d’actions qu’une instance de classe peut traiter au cours de son cycle
de vie en réaction à des événements discrets (de type signaux, invocations de méthode).
Ils spécifient habituellement le comportement d’une instance de classeur (classe ou
composant), mais parfois aussi le comportement interne d’autres éléments tels que les
cas d’utilisation, les sous-systèmes, les méthodes. Ils sont bien adaptés à la description
d’objets ayant un comportement d’automate. Cependant, la vision globale du système
est moins apparente sur ces diagrammes, car ils ne s’intéressent qu’à un seul élément du
système indépendamment de son environnement.

6.1.1. Etat
Un diagramme d’états-transitions est un graphe qui représente un automate à états finis,
C’est-à-dire une machine dont le comportement des sorties ne dépend pas seulement de
l’état de ses entrées, mais aussi d’un historique des sollicitations passées : cet historique
est caractérisé par un état. Exemple simple présente la notion d’état et l’effet des
invocations en fonction de l’état courant.

Les états sont représentés par des rectangles aux coins arrondis, tandis que les transitions
sont représentées par des arcs orientés liant les états entre eux. Certains états, dits «
composites », peuvent contenir des sous-diagrammes. UML offre également un certain
nombre de constructions à la sémantique particulière, telles que l’historique, qui permet
de retrouver un état précédent, les points de choix, qui permettent d’exprimer des
alternatives, ou encore un moyen d’exprimer des mécanismes concurrents

Peter SAMANO 0812440646 [email protected]

 49

EXEMPLE d’une Fenêtre d’application

le comportement simplifié d’une fenêtre d’application, qui répond aux stimuli de trois
boutons placés dans l’angle. Une fenêtre peut être dans trois états : réduite, normale,
agrandie. Lorsqu’elle est réduite, elle est représentée par une icône dans la barre des
tâches. À l’état normal, elle peut être déplacée et redimensionnée. Lorsqu’elle est
agrandie, elle occupe toute la surface disponible de l’écran et ne peut être déplacée ou
redimensionnée. Les arcs portent une étiquette indiquant le nom de l’événement qui
déclenche la transition associée. L’état initial (Init 1 et Init 2 ici), noté par un cercle
plein, désigne le point d’entrée du diagramme ou du sous-diagramme. Une nouvelle
instance de fenêtre sera initialisée à l’état créée, dans le sous-état ouverte et dans le sous-
état normale. Le pseudo-état historique, désigné par un H dans un cercle, permet de
retrouver la fenêtre son état précédent (normale ou agrandie) quand on quitte l’état
réduite. L’état final, désigné par un point dans un cercle correspond à la fin de vie de
l’instance et à sa destruction.

6.1.2. Événement
La vue proposée par les diagrammes d’états-transitions met en évidence les réactions
d’une partie du système à des événements discrets. Un état représente une période dans
la vie d’un objet dans laquelle ce dernier attend un événement ou accomplit une activité.
Quand un événement est reçu, une transition peut être déclenchée qui va faire basculer
l’objet dans un nouvel état. Les transitions d’un diagramme d’états-transitions sont donc
déclenchées par des événements, appelés « déclencheurs » ou triggers. La notion
d’événement est assez large en UML :
Un appel de méthode sur l’objet courant génère un événement de type call.
Le passage de faux à vrai de la valeur de vérité d’une condition booléenne
génère implicitement un événement de type change.
La réception d’un signal asynchrone, explicitement émis par un autre objet,
génère un événement de type signal.
L’écoulement d’une durée déterminée après un événement donné génère un
événement de type after. Par défaut, le temps commence à s’écouler dès l’entrée
dans l’état courant.
La fin d’une activité de type do/, interne à un état génère implicitement un
événement appelé completion event. Cela peut déclencher le tir des transitions
dites « automatiques », qui ne portent pas de déclencheur explicite.

Peter SAMANO 0812440646 [email protected]

 50

6.2. Diagramme paquetage

6.2.1. Paquetage
Un paquetage regroupe des éléments de la modélisation appelés aussi membres, portant
sur un sous-ensemble du système. Le découpage en paquetage doit traduire un
découpage logique du système à construire qui corresponde à des espaces de nommage
homogènes. Les éléments d’un paquetage peuvent avoir une visibilité déclarée soit de
type public (+) soit privé (-). Un paquetage peut importer des éléments d’un autre
paquetage. Un paquetage peut être fusionné avec un autre paquetage.
Formalisme et exemple
Le formalisme général d’un paquetage et les trois manières de présenter un paquetage.
 Représentation globale – Le nom du paquetage se trouve à l’intérieur du grand
rectangle.
 Représentation détaillée – Les membres du paquetage sont représentés et le nom
du paquetage d’ensemble s’inscrit dans le petit rectangle.
 Représentation éclatée – Les membres du paquetage sont reliés par un lien
connecté au paquetage par le symbole ⊕.

6.2.2. Dépendance entre paquetages

La dépendance entre paquetages peut être qualifiée par un niveau de visibilité qui est
soit public soit privé. Par défaut le type de visibilité est public. À chaque type de
visibilité est associé un lien de dépendance. Les deux types de dépendances entre
paquetages sont :
 « import » : Ce type de dépendance permet, pour un paquetage donné, d’importer
l’espace de nommage d’un autre paquetage. Ainsi tous les membres du paquetage
donné ont accès à tous les noms des membres du paquetage importé sans avoir à
utiliser explicitement le nom du paquetage concerné. Ce type de dépendance
correspond à un lien ayant une visibilité « public ».
 « access » : Ce type de dépendance permet, pour un paquetage donné, d’avoir
accès à l’espace de nommage d’un paquetage cible. L’espace de nommage n’est
donc pas importé et ne peut être transmis à d’autres paquetages par transitivité.
Ce type de dépendance correspond à un lien ayant une visibilité « privé ».

Peter SAMANO 0812440646 [email protected]

 51

Un exemple de dépendance entre paquetages mettant en jeu les niveaux de visibilité

6.3. Diagramme de structure composite

Le diagramme de structure composite permet de décrire des collaborations d’instances
(de classes, de composants…) constituant des fonctions particulières du système à
développer.
6.3. Collaboration
Une collaboration représente un assemblage de rôles d’éléments qui interagissent en
vue de réaliser une fonction donnée. Il existe deux manières de représenter une
collaboration :
 Représentation par une collaboration de rôles,
 Représentation par une structure composite : le diagramme de structure
composite.
Représentation et exemple
Dans ce cas, une collaboration est formalisée par une ellipse en pointillé dans laquelle
on fait figurer les rôles des éléments qui interagissent en vue de réaliser la fonction
souhaitée. Dans cet exemple, la fonction Persistance objets métier résulte d’une
collaboration entre deux rôles d’éléments :
 mapping : classeMétier,
 stockage : tableBDD

Représentation par un diagramme de structure composite

Cette nouvelle représentation permet de montrer plus explicitement les éléments de la
collaboration :

 La collaboration représentée par une ellipse en pointillé ;

Peter SAMANO 0812440646 [email protected]

 52

 Les éléments participant à la collaboration (classe, composant…) représentés à

l’extérieur de la collaboration ;
 Les rôles considérés dans chaque participation représentés sur les liens entre les
éléments participants et la collaboration.

TRAVAUX PRATQUES
 Enoncé 1.
Une agence de voyages organise des voyages où l’hébergement se fait en hôtel.
Le client doit disposer d’un taxi quand il arrive à la gare pour se rendre à l’hôtel.
Certains clients demandent à l’agent de voyages d’établir une facture détaillée.
Cela donne lieu à un nouveau cas d’utilisation appelé « Établir une facture
détaillée ». Comment mettre ce cas en relation avec les cas existants ?
Le voyage se fait soit par avion, soit par train. Comment modéliser cela ?
TD :
 Cas d’utilisation ;
 décrivez sous forme textuelle les différents cas d’utilisation ici-haut ;
 Diagramme de classe et Diagramme de séquence

 Enoncé 2.
Un hôtel est composé d’au moins deux chambres. Chaque chambre dispose d’une
salle d’eau qui peut être une douche ou une salle de bain. L’hôtel héberge des
personnes. Il peut employer du personnel et est dirigé par un des employés.
L’hôtel a les caractéristiques suivantes : une adresse, le nombre de pièces, la
catégorie. Une chambre est caractérisée par le nombre et le type de lits, le prix et
le numéro. On peut calculer le chiffre d’affaires, le loyer en fonction des
occupants.
TD :
1. Cas d’utilisation
2. Donnez le diagramme de classes.
3. Utilisez les contraintes pour affiner les relations.
4. Diagramme de séquence

Peter SAMANO 0812440646 [email protected]

 53

 Enoncé 3.
Modélisez à l’aide d’un diagramme de cas d’utilisation le système informatique
qui gère la distribution d’essence dans une station-service. Le fonctionnement de
la distribution de l’essence est décrit ci-après. Avant de pouvoir être utilisée par
un client, la pompe doit être armée par le pompiste. La pompe est ainsi apprêtée,
mais ce n’est que lorsque le client appuie sur la gâchette du pistolet de distribution
que l’essence est pompée. Si le pistolet est dans son étui de rangement et si la
gâchette est pressée, l’essence n’est pas pompée. La distribution de l’essence à un
client est terminée quand celui-ci remet le pistolet dans son étui. La mesure de
l’essence distribuée se fait par un débitmètre.
Quatre types de carburants sont proposés : diesel, sans plomb avec un indice
d’octane de 98, sans plomb avec un indice d’octane de 95, et plombé.
Le paiement peut s’effectuer en espèces, par chèque ou par carte bancaire. En fin
de journée, les transactions sont archivées. Le niveau des cuves ne doit pas
descendre en dessous de 5 % de la capacité maximale. Sinon les pompes ne
peuvent plus être armées. Pour un système complexe, il vaut mieux se concentrer
sur les fonctions essentielles puis passer aux cas moins importants.

TD :
 Cas d’utilisation ;
 décrivez sous forme textuelle les différents cas d’utilisation ici-haut ;
 Diagramme de classe
 Utilisez les contraintes pour affiner les relations.
 Diagramme de séquence

Peter SAMANO 0812440646 [email protected]

 54

BIBLIOGRAPHIE

Alistair Cockburn, Rédiger des cas d’utilisation efficaces, Eyrolles, 1999


Anneke Kleppe, Jos Warmer, Wim Bast, MDA Explained: The Model Driven
ArchitecturePractice and Promise, AddisonWesley, 2003

Ivar Jacobson, Grady Booch, James Rumbaugh, Le Processus unifié de
développement logiciel, Eyrolles, 2000

James Rumbaugh, Ivar Jacobson, Grady Booch, Unified Modeling Language
Reference Manual, Second Edition, AddissonWesley, 2004

Jos Warmer, Anneke Kleppe, The Object Constraint Language: Getting Your
Models ready for MDA, Second Edition, AddissonWesley, 2003

Kendal Scott, Fast Track UML 2.0, Apress, 2004

Michael Blaha, James Rumbaugh. Modélisation et conception orientées objet avec
UML 2,
Pearson Education, 2005
 Érich Gamma, Richard Helm, Ralph Johnson et John Vlissides. Design Patterns:
Elements
of Reusable Object-Oriented Software, Addison-Wesley, 1995

 Ivan Jacobson, Grady Booch et James Rumbaugh. Le processus unifié de

développement
logiciel, Eyrolles, 1999
 Brian W. Kernighan, Dennis M. Ritchie, The C Programming Language, Prentice
Hall, Inc.
1988. En français : Le Langage C : norme ANSI, taduit par Jean-François Groff et
Éric Mottier,
 Dunod, coll. « Sciences sup », 2e édition, 2004
 Craig Larman. UML et les design patterns, deuxième édition, CampusPress, 2005
 OMG (Object Management Group). UML 2.0 Superstructure (référence ptc/04-10-
02),

 Tom Penders. Introduction à UML, EOM, 2002

 James Rumbaugh, Ivar Jacobson et Grady Booch. UML 2.0 - Guide de référence,
CampusPress, 2004

Peter SAMANO 0812440646 [email protected]