Perfectionnement UML SBA 2023

RÉPUBLIQUE ALGÉRIENNE DÉMOCRATIQUE ET POPULAIRE
IFEP SENHADRI ABDELHAFID

SIDI BEL ABBES
Méthodologie De Modélisation applications Web
UML2.2 : Unified Modeling Language
Présenter par : Mr KORDARA Mohamed El’amine 1

CIP en Informatique
UML
 Introduction
 Objectifs Pédagogiques
 Cycle de vie d’un logiciel
 Historique d’UML
 Comparaison entre MERISE et UML
 Présentation du langage UML

 Diagrammes UML
 Diagramme de classes
 Diagramme de cas d'utilisation
 Diagramme d’activité
 Diagramme de séquence
 Diagramme de déploiement
amine.kordara@gmail.com 2
Objectifs pédagogiques:
 Objectif général :
A la fin du perfectionnement chaque enseignant sera capable
de concevoir et modéliser des applications web grâce à la
méthodologie UML et de l'appliquer à l'aide du programme
STARUML sans se référer au cahier de cours.
Sous Objectifs:
1) Définir le langage de modélisation UML
2) Elaborer le diagramme de classe
3) Elaborer le diagramme de cas d’utilisation
4) Elaborer le diagramme d’activités
5) Elaborer le diagramme de séquence
6) Elaborer le diagramme de déploiement
Cycle de vie d’un logiciel
4
 Processus (ensemble d’activités) nécessaire

au développement et à la maintenance d’un
logiciel
 Composé de plusieurs phases autonomes
mais dépendantes (interdépendantes).
 Chaque étape se termine par la remise de un
ou plusieurs documents validé conjointement
par l’utilisateur et le développeur.
Modèle en Cascade (WaterFall)
5
Analyse
Conception
Implémentation
Tests
Maintenance
Analyse
6
 Elle a pour but de dégager le problème à

étudier.
 Le résultat de l'analyse est le cahier de
charges (exprimé dans une langue naturelle)
contenant les besoins du futur système.
 Cette spécification est informelle.
 3 phases:(Faisabilité, Spécifications des
besoins, Organisation du projet)
Faisabilité
7
 Première étape du cycle de vie d’un logiciel

 Répondre à deux questions :
 Est-ce que le logiciel est réalisable ?
 Est-ce que le développement proposé vaut la

peine d’être mis en œuvre ?
►► Étudier le marché pour déterminer s’il

existe un marché potentiel pour le produit.
Spécification des besoins
8
 Permet de définir ce que doit faire le logiciel et

non comment il le fait
 Quatre types de spécifications
 Spécifications générales
 Spécifications fonctionnelles
 Spécifications d’interface
 Spécifications techniques
9
La spécification générale consiste à identifier :

 Objectifs à atteindre
 Contraintes (utilisation du matériel et outils

existants)
 Règles de gestion à respecter
10
Spécification fonctionnelles est la description des

fonctionnalités du futur logiciel de manière
détaillée que possible
Spécification d’interface décrit les interfaces du

logiciel avec le monde extérieur : homme
(IHM), autres logiciel (Middleware), machines
A. Madani (abdellah_madani@yahoo.fr)
11
Spécification technique :(Étude de l’existant)

 Moyens d’accès (local, distant, Internet, …)
 Temps de réponse acceptable (gestion des GAB,
gestion des emplois de temps, …)
 Plateforme (Windows, Unix, …)
 Quantité d’informations à stocker (choix du
SGBDR, …)
Organisation du projet
12
 Appelée aussi Planification et gestion de projet

 Permet de déterminer la manière de développer le
logiciel
 La phase de planification permet de :
 découper le projet en tâches
 décrire leur enchaînement dans le temps,
 affecter à chacune une durée et un effort
Organisation du projet
13
Plusieurs étapes :
 Analyse des coûts: estimation du prix du projet
 Planification: calendrier pour le développement
(jours ouvrables, jours fériés, nombre d’heures de
travail par jours, …)
 Répartition des tâches: distribuer les tâches et les
sous tâches (affectation des ressources aux
tâches)
Conception
14
 Permet de fournir une description fonctionnelle

(formelle) du système en utilisant une
méthode.
 Les méthodes proposent des formalismes
(dans la plupart des temps graphiques) pour
concevoir le système.
 Deux types de conception :
 Conception générale
 Conception détaillée
Conception générale
15
 Appelée aussi : ‘Conception architecturale’

 Se focaliser sur l’architecture générale du
système : décomposition du système en sous
système
Exemple, pour la gestion scolaire :
 Estudiantine (étudiants, notes, prof, filières, …)
 Administrative (personnel administratif, …)
 Bibliothèque (Ouvrages, auteurs, adhérents, …)
Conception détaillée
16
 Produire une description externe de chacune

des procédures, fonctions et des structures de
données (conception classique)
 Produire de manière précise les contenus des
objets en terme de propriétés et de méthodes
(conception Orientée Objet)
implémentation (Réalisation)
17
 Des programmes seront élaborés afin de

mettre en œuvre des solutions techniques
précédemment retenues
 Plusieurs types langages sont utilisés:
 Langages classiques (C, Pascal, Fortran, …)
 Langages orientés objets (C++, Java, C#, …)
Codage et Tests
18
On distingue plusieurs types de tests :

 Test unitaire: tester les parties du logiciel par les développeurs
 Test d’intégration: tester pendant l’intégration des modules
 Test système: tester dans un environnement proche à celui de
production
 Test alpha: tests faits par le client sur le site de développement
 Test bêta: tests faits par le client sur le site de production
 Test de régression: enregistrer les résultats des tests et les
comparer avec ceux des anciens versions pour déterminer si la
nouvelle n’a pas apporté de dégradation de performance.
Livraison
19
 Fournir au client une solution logiciel qui

fonctionne correctement.
 Plusieurs tâches :
 Installation: rendre le logiciel opérationnel sur le
site du client
 Formation: enseigner aux utilisateurs à se servir
de ce logiciel
 Assistance: répondre aux questions de l’utilisateur
Maintenance
20
 Mettre à jour et améliorer le logiciel

 La maintenance comprend :
 Corrective : correction des erreurs et anomalies
 Adaptative : adaptation à de nouveaux
environnements
 Évolutive ou Perfective : ajout de nouvelles
fonctionnalités
Documents
21
 Cahier des charges : description des fonctionnalités

désirées (décrites par l’utilisateur)
 Spécifications : décrit ce que doit remplir le logiciel
(décrites par le développeurs) :
 Modèle Objet : Classes et objets
 Scénarios des cas d’utilisation : différents enchaînements
possibles du point de vue de l’utilisateur
 IHM : propositions des interfaces homme-machines
 …
Documents
22
 Calendrier du projet: indique les tâches, les

délais et les ressources
 Plan de test: indique les procédures de tests à
appliquer
 Manuel d’utilisateur: mode d’emploi du logiciel
dans sa version finale
Documents
23
 Code source: code complet du produit fini

 Rapport des tests: décrit les tests effectués et
les réactions du système
 Rapport des défauts: décrit les comportements
du système qui n’ont pas satisfait le client.
Cours MSI-2A filière ICL
version 2.1 du 9 novembre 2009
Historique de l’UML
UML 2.2 UML 2.0 2005
2009
UML 1.3
OMG Acceptance, Nov 1997
Final submission to OMG, Sep ‘97 UML 1.1
public First submission to OMG, Jan ´97
feedback
UML partners UML 1.0
Web - June ´96 UML 0.9
OOPSLA ´95 Unified Method 0.8
Other methods Booch method OMT OOSE

24 amine.kordara@gmail.com 24
Comparaison entre MERISE et UML
Qu’est ce que UML ?
UML(Unified Modeling Language) un

langage de modélisation unifié
 Langage = syntaxe + sémantique :
 syntaxe : notations graphiques consistant
essentiellement en des représentations
conceptuelles d'un système
 sémantique : sens précis pour chaque notation
 UML est caractérisé par :

 un travail d'expert
 utilise l’approche orientée objet
 normalisé, riche
 Formel : sa notation limite les ambiguïté et les
incompréhensions
 langage ouvert
 INDÉPENDANT du langage de programmation
 Domaine d'application : permet de modéliser n'importe quel
système
 Supporté par plusieurs outils (AGL) : Objecteering, Open
tools, Rational Rose, PowerAMC, WinDesign, …
Attention
UML est un langage (et non pas une
méthode) qui :
 permet de représenter les modèles
 ne définit pas le processus d'élaboration des

modèles.
Diagrammes d'UML
UML1.1 comprend 9 de diagrammes :
Diagramme
Est sorte de
Cas d d’utilisation
Cas ’utilisation Classes
Classes États
EtatsTransitions
Transitions Séquence
Séquence
Collaboration Composants Déploiement Activité Objets
Diagrammes d'UML
UML définit deux types de diagrammes, structurels

(statiques) et comportementaux (dynamiques)
 Modélisation de la structure
 diagramme de classes
 diagramme d’objets
 diagramme de composants
 diagramme de déploiement
 Modélisation du comportement
 diagramme de cas d'utilisation
 diagramme d’états
 diagramme d’activités
 diagramme de collaboration
 diagramme de séquence
Diagramme d’UML
Les diagramme d’UML peuvent être utilisés pour

représenter différents points de vues :
 Vue externe : vue du système par ses utilisateurs
finaux
 Vue logique statique : structure des objets et leurs
relations
 Vue logique dynamique : comportement du
système
 Vue d’implémentation : composants logiciels
 Vue de déploiement : répartition des composants
Diagramme d’UML
Cas d’utilisation
Objets Composants
Classes Vue logique statique Vue Implémentation

(Structure des objets) (composants logiciels)
Vue externe
(fonctions système)
Séquence Vue déploiement
Vue logique dynamique
(Environnement
(Comportement)
d’implantation)
Collaboration
Activités
États transitions Déploiement
UML
Diagrammes de classes
Objets et classes
TaVoiture : Voiture
AutreVoiture
Marque =: Voiture
Renault
MaVoiture
Marque : Voiture
= Renault
Modèle = Megane
Objet : une entité concrète avec une identité Marque =Immatriculation
Renault
Modèle = Megane = 648DBX38
bien définie qui encapsule un état et un Modèle =1Megane
Immatriculation = 648DBX38
re immatriculation = 16 sept
comportement. L’état est représenté par
2009 = 648DBX38
Immatriculation
1re immatriculation
des valeurs d’attribut et des associations, = 16 sept
le comportement par des méthodes. 2007Kilométrage
1re immatriculation = 125
= 16 sept000
1997Kilométrage = 125 000 ? ()
Kilométrage-annuel
2 objets peuvent être semblables et pas identiques
Kilométrage = 125 000 ? ()
Kilométrage-annuel
Un objet peut être une instance d’une Kilométrage-annuel ? ()
classe.
Classe : une description d’un ensemble d’objets Voiture
qui partagent les mêmes attributs,
Marque : chaîne
opérations, méthodes, relations et
contraintes. Modèle : chaîne
Une classe peut posséder des attributs Immatriculation : chaîne (8)

ou des méthodes «de classe». 1re immatriculation : date
Kilométrage : entier
Kilométrage-annuel ? ( )
34 amine.kordara@gmail.com Kilometrage_annuel_moyen ( ) 34
Liens diagramme d’objets -/- diagramme de
classes
Structure statique d’un système, en termes d’objets et de liens entre ces

objets.
Ces objets et ces liens possèdent des attributs qui possèdent des valeurs.
Un objet est une instance de classe et un lien est une instance d’association.
Nom de l’objet :
Classe
Personne collaborateur
Attributs = valeurs
âge : entier *
Etienne :
personne patron 1
âge = 35 patron emploie>
collaborateur
Jean-Luc :
personne
âge = 25 Diagramme de classes
Diagramme d ’objets
Diagramme de classes
Structure statique d’un système, en termes de classes et de relations entre ces
classes.
Voiture
Nom de classe Couleur
Attributs Cylindrée
exemple
Opérations () : Vitesse max
Démarrer ()
Accélérer ()
Syntaxe: Freiner ()
• nom_attribut : type_attribut = valeur initiale
• nom_opération (nom_argument : type_argument = valeur_par_défaut, …) :
type_retourné
Visibilité : trois niveaux de visibilité pour les attributs et les opérations:
• public (+) : élément visible à tous les clients de la classe
• protégé ( #) : élément visible aux sous-classes de la classe
• privé (-) : élément visible à la classe seule
Nommage des associations
constructeur véhicule
Construire> produit
fabricant <construit par
passager <Transporte véhicule

personne véhicule
conducteur Conduit> véhicule
propriétaire Possède> véhicule
employé <Emploie employeur

personne entreprise
directeur Dirige> société
actionnaire Possède> société
Multiplicité des associations
1 Un et un seul (obligatoire)
0 .. 1 Zéro ou un (optionnel)
m .. n De m à n (entiers)
* ou 0 .. * quelconque
1 .. * Au moins 1
Personne 0..* Employeur Société

Employé 1
Associations
Agrégation:
• Association transitive : si voiture est composée de moteur et si moteur est
composé de courroie alors voiture est composée de courroie
• Association non symétrique : si voiture est composée de moteur, moteur ne
peut pas être composé de voiture
• Association qui peut être réflexive : exemple, une fonction peut être composée
d’autres fonctions, un sous ensemble d’autres sous ensembles.
Rôle et multiplicité :
• Une classe a un rôle dans une association.
• Les rôles portent une information de multiplicité précisant le nombre
d ’associations auquel une instance d ’objet peut être associée. Les multiplicités
les plus courantes sont : 1 / 0..1 / m..n / * /0..* / 1..*
Classe-association
Permet de «qualifier» plus finement une association
Véhicule
+NumImmatriculation
Commande
+ChargeUtile
+Num-commande +PermisRequis
+date
+PoidsTotal
affrète 0..*
1..*
Véhicule PeriodeConduite
* SociétéTransport 0..1
+NumImmatriculation +t0
+NumSIRET conduit +tf
+ChargeUtile
traite +NomCommercial +kilometrage
+TypeTransport
affrète
0..1 0..1
1..*
SociétéTransport 0..1 0..*
conduit
+NumSIRET 1...2 Chauffeur
+NomCommercial
+TypeTransport Chauffeur +Nom
+Prénom
+Nom +Adresse
+Prénom +TypePermis
+Adresse
+TypePermis +KilometrageAnnée()
Placement des attributs et des associations
1 Etudiant Réalise > Travail

0..* 0..*
0..* 1
Diplôme Note
Mention - valeur
0..1
Chambre
Numéro
Placement des attributs et des associations
1 Etudiant Réalise > Travail

0..* 0..*
0..* 1
Diplôme Note
Mention - valeur
0..1
Chambre
Numéro
Contraintes
personne Est_titulaire> compte

0 .. *
1
{Ordonnée}
0 .. *
personne classe
Parent d ’élève
{Sous ensemble}
0 .. *
Délégués
0 .. *
personne université
Enseignants
{Ou-exclusif}
0 .. *
Etudiants
Agrégation
Livre Chapitre
1 .. *
1
{Ordonnée}
{Ordonnée}
1 .. *
Paragraphe
Composition
Homme 1 1 Tête
La composition traduit une dépendance existentielle forte.
Diagramme de classes : Relations entre classes
Agrégation : quand une classe fait partie d’une autre classe (agrégat -
composant)
Association : toute relation structurelle entre classes, autre que l’agrégation et la
généralisation
Généralisation (voir transparents UML2) : factorisation des éléments communs
d’un ensemble de classes dites sous-classes dans une classe plus générale dite
super-classe. Elle signifie que la sous-classe est un ou est une sorte de la
super-classe. Le lien inverse est appelé spécialisation
spécialisation
classe 2
généralisation
1 1..* 1 1..*
véhicule moteur
constructeur Construit par
classe 1
classe 3
agrégatio voiture camion avion

n
classe 4
Exemple de diagramme de
classes
Problème
Titre_Problème
Objectif Projet
Delai NomProjet
Prix NuméroPDM
NiveauPriorite DateDebutProjet
FicheEtude
Conclusion 1..* Induit 1 Projet()
Tes_infos?()
Problème() Nouv_Paramètres()
Tes_infos?() 1..* Créer_Problème()
Nou_Paramètres()
Créer_Etude() 1..*
LesProblèmes LesProjets
1
EstResoluPar Outil Simulation

0..*
Créer_Projet()
Etude 0..1
0..1 Modifier_Projet()
Titre_Etude ModifierParamètre_Projet()
NomPièce Créer_Problème()
ComplétéePar ButEtude Suivant Modifier_Problème()
TypeEtude ModifierParamètre_Problème()
0..* 0..*
Conclusion Créer_Etude()
LesEtudes Modifier_Etude()
1..*
Etude() ModifierParamètre_Etude()
Tes_infos() FaireAppelAUneAncienne_Etude()
Nouv_Paramètres() Conclure_Etude()
Créer_Cycle() Créer_Cycle()
Ajouter_Conclusion() Modifier_Cycle()
ModifierPramètre_Cycle()
Rajouter_Entité()
47 amine.kordara@gmail.com Conclure_Cycle() 47
Exercice :
 Un hôtel est composé d'au moins deux chambres. Chaque chambre
dispose d'une salle d'eau : douche ou bien baignoire. Un hôtel héberge des
personnes. Il peut employer du personnel et il est impérativement dirigé par
un directeur. On ne connaît que le nom et le prénom des employés, des
directeurs et des occupants. Certaines personnes sont des enfants et
d'autres des adultes (faire travailler des enfants est interdit). Un hôtel a les
caractéristiques suivantes : une adresse, un nombre de pièces et une
catégorie. Une chambre est caractérisée par le nombre et de lits qu'elle
contient, son prix et son numéro. On veut pouvoir savoir qui occupe quelle
chambre à quelle date. Pour chaque jour de l'année, on veut pouvoir
calculer le loyer de chaque chambre en fonction de son prix et de son
occupation (le loyer est nul si la chambre est inoccupée). La somme de ces
loyers permet de calculer le chi re d'a aires de l'hôtel entre deux dates.
Question : Donnez une diagramme de classes pour modéliser le problème
de l'hôtel
Correction
UML
Diagrammes de cas d’utilisation
Principaux éléments des diagrammes
de cas d’utilisation
 QUOI ?
 Avant tout développement, il convient de
répondre à la question :
 “A quoi va servir le logiciel ?”
 sous peine de fournir des effeorts
considérables en vain.
 En UML, on établit des Diagrammes de Cas
d’Utilisation pour répondre à cette question.
Diagrammes de Cas d’Utilisation
Principaux éléments :
Acteurs (bonhommes)
Cas d’utilisation (ellipses)
Acteurs
 Un acteur est une entité extérieure au système modélisé, et qui interagit directement avec lui.
 Acteurs non humains
 Les principaux acteurs sont les utilisateurs du système.
 En plus des utilisateurs, les acteurs peuvent être :
 Des logiciels déjà disponibles à intégrer dans le projet ;
 Des systèmes informatiques externes au système mais qui interagissent avec lui ;
 tout élément extérieur au système et avec lequel il interagit
 Pour identifier les acteurs, on se fonde sur les frontières du système.
Rôles et personnes physiques

 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.
 Exemples :
 Imen, mustapha ou abdelkader sont tous les Clients du point de vue d’un distributeur automatique
 En tant que webmestre, radia a certains droits sur son site, mais il peut également s’identifier en
tant qu’utilisateur quelconque, sous une autre identité
Cas d’utilisation
 Un cas d’utilisation est un service rendu à un

acteur : c’est une fontionnalité de son point
de vue.
Relations liant les acteurs
 Associations entre cas et acteurs
 Les acteurs demandant des services aux systèmes, ils sont le plus
souvent à l’initiative des échanges avec le système :
 ils sont dits acteurs primaires.
 Lorsqu’ils sont sollicités par le système (dans le cas de serveurs
externes par exemple), ils sont dits acteurs secondaires.
Relations liant les acteurs
 On représente une association entre un
acteur et un cas d’utilisation par une ligne
pleine.
Relations entre acteurs
 Il n’y a qu’un seul type de relation possible entre acteurs : la relation
de généralisation.
 Il y a généralisation entre un cas A et un cas B lorsqu’on peut dire : A est
une sorte de B. Exemple :
 Un directeur est une sorte de commercial : il peut faire avec le système tout
ce que peut faire un commercial, plus d’autres choses
Relations entre cas d’utilisation
Généralisation entre cas d’utilsation
 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 de programmation orientés objet.
 Cet héritage signifie que les éléments spécifiques héritent de tout ce qui
caractérise l’élément général : - Les associations avec des acteurs - Les
relations de dépendance - Les héritages déjà existant, dans lesquel
l’élément général jour le rôle d’élément plus spécifique
Réutilisation de cas d’utilisation
 Les relations d’inclusion et d’extension permettent d’isoler un
service réutilisable comme partie de plusieurs autres cas
d’utilisation :
 On parle alors de réutilisation.
 Le code développé pour implémenter le cas d’utiliation réutilisé est
d’emblée identifié comme ne devant être développé qu’une seule
fois, puis réutilisé.
Décomposition de cas d’utilisation
 Un cas d’utilisation ne doit jamais se réduire à une seule action : il
doit occasionner des traitements d’une complexité minimale.
 Toutefois, il peut arriver qu’un cas d’utilisation recouvre un
ensemble très important d’échanges et de traitements. Dans ce cas,
on peut utiliser les relations d’inclusion et d’extension.
Synthèse
Diagramme complet
Description textuelle de cas
d’utilisation
 Un nom ne suffit pas à comprendre le détail de ce que
recouvre un cas d’utilisation.
 Il est donc nécessaire d’adjoindre à chaque cas
d’utilisation une description détaillée. Cette description
est parfois textuelle et composée de plusieurs rubriques
dont les plus importantes sont :
 Le scénario nominal : enchaînement d’actions typiques
dans le cas où les choses se passent comme prévu.
 Les enchaînements alternatifs : enchaînements dans
des cas particuliers.
Exercice:
 Dans un établissement de formation, on désire gérer la
réservation des salles de cours ainsi que du matériel
pédagogique (ordinateur portable ou/et Vidéo
projecteur). Seuls les enseignants sont habilités à
effectuer des réservations (sous réserve de disponibilité
de la salle ou du matériel). Le planning des salles peut
quant à lui être consulté par tout le monde (enseignants
et étudiants). Par contre, le récapitulatif horaire par
enseignant (calculé à partir du planning des salles) ne
peut être consulté que par les enseignants. Enfin, il
existe pour chaque formation un enseignant responsable
qui seul peut éditer le récapitulatif horaire pour
l’ensemble de la formation. Modéliser cette situation par
un diagramme de cas d’utilisation
Correction
UML
Diagrammes d’activités
Exercice: «Distributeur de billets »
 Le client introduit sa carte dont la validité est
immédiatement vérifiée. Il est ensuite invité à saisir le
code de la carte. Après trois tentatives infructueuses, la
carte est avalée. Sinon le client peut indiquer le montant
qu'il désire retirer, le solde de son compte bancaire est
alors consulté pour s'assurer que le retrait est possible.
En cas de solde insuffisant, le client en est informé et
peut alors saisir un montant inférieur. Si le solde du
compte est suffisant, le distributeur restitue la carte et
délivre alors les billets accompagnés d'un reçu. Décrire
le fonctionnement de ce distributeur de billets via un
diagramme d’activités.
Correction :
UML
Diagrammes de séquences
Présentation du diagramme de séquence
 Éléments du diagramme de séquence
Acteurs
Objets (instances)
Messages (cas d'utilisation, appels d’opération)
 Principes de base : Représentation graphique de la

chronologie des échanges de messages avec le
système ou au sein du système
« Vie » de chaque entité représentée verticalement
Échanges de messages représentés horizontalement
Types de messages
1. Message synchrone:
 Dans un message synchrone, l’émetteur reste bloqué le temps
que le récepteur traite le message envoyé (Émetteur bloqué en
attente du retour);
 Un message synchrone se représente par une flèche en traits
pleins et à l’extrémité pleine Le retour se représente par une
flèche en pointillé.
Types de messages
1. Message asynchrone:
 Dans un message asynchrone : l’émetteur n’est pas bloqué lorsque
le récepteur traite le message envoyé.
 Un message asynchrone se représente par une flèche en traits
pleins et à l’extrémité ouverte
Types de messages
1. Message récursif :
 Un message récursif est un message qu’un objet s’envoie à lui-
même.
Types de messages
1. Message création/destruction d’un objet
 La création d’un objet est matérialisée par une flèche qui pointe
sur le sommet d’une ligne de vie.
 La destruction d’un objet est matérialisée par une croix qui
marque la fin de la ligne de vie de l’objet.
Types de messages
Message création/destruction d’un objet
Types de messages
Message création/destruction d’un objet
Dans la plupart des cas, la réception d’un message est suivie de
l’exécution d’une méthode d’une classe. Cette méthode peut
recevoir des arguments et la syntaxe des messages permet de
transmettre ces arguments.
Structures de contrôle:
 Le diagramme de séquences peut inclure un

certain nombre de structures:
 Les tests (alternatives)
 Répétitions (itérations, boucles)
Alternative
 Principe : Condition à l'envoi d'un message
 Notation :
Deux diagrammes
Alternative
 Principe : Condition à l'envoi d'un message
 Notation :
Deux diagrammes
Bloc alt
Boucle
Principe: Répéter un enchaînement de
messages
Notation :
Notes
Référence à un autre diagramme
Exemple:
Exercice
On s'intéresse à la modélisation dynamique de la gestion d'une
bibliothèque. Pour emprunter un livre, on a le scénario suivant :
1) L'adhérent se présente au comptoir et la bibliothécaire saisit la
fonctionnalité pour emprunter un livre de l'application.
2) D'abord, il faut vérifier si l'adhérent a le droit d'emprunter des livres
(carte valide, nombre de livres déjà empruntés ne dépasse pas un
seuil fixé, …).
3) En suite, il faut vérifier si le livre est disponible.
4) Si tout va bien, on crée un nouveau prêt avec la date de prêt et la
date de retour, associé avec l'adhérent et le livre choisit.
5) On rend le livre indisponible.
6) On incrémente le nombre de livres empruntés par l'adhérent. Etablir
le diagramme de séquence de ce scénario de cas d'utilisation
Emprunter livre.
Correction
UML
Diagrammes de déploiement
(« deployment diagram »)
Le diagramme de déploiement
 Les diagrammes de déploiement montrent la disposition
physique des matériels qui composent le système et la
répartition des composants sur ces matériels.
 Il est la description finale de la topologie du système car
il unit les facettes hardware et software du système.
 Dans ce type de diagramme, il devrait être possible
d’observer un nœud de la topologie et de voir les
composantes qui s ’y exécutent, et quelles structures
logiques sont implantées dans ces composantes.
Nœuds:
 Définition: C’est une unités physiques
(matérielles) dotées d ’une puissance de calcul
donnée (processeurs, imprimantes, lecteurs de
cartes, périphériques de communication, etc).
 Un nœud est représenté par un cube en trois
dimensions avec son nom à l ’intérieur.
 Les périphériques sont aussi représentés par
des nœuds avec un stéréotype ou au moins un
nom qui indique clairement que le nœud n ’en
est pas un de calcul.
Exemple d’un diagramme de déploiement
Merci pour votre
attention

Perfectionnement UML SBA 2023

Transféré par

Informations du document

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

Perfectionnement UML SBA 2023

Transféré par

Droits d'auteur :

Formats disponibles

RÉPUBLIQUE ALGÉRIENNE DÉMOCRATIQUE ET POPULAIRE

IFEP SENHADRI ABDELHAFID

Méthodologie De Modélisation applications Web

UML2.2 : Unified Modeling Language

Présenter par : Mr KORDARA Mohamed El’amine 1

 Cycle de vie d’un logiciel

 Comparaison entre MERISE et UML

 Présentation du langage UML

 Diagramme de cas d'utilisation

 Processus (ensemble d’activités) nécessaire

 Elle a pour but de dégager le problème à

 Première étape du cycle de vie d’un logiciel

 Est-ce que le développement proposé vaut la

►► Étudier le marché pour déterminer s’il

 Permet de définir ce que doit faire le logiciel et

La spécification générale consiste à identifier :

 Contraintes (utilisation du matériel et outils

Spécification fonctionnelles est la description des

Spécification d’interface décrit les interfaces du

Spécification technique :(Étude de l’existant)

 Quantité d’informations à stocker (choix du

 Appelée aussi Planification et gestion de projet

 Permet de fournir une description fonctionnelle

 Appelée aussi : ‘Conception architecturale’

 Bibliothèque (Ouvrages, auteurs, adhérents, …)

 Produire une description externe de chacune

 Des programmes seront élaborés afin de

On distingue plusieurs types de tests :

 Fournir au client une solution logiciel qui

 Mettre à jour et améliorer le logiciel

 Cahier des charges : description des fonctionnalités

 Calendrier du projet: indique les tâches, les

 Code source: code complet du produit fini

Web - June ´96 UML 0.9

OOPSLA ´95 Unified Method 0.8

Other methods Booch method OMT OOSE

UML(Unified Modeling Language) un

 UML est caractérisé par :

 ne définit pas le processus d'élaboration des

Collaboration Composants Déploiement Activité Objets

UML définit deux types de diagrammes, structurels

Les diagramme d’UML peuvent être utilisés pour

 Vue de déploiement : répartition des composants

Classes Vue logique statique Vue Implémentation

Une classe peut posséder des attributs Immatriculation : chaîne (8)

Structure statique d’un système, en termes d’objets et de liens entre ces

Nom de classe Couleur

passager <Transporte véhicule

propriétaire Possède> véhicule

employé <Emploie employeur

actionnaire Possède> société

Personne 0..* Employeur Société

1 Etudiant Réalise > Travail

1 Etudiant Réalise > Travail

personne Est_titulaire> compte

La composition traduit une dépendance existentielle forte.

agrégatio voiture camion avion

EstResoluPar Outil Simulation

Rôles et personnes physiques

 Un cas d’utilisation est un service rendu à un

 Principes de base : Représentation graphique de la

 Le diagramme de séquences peut inclure un

Vous aimerez peut-être aussi