SUPPORT DE COURS

SYSTÈME
D’INFORMATION
IN3 – 2024 – 2025
Dr Azanguezet Benoît
Les systèmes d'information (SI) occupent une place centrale dans le fonctionnement des organisations modernes.
Ils regroupent un ensemble de ressources humaines, matérielles, logicielles et procédurales, permettant de traiter les
informations nécessaires à la gestion des processus organisationnels. Un système d’information assure ainsi la
collecte, le stockage, le traitement, l’analyse et la diffusion des données, afin de soutenir la prise de décision,
améliorer les performances, et faciliter la communication et la coordination au sein d'une entreprise ou d'une
institution.
La conception d'un système d’information requiert une compréhension approfondie des besoins des utilisateurs et
des flux d'information entre les différentes entités d'une organisation. Pour garantir une architecture bien pensée et
adaptée, il est crucial de recourir à des techniques de modélisation, qui permettent de visualiser et structurer les
processus et données du système. C’est dans ce contexte que les DFD (Data Flow Diagrams) et les diagrammes
UML (Unified Modeling Language) interviennent comme outils clés.
Les DFD, ou diagrammes de flux de données, sont des représentations graphiques des flux d'information au sein
d'un système. Ils permettent de comprendre et d’analyser la manière dont les données circulent entre les entités
externes, les processus, et les bases de données internes à l’organisation. Ces diagrammes sont particulièrement
utiles lors des phases d’analyse des besoins, car ils offrent une vue claire et globale des mouvements de données
sans entrer dans des détails techniques complexes.
Par ailleurs, les diagrammes UML jouent un rôle crucial dans la modélisation plus formelle et détaillée d’un
système. UML est un langage standardisé qui permet de visualiser, spécifier, construire et documenter les différents
aspects d’un système d’information. Il inclut plusieurs types de diagrammes pour modéliser aussi bien la structure
statique (comme les diagrammes de classes ou les diagrammes de composants) que les interactions dynamiques
et comportementales du système (comme les diagrammes de séquence, diagrammes d’activités, ou encore
diagrammes d’états).
En résumé, l’étude des systèmes d’information repose sur une bonne compréhension de la circulation et de la
gestion des données au sein d’un environnement organisationnel. Les outils de modélisation, tels que les DFD et
UML, permettent de décomposer et de visualiser ces processus de manière claire, facilitant ainsi la conception, la
mise en œuvre, et la maintenance des systèmes d’informatio.

-
1-
 Chapitre 1 : Les diagrammes de flux

Les diagrammes de flux répondent à la question : Que fait le système ?

En ce sens, ce sont des modèles FONCTIONNELS (qui décrivent les fonctions)

Il existe2 types principaux de diagrammes de flux :

1) Le modèle de contexte (MC) où le domaine d’étude est vu comme une boite noire. On ne représente
que les flux extérieurs au domaine.
2) Le modèle de flux de données (DFD) ou encore modèle de flux conceptuels (MFC) où l’on détaille
les activités du domaine d’étude. On représente aussi les flux internes au domaine.

Vocabulaire associé aux modèles de flux

A. Domaine d'étude
Le domaine d'étude est un sous -ensemble cohérent de l'entreprise ou de l'organisme, bien délimité et
formant le contenu du sujet à étudier.

Dans les modèles de flu x, le domaine d'étude est représenté par un rectangle à trait plein.
Domaine Le nom du domaine est placé à l’intérieur du rectangle.
d'étude

B. Acteur externe
Un acteur externe est un élément émetteur ou récepteur de données, situé hors du système
d'information étudié.

Dans les modèles de flux, un acteur externe est représenté par un cercle plein. Le
Acteur
externe nom de l’acteur est placé à l’intérieur du cercle.

C. Domaine connexe
Un domaine connexe est un composant du système d’information interagissant avec le domaine
d’étude . C’est un acteur interne à l’entreprise, mais externe au domaine d’étude

Dans le modèle de flux, un domaine connexe est représenté par un rectangle (ou un rond). Le nom
Domaine du domaine connexe est placé à l’intérieur du rectangle
connexe

D. Activité
L’activité est un ensemble de traitements homogènes qui transforment ou manipulent des
données. Une activité peut souvent être vue comme un sous -domaine d’étude, un morceau du
domaine d’étude.

Chaque activité peut être éclatée. Cet éclatement se traduit alors par l’élaboration d’un nouveau
diagramme qui décompose ce processus éclaté en plusieurs processus plus élémentaires.

Activité

-
2-
 Dans les modèles de flux, une activité est représentée graphiquement par un rectangle. Le
nom de l'activité est placé à l’intérieur du rectangle.

E. Flux de données
Un flux est un transfert d’informations entre composants du système. Le composant peut être un
domaine, une activité ou un acteur externe .

Flux Dans les modèles de flux, un flux de données est représenté graphiquement par une flèche
orientée du composant émetteur du flux vers le composant récepteur. Le libellé du flux est
inscrit en regard de la flèche tracée.

Formalisme graphique illustrant par exemple un échange entre un acteur externe et le domaine d'étude :

Acteur Flux Domaine

Acteur
externe d'étude
but

Modèle de contexte

Le modèle de contexte sert à représenter les interactions entre le domaine d'étude et l’environnement, et entre le
domaine d'étude et les éventuels domaines connexes.

Le domaine d'étude y est représenté comme une boîte noire.

Le modèle de contexte utilise les concepts suivants :

• le domaine d'étude
• les acteurs externes
• les flux de données
• les domaines connexes

Exemple de modèle de contexte : au sein d’une société commerciale, on étudie le domaine « gestion des ventes ».
Gestion
comptabilité
informations ventes

informations rémunération
commande GESTION DES
VENTES informations personnel Gestion du
personnel
facture

Client informations sur stocks

règlement

bon livraison

infos livraisons en cours

Gestion des stocks

Remarque
• on ne fait pas apparaître les flux entre acteurs externes et domaines connexes, ou entre les domaines
connexes.
Exemple :le flux correspondant à la livraison de marchandises n’apparaît pas.

-
3-
III. Modèle de flux conceptuel(MFC) ou diagramme de flux de
données(DFD)
Ce modèle permet de décider quelles activités, inter-reliées de quelle manière, permettront de résoudre au mieux
le problème posé, et cette réflexion est menée sans s'encombrer dans un premier temps du comportement du
système (ordonnancement, règles d'émission, synchronisations…).

Les modèles de flux conceptuels permettent de décomposer le domaine d’étude en activités. Il n’y a pas ici de
notion d’organisation mais d’objectifs à réaliser. On représente les flu x entre activités et avec
l’environnement.

Pour analyser les communications et les activités, on procède par « zooms » successifs sur le domaine étudié
pour élaborer des modèles de plus en plus détaillés qui permettront d'avoir une cartographie détaillée du système
et de préparer le passage au modèle conceptuel de représentation des traitements.

Le modèle de contexte est également appelé le diagramme de flux de données de niveau 0.

Nous obtenons ensuite des diagrammes de premier, deuxième, troisième, … niveau, par éclatements successifs
des activités à chacun de ces niveaux.

La décomposition d’un domaine ou d’une activité en plusieurs activités peut faire apparaître de nouveaux flux
dus :
- à l’échange d’informations entre activités
- à la décomposition d’un flux présent au niveau n en plusieurs flux au niveau n+1.

Exemple : si on reprend le modèle de contexte précédent, on s’aperçoit que le domaine des ventes peut-être
éclaté en trois activités. Nous obtenons ainsi le diagramme de flux de données de niveau 1 :
GESTION DES VENTES
informations sur stocks

bon livraison Gestion des

Gestion des stocks
infos livraisons en cours
Commandes

commande
Double bon Double
livraison commande
Client facture
Gestion des informations Gestion
règlement montants vente
comptabilité
Factures

informations ventes

informations rémunération
Gestion Gestion du
Force de
personnel
vente
informations personnel

Remarque

• On peut décomposer le modèle de flux de niveau 1 en un modèle de flux de niveau 2 et etc … jusqu’à
arriver à un modèle où l’activité correspond à une opération au sens Merise (règle d’ininterruption).
Exemple : l’activité « gestion des factures » peut être encore décomposée en activités « facturation » et
« Suivi des réglements ».

-
4-
1.2. POURQUOI ET COMMENT 5
MODÉLISER ?

Règles de décomposition des activités

Pourquoi décomposer ?
• Pour désagréger les groupes de flux , pour arriver à la définition des flux-types du domaine étudié
• Pour préparer l'étude dynamique du système d'information, pour arriver à l ’identification des
processus et des opérations conceptuelles

Comment décomposer ?
• Identifier les groupes de données entrant et sortant du domaine d ’étude pour construire le
modèle de contexte
• Identifier les activités générant ou traitant les flux de données pour construire le DFD de
niveau 1 (approche par les données) ou identifier une activité de niveau 1 comme un ensemble d
’activités participant à une même finalité (approche par les objectifs)

Jusqu'où décomposer ?
Lorsqu'une activité a atteint le niveau d'interruptabilité (dès lors que le traitement est déclenché, il
se déroule sans attente de ressources complémentaires extérieures). L'activité est alors une opération
conceptuelle qui sera décrite lors de l'étude dynamique du SI dans le MCTA.

-
5-
 1.2. POURQUOI ET COMMENT 6
MODÉLISER ?
Chapitre 1

Introduction à la modélisation objet

1.1 Le SI et le GL
1.1.1 L’informatisation
L’informatisation est l'un des phénomènes les plus marquants de notre époque. Elle s'intègre désormais dans presque tous
les aspects de la vie quotidienne, que ce soit dans les objets eux-mêmes ou dans les processus de conception et de
fabrication. Par exemple, dans les automobiles modernes, environ 90% des nouvelles fonctionnalités sont apportées par
l’électronique et l’informatique embarquée. Aujourd'hui, on retrouve du logiciel partout : dans les ampoules électriques, les
fours à micro-ondes, les vêtements, et même dans des objets comme les stylos ou les livres.
L'informatique est également devenue un élément central dans la gestion des grandes entreprises. Un système
d’information (SI) est généralement constitué de matériel et de logiciels. Les investissements dans ces systèmes se
répartissent typiquement à environ 20% pour le matériel et 80% pour le logiciel. En effet, les coûts et les défis liés à
l'informatique dans les entreprises modernes ne concernent plus tellement le matériel, qui est devenu fiable et standardisé,
mais bien les logiciels.
1.1.2 Les Logiciels
Un logiciel est un ensemble de programmes qui permet à un ordinateur ou à un système informatique d’effectuer une tâche
spécifique, comme la comptabilité ou la gestion des prêts. Selon leur taille, les logiciels peuvent être développés par une
seule personne ou par une équipe de développement coordonnée. Plus un logiciel est complexe et implique de grandes
équipes, plus les défis de conception, de coordination, et de gestion augmentent.
Le développement logiciel est une phase cruciale du cycle de vie d'un produit informatique. Il s'agit de l'étape qui
monopolise l'essentiel des coûts et qui détermine la réussite ou l'échec d'un projet. Une étude réalisée par le Standish
Group en 1995 montrait que seulement 16,2% des projets logiciels étaient livrés selon les délais et budgets prévus, tandis
que 31,1% des projets étaient abandonnés en cours de développement. Cette même étude révélait que les grandes
entreprises rencontrent plus de difficultés avec seulement 9% des projets réussis.
La principale cause de ces échecs n’est souvent pas liée à l’informatique elle-même, mais à la maîtrise d'ouvrage, c'est-à-
dire aux processus de gestion et de conception des projets. Face à ces défis, il est apparu nécessaire d’adopter des
approches méthodologiques rigoureuses pour structurer et faciliter le travail en équipe ainsi que la maintenance du code.
Ainsi, le génie logiciel est né.
1.1.3 Le Génie Logiciel
Le génie logiciel est une discipline apparue pour répondre aux difficultés rencontrées dans le développement des logiciels
complexes. Il a été formellement défini en 1968 lors d’une conférence parrainée par l'OTAN à Garmisch-Partenkirchen. Le
génie logiciel a pour objectif principal d'optimiser le coût, le temps et la qualité de développement des logiciels. Il vise à
résoudre les problèmes majeurs liés à la non-fiabilité des logiciels, les dépassements de délais, et les difficultés de respect
des spécifications initiales.
Cette discipline met en avant l'importance d'une approche méthodologique qui couvre toutes les étapes du cycle de vie du
logiciel, incluant :
• L'analyse des besoins,
• L'élaboration des spécifications,
• La conceptualisation,
• Le développement,
• Les phases de test,
• La maintenance.
La maintenance logicielle est devenue une phase critique dans le cycle de vie des logiciels. En 1986, une enquête auprès de
55 entreprises américaines a montré que 53% du budget total consacré à un logiciel était destiné à sa maintenance, qui
inclut la correction des bogues, les adaptations aux nouveaux environnements, et les améliorations des performances.
Ainsi, le génie logiciel englobe la gestion du projet dans son ensemble, nécessitant des équipes structurées pour les grands
projets (souvent dépassant 10 000 lignes de code), et une organisation stricte pour garantir le respect des délais, des coûts
et des spécifications. -
6-
Cette discipline s’étend à plusieurs domaines de l'informatique, tels que la conception, la gestion de projet, le
 1.2. POURQUOI ET COMMENT 7
développement
MODÉLISER d’applications
? et la mise en place d'outils de collaboration pour les équipes de développeurs, afin de
répondre aux exigences croissantes du marché et aux besoins de fiabilité des systèmes d’information modernes.

1.1.1 Notion de qualité pour un logiciel

En génie logiciel, divers travaux ont mené à la définition de la qualité du logiciel en termes de facteurs, qui
dépendent, entre autres, du domaine de l’application et des outils utilisés. Parmi ces derniers nous pouvons citer :

Validité : aptitude d’un produit logiciel à remplir exactement ses fonctions, définies par le cahier des charges et les
spécifications.
Fiabilité ou robustesse : aptitude d’un produit logiciel à fonctionner dans des conditions anormales.
Extensibilité (maintenance) : facilité avec laquelle un logiciel se prête à sa maintenance, c’est-à-dire à une
modification ou à une extension des fonctions qui lui sont demandées.
Réutilisabilité : aptitude d’un logiciel à être réutilisé, en tout ou en partie, dans de nouvelles applica- tions.
Compatibilité : facilité avec laquelle un logiciel peut être combiné avec d’autres logiciels.
Efficacité : Utilisation optimales des ressources matérielles.
Portabilité : facilité avec laquelle un logiciel peut être transféré sous différents environnements matériels et logiciels.
Vérifiabilité : facilité de préparation des procédures de test.
Intégrité : aptitude d’un logiciel à protéger son code et ses données contre des accès non autorisés.
Facilité d’emploi : facilité d’apprentissage, d’utilisation, de préparation des données, d’interprétation des erreurs et
de rattrapage en cas d’erreur d’utilisation.
Ces facteurs sont parfois contradictoires, le choix des compromis doit s’effectuer en fonction du contexte.

1.2 Pourquoi et comment modéliser ?

1.2.1 Notions de modèle et de modélisation
Qu’est-ce qu’un modèle ?
Un modèle est une représentation abstraite et simplifiée (i.e. qui exclut certains détails), d’une entité (phénomène,
processus, système, etc.) du monde réel en vue de le décrire, de l’expliquer ou de le prévoir. Modèle est synonyme
de théorie, mais avec une connotation pratique : un modèle, c’est une théorie orientée vers l’action qu’elle doit servir.
Concrètement, un modèle permet de réduire la complexité d’un phénomène en éliminant les détails qui
n’influencent pas son comportement de manière significative. Il reflète ce que le concepteur croit important pour
la compréhension et la prédiction du phénomène modélisé, les limites du phénomène modélisé dépendant des
objectifs du modèle.
Voici quelques exemples de modèles prédictifs :
Modèle météorologique – à partir de données d’observation (satellite . . .), il permet de prévoir les conditions
climatiques pour les jours à venir.
Modèle économique – peut par exemple permettre de simuler l’évolution de cours boursiers en fonc- tion
d’hypothèses macro-économiques (évolution du chômage, taux de croissance . . .).
Modèle démographique – définit la composition d’un panel d’une population et son comportement, dans le but de
fiabiliser des études statistiques, d’augmenter l’impact de démarches commerciales, etc.

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

-
7-
 1.2. POURQUOI ET COMMENT 8
MODÉLISER ?

exemple, les plateformes de modélisation savent maintenant exploiter les modèles pour faire de la gé- nération de code
(au moins au niveau du squelette) voire des aller-retours entre le code et le modèle sans perte d’information. Le
modèle est enfin indispensable pour assurer un bon niveau de qualité et une maintenance efficace. En effet, une fois
mise en production, l’application va devoir être maintenue, probablement par une autre équipe et, qui plus est, pas
nécessairement de la même société que celle ayant créée l’application.
Le choix du modèle a donc une influence capitale sur les solutions obtenues. Les systèmes non - triviaux sont
mieux modélisés par un ensemble de modèles indépendants. Selon les modèles employés, la démarche de
modélisation n’est pas la même.

Qui doit modéliser ?

La modélisation est souvent faite par la maîtrise d’œuvre informatique (MOE). C’est malencontreux, car les
priorités de la MOE résident dans le fonctionnement de la plate-forme informatique et non dans les processus de
l’entreprise.
Il est préférable que la modélisation soit réalisée par la maîtrise d’ouvrage (MOA) de sorte que le métier soit
maître de ses propres concepts. La MOE doit intervenir dans le modèle lorsque, après avoir défini les concepts du
métier, on doit introduire les contraintes propres à la plate-forme informatique.
Il est vrai que les métiers, dont les priorités sont opérationnelles, ne disposent pas toujours de la capacité
d’abstraction, de la rigueur conceptuelle nécessaires à la formalisation. La professionnalisation de la MOA a pour but
de les doter de ces compétences. Cette professionnalisation réside essentiellement dans l’aptitude à modéliser le système
d’information du métier : le maître mot est modélisation. Lorsque le modèle du système d’information est de bonne
qualité, sobre, clair, stable, la maîtrise d’œuvre peut travailler dans de bonnes conditions. Lorsque cette
professionnalisation a lieu, elle modifie les rapports avec l’informatique et déplace la frontière des responsabilités, ce
qui contrarie parfois les informaticiens dans un premier temps, avant qu’ils n’en voient apparaître les bénéfices.

Maîtrise d’ouvrage et maîtrise d’œuvre

Maître d’ouvrage (MOA) : Le MOA est une personne morale (entreprise, direction etc.), une entité de
l’organisation. Ce n’est jamais une personne.
Maître d’œuvre (MOE) : Le MOE est une personne morale (entreprise, direction etc.) garante de la bonne réalisation
technique des solutions. Il a, lors de la conception du SI, un devoir de conseil vis-à-vis du MOA, car le SI
doit tirer le meilleur parti des possibilités techniques.

Le MOA est client du MOE à qui il passe commande d’un produit nécessaire à son activité.
Le MOE fournit ce produit ; soit il le réalise lui-même, soit il passe commande à un ou plusieurs
fournisseurs (« entreprises ») qui élaborent le produit sous sa direction.
La relation MOA et MOE est définie par un contrat qui précise leurs engagements mutuels. Lorsque le
produit est compliqué, il peut être nécessaire de faire appel à plusieurs fournisseurs. Le
MOE assure leur coordination ; il veille à la cohérence des fournitures et à leur compatibilité. Il coordonne
l’action des fournisseurs en contrôlant la qualité technique, en assurant le respect des délais fixés par le MOA et en
minimisant les risques.
Le MOE est responsable de la qualité technique de la solution. Il doit, avant toute livraison au MOA, procéder
aux vérifications nécessaires (« recette usine »).

1.2.2 Le cycle de vie d’un logiciel

Le cycle de vie d’un logiciel (en anglais software lifecycle), désigne toutes les étapes du développement d’un
logiciel, de sa conception à sa disparition. L’objectif d’un tel découpage est de permettre de définir des jalons
intermédiaires permettant la validation du développement logiciel, c’est-à-dire la conformité du logiciel avec les
besoins exprimés, et la vérification du processus de développement, c’est-à-dire l’adéquation des méthodes mises
en œuvre.

-
8-
 1.2. POURQUOI ET COMMENT 9
MODÉLISER ?

L’origine de ce découpage provient du constat que les erreurs ont un coût d’autant plus élevé qu’elles sont détectées
tardivement dans le processus de réalisation. Le cycle de vie permet de détecter les erreurs au plus tôt et ainsi de
maîtriser la qualité du logiciel, les délais de sa réalisation et les coûts associés.
Le cycle de vie du logiciel comprend généralement a minima les étapes suivantes :
Définition des objectifs – Cet étape consiste à définir la finalité du projet et son inscription dans une stratégie
globale.
Analyse des besoins et faisabilité – c’est-à-dire l’expression, le recueil et la formalisation des besoins du
demandeur (le client) et de l’ensemble des contraintes puis l’estimation de la faisabilité de ces besoins.
Spécification ou conception générale – Il s’agit de l’élaboration des spécifications de l’architecture gé- nérale
du logiciel.
Conception détaillée – Cette étape consiste à définir précisément chaque sous-ensemble du logiciel.
Codage (Implémentation ou programmation) – c’est la traduction dans un langage de programmation des
fonctionnalités définies lors de phases de conception.
Tests unitaires – Ils permettent de vérifier individuellement que chaque sous-ensemble du logiciel est implémenté
conformément aux spécifications.
Intégration – L’objectif est de s’assurer de l’interfaçage des différents éléments (modules) du logiciel.
Elle fait l’objet de tests d’intégration consignés dans un document.
Qualification (ou recette) – C’est-à-dire la vérification de la conformité du logiciel aux spécifications
initiales.
Documentation – Elle vise à produire les informations nécessaires pour l’utilisation du logiciel et pour des
développements ultérieurs.
Mise en production
Maintenance – Elle comprend toutes les actions correctives (maintenance corrective) et évolutives (maintenance
évolutive) sur le logiciel.
La séquence et la présence de chacune de ces activités dans le cycle de vie dépend du choix d’un modèle de
cycle de vie entre le client et l’équipe de développement. Le cycle de vie permet de prendre en compte, en plus des
aspects techniques, l’organisation et les aspects humains.

1.2.3 Modèles de cycles de vie d’un logiciel

Modèle de cycle de vie en cascade
Le modèle de cycle de vie en cascade a été mis au point dès 1966, puis formalisé aux alentours de 1970.
Dans ce modèle le principe est très simple : chaque phase se termine à une date précise par la production de certains
documents ou logiciels. Les résultats sont définis sur la base des interactions entre étapes, ils sont soumis à une
revue approfondie et on ne passe à la phase suivante que s’ils sont jugés satisfaisants.
Le modèle original ne comportait pas de possibilité de retour en arrière. Celle-ci a été rajoutée ultérieurement sur la
base qu’une étape ne remet en cause que l’étape précédente, ce qui, dans la pratique, s’avère insuffisant.

Modèle de cycle de vie en V

Le modèle en V demeure actuellement le cycle de vie le plus connu et certainement le plus utilisé.
Le principe de ce modèle est qu’avec toute décomposition doit être décrite la recomposition, et que toute description
d’un composant est accompagnée de tests qui permettront de s’assurer qu’il correspond à sa description.
Ceci rend explicite la préparation des dernières phases (validation-vérification) par les premières (construction du
logiciel), et permet ainsi d’éviter un écueil bien connu de la spécification du logiciel : énoncer une propriété qu’il est
impossible de vérifier objectivement après la réalisation.

-
9-
1.2. POURQUOI ET COMMENT 10
MODÉLISER ?

Fig. 1.1 – Modèle du cycle de vie en cascade

Fig. 1.2 – Modèle du cycle de vie en V

-
10 -
 1.2. POURQUOI ET COMMENT 11
MODÉLISER ?

Modèle de cycle de vie en spirale

Proposé par B. Boehm en 1988, ce modèle est beaucoup plus général que le précédent. Il met l’accent sur l’activité
d’analyse des risques : chaque cycle de la spirale se déroule en quatre phases :
1. détermination, à partir des résultats des cycles précédents, ou de l’analyse préliminaire des besoins, des
objectifs du cycle, des alternatives pour les atteindre et des contraintes ;
2. analyse des risques, évaluation des alternatives et, éventuellement maquettage ;
3. développement et vérification de la solution retenue, un modèle « classique » (cascade ou en V) peut
être utilisé ici ;
4. revue des résultats et vérification du cycle suivant.
L’analyse préliminaire est affinée au cours des premiers cycles. Le modèle utilise des maquettes exploratoires
pour guider la phase de conception du cycle suivant. Le dernier cycle se termine par un processus de développement
classique.

Modèle par incrément

Dans les modèles précédents un logiciel est décomposé en composants développés séparément et intégrés à la fin du
processus.
Dans les modèles par incrément un seul ensemble de composants est développé à la fois : des incréments viennent
s’intégrer à un noyau de logiciel développé au préalable. Chaque incrément est développé selon l’un des modèles
précédents.
Les avantages de ce type de modèle sont les suivants :
– chaque développement est moins complexe ;
– les intégrations sont progressives ;
– il est ainsi possible de livrer et de mettre en service chaque incrément ;
– il permet un meilleur lissage du temps et de l’effort de développement grace à la possibilité de
recouvrement (parallélisation) des différentes phases.
Les risques de ce type de modèle sont les suivants :
– remettre en cause les incréments précédents ou pire le noyau ;
– ne pas pouvoir intégrer de nouveaux incréments.
Les noyaux, les incréments ainsi que leurs interactions doivent donc être spécifiés globalement, au début du projet.
Les incréments doivent être aussi indépendants que possibles, fonctionnellement mais aussi sur le plan du calendrier du
développement.

1.2.4 Méthodes d’analyse et de conception

Les méthodes d’analyse et de conception fournissent une méthodologie et des notations standards qui aident à
concevoir des logiciels de qualité. Il existe différentes manières pour classer ces méthodes, dont :
La distinction entre composition et décomposition : Elle met en opposition d’une part les méthodes ascendantes
qui consistent à construire un logiciel par composition à partir de modules existants et, d’autre part, les
méthodes descendantes qui décomposent récursivement le système jusqu’à arriver à des modules programmables
simplement.
La distinction entre fonctionnel (dirigée par le traitement) et orientée objet : Dans la stratégie fonc- tionnelle
(également qualifiée de structurée) un système est vu comme un ensemble hiérarchique d’unités en interaction,
ayant chacune une fonction clairement définie. Les fonctions disposent d’un état local, mais le système a un
état partagé, qui est centralisé et accessible par l’ensemble des fonctions. Les stratégies orientées objet considèrent
qu’un système est un ensemble d’objets inter- agissants. Chaque objet dispose d’un ensemble d’attributs
décrivant son état et l’état du système est décrit (de façon décentralisée) par l’état de l’ensemble.

-
11 -
1.2. POURQUOI ET COMMENT 12
MODÉLISER ?

1.3 De la programmation structurée à l’approche orientée objet

1.3.1 Méthodes fonctionnelles ou structurées

Fig. 1.3 – Représentation graphique d’une approche fonctionnelle

Les méthodes fonctionnelles (également qualifiées de méthodes structurées) trouvent leur origine dans les langages
procéduraux. Elles mettent en évidence les fonctions à assurer et proposent une approche hiérarchique descendante et
modulaire.
Ces méthodes utilisent intensivement les raffinements successifs pour produire des spécifications dont l’essentielle
est sous forme de notation graphique en diagrammes de flots de données. Le plus haut niveau représente l’ensemble du
problème (sous forme d’activité, de données ou de processus, selon la méthode). Chaque niveau est ensuite décomposé
en respectant les entrées/sorties du niveau supérieur. La décomposition se poursuit jusqu’à arriver à des composants
maîtrisables (cf. figure 1.3).
L’approche fonctionnelle dissocie le problème de la représentation des données, du problème du traitement de ces
données. Sur la figure 1.3, les données du problème sont représentées sur la gauche. Des flèches transversalles
matérialisent la manipulation de ces données par des sous-fonctions. Cet accès peut-être direct (c’est parfois le cas quand
les données sont regroupées dans une base de données), ou peut être réalisé par le passage de paramètre depuis le
programme principal.
La SADT (Structured Analysis Design Technique) est probablement la méthode d’analyse fonctionnelle et de
gestion de projets la plus connue. Elle permet non seulement de décrire les tâches du projet et
leurs interactions, mais aussi de décrire le système que le projet vise à étudier, créer ou modifier, en mettant notamment
en évidence les parties qui constituent le système, la finalité et le fonctionnement de chacune, ainsi que les interfaces
entre ces diverses parties. Le système ainsi modélisé n’est pas une simple collection d’éléments indépendants, mais une
organisation structurée de ceux-ci dans une finalité précise.

1.3.2 L’approche orientée objet

L’approche orientée objet considère le logiciel comme une collection d’objets dissociés, et identifiés, définis par des
propriétés. Une propriété est soit un attribut (i.e. une donnée caractérisant l’état de l’objet), entité élémentaire
comportementale de l’objet). La fonctionnalité du logiciel émerge alors de l’interaction entre les différents objets qui le
constituent. L’une des particularités de cette approche est qu’elle rapproche les données et leurs traitements associés au
sein d’un unique objet.
Comme nous venons de le dire, un objet est caractérisé par plusieurs notions :
L’identité – L’objet possède une identité, qui permet de le distinguer des autres objets, indépendamment de son état.
On construit généralement cette identité grâce à un identifiant découlant naturellement du problème (par exemple
un produit pourra être repéré par un code, une voiture par un numéro de série, etc.)
Les attributs – Il s’agit des données caractérisant l’objet. Ce sont des variables stockant des informations sur l’état de
l’objet.

-
12 -
1.3. DE LA PROGRAMMATION STRUCTURÉE À L’APPROCHE ORIENTÉE 19
OBJET

Les méthodes – Les méthodes d’un objet caractérisent son comportement, c’est-à-dire l’ensemble des actions (appelées
opérations) que l’objet est à même de réaliser. Ces opérations permettent de faire réagir l’objet aux sollicitations
extérieures (ou d’agir sur les autres objets). De plus, les opérations sont étroitement liées aux attributs, car leurs
actions peuvent dépendre des valeurs des attributs, ou bien les modifier.
La difficulté de cette modélisation consiste à créer une représentation abstraite, sous forme d’objets, d’entités ayant
une existence matérielle (chien, voiture, ampoule, personne, . . .) ou bien virtuelle (client, temps, . . .).
La Conception Orientée Objet (COO) est la méthode qui conduit à des architectures logicielles fondées sur les objets
du système, plutôt que sur la fonction qu’il est censé réaliser.

1.3.3 Approche fonctionnelle vs. approche objet

Selon la thèse de Church-Turing, tout langage de programmation non trivial équivaut à une machine de Turing. Il
en résulte que tout programme qu’il est possible d’écrire dans un langage pourrait également être écrit dans n’importe
quel autre langage. Ainsi, tout ce que l’on fait avec un langage de programmation par objets pourrait être fait en
programmation impérative. La différence entre une approche fonctionnelle et une approche objet n’est donc pas d’ordre
logique, mais pratique.
L’approche structurée privilégie la fonction comme moyen d’organisation du logiciel. Ce n’est pas pour cette
raison que l’approche objet est une approche non fonctionnelle. En effet, les méthodes d’un objet sont des fonctions.
Ce qui différencie sur le fond l’approche objet de l’approche fonctionnelle, c’est que les fonctions obtenues à l’issue
de la mise en œuvre de l’une ou l’autre méthode sont distinctes. L’approche objet est une approche orientée donnée.
Dans cette approche, les fonctions se déduisent d’un regroupement de champs de données formant une entité
cohérente, logique, tangible et surtout stable quant au problème traité. L’approche structurée classique privilégie une
organisation des données pos- térieure à la découverte des grandes, puis petites fonctions qui les décomposent,
l’ensemble constituant les services qui répondent aux besoins.
En approche objet, l’évolution des besoins aura le plus souvent tendance à se présenter comme un changement de
l’interaction des objets. S’il faut apporter une modification aux données, seul l’objet incriminé (encapsulant cette donnée)
sera modifié. Toutes les fonctions à modifier sont bien identifiées : elles se trouvent dans ce même objet : ce sont ses
méthodes. Dans une approche structurée, l’évolution des besoins entraîne souvent une dégénérescence, ou une profonde
remise en question, de la topologie typique de la figure 1.3 car la décomposition des unités de traitement (du programme
principal aux sous- fonctions) est directement dictée par ces besoins. D’autre part, une modification des données entraîne
généralement une modification d’un nombre important de fonctions éparpillées et difficiles à identifier dans la hiérarchie
de cette décomposition.
En fait, la modularité n’est pas antinomique de l’approche structurée. Les modules résultant de la
décomposition objet sont tout simplement différents de ceux émanant de l’approche structurée. Les unités de
traitement, et surtout leur dépendance dans la topologie de la figure 1.3 sont initialement bons. C’est leur résistance au
temps, contrairement aux modules objet, qui est source de problème. La structure d’un logiciel issue d’une approche
structurée est beaucoup moins malléable, adaptable, que celle issue d’une approche objet.
Ainsi la technologie objet est la conséquence ultime de la modularisation du logiciel, démarche qui vise à
maîtriser sa production et son évolution. Mais malgré cette continuité logique les langages objet ont apporté en
pratique un profond changement dans l’art de la programmation : ils impliquent en effet un changement de l’attitude
mentale du programmeur.

1.3.4 Concepts importants de l’approche objet

Dans la section 1.3.2, nous avons dit que l’approche objet rapproche les données et leurs traitements. Mais cette
approche ne fait pas que ça, d’autres concepts importants sont spécifiques à cette approche et participent à la qualité du
logiciel.

-
19 -
 1.3. DE LA PROGRAMMATION STRUCTURÉE À L’APPROCHE ORIENTÉE 20
OBJET

Notion de classe
Tout d’abord, introduisons la notion de classe. Une classe est un type de données abstrait, caractérisé par des
propriétés (attributs et méthodes) communes à toute une famille d’objets et permettant de créer (instancier) des
objets possédant ces propriétés. Les autres concepts importants qu’il nous faut maintenant introduire sont
l’encapsulation, l’héritage et l’agrégation.

Encapsulation
L’encapsulation consiste à masquer les détails d’implémentation d’un objet, en définissant une inter- face.
L’interface est la vue externe d’un objet, elle définit les services accessibles (offerts) aux utilisateurs de l’objet.
L’encapsulation facilite l’évolution d’une application car elle stabilise l’utilisation des objets : on peut modifier
l’implémentation des attributs d’un objet sans modifier son interface, et donc la façon dont l’objet est utilisé.
L’encapsulation garantit l’intégrité des données, car elle permet d’interdire, ou de restreindre, l’accès direct aux
attributs des objets.

Héritage, Spécialisation, Généralisation et polymorphisme

L’héritage est un mécanisme de transmission des propriétés d’une classe (ses attributs et méthodes) vers une sous-
classe. Une classe peut être spécialisée en d’autres classes, afin d’y ajouter des caractéris- tiques spécifiques ou d’en
adapter certaines. Plusieurs classes peuvent être généralisées en une classe qui les factorise, afin de regrouper les
caractéristiques communes d’un ensemble de classes.
Ainsi, la spécialisation et la généralisation permettent de construire des hiérarchies de classes. L’hé- ritage peut être
simple ou multiple. L’héritage évite la duplication et encourage la réutilisation.
Le polymorphisme représente la faculté d’une méthode à pouvoir s’appliquer à des objets de classes différentes.
Le polymorphisme augmente la généricité, et donc la qualité, du code.

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

1.3.5 Historique la programmation par objets

Les premiers langages de programmation qui ont utilisé des objets sont Simula I (1961-64) et Simula 67 (1967),
conçus par les informaticiens norvégiens Ole-Johan Dahl et Kristan Nygaard. Simula 67 contenait déjà les objets, les
classes, l’héritage, l’encapsulation, etc.
Alan Kay, du PARC de Xerox, avait utilisé Simula dans les années 1960. Il réalisa en 1976 Smalltalk qui reste,
aux yeux de certains programmeurs, le meilleur langage de programmation par objets.
Bjarne Stroustrup a mis au point C++, une extension du langage C permettant la programmation orientée objets, aux
Bell Labs d’AT&T en 1982. C++ deviendra le langage le plus utilisé par les pro- grammeurs professionnels. Il arrivera
à maturation en 1986, sa standardisation ANSI / ISO date de 1997.
Java est lancé par Sun en 1995. Comme il présente plus de sécurité que C++, il deviendra le langage favori de certains
programmeurs professionnels.

1.4 UML
1.4.1 Introduction
La description de la programmation par objets a fait ressortir l’étendue du travail conceptuel néces- saire : définition
des classes, de leurs relations, des attributs et méthodes, des interfaces etc.

-
20 -
1.4. UML 21

Pour programmer une application, il ne convient pas de se lancer tête baissée dans l’écriture du code : il faut d’abord
organiser ses idées, les documenter, puis organiser la réalisation en définissant les modules et étapes de la réalisation.
C’est cette démarche antérieure à l’écriture que l’on appelle modélisation ; son produit est un modèle.
Les spécifications fournies par la maîtrise d’ouvrage en programmation impérative étaient souvent floues : les
articulations conceptuelles (structures de données, algorithmes de traitement) s’exprimant dans le vocabulaire de
l’informatique, le modèle devait souvent être élaboré par celle-ci. L’approche objet permet en principe à la maîtrise
d’ouvrage de s’exprimer de façon précise selon un vocabulaire qui, tout en transcrivant les besoins du métier, pourra
être immédiatement compris par les informaticiens. En principe seulement, car la modélisation demande aux maîtrises
d’ouvrage une compétence, un professionnalisme qui ne sont pas aujourd’hui répandus.

1.4.2 Histoire des modélisations par objets

Les méthodes utilisées dans les années 1980 pour organiser la programmation impérative (notam- ment 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ée 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, plus modeste). 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’OMG5. L’OMG adopte en novembre 1997 UML 1.1 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.

1.4.3 UML en œuvre

UML n’est pas une méthode (i.e. une description normative des étapes de la modélisation) : ses auteurs ont en effet
estimé qu’il n’était pas opportun de définir une méthode en raison de la diversité des cas particuliers. Ils ont préféré se
borner à définir un langage graphique qui permet de représenter, de
5 L’OMG (Object Management Group) est une association américaine à but non-lucratif créée en 1989 dont l’objectif est de standardiser

et promouvoir le modèle objet sous toutes ses formes. L’OMG est notamment à la base des spécifications UML, MOF, CORBA et IDL.
L’OMG est aussi à l’origine de la recommandation MDA

-
21 -
 1.4. UML 22

communiquer les divers aspects d’un système d’information (aux graphiques sont bien sûr associés des textes qui
expliquent leur contenu). UML est donc un métalangage car il fournit les éléments permettant de construire le modèle
qui, lui, sera le langage du projet.
Il est impossible de donner une représentation graphique complète d’un logiciel, ou de tout autre système complexe,
de même qu’il est impossible de représenter entièrement une statue (à trois dimen- sions) par des photographies (à deux
dimensions). Mais il est possible de donner sur un tel système des vues partielles, analogues chacune à une
photographie d’une statue, et dont la juxtaposition donnera une idée utilisable en pratique sans risque d’erreur grave.
UML 2.0 comporte ainsi treize types de diagrammes représentant autant de vues distinctes pour représenter des
concepts particuliers du système d’information. Ils se répartissent en deux grands groupes :

Diagrammes structurels ou diagrammes statiques (UML Structure)

– diagramme de classes (Class diagram)
– diagramme d’objets (Object diagram)
– diagramme de composants (Component diagram)
– diagramme de déploiement (Deployment diagram)
– diagramme de paquetages (Package diagram)
– diagramme de structures composites (Composite structure diagram)
Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior)
– diagramme de cas d’utilisation (Use case diagram)
– diagramme d’activités (Activity diagram)
– diagramme d’états-transitions (State machine diagram)
– Diagrammes d’interaction (Interaction diagram)
– diagramme de séquence (Sequence diagram)
– diagramme de communication (Communication diagram)
– diagramme global d’interaction (Interaction overview diagram)
– diagramme de temps (Timing diagram)

Ces diagrammes, d’une utilité variable selon les cas, ne sont pas nécessairement tous produits à l’oc- casion d’une
modélisation. Les plus utiles pour la maîtrise d’ouvrage sont les diagrammes d’activités, de cas d’utilisation, de classes,
d’objets, de séquence et d’états-transitions. Les diagrammes de composants, de déploiement et de communication sont
surtout utiles pour la maîtrise d’œuvre à qui ils permettent de formaliser les contraintes de la réalisation et la solution
technique.

Diagramme de cas d’utilisation

Le diagramme de cas d’utilisation (cf. section 2) représente la structure des grandes fonctionnalités nécessaires aux
utilisateurs du système. C’est le premier diagramme du modèle UML, celui où s’assure la relation entre l’utilisateur
et les objets que le système met en œuvre.

Diagramme de classes
Le diagramme de classes (cf. section 3) est généralement considéré comme le plus important dans un développement
orienté objet. Il représente l’architecture conceptuelle du système : il décrit les classes que le système utilise, ainsi que
leurs liens, que ceux-ci représentent un emboîtage conceptuel (héritage) ou une relation organique (agrégation).

Diagramme d’objets
Le diagramme d’objets (cf. section 3.6) permet d’éclairer un diagramme de classes en l’illustrant par des
exemples. Il est, par exemple, utilisé pour vérifier l’adéquation d’un diagramme de classes à différents cas
possibles.

-
22 -
Diagramme d’états-transitions
Le diagramme d’états-transitions (cf. section 5) représente la façon dont évoluent (i.e. cycle de vie) les objets
appartenant à une même classe. La modélisation du cycle de vie est essentielle pour représenter et mettre en forme
la dynamique du système.

Diagramme d’activités
Le diagramme d’activités (cf. section 6) n’est autre que la transcription dans UML de la représen- tation du processus
telle qu’elle a été élaborée lors du travail qui a préparé la modélisation : il montre l’enchaînement des activités qui
concourent au processus.

Diagramme de séquence et de communication

Le diagramme de séquence (cf. section 7.3) représente la succession chronologique des opérations réalisées par
un acteur. Il indique les objets que l’acteur va manipuler et les opérations qui font passer d’un objet à l’autre. On
peut représenter les mêmes opérations par un diagramme de communication (cf. section 7.2), graphe dont les nœuds
sont des objets et les arcs (numérotés selon la chronologie) les échanges entre objets. En fait, diagramme de séquence
et diagramme de communication sont deux vues différentes mais logiquement équivalentes (on peut construire l’une
à partir de l’autre) d’une même chronologie. Ce sont des diagrammes d’interaction (section 7).

1.4.4 Comment présenter un modèle UML ?

La présentation d’un modèle UML se compose de plusieurs documents écrits en langage courant et d’un
document formalisé : elle ne doit pas se limiter au seul document formalisé car celui-ci est pratiquement
incompréhensible si on le présente seul. Un expert en UML sera capable dans certains cas de reconstituer les intentions
initiales en lisant le modèle, mais pas toujours ; et les experts en UML sont rares. Voici la liste des documents qui
paraissent nécessaires :
Présentation stratégique : elle décrit pourquoi l’entreprise a voulu se doter de l’outil considéré, les buts qu’elle
cherche à atteindre, le calendrier de réalisation prévu, etc.
Présentation des processus de travail par lesquels la stratégie entend se réaliser : pour permettre au
lecteur de voir comment l’application va fonctionner en pratique, elle doit être illustrée par une esquisse des
écrans qui seront affichés devant les utilisateurs de terrain.
Explication des choix qui ont guidé la modélisation formelle : il s’agit de synthétiser, sous les yeux du
lecteur, les discussions qui ont présidé à ces choix.
Modèle formel : c’est le document le plus épais et le plus difficile à lire. Il est préférable de le présenter sur l’Intranet de
l’entreprise. En effet, les diagrammes peuvent être alors équipés de liens hypertextes permettant l’ouverture de
diagrammes plus détaillés ou de commentaires.
On doit présenter en premier le diagramme de cas d’utilisation qui montre l’enchaînement des cas d’utilisation au
sein du processus, enchaînement immédiatement compréhensible ; puis le diagramme d’activités, qui montre le contenu
de chaque cas d’utilisation ; puis le diagramme de séquence, qui montre l’enchaînement chronologique des opérations
à l’intérieur de chaque cas d’utilisation. Enfin, le diagramme de classes, qui est le plus précis conceptuellement mais
aussi le plus difficile à lire car il présente chacune des classes et leurs relations (agrégation, héritage, association, etc.).

-
23 -
Chapitre 3

Diagramme de cas d’Utilisation (use case)

Le diagramme de cas d'utilisation : Un outil essentiel
Le diagramme de cas d'utilisation est un élément essentiel lorsqu'il s'agit de travailler avec UML pour le recueil des
besoins.
UML, en lui-même, est simplement un langage, et son utilité réside dans sa capacité à formaliser les besoins. En
d'autres termes, il permet de représenter ces besoins de manière graphique, de manière suffisamment claire et simple
pour que toutes les personnes impliquées dans un projet puissent les comprendre. Il est important de rappeler que
très souvent, le maître d'ouvrage et les utilisateurs finaux ne sont pas des informaticiens, ils ont donc besoin d'un
moyen simple et accessible pour exprimer leurs besoins. C'est précisément ce que les diagrammes de cas d'utilisation
offrent.
Les diagrammes de cas d'utilisation servent à identifier et à répertorier les principales fonctionnalités d'un système.
Ils permettent de visualiser de manière synthétique comment les acteurs (utilisateurs ou autres systèmes)
interagissent avec le système, quelles actions ils réalisent, et quelles sont les fonctionnalités offertes par le système
en réponse à ces actions. En résumé, les diagrammes de cas d'utilisation sont un outil puissant pour comprendre et
documenter les exigences du projet de manière compréhensible pour toutes les parties prenantes.
EXEMPLE : La figure ci-dessous modélise une borne interactive qui permet d’accéder à une banque. Le système à
modéliser apparaît dans un cadre (cela permet de séparer le système à modéliser du monde extérieur). Les
utilisateurs sont représentés par des petits bonshommes, et les grandes fonctionnalités (les cas d’utilisation) par des
ellipses.

L’ensemble des cas d’utilisation contenus dans le cadre constitue « un sujet ». Les petits bonshommes sont appelés «
acteurs ». Ils sont connectés par de simples traits (appelés « associations ») aux cas d’utilisation et mettent en
évidence les interactions possibles entre le système et le monde extérieur. Chaque cas modélise une façon
particulière et cohérente d’utiliser un système pour un acteur donné.

Définition d'un cas d'utilisation

Un cas d'utilisation est une représentation spécifique de la manière dont un système est utilisé. Dans cette
représentation, les acteurs, qui sont des entités extérieures au système, sont utilisés pour modéliser toutes les
interactions avec ce dernier. Un cas d'utilisation décrit un scénario complet, de son déclenchement initial à son
déroulement et jusqu'à sa conclusion, tout en se concentrant sur le service qu'il offre à l'acteur qui l'initie. En résumé,
un cas d'utilisation permet de décrire comment un acteur interagit avec un système pour accomplir une tâche ou
atteindre un objectif spécifique.
Notation et spécification -
24 - du cas est inclus dans l’ellipse ou bien
Un cas d’utilisation se représente par une ellipse (figure ci-dessous). Le nom
il figure dessous. Un stéréotype (voir la définition ci-après), peut être ajouté optionnellement au-dessus du nom, et
une liste de propriétés placée au-dessous. Un cas d’utilisation se représente aussi sous la forme d’un rectangle à deux
compartiments : celui du haut contient le nom du cas ainsi qu’une ellipse (symbole d’un cas d’utilisation) ; celui du
bas est optionnel et peut contenir une liste de propriétés (figure ci-dessous). Un acteur se représente par un petit
bonhomme ayant son nom inscrit dessous (figure ci-dessous) ou par un rectangle contenant le stéréotype acteur avec
son nom juste en dessous (figure ci-dessous). Il est recommandé d’ajouter un commentaire sur l’acteur pour préciser
son rôle.

La figure ci-dessous représente un acteur par un rectangle. UML utilise aussi les rectangles pour représenter des
classes, et plus généralement des classeurs. Pour autant, la notation n’est pas ambiguë puisque le stéréotype acteur
indique que le rectangle désigne un acteur. Les stéréotypes permettent d’adapter le langage à des situations
particulières.
Définition Un stéréotype représente une variation d’un élément de modèle existant.

À un niveau d’abstraction plus élevé, UML permet de représenter tous les cas d’utilisation d’un système par un
simple rectangle. La figurec-dessous montre comment un tel rectangle peut remplacer tous les cas d’utilisation de la
figure 1

Le rectangle de la figure est appelé « classeur ».

Définition d'un classeur

Un classeur est un élément de modélisation utilisé dans le contexte de la conception de systèmes. Il sert à décrire une
unité, qu'elle soit de nature comportementale ou structurelle. Les acteurs, qui représentent les entités externes
interagissant avec un système, et les cas d'utilisation, qui décrivent les scénarios d'utilisation d'un système, sont des
exemples de classeurs couramment utilisés dans la modélisation.
Il convient de noter que le terme "classeur" est un concept générique qui englobe divers types d'unités de
modélisation, notamment les classes (dans le contexte de la programmation orientée objet), les parties d'un système,
et d'autres éléments similaires. Cette notion de "classeur" est utilisée pour simplifier la discussion et l'organisation
des différents éléments lors de la modélisation d'un système, en les regroupant sous une seule catégorie générale.
Notation
Un classeur se représente par un rectangle contenant éventuellement des compartiments (la figure ci-dessous montre
comment il est possible de faire figurer explicitement des cas d’utilisation dans un classeur).

-
25 -
 Un acteur peut utiliser plusieurs fois le même cas d’utilisation.

EXEMPLE La figure ci-dessous montre un internaute qui télécharge plusieurs morceaux de musique sur Internet.

Le symbole * qui signifie « plusieurs »

est ajouté à l’extrémité du cas et s’appelle une multiplicité. Plusieurs valeurs sont possibles pour la multiplicité :
exactement n s’écrit tout simplement n, m..n signifie entre m et n, etc. Préciser une multiplicité sur une relation
n’implique pas nécessairement que les cas sont utilisés en même temps.

relations entre cas d'utilisations :

Les relations entre les cas d'utilisation en UML sont essentielles pour clarifier les interactions et les dépendances
entre les différentes fonctionnalités d'un système. Voici une explication des principaux types de relations entre les
cas d'utilisation :
Relation d'inclusion (inclusion) :
Cette relation indique qu'un cas d'utilisation A est inclus dans un autre cas d'utilisation B.
Elle signifie que le comportement décrit par A est inclus dans le comportement global de B. En d'autres termes, B
dépend de A.
Cette dépendance est symbolisée par le stéréotype "inclus".
Exemple : Dans le contexte d'une banque, l'accès aux informations d'un compte bancaire (cas A) est inclus dans le
processus de transaction bancaire (cas B), car il nécessite une phase d'authentification avec un mot de passe.
Relation d'extension (extension) :
Cette relation indique qu'un cas d'utilisation A peut étendre le comportement d'un autre cas d'utilisation B.
L'extension est souvent soumise à une condition, qui est exprimée graphiquement sous la forme d'une note.
Exemple : Dans une banque, la vérification du solde du compte (cas A) peut étendre le processus de retrait d'argent
(cas B) uniquement si la demande de retrait dépasse 20 euros.
Relation de généralisation/spécialisation (généralisation) :
Cette relation indique qu'un cas d'utilisation A est une généralisation d'un cas d'utilisation B.
Cela signifie que B est un cas particulier de A. A est plus général, tandis que B est plus spécifique.
Exemple : Dans le contexte bancaire, la consultation d'un compte bancaire via Internet (cas A) est une généralisation
de la consultation de compte (cas B).
Ces relations aident à organiser et à hiérarchiser les cas d'utilisation dans-un diagramme UML, ce qui facilite la
compréhension et la gestion des fonctionnalités du système. Les relations26d'inclusion
- et d'extension sont
particulièrement utiles pour décomposer un cas complexe en sous-cas plus simples, améliorant ainsi la lisibilité et la
modularité du modèle.
EXEMPLE À la figure ci-dessous le modélisateur a jugé que la vente d’un article par correspondance est un
problème complexe et qu’il est important de faire apparaître dans le modèle une décomposition en sous-cas.
Notation et spécification Une dépendance se représente par une flèche pointillée. Un stéréotype est souvent ajouté
au-dessus du trait. Le stéréotype inclut indique que la relation de dépendance est une inclusion (figures 1.8 et 1.9).
Le stéréotype étend indique une extension (figure 1.8). L’extension peut intervenir à un point précis du cas étendu ;
ce point s’appelle le point d’extension ; il porte un nom, qui figure dans un compartiment du cas étendu sous la
rubrique « point d’extension », et est éventuellement associé à une contrainte indiquant le moment où l’extension
intervient. Une extension est souvent soumise à une condition (indiquée dans une note attachée à la flèche
pointillée). Le symbole utilisé pour la généralisation est une flèche en traits pleins dont la pointe est un triangle
fermé. La flèche pointe vers le cas le plus général (figure 1.8).

Un cas relié à un autre cas peut ne pas être directement accessible à un acteur (figure 1.9). Un tel cas est appelé « cas
interne ».
Définition Un cas d’utilisation est dit « interne » s’il n’est pas relié directement à un acteur.
Les relations entre cas ne sont pas obligatoires. Elles permettent de clarifier et d’enrichir les cas d’utilisation. Par
exemple, à la figure 1.8, rien n’empêche de regrouper les cas « Consulter comptes » et « Consulter sur Internet » en
un seul cas. Cependant, indiquer dès la phase de recueil des besoins qu’il y a des cas particuliers apporte une
information supplémentaire pertinente. La question à se poser est : faut-il la faire figurer dans le diagramme de cas
d’utilisation ou la prendre en compte plus tard ? La réponse à cette question ne sera pas toujours la même selon le
contexte du projet.
Remarque Attention à l’orientation des flèches : si le cas A inclut B on trace la flèche de A vers B, mais si B étend A,
la flèche est dirigée de B vers A.
RELATIONS ENTRES 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 (tous les cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse
n’est pas vrai). La figure ci-dessous montre que le directeur des ventes est- un préposé aux commandes avec un
pouvoir supplémentaire (en plus de pouvoir passer et suivre une commande, 27 - il peut gérer le stock). Le préposé aux
commandes ne peut pas gérer le stock.

Notation Le symbole utilisé pour la généralisation entre acteurs est une flèche en traits pleins dont la pointe est un
triangle fermé. La flèche pointe vers l’acteur le plus général.
REGROUPEMENT DES CAS D'UTILISATION EN PAQUETAGES
En effet, UML offre la possibilité de regrouper des cas d'utilisation dans des entités appelées "paquetages". Ce
regroupement peut être effectué de différentes manières pour organiser efficacement les cas d'utilisation dans un
diagramme de cas d'utilisation. Voici quelques points importants à retenir :
Regroupement par Acteur :
Vous pouvez organiser des cas d'utilisation en les associant à des acteurs spécifiques. Cela signifie que les cas
d'utilisation sont regroupés en fonction des acteurs qui les initient ou les utilisent. Cette approche permet de montrer
clairement quelles fonctionnalités sont liées à chaque acteur dans le système.
Regroupement par Domaine Fonctionnel :
Vous pouvez également organiser des cas d'utilisation en fonction de leur domaine fonctionnel. Cela signifie que les
cas d'utilisation sont regroupés en fonction de la catégorie ou de la fonction à laquelle ils appartiennent. Par exemple,
vous pourriez regrouper tous les cas d'utilisation liés aux opérations bancaires, tels que la consultation de compte, le
retrait d'argent, le virement, etc., dans un paquetage "Opérations Bancaires".
Hiérarchie de Paquetages :
Vous pouvez créer une hiérarchie de paquetages en incorporant un paquetage dans un autre paquetage. Cela permet
de structurer davantage le modèle. Par exemple, vous pourriez avoir un paquetage principal appelé "Système
Bancaire" qui contient plusieurs sous-paquetages tels que "Opérations Bancaires", "Gestion des Clients", etc.
L'utilisation de paquetages permet de rendre le modèle plus modulaire, plus organisé et plus facile à gérer. Il offre
également une représentation visuelle claire de la structure fonctionnelle du système, que ce soit en fonction des
acteurs ou des domaines fonctionnels.
En résumé, les paquetages sont une fonctionnalité essentielle d'UML qui vous permet de regrouper et d'organiser
efficacement les cas d'utilisation dans un diagramme de cas d'utilisation, en fonction de vos besoins de modélisation.
Définition Un paquetage permet d’organiser des éléments de modélisation en groupe. Un paquetage peut contenir
des classes, des cas d’utilisations, des interfaces, etc.
EXEMPLE À la figure ci-dessous, trois paquetages ont été créés : Client, Stock et Support. Ces paquetages
contiennent les cas d’utilisation du diagramme de la figure 1.10 (Client contient les cas « Passer une commande » et
« Suivre une commande », Stock contient le cas « Gérer le stock », tandis que le cas « Rechercher article » est inclus
dans le paquetage Support.

-
28 -
En tant que langage, UML est soumis à des règles de nommage qu’il faut strictement respecter : pour accéder au
contenu de paquetages imbriqués les uns dans les autres, il faut utiliser des deux-points comme séparateur des noms
de paquetage. Par exemple, si un paquetage B inclus dans un paquetage A contient une classe X, il faut écrire
A::B::X pour pouvoir utiliser la classe X en dehors du contexte des paquetages.

-
29 -
Chapitre 4

Diagramme de classes (Class Diagram)

3.1 Introduction
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.
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 permet de fournir une représentation abstraite des objets du système qui vont interagir
ensemble pour réaliser les cas d’utilisation. Il est important de noter qu’un même objet peut très bien intervenir dans la
réalisation de plusieurs cas d’utilisation. Les cas d’utilisation ne réalisent donc pas une partition1 des classes du
diagramme de classes. Un diagramme de classes n’est donc pas adapté (sauf cas particulier) pour détailler, décomposer,
ou illustrer la réalisation d’un cas d’utilisation particulier.
Il s’agit d’une vue statique car on ne tient pas compte du facteur temporel dans le comportement du système. Le
diagramme de classes modélise les conceps du domaine d’application ainsi que les concepts internes créés de toutes
pièces dans le cadre de l’implémentation d’une application. Chaque langage de Programmation Orienté Objets donne
un moyen spécifique d’implémenter le paradigme objet (pointeurs ou pas, héritage multiple ou pas, etc.), mais le
diagramme de classes permet de modéliser les classes du système et leurs relations indépendamment d’un langage
de programmation particulier.
Les principaux éléments de cette vue statique sont les classes et leurs relations : association, généra- lisation et
plusieurs types de dépendances, telles que la réalisation et l’utilisation.

3.2 Les classes

3.2.1 Notions de classe et d’instance de classe
Une instance est une concrétisation d’un concept abstrait. Par exemple :
– la Ferrari Enzo qui se trouve dans votre garage est une instance du concept abstrait Automobile ;
– l’amitié qui lie Jean et Marie est une instance du concept abstrait Amitié ;
Une classe est un concept abstrait représentant des éléments variés comme :
– des éléments concrets (ex : des avions),
– des éléments abstraits ( ex : des commandes),
– des composants d’une application (ex : les boutons des boîtes de dialogue),
– des structures informatiques (ex : des tables de hachage),
– des éléments comportementaux (ex : des tâches), etc.
1 Une partition d’un ensemble est un ensemble de parties non vides de cet ensemble, deux à deux disjointes et dont la réunion est égale

à l’ensemble.

35

-
30 -
Tout système orienté objet est organisé autour des classes.
Une classe est 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, si l’on considère que Homme (au sens être humain) est un concept abstrait, on peut dire que la personne
Marie-Cécile est une instance de Homme. Si Homme était une classe, Marie-Cécile en serait une instance : un objet.

3.2.2 Notions de propriétés

Une classe définit un jeu d’objets dotés de propriétés. Les propriétés d’un objet permettent de spécifier son état
et son comportement. Dans les sections 1.3.2 et 1.3.4, nous avons dit que les propriétés d’un objet étaient soit des
attributs, soit des opérations. Ce n’est pas exact dans un diagramme de classe car les terminaisons d’associations
font également partie des propriétés d’un objet au même titre que les attributs et les opération.
État d’un objet : Ce sont les attributs et les terminaisons d’associations (cf. section 3.3.2) qui décrivent l’état d’un
objet. On utilise les attributs pour des valeurs de données pures, dépourvues d’identité, telles que les nombres et
les chaînes de caractères. On utilise les associations pour connecter les classes du diagramme de classe. Dans ce
cas, la terminaison de l’association (du côté de la classe cible) est une propriété de la classe de base.
Les propriétés décrites par les attributs prennent des valeurs lorsque la classe est instanciée. L’instance d’une
association est appelée un lien.
Comportement d’un objet : Les opérations décrivent les éléments individuels d’un comportement que l’on peut
invoquer. Ce sont des fonctions qui peuvent prendre des valeurs en entrée et modifier les attributs ou produire des
résultats.
Une opération est la spécification (i.e. déclaration) d’une méthode. L’implémentation (i.e. définition) d’une
méthode est également appelée méthode. Il y a donc une ambiguïté sur le terme méthode.
Les attributs, les terminaisons d’association et les méthodes constituent donc les propriétés d’une classe (et de ses
instances).

3.2.3 Représentation graphique

Une classe est un classeur 2. Elle est représentée par un rectangle divisé en trois à cinq compartiments (figure 3.1).

Fig. 3.1 – Représentation UML d’une classe

Le premier indique le nom de la classe (cf. section 3.2.5), le deuxième ses attributs (cf. section 3.2.6) et le troisième
ses opérations (cf. section 3.2.7). Un compartiment des responsabilités peut être ajouté pour énumérer l’ensemble de
tâches devant être assurées par la classe mais pour lesquelles on ne dispose pas encore assez d’informations. Un
compartiment des exceptions peut également être ajouté pour énumérer les situations exceptionnelles devant être gérées
par la classe.
2 De manière générale, toute boîte non stéréotypée dans un diagramme de classes est implicitement une classe. Ainsi, le

stéréotype class est le stéréotype par défaut.

-
36 -
 3.2. LES CLASSES 37

3.2.4 Encapsulation, visibilité, interface

Fig. 3.2 – Bonnes pratiques concernant la manipulation des attributs.

Nous avons déjà abordé cette problématique section 1.3.4. L’encapsulation est un mécanisme consis- tant à
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 appel 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 ou +: tout élément qui peut voir le conteneur peut également voir l’élément indiqué.
protected ou # : seul un élément situé dans le conteneur ou un de ses descendants peut voir l’élément indiqué.
private ou - : seul un élément situé dans le conteneur peut voir l’élément.
package ou ∼ ou rien : seul un élément déclaré dans le même paquetage peut voir l’élément.
Par ailleur, UML 2.0 donne la possibilité d’utiliser n’importe quel langage de programmation pour la
spécification de la visibilité.
Dans une classe, le marqueur de visibilité se situe au niveau de ses propriétés (attributs, terminaisons d’association
et opération). Il permet d’indiquer si une autre classe peut accéder à ses propriétés.
Dans un paquetage, le marqueur de visibilité se situe sur des éléments contenus directement dans le paquetage,
comme les classes, les paquetages imbriqués, etc. Il indique si un autre paquetage susceptible d’accéder au premier
paquetage peut voir les éléments.
Dans la pratique, lorsque des attributs doivent être accessibles de l’extérieur, il est préférable que cet accès ne soit
pas direct mais se fasse par l’intermédiaire de méthodes (figure 3.2).

3.2.5 Nom d’une classe

Le nom de la classe doit évoquer le concept décrit par la classe. Il commence par une majuscule. On peut ajouter
des informations subsidiaires comme le nom de l’auteur de la modélisation, la date, etc. Pour indiquer qu’une
classe est abstraite, il faut ajouter le mot-clef abstract.
La syntaxe de base de la déclaration d’un nom d’une classe est la suivante :
[ <Nom_du_paquetage_1>::...::<Nom_du_paquetage_N> ]
<Nom_de_la_classe> [ { [abstract], [<auteur>], [<date>], ... } ]

3.2.6 Les attributs

Attributs de la classe
Les attributs définissent des informations qu’une classe ou un objet doivent connaître. Ils représentent les données
encapsulées dans les objets de cette classe. Chacune de ces informations est définie par un

-
37 -
 3.3. RELATIONS ENTRE 38
CLASSES

nom, un type de données, une visibilité et peut être initialisé. Le nom de l’attribut doit être unique dans la classe. La
syntaxe de la déclaration d’un attribut est la suivante :
<visibilité> [/] <nom_attribut>:
<Type> [ ’[’ <multiplicité> ’]’ [ ’{’ <contrainte> ’}’ ] ] [ = <valeur_par_défaut> ]
Le type de l’attribut (<Type>) peut être un nom de classe, un nom d’interface ou un type de donné prédéfini. La
multiplicité (<multiplicité>) d’un attribut précise le nombre de valeurs que l’attribut peut contenir. Lorsqu’un
multiplicité supérieure à 1 est précisée, il est possible d’ajouter une contrainte (<contrainte>) pour préciser si les
valeurs sont ordonnées ({ordered}) ou pas ({list}).

Attributs de classe
Par défaut, chaque instance d’une classe possède sa propre copie des attributs de la classe. Les valeurs des attributs
peuvent donc différer d’un objet à un autre. Cependant, il est parfois nécessaire de définir un attribut de classe (static
en Java ou en C++) qui garde une valeur unique et partagée par toutes les instances de la classe. Les instances ont
accès à cet attribut mais n’en possèdent pas une copie. Un attribut de classe n’est donc pas une propriété d’une
instance mais une propriété de la classe et l’accès à cet attribut ne nécessite pas l’existence d’une instance.
Graphiquement, un attribut de classe est souligné.

Attributs dérivés
Les attributs dérivés peuvent être calculés à partir d’autres attributs et de formules de calcul. Lors de la
conception, un attribut dérivé peut être utilisé comme marqueur jusqu’à ce que vous puissiez déterminer les règles à lui
appliquer.
Les attributs dérivés sont symbolisés par l’ajout d’un « / » devant leur nom.

3.2.7 Les méthodes

Méthode de la classe
Dans une classe, une opération (même nom et même types de paramètres) doit être unique. Quand le nom d’une
opération apparaît plusieurs fois avec des paramètres différents, on dit que l’opération est surchargée. En revanche, il est
impossible que deux opérations ne se distinguent que par leur valeur retournée.
La déclaration d’un opération contient les types des paramètres et le type de la valeur de retour, sa syntaxe est la
suivante :
<visibilité> <nom_méthode> ( [ <paramètre> [, <paramètre> [, <paramètre> ...] ] ] ) :
[<valeur_renvoyé>] [ { <propriétés> } ]
La syntaxe de définition d’un paramètre (<paramètre>) est la suivante :
[<direction>] <nom_paramètre>:<Type> [’[’<multiplicité>’]’] [=<valeur_par_défaut>]
La direction peut prendre l’une des valeurs suivante :
in : Paramètre d’entrée passé par valeur. Les modifications du paramètre ne sont pas disponibles pour l’appelant.
C’est le comportement par défaut.
out : Paramètre de sortie uniquement. Il n’y a pas de valeur d’entrée et la valeur finale est disponible pour
l’appelant.
inout : Paramètre d’entrée/sortie. La valeur finale est disponible pour l’appelant.
Le type du paramètre (<Type>) peut être un nom de classe, un nom d’interface ou un type de donné prédéfini.
Les propriétés (<propriétés>) correspondent à des contraintes ou à des informations complémen- taires comme les
exceptions, les préconditions, les postconditions ou encore l’indication qu’une méthode est abstraite (mot-clef abstract),
etc.

-
38 -
 3.3. RELATIONS ENTRE 39
CLASSES

Méthode de classe
Comme pour les attributs de classe, il est possible de déclarer des méthodes de classe. Une méthode de classe ne
peut manipuler que des attributs de classe et ses propres paramètres. Cette méthode n’a pas accès aux attributs de la classe
(i.e. des instances de la classe). L’accès à une méthode de classe ne nécessite pas l’existence d’une instance de cette
classe.
Graphiquement, une méthode de classe est soulignée.

Méthodes et classes abstraites

Une méthode est dite abstraite lorsqu’on connaît son entête mais pas la manière dont elle peut être réalisée (i.e.
on connaît sa déclaration mais pas sa définition).
Une classe est dite abstraite lorsqu’elle définit au moins une méthode abstraite ou lorsqu’une classe parent (cf.
section 3.3.1) contient une méthode abstraite non encore réalisée.
On ne peut instancier une classe abstraite : elle est vouée à se spécialiser (cf. section 3.3.1). Une classe abstraite peut
très bien contenir des méthodes concrètes.
Une classe abstraite pure ne comporte que des méthodes abstraites. En programmation orientée objet, une telle classe
est appelée une interface.

3.2.8 Classe active

Une classe est passive par défaut, elle sauvegarde les données et offre des services aux autres. Une classe active
initie et contrôle le flux d’activités.
Graphiquement, une classe active est représentée comme une classe standard dont les lignes verticales du cadre, sur
les côtés droit et gauche, sont doublées.

3.3 Relations entre classes

3.3.1 Généralisation et Héritage

Fig. 3.3 – Partie du règne animal décrit avec l’héritage multiple.

La généralisation décrit une relation entre une classe générale (classe de base ou classe parent) et une classe
spécialisée (sous-classe). 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. Ainsi, l’héritage permet la classification des
objets (cf. figure 3.3).
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 (cf. figure 3.3).
Les propriétés principales de l’héritage sont :
– La classe enfant possède toutes les propriétés des ses classes parents, mais elle ne peut accéder aux propriétés
privées de celle-ci.

-
39 -
3.3. RELATIONS ENTRE 40
CLASSES

– Une classe enfant peut redéfinir (même signature) une ou plusieurs méthodes de la classe parent. Sauf
indication contraire, un objet utilise les opérations les plus spécialisées dans la hiérarchie des classes.
– Toutes les associations de la classe parent s’appliquent aux classes dérivées.
– Une instance d’une classe peut être utilisée partout où une instance de sa classe parent est attendue. Par
exemple, en se basant sur le diagramme de la figure 3.3, toute opération acceptant un objet d’une classe
Animal doit accepter un objet de la classe Chat.
– Une classe peut avoir plusieurs parents, on parle alors d’héritage multiple (cf. la classe Ornitho- rynque de
la figure 3.3). Le langage C++ est un des langages objet permettant son implémentation
effective, le langage java ne le permet pas.
En UML, la relation d’héritage n’est pas propre aux classes. Elle s’applique à d’autre éléments du langage
comme les paquetages, les acteurs ou les cas d’utilisation (cf. section 2.3.2).

3.3.2 Association
Une association est une relation entre deux classes (association binaire) ou plus (association n-aire), qui décrit les
connexions structurelle entre leurs instances.

Terminaison d’association vs. attribut

Un attribut est une association dégénérée dans laquelle une terminaison d’association 3 est détenue par un classeur
(généralement une classe). Le classeur détenant cette terminaison d’association devrait théoriquement se trouver à l’autre
terminaison, non modélisée, de l’association. Un attribut n’est donc rien d’autre qu’une terminaison d’un cas
particulier d’association.
Les terminaisons d’associations et les attributs sont donc deux éléments conceptuellement très proches que l’on
regroupe sous le terme de propriété structurelle.
Une propriété structurelle peut être paramètrée par les éléments suivant :
nom : Comme un attribut, une terminaison d’association peut être nommée. Le nom est situé à proximité de la
terminaison, mais contrairement à un attribut, ce nom est facultatif. Le nom d’une terminaison d’association est
appelée nom du rôle. Une association peut donc posséder autant de noms de rôle que de terminaisons (deux pour
une association binaire et n pour une association n-aire).
visibilité : Comme un attribut, une terminaison d’association possède une visibilité (cf. section 3.2.4). La visibilité est
mentionnée à proximité de la terminaison, et plus précisément, le cas échéant, devant le nom de la terminaison.
multiplicité : Comme un attribut, une terminaison d’association peut posséder une multiplicité. Elle est mentionnée à
proximité de la terminaison. Il n’est pas impératif de la préciser, mais, contrairement à un attribut dont la
multiplicité par défaut est 1, la multiplicité par défaut d’une terminaison d’association est non spécifiée.
L’interprétation de la multiplicité pour une terminaison d’association est moins évidente que pour un attributs (cf.
section 3.3.3).
navigabilité : Pour un attribut, la navigabilité est implicite, navigable, et toujours depuis la classe vers l’attribut. Pour
une terminaison d’association, la navigabilité peut être précisée (cf. section 3.3.4).

Association binaire

Fig. 3.4 – Exemple d’association binaire.

3 Une terminaison d’associations est une extrêmité de l’association. Une association binaire en possède deux, une association n-aire

en possède n

-
40 -
 3.3. RELATIONS ENTRE 41
CLASSES

Une association binaire est matérialisée par un trait plein entre les classes associées (cf. figure 3.4).
Elle peut être ornée d’un nom, avec éventuellement une précision du sens de lecture (► ou ◄).
Quand les deux extrémités de l’association pointent vers la même classe, l’association est dite réflexive.

Association n-aire

Fig. 3.5 – Exemple d’association n-aire.

Une association n-aire lie plus de deux classes. La section 3.3.3 détaille comment interpréter les multiplicités
d’une association n-aire. La ligne pointillé d’une classe-association (cf. section 3.3.6) peut être reliée au losange par
une ligne discontinue pour représenter une association n-aire dotée d’attributs, d’opérations ou d’associations.
On représente une association n-aire par un grand losange avec un chemin partant vers chaque classe participante
(cf. figure 3.5). Le nom de l’association, le cas échéant, apparaît à proximité du losange.

3.3.3 Multiplicité ou cardinalité

La multiplicité associée à une terminaison d’association, d’agrégation ou de composition déclare le nombre
d’objets susceptibles d’occuper la position définie par la terminaison d’association. Voici quelques exemples de
multiplicité :
– exactement un : 1 ou 1..1
– plusieurs : ∗ ou 0..∗
– au moins un : 1..∗
– de un à six : 1..6
Dans une association binaire (cf. figure 3.4), la multiplicité sur la terminaison cible contraint le nombre d’objets de
la classe cible pouvant être associés à un seul objet donné de la classe source (la classe de l’autre terminaison de
l’association).
Dans une association n-aire, la multiplicité apparaissant sur le lien de chaque classe s’applique sur une instance
de chacune des classes, à l’exclusion de la classe-association et de la classe considérée. Par exemple, si on prend une
association ternaire entre les classes (A, B, C), la multiplicité de la terminaison C indique le nombre d’objets C qui
peuvent apparaître dans l’association (définie section 3.3.6) avec une paire particulière d’objets A et B.

Remarque
Il faut noter que, pour les habitués du modèle entité/relation, les multiplicités sont en UML « à l’envers »
(par référence à Merise) pour les associations binaires et « à l’endroit » pour les n-aires avec n > 2.

3.3.4 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 (cf. figure 3.6). Par défaut, une association est navigable dans les deux sens.
Par exemple, sur la figure 3.6, la terminaison du côté de la classe Commande n’est pas navigable : cela signifie
que les instances de la classe Produit ne stockent pas de liste d’objets du type Commande.

-
41 -
3.3. RELATIONS ENTRE 42
CLASSES

Fig. 3.6 – Navigabilité.

Inversement, la terminaison du côté de la classe Produit est navigable : chaque objet commande contient une liste de
produits.

Fig. 3.7 – Implicitement, ces trois notations ont la même sémantique.

Lorsque l’on représente la navigabilité uniquement sur l’une des extrémités d’une association, il faut remarquer
que, implicitement, les trois associations représentées sur la figure 3.7 ont la même signification : l’association ne peut
être traversée que dans un sens.

Fig. 3.8 – Deux modélisations équivalentes.

Dans la section 3.3.2, nous avons dit que :

« Un attribut est une association dégénérée dans laquelle une terminaison d’association est détenue par un
classeur (généralement une classe). Le classeur détenant cette terminaison d’association devrait
théoriquement se trouver à l’autre terminaison, non modélisée, de l’association. Un attribut n’est donc rien
d’autre qu’une terminaison d’un cas particulier d’association. »
La figure 3.8 illustre parfaitement cette situation. Attention toutefois, si vous avez une classe Point dans votre diagramme
de classe, il est extrêmement maladroit de représenter des classes (comme la classe Polygone) avec un ou plusieurs
attributs de type Point. Il faut, dans ce cas, matérialiser cette propriété de la classe en question par une ou plusieurs
associations avec la classe Point.

3.3.5 Qualification
Généralement, une classe peut être décomposée en sous-classes ou posséder plusieurs propriétés. Une telle
classe rassemble un ensemble d’éléments (d’objets). Quand une classe est liée à une autre classe par une association, il
est parfois préférable de restreindre la portée de l’association à quelques éléments ciblés (comme un ou plusieurs
attributs) de la classe. Ces éléments ciblés sont appelés un qualificatif. Un qualificatif permet donc de sélectionner
un ou des objets dans le jeu des objets d’un objet (appelé

-
42 -
3.3. RELATIONS ENTRE 43
CLASSES

Fig. 3.9 – En haut, un diagramme représentant l’association entre une banque et ses clients (à gauche), et un diagramme
représentant l’association entre un échiquier et les cases qui le composent (à droite). En bas, les diagrammes équivalents
utilisant des associations qualifiées.

objet qualifié) relié par une association à un autre objet. L’objet sélectionné par la valeur du qualificatif est appelé
objet cible. L’association est appelé association qualifiée. Un qualificatif agit toujours sur une association dont la
multiplicité est plusieurs (avant que l’association ne soit qualifiée) du côté cible.
Un objet qualifié et une valeur de qualificatif génèrent un objet cible lié unique. En considérant un objet
qualifié, chaque valeur de qualificatif désigne un objet cible unique.
Par exemple, le diagramme de gauche de la figure 3.9 nous dit que :
– Un compte dans une banque appartient à au plus deux personnes. Autrement dit, une instance du couple
{Banque , compte} est en association avec zéro à deux instances de la classe Personne.
– Mais une personne peut posséder plusieurs comptes dans plusieurs banques. C’est-à-dire qu’une
instance de la classe Personne peut être associée à plusieurs (zéro compris) instances du couple
{Banque , compte}.
Le diagramme de droite de cette même figure nous dit que :
– Une instance du triplet {Echiquier, rangée, colonne} est en association avec une instance unique de la
classe Case.
– Inversement, une instance de la classe Case est en association avec une instance unique du triplet
{Echiquier, rangée, colonne}.

3.3.6 Classe-association

Fig. 3.10 – Exemple de classe-association.

Une classe-association possède les propriétés des associations et des classes : elle se connecte à deux ou plusieurs
classes et possède également des attributs et des opérations.

-
43 -
3.3. RELATIONS ENTRE 44
CLASSES

Une classe-association est caractérisée par un trait discontinu entre la classe et l’association qu’elle représente (figure
3.10).
Par exemple, dans la figure 3.10, la détention d’actions est modélisée en tant qu’association entre les classes
Personne et Société. Les attributs de la classe-association Action permettent de préciser les informations relatives à
chaque détention d’actions (nombre d’actions, prix et date d’achat).

3.3.7 Agrégation

Fig. 3.11 – Exemple de relation d’agrégation et de composition.

Une agrégation est une association qui représente une relation d’inclusion structurelle ou compor- tementale
d’un élément dans un ensemble. Graphiquement, on ajoute un losange vide (♦) du côté de l’agrégat (cf. figure
3.11). Contrairement à une association simple, l’agrégation est transitive.

3.3.8 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 (cf. figure 3.11).

3.3.9 Dépendance

Fig. 3.12 – Exemple de relation de 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é (cf. figure 3.12). Elle indique que la modification de la
cible implique une modification de la source. La dépendance est souvent stéréotypée pour mieux expliciter le lien
sémantique entre les éléments du modèle (cf. figure 3.15).

3.4 Interfaces
Nous avons déjà abordé la notion d’interface dans les sections 1.3.4 et 3.2.4. En effet, les classes permettent de définir
en même temps un objet et son interface. Le classeur, que nous décrivons dans cette section, ne permet de définir
que des éléments d’interface. Il peut s’agir de l’interface complète d’un objet, ou simplement d’une partie
d’interface qui sera commune à plusieurs objets.
Le rôle de ce classeur, stéréotypé « interface », est de regrouper un ensemble de propriétés et d’opé- rations assurant
un service cohérent.
Une interface est représentée comme une classe excepté l’absence du mot-clef abstract (car l’interface et toutes ses
méthodes sont, par définition, abstraites) et l’ajout du stéréotype « interface » (cf. figure 3.13). Une interface doit être
réalisée par au moins une classe. Graphiquement, cela est représenté par un trait discontinu terminé par une flèche
triangulaire et le stéréotype « realize ». Une classe (classe cliente de l’interface) peut dépendre d’une interface
(interface requise). On représente cela par une relation de
dépendance et le stéréotype « use ».

-
44 -
 3.5. ÉLABORATION D’UN DIAGRAMME DE 45
CLASSES

Fig. 3.13 – Exemple de diagramme mettant en œuvre une interface

3.5 Élaboration d’un diagramme de classes

Il y a au moins trois points de vue qui guident la modélisation (Steve Cook et John Daniels) :
– Le point de vue spécification met l’accent sur les interfaces des classes plutôt que sur leurs contenus.
– Le point de vue conceptuel capture les concepts du domaine et les liens qui les lient. Il s’intéresse peu
ou prou à la manière éventuelle d’implémenter ces concepts et relations et aux langages
d’implémentation.
– Le point de vue implémentation, le plus courant, détaille le contenu et l’implémentation de chaque classe.
En fonction du point de vue adopté, vous obtiendrez des modèles différents.
Une démarche couramment utilisée pour bâtir un diagramme de classes consiste à :
Trouver les classes du domaine étudié. Cette étape empirique se fait généralement en collaboration avec un
expert du domaine. Les classes correspondent généralement à des concepts ou des sub- stantifs du domaine.
Trouver les associations entre classes. Les associations correspondent souvent à des verbes, ou des constructions
verbales, mettant en relation plusieurs classes, comme « est composé de », « pilote »,
« travaille pour ». Attention, méfiez vous de certains attributs qui sont en réalité des relations entre classes.
Trouver les attributs des classes. Les attributs correspondent souvent à des substantifs, ou des groupes nominaux,
tels que « la masse d’une voiture » ou « le montant d’une transaction ». Les adjectifs et les valeurs
correspondent souvent à des valeurs d’attributs. Vous pouvez ajouter des attributs à toutes les étapes du cycle
de vie d’un projet (implémentation comprise). N’espérez pas trouver tous les attributs dès la construction du
diagramme de classes.
Organiser et simplifier le modèle en éliminant les classes redondantes et en utilisant l’héritage.
Vérifier les chemins d’accès aux classes.
Itérer et raffiner le modèle. Un modèle est rarement correct dès sa première construction. La modélisa- tion objet est
un processus non pas linéaire mais itératif.

3.6 Diagramme d’objets (object diagram)

3.6.1 Présentation
Un diagramme d’objets représente des objets (i.e. instances de classes) et leurs liens (i.e. instances de relations) pour
donner une vue de l’état du système à un instant donné. Un diagramme d’objets permet, selon les situations, d’illustrer
le modèle de classes (en montrant un exemple qui explique le modèle), de préciser certains aspects du système (en
mettant en évidence des détails imperceptibles dans le diagramme de classes), d’exprimer une exception (en modélisant
des cas particuliers, des connaissances non généralisables . . .), ou de prendre une image (snapshot) d’un système à un
moment donné. Le diagramme de classes modélise les règles et le diagramme d’objets modélise des faits.

-
45 -
 Fig. 3.14 – Exemple de diagramme de classes et de diagramme d’objets associé.

Par exemple, le diagramme de classes de la figure 3.14 montre qu’une entreprise emploie au moins deux personnes
et qu’une personne travaille dans au plus deux entreprises. Le diagramme d’objets modélise lui une entreprise particulière
(OSKAD) qui emploie trois personnes.
Un diagramme d’objets ne montre pas l’évolution du système dans le temps. Pour représenter une interaction,
il faut utiliser un diagramme de communication (cf. section 7.2) ou de séquence (cf. section 7.3).

3.6.2 Représentation
Graphiquement, un objet se représente comme une classe. Cependant, le compartiment des opérations n’est pas utile.
De plus, le nom de la classe dont l’objet est une instance est précédé d’un « : » et est souligné. Pour différencier les
objets d’une même classe, leur identifiant peut être ajouté devant le nom de la classe. Enfin les attributs reçoivent
des valeurs. Quand certaines valeurs d’attribut d’un objet ne sont pas renseignées, on dit que l’objet est partiellement
défini.
Dans un diagrammes d’objets, les relations du diagramme de classes deviennent des liens. Graphi- quement, un
lien se représente comme une relation, mais, s’il y a un nom, il est souligné. Naturellement, on ne représente pas les
multiplicités.

3.6.3 Relation de dépendance d’instanciation

Fig. 3.15 – Dépendance d’instanciation entre les classeurs et leurs instances.

La relation de dépendance d’instanciation (stéréotypée « instanceof ») décrit la relation entre un classeur et ses
instances. Elle relie, en particulier, les liens aux associations et les objets aux classes.

-
46 -
Chapitre 5

Diagramme d’états-transitions
(State machine diagram)

5.1 Introduction au formalisme

5.1.1 Présentation
Les diagrammes d’états-transitions 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.
Le diagramme d’états-transitions est le seul diagramme, de la norme UML, à offrir une vision complète et
non ambiguë de l’ensemble des comportements de l’élément auquel il est attaché. En effet, un diagramme d’interaction
n’offre qu’une vue partielle correspondant à un scénario sans spécifier comment les différents scénarii interagissent entre
eux.
La vision globale du système n’apparaît pas sur ce type de diagramme puisqu’ils ne s’intéressent qu’à un seul
élément du système indépendamment de son environnement.
Concrètement, 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.

5.1.2 Notion et exemple d’automate à états finis

Comme nous venons de le dire, un automate à états finis est un automate 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 globale.
Un état global est un jeu de valeurs d’objet, pour une classe donnée, produisant la même réponse face aux
événements. Toutes les instances d’une même classe ayant le même état global réagissent de la même manière à un
événement.
Un automate à états finis est graphiquement représenté par un graphe comportant des états, maté- rialisés par des
rectangles aux coins arrondis, et des transitions, matérialisées par des arcs orientés liant les états entre eux.
La figure 5.1 montre un exemple simple d’automate à états finis. Cet automate possède deux états (Allumé et Eteint)
et deux transitions correspondant au même évènement : la pression sur un bouton d’éclairrage domestique. Cet automate
à états finis illustre en fait le fonctionnement d’un télérupteur dans une maison. Lorsque l’on appuie sur un
bouton d’éclairrage, la réaction de l’éclairage associé

67

-
47 -
 Fig. 5.1 – Un diagramme d’états-transitions simple.

dépendra de son état courant (de son historique) : s’il la lumière est allumée, elle s’éteindra, si elle est éteinte, elle
s’allumera.

Remarque
Nous avons employé dans cette section le terme d’état global, qui désigne une situation particulière dans laquelle
se trouve l’ensemble de l’automate à états finis, par opposition au simple terme d’état, qui désigne l’un des états
élémentaire d’un automate à états finis, pour lever toute ambiguïté sur la notion d’état. Dans le cas d’un diagramme
d’états-transitions simple, ces deux notions se rejoignent puisqu’un tel diagramme ne comporte toujours qu’un état
actif à la fois, mais si le diagramme d’états-transitions comporte des états concurrents (cf. section 5.6.5), plusieurs
états peuvent être actifs en même temps, l’état global étant alors caractérisé par l’ensemble des états actifs. La section
5.2.1 donne plus d’information sur cette ambiguïté du terme état.

5.1.3 Diagrammes d’états-transitions

Un diagramme d’états-transitions rassemble et organise les états et les transitions d’un classeur donné. Bien entendu,
le modèle dynamique du système comprend plusieurs diagrammes d’états-transitions. Il est souhaitable de construire
un diagramme d’états-transitions pour chaque classeur (qui, le plus souvent, est une classe) possédant un comportement
dynamique important. Un diagramme d’états- transitions ne peut être associé qu’à un seul classeur. Tous les automates
à états finis des diagrammes d’états-transitions d’un système s’exécutent concurremment et peuvent donc changer d’état
de façon indépendante.

5.2 État
5.2.1 Les deux acceptions du terme état
État dans un diagrammes d’états-transitions

Fig. 5.2 – Exemple d’état simple.

Comme nous l’avons déjà dit, un état, que l’on peut qualifier informellement d’élémentaire, se re- présente
graphiquement dans un diagrammes d’états-transitions par un rectangles aux coins arrondis (figure 5.2).
Certains états, dits composites (cf. section 5.6), peuvent contenir (i.e. envelopper) des sous-états.

-
68 -
 5.3. ÉVÉNEMENT 69

Le nom de l’état peut être spécifié dans le rectangles et doit être unique dans le diagrammes d’états- transitions,
ou dans l’état enveloppant. On peut l’omettre, ce qui produit un état anonyme. Il peut y avoir un nombre quelconque
d’états anonymes distincts. Un état imbriqué peut être identifié par son nom qualifié (cf. section 2.4.5) si tous les
états enveloppant ont des noms.
Un état peut être partitionné en plusieurs compartiments séparés par une ligne horizontale. Le premier compartiment
contient le nom de l’état et les autres peuvent recevoir des transitions interne (cf. section 5.4.6), ou des sous-états (cf.
section 5.6), quand il s’agit d’un état composite. Dans le cas d’un état simple (i.e. sans transitions interne ou sous-état),
on peut omettre toute barre de séparation (figure 5.2).

État d’un objet, ou du diagrammes d’états-transitions (i.e. état global)

Un objet peut passer par une série d’états pendant sa durée de vie. Un état représente une période dans la vie d’un
objet pendant laquelle ce dernier attend un événement ou accomplit une activité. La configuration de l’état actif de l’objet
est le jeu des états (élémentaires) qui sont actifs à un instant donné. Si cette configuration contient plusieurs états, il y a
concurrence au sein de l’objet. Le nombre d’états (élémentaires) actifs peut changer pendant la durée de vie d’un objet
du fait d’embranchements ou de jointures appelées transitions concurrentes (cf. section 5.6.5).

5.2.2 État initial et final

État initial

Fig. 5.3 – Représentation graphique de l’état initial.

L’état initial est un pseudo état qui indique l’état de départ, par défaut, lorsque le diagramme d’états- transitions, ou
l’état enveloppant, est invoqué. Lorsqu’un objet est créé, il entre dans l’état initial.

État final

Fig. 5.4 – Représentation graphique de l’état final.

L’état final est un pseudo état qui indique que le diagramme d’états-transitions, ou l’état enveloppant, est terminé.

5.3 Événement
5.3.1 Notion d’évènement
Un événement est quelque chose qui se produit pendant l’exécution d’un système et qui mérite d’être modélisé. Les
diagrammes d’états-transitions permettent justement de spécifier les réactions d’une partie du système à des événements
discrets. Un événement se produit à un instant précis et est dépourvu de durée. Quand un événement est reçu, une
transition peut être déclenchée et faire basculer l’objet dans un nouvel état. On peut diviser les événements en plusieurs
types explicites et implicites : signal, appel, changement et temporel.

-
69 -
5.3.2 Événement de type signal (signal)

Fig. 5.5 – Déclaration de signaux et héritage.

Un signal est un type de classeur destiné explicitement à véhiculer une communication asynchrone à sens unique
entre deux objets. L’objet expéditeur crée et initialise explicitement une instance de signal et l’envoi à un objet explicite
ou à tout un groupe d’objets. Il n’attend pas que le destinataire traite le signal pour poursuivre son déroulement. La
réception d’un signal est un événement pour l’objet destinataire. Un même objet peut être à la fois expéditeur et
destinataire.
Les signaux sont déclarés par la définition d’un classeur portant le stéréotype « signal » ne fournissant pas d’opération
et dont les attributs sont interprétés comme des arguments (cf. figure 5.5). La syntaxe d’un signal est la suivante :

<nom_événement> ( [ <paramettre> : <type> [; <paramettre> : <type> ... ] ] )

Les signaux supporte la relation de généralisation (cf. figure 5.5). Les signaux héritent des attri- buts de leurs
parents (héritage) et ils déclenchent des transitions contenant le type du signal parent (polymorphisme).

5.3.3 Événement d’appel (call)

Un événement d’appel représente la réception de l’appel d’une opération par un objet. Les paramètres de l’opération
sont ceux de l’événement d’appel. La syntaxe d’un événement d’appel est la même que celle d’un signal. Par contre,
les événements d’appel sont des méthodes déclarées au niveau du diagramme de classes.

5.3.4 Événement de changement (change)

Un événement de changement est généré par la satisfaction (i.e. passage de faux à vrai) d’une expression
booléenne sur des valeurs d’attributs. Il s’agit d’une manière déclarative d’attendre qu’une condition soit satisfaite.
La syntaxe d’un événement de changement est la suivante :

when ( <condition_booléenne> )

Notez la différence entre une condition de garde (cf. section 5.4.2) et un événement de changement. La première est
évaluée une fois que l’événement déclencheur de la transition a lieu et que le destinataire le traite. Si elle est fausse, la
transition ne se déclenche pas et la condition n’est pas réévaluée. Un événement de changement est évalué
continuellement jusqu’à ce qu’il devienne vrai, et c’est à ce moment-là que la transition se déclenche.

-
70 -
5.4. TRANSITION 71

5.3.5 Événement temporel (after ou when)

Les événements temporels sont générés par le passage du temps. Ils sont spécifiés soit de manière absolue (date
précise), soit de manière relative (temps écoulé). Par défaut, le temps commence à s’écouler dès l’entrée dans l’état
courant.
La syntaxe d’un événement temporel spécifié de manière relative est la suivante :

after ( <durée> )

Un événement temporel spécifié de manière absolue est défini en utilisant un événement de change- ment :

when ( date = <date> )

5.4 Transition
5.4.1 Définition et syntaxe
Une transition définit la réponse d’un objet à l’occurrence d’un événement. Elle lie, généralement, deux états E1 et
E2 et indique qu’un objet dans un état E1 peut entrer dans l’état E2 et exécuter certaines activités, si un événement
déclencheur se produit et que la condition de garde est vérifiée.
La syntaxe d’une transition est la suivante :

[ <événement> ][ ’[’ <garde> ’]’ ] [ ’/’ <activité> ]

La syntaxe de <événement> a été définie dans la section 5.3

Le même événement peut être le déclencheur de plusieurs transitions quittant un même état. Chaque transition avec
le même événement doit avoir une condition de garde différente. En effet, une seule tran- sition peut se déclencher dans
un même flot d’exécution. Si deux transitions sont activées en même temps par un même événement, une seule se
déclenche et le choix n’est pas prévisible (i.e. pas déterministe).

5.4.2 Condition de garde

Une transition peut avoir une condition de garde (spécifiée par ’[’ <garde> ’]’ dans la syntaxe). Il s’agit
d’une expression logique sur les attributs de l’objet, associé au diagramme d’états-transitions, ainsi que sur les
paramètres de l’événement déclencheur. La condition de garde est évaluée uniquement lorsque l’événement déclencheur
se produit. Si l’expression est fausse à ce moment là, la transition ne se déclenche pas, si elle est vraie, la transition se
déclenche et ses effets se produisent.

5.4.3 Effet d’une transition

Lorsqu’une transition se déclenche (on parle également de tir d’une transition), son effet (spécifié par
’/’ <activité> dans la syntaxe) s’exécute. Il s’agit généralement d’une activité qui peut être
– une opération primitive comme une instruction d’assignation ;
– l’envoi d’un signal ;
– l’appel d’une opération ;
– une liste d’activités, etc.
La façon de spécifier l’activité à réaliser est laissée libre (langage naturel ou pseudo-code).
Lorsque l’exécution de l’effet est terminée, l’état cible de la transition devient actif.

5.4.4 Transition externe

Une transition externe est une transition qui modifie l’état actif. Il s’agit du type de transition le plus répandu. Elle
est représentée par une flèche allant de l’état source vers l’état cible.
La figure 5.6 illustre la représentation graphique d’une transition externe entre deux états.

-
71 -
 Fig. 5.6 – Représentation graphique d’une transition externe entre deux états.

5.4.5 Transition d’achèvement

Une transition dépourvue d’événement déclencheur explicite se déclenche à la fin de l’activité conte- nue dans l’état
source (y compris les état imbriqués). Elle peut contenir une condition de garde qui est évaluée au moment où l’activité
contenue dans l’état s’achève, et non pas ensuite.
Les transitions de garde sont, par exemple, utilisées pour connecter les états initiaux et les états historiques (cf.
section 5.6.3) avec leur état successeurs puisque ces pseudo-états ne peuvent rester actifs.

5.4.6 Transition interne

Fig. 5.7 – Représentation de la saisie d’un mot de passe dans un état unique en utilisant des transitions internes.

Les règles de déclenchement d’une transition interne sont les mêmes que pour une transition externe excepté qu’une
transition interne ne possède pas d’état cible et que l’état actif reste le même à la suite de son déclenchement. La
syntaxe d’une transition interne reste la même que celle d’une transition classique (cf. section 5.4.1). Par contre, les
transitions internes ne sont pas représentées par des arcs mais sont spécifiées dans un compartiment de leur état associé
(cf. figure 5.7).
Les transitions internes possèdent des noms d’événement prédéfinis correspondant à des déclen- cheurs particuliers
: entry, exit, do et include. Ces mots clefs réservés viennent prendre la place du nom de l’événement dans la syntaxe
d’une transition interne.
entry – entry permet de spécifier une activité qui s’accomplit quand on entre dans l’état.
exit – exit permet de spécifier une activité qui s’accomplit quand on sort de l’état.
do – Une activité do commence dès que l’activité entry est terminée. Lorsque cette activité est terminée, une transition
d’achèvement peut être déclenchée, après l’exécution de l’activité exit bien entendu. Si une transition se
déclenche pendant que l’activité do est en cours, cette dernière est interrompue et l’activité exit de l’état s’exécute.
include – permet d’invoquer un sous-diagramme d’états-transitions.
Les activités entry servent souvent à effectuer la configuration nécessaire dans un état. Comme il n’est pas
possible de l’éluder, toute action interne à l’état peut supposer que la configuration est effectuée
indépendamment de la manière dont on entre dans l’état. De manière analogue, une activité exit est une
occasion de procéder à un nettoyage. Cela peut s’avérer particulièrement utile lorsqu’il existe des transitions de
haut niveau qui représentent des conditions d’erreur qui abandonnent les états imbriqués.
Le déclenchement d’une transition interne ne modifie pas l’état actif et n’entraîne donc pas l’activation des activités
entry et exit.

-
72 -
5.5. POINT DE CHOIX 73

5.5 Point de choix

Il est possible de représenter des alternatives pour le franchissement d’une transition. On utilise pour cela des pseudo-
états particuliers : les points de jonction (représentés par un petit cercle plein) et les points de décision (représenté par
un losange).

5.5.1 Point de jonction

Les points de jonction sont un artefact graphique (un pseudo-état en l’occurrence) qui permet de partager des
segments de transition, l’objectif étant d’aboutir à une notation plus compacte ou plus lisible des chemins alternatifs.
Un point de jonction peut avoir plusieurs segments de transition entrante et plusieurs segments de transition
sortante. Par contre, il ne peut avoir d’activité interne ni des transitions sortantes dotées de déclencheurs
d’événements.
Il ne s’agit pas d’un état qui peut être actif au cours d’un laps de temps fini. Lorsqu’un chemin passant par
un point de jonction est emprunté (donc lorsque la transition associée est déclenchée) toutes les gardes le long de ce
chemin doivent s’évaluer à vrai dès le franchissement du premier segment.
La figure 5.8 illustre bien l’utilité des points de jonction.
La figure 5.9 illustre l’utilisation de points de jonction pour représenter le branchement d’une clause conditionnelle.

5.5.2 Point de décision

Un point de décision possède une entrée et au moins deux sorties. Contrairement à un point de jonction, les gardes
situées après le point de décision sont évaluées au moment où il est atteint. Cela permet de baser le choix sur des résultats
obtenus en franchissant le segment avant le point de choix (cf. figure 5.10). Si, quand le point de décision est atteint,
aucun segment en aval n’est franchissable, c’est que le modèle est mal formé.
Il est possible d’utiliser une garde particulière, notée [else], sur un des segments en aval d’un point de
choix. Ce segment n’est franchissable que si les gardes des autres segments sont toutes fausses. L’utilisation d’une clause
[else] est recommandée après un point de décision car elle garantit un modèle bien formé.

5.6 États composites

5.6.1 Présentation
Un état simple ne possède pas de sous-structure mais uniquement, le cas échéant, un jeu de transitions internes. Un
état composite est un état décomposé en régions contenant chacune un ou plusieurs sous- états.
Quand un état composite comporte plus d’une région, il est qualifié d’état orthogonal. Lorsqu’un état orthogonal est
actif, un sous-état direct de chaque région est simultanément actif, il y a donc concurrence (cf. section 5.6.5). Un état
composite ne comportant qu’une région est qualifié d’état non orthogonal.
Implicitement, tout diagramme d’états-transitions est contenu dans un état externe qui n’est usuel- lement pas
représenté. Cela apporte une plus grande homogénéité dans la description : tout diagramme d’états-transitions est
implicitement un état composite.
L’utilisation d’états composites permet de développer une spécification par raffinements. Il n’est pas nécessaire de
représenter les sous-états à chaque utilisation de l’état englobant. Une notation abrégée (figure 5.12) permet d’indiquer
qu’un état est composite et que sa définition est donnée sur un autre diagramme.
La figure figure 5.11 montre un exemple d’état composite et la figure 5.12 montre sa notation abrégée.

-
73 -
5.6. ÉTATS 74
COMPOSITES

Fig. 5.8 – En haut, un diagramme sans point de jonction. En bas, son équivalent utilisant un point de jonction.

Fig. 5.9 – Exemple d’utilisation de deux points de jonction pour représenter une alternative.

Fig. 5.10 – Exemple d’utilisation d’un point de décision.

-
74 -
5.6. ÉTATS 75
COMPOSITES

Fig. 5.11 – Exemple d’état composite modélisant la composition d’un numéro de téléphone.

Fig. 5.12 – Notation abrégée d’un état composite.

5.6.2 Transition

Les transitions peuvent avoir pour cible la frontière d’un état composite et sont équivalentes à une transition ayant
pour cible l’état initial de l’état composite.
Une transition ayant pour source la frontière d’un état composite est équivalente à une transition qui s’applique
à tout sous-état de l’état composite source. Cette relation est transitive : la transition est franchissable depuis tout état
imbriqué, quelle que soit sa profondeur.
Par contre, si la transition ayant pour source la frontière d’un état composite ne porte pas de déclen- cheur explicite
(i.e. s’il s’agit d’une transition d’achèvement), elle est franchissable quand l’état final de l’état composite est atteint.
Les transitions peuvent également toucher des états de différents niveaux d’imbrication en traversant les frontières
des états composites.

Fig. 5.13 – Exemple de configuration complexe de transition. Depuis l’état État 1, la réception de l’événement
event1 produit la séquence d’activités QuitterE11, QuitterE1, action1, EntrerE2, EntrerE21, initialiser(),
EntrerE22, et place le système dans l’état État22.

La figure 5.13 illustre une configuration complexe de transition produisant une cascade d’activités.

-
75 -
5.6. ÉTATS 76
COMPOSITES

Fig. 5.14 – Exemple de diagramme possédant un état historique profond permettant de reprendre le programme de
lavage ou de séchage d’une voiture à l’endroit où il était arrivé avant d’être interrompu.

5.6.3 État historique

Un état historique, également qualifié d’état historique plat, est un pseudo-état qui mémorise le dernier sous-état
actif d’un état composite. Graphiquement, il est représenté par un cercle contenant un H.
Une transition ayant pour cible l’état historique est équivalente à une transition qui a pour cible le dernier état visité
de l’état englobant. Un état historique peut avoir une transition sortante non étiquetée indiquant l’état à exécuter si la
région n’a pas encore été visitée.
Il est également possible de définir un état historique profond représenté graphiquement par un cercle contenant un
H*. Cet état historique profond permet d’atteindre le dernier état visité dans la région, quel que soit sont niveau
d’imbrication, alors que le l’état historique plat limite l’accès aux états de son niveau d’imbrication.
La figure 5.14 montre un diagramme d’états-transitions modélisant le lavage automatique d’une voiture. Les
états de lavage, séchage et lustrage sont des états composites définis sur trois autres diagrammes d’états-transitions non
représentés ici. En phase de lavage ou de séchage, le client peut appuyer sur le bouton d’arrêt d’urgence. S’il appuie
sur ce bouton, la machine se met en attente. Il a alors deux minutes pour reprendre le lavage ou le lustrage, exactement
où le programme à été interrompue, c’est à dire au niveau du dernier sous-état actif des états de lavage ou de lustrage
(état historique profond). Si l’état avait été un état historique plat, c’est toute la séquence de lavage ou de lustrage qui
aurait recommencée. En phase de lustrage, le client peut aussi interrompre la machine. Mais dans ce cas, la machine
s’arrêtera définitivement.

5.6.4 Interface : les points de connexion

Comme nous l’avons déjà dit, il est possible de masquer les sous-états d’un état composite et de les définir dans
un autre diagramme. Cette pratique nécessite parfois l’utilisation de pseudo-états appelés points de connexion.
Lorsque l’on utilise le comportement par défaut de l’état composite, c’est-à-dire entrer par l’état initial par défaut et
considérer les traitements finis quand l’état final est atteint, aucun problème ne se pose car on utilise des transitions
ayant pour cible, ou pour source, la frontière de l’état composite. Dans ce cas,

-
76 -
5.6. ÉTATS 77
COMPOSITES

Fig. 5.15 – Exemple d’utilisation de points de connexion.

les points de connexion sont inutiles.

Le problème se pose lorsqu’il est possible d’entrer ou de sortir d’un état composite de plusieurs façons. C’est, par
exemple, le cas lorsqu’il existe des transitions traversant la frontière de l’état composite et visant directement, ou ayant
pour source, un sous-état de l’état composite. Dans ce cas, la solution est d’utiliser des points de connexion sur la frontière
de l’état composite.
Les points de connexion sont des points d’entrée et de sortie portant un nom, et situés sur la frontière d’un état
composite. Ils sont respectivement représentés par un cercle vide et un cercle barré d’une croix (cf. figure 5.15).
Il ne s’agit que de références à un état défini dans l’état composite . Une unique transition d’achèvement, dépourvue de
garde, relie le pseudo-état source (i.e. le point de connexion) à l’état référencé. Cette transition d’achèvement n’est que
le prolongement de la transition qui vise le point de connexion (il peut d’ailleurs y en avoir plusieurs).
Les points de connexions offrent ainsi une façon de représenter l’interface (au sens objet) d’un état composite en
masquant l’implémentation de son comportement.
On peut considérer que les pseudo-états initiaux et finaux sont des points de connexion sans nom.

5.6.5 Concurrence

Fig. 5.16 – Exemple d’utilisation d’un état composite orthogonal.

-
77 -
 Les diagrammes d’états-transitions permettent de décrire efficacement les mécanismes concurrents grâce à
l’utilisation d’états orthogonaux. Un état orthogonal est un état composite comportant plus d’une région, chaque
région représentant un flot d’exécution. Graphiquement, dans un état orthogonal, les différentes régions sont séparées
par un trait horizontal en pointillé allant du bord gauche au bord droit de l’état composite.
Chaque région peut posséder un état initial et final. Une transition qui atteint la bordure d’un état composite
orthogonal est équivalente à une transition qui atteint les états initiaux de toutes ses régions concurrentes.
Toutes les régions concurrentes d’un état composite orthogonal doivent atteindre leur état final pour que l’état
composite soit considéré comme terminé.
La figure 5.16 illustre l’utilisation d’un état composite orthogonal pour modéliser le fait que la préparation de
la boisson d’un distributeur de boisson se fait en parallèle au rendu de la monaie.

Fig. 5.17 – Exemple d’utilisation de transitions complexes.

Il est également possible de représenter ce type de comportement au moyen de transitions concur- rentes. De telles
transitions sont qualifiées de complexes. Les transitions complexes sont représentées par une barre épaisse et peuvent,
éventuellement, être nommées. La figure 5.17 montre la mise en œuvre de ce type de transition. Sur ce diagramme,
l’état orthogonal préparer boisson et rendre monnaie peut éventuellement ne pas apparaître (tout en gardant la
représentation de ses sous-états) pour alléger la représentation, car la notion de concurrence est clairement apparente de
par l’utilisation des transitions complexes.

-
78 -
Chapitre 6

Diagramme d’activités
(Activity diagram)

6.1 Introduction au formalisme

6.1.1 Introduction
Les diagrammes d’activités permettent de mettre l’accent sur les traitements. Ils sont donc parti- culièrement
adaptés à la modélisation du cheminement de flots de contrôle et de flots de données. Ils permettent ainsi de
représenter graphiquement le comportement d’une méthode ou le déroulement d’un cas d’utilisation.
Les diagrammes d’activités sont relativement proches des diagrammes d’états-transitions dans leur présentation,
mais leur interprétation est sensiblement différente. Les diagrammes d’états-transitions sont orientés vers des systèmes
réactifs, mais ils ne donnent pas une vision satisfaisante d’un traitement faisant intervenir plusieurs classeurs et doivent
être complétés, par exemple, par des diagrammes de séquence. Au contraire, les diagrammes d’activités ne sont pas
spécifiquement rattachés à un classeur particulier. Ils permettent de spécifier des traitements a priori séquentiels et offrent
une vision très proche de celle des langages de programmation impératifs comme C++ ou Java.
Dans la phase de conception, les diagrammes d’activités sont particulièrement adaptés à la description des cas
d’utilisation. Plus précisément, ils viennent illustrer et consolider la description textuelle des cas d’utilisation (cf.
section 2.5.3). De plus, leur représentation sous forme d’organigrammes les rend facilement intelligibles et beaucoup
plus accessibles que les diagrammes d’états-transitions.
Les diagrammes d’activités sont également utiles dans la phase de réalisation car ils permettent une description si
précise des traitements qu’elle autorise la génération automatique du code.

6.1.2 Action (action)

Une action est le plus petit traitement qui puisse être exprimé en UML. Une action a une incidence sur l’état
du système ou en extrait une information. Les actions sont des étapes discrètes à partir des- quelles se construisent les
comportements. La notion d’action est à rapprocher de la notion d’instruction élémentaire d’un langage de
programmation (comme C++ ou Java). Une action peut être, par exemple :
– une affectation de valeur à des attributs ;
– un accès à la valeur d’une propriété structurelle (attribut ou terminaison d’association) ;
– la création d’un nouvel objet ou lien ;
– un calcul arithmétique simple ;
– l’émission d’un signal ;
– la réception d’un signal ;
– ...
Nous décrivons ci-dessous les types d’actions les plus courants prédéfinis dans la notation UML.

79

-
79 -
6.1. INTRODUCTION AU 81
FORMALISME

Action appeler (call operation) – L’action call operation correspond à l’invocation d’une opération sur un objet
de manière synchrone ou asynchrone. Lorsque l’action est exécutée, les paramètres sont transmis à l’objet cible.
Si l’appel est asynchrone, l’action est terminée et les éventuelles valeurs de retour seront ignorées. Si l’appel
est synchrone, l’appelant est bloqué pendant l’exécution de l’opération et, le cas échéant, les valeurs de retour
pourront être réceptionnées.
Action comportement (call behavior) – L’action call behavior est une variante de l’action call operation
car elle invoque directement une activité plutôt qu’une opération.
Action envoyer (send) – Cette action crée un message et le transmet à un objet cible, où elle peut dé- clencher un
comportement. Il s’agit d’un appel asynchrone (i.e. qui ne bloque pas l’objet appelant) bien adapté à l’envoi de
signaux (send signal).
Action accepter événement (accept event) – L’exécution de cette action bloque l’exécution en cours jus- qu’à la
réception du type d’événement spécifié, qui généralement est un signal. Cette action est utilisée pour la réception
de signaux asynchrones.
Action accepter appel (accept call) – Il s’agit d’une variante de l’action accept event pour les appels synchrones.
Action répondre (reply) – Cette action permet de transmettre un message en réponse à la réception d’une action
de type accept call.
Action créer (create) – Cette action permet d’instancier un objet.
Action détruire (destroy) – Cette action permet de détruire un objet.
Action lever exception (raise exception) – Cette action permet de lever explicitement une exception.
Graphiquement, les actions apparaissent dans des nœuds d’action, décrits section 6.2.1.

6.1.3 Activité (activity)

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 (transitions). Le flot de contrôle reste dans
l’activité jusqu’à ce que les traitements soient terminés.
Une activité est un comportement (behavior en anglais) et à ce titre peut être associée à des paramètres.

6.1.4 Groupe d’activités (activity group)

Un groupe d’activités est une activité regroupant des nœuds et des arcs. Les nœuds et les arcs peuvent appartenir à
plus d’un groupe. Un diagramme d’activités est lui-même un groupe d’activités (cf. figure 6.2).

6.1.5 Nœud d’activité (activity node)

Fig. 6.1 – Représentation graphique des nœuds d’activité. De la gauche vers la droite, on trouve : le nœud
représentant une action, qui est une variété de nœud exécutable, un nœud objet, un nœud de décision ou de fusion, un
nœud de bifurcation ou d’union, un nœud initial, un nœud final et un nœud final de flot.

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 (executable node en anglais) ;
– les nœuds objets (object node en anglais) ;

-
80 -
6.1. INTRODUCTION AU 81
FORMALISME

Fig. 6.2 – Exemple de diagramme d’activités modélisant le fonctionnement d’une borne bancaire.

-
81 -
6.1. INTRODUCTION AU 81
FORMALISME

– et les nœuds de contrôle (control nodes en anglais).

La figure 6.1 représente les différents types de nœuds d’activité. La figure 6.2 montre comment certains de ces
nœuds sont utilisés pour former un diagramme d’activités.

6.1.6 Transition

Fig. 6.3 – Représentation graphique d’une transition.

Le passage d’une activité vers une autre est matérialisé par une transition. Graphiquement les transi- tions sont
représentées par des flèches en traits pleins qui connectent les activités entre elles (figure 6.3). Elles sont déclenchées
dès que l’activité source est terminée et provoquent automatiquement et immé- diatement le début de la prochaine
activité à déclencher (l’activité cible). Contrairement aux activités, les transitions sont franchies de manière atomique,
en principe sans durée perceptible.
Les transitions spécifient l’enchaînement des traitements et définissent le flot de contrôle.

6.2 Nœud exécutable (executable node)

Un nœud exécutable est un nœud d’activité qu’on peut exécuter (i.e. une activité). Il possède un gestionnaire
d’exception qui peut capturer les exceptions levées par le nœud, ou un de ses nœuds imbriqués.

6.2.1 Nœud d’action

Fig. 6.4 – Représentation graphique d’un nœud d’action.

Un nœud d’action est un nœud d’activité exécutable qui constitue l’unité fondamentale de fonction- nalité exécutable
dans une activité. L’exécution d’une action représente une transformation ou un calcul quelconque dans le système
modélisé. Les actions sont généralement liées à des opérations qui sont directement invoquées. Un nœud d’action doit
avoir au moins un arc entrant.
Graphiquement, un nœud d’action est représenté par un rectangle aux coins arrondis (figure 6.4) qui contient
sa description textuelle. Cette description textuelle peut aller d’un simple nom à une suite d’actions réalisées par
l’activité. UML n’impose aucune syntaxe pour cette description textuelle, on peut donc utiliser une syntaxe proche de
celle d’un langage de programmation particulier ou du pseudo-code.
Certaines actions de communication ont une notation spéciale (cf. figure 6.5).

6.2.2 Nœud d’activité structurée (structured activity node)

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.
Les transitions d’une activité structurée doivent avoir leurs nœuds source et cible dans le même nœud
d’activité structurée. Les nœuds et les arcs contenus par nœud d’activité structuré ne peuvent pas être contenus dans un
autre nœud d’activité structuré.

-
82 -
6.3. NŒUD DE 83
CONTRÔLE

Fig. 6.5 – Représentation particulière des nœuds d’action de communication.

Un nœud structuré est dénoté par le stéréotype « structured » et identifié par un nom unique décrivant le
comportement modélisé dans l’activité structurée.
Graphiquement, le contour d’un nœud d’activité structurée est en pointillé. Une ligne horizontale en trait
continu sépare le compartiment contenant le stéréotype « structured » et le nom de l’activité structurée du corps de
l’activité structurée.

6.3 Nœud de contrôle (control node)

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 (initial node en anglais) ;
– nœud de fin d’activité (final node en anglais)
– nœud de fin de flot (flow final en anglais) ;
– nœud de décision (decision node en anglais) ;
– nœud de fusion (merge node en anglais) ;
– nœud de bifurcation (fork node en anglais) ;
– nœud d’union (join node en anglais).
La figure 6.6 illustre l’utilisation de ces nœuds de contrôle.

6.3.1 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 (cf. figure 6.6).

-
83 -
6.3. NŒUD DE 84
CONTRÔLE

Fig. 6.6 – Exemple de diagramme d’activité illustrant l’utilisation de nœuds de contrôle. Ce diagramme décrit la
prise en compte d’une commande.

-
84 -
 6.3. NŒUD DE 85
CONTRÔLE

6.3.2 Nœud final

Un nœud final est un nœud de contrôle possédant un ou plusieurs arcs entrants et aucun arc sortant.

Nœud de fin d’activité

Lorsque l’un des arcs d’un nœud de fin d’activité est activé (i.e. lorsqu’un flot d’exécution atteint un nœud de
fin d’activité), l’exécution de l’activité enveloppante s’achève et tout nœud ou flot actif au sein de l’activité
enveloppante est abandonné. Si l’activité a été invoquée par un appel synchrone, un message (reply) contenant les
valeurs sortantes est transmis en retour à l’appelant.
Graphiquement, un nœud de fin d’activité est représenté par un cercle vide contenant un petit cercle plein (cf. figure
6.6).

Nœud de fin de flot

Lorsqu’un flot d’exécution atteint un nœud de fin de flot, le flot en question est terminé, mais cette fin de flot
n’a aucune incidence sur les autres flots actifs de l’activité enveloppante.
Graphiquement, un nœud de fin de flot est représenté par un cercle vide barré d’un X.
Les nœuds de fin de flot sont particuliers et à utiliser avec parcimonie. Dans l’exemple de la figure 6.6, le nœud
de fin de flot n’est pas indispensable : on peut le remplacer par un nœud d’union possédant une transition vers un nœud
de fin d’activité.

6.3.3 Nœud de décision et de fusion

Nœud de décision (decision node)

Un nœud de décision est un nœud de contrôle qui permet de faire un choix entre plusieurs flots sortants. Il possède
un arc entrant et plusieurs arcs sortants. Ces derniers sont généralement accompagnés de conditions de garde pour
conditionner le choix. Si, quand le nœud de décision est atteint, aucun arc en aval n’est franchissable (i.e. aucune
condition de garde n’est vraie), c’est que le modèle est mal formé. L’utilisation d’une garde [else] est recommandée
après un nœud de décision car elle garantit un modèle bien formé. En effet, la condition de garde [else] est validée si
et seulement si toutes les autres gardes des transitions ayant la même source sont fausses. Dans le cas où plusieurs arcs
sont franchissables (i.e. plusieurs conditions de garde sont vraies), seul l’un d’entre eux est retenu et ce choix est non
déterministe.
Graphiquement, on représente un nœud de décision par un losange (cf. figure 6.6).

Nœud de fusion (merge node)

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, on représente un nœud de fusion, comme un nœud de décision, par un losange (cf. figure 6.6).

Remarque
Graphiquement, il est possible de fusionner un nœud de fusion et un nœud de décision, et donc d’avoir un
losange possédant plusieurs arcs entrants et sortants. Il est également possible de fusionner un nœud de décision ou
de fusion avec un autre nœud, comme un nœud de fin de flot sur la figure 6.6, ou avec une activité. Cependant,
pour mieux mettre en évidence un branchement conditionnel, il est préférable d’utiliser un nœud de décision
(losange).

-
85 -
 6.3. NŒUD DE 86
CONTRÔLE

6.3.4 Nœud de bifurcation et d’union

Nœud de bifurcation ou de débranchement (fork node)
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. Un tel nœud possède donc un arc entrant et plusieurs arcs sortants. On apparie généralement
un nœud de bifurcation avec un nœud d’union pour équilibrer la concurrence (cf. figure 6.2).
Graphiquement, on représente un nœud de bifurcation par un trait plein (cf. figure 6.6).

Nœud d’union ou de jointure (join node)

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 de union, comme un nœud de bifurcation, par un trait plein (cf. figure
6.2).

Remarque
Graphiquement, il est possible de fusionner un nœud de bifurcation et un nœud d’union, et donc d’avoir un trait
plein possédant plusieurs arcs entrants et sortants (cf. figure 6.6).

6.4 Nœud d’objet (object node)

6.4.1 Introduction
Jusqu’ici, nous avons montré comment modéliser le comportement du flot de contrôle dans un diagramme
d’activités. Or, les flots de données n’apparaissent pas et sont pourtant un élément essentiel des traitements (arguments
des opérations, valeurs de retour, . . .).
Justement, un nœud d’objet permet de définir un flot d’objet (i.e. un flot de données) dans un diagramme
d’activités. Ce nœud représente l’existence d’un objet généré par une action dans une activité et utilisé par d’autres
actions.

6.4.2 Pin d’entrée ou de sortie

Fig. 6.7 – Représentation des pins d’entrée et de sortie sur une activité.

Pour spécifier les valeurs passées en argument à une activité et les valeurs de retour, on utilise des nœuds d’objets
appelés pins (pin en anglais) d’entrée ou de sortie. L’activité ne peut débuter que si l’on affecte une valeur à chacun de
ses pins d’entrée. Quand l’activité se termine, une valeur doit être affectée à chacun de ses pins de sortie.
Les valeurs sont passées par copie : une modification des valeurs d’entrée au cours du traitement de l’action n’est
visible qu’à l’intérieur de l’activité.
Graphiquement, un pin est représenté par un petit carré attaché à la bordure d’une activité (cf. figure 6.7). Il est typé
et éventuellement nommé. Il peut contenir des flèches indiquant sa direction (entrée ou sortie) si l’activité ne permet pas
de le déterminer de manière univoque.

-
86 -
6.4.3 Pin de valeur (value pin)
Un pin valeur est un pin d’entrée qui fournit une valeur à une action sans que cette valeur ne provienne d’un
arc de flot d’objets. Un pin valeur est toujours associé à une valeur spécifique.
Graphiquement, un pin de valeur se représente comme un pin d’entrée avec la valeur associée écrite à proximité.

6.4.4 Flot d’objet

Fig. 6.8 – Deux notations possibles pour modéliser un flot de données.

Un flot d’objets permet de passer des données d’une activité à une autre. Un arc reliant un pin de sortie à un
pin d’entrée est, par définition même des pins, un flot d’objets (en haut de la figure 6.8). Dans cette configuration,
le type du pin récepteur doit être identique ou parent (au sens de la relation de généralisation) du type du pin
émetteur.
Il existe une autre représentation possible d’un flot d’objets, plus axée sur les données proprement dites car elle
fait intervenir un nœud d’objet détaché d’une activité particulière (en bas de la figure 6.8). Graphiquement, un tel
nœud d’objet est représenté par un rectangle dans lequel est mentionné le type de l’objet (souligné). Des arcs viennent
ensuite relier ce nœud d’objet à des activités sources et cibles. Le nom d’un état, ou d’une liste d’états, de l’objet peut
être précisé entre crochets après ou sous le type de l’objet. On peut également préciser des contraintes entre
accolades, soit à l’intérieur, soit en dessous du rectangle du nœud d’objet.
La figure 6.11 montre l’utilisation de nœuds d’objets dans un diagramme d’activités.
Un flot d’objets peut porter une étiquette stéréotypée mentionnant deux comportements particuliers :
– «transformation» indique une interprétation particulière de la donnée véhiculée par le flot ;
– «selection» indique l’ordre dans lequel les objets sont choisis dans le nœud pour le quitter (cf. figure 6.10).

6.4.5 Nœud tampon central (central buffer node)

Un nœud tampon central est un nœud d’objet qui accepte les entrées de plusieurs nœuds d’objets ou produit des
sorties vers plusieurs nœuds d’objets. Les flots en provenance d’un nœud tampon central ne sont donc pas
directement connectés à des actions. Ce nœud modélise donc un tampon traditionnel qui peut contenir des valeurs en
provenance de diverses sources et livrer des valeurs vers différentes destinations.
Graphiquement, un nœud tampon central est représenté comme un nœud d’objet détaché (en bas de la figure 6.8)
stéréotypé «centralBuffer» (cf. figure 6.9).

6.4.6 Nœud de stockage des données (data store node)

Un nœud de stockage des données est un nœud tampon central particulier qui assure la persistance des données.
Lorsqu’une information est sélectionnée par un flux sortant, l’information est dupliquée et ne disparaît pas du
nœud de stockage des données comme ce serait le cas dans un nœud tampon

-
87 -
Fig. 6.9 – Exemple d’utilisation d’un nœud tampon central pour centraliser toutes les commandes prises par différents
procédés, avant qu’elles soient traitées.

Fig. 6.10 – Dans cette modélisation, le personnel, après avoir été recruté par l’activité Recruter personnel, est stocké de
manière persistante dans le nœud de stockage Base de donnée du Personnel. Bien qu’ils restent dans ce nœud, chaque
employé qui n’a pas encore reçu d’affectation (étiquette stéréotypée «selection» : [Link]=null) est
disponible pour être utilisé par l’activité Affecter personnel.

-
88 -
6.5. PARTITIONS 89

central. Lorsqu’un flux entrant véhicule une donnée déjà stockée par le nœud de stockage des données, cette dernière
est écrasée par la nouvelle.
Graphiquement, un nœud tampon central est représenté comme un nœud d’objet détaché (en bas de la figure 6.8)
stéréotypé «datastore» (cf. figure 6.10).

6.5 Partitions

Fig. 6.11 – Illustration de l’utilisation de nœuds d’objets et de partitions dans un diagramme d’activités.

Les partitions, souvent appelées couloirs ou lignes d’eau (swimlane) du fait de leur notation, per- mettent d’organiser
les nœuds d’activités dans un diagramme d’activités en opérant des regroupements (cf. figure 6.11).
Les partitions n’ont pas de signification bien arrêtée, mais correspondent souvent à des unités d’or- ganisation du
modèle. On peut, par exemple, les utiliser pour spécifier la classe responsable de la mise en œuvre d’un ensemble
tâche. Dans ce cas, la classe en question est responsable de l’implémentation du comportement des nœuds inclus
dans ladite partition.
Graphiquement, les partitions sont délimitées par des lignes continues. Il s’agit généralement de lignes
verticales, comme sur la figure 6.11, mais elle peuvent être horizontales ou même courbes. Dans la version 2.0
d’UML, les partitions peuvent être bidimensionnelles, elles prennent alors la forme d’un tableau. Dans le cas d’un
diagramme d’activités partitionné, les nœuds d’activités appartiennent for-

-
89 -
6.5. PARTITIONS 90

cément à une et une seule partition. Les transitions peuvent, bien entendu, traverser les frontières des partitions.
Les partitions d’activités étant des catégories arbitraires, on peut les représenter par d’autre moyens quand une
répartition géométrique s’avère difficile à réaliser. On peut ainsi utiliser des couleurs ou tout simplement étiqueter les
nœuds d’activité par le nom de leur partition d’appartenance.

6.6 Exceptions

Fig. 6.12 – Notation graphique du fait qu’une activité peut soulever une exception.

Une exception est générée quand une situation anormale entrave le déroulement nominal d’une tâche. Elle peut être
générée automatiquement pour signaler une erreur d’exécution (débordement d’indice de tableau, division par zéro,
. . .), ou être soulevée explicitement par une action (RaiseException) pour signaler une situation problématique qui n’est
pas prise en charge par la séquence de traitement normale. Graphiquement, on peut représenter le fait qu’une activité
peut soulever une exception comme un pin de sortie orné d’un petit triangle et en précisant le type de l’exception à
proximité du pin de sortie (cf. figure 6.12).

Fig. 6.13 – Les deux notations graphiques de la connexion entre une activité protégée et son gestionnaire d’exception
associé.

Un gestionnaire d’exception est une activité possédant un pin d’entrée du type de l’exception qu’il gère et lié à
l’activité qu’il protège par un arc en zigzag ou un arc classique orné d’une petite flèche en zigzag. Le gestionnaire
d’exception doit avoir les mêmes pins de sortie que le bloc qu’il protège (cf. figure 6.13).
Les exceptions sont des classeurs et, à ce titre, peuvent posséder des propriétés comme des attributs ou des
opérations. Il est également possible d’utiliser la relation d’héritage sur les exceptions. Un ges- tionnaire d’exception
spécifie toujours le type des exceptions qu’il peut traiter, toute exception dérivant de ce type est donc également prise
en charge.
Lorsqu’une exception survient, l’exécution de l’activité en cours est abandonnée sans générer de valeur de sortie.
Le mécanisme d’exécution recherche alors un gestionnaire d’exception susceptible de traiter l’exception levée ou
une de ses classes parentes. Si l’activité qui a levé l’exception n’est pas protégée de cette exception, l’exception est
propagée à l’activité englobante. L’exécution de cette dernière

-
90 -
Fig. 6.14 – Exemple d’utilisation d’un gestionnaire d’exception pour protéger une activité de l’exception
Division_par_zero déclenchée en cas de division par zéro.

est abandonnée, ses valeurs de sortie ne sont pas générées et un gestionnaire d’exception est recherché à son niveau. Ce
mécanisme de propagation se poursuit jusqu’à ce qu’un gestionnaire adapté soit trouvé. Si l’exception se propage
jusqu’au sommet d’une activité (i.e. il n’y a plus d’activité englobante), trois cas de figure se présentent. Si l’activité a
été invoquée de manière asynchrone, aucun effet ne se produit et la gestion de l’exception est terminée. Si l’activité a
été invoquée de manière synchrone, l’exception est propagée au mécanisme d’exécution de l’appelant. Si l’exception
s’est propagée à la racine du système, le modèle est considéré comme incomplet ou mal formé. Dans la plupart des
langages orientés objet, une exception qui se propage jusqu’à la racine du programme implique son arrêt. Quand un
gestionnaire d’exception adapté a été trouvé et que son exécution se termine, l’exécution se poursuit comme si l’activité
protégée s’était terminée normalement, les valeurs de sortie fournies par le gestionnaire remplaçant celle que l’activité
protégée aurait dû produire.

-
91 -
Chapitre 7

Diagrammes d’interaction
(Interaction diagram)
7.1 Présentation du formalisme
7.1.1 Introduction
Un objet interagit pour implémenter un comportement. On peut décrire cette interaction de deux manières
complémentaires : l’une est centrée sur des objets individuels (diagramme d’états-transitions) et l’autre sur une
collection d’objets qui coopèrent (diagrammes d’interaction).
La spécification d’un diagramme d’états-transitions est précise et conduit immédiatement au code. Elle ne permet
pas pour autant d’expliquer le fonctionnement global d’un système, car elle se concentre sur un seul objet à la fois. La
vue de l’ensemble des interactions offre une vue plus holistique1 du comportement d’un jeu d’objets.
Les diagrammes d’interaction permettent d’établir un lien entre les diagrammes de cas d’utilisation et les
diagrammes de classes : ils montrent comment des objets (i.e. des instances de classes) commu- niquent pour réaliser
une certaine fonctionnalité. Ils apportent un aspect dynamique à la modélisation du système.
Le modélisateur doit pouvoir focaliser son attention sur un sous-ensemble d’éléments du système et étudier
leur façon d’interagir pour décrire un comportement particulier du système. UML permet de décrire un
comportement limité à un contexte précis de deux façons : dans le cadre d’un classeur structuré (cf. section 7.1.2) ou
dans celui d’une collaboration (cf. section 7.1.3).

7.1.2 Classeur structuré

Fig. 7.1 – Exemple de classeur structuré montrant qu’un classeur Moteur est en fait constitué d’un objet
Allumage et de quatre objets Bougie.

Les classes découvertes au moment de l’analyse (celles qui figurent dans le diagramme de classes) ne sont pas assez
détaillées pour pouvoir être implémentées par des développeurs. UML propose de partir

1 Doctrine ou point de vue qui consiste à considérer les phénomènes comme des totalités.

93

-
92 -
des classeurs découverts au moment de l’analyse (tels que les classes, les sous-systèmes, les cas d’uti- lisation, . . .)
et de les décomposer en éléments suffisamment fins pour permettre leur implémentation. Les classeur ainsi
décomposés s’appellent des classeurs structurés.
Graphiquement, un classeur structuré se représente par un rectangle en trait plein comprenant deux compartiments.
Le compartiment supérieur contient le nom du classeur et le compartiment inférieur montre les objets internes reliées
par des connecteurs (cf. figure 7.1).

7.1.3 Collaboration

Fig. 7.2 – Diagramme de collaboration d’une transaction immobilière.

Une collaboration montre des instances qui collaborent dans un contexte donné pour mettre en oeuvre une
fonctionnalité d’un système.
Graphiquement, une collaboration se représente par une ellipse en trait pointillé comprenant deux compartiments.
Le compartiment supérieur contient le nom de la collaboration et le compartiment inférieur montre les participants à la
collaboration (cf. figure 7.2).

7.1.4 Interactions et lignes de vie

Fig. 7.3 – Diagramme de classe d’un système de pilotage.

Fig. 7.4 – Diagramme de communication d’un système de pilotage.

Une interaction montre le comportement d’un classeur structuré ou d’une collaboration en se focali- sant sur
l’échange d’informations entre les éléments du classeur ou de la collaboration. Une interaction

-
94 -
7.2. DIAGRAMME DE COMMUNICATION 95

Fig. 7.5 – Diagramme de séquence d’un système de pilotage.

contient un jeu de ligne de vie. Chaque ligne de vie correspond à une partie interne d’un classeur ou de la collaboration
et représente une instance ou un jeu d’instances sur une période donnée. L’interaction décrit donc l’activité interne des
éléments du classeur ou de la collaboration, appelés lignes de vie, et des messages qu’ils échangent.
UML propose principalement deux diagrammes pour illustrer une interaction : le diagramme de communication et
celui de séquence. Une même interaction peut être présentée aussi bien par l’un que par l’autre (cf. figure 7.4 et 7.5).

Remarque
A ces deux diagrammes, UML 2.0 en ajoute un troisième : le diagramme de timing. Son usage est limité à la
modélisation des systèmes qui s’exécutent sous de fortes contraintes de temps, comme les systèmes temps réel.

7.1.5 Représentation générale

Un diagramme d’interaction se représente par un rectangle contenant, dans le coin supérieur gauche, un pentagone
accompagné du mot-clef sd lorsqu’il s’agit d’un diagramme de séquence (cf. figure 7.5) et com lorsqu’il s’agit d’un
diagramme de communication (cf. figure 7.4). Le mot clé est suivi du nom de l’interaction. Dans le pentagone, on
peut aussi faire suivre le nom par la liste des lignes de vie impliquées, précédée par le mot clé lifelines :. Enfin, des
attributs peuvent être indiqués dans la partie supérieure du rectangle contenant le diagramme (cf. figure 7.9). La
syntaxe de ces attributs est la même que celle des attributs d’un classe.

7.2 Diagramme de communication (Communication diagram)

Contrairement à un diagramme de séquence, un diagramme de communication rend compte de l’or- ganisation
spatiale des participants à l’interaction, il est souvent utilisé pour illustrer un cas d’utilisation ou pour décrire une
opération.

7.2.1 Représentation des lignes de vie

Les lignes de vie sont représentées par des rectangles contenant une étiquette dont la syntaxe est :

[<nom_du_rôle>] : [<Nom_du_type>]

Au moins un des deux noms doit être spécifié dans l’étiquette, les deux points ( :) sont, quand à eux, obligatoire.

-
95 -
 7.2.2 Représentation des connecteurs
Les relations entre les lignes de vie sont appelées connecteurs et se représentent par un trait plein reliant deux lignes
de vies et dont les extrémités peuvent être ornées de multiplicités.

7.2.3 Représentation des messages

Dans un diagramme de communication, les messages sont généralement ordonnés selon un numéro de séquence
croissant.
Un message est, habituellement, spécifié sous la forme suivante :

[ ’[’cond’]’ [séq] [ *[||] ’[’iter’]’ ] :] [r :=] msg([par])

cond est une condition sous forme d’expression booléenne entre crochets.
séq est le numéro de séquence du message. On numérote les messages par envoi et sous-envoi désignés par des chiffres
séparés par des points : ainsi l’envoi du message 1.4.3 est antérieur à celui du message 1.4.4 mais postérieur à
celui du message 1.3.5. La simultanéité d’un envoi est désignée par une lettre : les messages 1.6.a et 1.6.b sont
envoyés en même temps.
iter spécifie (en langage naturel, entre crochets) l’envoi séquentiel (ou en parallèle, avec ||). On peut omettre
cette spécification et ne garder que le caractère "*" (ou "*||") pour désigner un message récurrent envoyé un
certain nombre de fois.
r est la valeur de retour du message, qui sera par exemple transmise en paramètre à un autre message.
msg est le nom du message.
par désigne les paramètres (optionnels) du message.
Cette syntaxe un peu complexe permet de préciser parfaitement l’ordonnancement et la synchroni- sation des
messages entre les objets du diagramme de communication. La direction d’un message est spécifiée par une flèche
pointant vers l’un ou l’autre des objets de l’interaction, reliés par ailleurs avec un trait continu (connecteur).

7.3 Diagramme de séquence (Sequence diagram)

Les principales informations contenues dans un diagramme de séquence sont les messages échangés entre les lignes
de vie, présentés dans un ordre chronologique. Ainsi, contrairement au diagramme de communication, le temps y
est représenté explicitement par une dimension (la dimension verticale) et s’écoule de haut en bas.

7.3.1 Représentation des lignes de vie

Une ligne de vie se représente par un rectangle, auquel est accroché une ligne verticale pointillée, contenant une
étiquette dont la syntaxe est :

[<nom_du_rôle>] : [<Nom_du_type>]

Au moins un des deux noms doit être spécifié dans l’étiquette, les deux points ( :) sont, quand à eux, obligatoire.

7.3.2 Représentation des messages

Messages synchrones et asynchrones, création et destruction d’instance
Un message définit une communication particulière entre des lignes de vie. Plusieurs types de messages
existent, les plus commun sont :
– l’envoi d’un signal ;
– l’invocation d’une opération ;

-
96 -
 – la création ou la destruction d’une instance.
Une interruption ou un évènement sont de bons exemples de signaux. Ils n’attendent pas de réponse et ne bloquent
pas l’émetteur qui ne sait pas si le message arrivera à destination, le cas échéant quand il arrivera et s’il serra traité par
le destinataire. Un signal est, par définition, un message asynchrone.

Fig. 7.6 – Représentation d’un message asynchrone.

Graphiquement, un message asynchrone se représente par une flèche en traits pleins et à l’extrémité ouverte partant
de la ligne de vie d’un objet expéditeur et allant vers celle de l’objet cible (figure 7.6).
L’invocation d’une opération est le type de message le plus utilisé en programmation objet. L’invoca- tion peut être
asynchrone ou synchrone. Dans la pratique, la pluspart des invocations sont synchrones, l’émetteur reste alors
bloqué le temps que dure l’invocation de l’opération.

Fig. 7.7 – Représentation d’un message synchrone.

Graphiquement, un message synchrone se représente par une flèche en traits pleins et à l’extrémité pleine partant
de la ligne de vie d’un objet expéditeur et allant vers celle de l’objet cible (figure 7.7). Ce message peut être suivi
d’une réponse qui se représente par une flèche en pointillé (figure 7.7).
La création d’un objet est matérialisée par une flèche qui pointe sur le sommet d’une ligne de vie. La destruction
d’un objet est matérialisée par une croix qui marque la fin de la ligne de vie de l’objet.

Événements et messages

Fig. 7.8 – Les différents évènement correspondant à un message asynchrone.

-
97 -
 UML permet de séparer clairement l’envoi du message, sa réception, ainsi que le début de l’exécution de la
réaction et sa fin (figure 7.8).

Syntaxe des messages et des réponses

Fig. 7.9 – Syntaxe des messages et des réponses.

Dans la plupart des cas, la réception d’un message est suivie de l’exécution d’une méthode d’une classe. Cette
méthode peut recevoir des arguments et la syntaxe des messages permet de transmettre ces arguments. La syntaxe
de ces messages est la même que pour un diagramme de communication (cf. section 7.2.3) excepté deux points :
– la direction du message est directement spécifiée par la direction de la flèche qui matérialise le message, et
non par une flèche supplémentaire au dessus du connecteur reliant les objets comme c’est le cas dans un
diagramme de communication ;
– les numéros de séquence sont généralement omis puisque l’ordre relatif des messages est déjà matérialisé
par l’axe vertical qui représente l’écoulement du temps.
La syntaxe de réponse à un message est la suivante :

[<attribut> = ] message [ : <valeur_de_retour>]

où message représente le message d’envoi.

La figure 7.9 montre un exemple d’exécution d’une méthode avec une réponse.

Message perdu et trouvé

Fig. 7.10 – Représentation d’un message perdu et d’un message trouvé.

Un message complet est tel que les événements d’envoi et de réception sont connus. Comme nous l’avons déjà vu,
un message complet se représente par une simple flèche dirigée de l’émetteur vers le récepteur.

-
98 -
 Un message perdu est tel que l’événement d’envoi est connu, mais pas l’événement de réception. Il se
représente par une flèche qui pointe sur une petite boule noire (figure 7.10).
Un message trouvé est tel que l’événement de réception est connu, mais pas l’événement d’émission.
Une flèche partant d’une petite boule noire représente un message trouvé (figure 7.10).

Porte
Une porte est un point de connexion qui permet de représenter un même message dans plusieurs fragments
d’interaction. Ces messages entrants et sortants vont d’un bord d’une diagramme à une ligne de vie (ou l’inverse).

Exécution de méthode et objet actif

Un objet actif initie et contrôle le flux d’activités. Graphiquement, la ligne pointillée verticale d’un objet actif
est remplacée par un double trait vertical.
Un objet passif, au contraire, a besoin qu’on lui donne le flux d’activité pour lui appliquer une méthode. La
spécification de l’exécution d’une réaction sur un objet passif se représente par un rectangle blanc ou gris placé sur la
ligne de vie en pointillée (cf. figures 7.7 ou 7.9 par exemple). Le rectangle peut éventuellement porter un label.

7.3.3 Fragments d’interaction combinés

Introduction
Un fragment combiné représente des articulations d’interactions. Il est défini par un opérateur et des opérandes.
L’opérateur conditionne la signification du fragment combiné. Il existe 12 d’opérateurs définis dans la notation UML
2.0. Les fragments combinés permettent de décrire des diagrammes de séquence de manière compacte. Les fragments
combinés peuvent faire intervenir l’ensemble des entités participant au scénario ou juste un sous-ensemble.
Un fragment combiné se représente de la même façon qu’une interaction. Il est représenté un rectangle dont le coin
supérieur gauche contient un pentagone. Dans le pentagone figure le type de la combinaison, appelé opérateur
d’interaction. Les opérandes d’un opérateur d’interaction sont séparés par une ligne pointillée. Les conditions de choix
des opérandes sont données par des expressions booléennes entre crochets ([ ]).
La liste suivante regroupe les opérateurs d’interaction par fonctions :
– les opérateurs de choix et de boucle : alternative, option, break et loop ;
– les opérateurs contrôlant l’envoi en parallèle de messages : parallel et critical region ;
– les opérateurs contrôlant l’envoi de messages : ignore, consider, assertion et negative ;
– les opérateurs fixant l’ordre d’envoi des messages : weak sequencing , strict sequencing.
Nous n’aborderons que quelques-unes de ces interactions dans la suite de cette section.

Opérateurs alt et opt

L’opérateur alternative, ou alt, est un opérateur conditionnel possédant plusieurs opérandes (cf. figure 7.11). C’est
un peu l’équivalent d’une exécution à choix multiple (condition switch en C++). Chaque opérande détient une condition
de garde. L’absence de condition de garde implique une condition vraie (true). La condition else est vraie si
aucune autre condition n’est vraie. Exactement un opérande dont la condition est vraie est exécuté. Si plusieur
opérandes prennent la valeur vraie, le choix est non déterministe.
L’opérateur option, ou opt, comporte une opérande et une condition de garde associée. Le sous- fragment s’exécute
si la condition de garde est vraie et ne s’exécute pas dans le cas contraire.

-
99 -
 Fig. 7.11 – Représentation d’un choix dans un diagramme de séquence.

Fig. 7.12 – Représentation d’une boucle dans un diagramme de séquence.

Opérateur loop
Un fragments combiné de type loop (cf. figure 7.12) possède un sous-fragment et spécifie un compte minimum et
maximum (boucle) ainsi qu’une condition de garde.
La syntaxe de la boucle est la suivante :

loop[ ’(’<minInt> [ ’,’ <maxInt> ] ’)’ ]

La condition de garde est placée entre crochets sur la ligne de vie.

La boucle est répétée au moins minInt fois avant qu’une éventuelle condition de garde booléenne ne soit testée. Tant
que la condition est vraie, la boucle continue, au plus maxInt fois.

Opérateur par
Un fragments combiné de type parallel, ou par, possède au moins deux sous-fragments exécutés simultanément (cf.
figure 7.13). La concurrence est logique et n’est pas nécessairement physique : les exécutions concurrentes peuvent
s’entrelacer sur un même chemin d’exécution dans la pratique.

-
100
-
 Fig. 7.13 – MicrowaveOven est un exemple d’objet effectuant deux tâches en parallèle.

Opérateur strict

Fig. 7.14 – Procédures de décollage d’un avion dans l’ordre.

Un fragments combiné de type strict sequencing, ou strict, possède au moins deux sous-fragments. Ceux-ci
s’exécutent selon leur ordre d’apparition au sein du fragment combiné. Ce fragment combiné est utile surtout
lorsque deux parties d’un diagramme n’ont pas de ligne de vie en commun (cf. figure 7.14).

7.3.4 Utilisation d’interaction (interaction use)

Il est possible de faire référence à une interaction (on appelle cela une utilisation d’interaction) dans la définition
d’une autre interaction. Comme pour toute référence modulaire, cela permet la réutilisation d’une définition dans de
nombreux contextes différents.
Lorsqu’une utilisation d’interaction s’exécute, elle produit le même effet que l’exécution d’une inter- action
référencée avec la substitution des arguments fournie dans le cadre de l’utilisation de l’interaction.

-
101
-
L’utilisation de l’interaction doit couvrir toutes les lignes de vie qui apparaissent dans l’interaction réfé- rencée.
L’interaction référencée ne peut ajouter des lignes de vie que si elles ont lieu en son sein.
Graphiquement, une utilisation apparaît dans un diagramme de séquence sous forme de rectangle avec le tag
ref (pour référence). On place dans le rectangle le nom de l’interaction référencée (cf. figure 7.14). La syntaxe
complète pour spécifier l’interaction à réutiliser est la suivante :

[ <nomAttributValeurRetour> ’=’ ] <nomInteraction> [

’(’ [<arguments>] ’)’ ][ ’:’ <valeurRetour>

-
102
-
Chapitre 8 et Chapitre 9
Diagrammes de composants (Component
diagram) &
Diagrammes de déploiement
(Deployment diagram)

8.1 Introduction
Les diagrammes de composants et les diagrammes de déploiement sont les deux derniers types de vues
statiques en UML. Les premiers décrivent le système modélisé sous forme de composants réutilisables et mettent en
évidence leurs relations de dépendance. Les seconds se rapprochent encore plus de la réalité physique, puisqu’ils
identifient les éléments matériels (PC, Modem, Station de travail, Serveur, etc.), leur disposition physique (connexions)
et la disposition des exécutables (représentés par des composants) sur ces éléments matériels.

8.2 Diagrammes de composants

8.2.1 Pourquoi des composants ?

Dans la section 1.1.4, parmi tous les facteurs qui concourent à la qualité d’un logiciel, nous avons introduit la notion
de réutilisabilité comme étant l’aptitude d’un logiciel à être réutilisé, en tout ou en partie, dans de nouvelles
applications. Or, la notion de classe, de part sa faible granularité et ses connexions figées (les associations avec les autres
classes matérialisent des liens structurels), ne constitue pas une réponse adaptée à la problématique de la réutilisation.
Pour faire face à ce problème, les notions de patrons et de canevas d’applications ont percé dans les années 1990
pour ensuite laisser la place à un concept plus générique et fédérateur : celui de composant. La programmation par
composants constitue une évolution technologique soutenue par de nombreuses plateformes (composants EJB,
CORBA, .Net, WSDL, . . .). Ce type de programmaiton met l’accent sur la réutilisation du composant et
l’indépendance de son évolution vis-à-vis des applications qui l’utilisent.
La programmation orientée composant s’intègre très bien dans le contexte de la programmation orientée objet
puisqu’il ne s’agit, finalement, que d’un facteur d’échelle. En effet, l’utilisation de compo- sants est assimilable à
une approche objet, non pas au niveau du code, mais au niveau de l’architecture générale du logiciel.

103

-
103
-
Fig. 8.1 – Représentation d’un composant et de ses interfaces requises ou offertes sous la forme d’un classeur structuré
stéréotypé «component». Au lieu ou en plus du mot clé, on peut faire figurer une icône de composant (petit rectangle
équipé de deux rectangles plus petits dépassant sur son côté gauche) dans l’angle supérieur droit (comme sur la figure
de droite).

Fig. 8.2 – Représentation d’un composant accompagnée de la représentation explicite de ses interfaces requise et
offerte.

Fig. 8.3 – Représentation classique d’un composant et de ses interfaces requise (représenté par un demi- cercle) et offerte
(représentée par un cercle). Cette représentation est souvent utilisée dans les diagrammes de composants (cf. figure 8.5).
Sur la figure du bas, le stéréotype « component » est rendu inutile par la représentation même du composant.

Fig. 8.4 – Représentation d’un composant et de ses interfaces requise et offerte avec la représentation explicite de
leur port correspondant.

-
104
-
8.2. DIAGRAMMES DE COMPOSANTS 105

8.2.2 Notion de composant

Un composant doit fournir un service bien précis. Les fonctionnalités qu’il encapsule doivent être cohérentes entre
elles et génériques (par opposition à spécialisées) puisque sa vocation est d’être réutili- sable.
Un composant est une unité autonome représentée par un classeur structuré, stéréotypé «component», comportant
une ou plusieurs interfaces requises ou offertes. Son comportement interne, généralement
réalisé par un ensemble de classes, est totalement masqué : seules ses interfaces sont visibles. La seule contrainte pour
pouvoir substituer un composant par un autre est de respecter les interfaces requises et offertes.
Les figures 8.1, 8.2, 8.3 et 8.4 illustrent différentes façons de représenter un composant.
Un composant étant un classeur structuré, on peut en décrire la structure interne. L’implémentation d’un
composant peut être réalisée par d’autres composants, des classes ou des artefacts (cf. section 8.3.3). Les éléments d’un
composant peuvent être représentés dans le symbole du composant (cf. figure 8.5), ou à côté en les reliant au
composant par une relation de dépendance.
Pour montrer les instances des composants, un diagramme de déploiement doit être utilisé (cf. section 8.3).

8.2.3 Notion de port

Un port est un point de connexion entre un classeur et son environnement.
Graphiquement, un port est représenté par un petit carré à cheval sur la bordure du contour du classeur. On peut
faire figurer le nom du port à proximité de sa représentation.
Généralement, un port est associé à une interface requise ou offerte (cf. figure 8.4). Parfois, il est relié directement à
un autre port situé sur la limite du composant englobant (cf. figure 8.5) par une flèche en trait plein, pouvant être
stéréotypée «delegate», et appelée connecteur de délégation.
L’utilisation des ports permet de modifier la structure interne d’un classeur sans affecter les clients externes.

8.2.4 Diagramme de composants

La relation de dépendance est utilisée dans les diagrammes de composants pour indiquer qu’un élément de
l’implémentation d’un composant fait appel aux services offerts par les éléments d’implé- mentation d’un autre
composant (cf. figure 8.6).
Lorsqu’un composant utilise l’interface d’un autre composant, on peut utiliser la représenation de la figure 8.3
en imbriquant le demi-cercle d’une interface requise dans le cercle de l’interface offerte correspondante (cf. figure 8.5).

-
105
-
8.3. DIAGRAMME DE 106
DÉPLOIEMENT

Fig. 8.5 – Représentation de l’implémentation d’un composant complexe contenant des sous-composants.

Fig. 8.6 – Exemple de diagramme montrant les dépendances entre composants.

-
106
-
8.3. DIAGRAMME DE 107
DÉPLOIEMENT

8.3 Diagramme de déploiement

8.3.1 Objectif du diagramme de déploiement
Un diagramme de déploiement décrit la disposition physique des ressources matérielles qui com- posent le système
et montre la répartition des composants sur ces matériels. Chaque ressource étant matérialisée par un nœud, le diagramme
de déploiement précise comment les composants sont répartis sur les nœuds et quelles sont les connexions entre les
composants ou les nœuds. Les diagrammes de déploiement existent sous deux formes : spécification et instance.

8.3.2 Représentation des nœuds

Fig. 8.7 – Représentation d’un nœud (à gauche) et d’une instance de nœud (à droite).

Chaque ressource est matérialisée par un nœud représenté par un cube comportant un nom (cf. figure 8.7). Un nœud
est un classeur et peut posséder des attributs (quantité de mémoire, vitesse du processeur,
. . .).

Fig. 8.8 – Deux possibilités pour représenter l’affectation d’un composant à un nœud.

Pour montrer qu’un composant est affecté à un nœud, il faut soit placer le composant dans le nœud, soit les relier
par une relation de dépendance stéréotypée «support» orientée du composant vers le nœud (cf. figure 8.8).

8.3.3 Notion d’artefact (artifact)

Un artefact correspond à un élément concret existant dans le monde réel (document, exécutable, fichier, tables de
bases de données, script, . . .). Il se représente comme un classeur par un rectangle contenant le mot-clé «artifact» suivi
du nom de l’artefact (cf. figures 8.9 et 8.9).
L’implémentation des modèles (classes, . . .) se fait sous la forme de jeu d’artefacts. On dit qu’un arte- fact peut
manifester, c’est-à-dire résulter et implémenter, un ensemble d’éléments de modèle. On appelle manifestation la relation
entre un élément de modèle et l’artefact qui l’implémente. Graphiquement, une manifestation se représente par une
relation de dépendance stéréotypée «manifest» (cf. figure 8.11).
Une instance d’un artefact se déploie sur une instance de nœud. Graphiquement, on utilise une relation de
dépendance (flèche en trait pointillé) stéréotypée «deploy» pointant vers le nœud en question (cf. figure 8.10). L’artefact
peut aussi être inclus directement dans le cube représentant le noeud (cf. figure 8.9). En toute rigueur, seul des artefacts
doivent être déployés sur des nœuds. Un composant doit donc être manifesté par un artefact qui, lui-même, peut
être déployé sur un nœud.

-
107
-
Fig. 8.9 – Représentation du déploiement de deux artefacts dans un nœud. La dépendance entre les deux artefacts
est également représentée.

Fig. 8.10 – Représentation du déploiement de deux artefacts dans un nœud utilisant la relation de dépendance
stéréotypée «deploy».

Fig. 8.11 – Représentation du déploiement dans un nœud d’un artefact manifestant un composant.

Dans un diagramme de déploiement, les associations entre nœuds sont des chemins de communica- tion qui
permettent l’échange d’informations (cf. figure 8.12).

-
108
-
Chapitre 10

Mise en œuvre d’UML

9.1 Introduction
9.1.1 UML n’est pas une méthode

Fig. 9.1 – Quelle méthode pour passer de l’expression des besoins au code de l’application ?

La problématique que pose la mise en œuvre d’UML est simple : comment passer de l’expression des besoins au
code de l’application ? Cette problématique est parfaitement illustrée par la figure 9.1.
Comme nous l’avons déjà dit, à maintes reprises, UML n’est qu’un langage de modélisation, ce n’est pas une
méthode. En effet, UML ne propose pas une démarche de modélisation explicitant et encadrant toutes les étapes d’un
projet, de la compréhension des besoins à la production du code de l’application. Une méthode se doit de définir une
séquence d’étapes, partiellement ordonnées, dont l’objectif est de produire un logiciel de qualité qui répond aux besoins
des utilisateurs dans des temps et des coûts prévisibles.
Bien qu’UML ne soit pas une méthode, ses auteurs précisent néanmoins qu’une méthode 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éali- sation. 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. Nous avons déjà présenté le modèle de cycle de vie par incrément dans la section 1.2.3.

111

-
109
-
9.3. PHASES 112
D’ANALYSE

9.1.2 Une méthode simple et générique

Dans les sections qui suivent (sections 9.2, 9.3 et 9.4) nous allons présenter une méthode simple et générique qui
se situe à mi-chemin entre UP (Unified Process), qui constitue un cadre général très complet de processus de
développement, et XP (eXtreme Programming) qui est une approche minimaliste à la mode centrée sur le code.
Cette méthode est issue de celle présentée par Roques (2002) dans son livre
« UML - Modéliser un site e-commerce » qui résulte de plusieurs années d’expérience sur de nombreux projets dans des
domaines variés. Elle a donc montré son efficacité dans la pratique et est :
– conduite par les cas d’utilisation, comme UP, mais bien plus simple ;
– relativement légère et restreinte, comme XP, mais sans négliger les activités de modélisation en analyse et
conception ;
– fondée sur l’utilisation d’un sous-ensemble nécessaire et suffisant du langage UML (modéliser 80% des
problèmes en utilisant 20% d’UML).
Dans tous les cas, il faut garder à l’esprit qu’une méthode n’est pas une formule magique. Le fait de produire
des diagrammes UML selon un ordre établi n’est en aucun cas une garantie de réussite. Une méthode ne sert qu’à
canaliser et ordonner les étapes de la modélisation. La valeur n’est pas dans la méthode mais dans les personnes
qui la mettent en œuvre.

9.2 Identification des besoins et spécification des fonctionnalités

9.2.1 Identification et représentation des besoins : diagramme de cas d’utilisation

Fig. 9.2 – Les besoins sont modélisés par un diagramme de cas d’utilisation.

Les cas d’utilisation sont utilisés tout au long du projet. Dans un premier temps, on les crée pour identifier et
modéliser les besoins des utilisateurs (figure 9.2). 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 (cf. section 2.5). Si l’application est complexe, vous pourrez organiser les cas d’utilisation en paquetages.
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 textuelle
et sous forme graphique au moyen de diagrammes de séquence (cf. section 9.2.2). Les utilisateurs ont souvent beaucoup
de difficultés à exprimer clairement et précisément ce qu’ils attendent du système. L’objectif de cette étape et des deux
suivantes (section 9.2.2 et 9.2.3) est justement de les aider à formuler et formaliser ces besoins.

-
112
-
9.3. PHASES 113
D’ANALYSE

9.2.2 Spécification détaillée des besoins : diagrammes de séquence système

Fig. 9.3 – Les diagrammes de séquence système illustrent la description textuelle des cas d’utilisation.

Dans cette étape, on cherche à détailler la description des besoins par la description textuelle des cas d’utilisation
(cf. section 2.5.3) et la production de diagrammes de séquence système illustrant cette des- cription textuelle (figure 9.3).
Cette étape amène souvent à mettre à jour le diagramme de cas d’utilisation puisque nous somme 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.
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.

9.2.3 Maquette de l’IHM de l’application (non couvert par UML)

Une maquette d’IHM (Interface Homme-Machine) est un produit jetable permettant aux utilisateurs d’avoir une vue
concrète mais non définitive de la future interface de l’application (figure 9.4). La maquette peut très bien consister
en un ensemble de dessins produits par un logiciel de présentation ou de dessin. Par la suite, la maquette pourra
intégrer des fonctionnalités de navigation permettant à l’utilisateur de tester l’enchaînement des écrans ou des menus,
même si les fonctionnalités restent fictives. La maquette doit être développée rapidement afin de provoquer des retours
de la part des utilisateurs.

9.3 Phases d’analyse

9.3.1 Analyse du domaine : modèle du domaine
La modélisation des besoins par des cas d’utilisation s’apparente à une analyse fonctionnelle clas- sique.
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 (sections 9.2.1, 9.2.2 et 9.2.3). 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 (figure 9.5)
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

-
113
-
9.3. PHASES 114
D’ANALYSE

Fig. 9.4 – Une maquette d’IHM facilite les discussions avec les futurs utilisateurs.

Fig. 9.5 – La phase d’analyse du domaine permet d’élaborer la première version du diagramme de classes.

-
114
-
9.3. PHASES 115
D’ANALYSE

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érations, mais seulement des attributs. Les étapes à suivre pour établir
ce diagramme sont (cf. section 3.5) :
– identifier les entités ou concepts du domaine ;
– identifier et ajouter les associations et les attributs ;
– organiser et 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épen- dance.
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.

9.3.2 Diagramme de classes participantes

Fig. 9.6 – Le diagramme de classes participantes effectue la jonction entre les cas d’utilisation, le modèle du domaine et
les diagrammes de conception logicielle.

Le diagramme de classes participantes est particulièrement important puisqu’il effectue la jonction entre, d’une part,
les cas d’utilisation (section 9.2.1), le modèle du domaine (section 9.3.1) et la maquette (section 9.2.3), et d’autre part,
les diagrammes de conception logicielle que sont les diagrammes d’in- teraction (section 9.4.1) et le diagramme de
classes de conception (section 9.4.2). Les diagrammes de conception logicielle n’apparaissent pas encore sur la figure
9.6.
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,

-
115
-
9.3. PHASES 116
D’ANALYSE

les dialogues, les contrôles et les entités ainsi que leurs relations.

Les classes de dialogues – Les classes qui permettent les interactions entre l’IHM et les utilisateurs sont qualifiées
de dialogues. Ces classes sont directement issues de l’analyse de la maquette présentée section 9.2.3. 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 la section 9.2.1. En général, les dialogues vivent seulement le temps du déroulemet du cas
d’utilisation concerné.

Les classes de contrôles – Les classes qui modélisent la cinématique de l’application sont appelées contrôles. Elles
font la jonction entre les dialogues et les classes métier en permettant au 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 – Les classes métier, qui proviennent directement du modèle du domaine (cf. section 9.3.1), 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 (cf. section 9.5.2).

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 (cf. section 9.3.1).
– 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 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 informa- tions 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 dialoques, mais pas directement
avec des entités.
– Il est également possible d’ajouter les acteurs sur le diagramme de classes participantes en respec- tant la
règle suivante : un acteur ne peut être lié qu’à un dialogue.
Certaines classes possèdent un comportement dynamique complexe. Ces classes auront intérêt à être détaillées par
des diagrammes d’états-transitions.
L’attribution des bonnes responsabilités, dégagée dans la section 9.2.2, aux bonnes classes est l’un des problèmes
les plus délicats de la conception orientée objet. Ce problème sera affronté en phase de conception lors de l’élaboration
des diagrammes d’interaction (section 9.4.1) et du diagramme de classes de conception (section 9.4.2).
Lors de la phase d’élaboration du diagramme de classes participantes, le chef de projet a la possibilité de découper
le travail de son équipe d’analystes par cas d’utilisation. L’analyse et l’implémentation des fonctionnalités dégagées
par les cas d’utilisation définissent alors les itérations à réaliser. L’ordonnance- ment des itérations étant défini par le
degré d’importance et le coefficient de risque affecté à chacun des cas d’utilisation dans la section 9.2.1.

-
116
-
9.4. PHASE DE 117
CONCEPTION

Fig. 9.7 – Les diagrammes d’activités de navigation représentent graphiquement l’activité de navigation dans l’IHM.

9.3.3 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 diagrammes des diagrammes de navigation. Le concepteur à 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 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.

9.4 Phase de conception

9.4.1 Diagrammes d’interaction
Maintenant, il faut attribuer précisément les responsabilités de comportement, dégagée par le dia- grammes de
séquence système dans la section 9.2.2, aux classes d’analyse du diagramme de classes participantes élaboré dans la
section 9.3.2. Les résultats de cette réflexion sont présentés sous la forme de diagrammes d’interaction UML (figure
9.8). Inversement, l’élaboration de ces diagrammes facilite grandement la réflexion.

-
117
-
9.4. PHASE DE 118
CONCEPTION

Fig. 9.8 – Les diagrammes d’interaction permettent d’attribuer précisément les responsabilités de com- portement aux
classes d’analyse.

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 (dans la section 9.4.2).
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 in- voquent des
opérations sur les objets récepteurs. Il est ainsi possible de suivre visuellement les interac- tions dynamiques entre objets,
et les traitements réalisés par chacun d’eux. Avec un outil de modélisation UML (comme Rational Rose 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 de la section 9.2.2, nous remplaçons ici le système, vu comme
une boîte noire, par un ensemble d’objets en collaboration (cf. figure 9.9). 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 dans la section
9.3.2. 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.

-
118
-
9.4. PHASE DE 119
CONCEPTION

Fig. 9.9 – Le système des diagrammes de séquences système, vu comme une boîte noire, est remplacé par un
ensemble d’objets en collaboration.

Fig. 9.10 – Chaîne complète de la démarche de modélisation du besoin jusqu’au code.

9.4.2 Diagramme de classes de conception

L’objectif de cette étape est de produire le diagramme de classes qui servira pour l’implémentation (figure 9.10).
Une première ébauche du diagramme de classes de conception a déjà été élaborée en parallèle du diagrammes
d’interaction (section 9.4.1). 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

-
119
-
 9.4. PHASE DE 120
CONCEPTION

l’implémentation de l’interface graphique), etc.

Pour une classe, le couplage est la mesure de la quantité d’autre 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, référez vous à la section 9.5. Parfois, les classes du type entités ont intérêt
à être implémentées dans une base de données relationnelle (cf. section 9.5.2).

9.5 Phase d’implémentation

9.5.1 Implémentation en Java
Classe
Parfois, la génération automatique de code produit, pour chaque classe, un constructeur et une méthode finalize
comme ci-dessous. Rappelons que cette méthode est invoquée par le ramasse miettes lorsque celui-ci constate que l’objet
n’est plus référencé. Pour des raisons de simplification, nous ne ferons plus figurer ces opérations dans les sections
suivantes.
public class A {
public A() {
...
}
protected void finalize() throws Throwable {
[Link]();
...
}
}

Classe avec attributs et opérations

public class A { public
String a1;
package String a2;
protected String a3;
private String a4;
public void op1() {
...
}
public void op2() {
...
}
}

Classe abstraite
public abstract class A {
...
}

Interface
public interface A {
...
}

-
120
-
 9.5. PHASE 121
D’IMPLÉMENTATION

Héritage simple

public class A {
...
}

public class B extends A {

...
}

Réalisation d’une interface par une classe

public interface Ia {
...
}

public class A implements Ia {

...
}

Association bidirectionnelle 1 vers 1

public class A {
private B rb;
public void addB( B b ) {
if( b != null ){
if ( [Link]() != null ) { // si b est déjà connecté à un autre A
[Link]().setB(null); // cet autre A doit se déconnecter
}
[Link]( b );
[Link]( this );
}
public B getB() { return( rb ); } public
void setB( B b ) { [Link]=b; }
}

public class B {
private A ra;
public void addA( A a ) {
if( a != null ) {
if ([Link]() != null) { // si a est déjà connecté à un autre B
[Link]().setA( null ); // cet autre B doit se déconnecter
}
[Link]( a );
[Link]( this );
}
}
public void setA(A a){ [Link]=a; }

-
121
-
 9.5. PHASE 122
D’IMPLÉMENTATION

public A getA(){ return(ra); }

}

Association unidirectionnelle 1 vers 1

public class A {
private B rb;
public void addB( B b ) {
if( b != null ) {
[Link]( b );
}
public void setB( B b ) { [Link]=b; }
}

public class B {
... // La classe B ne connaît pas l’existence de la classe A
}

Association bidirectionnelle 1 vers plusieurs

public class A {
private ArrayList <B> rb;
public A() { rb = new ArrayList<B>(); }
public void addB( B b ) {
if(  ) {
[Link]( this );
[Link]( b );
}
}
public ArrayList <B> getRB() { return(rb); }
}

public class B { private

A ra;
public void addA( A a ) {
if( a != null ) {
if( ![Link]().contains( this ) ) {
[Link]( a );
[Link]().add( this );
}
}
}
public void setA(A a) { [Link]=a; }
}

-
122
-
 9.5. PHASE 123
D’IMPLÉMENTATION

Association unidirectionnelle 1 vers plusieurs

public class A {
private ArrayList <B> rb;
public A() { rb = new ArrayList<B>(); }
public void addB(B b){
if(  ) {
[Link](b);
}
}
}

public class B {
... // B ne connaît pas l’existence de A
}

Association 1 vers N
Dans ce cas, il faut utiliser un tableau plutôt qu’un vecteur. La
dimension du tableau étant données par la cardinalité de la
terminaison d’association.

Agrégations

Les agrégations s’implémentent comme les associations.

Composition
Une composition peut s’implémenter comme une association
unidirectionnelle.

9.5.2 Implémentation en SQL

Introduction
Il est possible de traduire un diagramme de classe en modèle relationnel. Bien entendu, les méthodes des classes ne
sont pas traduites. Aujourd’hui, lors de la conception de base de données, il devient de plus en plus courant d’utiliser
la modélisation UML plutôt que le traditionnel modèle entités-associations.
Cependant, à moins d’avoir respecté une méthodologie adaptée, la correspondance entre le modèle objet et le modèle
relationnel n’est pas une tâche facile. En effet, elle ne peut que rarement être complète puisque l’expressivité d’un
diagramme de classes est bien plus grande que celle d’un schéma relationnel. Par exemple, comment représenter dans
un schéma relationnel des notions comme la navigabilité ou la composition ? Toutefois, de nombreux AGL (Atelier
de Génie Logiciel) comportent maintenant des fonctionnalités de traduction en SQL qui peuvent aider le développeur
dans cette tâche.

Classe avec attributs

Chaque classe devient une relation. Les attributs de la classe deviennent des attributs de la relation. Si la classe
possède un identifiant, il devient la clé primaire de la relation, sinon, il faut ajouter une clé primaire arbitraire.
create table relation_A ( num_relation_A
integer primary key, att1 text,
att2 integer);

-
123
-
 9.5. PHASE 124
D’IMPLÉMENTATION

Association 1 vers 1
Pour représenter une association 1 vers 1 entre deux relation, la clé primaire de l’une des relations doit figurer
comme clé étrangère dans l’autre relation.
create table relation_A (
id_A integer primary key,
attA1 text,
attA2 integer);

create table relation_B ( id_B

integer primary key,
num_A integer references relation_A,
attB1 text,
attB2 integer);

Association 1 vers plusieurs

Pour représenter une association 1 vers plusieurs, on procède comme pour une association 1 vers 1, excepté que
c’est forcément la relation du côté plusieurs qui reçoit comme clé étrangère la clé primaire de la relation du côté 1.
create table relation_A (
id_A integer primary key,
num_B integer references relation_B,
attA1 text,
attA2 integer);

create table relation_B ( id_B

integer primary key, attB1
text,
attB2 integer);

Association plusieurs vers plusieurs

Pour représenter une association du type plusieurs vers plusieurs, il faut introduire une nouvelle relation dont les
attributs sont les clés primaires des relations en association et dont la clé primaire est la concaténation de ces deux
attributs.
create table relation_A (
id_A integer primary key,
attA1 text,
attA2 integer);

create table relation_B ( id_B

integer primary key, attB1
text,
attB2 integer);

create table relation_A_B (

num_A integer references relation_A,
num_B integer references relation_B,
primary key (num_A, num_B));

Classe-association plusieurs vers plusieurs

Le cas est proche de celui d’une association plusieurs vers plusieurs, les attributs de la classe- association étant
ajoutés à la troisième relation qui représente, cette fois ci, la classe-association elle- même.

-
124
-
9.5. PHASE 125
D’IMPLÉMENTATION

create table relation_A ( id_A

integer primary key, attA1
text,
attA2 integer);

create table relation_B ( id_B

integer primary key, attB1
text,
attB2 integer);

create table relation_C (

num_A integer references relation_A,
num_B integer references relation_B,
attC1 text,
attC2 integer,
primary key (num_A, num_B));

Héritage
Les relations correspondant aux sous-classes ont comme clé étrangère et primaire la clé de la relation correspondant
à la classe parente. Un attribut type est ajouté dans la relation correspondant à la classe parente. Cet attribut permet de
savoir si les informations d’un tuple de la relation correspondant à la classe parente peuvent être complétées par un tuple
de l’une des relations correspondant à une sous- classe, et, le cas échéant, de quelle relation il s’agit. Ainsi, dans cette
solution, un objet peut avoir ses attributs répartis dans plusieurs relations. Il faut donc opérer des jointures pour
reconstituer un objet. L’attribut type de la relation correspondant à la classe parente doit indiquer quelles jointures faire.
create table relation_C ( id_C
integer primary key, attC1
text,
attC2 integer,
type text);

create table relation_A (

id_A references relation_C, attA1
text,
attA2 integer, primary
key (id_A));

create table relation_B (

id_B references relation_C, attB1
text,
attB2 integer, primary
key (id_B));

-
125
-