GENIE LOGICIEL

A. BOUAMARI
bouamari@univ-setif.dz

Département d’informatique - UFA Sétif 1

Licence Informatique UFA Sétif 1- février 2021

 CHAPITRE 4
UML - MODELISATION DE LA STRUCTURE

4.1 Introduction

Les diagrammes de structures (voir chapitre 2 section 4.3) peuvent être répartis en

deux grandes catégories, les diagrammes de structure et des diagrammes d’architecture. Le

présent chapitre décrit les diagrammes de classes et d’objets qui sont utilisés pour la

modélisation de la structure statique de l’application. Les diagrammes de composants, de

déploiement et de packages sont, quant à eux, utilisés pour la modélisation des aspects liés

à l’architecture de l’application (voir chapitre 6).

Les diagrammes de classes et d’objets définissent quels sont les éléments impliqués

dans la réalisation des fonctionnalités du système et quelles sont leurs caractéristiques. Ces

éléments et les relations entre eux sont statiques, c'est-à-dire qu’ils ne changent pas au fil

du temps. Par exemple, les étudiants possèdent un nom et un numéro et suivent différentes

matières.

4.2 Diagramme d’objets

Sur la base des définitions du diagramme de classes, un diagramme d'objets associé

montre un aperçu concret de l'état du système à un point d'exécution spécifique. Ce type de

diagrammes visualise les instances de classes (i.e. les objets concrets) et les liens qui sont

définis entre ces instances.

Un objet possède une identité unique, un état ou des caractéristiques structurelles

(i.e. des valeurs concrètes affectées à ses attributs) et un comportement (i.e. les opérations

généralement utilisées dans le cadre d’interaction entre objets).

1
 Figure 1 : Diagramme d’objets

Le diagramme d'objets de la figure 1 montre un exemple de système contenant trois

objets étudiants : ab, am et fa caractérisés chacun par numéro d’inscription, nom, prénom et

date de naissance. Le système contient également trois cours : gl (Génie logiciel), se2

(Systèmes d’exploitation), et bd (Bases de données). Le cours gl se déroule dans la salle sc1

et le cours db dans la salle sc2. La salle n’est, cependant, pas précisée dans le cas du cours

bd. L'étudiant ab est inscrit aux deux cours gl et se2, etc.

4.3 Diagramme de classes

Le diagramme de classes définit une abstraction de haut niveau pour caractériser les

différents objets du système et les liens entre ces objets. Le diagramme est utilisé dans les

différentes phases du développement de systèmes logiciels, particulièrement les phases

d’analyse et de conception, et peut servir des objectifs de génération automatique du code

ou de documentation.

2
 Le niveau de détails ou d'abstraction du diagramme de classes est différent dans

chaque phase. Au cours de l’analyse, le rôle du diagramme de classes se limite à définir le

vocabulaire à utiliser et à développer une vue conceptuelle du système indépendante des

détails d’implémentation. Dans la phase de conception, le modèle d’analyse est étendu aux

détails techniques d’implémentation.

4.3.1 Classes

Une classe constitue le schéma de réalisation d'un ensemble d'objets similaires dans

le domaine d’étude. Les classes peuvent caractériser des éléments matériels (e.g. étudiants,

salle de cours) ou des éléments immatériels et des concepts abstraits (e.g. cours, séance,

groupes d’étudiants). Dans les langages de programmation orientés objet, les applications

sont créées sur la base des définitions de classes.

La figure 2 montre un exemple de classe UML et la définition correspondante de

classe Java.

Figure 2 : Exemple de correspondance entre classes UML-Java

3
 Les caractéristiques pertinentes des instances d'une classe sont décrites à travers la

définition des caractéristiques structurelles (attributs) et du comportement (opérations).

Les attributs permettent de stocker des informations communes pour toutes les instances

d’une classe, mais qui ont généralement des valeurs spécifiques pour chacune de ces

instances. Les opérations permettent aux objets de communiquer entre eux, d'agir et de

réagir.

4.3.2 Attributs

Un attribut possède un nom et peut avoir un type, une multiplicité, une valeur par

défaut, des propriétés supplémentaires et des modificateurs de visibilité.

Les types d'attributs possibles comprennent les types de données primitifs (e.g.

Integer, String), les types de données composites (e.g. Date, Enumération) ou des classes

définies par l'utilisateur. Il est aussi possible de définir des valeurs par défaut pour les

attributs afin que le système puisse les utiliser dans le cas où les valeurs de ces attributs

sont exigées et ne sont pas explicitement spécifiées.

Des propriétés supplémentaires de l'attribut peuvent être spécifiées entre accolades.

Par exemple, la propriété {readOnly} signifie que la valeur de l'attribut ne peut pas être

modifiée une fois qu'il a été initialisé.

La multiplicité d'un attribut indique le nombre de valeurs qu’un attribut peut avoir

ce qui permet de définir des ensembles ; il peut s’agir alors d’ensemble non-ordonnées et

sans duplications {unordred, unique}, d’ensemble multiple {unordred, non-unique},

d’ensemble ordonné {ordred, unique} ou de liste {ordred, non-unique}. La multiplicité est

représentée par un intervalle min..max entre crochets. S'il n'y a pas de limite supérieure

pour l'intervalle, celle-ci est exprimée avec un astérisque ∗ (e.g. [1..10],[1..*],[5]).

4
 La spécification d'une barre oblique avant le nom d'un attribut indique que la valeur

de cet attribut est dérivée des autres attributs. Par exemple, l'âge d'une personne, qui peut

être calculé à partir de sa date de naissance.

4.3.3 Opérations

Le diagramme de classe modélise uniquement les signatures des opérations que les

objets fournissent sans se préoccuper de la façon dont ces opérations sont implémentées.

En fait, des diagrammes UML spécifiques sont utilisés pour décrire le comportement des

objets en termes d’implémentations d’opérations (e.g. le diagramme d'activité).

Les opérations sont caractérisées par leur nom, leurs paramètres, le type de leur

valeur de retour ainsi que leurs modificateurs de visibilité.

4.3.4 Relations entre classes

Les rapports les plus courants entre classes peuvent avoir la forme de relations de

dépendance ("uses-a"), d’associations ("has-a") ou de relations d’héritage ("is-a").

4.3.4.1 Dépendance

La relation de dépendance exprime le fait qu’un objet client demande des services à

un objet serveur ; il est donc dépendant de cet objet. Ainsi, une classe cliente dépend d'une

autre classe serveur si ses méthodes utilisent ou manipulent des objets de cette classe. Dans

l’exemple d’une application e-commerce (figure 3), la classe Panier dépend de la classe

Produit car la classe Panier utilise la classe Produit comme paramètre de l’opération d'ajout

de nouvelles lignes produits (items). La dépendance est représentée par une flèche en

pointillé partant de la classe dépendante à la classe serveur.

5
 Figure 3 : Représentation UML de relation de dépendance

4.3.4.2 Associations

Une association entre classes représente une abstraction des liens - d’une même

sémantique - qui existent entre objets de ces classes. Les associations décrivent les classes

qui sont des partenaires de communication potentiels. Ces partenaires de communication

peuvent ainsi accéder aux attributs et opérations des autres classes si leurs attributs et

opérations ont les visibilités correspondantes.

Si l’association est dirigée (i.e. une flèche qui pointe sur l’une des deux classes), la

navigation unidirectionnelle d'un objet vers son objet partenaire est alors possible. La

navigabilité, ici, indique que l’objet connaît ses objets partenaires et peut donc accéder à

leurs attributs et opérations visibles. Une association bidirectionnelle permet d’avoir une

navigabilité dans les deux directions. Les langages de programmation objet implémentent

les associations par le biais de références aux objets associés. Une association peut être

également représentée de cette manière dans le diagramme de classes, c'est-à-dire comme

un attribut avec la multiplicité appropriée et le type correspondant à la classe des objets

partenaires (figure 4).

6
 Figure 4 : Représentations UML d’association et code Java correspondant

Les associations sont généralement caractérisées par une décoration avec sens de

lecture, des multiplicités et des rôles. Elles peuvent être binaires ou n-aires et peuvent

prendre différentes formes : association simple uni ou bidirectionnelle, agrégation ou

composition. Une association peut être porteuse d’information ; elle est définie alors par

une classe-association.

4.3.4.3 Héritage

L’héritage exprime une propagation automatique des données entre une classe

générale et une classe spéciale. La classe spéciale hérite de toutes les caractéristiques de la

classe générale (attributs et opérations visibles et associations), et peut même en définir de

nouvelles caractéristiques et de nouvelles implémentations des opérations héritées.

4.4 Développement de diagrammes de classes

UML définit de façon détaillée la syntaxe et la sémantique des éléments modèles des

diagrammes de classes mais ne décrit pas la manière dont ces diagrammes sont construits.

Des directives générales doivent être adoptées pour la création progressive de diagrammes

de classes associés aux phases d’analyse et de conception.

7
4.4.1 Classes d’analyse

Le modèle d’architectures MVC (Model-View-Controller) de la figure 5 définit trois

types de classes d’analyse pour répondre au premier principe de la conception de classes

(i.e. les principes SOLID), à savoir SRP (Single Responsibility Principle) : une classe ne doit

pas avoir plus qu’une responsabilité.

Figure 5 : Modèle MVC simplifié

Le modèle (entité) contient les données pertinentes du domaine, met en œuvre les

opérations nécessaires pour accéder et modifier ces données et notifie les vues associées en

cas de modification de ce contenu. Un modèle peut être associé à plusieurs vues ; chaque

vue montre une partie ou un aspect différent du contenu global du modèle et sert comme

interface communicant les événements externes aux contrôleurs correspondants. Les

contrôleurs prennent en charge les événements utilisateurs et apportent les modifications

appropriées au contenu du modèle.

La démarche générale d’analyse procède d’abord par l’identification, à partir de la

description du système, des classes entités (i.e. classes de données), des attributs et des

relations possibles entre classes.

8
 Les descriptions des interactions associées aux cas d’utilisation sont ensuite utilisées

pour l’identification (i) des classes de vue (i.e. affichage ou interface utilisateur), (ii) des

classes de contrôle (i.e. logique des traitements) et (iii) des opérations à mettre en œuvre.

4.4.1.1 Classes entités, associations et attributs

Dans un premier temps, le modèle d’analyse établit une représentation des éléments

significatifs de structure du domaine tout en négligeant les aspects liés à l’implémentation.

Ces éléments de structure représentent les concepts du domaine, les attributs des concepts

et les relations entre concepts.

Dans une description textuelle du domaine, les noms qui font référence aux données

pertinentes du système tels que étudiant, enseignant, cours, etc. indiquent généralement

des classes. En revanche, les noms qui font référence aux acteurs externes et aux valeurs

tels que administrateur, Ahmed ou bases de données et les expressions qui indiquent les

relations éventuelles entre classes représentent rarement des classes.

Les opérations et les fonctions sont repérées souvent par des verbes qui expriment

des suites d’actions à exécuter qui possède un événement déclencheur et qui produisent un

résultat.

Les noms et les expressions nominales sont utilisés alors pour définir la liste des

classes candidates. Cette liste est filtrée puis épurée afin de retenir uniquement les classes

entités ; les concepts faisant référence aux attributs, valeurs d’attributs, instances, acteurs,

associations ou opérations sont tous éliminés de cette liste. La démarche d’analyse procède

ensuite à l’identification des attributs des classes entités et des associations possibles entre

ces classes.

9
 Par exemple, dans le système de location de voitures, les assistants peuvent effectuer

des réservations de modèles de voitures (CarModel) pour des clients membres (Member).

Les clients membres sont identifiés par id et les modèles de voitures par name et price. Un

membre peut réserver plusieurs modèles de voitures et un modèle de voitures peut être

réservé par plusieurs membres. Une réservation (Reservation) est caractérisée par number

et date. La table 1 établit la liste des classes candidates et les classes entités résultantes.

Table 1 Table de classes candidates

Classe candidate Eliminée pour les raisons suivantes Classe entité

Member -- Member
CarModel -- CarModel
Reservation -- Reservation
price attribut CarModel
15/12/20 valeur d’attribut date Reservation
assistant acteur --
cm1 instance de classe CarModel
… … …

Les attributs sont ensuite systématiquement identifiés pour chacune des classes

entités. Les associations sont repérées à partir des expressions qui indiquent des rapports

entre classes. Par exemple, l’expression "un membre peut réserver plusieurs modèles de

voitures" détermine une association entre les classes Member et CarModel. Le diagramme

de la figure 6 montre les classes entités, leurs attributs et l’association correspondants à cet

exemple.

10
 Figure 6 : diagramme de classes initial

4.4.1.2 Classes de vues, classes de contrôles et opérations

Les interactions associées aux cas d’utilisation sont modélisées avec des diagrammes

d’interaction (diagramme de séquence ou diagramme de communication) qui représentent

les différents objets impliqués dans l’interaction, leurs types et les messages échangés entre

ces objets pour la réalisation d’un cas d’utilisation. Le diagramme de classes est étendu au

fur et à mesure aux nouveaux éléments (classes de vue, classes de contrôle, opérations) qui

peuvent être identifiés dans la réalisation des différents cas d’utilisation du système.

Figure 7 : Exemple d’interaction

11
 Le diagramme de la figure 7 montre la réalisation du cas d’utilisation "consulter liste

réservations". Ce diagramme identifie de nouvelles classes (MemberUI et ReservationCtrl)

et de nouvelles opérations (e.g. showReservation(), getSummary()). La figure 8 présente

l’ébauche du nouveau diagramme de classe après réalisation du cas d’utilisation "consulter

liste réservations".

Figure 8 : Ebauche du diagramme de classes

4.4.2 Classes de conception

Le modèle de conception étend le modèle d’analyse et établit une conception finale

de la solution logicielle tenant compte des choix techniques tels que le type d’application

(e.g. rich client, web, mobile), le type de déploiement (e.g. client-serveur) les technologies

adoptées (e.g. CGI avec servlets), les fonctionnalités système additionnelles (e.g. logging,

cache, authentification, autorisation, gestion des exceptions). L’activité de conception doit

permettre alors l’identification des classes additionnelles répondant à ces choix techniques

(e.g. servlets, classes d’accès aux données, classes protocole).

12