Cours UML ENSA 2017-2018 Ch1-3 PDF

UNIFIED MODELING LANGUAGE
Pr. Youssef GAHI
02/04/2018
ENSA DE KENITRA 1
UNIFIED MODELING LANGUAGE 2017-2018
OBJECTIFS
01 > INTRODUCTION 06 > DIAGRAMMES D'ÉTATS-

TRANSITIONS
02 > DIAGRAMMES DE CAS D’UTILISATION

07 > DIGRAMMES D'ACTIVITÉS
03 > DIAGRAMMES DE CLASSES

08 > DIAGRAMMES DE
COMMUNICATION
DIAGRAMMES DE
04 09
>
> DIAGRAMMES D’OBJETS COMPOSANTS ET DE
DÉPLOIEMENT
10
> BONNES PRATIQUES DE LA
05 > DIAGRAMMES DE SÉQUENCE MODÉLISATION OBJET
ENSA DE KENITRA 2
01 INTRODUCTION
UNIFIED MODELING LANGUAGE 2017-2018 ENSA DE KENITRA

INTRODUCTION AUX SI
 Un système d’information représente l’ensemble des éléments participant à la gestion,

stockage, traitement, transport et diffusion de l’information au sein d’une organisation.
 Rôle:
> Collecte d’informations
> Stockage de l’information
> Traitement de l’information
> Diffusion de l’information
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 4
LES DIFFÉRENTES PHASES DANS LE CYCLE DE VIE D’UN LOGICIEL
L’intégration et la
Cadrage de besoins
validation client
Conception
fonctionnelle et Formation et transfert
technique
Maintenance et
Réalisation
évolution
ENSA DE KENITRA 5
CADRAGE ET CONCEPTION
Phase 1 Phase 2
Cadrage de besoins Conception fonctionnelle et technique
 Dérouler des ateliers de cadrage de besoins  Etudier la faisabilité du besoin exprimé
 Impliquer les différents interlocuteurs métier (les  Dérouler des ateliers d’études et d’architecture
interlocuteurs concernés par le produit) pour
exprimer leur besoins.
 Définir les différents flux fonctionnels
 définir le produit à réaliser sur 5 axes
Objectifs > Les clients/utilisateurs du produit  Définir l’architecture globale du produit et les
> Leurs besoins différents flux entre les composants
> Les enjeux pour l’entreprise
> La proposition de valeur du produit  Choisir les technologies à adopter (avec l’aide du
> Les critères de succès quantifiables responsable des développements)
 Prioriser les besoins pour respecter le budget
 Document de cadrage  Rapport de faisabilité

 Cahier de spécification  Dossier fonctionnel
Livrables  Contrat commercial (Engagement)  Dossier d’architecture
ENSA DE KENITRA 6
RÉALISATION ET INTÉGRATION
Phase 3 Phase 4
Réalisation L’intégration et la validation client
 Traduction dans un langage de programmation  Vérifier la plateforme de production chez le client

des différents modules
 Installer le produit
 Implémentation de l’architecture définie
 Dérouler le cahier de recette pour valider
 Respect des normes de qualité logiciel l’installation dans la présence d’un représentant
de chez le client
Objectifs
 Revues des spécifications
 Test et validation en interne du cahier de recette
 Rédaction de la documentation d’utilisation et

d’installation
 CD d’installation  Les logs d’installation

 Documentation  Un rapport d’installation
Livrables  Un PV (réception) signé par le client
ENSA DE KENITRA 7
FORMATION ET ÉVOLUTION
Phase 5 Phase 6
Formation Maintenance et évolution
 La formation peut prendre plusieurs formes:  Corrections des erreurs
 Les sessions de formation : elles s’appuient sur  Prise en compte de nouveaux cas d'utilisation
l’alternance d’un enseignement théorique et des
mises en pratiques immédiates
 Ajout de nouvelles fonctionnalités
 Le transfert de compétences : il est

Objectifs principalement dédié aux équipes techniques
d’exploitation ou de maintenance
 L’accompagnement en production : il se met en

place lorsque la montée en charge et/ou le
déploiement représente(nt) un enjeu majeur et
critique du projet.
 Support de formation  Des patch/hotfix dans le cas de la maintenance

 Rapport d’accompagnement  De nouveaux programmes d’installations dans le
Livrables cas des évolutions.
ENSA DE KENITRA 8
CONCEPTION
 Processus créatif pour la mise au point d’un logiciel
 Permet de donner une architecture au logiciel en le découpant en briques, chacune en

charge de fonctionnalités différentes.
 3 types de conception
> Conception fonctionnelle
+ L’analyse fonctionnelle est une démarche qui « consiste à rechercher et à
caractériser les fonctions offertes par un produit pour satisfaire les besoins de
son utilisateur. »
> Conception Architecturelle
+ Définition de la structure interne du logiciel
+ Décomposition en composants de taille maîtrisable
+ Définition des interfaces et interactions entre composants
> Conception détaillée
+ Définition du rôle de chacun des composants
+ Définition des sous-composants
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 9
LES DIFFÉRENTES VUES
Vue métier
Les processus métier et leurs
activités, l’organisation
Vu
Vue fonctionnelle
Les fonctions du SI supportant les
processus métier
Vue applicative
Les blocs applicatifs, les
messages, les données
Vue technique
Les matériels,les logiciels,les
technologies
CENTRE DE DE
ENSA TRANSMISSION
KENITRA
MODÉLISATION
 Support de la conception
 Formalisation de la solution, en utilisant des notations ou des règles connues
 Permet de réduire la complexité d’un phénomène

> Éliminer les détails non significatifs
> Refléter ce qui est important pour la compréhension et prédiction du phénomène
modélisé
 Création d’un Modèle
> Représentation abstraite et simplifiée d’une entité du monde réel en vue de le
décrire, de l’expliquer ou de le prévoir
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 11
MODÉLISATION
 Il est naturellement trop difficile de réaliser un besoin a partir des représentations

mentales.
 Il faut tout d’abord passer par des modèles et représentations schématiques afin de
réaliser un besoin cadré.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 12
MODÈLE
 Un modèle est une représentation abstraite de la réalité qui exclut certains détails du
monde réel.
> Il 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épendent des objectifs du modèle.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 13
MÉTHODE ET LANGAGE
 Méthode de conception
> Description normative des étapes de la modélisation
> Exemple: Merise
> Problème:
+ Existence de plusieurs cas particuliers  difficulté de représenter une méthode
exhaustive
 Langage de modélisation
> Langage graphique pour représenter, communiquer les divers aspects d’un système
d’information
> Possède un vocabulaire et des règles qui permettent de combiner les mots afin de
communiquer
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 14
LANGAGES DE MODÉLISATION
 Un langage de modélisation doit définir :

> La sémantique des concepts ;
> Une notation pour la représentation de concepts ;
> Des règles de construction et d'utilisation des concepts.
 Des langages à différents niveaux de formalisation

> Langages formels (Z,B,VDM) : le plus souvent mathématiques, au
grand pouvoir d'expression et permettant des preuves formelles sur les
spécifications ;
> Langages semi-formels (MERISE, UML...) : le plus souvent
graphiques, au pouvoir d'expression moindre mais plus faciles d'emploi.
 L'industrie du logiciel dispose de nombreux langages de modélisation :

> Adaptés aux systèmes procéduraux (MERISE...) ;
> Adaptés aux systèmes temps réel (ROOM, SADT...) ;
> Adaptés aux systèmes à objets (OMT, Booch, UML...).
 Le rôle des outils (Ateliers Génie Logiciel) est primordial pour

l'utilisabilité en pratique des langages de modélisation.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 15
MODÉLISATION PAR DÉCOMPOSITION FONCTIONNELLE
 Approche descendante :
> Décomposer la fonction globale jusqu'à obtenir des fonctions simples à
appréhender et donc à programmer.
C'est la fonction qui donne la forme du système.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 16
MODÉLISATION ORIENTÉE OBJETS
 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 une décomposition
fonctionnelle.
C'est la structure du système lui donne sa forme.
 On peut partir des objets du domaine (briques de base) et remonter vers le système
global : approche ascendante.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 17
UNIFIED MODELING LANGUAGE
 Au milieu des années 90, les auteurs de Booch, OOSE et OMT ont décidé de créer un
langage de modélisation unifié avec pour objectifs :
> Modéliser un système des concepts à l'exécutable, en utilisant les techniques
orientée objet ;
> Réduire la complexité de la modélisation ;
> Utilisable par l'homme comme la machine :
+ Représentations graphiques mais disposant de qualités formelles suffisantes
pour être traduites automatiquement en code source ;
+ Ces représentations ne disposent cependant pas de qualités formelles
suffisantes pour justifier d'aussi bonnes propriétés mathématiques que des
langages de spécification formelle (Z, VDM...).
 Officiellement UML est né en 1994.
 UML v2.0 date de 2005. Il s'agit d'une version majeure apportant des innovations radicales
et étendant largement le champ d'application d'UML.
 La dernière version v2.5.1 a été publiée en Décembre 2017.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 18
BRIQUES DE BASE D’UML
 Les éléments
> Ce sont les abstractions essentielles au modèle.
 Les relations
> Les relations expriment les liens existants entre les différents éléments.
 Les diagrammes
> Un diagramme est une représentation visuelle de l’ensemble des éléments qui
constituent le système
> Ils servent à visualiser un système sous différents angles (utilisateur, administrateur
par ex.)
> Dans les systèmes complexes, un diagramme ne fournit qu’une vue partielle du
système
+ L’ensemble des diagrammes réunis permet d’obtenir une vue globale du système
à concevoir
+ Chaque diagramme va permettre de modéliser ou spécifier une vue (spécificité)
du système à concevoir
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 19
LES 4+1 VUES
 Vue des cas d’utilisation

> Description du modèle vu par les acteurs du système
> Besoins attendus pour chaque acteur
> Le QUOI et le QUI
 Vue logique
> Définition du système vu de l’intérieur
> COMMENT satisfaire les besoins des acteurs
 Vue d’implémentation
> Dépendances entre les modules
 Vue des processus

> Vue temporelle et technique
> Mise en oeuvre des notions de tâches concurrentes, synchronisation…
 Vue de déploiement
> Position géographique et architecture physique de chaque élément
> Le OÙ
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 20
LES 4+1 VUES
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 21
DIAGRAMMES D’UML 2
 Diagrammes structurels / 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 / 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)
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 22
02 DIAGRAMMES DE CAS
D’UTILISATION

MODÉLISATION DES BESOINS
 Avant de développer un système, il faut savoir précisément à QUOI il devra servir,

c’est a dire à quels besoins il devra répondre.
 Modéliser les besoins permet de :

> Faire l'inventaire des fonctionnalités attendues ;
> Organiser les besoins entre eux, de manière à faire apparaître des relations
(réutilisations possibles, ...).
 Avec UML, on modélise les besoins au moyen de diagrammes de cas d'utilisation.
 Le diagramme des Cas d’Utilisation:

> Le diagramme fonctionnel d’UML
> Un moyen pour spécifier les usages/fonctionnalités d'un système
> Représente les interactions entre les utilisateurs et le système
> Une représentation graphique (diagramme) accompagnée par une description
textuelle
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 24
EXEMPLE DE DIAGRAMME DE CAS D'UTILISATION
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 25
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.
 Dans le cas où l'on désire présenter les attributs ou les opérations du cas d'utilisation, il
est préférable de le représenter sous la forme d'un classeur stéréotypé << use case >>
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 26
ACTEURS ET CAS D'UTILISATION
 Un acteurs est une entité extérieure au système modélisé, et qui interagit directement
avec lui.
 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.
 Il est également possible de représenter un acteur sous la forme d'un classeur

stéréotypé << actor >>.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 27
ACTEURS PRINCIPAUX ET SECONDAIRES
 Un acteur est qualifié de principal pour un cas d'utilisation lorsque ce cas rend service
à cet acteur.
 Les autres acteurs sont alors qualifiés de secondaires.
 Un cas d'utilisation a au plus un acteur principal. Un acteur principal obtient un résultat

observable du système tandis qu'un acteur secondaire est sollicité pour des
informations complémentaires.
 En général, l'acteur principal initie le cas d'utilisation par ses sollicitations.
 Le stéréotype << primary >> vient orner l'association reliant un cas d'utilisation à son
acteur principal, le stéréotype << secondary >> est utilisé pour les acteurs
secondaires
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 28
IDENTIFICATION DES ACTEURS
 Les principaux acteurs sont les utilisateurs du système.
 Un acteur correspond à un rôle, pas à une personne physique.
 Une même personne physique peut être représentée par plusieurs acteurs si elle a
plusieurs rôles.
 Si plusieurs personnes jouent le même rôle vis-à-vis du système, elles seront

représentées par un seul acteur.
 En plus des utilisateurs, les acteurs peuvent être :

> Des périphériques manipulés par le système (imprimantes...) ;
> 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 se fonde sur les frontières du système.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 29
RELATIONS ENTRE CAS D'UTILISATION EN ACTEURS
 Une relation d'association est chemin de communication entre un acteur et un cas

d'utilisation et est représenté un trait continu
 Les acteurs impliqués dans un cas d'utilisation lui sont liés par une association.
 Un acteur peut utiliser plusieurs fois le même cas d'utilisation.
 Lorsqu'un acteur peut interagir plusieurs fois avec un cas d'utilisation, il est possible
d'ajouter une multiplicité sur l'association du côté du cas d'utilisation.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 30
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) ;
> la généralisation/spécialisation.
 Une dépendance se représente par une flèche avec un trait pointillé. Si le cas A inclut
ou étend le cas 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.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 31
RELATIONS ENTRE CAS D'UTILISATION
 Inclusion : le cas A inclut le cas B (B est une partie obligatoire de A).
 Extension : le cas B étend le cas A (B est une partie optionnelle de A).
 Généralisation : le cas A est une généralisation du cas du cas B (B est une sorte de
A).
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 32
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 >>.
 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
 Les inclusions permettent essentiellement de factoriser une partie de la description
d'un cas d'utilisation qui serait commune à d'autres cas d'utilisation.
 Il ne faut surtout pas abuser de

ce type de décomposition : il
faut éviter de réaliser du
découpage fonctionnel d'un cas
d'utilisation en plusieurs sous-
cas d'utilisation pour ne pas
retomber dans le travers de la
décomposition fonctionnelle.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 33
RELATION D'EXTENSION
 La relation d'extension est probablement la plus utile, car elle a une sémantique qui a
un sens du point de vue métier au contraire des deux autres qui sont plus des artifices
d'informaticiens.
 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 >>
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 34
DÉPENDANCES D'INCLUSION ET D'EXTENSION
 Les inclusions et les extensions sont représentées par des dépendances.

> Lorsqu'un cas B inclut un cas A, B dépend de A.
> Lorsqu'un cas B étend un cas A, B dépend aussi de A.
> On note toujours la dépendance par une flèche pointillée B ---> A qui
se lit <<B dépend de A>>
 Lorsqu'un élément A dépend d'un élément B, toute modification de B sera susceptible

d'avoir un impact sur A.
 Les <<incude>> et les <<extend>> sont des stéréotypes (entre guillemets) des
relations de dépendance.
 Le sens des èches indique le dépendance, pas le sens de la relation d'inclusion.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 35
RÉUTILISABILITÉ AVEC LES INCLUSIONS ET LES EXTENSIONS
 Les relations entre cas permettent la réutilisabilité du cas <<s'authentifiier>> : il sera

inutile de développer plusieurs fois un module d'authentification.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 36
DÉCOMPOSITION GRÂCE AUX INCLUSIONS ET AUX
EXTENSIONS
 Quand un cas est trop complexe (faisant intervenir un trop grand nombre d'actions), on
peut procéder à sa décomposition en cas plus simples.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 37
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.
 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.
 La flèche pointe vers l'élément général.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 38
RELATIONS ENTRE ACTEURS
 Une seule relation possible : la généralisation.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 39
CONDITIONS D’UNE RELATION
 Il est possible de mentionner les conditions nécessaires pour une relation a l’interieur
d’un diagramme de cas d’utilisations.
 Graphiquement, la condition est exprimée sous la forme d'une note.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 40
RECENSER LES CAS D'UTILISATION
 Il n'y a pas une manière mécanique et totalement objective de repérer les cas
d'utilisation.
> Il faut se placer du point de vue de chaque acteur et déterminer comment il se sert
du système, dans quels cas il l'utilise, et à quelles fonctionnalités il doit avoir accès.
> Il faut éviter les redondances et limiter le nombre de cas en se situant au bon niveau
d'abstraction (par exemple, ne pas réduire un cas à une seule action).
> Il ne faut pas faire apparaître les détails des cas d'utilisation, mais il faut rester au
niveau des grandes fonctions du système.
Trouver le bon niveau de détail pour les cas d'utilisation est un problème
difficile qui nécessite de l'expérience.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 41
DESCRIPTION DES CAS D'UTILISATION
 Le diagramme de cas d'utilisation décrit les grandes fonctions d'un système du point de
vue des acteurs, mais n'expose pas de façon détaillée le dialogue entre les acteurs et
les cas d'utilisation.
 Un simple nom est tout à fait insuffisant pour décrire un cas d'utilisation.
Chaque cas d'utilisation doit être documenté pour qu'il n'y ait
aucune ambiguïté concernant son déroulement et ce qu'il
recouvre précisément.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 42
DESCRIPTION TEXTUELLE
Identification
Nom du cas : Payer CB

Objectif : Détailler les étapes permettant à
client de payer par carte bancaire
Acteurs : Client, Banque (secondaire)
Date : 18/09
Responsables : Toto
Version : 1.0
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 43
 Séquencements :
> Le cas d'utilisation commence lorsqu'un client demande le paiement par carte
bancaire
> Préconditions
+ Le client a validé sa commande
> Enchaînement nominal
+ 1. Le client saisit les informations de sa carte bancaire
+ 2. Le système vérifie que le numéro de CB est correct
+ 3. Le système vérifie la carte auprès du système bancaire
+ 4. Le système demande au système bancaire de débiter le client
+ 5. Le système notifie le client du bon déroulement de la transaction
> Enchaînements alternatifs
+ 1 En (2) : si le numéro est incorrect, le client est averti de l'erreur, et invité à
recommencer
+ 2 En (3) : si les informations sont erronées, elles sont redemandées au client
> Post-conditions
+ La commande est validée
+ Le compte de l'entreprise est crédité
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 44
 Rubriques optionnelles
> Contraintes non fonctionnelles :
+ Fiabilité : les accès doivent être sécurisés
+ Confidentialité : les informations concernant le client ne doivent pas être
divulgués
> Contraintes liées à l'interface homme-machine :
+ Toujours demander la validation des opérations bancaires
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 45
03 DIAGRAMMES DE CLASSES

OBJECTIF
 Les diagrammes de cas d'utilisation modélisent à QUOI sert le système.
 le diagramme de cas d'utilisation montre un système du point de vue des acteurs
 Le système est composé d'objets qui interagissent entre eux et avec les acteurs pour
réaliser ces cas d'utilisation.
 Les diagrammes de classes permettent de spécifier la structure et les liens entre les
objets dont le système est composé.
 Le diagramme de classes montre la structure interne du système.
 Le diagramme de classes permet de fournir une représentation abstraite des objets du

système qui vont interagir pour réaliser les cas d'utilisation
 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.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 47
EXEMPLE DE DIAGRAMME DE CLASSES
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 48
CONCEPTS ET INSTANCES
 Une instance est la concrétisation d'un concept abstrait.

> Concept : Stylo
> Instance : le stylo que vous utilisez à ce moment précis est une instance du concept
stylo : il a sa propre forme, sa propre couleur, son propre niveau d'usure, etc.
 Un objet est une instance d'une classe

> Classe : Vidéo
> Objets : Film, Spectacle, etc.
> Une classe spécifie la manière dont tous les objets de même type seront décrits
(désignation, label, auteur, etc).
Une classe est une représentation d’un type d'objets concrets.
 Un lien est une instance d'association.

> Association : Concept avis d'internaute qui lie commentaire et article
> Lien : instance [Jean avec son avis négatif], [Paul avec son avis positif]
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 49
REPRÉSENTATION GRAPHIQUE
D’UNE CLASSE
 Une classe est la description d'un ensemble d'objets ayant une sémantique, des
attributs, des méthodes et des relations en commun. Elle spécifie l'ensemble des
caractéristiques qui composent des objets de même type.
 Une classe est un classeur. Elle est représentée par un rectangle divisé en trois à cinq
compartiments
 Le premier indique le nom de la classe
 Le deuxième ses attributs.
 Le troisième compartiment est réservé

aux opérations de la classe.
 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.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 50
PROPRIÉTÉS : ATTRIBUTS ET OPÉRATIONS
 Les attributs et les opérations sont les propriétés d'une classe. Leur nom commence
par une minuscule.
> Un attribut décrit une donnée de la classe.
+ Les types des attributs et leurs initialisations ainsi que les modificateurs d'accès
peuvent être précisés dans le modèle
+ Les attributs prennent des valeurs lorsque la classe est instanciée : ils sont en
quelque sorte des variables attachées aux objets.
> Une opération est un service offert par la classe (un traitement que les objets
correspondant peuvent effectuer).
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 51
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.
 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érent 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.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 52
ENCAPSULATION, VISIBILITÉ, INTERFACE
 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.
 Dans une classe, le marqueur de visibilité se situe au niveau de chacune de ses

caractéristiques (attributs, terminaisons d'association et opération). Il permet d'indiquer si
une autre classe peut y accéder.
 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.
 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 d'opérations
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 53
EXEMPLE D'ENCAPSULATION
 Les modificateurs d'accès sont également applicables aux opérations.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 54
COMPARTIMENT DU NOM DE LA 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>], ... } ]
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 55
MÉTALANGAGE
 []:
> les crochets indiquent que ce qui est à l'intérieur est optionnel ;
 <>:
> les signes inférieur et supérieur indiquent que ce qui est à l'intérieur est plus ou
moins libre ; par exemple, la syntaxe de déclaration d'une variable
comme compteur : int est <nom_variable> : <type> ;
 '':
> les cotes sont utiles quand on veut utiliser un métacaractère comme un caractère ;
par exemple, pour désigner un crochet ([) il faut écrire '[», car [ est un métacaractère
ayant une signification spéciale ;
 …:
> permet de désigner une suite de séquence de longueur non définie, le contexte
permettant de comprendre de quelle suite il s'agit.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 56
COMPARTIMENT DES 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 nom, un type de données, une visibilité
et peut être initialisée.
 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ée prédéfini.
 La multiplicité (<multiplicité>) d'un attribut précise le nombre de valeurs que l'attribut
peut contenir. Lorsqu'une 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}).
ENSA DE KENITRA 57
COMPARTIMENT DES ATTRIBUTS
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. 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é.
ENSA DE KENITRA 58
COMPARTIMENT DES OPÉRATIONS
Méthode de la classe
Une opération est définie par son nom ainsi que par les types de ses paramètres
et le type de sa valeur de retour.
 Dans une classe, une opération (même nom et mêmes 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.
 La déclaration d'une 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_1>, ... , <paramètre_N>]) : [<type_renvoyé>] [{<propriétés>}]
 La syntaxe de la liste des paramètres est la suivante :

> nomClasse1 nomParam1 , ... , nomClasseN nomParamN
 Les propriétés (<propriétés>) correspondent à des contraintes

ou à des informations complémentaires comme les exceptions,
les préconditions, les postconditions ou encore l'indication
qu'une méthode est abstraite (mot-clef abstract), etc.
ENSA DE KENITRA 59
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.
 Une méthode de classe ne peut manipuler que des attributs de classe et ses propres
paramètres.
 Graphiquement, une méthode de classe est soulignée.
ENSA DE KENITRA 60
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 contient une méthode abstraite non encore réalisée.
 On ne peut instancier une classe abstraite : elle est vouée à se spécialiser. 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. Pour indiquer
qu'une classe est abstraite, il faut ajouter le mot-clef abstract devant son nom.
ENSA DE KENITRA 61
INTERFACE
 Le rôle d'une interface est de regrouper un ensemble d'opérations assurant un service

cohérent offert par un classeur et une classe en particulier.
 Une interface est dénie comme une classe, avec les mêmes compartiments. On ajoute
le stéréotype interface avant le nom de l'interface.
 On utilise une relation de type réalisation entre une interface et une classe qui
l'implémente.
 Les classes implémentant une interface doivent implémenter toutes les opérations
décrites dans l'interface
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 62
CLASSE CLIENTE D'UNE INTERFACE
 Quand une classe dépend d'une interface (interface requise) pour réaliser ses
opérations, elle est dite classe cliente de l'interface.
 On utilise une relation de dépendance entre la classe cliente et l'interface requise.

Toute classe implémentant l'interface pourra être utilisée.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 63
EXEMPLE D'INTERFACE
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 64
RELATIONS ENTRE CLASSES
 Il existe 4 types de relations possibles entre les classes:

> Association
> Aggregation
> Composition
> Généralisation/Spécialisation
 Une association représente une relation sémantique entre les objets d'une classe.
 Une relation d'agrégation décrit une relation de contenance ou de composition.
 Une relation d'héritage est une relation de généralisation/spécialisation permettant

l'abstraction.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 65
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 indique donc qu'il peut y avoir des liens entre des instances des classes
associées.
 Une association est une relation structurelle entre objets.

> Une association est souvent utilisée pour représenter les liens possibles entre objets
de classes données.
> Elle est représentée par un trait entre classes.
> Elle est souvent dirigée par une flèche
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 66
MULTIPLICITÉS DES ASSOCIATIONS
 La notion de multiplicité permet le contrôle du nombre d'objets intervenant dans chaque

instance d'une association.
> Exemple : un article n'appartient qu'à une seule catégorie (1) ; une catégorie
concerne plus de 0 articles, sans maximum (*).
 La syntaxe est MultMin..MultMax.

> << * >> à la place de MultMax signifie <<plusieurs>> sans préciser de nombre.
> << n..n >> se note aussi <<n>> et << 0..*>> se note <<*>>
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 67
NAVIGABILITÉ D'UNE ASSOCIATION
 La navigabilité permet de spécifier dans quel(s) sens il est possible de traverser

l'association à l'exécution.
 On restreint la navigabilité d'une association à un seul sens à l'aide d'une flèche.
> Exemple : Connaissant un article on connaît les commentaires, mais pas l'inverse.
 On peut aussi représenter les associations navigables dans un seul sens par des
attributs.
> Exemple : En ajoutant un attribut avis Internaute de classe Commentaire à la
place de l'association.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 68
ASSOCIATION UNIDIRECTIONNELLE DE 1 VERS 1
 La flèche indique ici que la relation est uni-directionnelle : les objets de classe Client
connaissent ceux de la classe Adresse auxquels il sont liés, mais pas l’inverse.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 69
IMPLÉMENTATION
public class Adresse {

...
}
public class Client {

private Adresse livraison ;
public void setAdresse ( Adresse adresse ){
this.livraison = adresse ;
}
public Adresse getAdresse (){

return livraison ;
}
}
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 70
ASSOCIATION BIDIRECTIONNELLE DE 1 VERS 1
 L’absence de flèche indique ici que l’on peut accéder aux adresses à partir des clients
qui leur sont liés, et inversement.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 71
IMPLÉMENTATION
public class Client {

Adresse facturation ;
public void setAdresse ( Adresse uneAdresse ){
if( uneAdresse != null ){
this.facturation = uneAdresse ;
facturation . client = this ; // correspondance
}
}
}
public class Adresse {
Client client ;
public void setClient ( Client unClient ){
this . client = client ;
client.facturation = this ; // correspondance
}
}
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 72
MULTIPLICITÉS
 Les multiplicités permettent de contraindre le nombre d’objets intervenant dans les

instanciations des associations. On en place de chaque côté des associations.
> Une multiplicité d’un côté spécifie combien d’objets de la classe du côté considéré
sont associés à un objet donné de la classe de l’autre côté.
> Syntaxe : min..max, où min et max sont des nombres représentant respectivement
les nombre minimaux et maximaux d’objets concernés par l’association.
 Ici, le 1..5 s’interprète comme à un objet donné de la classe Article,

on doit associer au minimum 1 objet de la classe Categorie et on peut en associer au
maximum 5
 Certaines écritures possibles :
> * à la place de max signifie plusieurs sans préciser de nombre.
> n..n se note aussi n pour exactement n
> 0..* se note aussi *
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 73
RÔLES
 On peut donner à une classe un rôle dans uns association.
 C’est surtout utile quand plusieurs associations concernent les mêmes classes en
qu’en conséquence, de mêmes objets peuvent être liés par des modalités différentes.
 Ici, des adresses peuvent être liées aux clients :

> Les adressers jouent le rôle d’adresses de livraison ou d’adresses de facturation
> Rien n’empêche qu’une adresse soit à la fois une adresse de livraison et un adresse
de facturation
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 74
NAVIGABILITÉ
 La navigabilité indique s'il est possible de traverser une association. On représente

graphiquement la navigabilité par une flèche du côté de la terminaison navigable et on
empêche la navigabilité par une croix du côté de la terminaison non navigable.
 Par défaut, une association est navigable dans les deux sens.
 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.
Inversement, la terminaison du côté de la classe Produit est navigable : chaque objet
commande contient une liste de produits.
 Implicitement, ces trois notations ont la même sémantique.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 75
ASSOCIATION UNIDIRECTIONNELLE DE 1 VERS *
 Une classe article contient un type de la classe commentaire sous forme d’une liste de
commentaires, mais pas l’inverse.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 76
IMPLEMENTATION
public class Commentaire {

}
public class Article {

private Vector avisInternaute = new Vector ();
public void addCommentaire ( Commentaire commentaire ){
avisInternaute.addElement ( commentaire );
}
public void removeCommentaire ( Commentaire comment){
avisInternaute.removeElement (comment);
}
}
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 77
ASSOCIATIONS RÉFLEXIVES
 L'association la plus utilisée est l'association binaire (reliant deux classs).
 Parfois, les deux extrémités de l'association pointent vers le même classeur. Dans ce
cas, l'association est dite réfexive .
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 78
CLASSE-ASSOCIATION
 Une association peut être raffinée et avoir ses propres attributs, qui ne sont disponibles
dans aucune des classes qu'elle lie.
 Comme, dans le modèle objet, seules les classes peuvent avoir des attributs, cette
association devient alors une classe appelée <<classe-association>> .
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 79
ASSOCIATIONS N-AIRES
 Une association n-aire lie plus de deux classes.

> Notation avec un losange central pouvant éventuellement accueillir une classe-
association.
> La multiplicité de chaque classe s'applique à une instance du losange.
Les associations n-aires sont peu fréquentes et concernent surtout les cas
où les multplicités sont toutes <<*>> Dans la plupart des cas, on utilisera
plus avantageusement des classes-association ou plusieurs relations binaires.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 80
ÉQUIVALENCES
 Parfois, l'information véhiculée par une classe-association peut être véhiculée sans
perte d'une autre manière
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 81
ASSOCIATION DE TYPE AGRÉGATION
 Une association simple entre deux classes représente une relation structurelle entre
pairs, c'est-à-dire entre deux classes de même niveau conceptuel : aucune des deux
n'est plus importante que l'autre.
 Lorsque l'on souhaite modéliser une relation tout/partie où une

classe constitue un élément plus grand (tout) composé
d'éléments plus petits (partie), il faut utiliser une agrégation.
 Une agrégation est une forme particulière d'association.

Elle représente la relation d'inclusion d'un élément
dans un ensemble.
 On représente l'agrégation par l'ajout d'un losange

vide du côté de l'agrégat.
 Une agrégation dénote une relation d'un ensemble

à ses parties. L'ensemble est l'agrégat et
la partie l'agrégé.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 82
ASSOCIATION DE TYPE COMPOSITION
 La relation de composition décrit une contenance structurelle entre instances. On

utilise un losange plein.
 La destruction et la copie de l'objet composite (l'ensemble) impliquent respectivement

la destruction ou la copie de ses composants (les parties).
 Une instance de la partie n'appartient jamais à plus d'une instance de l'élément

composite.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 83
COMPOSITION ET AGRÉGATION
 Dès lors que l'on a une relation du tout à sa partie, on a une relation d'agrégation ou de
composition.
La composition est aussi dite agrégation forte.
 Pour décider de mettre une composition plutôt qu'une agrégation, on doit se poser les
questions suivantes :
> Est-ce que la destruction de l'objet composite (du tout) implique nécessairement la
destruction des objets composants (les parties) ? C'est le cas si les composants
n'ont pas d'autonomie vis-à-vis des composites.
> Lorsque l'on copie le composite, doit-on aussi copier les composants, ou est-ce
qu'on peut les réutiliser , auquel cas un composant peut faire partie de plusieurs
composites ?
Si on répond par l'affirmative à ces deux questions, on doit utiliser une

composition.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 84
AGGREGATION ET COMPOSITION
 Les notions d'agrégation et surtout de composition posent de nombreux problèmes en

modélisation et sont souvent le sujet de querelles d'experts et sources de confusions.
 Ce que dit la norme UML Superstructure version 2.1.1 reflète d'ailleurs très bien le flou
qui entoure ces notions :
> Precise semantics of shared aggregation varies by application area and modeler.
The order and way in which part instances are created is not defined.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 85
AGGREGATION ET COMPOSITION
 La composition peut être vue comme une relation “fait partie de” (“part of”), c’est à
dire que si un objet B fait partie d’un objet A alors B ne peut pas exister sans A. Ainsi si
A disparaît alors B également.
 L’agrégation quant à elle est vue comme une relation de type “a un” (“has a”), c’est à
dire que si un objet A a un objet B alors B peut vivre sans A.
 La classe Employe possède deux attributs : Salaire et ProjetCourant. L’instance de

Salaire fait partie de l’instance d’employé, si on supprime l’employé alors son salaire
aussi est supprimé, c’est une relation de composition. En revanche l’employé a
un projet courant. Si l’utilisateur part de l’entreprise le projet perdurera, c’est une
relation d’agrégation.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 86
RELATION D'HÉRITAGE
 L'héritage une relation de spécialisation/généralisation.
 Les éléments spécialisés héritent

de la structure et du comportement
des éléments plus généraux
(attributs et opérations)
 Exemple :
> Par héritage d'Article,
un livre a d‘office un prix,
une désignation et une opération
acheter(), sans qu'il
soit nécessaire de le préciser
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 87
IMPLANTATION DE L'HÉRITAGE EN JAVA
class Article {
...
void acheter () {
...
}
}
class Livre extends Article {

...
}
Les << extends >> Java n'a rien à voir avec le << extend >> UML vu pour les
cas d'utilisation
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 88
RELATION D'HÉRITAGE ET PROPRIÉTÉS
 La classe enfant possède toutes les propriétés de ses classes parents (attributs et
opérations)
> La classe enfant est la classe spécialisée (ici Livre)
> La classe parent est la classe générale (ici Article)
 Toutefois, elle n'a pas accès aux propriétés privées.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 89
TERMINOLOGIE DE L'HÉRITAGE
 Une classe enfant peut redéfinir (même signature) une ou plusieurs méthodes de la
classe parent.
> Sauf indications contraires, un objet utilise les opérations les plus spécialisées dans
la hiérarchie des classes.
> La surcharge d'opérations (même nom, mais signatures des opérations différentes)
est possible dans toutes les classes.
 Toutes les associations de la classe parent s'appliquent, par défaut, aux classes
dérivées (classes enfant).
 Principe de substitution : une instance d'une classe peut être utilisée partout où une
instance de sa classe parent est attendue.
> Par exemple, toute opération acceptant un objet d'une classe Animal doit accepter
tout objet de la classe Chat (l'inverse n'est pas toujours vrai).
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 90
HÉRITAGE MULTIPLE
 Une classe peut avoir plusieurs classes parents. On parle alors d'héritage multiple.
> Le langage C++ est un des langages objet permettant son implantation effective.
> Java ne le permet pas.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 91
CLASSE PARAMÉTRÉE
 Pour définir une classe générique et paramétrable en fonction de valeurs et/ou de

types :
> Définition d'une classe paramétrée par des éléments spécifiés dans un rectangle en
pointillés ;
> Utilisation d'une dépendance stéréotypée <<bind>> pour définir des classes en
fonction de la classe paramétrée.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 92
DIAGRAMMES DE CLASSES À DIFFÉRENTES ÉTAPES DE LA
CONCEPTION
 On peut utiliser les diagrammes de classes pour représenter un système à différents

niveaux d'abstraction :
> 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'implantation.
> Le point de vue implantation, le plus courant, détaille le contenu et l'implantation de
chaque classe.
 Les diagrammes de classes s'étoffent à mesure qu'on va de hauts niveaux à de bas

niveaux d'abstraction (de la spécification vers l'implantation)
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 93
CONSTRUCTION D'UN DIAGRAMME DE CLASSES
 Trouver les classes du domaine étudié ;

> Souvent, concepts et substantifs du domaine.
 Trouver les associations entre classes ;

> Souvent, verbes mettant en relation plusieurs classes.
 Trouver les attributs des classes ;

> Souvent, substantifs correspondant à un niveau de granularité plus n que les
classes. Les adjectifs et les valeurs correspondent souvent à des valeurs d'attributs.
 Organiser et simplifier le modèle en utilisant l'héritage ;
 Tester les chemins d'accès aux classées ;
 Itérer et raffiner le modèle.
CENTRE DE DE
ENSA TRANSMISSION
KENITRA 94

Cours UML ENSA 2017-2018 Ch1-3 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours UML ENSA 2017-2018 Ch1-3 PDF

Transféré par

Droits d'auteur :

Formats disponibles

UNIFIED MODELING LANGUAGE

Pr. Youssef GAHI

01 > INTRODUCTION 06 > DIAGRAMMES D'ÉTATS-

02 > DIAGRAMMES DE CAS D’UTILISATION

03 > DIAGRAMMES DE CLASSES

05 > DIAGRAMMES DE SÉQUENCE MODÉLISATION OBJET

UNIFIED MODELING LANGUAGE 2017-2018 ENSA DE KENITRA

 Un système d’information représente l’ensemble des éléments participant à la gestion,

 Dérouler des ateliers de cadrage de besoins  Etudier la faisabilité du besoin exprimé

 Prioriser les besoins pour respecter le budget

 Document de cadrage  Rapport de faisabilité

 Traduction dans un langage de programmation  Vérifier la plateforme de production chez le client

 Test et validation en interne du cahier de recette

 Rédaction de la documentation d’utilisation et

 CD d’installation  Les logs d’installation

 La formation peut prendre plusieurs formes:  Corrections des erreurs

 Le transfert de compétences : il est

 L’accompagnement en production : il se met en

 Support de formation  Des patch/hotfix dans le cas de la maintenance

 Processus créatif pour la mise au point d’un logiciel

 Permet de donner une architecture au logiciel en le découpant en briques, chacune en

 Formalisation de la solution, en utilisant des notations ou des règles connues

 Permet de réduire la complexité d’un phénomène

 Il est naturellement trop difficile de réaliser un besoin a partir des représentations

 Un langage de modélisation doit définir :

 Des langages à différents niveaux de formalisation

 L'industrie du logiciel dispose de nombreux langages de modélisation :

 Le rôle des outils (Ateliers Génie Logiciel) est primordial pour

C'est la fonction qui donne la forme du système.

C'est la structure du système lui donne sa forme.

 Officiellement UML est né en 1994.

 Vue des cas d’utilisation

 Vue des processus

 Diagrammes structurels / statiques (UML Structure)

 Diagrammes comportementaux / dynamiques (UML Behavior)

UNIFIED MODELING LANGUAGE 2017-2018 ENSA DE KENITRA

 Avant de développer un système, il faut savoir précisément à QUOI il devra servir,

 Modéliser les besoins permet de :

 Avec UML, on modélise les besoins au moyen de diagrammes de cas d'utilisation.

 Le diagramme des Cas d’Utilisation:

 Il est également possible de représenter un acteur sous la forme d'un classeur

 Les autres acteurs sont alors qualifiés de secondaires.

 Un cas d'utilisation a au plus un acteur principal. Un acteur principal obtient un résultat

 En général, l'acteur principal initie le cas d'utilisation par ses sollicitations.

 Les principaux acteurs sont les utilisateurs du système.

 Un acteur correspond à un rôle, pas à une personne physique.

 Si plusieurs personnes jouent le même rôle vis-à-vis du système, elles seront

 En plus des utilisateurs, les acteurs peuvent être :

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

 Un acteur peut utiliser plusieurs fois le même cas d'utilisation.

 Il existe principalement deux types de relations :

 Inclusion : le cas A inclut le cas B (B est une partie obligatoire de A).

 Extension : le cas B étend le cas A (B est une partie optionnelle de A).

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

 Lorsque A est sollicité, B l'est obligatoirement, comme une partie de A. Cette

 Il ne faut surtout pas abuser de

 Exécuter B peut éventuellement entraîner l'exécution de A : contrairement à l'inclusion,

 Les inclusions et les extensions sont représentées par des dépendances.

 Lorsqu'un élément A dépend d'un élément B, toute modification de B sera susceptible

 Le sens des èches indique le dépendance, pas le sens de la relation d'inclusion.

 Les relations entre cas permettent la réutilisabilité du cas <<s'authentifiier>> : il sera

 Un cas A est une généralisation d'un cas B si B est un cas particulier de A.

 la consultation d'un compte via Internet est un cas particulier de la consultation.