Génie logiciel

Support de cours de la ​3ème année licence: ISIL + SI

Contenu de la matière

Chapitre 1. Introduction au génie logiciel

1. Définitions et objectifs
2. Principes du Génie logiciel
3. Qualités attendues d’un logiciel
4. Cycle de vie d’un logiciel
5. Modèles de cycle de vie d’un logiciel
Chapitre 2. Modélisation avec UML
1. Modélisation, modèle, modélisation orientée objet, UML en application
2. Éléments et mécanismes généraux
3. Les diagrammes UML
Chapitre 3. Diagramme UML de cas d’utilisation : vue fonctionnelle
Chapitre 4. Diagrammes UML de classes et d’objets : vue statique
1. Diagramme de classes
2. Diagramme d’objets
Chapitre 5. Diagrammes UML: Vue dynamique
1. Diagramme d’interaction (séquence et collaboration).
2. Diagramme d’activités
3. Diagramme d’états/transitions
Chapitre 1. Introduction au génie logiciel

1.Introduction
Le ​génie logiciel (​software engineering​) représente l'application de principes
d'ingénierie dans le domaine de la création de logiciels. Il consiste à identifier et à
utiliser des ​méthodes​, des ​pratiques et des ​outils permettant de maximiser les
chances de réussite d'un projet logiciel.

Il s'agit d'une science récente dont l'origine remonte aux années 1970. A cette époque,
l'augmentation de la puissance matérielle a permis de réaliser des logiciels plus
complexes mais souffrant de nouveaux défauts : délais non respectés, coûts de
production et d'entretien élevés, manque de fiabilité et de performances. Cette
tendance se poursuit encore aujourd'hui.

L'apparition du génie logiciel est une réponse aux défis posés par la complexification
des logiciels et de l'activité qui vise à les produire.

2.Définitions et objectifs
Le ​génie logiciel est un ensemble des méthodes, des techniques et des outils dédiés à
la conception, au développement (production) et à la maintenance de logiciels de
qualité industrielle.

Les ​objectifs ​du génie logiciel consistent à rationaliser et à optimiser le processus de

production d'un logiciel. Les enjeux associés sont multiples :

1. Adéquation aux besoins du client.

2. Respect des délais de réalisation prévus.
3. Maximisation des performances et de la fiabilité.
4. Facilitation de la maintenance et des évolutions ultérieures.

Comme tout projet, la réalisation d'un logiciel est soumise à des exigences
contradictoires et difficilement conciliables.
Le génie logiciel a pour objectif de maximiser la surface du triangle en tenant compte
des priorités du client.

Un ​logiciel ​est composé :

● Des ​documents ​de gestion de projet.
● Une ​spécification ​décrivant la liste des fonctions à remplir par le logiciel, les
facteurs qualité du logiciel (portabilité, évolutivité, robustesse,...), les contraintes
(performances temporelles et spatiales, ...) et les interfaces avec son
environnement.
● Une ​conception ​décrivant la découpe de la spécification en modules (ou objets),
la description des interfaces entre ces modules (ou objets) et la description des
algorithmes mis en place.
● Un ​code source​ et un ​exécutable.

Le logiciel doit être le produit d’un processus de développement spécifique. Il a un

ensemble de caractéristiques qui le différencie des autres types de produits. Ces
caractéristiques sont :

● produit unique​ : conçu et fabriqué une seule fois, reproduit.

● Inusable :​ Défauts pas dus à l'usure mais proviennent de sa conception.
● Complexe ​:Le logiciel est fabriqué pour soulager l'humain d'un problème
complexe ; il est donc par nature complexe.
● Invisible ​: Fabrication du logiciel est une activité purement intellectuelle avec
une difficulté de perception de la notion de qualité du logiciel.
● Techniques non matures​ : Encore artisanal ( fait à la main) malgré les progrès.
 3.Principes du Génie logiciel
Le génie logiciel s’applique sur un ensemble de principes qui doivent guider la création
d’un produit logiciel, et plus généralement le travail d’un développeur. Les principes les
plus important du génie logiciel sont :

1. La séparation des responsabilités​ (​separation of concerns​)

Ce principe vise à organiser un logiciel en plusieurs sous-parties, chacune ayant une
responsabilité bien définie et unique.

Exemples :
- Une sous-partie qui s'occupe des affichages à l'écran participe ne devrait pas
comporter de traitements métier, ni de code en rapport avec l'accès aux
données.
- Un composant de traitements métier (calcul scientifique ou financier, etc) ne doit
pas s'intéresser ni à l'affichage des données qu'il manipule, ni à leur stockage.
- Une classe d'accès à une base de données (connexion, exécution de requêtes)
ne devrait faire ni traitements métier, ni affichage des informations.
- Une classe qui aurait deux raisons de changer devrait être scindée en deux
classes distinctes.

2. Réutilisation
Le principe de la réutilisation incite à exploiter les composants logiciels pré-fabriqués
tels que les librairies, pour faire face à la complexité des logiciels, les contraintes de
réalisation dans des délais de plus en plus courts, tout en maintenant le meilleur niveau
de qualité possible.

Exemple :
- Utiliser une librairie d’affichage 2D au lieu de développer une.

3. Encapsulation maximale
Ce principe de conception recommande d'exposer au reste de l'application que le strict
nécessaire pour que la sous-partie joue son rôle.

Exemples :
- Au niveau d'une classe, cela consiste à ne donner le niveau d'accessibilité
publique qu'à un nombre minimal de membres, qui seront le plus souvent des
méthodes.
 - Au niveau d'une sous-partie d'application composée de plusieurs classes, cela
consiste à rendre certaines classes privées afin d'interdire leur utilisation par le
reste de l'application.

4. Couplage faible
La définition du couplage est la suivante : "une entité (sous-partie, composant, classe,
méthode) est couplée à une autre si elle dépend d'elle", autrement dit, si elle a besoin
d'elle pour fonctionner.
un couplage fort tisse entre ses éléments des liens puissants qui la rendent plus rigide à
toute modification (on parle de "code spaghetti"). A l'inverse, un couplage faible permet
une grande souplesse de mise à jour. Un élément peut être modifié (exemple :
changement de la signature d'une méthode publique) en limitant ses impacts.
Le couplage peut également désigner une dépendance envers une technologie ou un
élément extérieur spécifique : un SGBD, un composant logiciel, etc.

5. Cohésion forte
Ce principe recommande de rassembler l’ensemble des éléments (composants,
classes, méthodes) ayant des rôles similaires ou dédiés à une même problématique.
Inversement, il déconseille de rassembler des éléments ayant des rôles différents.

Exemple :
- ajouter une méthode de calcul métier au sein d'un composant lié aux données
(ou à la présentation) est contraire au principe de cohésion forte.

4.Qualités attendues d’un logiciel

La qualité du logiciel est définie par son aptitude à satisfaire les besoins des utilisateurs.
Elle est définie comme "l'ensemble des attributs et caractéristiques d'un produit ou d'un
service qui portent sur sa capacité à satisfaire des besoins donnés". Une définition des
principaux facteurs de qualité d'un logiciel est proposée ci-dessous:

- Utilité: ​Adéquation entre Le besoin effectif de l'utilisateur et les fonctions offertes

par le logiciel.
- Utilisabilité: ​Effectivité, efficacité et satisfaction avec laquelle des utilisateurs
spéciaux accomplissent des objectifs spéciaux dans un environnement
particulier.
- Fiabilité: ​le logiciel est conforme à ses spécifications, les résultats sont ceux
attendus.
 - Interopérabilité, couplabilité : ​Un logiciel doit pouvoir interagir en synergie
avec d'autres logiciels.
- Performance : ​Les logiciels doivent satisfaire aux contraintes de temps
d'exécution.
- Portabilité : ​Un même logiciel doit pouvoir fonctionner sur plusieurs machines.
- Reutilisable.
- Maintenabilité

5.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 lla 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.

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 les activités suivantes :

1. Définition des besoins (Pourquoi?) :

Activités : il faut effectuer des consultations d'experts et d'utilisateurs potentiels et
réaliser des questionnaire d'observation de l'usager dans ses tâches :
● Pourquoi faut-il réaliser un logiciel?
● Y a-t-il de meilleures alternatives?
● Le logiciel sera-t-il satisfaisant pour les utilisateurs?
● Y a-t-il un marché pour le logiciel?
● A-t-on le budget, le personnel, le matériel nécessaire?

Productions :
● Cahier des charges (les « exigences »)
● Fonctionnalités attendues
● Contraintes non fonctionnelles
● Qualité, précision, optimalité, ...
● temps de réponse, contraintes de taille, de volume de traitement, …
 2. Analyse des besoins / spécification (Quoi?)
Activités : ​Définir précisément les fonctions que le logiciel doit réaliser ou fournir en
définissant les spécifications générales : Objectifs, contraintes (utilisation de matériels
et outils existants) et généralités à respecter ; les spécifications fonctionnelles :
description détaillé des fonctionnalités du logiciel et les spécifications d'interface :
description des interfaces du logiciel avec le monde extérieure (hommes, autres
logiciels, matériels...).
Productions :
● Dossier d'analyse
● Ébauche du manuel utilisateur
● Première version du glossaire

3. Codage et tests unitaires (Comment ?)

Activités : Définir la structure ou l’architecture du logiciel (décomposition en modules)
et la spécification des interfaces des modules, ensuite réaliser la conception détaillée
du logiciel en implémentant les algorithmes de chacune des procédures des modules et
les tester indépendamment les uns des autres.

Productions :
● Modules codés et testés
● Documentation de chaque module
● Résultats des tests unitaires
● Planning mis à jour

4. Vérification et validation
Activités : ​Les modules doivent être testés et intégrés suivant un plan d'intégration, de
plus le test de l'ensemble (modules intégrés) doit être réalisé conformément au plan de
tests. Il faut intégrer les différents modules avec validation / vérification de l’adéquation
de l’implantation, de la conception et de l’architecture avec le cahier de charge
(acceptation).

Productions :
● Logiciel testé
● Jeu de tests de non-régression
● Manuel d'installation : guide dans les choix d'installation
● Version finale du manuel utilisateur
● Manuel de référence : liste exhaustive de chaque fonctionnalité
 5. Maintenance

Activités : ​Utilisation en situation réelle, retour d’information des usagers, des

administrateurs, des gestionnaires…Il faut organiser une formation de l'utilisateur avec
une assistance technique et effectuer si nécessaire des maintenance correctives en cas
de non conformité aux spécifications, avec détection et correction des erreurs
résiduelles ; maintenance adaptative concernant la modification de l'environnement
(matériel, fournitures logicielles, outil, …) ou maintenance évolutive à cause de
changement des spécifications fonctionnelles du logiciel.

Productions :
● Logiciel corrigé
● Mises à jour, patch
● Documents corrigés.

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.

6.Modèles de cycle de vie d’un logiciel

Afin d'être en mesure d'avoir une méthodologie commune entre le client et la société de
service réalisant le développement, des modèles de cycle de vie ont été mis au point
définissant les étapes du développement ainsi que les documents à produire permettant
de valider chacune des étapes avant de passer à la suivante.

1. Le cycle de vie en Cascade

Adapté pour des projets de petite taille, et dont le domaine est bien maîtrisé.
 2. Le cycle de vie en V
Adapté pour des projets dont le domaine est bien maîtrisé

3. Le prototypage
Un Prototype est une version d'essai du logiciel. Généralement, un prototype est
développé pour tester les différents concepts et exigences ainsi que pour montrer aux
clients les fonctions que l'on veut mettre en œuvre.

4. Le modele incremental
Le modèle de développement incrémental consiste à concevoir et livrer au client un
sous-ensemble minimal et fonctionnel du système.

5. Le modèle en spirale
C’est modèle itératif ou à chaque itération on reproduit les mêmes étapes du cycle de
vie.
Chapitre 2. Modélisation avec UML

1.Introduction
Comme toutes les étapes du cycle de vie du logiciel, la modélisation est une phase
importante au développement du logiciel. C’est l’étape ou on définit l’architecture du
système logiciel à réaliser. Cette architecture aide à communiquer les besoins du client
d’une partie et symbolise un modèle de solution ou ce qu’on appelle un modèle.

1. Modèle
Un ​modèle ​est une simplification de la réalité qui permet de mieux comprendre le
système à développer. Un modèle permet de communiquer une solution acceptable du
système informatique. Cette communication est essentielle pour aboutir à une
compréhension commune aux différentes parties prenantes (les entités concernées par
le développement du logiciel) et précise d’un problème donné.

Un modèle est une abstraction d’objets de la réalité. C’est donc une simplification du
monde réel. La problématique consiste alors à trouver le bon niveau d’abstraction et à
exprimer les concepts du monde réel dans un langage assez abstrait mais aussi précis
qu’un langage de programmation pour que ce langage soit interprétable par un
programme informatique.

2. La modélisation
La modélisation est le processus de création d’un modèle représentatif du système réel
en utilisant des méthodes et des langages spécifiques à l’exemple de l’UML, Réseaux
de pétri, Merise, etc.

Les principes de modélisation sont​ :

- Maîtriser la complexité
- abstraire la réalité pour mieux comprendre le système à réaliser / réalisé
- Le modèle doit être relié au monde réel
- Un modèle peut être exprimé avec différents niveaux d’abstraction / raffinement
- Une seule « vue » du système n’est pas suffisante
Le modèle du système dans les premières phases du cycle de vie de logiciel est
nécessairement une simplification du système réel. Le processus de modélisation vise
à mieux cerner les limites du système à réaliser. Ensuite, les modèles sont de plus en
plus utilisés pour aboutir au code.

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

fonctionnement du système. Elle permet de maîtriser la complexité d’un système et
d’assurer sa cohérence.

La modélisation se fait à l’aide d’une méthode et outils. Les méthodes d’analyse et de

conception fournissent une méthodologie et des notations standards qui aident à
concevoir des logiciels de qualité.

3. La modélisation orientée objet

L’approche orientée objet considère le logiciel comme une collection d’objets dissociés,
identifiés et possédant des propriétés. Une propriété est soit un attribut (i.e. une donnée
caractérisant l’état de l’objet), soit une entité comportementale de l’objet (i.e. une
fonction). La fonctionnalité du logiciel émerge alors de l’interaction entre les différents
objets qui le constituent. L’une des particularités de cette approche est qu’elle
rapproche les données et leurs traitements associés au sein d’un unique objet.

Comme nous venons de le dire, un objet est caractérisé par plusieurs notions :

L’identité – L’objet possède une identité, qui permet de le distinguer des autres objets,
indépendamment de son état. On construit généralement cette identité grâce à un
identifiant découlant naturellement du problème (par exemple, un produit pourra être
repéré par un code, une voiture par un numéro de série, etc.)
Les attributs – Il s’agit des données caractérisant l’objet. Ce sont des variables
stockant des informations sur l’état de l’objet.
Les méthodes - ​Les méthodes d’un objet caractérisent son comportement, c’est-à-dire
l’ensemble des actions (appelées opérations) que l’objet est à même de réaliser. Ces
opérations permettent de faire réagir l’objet aux sollicitations extérieures (ou d’agir sur
les autres objets). De plus, les opérations sont étroitement liées aux attributs, car leurs
actions peuvent dépendre des valeurs des attributs, ou bien les modifier.

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. En résumé, l’architecture du système est dictée par la structure du problème.

4. UML

UML est un langage de modélisation orienté objet​, c’est-à-dire que toutes les entités
modélisées sont des objets ou se rapportent à des objets, par exemple : un objet
possède une structure de données (avec ce qui s’appelle des « attributs ») et des
comportements (avec ce qui s’appelle des « opérations »).

UML n’est pas une méthode. UML a été adopté par toutes les méthodes orientées
objet et est devenu le standard de l’industrie.

UML est un langage et possède les attributs d’un langage. Ainsi, étant graphique,
UML permet de visualiser le système réalisé ; le modèle est divisé en vues
sélectionnant les éléments pertinents puis en diagrammes de différents types. L’aspect
graphique d' UML retient le premier l’attention de ses utilisateurs. Comme pour tout
langage, les éléments du langage sont définis de manière précise, complète et sans
ambiguïté.

2.Éléments et mécanismes généraux

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.

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

2. Encapsulation
L’encapsulation consiste à masquer les détails d’implémentation d’un objet, en
définissant une interface. L’interface est la vue externe d’un objet, elle définit les
services accessibles (offerts) aux utilisateurs de l’objet.
L’encapsulation facilite l’évolution d’une application car elle stabilise l’utilisation des
objets : on peut modifier l’implémentation des attributs d’un objet sans modifier son
interface, et donc la façon dont l’objet est utilisé.

3. 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éristiques spécifiques ou d’en adapter certaines.
Plusieurs classes peuvent être généralisées en une classe qui les factorise, afin de
regrouper les caractéristiques communes d’un ensemble de classes.

Ainsi, la spécialisation et la généralisation permettent de construire des hiérarchies de

classes. L’héritage 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.

3.Les diagrammes UML

Le métamodèle UML fournit une panoplie d'outils permettant de représenter l'ensemble
des éléments du monde objet (classes, objets, ...) ainsi que les liens qui les relie.

Toutefois, étant donné qu'une seule représentation est trop subjective, UML fournit un
moyen astucieux permettant de représenter diverses projections d'une même
représentation grâce aux ​vues​.

Une vue est constituée d'un ou plusieurs ​diagrammes​. On distingue deux types de
vues :

● Les vues statiques​, c'est-à-dire représentant le système physiquement

○ diagrammes d'objets
○ diagrammes de classes
○ diagrammes de cas d'utilisation
○ diagrammes de composants
○ diagrammes de déploiement
● Les vues dynamiques​, montrant le fonctionnement du système
○ diagrammes de séquence
○ diagrammes de collaboration
○ diagrammes d'états-transitions
○ diagrammes d'activités
 Chapitre 3. Diagramme UML de cas
d’utilisation : vue fonctionnelle

1.Introduction
Bien souvent, la maîtrise d’ouvrage et les utilisateurs ne sont pas des informaticiens. Il
leur faut un moyen simple d’exprimer leurs besoins. C’est précisément le rôle des
diagrammes de cas d’utilisation qui permettent de recueillir, d’analyser et d’organiser
les besoins, et de recenser les grandes fonctionnalités d’un système. Il s’agit donc de la
première étape UML d’analyse d’un système.

Un diagramme de cas d’utilisation capture le comportement d’un système, d’un sous

système,d’une classe ou d’un composant tel qu’un utilisateur extérieur le voit. Les cas
d’utilisation permettent d’exprimer le besoin des utilisateurs d’un système, ils sont donc
une vision orientée utilisateur de ce besoin au contraire d’une vision informatique.

2.Éléments des diagrammes de cas d’utilisation

1. Acteur
Un acteur est l’idéalisation d’un rôle joué par une personne externe, un processus ou
une chose qui interagit avec un système. Il se représente par un petit bonhomme avec
son nom (i.e. son rôle) inscrit dessous.

Exemple de représentation d’un acteur

Il est également possible de représenter un acteur sous la forme d’un classeur
stéréotypé :

Exemple de représentation d’un acteur sous la forme d’un classeur

2. Cas d’utilisation
Un cas d’utilisation est une unité cohérente représentant une fonctionnalité visible de
l’extérieur. Il réalise un service de bout en bout, avec un déclenchement, un
déroulement et une fin, pour l’acteur qui l’initie. Un cas d’utilisation modélise donc un
service rendu par le système, sans imposer le mode de réalisation de ce service.

Un cas d’utilisation se représente par une ellipse contenant le nom du cas (un verbe à
l’infinitif), et optionnellement, au-dessus du nom, un stéréotype.

Exemple de représentation d’un cas d’utilisation

3. Représentation d’un diagramme de cas d’utilisation

Comme le montre la figure en dessous, la frontière du système est représentée par un

cadre. Le nom du système figure à l’intérieur du cadre, en haut. Les acteurs sont à
l’extérieur et les cas d’utilisation à l’intérieur.
 Exemple simplifié de diagramme de cas d’utilisation modélisant une borne d’accès à
une banque.

4. Relations dans les diagrammes de cas d’utilisation

1. Relations entre acteurs et cas d’utilisation

- Relation d’association

Diagramme de cas d’utilisation représentant un logiciel de partage de fichiers

Une relation d’association est chemin de communication entre un acteur et un cas

d’utilisation et est représenté un trait continu.

- Cas d’utilisation interne

Quand un cas n’est pas directement relié à un acteur, il est qualifié de cas d’utilisation
interne.

2. Relations entre cas d’utilisation

Il existe principalement deux types de relations :

 - les dépendances stéréotypées, qui sont explicitées par un stéréotype (les plus
utilisés sont l’inclusion et l’extension),
- et la généralisation/spécialisation.

Une dépendance entre deux cas d’utilisation se représente par une flèche avec un trait
pointillé. Si le cas A inclut ou étend le cas B, la flèche est dirigée de A vers B.

Le symbole utilisé pour la généralisation est un flèche avec un trait plein dont la pointe
est un triangle fermé désignant le cas le plus général. L’exemple suivante illustre les
différents type de relations dans un diagramme de cas d’utilisation :

Exemple de diagramme de cas d’utilisation

- Relation d’inclusion

Un cas A inclut un cas B si le comportement décrit par le cas A inclut le comportement

du cas B : le cas A dépend de B. Lorsque A est sollicité, B l’est obligatoirement, comme
une partie de A. Cette dépendance est symbolisée par le stéréotype « include ». Par
exemple, l’accès aux informations d’un compte bancaire inclut nécessairement une
phase d’authentification avec un identifiant et un mot de passe.

- Relation d’extension

On dit qu’un cas d’utilisation A étend un cas d’utilisation B lorsque le cas d’utilisation A
peut être appelé au cours de l’exécution du cas d’utilisation B. Exécuter B peut
éventuellement entraîner l’exécution de A : contrairement à l’inclusion, l’extension est
optionnelle. Cette dépendance est symbolisée par le stéréotype « extend ».

- Relation de généralisation

Un cas A est une généralisation d’un cas B si B est un cas particulier de A. Dans la
figure 2.7, la consultation d’un compte via Internet est un cas particulier de la
consultation. Cette relation de généralisation/spécialisation est présente dans la plupart
des diagrammes UML et se traduit par le concept d’héritage dans les langages orientés
objet.

3. Relations entre acteurs

La seule relation possible entre deux acteurs est la généralisation : un acteur A est une
généralisation d’un acteur B si l’acteur A peut être substitué par l’acteur B. Dans ce cas,
tous les cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai.

Relations entre acteurs

3. Modélisation des besoins avec UML
1. Comment identifier les acteurs ?
Les acteurs d’un système sont les entités externes à ce système qui interagissent
(saisie de données, réception d’information, . . .) avec lui. Les acteurs sont donc à
l’extérieur du système et dialoguent avec lui.

Chaque acteur doit être nommé. Ce nom doit refléter son rôle car un acteur représente
un ensemble cohérent de rôles joués vis-à-vis du système. Pour trouver les acteurs
d’un système, il faut identifier quels sont les différents rôles que vont devoir jouer ses
utilisateurs (ex : responsable clientèle, responsable d’agence, administrateur,
approbateur, . . .). Il faut également s’intéresser aux autres systèmes avec lesquels le
système va devoir communiquer comme :
– les périphériques manipulés par le système (imprimantes, hardware d’un distributeur
de billet, . . .) ;
– des logiciels déjà disponibles à intégrer dans le projet ;
– des systèmes informatiques externes au système mais qui interagissent avec lui, etc.

Pour faciliter la recherche des acteurs, on peut imaginer les frontières du système. Tout
ce qui est à l’extérieur et qui interagit avec le système est un acteur, tout ce qui est à
l’intérieur est une fonctionnalité à réaliser.

Vérifiez que les acteurs communiquent bien directement avec le système par émission
ou réception de messages.

2. Comment recenser les cas d’utilisation ?

L’ensemble des cas d’utilisation doit décrire exhaustivement les exigences

fonctionnelles du système. Chaque cas d’utilisation correspond donc à une fonction
métier du système, selon le point de vue d’un de ses acteurs.

Pour identifier les cas d’utilisation, il faut se placer du point de vue de chaque acteur et
déterminer comment et surtout pourquoi il se sert du système. Il faut éviter les
redondances et limiter le nombre de cas en se situant à un bon niveau d’abstraction.
Trouver le bon niveau de détail pour les cas d’utilisation est un problème difficile qui
nécessite de l’expérience.

Nommez les cas d’utilisation avec un verbe à l’infinitif suivi d’un complément. Par
exemple, un distributeur de billets aura probablement un cas d’utilisation retirer de
l’argent et non pas Distribuer de l’argent.
 Chapitre 4. Diagrammes UML de
classes et d’objets : vue statique

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 s’agit d’une vue statique car on ne tient pas compte du facteur temporel dans le
comportement du système. Les principaux éléments de cette vue statique sont les
classes et leurs relations : association, généralisation et plusieurs types de
dépendances, telles que la réalisation et l’utilisation.

2.Les classes
1. Notions de classe et d’instance de classe
Une instance est une concrétisation d’un concept abstrait.
Exemple :
- Vous êtes une instance du concept abstrait Etudiant ;

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 de marchandises ou services),
- des composants d’une application (ex : les boutons des boîtes de dialogue),
- des structures informatiques (ex : des tables de hachage),

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.

Exemple:
Si l'on considère que l'Homme (au sens être humain) est un concept abstrait, on peut
dire que la personne Mohamed est une instance de l'Homme. Si l'homme était une
classe, Mohamed en serait une instance : un objet.

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. Les propriétés d’un objet sont
soit des attributs, soit des opérations.

État d’un objet : Ce sont les attributs, réunis sous le terme générique de propriété
structurelle, 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.

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

d’une méthode est également appelée méthode.

Les attributs et les méthodes constituent donc les propriétés d’une classe (et de ses
instances).

3. Représentation graphique

Une classe est un classeur. Elle est représentée par un rectangle divisé en trois parties.
Le premier indique le nom de la classe, le deuxième ses attributs, et le troisième ses
opérations. Voir la figure suivante :
 Représentation UML d’une classe

4. Encapsulation, visibilité, interface

L’encapsulation est un mécanisme consistant à rassembler les données et les
méthodes au sein d’une structure en cachant l’implémentation de l’objet, c’est-à-dire en
empêchant l’accès aux données par un autre moyen que les services proposés. Ces
services accessibles (offerts) aux utilisateurs de l’objet définissent ce que l’on appelle
l’interface de l’objet (sa vue externe). L’encapsulation permet donc de garantir l’intégrité
des données contenues dans l’objet.

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.

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. Voir la figure suivante :

Bonnes pratiques concernant la manipulation des attributs.

 5. Relations entre classes

Généralisation et Héritage:
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é.

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

Association:
Une association est une relation entre deux classes (association binaire) ou plus
(association n-aire), qui décrit les connexions structurelles entre leurs instances. Une
association 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.
- Multiplicité : Une terminaison d’association peut posséder une multiplicité. Elle
est mentionnée à proximité de la terminaison.

Exemple d’association.

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

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.

Classe-association
Parfois, une association doit posséder des propriétés. Par exemple, l’association
Emploie entre une société et une personne possède comme propriétés le salaire et la
date d’embauche. En effet, ces deux propriétés n’appartiennent ni à la société, qui peut
employer plusieurs personnes, ni aux personnes, qui peuvent avoir plusieurs emplois. Il
s’agit donc bien de propriétés de l’association Emploie.

Les associations ne pouvant posséder de propriété, il faut introduire un nouveau

concept pour modéliser cette situation : celui 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.

Une classe-association est caractérisée par un trait discontinu entre la classe et

l’association qu’elle représente, voir la figure suivante :

Exemple de classe-association

Agrégation et composition
Une agrégation est une association qui représente une relation d’inclusion structurelle
ou comportementale d’un élément dans un ensemble. Graphiquement, on ajoute un
losange vide du côté de l’agrégat.
La signification de cette forme simple d’agrégation est uniquement conceptuelle. Elle ne
contraint pas la navigabilité ou les multiplicités de l’association. Elle n’entraîne pas non
plus de contrainte sur la durée de vie des parties par rapport au tout.

Exemple de relation d’agrégation et de 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 : la multiplicité du côté composite ne doit pas être
supérieure à 1 (i.e. 1 ou 0..1). Graphiquement, on ajoute un losange plein.
 3. Diagramme d’objets (object diagram)
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 figée de l’état d’un système à un
instant donné. Un diagramme d’objets peut être utilisé pour :
- illustrer le modèle de classes en montrant un exemple qui explique le modèle ;
- préciser certains aspects du système en mettant en évidence des détails
imperceptibles dans le diagramme de classes ;
- exprimer une exception en modélisant des cas particuliers ou des connaissances
non généralisables qui ne sont pas modélisés dans un diagramme de classe ;
- 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.

Représentation graphique
Graphiquement, un objet se pré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é.

Exemple de diagramme de classes et de diagramme d’objets associés.

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 diagramme d’objets, les relations du diagramme de classes deviennent des

liens. La relation de généralisation ne possède pas d’instance, elle n’est donc jamais
représentée dans un diagramme d’objets. Graphiquement, un lien se présente comme
une relation, mais, s’il y a un nom, il est souligné. Naturellement, on ne représente pas
les multiplicités.

4.Élaboration et implémentation d’un diagramme

de classes
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 substantifs du domaine.
- Trouver les associations entre les 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.
- Itérer et raffiner le modèle. Un modèle est rarement correct dès sa première
construction. La modélisation objet est un processus non pas linéaire mais
itératif.
5.Implémentation d’un diagramme de classe
1. Classe

2. Héritage simple

3. Association bidirectionnelle 1 vers 1

4. Association unidirectionnelle 1 vers 1
5. Association bidirectionnelle 1 vers plusieurs
6. Association unidirectionnelle 1 vers plusieurs

7. Association 1 vers N

8. Agrégations
9. Composition