Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université Abderrahmane Mira de Bejaia

Faculté des Sciences Exactes
Département d’Informatique

Cours Génie logiciel

Réalisé par: Dr. YESSAD Nawal Ep. OUATAH
yessadnawel@gmail.Com
Niveau : L3

Année universitaire 2019/2020

 CHAPITRE 3:
INTRODUCTION À UML
 UML
Unified Modeling Language
(Langage de Modélisation Unifié)

Pourquoi UML

Besoin de modéliser pour construire un logiciel

Pourquoi Modéliser
Pourquoi modéliser ?

les systèmes sont souvent trop complexes

Nous somme incapable de les comprendre dans leur totalité

Modèle
Une simplification de la réalité.
Une abstraction centrée sur la représentation conceptuelle et physique d’un système.

ABSTRACTION
Système réel Modèle

 Et particulièrement en génie logiciel :

-Être un facteur de réduction des coûts et des délais,
-Être un facteur d’accroissement de la qualité du produit,
-Permettre d’assurer une maintenance facile et efficace,
-Permettre de contrôler l’avancement d’un projet.
Modélisation en diagrammes

 Modèle = ensemble d’éléments de modélisation vus dans un ensemble de

diagrammes

Diagramme
 Support graphique de modélisation, chaque diagramme propose un point de vue différent.
 mise en œuvre d’un ensemble d’éléments de visualisation représentant des éléments de
modélisation (graphe)
 UML -Unified Modeling Language

Définition
UML est un langage de modélisation orienté objet standard qui permet de représenter
(de manière graphique) et de communiquer les divers aspects d’un système informatique.

●
UML n'est pas une méthode de conception et pas un langage de programmation

C’est juste un ensemble de notations ayant comme base la notion d’objet.

Langage graphique : Ensemble de diagrammes permettant de modéliser le2 logiciel à selon

différentes vues et à différents niveaux d'abstraction
Évolution de L’UML

1995 :
 UML 0.8 (intégrant la méthode Booch)
 UML 0.9 (intégrant les méthodes OOSE et OMT)
1996 : UML 1.0 proposé à l’OMG
1997 : UML 1.0 standardisé par l’OMG
1998 : UML 1.2
1999 : UML 1.3
2000 : UML 1.4
2003 : UML 1.5 puis UML 2.0

3
Outils de modélisation UML

 Les logiciels de modélisation UML sont nombreux.

 Fonctionnalités principales :
 de modéliser tous les diagrammes UML, avec tous les composants.
 de naviguer facilement et naturellement entre ces diagrammes (organisation
arborescente en paquetages)
 d’exporter les diagrammes pour les intégrer dans les documents de conception.
 production automatique de code, de documents, . . . .

Exemples : Umbrello, StarUML, Visual Paradigm, Rational Architect, etc.

Les diagrammes de l’UML

4
Diagrammes d’UML

Représentation du logiciel à différents points de vue :

 Vue des cas d'utilisation -------------------> vue des acteurs (besoins attendus)

 Vue logique -------------------> vue de l’intérieur (satisfaction des besoins)

 Vue d'implantation -------------------> dépendances entre les modules

 Vue des processus -------------------> dynamique du système

 Vue de déploiement -------------------> organisation environnementale du logiciel

 DIAGRAMME DE
CAS D’UTILISATION
Diagrammes de cas d’utilisation

Définition
Ce diagramme est destiné à représenter les besoins des utilisateurs par rapport au système.

Les diagrammes des cas d’utilisation permettent :

 Définir les limites du système
 Définir les utilisateurs ou éléments qui interagissent avec le système
 Définir les fonctionnalités du du système

Eléments constitutifs :
 Acteurs
 Cas d’utilisation
 l’interaction entre l’acteur et le cas d’utilisation.
Les concepts de base

Acteur
 Un acteur représente un rôle joué par une entité extérieure
au système étudié et qui interagit avec celui-ci.
 représente un ensemble cohérent de rôles qu’un utilisateur
Nom de l’Acteur
peut effectuer.

Catégories:
 Acteurs principaux : personnes utilisant le système (ie. l’initiative des échanges nécessaires
pour réaliser le cas d’utilisation)
 Acteurs secondaires: qui administrent le système (paramètrent le système en lui
fournissant les informations nécessaires )
Types:
 Matériel externe: dispositifs matériels faisant partie du domaine de l’application (ex.
imprimante, scanner, etc.)
 Autres systèmes (ex. serveur Web, système de contrôle d’accès, etc.)
Les concepts de base

Remarques :
 Pour identifier les acteurs, il faut classer les utilisateurs par catégories et chacune d’elles
correspond à un rôle joué par un acteur
 Plusieurs personnes peuvent jouer le même rôle, ils correspondent dans ce cas à un seul acteur
 Une même personne peut jouer différents rôles, elle correspond dans ce cas à plusieurs acteurs
Les concepts de base

Cas d’utilisation
Ensemble cohérent de fonctionnalités fournies par le système ou un Nom Cas d’utilisation
sous-système en réponse à une action de l’utilisateur. Ce ci se
traduit par l’échange de messages entre le système et les acteurs.
Les cas d’utilisation

Relations/Interactions
 Les acteurs sont reliés aux cas d’utilisation qu’ils peuvent
déclencher Cas d’utilisation
 Le trait représente des données qui sont échangées entre
l’utilisateur et le système Acteur
Schéma général

Remarques :

 Les cas d’utilisation peuvent être contenus dans un cadre qui représente les limites du
système. Le nom du système figure à l’intérieur du cadre, en haut. Les acteurs sont alors forcément
à l’extérieur du cadre puisqu’ils ne font pas partie du système.

 Par convention et dans la mesure du possible ; Les acteurs principaux sont situés à gauche
du cas d'utilisation. Les acteurs secondaires sont situés à droite du cas d'utilisation.

Acteur principal
Nom du système Système

C.U. 1

Acteur secondaires
C.U. 2

Les cas d’utilisation

Un acteur déclenche un cas d’utilisation

Exemple
Système de commande de produit

Traiter une
commande
Commander
un produit
Préparer une
facture
Payer une Fournisseur
Client
facture
Livrer un
produit

 Un client fait la commande d’un produit

 Le fournisseur traite la commande
 Le fournisseur prépare la facture
 Le fournisseur livre le produit
 Après réception, le client paye la facture
Relation entre les acteurs

 La seule relation possible entre deux acteurs est la généralisation

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

Responsable du groupe
Relation entre les acteurs Le directeur des ventes est un préposé aux commandes
avec un pouvoir supplémentaire : en plus de pouvoir passer
et suivre une commande, il peut gérer le stock. Par contre,
le préposé aux commandes ne peut pas gérer le stock.

Système de vente par Système de vente par

correspondance correspondance

Passer une commande Passer une commande

Préposé aux
Préposé aux commandes
Suivre une commande Suivre une commande
commandes

Gérer les stocks Gérer les stocks

Directeur
Directeur des ventes
des ventes
Relations entre les cas d’utilisation

 Trois types de relations entre cas d’utilisation

1. Relation d’Inclusion
2. Relation d’Extension
3. Relation de Généralisation
Relations entre les cas d’utilisation

Relation d’inclusion
 Une instance du d’utilisation cas A inclut le
comportement décrit par le cas d’utilisation B
(dans le sens de la flèche ) << includes >>
A B
 B est une partie obligatoire de A

 Est représentée par une flèche en traits

pointillés et par le mot clé « inclut » (ou «
include » en anglais) placé à proximité de cette
flèche.

Envoyer un << includes >>

S’authentifier
mail

Gérer << includes >>

Utilisateur compte
Relations entre les cas d’utilisation

Relation d’extension
 Une relation d'extension entre cas d'utilisation signifie que le cas d'utilisation source étend le
comportement du cas d'utilisation destination.

 Elle est représentée par une flèche en traits pointillés et par le mot clé « étend » (ou « extend »
en anglais) placé à proximité de cette flèche.

 dénote un comportement optionnel, B est une partie optionnelle de A

 On lit B étend A (dans le sens de la flèche)

<< extends >>

A B
Relations entre les cas d’utilisation
 Remarques

 L’extension peut intervenir à un point précis du cas étendu. Ce point s’appelle le point
d’extension. Il porte un nom, qui figure dans un compartiment du cas étendu sous la rubrique
point d’extension, et est éventuellement associé à une contrainte indiquant le moment où
l’extension intervient. L’extension peut être soumise à une condition. Graphiquement, la
condition est exprimée sous la forme d’une note.

 Une contrainte définit des propositions devant être maintenues à vraies pour garantir la validité
du système modélisé. On représente une contrainte sous la forme d'une chaîne de texte placée
entre accolades { }.

 Une note en UML est une annotation qui peut concerner n’importe quel élément UML. Une note
contient une information textuelle comme un commentaire, un corps de méthode ou une
contrainte. Graphiquement, elle est représentée par un rectangle dont l'angle supérieur droit est
plié. Une note n'indique pas explicitement le type d'élément qu'elle contient, toute l'intelligibilité
d'une note doit être contenue dans le texte même. On peut relier une note à l'élément qu'elle
décrit grâce à une ligne en pointillés
Relations entre les cas d’utilisation

<< extends >> Imprimer l’extrait

compte
Consulter
compte CCP
Commander un
Client << extends >> carnet de chèques
Relations entre les cas d’utilisation

Relation de généralisation

 Une relation de généralisation de cas d’utilisation

peut être définie conformément au principe de la A B
spécialisation - généralisation déjà présentée pour
les classes.

 A est une généralisation de B

 On lit B est cas particulier de A

Rechercher par
nom
Rechercher
fournisseur
Rechercher par
Client
ville
Relations entre les cas d’utilisation

Remarque : Quand un cas n’est pas

directement relié à un acteur, il est
qualifié de cas d’utilisation interne.
Description textuelle des cas d’utilisation

 La description d’un scénario par un diagramme de séquence n’empêche pas de décrire le

cas sous forme textuelle, ce qui permet de faire figurer des renseignements supplémentaires.

 Une description textuelle couramment utilisée se compose de trois parties.

1. La première partie permet d’identifier le cas

2. La deuxième partie contient la description du fonctionnement du cas sous la forme d’une
séquence de messages échangés entre les acteurs et le système.
3. La troisième partie de la description d’un cas d’utilisation est une rubrique optionnelle.
Elle contient généralement des spécifications non fonctionnelles (ce sont le plus souvent des
spécifications techniques,).
 Sommaire d’identification
Titre Nom du cas d’utilisation
Résumé But du cas d’utilisation
Acteurs Acteurs participants au cas d’utilisation
Dates dates de création et de mise à jour de la description courante ;
Nom Nom des responsables
Numéro Numéro de version
Description des scénarios
Préconditions Conditions décrivant dans quel état doit être le système avant que le
cas d’utilisation puisse être déclenché

Scénario nominal Séquences d'actions associées au cas d'utilisation se déroulant lorsqu'il

n'y a pas d'erreurs

Enchainement d’erreurs Séquences d'action conduisant à un échec

Postconditions Conditions décrivant l’état du système à l'issue des différents scénarios

Rubrique optionnelle (spécifications non fonctionnelles)

 Sommaire d’identification
Titre Consulter le compte depuis internet
Résumé Détailler les étapes permettant à un client à consulter son compte bancaire
Acteurs Client, Banque (secondaire)
Dates 21/02/2018
Nom Marc Laporte
Numéro Version : 1.0
Description des scénarios
Préconditions Le client existe et son compte a été créé

Scénario nominal 2.1 Le client s’authentifie

2.2 Le système vérifie le login et le mot de passe ont été saisis
2.3 Le système vérifie que le login et le mot de passe sont valides
2.4 Le système affiche la page web du compte pour le client
Enchainement d’erreurs a En (2.2) : si le login ou le mdp sont incorrectement saisis, le
client est averti de l’erreur, et invitéà recommencer
b En (2.3) : si les informations sont erronées, elles sont re-
demandées au client
Postconditions Le système stocke dans l’historique la date d’accès au compte du client

Rubrique optionnelle
Contraintes non fonctionnelles : Confidentialité: les informations concernant le client ne doivent pas être divulgués
Contraintes liées à l’interface homme-machine : Toujours demander la validation de la part du client
DIAGRAMME DE
CLASSE
Diagramme de classe

Définition
 Ce diagramme représente la description statique du système en intégrant dans chaque
classe la partie dédiée aux données et celle consacrée aux traitements.

 C’est le diagramme pivot de l’ensemble de la modélisation d’un système.

Diagramme de classe

Rappel
Nom de la
classe
Cardinalités
Etudiant Formation
+ Matricule + IDformation
+ Nom + Filière
+ Prénom * Suivre 1 + Cycledeformation
Public − Datenaissance + Année
− Lieunaissance + Université
+ Modifier (…)
Privé
+ Age(…)
Attributs

Méthodes Association
Les concepts de base

Association entre classes

 Une association entre classes représente les liens qui existent entre les instances de ces classes
 Une association peut être identifiée par son nom.
 Il est possible d’exprimer les multiplicités (cardinalités) sur le lien d’association.
 La multiplicité indique un domaine de valeurs pour préciser le nombre d’instance d’une
classe vis-à-vis d’une autre classe pour une association donnée.

1 Un et un seul
Notation des multiplicités d’association :
0..1 Zéro ou 1

N N (entier naturel)

M..N De M à N (entiers naturels)

0..* De zéro à plusieurs

1..* De 1à plusieurs
Les concepts de base

 Il est possible de préciser le rôle d'une classe au sein d'une association.

 Le rôle est placé à une extrémité du lien d’association, il se distingue ainsi du nom de
l’association situé au centre du lien.

 Dans cet exemple, une personne travaille pour une et une seule entreprise.
 L’entreprise emploie au moins une personne.
 L’entreprise est l’employeur des personnes qui travaillent pour elle et une
personne a un statut d’employé dans l’entreprise.
Les concepts de base

Association binaire
Une association binaire est représentée par un
simple trait.

Remarque: On peut avoir plusieurs associations entre deux classes.

Les concepts de base
Association n-aire
 Une association n-aire lie plus de deux classes.
 Elle est graphiquement représentée par un grand losange avec un chemin partant vers chaque
classe participante.
 Le nom de l’association, le cas échéant, apparaît à proximité du losange.

Pour une association ternaire, les cardinalités se lisent

de la façon suivante :
 Pour un couple d'instances de la classe 1 et de la
classe 2, il y a au minimum n1 instances de la classe
3 et au maximum n2.
Les concepts de base
Association n-aire
 Une association n-aire lie plus de deux classes.
 Elle est graphiquement représentée par un grand losange avec un chemin partant vers chaque
classe participante.
 Le nom de l’association, le cas échéant, apparaît à proximité du losange.

Pour une association ternaire, les cardinalités se lisent

de la façon suivante :
 Pour un couple d'instances de la classe 1 et de la
classe 2, il y a au minimum n1 instances de la classe
3 et au maximum n2.
Les concepts de base

Classe association
 Une classe-association est nécessaire quand une association
doit posséder ces propres propriétés.
Association entre les classes

Classe 1 Classe 1 Classe 1

Généralisation Agrégation Composition

Classe 2 Classe 2 Classe 2

Personne Formation Livre

1
1..*

1..*
1..*
Chapitre
Homme Module
Exercice

 Lors de son inscription en début d’année, chaque étudiant remplit une fiche sur laquelle il
indique certains renseignements comme son numéro d’identification nationale, son nom et
prénom, son adresse et la liste des matières qu’il s’engage à suivre. Un code lui sera
automatiquement attribué. Une matière est caractérisée par un code et un intitulé. Chaque
matière est placée sous la responsabilité d’un enseignant identifié par un code et caractérisé par
son nom, prénom et le numéro de son bureau. Cet enseignant se rend disponible un jour dans la
semaine à un horaire précis afin de donner tout renseignement concernant les matières qu’il
dirige.

 Composer le diagramme de classe correspondant

 Que faut-il modifier pour qu’un enseignant se rende disponible à différents moments (un seul
créneau par matière qu’il dirige) ?
 Que faut-il modifier pour que différents créneaux soient disponibles par matière qu’il dirige ?
DIAGRAMME DE
SÉQUENCE
Diagrammes de séquence

Définition
 Un diagramme de séquence montre quels sont les objets qui participent à l’exécution du use-
case et quels sont les messages qu’ils échangent
 Description des interactions entre un acteur et les objets du système d’un point de vue
temporel.
 L’accentestmissurlachronologiedesenvoisdemessages
 Chaque bloc ou objet participant dans le processus est représenté par une barre verticale.

 Deux utilisations
 Documentation des cas d’utilisation
– Evénements qui surviennent dans le domaine de l’application
 Représentation précise des interactions entre objets
– Echanges de messages
Concepts de base

:Objet
Ligne de vie des objets
 Est représentée par une ligne verticale en traits pointillés, placée sous le
symbole de l’objet concerné.
 Cette ligne de vie précise l’existence de l’objet concerné durant un certain
laps du temps.

Barre d’activation
:Objet
Les diagrammes de séquence permettent de représenter les périodes d’activité
des objets. Une période d’activité correspond au temps pendant lequel un
objets effectue une action, soit directement, soit par l’intermédiaire d’un autre
objet qui lui sert desous-traitant. Les périodes d’activité se représentent par
des bandes rectangulaires placées sur les lignes de vie. Le début et la fin d’une
bande correspondent respectivement au début et à la fin d’une période
d’activité.
Concepts de base

Message synchrone
Un message synchrone est utilisé dans le cas ou l’émetteur reste en attente de
la réponse à son message avant de poursuivre ses actions.
Message synchrone
Le message de retour peut ne pas être représenté car il est inclus dans la fin
d’exécution de l’opération de l’objet destinataire du message.

Message retour

Message asynchrone
Message asynchrone est utilisé dans le cas ou l’émetteur n’attend pas la réponse
à son message, il poursuit l’exécution de ses opérations.

Message asynchrone
Concepts de base

Remarque:

- L’ordre d’envoi d’un message est déterminé par sa position sur l’axe vertical du diagramme ;
le temps s’écoule « de haut en bas » de cet axe.

- La disposition des objets sur l’axe horizontal n’a pas de conséquence pour la sémantique du
diagramme.

- Les messages sont étiquettés par le nom de l’opération ou du signal invoqué.

Concepts de base

Message récursif
l’envoi de messages récursifs se représente par un dédoublement de la bande
rectangulaire.
L’objet apparait alors comme s’il était actif plusieurs fois.

Remarque :
Un objet peut également s’envoyer un message. Cette situation se représente par une
flèche qui revient en boucle sur la ligne de vie de l’objet.
Fragments d’interaction

Définition
 Un fragment d’interaction dit combiné correspond à un ensemble d’interaction auquel on
applique un opérateur d’intéraction .
 Plusieurs opérateurs ont été définis dans UML: loop, alt, opt, etc.

 L’opérateur loop: correspond à une instruction de boucle.

LOOP [condition]
Fragments d’interaction

 L’opérateur alt: se représente dans un fragment possédant au moins deux parties

séparées par des pointillés. L’opérateur alt correspond à une instruction de test avec une
ou plusieurs alternatives possibles Si…Sinon…
ALT [condition]

 L’opérateur opt (opération optionnelle)correspond à une instruction de test sans

alternative (sinon). l'appel ne s'exécute que si la condition est vraie fourni
OPT

 L’opérateur Ref
REF
Diagrammes de séquence (résumé)

Les objets du système

: Objet : Objet : Objet

Acteur
Message Activer une Activer une
action action locale
Message
Message Message
Message
Appel asynchrone Récursion
Message
Toujours Appel synchrone
actif
Barre
Réponse d’activation Ligne de vie
de l’objet
Diagrammes de séquence (Exemple)

(AUTHENTIFICATION –SYSTÈME DE MESSAGERIE)

Système :Comptes :Emails

Utilisateur
Saisir (USER,PWD)
Valider
Envoyer(USER,PSW)
Rechercher
(<USER,PSW>)
ALT [<USER,PSW>nontrouvé] Utilisateur nonauthentifié
Messaged’erreur

[Sinon] Utilisateurauthentifié

RécupérerEmailsdeUSER

CollecterEmails
deUSER
EmailsdeUSER
2
Affichage 3
Exercice

Afin de développer une application interactive de jeu d’échecs sur Smartphone, nous nous
intéressons à la modélisation chronologique des différentes actions génériques qui
doivent s’exécuter pour dérouler une partie entre deux joueurs. Les Smartphones de ces
deux derniers sont connectés directement en mode Bluetooth.
Nous supposons que l’application dispose d’une fonctionnalité lui permettant de vérifier la
validité d’un coup et une autre lui permettant de vérifier si le roi est en position d’échec et
mat. Les coups sont notés en algébrique et échangés entre les Smartphones sous forme de
chaînes de caractères. Par exemple, le coup « Cg5 » signifie que le joueur a déplacé
son cavalier à la case indexée par la colonne « g » et la ligne « 5 ». Le mouvement du doigt
sur l’écran introduit le coup à jouer et l’application dispose la fonctionnalité de le
correspondre à la notation algébrique.

26

Travail demandé: Proposer un diagramme de séquence

 DIAGRAMME DE
COMMUNICATION
Diagramme de communication

Définition
 Le diagramme de communication constitue une autre représentation des interactions que celle
du diagramme de séquence.
 le diagramme de communication met plus l’accent sur l’aspect spatial des échanges que
l’aspect temporel.
Diagramme de communication
DIAGRAMME
D’OBJETS
Diagramme d’objets

Définition
 Le diagramme d’objets fait parties des diagrammes structurels (statique).
 Il représente les objets d’un système (c.a.d. les instances des classes) et leurs liens (c.a.d. les
instances des associations) à un instant donné.
 Il donne une vue figée du système à un moment précis.
 A un diagramme de classe correspond une infinité de diagrammes d’objets.
 Nous nous servirons du diagramme d’objet pour donner des exemples, des cas de figure, qui
permettront d’affner le diagramme de classe et de mieux le comprendre.
Diagramme d’objets

Dans le diagramme de classes ci-dessous, nous représentons un lien entre

deux classes Commande et Client.
Diagramme d’objets

Si nous nous intéressons à un client en particulier pour voir les

commandes qu’il a effectué, nous représentons ceci par un diagramme
d’objets donné comme suit :

Remarque :
 Le nom d’un objet est souligné. Il peut être désigné sous trois
formes :
 nom de l’objet, désignation directe et explicite d’un objet ;
 nom de l’objet : nom de la classe, désignation incluant le nom
de la classe ;
 nom de la classe, désignation anonyme d’un objet d’une classe
donnée.
DIAGRAMME DE
D’ÉTAT-
TRANSITION
Diagramme d’état de transition

Définition
 Un diagramme d’état de transition peut être vu comme un ordinogramme pour un objet
bien précis du système étudié. Il peut représenter un automate d’états finis.

 Un état : représente une situation durant la vie d’un objet pendant laquelle :
 Il satisfait une certaine condition
 Il exécute une certaine activité
 Ou bien il attend un certain événement

 Etat initial et état final

 L’état initial d’un diagramme correspond à la création de l’instance.
 L’état final correspond à la destruction de l’instance.
Diagramme d’état de transition

Un événement :
 un événement peut être la réception d’un message, l’appel d’une opération, le passage du
temps (mot clé : after) le changement dans la satisfaction d’une condition.

 Un événement peut porter des paramètres qui représentent le flot d’information entre objets.

Une transition:
 Une transition représente un changement d'état; elle est déclenchée par un événement.

 Pour passer d’un état à un autre (une transition), il faudrait un événement. Une condition ou
(condition de garde) est une expression booléenne qui doit être vraie lorsque l’événement arrive
pour que la transition soit déclenchée.
Diagramme d’état de transition

Evènement
Etat
Etat initial
Transition

Etat final
DIAGRAMME DE
DÉPLOIEMENT
Diagramme de déploiement

Définition
 Modélise l'aspect matériel de l'application
 Montre la disposition physique des différentes ressources matérielles (PC, Modem, Station de
travail, Serveur, etc.) qui composent le système, leurs interconnexions et la répartition des
programmes/exécutables sur ces matériels.
 Chaque ressource est matérialisée par un nœud représente par un cube comportant un nom
 Les associations entre nœuds sont des chemins de communication qui permettent l' échange
d'informations
 Un système est généralement décrit par un petit nombre de diagrammes de déploiement
(généralement un seul su t)
Diagramme de déploiement
DIAGRAMME DE
COMPOSANTS
Diagramme de déploiement

Définition

un composant est un élément logiciel remplaçable et réutilisable qui fourni ou reçoit un service bien
précis. Il peut être vu comme une pièce détachée du logiciel. Les plu-gins, les drivers, les codecs, les
bibliothèques sont des composants.

La notion de composant est proche de celle d’objet, dans le sens de la modularité et de réutilisation
avec toute fois une granularité qui peut être différente. Le composant est à l’architecture du logiciel ce
que l’objet est à l’architecture du code.

Les composants fournissent des services via des interfaces

Il existe deux types d’interface :

✔ Les interfaces requise : Ce sont des interfaces qui fournissent un service au composant et dont il a
besoin pour fonctionner.

✔ Les interfaces fournies : Ce sont des interfaces par lesquels le composant fourni lui-même un
service.
 Il existe plusieurs possibilités pour représenter un composant

Un rectangle dans lequel Un rectangle dans lequel Un rectangle dans lequel

figure : figure : figure :
- Le nom du composant. - Le nom du composant. - Le stéréotype
- 2 petits rectangles l’un au - Le symbole en haut à droite <<component>>.
dessus - Le nom du composant.
il existe plusieurs possibilités pour représenter les interfaces :

Intégrées dans la représentation du composant :

Nous reprenons l’une des trois représentations du composant que nous venons juste de voir et
nous ajoutons un compartiment dans lequel nous listons les interfaces requises et fournies
(grâce aux stéréotypes <<required interface>> et <<provided interface>>).
Conclusions

• UML est devenu un standard international : adopté un peu partout (universel)

• les modèles sont simples, faciles à lire et à communiquer

 Montrer les limites d’un système et ses fonctions principales à l’aide des cas d’utilisation et
des acteurs.
 Illustrer les réalisations de Cas d ’Utilisation à l’aide de diagrammes d’interaction.
 Représenter la structure statique d’un système à l’aide de diagrammes de classes,
associations, contraintes.
 Modéliser la dynamique, le comportement des objets à l’aide de diagrammes
états/transitions.
 Révéler l’implantation physique de l’architecture avec des diagrammes de composants et
de déploiement.