Licence Sciences :

Informatique Fondamentale && Intelligence Artificielle

Semestre 5

Cours Modélisation objet :

Le langage UML

Professeur : LAASSIRI Jalal / [email protected]

Faculté des Sciences de Kénitra

Département d’informatique

1
 Plan du cours

• Les concepts d’UML

– UML
• Introduction au langage UML
• Vue structurelle (Diagramme de classes / Diagramme d’objets)
• Vue fonctionnelle (Diagramme des cas d’utilisation / Diagramme de
collaboration / Diagramme de séquence)
• Vue dynamique (Diagramme d’états-transitions / Diagramme
d’activité)
• Vue compositionelle (Les composants et le diagramme de composants)
– OCL
• Introduction au langage OCL
• Syntaxe
– Les outils : Objecteering, Rose et les autres
• Méthodologie et Design Pattern
– Méthodologie :
• la conception d’une application passe par une méthode
• Le test
– Design Pattern
– L’approche MDA, …

pr. LAASSIRI Jalal / Dept 2

 Les concepts d’UML
- UML – Génie logiciel

pr. LAASSIRI Jalal / Dept 3

pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
 La complexité des logiciels

• Les systèmes peuvent être décomposés selon

– ce qu’ils font (approche fonctionnelle)
– ce qu’ils sont (approche objet)

• L’approche objet gère plus efficacement la complexité

– Modèles basés sur le monde réel  stabilité
– Structure indépendante des fonctions  évolutivité
– Approche modulaire  maintenance, réutilisabilité

6
 Étapes classiques d’un processus de développement logiciel
1.Analyse des besoins
1. Compréhension des attentes des utilisateurs et du client.
2. Rédaction du cahier des charges / spécifications fonctionnelles.
2.Conception (Design)
1. Conception globale (architecture du système).
2. Conception détaillée (modules, bases de données, UML).
3.Implémentation (Codage)
1. Transformation de la conception en code source.
2. Respect des normes de programmation.
4.Tests
1. Tests unitaires (chaque module).
2. Tests d’intégration (modules combinés).
3. Tests système et validation (avec l’utilisateur).
5.Déploiement
1. Mise en production.
2. Formation des utilisateurs.
6.Maintenance et évolution
1. Correction de bugs.
2. Amélioration et ajout de nouvelles fonctionnalités.
3. Adaptation aux changements techniques (mises à jour).
 Modèles de développement logiciel (processus)
1. Modèle en cascade (Waterfall)
•Étapes séquentielles : analyse → conception → codage → test → déploiement.
•Simple mais rigide, peu flexible face aux changements.
2. Modèle en V
•Similaire à la cascade mais avec tests associés à chaque étape.
•Accent sur la vérification et validation.
3. Modèle incrémental
•Développement par petits incréments (fonctionnalités ajoutées progressivement).
4. Modèle itératif
•Développement par versions successives, avec retours fréquents des utilisateurs.
5. Méthodes agiles (Scrum, XP, Kanban, …)
•Développement adaptatif et collaboratif.
•Cycles courts appelés sprints.
•Forte implication du client.
6. Modèle spiral
•Combine l’itératif et l’approche gestion des risques.
 Processus en cascade
Chaque étape doit être terminée avant que ne commence la suivante

À chaque étape, production d'un document base de l'étape suivante

Spécification Cahier des charges

fonctionnel

Conception Dossier de

conception détaillée

Programmation
Code documenté +
et test unitaire
Rapport de tests unitaires

Intégration
et test système Rapport de validation

Livraison
et maintenance
 Processus en cascade
Caractéristiques:
Hérité des méthodes classiques d'ingénierie
Découverte d'une erreur entraîne retour à la phase à l'origine de
l'erreur et nouvelle cascade, avec de nouveaux documents...
Coût de modification d'une important, donc choix
•
erreur en

amont cruciaux (typique d'une production industrielle)

Pas toujours adapté à une production logicielle, en particulier si

besoins du client changeants ou difficiles à spécifier
 Notation unifiée UML

OOD (Object-Oriented Design) de Grady Booch, définie pour le

Department of Defense, introduit le concept de paquetage (package) ;

OMT (Object Modeling Technique) de James Rumbaugh (General Electric)

fournit une représentation graphique des aspects statique, dynamique et
fonctionnel d'un système ;

OOSE(Object-oriented software engineering) d'Ivar Jacobson (Ericsson)

fonde l'analyse sur la description des besoins des utilisateurs (cas
d'utilisation, ou use cases).

pr. LAASSIRI Jalal / Dept 17

 Genèse d’UML
OMT • Utilisation d’un standard de modélisation « universel »
Booch • Au départ, plus de 150 méthodes !!
• Unification progressive de plusieurs méthodes, de remarques des utilisateurs,
OOSE
des partenaires
Fusion • 1989 : création de l’OMG (Object Management group) ; groupe créé à
Classe-Relation l’initiative de grandes sociétés informatiques américaines afin de normaliser
les systèmes à objets ; 1ère réalisation de l’OMG : CORBA (communication
ROOM entre applications objets dans un système distribué hétérogène)
HOOD

etc... UML 2.0

Rational OMG …
Fin 1990 UML 1.4
1995 Fin 2001
OMT UML 1.3
(Rumbaugh et al.) Unified Method
0.8 1996 Juin 1999
Booch UML 1.1
UML 0.9 Nov. 1997
OOSE
(Jacobson et al.)

Catalysis ROOM etc.

pr. LAASSIRI Jalal / Dept 18

 Axes de modélisation d ’un système

Statique (ce que le système EST)

• diagramme de classes
• diagramme d’objets
• diagramme de composants
• diagramme de déploiement
Dynamique
(comment le système
EVOLUE) Fonctionnel
(ce que le système FAIT)
• diagramme de séquence
• diagramme de collaboration • diagramme de cas d’utilisation
• diagramme d’états-transitions • diagramme de collaboration
• diagramme d’activités

pr. LAASSIRI Jalal / Dept 25

 Références
• http://www.OMG.org : les normes UML, OCL, MDA, …
• Modélisation objet avec UML, PA. Muller, N. Gaertner, ed. Eyrolles
• http://uml.free.fr : UML en français
• The Unified software development process, I. Jacobson, G. Booch, J.
Rambaugh, ed. Addison-Wesley, 1999
• Design Patterns: Elements of reusable Object Oriented Software, E.
Gamma, R. Helm, R. Johnson, J. Vlissides, ed. Addison-Wesley, 1994

• D’autres cours sur le web :

– http:// www-igm .univ-mlv .fr/ ~dr/DESS/Elaboration/siframes.htm
– http://www.iutc3.unicaen.fr/~moranb/cours/acsi/ menucoo.htm
– http://www.cnamversailles.fr/ress_uv_pres/prog_oo/Ressources%peda
gogiques/NotationUML-0399.ppt

pr. LAASSIRI Jalal / Dept 28

 Exemples d’outils
Gratuits / Open Source
•StarUML
Léger, multiplateforme, supporte UML 2.x, génération de code (Java, C++…).
•Modelio
Outil open source français, supporte UML, BPMN, génération de code, ingénierie inverse.
•Umbrello (KDE)
Principalement sous Linux, diagrammes UML classiques, export de code.
•ArgoUML
Ancien mais encore utilisé pour l’enseignement.
•PlantUML
Basé sur du texte → génère des diagrammes UML (utilisé dans Git, Markdown, Docs
techniques).
Professionnels / Payants
•Enterprise Architect (Sparx Systems)
Très complet, largement utilisé en industrie, supporte UML, SysML, BPMN.
•IBM Rational Rose / Rational Software Architect
Ancien leader du marché pour grands projets logiciels.
•Visual Paradigm
Supporte UML, Agile, gestion de projet, génération de code, ingénierie inverse.
•MagicDraw (No Magic)
Très puissant pour UML et SysML (souvent utilisé en systèmes critiques).
 Les objets

• Les objets du monde réel nous entourent, ils naissent, vivent et meurent.

• Les objets informatiques définissent une représentation simplifiée des entités du

monde réel.

• Les objets représentent des entités

– concrètes : avec une masse
– abstraites : concept

pr. LAASSIRI Jalal / Dept 30

 Les objets sont des abstractions

• Une abstraction est un résumé, un condensé

• Mise en avant des caractéristiques essentielles
• Dissimulation des détails
• Une abstraction se définit par rapport à un point de vue

• Exemples d’abstractions
– Une carte routière
– Un nombre complexe
– Un téléviseur
– Une transaction bancaire
– Une porte logique
– Une pile
– Un étudiant

pr. LAASSIRI Jalal / Dept 31

 Caractéristiques fondamentales des objets

• Objet = État + Comportement + Identité

• Communication entre objets

pr. LAASSIRI Jalal / Dept 32

 L’état

• L’état d’un objet :

– regroupe les valeurs instantanées de tous les attributs d’un objet
– évolue au cours du temps
– à un instant donné est la conséquence de ses comportements passés

• Exemples
– Pour un signal électrique : l’amplitude, la pulsation, la phase, …
– Pour une voiture : la marque, la puissance, la couleur, le nombre de
places assises, …
– Pour un étudiant : le nom, le prénom, la date de naissance, l'adresse,
…

pr. LAASSIRI Jalal / Dept 33

 Le comportement

• Le comportement
– décrit les actions et les réactions d’un objet
– regroupe toutes les compétences d’un objet
– se représente sous la forme d’opérations (méthodes)

• Un objet peut faire appel aux compétences d’un autre objet

• L’état et le comportement sont liés

– Le comportement dépend de l’état
– L’état est modifié par le comportement

pr. LAASSIRI Jalal / Dept 34

 L’identité

• Tout objet possède une identité qui lui est propre et qui le caractérise
• L’identité permet de distinguer tout objet de façon non ambiguë,
indépendamment de l’état
• Il est possible de définir une contrainte d’unicité
• Une clé primaire dans une base de donnée relationnelle est une manière de
réaliser l’identité (en l’insérant dans l’état)

pr. LAASSIRI Jalal / Dept 35

 Communication entre objets

• Application = société d'objets collaborant

• Les objets travaillent en synergie afin de réaliser les fonctions de l’application
• Le comportement global d’une application repose donc sur la communication
entre les objets qui la composent

• Les objets
– ne vivent pas en ermites
– Les objets interagissent les uns avec les autres
– Les objets communiquent en échangeant des messages

pr. LAASSIRI Jalal / Dept 36

 Communication (suite)

• Catégories de messages :

– Constructeurs : créent des objets

– Destructeurs : détruisent des objets
– Accesseurs : renvoient tout ou partie de l’état
– Modifieurs : changent tout ou partie de l’état
– Itérateurs : traversent une collection d’objets

pr. LAASSIRI Jalal / Dept 37

 Les classes

• La classe
– est une description abstraite d’un ensemble d’objets
– peut être vue comme la factorisation des éléments communs à un
ensemble d’objets
– décrit le domaine de définition d’un ensemble d’objets

• Description des classes

– Séparée en deux parties
•La spécification d’une classe qui décrit le domaine de définition et les
propriétés des instances de cette classe (type de donnée)
•La réalisation qui décrit comment la spécification est réalisée

pr. LAASSIRI Jalal / Dept 38

 Conclusion

• Les objets naissent, vivent et meurent

• Les objets interagissent entre eux

• Les objets sont regroupés dans des classes qui les décrivent de manière abstraite

• La classe intègre les concepts de type et de module

pr. LAASSIRI Jalal / Dept 39

UML : Vue structurelle
- Diagramme de classes -

pr. LAASSIRI Jalal / Dept 40

 Définitions
• Structure statique d’un système
– Classes (ensembles d’objets)
– Relations entre classes (ensembles de liens entre objets)

• Opérations / méthodes
– Opération : service qui peut être demandé à n’importe quel objet de
la classe.
– Méthode : implémentation d’une opération.
– Chaque opération non abstraite d’une classe doit avoir une méthode
qui fournit un algorithme exécutable comme corps (cet algorithme
est donné dans un langage de programmation ou dans du texte
structuré).

pr. LAASSIRI Jalal / Dept 41

 Niveau de détail d’analyse

Spécification : plusieurs niveaux de détails :

– Niveau de détail d’analyse
Pas de précision sur la mise en œuvre
Indépendant du logiciel
Plusieurs niveaux de précision au fil des itérations d’analyse

• simplifié
–Uniquement le nom de la classe NomClasse

•intermédiaire NomClasse
–Nom de la classe attribut1 NomClasse
–Nom des attributs, ou des opérations attribut2
attribut3 attribut1
… attribut2
•complet attribut3
–Nom de la classe …
–Noms des attributs
Opération1
–Noms des méthodes
Opération2
…

pr. LAASSIRI Jalal / Dept 42

 Niveau de détail de conception

– Niveau de détail de conception

Identification de l’interface des classes :
type des objets, comportement externe, façon interne de les mettre en
œuvre Indépendant du logiciel

•Attributs :
–Type
–Valeurs par défaut
–Degré de visibilité NomClasse
–Caractéristique - Attribut1 : type1
# Attribut2 : type2 = valeur2
•Opérations :
# /Attribut3 : type3
–Signature …
–Degré de visibilité
+ Opération1 (arg1, arg2,…) : type4
–Caractéristique
# Opération2 () : void
…

pr. LAASSIRI Jalal / Dept 43

 Notation des attributs et opérations

Nom de classe
Attributs

Opérations( )

• Attribut
<visibilité> <nomAttribut> : <type> = <valeur par défaut>

• Opération
<visibilité> <nomOpération> (listeParamètres) : <typeRetour>
Paramètre
<nom> : <type> = <valeur par défaut>

pr. LAASSIRI Jalal / Dept 44

 Visibilité

Visibilité = degré de protection

+ : publique (accessible à toutes les classes)
les classes peuvent accéder aux données et méthodes d'une
classe définie avec le niveau de visibilité public
# : protégé (accessibles uniquement aux sous-classes)
l'accès aux données est limité aux méthodes de la classe elle-
même
- : privé (inaccessible à tout objet hors de la classe)
Pas de visibilité
par défaut NomClasse

+ Attribut publique
# Attribut protégé
- Attribut privé

+ Opération publique
# Opération protégée
- Opération privée

pr. LAASSIRI Jalal / Dept 45

 Type

• Attribut
• type de base (entier, booléen, caractère, tableau…)
integer, double, char, string, boolean, date, time, void
• Au niveau analyse, pas d’attribut instance d’une classe (on utilise
une association)
• Au niveau conception, on décide quelles associations peuvent être
représentées par des attributs

• Opération
• Type quelconque (de base ou classe)

pr. LAASSIRI Jalal / Dept 46

 Valeur par défaut des attributs

• Affectée à l’attribut à la création des instances de la classe

• En analyse, on se contente souvent d’indiquer le nom des attributs

Voiture

- Marque : string
- Modèle : string
- Turbo : boolean = false

+ Démarrer ()
+ Rouler ()
+ Freiner ()

pr. LAASSIRI Jalal / Dept 47

 Attributs et opérations de classe

• Notation : nomAttribut ou nomOpération

• Attribut partagé par toutes les instances de la classe
• Opération sur des attributs de classes

Voiture

- Marque : string
- Modèle : string
- Turbo : boolean = false
- NbRoues : int = 4
- NbInstances = 0

+ Démarrer ()
+ Rouler ()
+ Freiner ()
+ IncrémenterNbInstances ()

pr. LAASSIRI Jalal / Dept 48

 Exemples / niveaux d’abstraction

voiture voiture
immatriculation + immatriculation : string
couleur + couleur : string
marque + marque : string
puissance # puissance : int attributs
poids # poids : int types
date - date : Date
propriétaire - propriétaire : string
demarrer + demarrer()
arreter - contact() : bool
conduire + conduire(a : string = « kenitra », b : string) méthodes
voiture prototype
vendre + vendre(prix : float)

Niveaux d’accès
Classe non documentée Classe documentée Classe détaillée

UML 46
pr. LAASSIRI Jalal / Dept 49
 Attributs et opérations dérivés

• Notation : /nomAttribut
• Propriété redondante, dérivée d’autres propriétés déjà allouées
• En conception, un attribut dérivé peut donner lieu à une opération qui
encapsulera le calcul effectué

Commande Commande
Numéro Numéro
PrixHT PrixHT
TVA TVA
/PrixTTC /PrixTTC

CalculerPrixTTC ()

pr. LAASSIRI Jalal / Dept 50

 Sémantique

Un diagramme de classes est une collection d'éléments de modélisation

statiques (classes, paquetages...), qui montre la structure d'un modèle

Un diagramme de classes fait abstraction des aspects dynamiques et temporels

Pour un modèle complexe, plusieurs diagrammes de classes complémentaires

doivent être construits
On peut par exemple se focaliser sur :
les classes qui participent à un cas d'utilisation (cf. collaboration)
les classes associées dans la réalisation d'un scénario précis
les classes qui composent un paquetage
la structure hiérarchique d'un ensemble de classes

UML 48
pr. LAASSIRI Jalal / Dept 51
 Les relations entre classes

• L’association
• L’agrégation
• La généralisation

pr. LAASSIRI Jalal / Dept 52

 L’association

• L’association exprime une connexion sémantique entre classes

• La plupart des associations sont binaires : connectent 2 classes
• Notation :

Classe1 Classe2

Université Étudiant

pr. LAASSIRI Jalal / Dept 53

 Association n-aire
Salle
• Représentation au niveau de
l’association

Enseignant  Étudiant

Cours
Début
Fin
• Représentation au moyen d’une
classe
+ contrainte qui exprime que
les multiples branches de
Salle
l’association s’instancient
simultanément en un même lien
<< assoc. Ternaire>>

Enseignant Cours Étudiant

Début
Fin

pr. LAASSIRI Jalal / Dept 54

 Association qualifiée

Une association qualifiée met en relation deux classes sur la base d’un attribut
spécifique appelé « clé »

* 1..n
Banque numCompte Personne

52
pr. LAASSIRI Jalal / Dept 55
 Nommage des associations

• Indication du sens de lecture de l’association

• Une association peut se lire dans les 2 sens, en fonction des besoins
• Usage : forme verbal, active ou passive – Pb : confusion avec le comportement
nommage des extrémités : plus en phase avec la représentation statique

NomAssoc >
Classe1 Classe2

Emploie >
Société Personne

< Est employé par

Société Personne

pr. LAASSIRI Jalal / Dept 56

 Nommage des rôles

• Le rôle décrit comment une classe voit une autre classe à travers une
association
• Une association a par essence 2 rôles, selon le sens dans lequel on la
regarde
• Usage : Forme nominale

Rôle1
Classe1 Classe2
Rôle2

Société Employeur
Personne Parent
Employé
Personne
Directeur
Société Personne Enfant
Employé

pr. LAASSIRI Jalal / Dept 57

 Principales contraintes

Contrainte {ordonnée} : une relation d’ordre décrit les

objets

Contrainte {sous-ensemble} : une collection est incluse

dans une autre collection

Contrainte {ou-exclusif} : pour un objet donné, une

seule association est valide

UML 55
pr. LAASSIRI Jalal / Dept 58
 Exemples

Peintre Tableau
1 peint 1..n
{ordonnée}

Personne Armée
militaire

{sous-ensemble}
général

Personne Licence
enseignant
{ou-exclusif}

étudiant
56
pr. LAASSIRI Jalal / Dept 59
 Multiplicité

• Chaque rôle porte une indication de multiplicité : nombre d’objets

de la classe considérée pouvant être liés à un objet de l’autre classe
• Information portée par le rôle

Rôle1 m2
Classe1 Classe2
m1 Rôle2

Valeur : signification :
1 Un et un seul
0..1 Zéro ou un
M .. N De M à N (entiers naturels)
* De zéro à plusieurs
0 .. * De zéro à plusieurs
1 .. * D'un à plusieurs

pr. LAASSIRI Jalal / Dept 60

pr. LAASSIRI Jalal / Dept 61
 Lecture d’un association

« Un employeur emploi plusieurs personnes »

*
Société SonEmployeur
1 SesEmployés Personne

« Un employé est employé par un seul employeur »

pr. LAASSIRI Jalal / Dept 62

 Les restrictions

• Une restriction (ou qualification) consiste à sélectionner un sous-ensemble

d’objets parmi l’ensemble des objets qui participent à une association

Classe A Clé Classe B

• Exemple :

*
Échiquier Case

Ligne 1
Échiquier Case
Colonne

pr. LAASSIRI Jalal / Dept 63

 Classe associative

• Ensemble d’attributs qualifiant la relation

SesÉtudiants *
Étudiant SesMatières
Matière
*

Moyenne
• Représentation simplifiée

Étudiant Moyenne Matière

pr. LAASSIRI Jalal / Dept 64

 L’agrégation(1)

• Connexions bidirectionnelles dissymétriques

– une des extrémités est prédominante par rapport à l’autre
– Ne concerne qu’un seul rôle
• Représentation des relations de type :
– tout et parties
– composé et composants
– maître et esclaves
• Deux type d’agrégation :
– Agrégation partagée (par référence) – notion de co-propriété
•La création (resp. la destruction) des composants est indépendante de la création
(resp. la destruction) du composite.
•Un objet peut faire partie de plusieurs composites à la fois.
– Composition (par valeur) :
•Cas particulier de l’agrégation : attributs contenus physiquement par l’agrégat
•La création (resp. la destruction) du composite entraîne la création (resp. la
destruction) des composants.
•Un objet ne fait partie que d’un seul composite à la fois.

pr. LAASSIRI Jalal / Dept 65

 Exemples

• Agrégation

CoPropriétaire 0..*
Personne  Immeuble
Immeuble
1..*

• Composition

Voiture
Moteur Voiture  1
Moteur

* 1
Cylindre Carburateur

pr. LAASSIRI Jalal / Dept 66

 L’agrégation(2)

 

pr. LAASSIRI Jalal / Dept 67

 Navigabilité d’une association

• Qualité d’une association qui permet le passage d’une classe vers une autre
• Par défaut, on peut naviguer dans les 2 sens
• On peut cependant limiter la navigabilité :

Classe 1 Classe 2
• Exemple :
Une instance d’utilisateur peut accéder à des instances
de Mot de passe, mais pas l’inverse.

Utilisateur
détenteur * Mot de passe
1 clef

pr. LAASSIRI Jalal / Dept 68

 Méthode - 1ers attributs
PRODUIT
• Attributs décrivant l'objet
- Nom : string
- Description : string • Attributs de classes
- Poids : float
- PrixHT : float • Attributs dérivés
- TauxTaxe : float = 19,6
- /PrixTTC : float
- TauxFrancs : float = 6,5559
- /PrixTTCFrancs : float

pr. LAASSIRI Jalal / Dept 69

 Méthode - 1ères méthodes
PRODUIT
• Constructeur (s)
- Nom : string
- Description : string • Accesseurs (1 pour chaque attribut)
- Poids : float
- PrixHT : float • Calcul des attributs dérivés
- TauxTaxe : float = 19,6
- /PrixTTC : float
- TauxFrancs : float = 6,5559
- /PrixTTCFrancs : float

+ PRODUIT (nom : string, description :

string, poids : float, prixHT : float) :
PRODUIT

+ GetNom () : string
+ GetDescription () : string
+ GetPoids () : float
+ GetPrixHT () : float
+ GetTauxTaxe () : float
+ GetPrixTTC () : float
+ GetTauxFrancs () : float
+ GetPrixTTCFrancs () : float
+ GetSesPaniers () : ensemble(PANIER)

+ CalculerPrixTTC () : void
+ CalculerPrixTTCFrancs () : void

pr. LAASSIRI Jalal / Dept 70

 Méthode - Autres méthodes
PRODUIT
• Modifieurs
- Nom : string
- Description : string – Publics
- Poids : float
- PrixHT : float – Privés
- TauxTaxe : float = 19,6
- /PrixTTC : float • Autres méthodes
- TauxFrancs : float = 6,5559
- /PrixTTCFrancs : float

+ PRODUIT (nom : string, description :

string, poids : float, prixHT : float) :
PRODUIT
+ GetNom () : string
+ GetDescription () : string
+ GetPoids () : float
+ GetPrixHT () : float
+ GetTauxTaxe () : float
+ GetPrixTTC () : float
+ GetTauxFrancs () : float
+ GetPrixTTCFrancs () : float
+ GetSesPaniers () : ensemble(PANIER)
+ CalculerPrixTTC () : void
+ CalculerPrixTTCFrancs () : void

+ SetPrixHT (prixHT : float) : void

- SetTauxTaxe (taux : float) : void

pr. LAASSIRI Jalal / Dept 71

 Méthode - Associations et rôles
PRODUIT
PANIER
- Nom : string
- Description : string - /PrixTTC : float
- Poids : float - /Poids : float
- PrixHT : float - /PrixTTCFrancs : float
- TauxTaxe : float = 19,6
- /PrixTTC : float *
- TauxFrancs : float = 6,5559 SesProduits
- /PrixTTCFrancs : float

+ PRODUIT (nom : string, description :

string, poids : float, prixHT : float) : + PANIER (unProduit : PRODUIT) :
PRODUIT PANIER

+ GetNom () : string + GetPrixTTC () : float

+ GetDescription () : string + GetPoids () : float
+ GetPoids () : float + GetPrixTTCFrancs () : float
+ GetPrixHT () : float + GetSesProduits () : ensemble(Produit)
+ GetTauxTaxe () : float
+ GetPrixTTC () : float + CalculerPrixTTC () : void
+ GetTauxFrancs () : float + CalculerPoids () : void
+ GetPrixTTCFrancs () : float + CalculerPrixTTCFrancs () : void

+ CalculerPrixTTC () : void + AjouterAuPanier (unProduit : PRODUIT) :

+ CalculerPrixTTCFrancs () : void void
+ SupprimerDuPanier (unProduit :
+ SetPrixHT (prixHT : float) : void PRODUIT) : void

pr. LAASSIRI Jalal / Dept 72

 Méthode - Version "light"
PRODUIT
• Attributs
Nom
Description – Explicite : nom
Poids
PrixHT – Implicite :
TauxTaxe
/PrixTTC •Visibilité privée
TauxFrancs •Type, valeur par défaut
/PrixTTCFrancs
• Méthodes
+ SetPrixHT (prixHT : float) : void
– Explicite : méthodes spécifiques
– Implicite :
•Constructeur
•Accesseurs "GetToto" (1 par
attribut et rôle)
•Modifieurs privés "SetToto"
•Calcul des attributs dérivés

pr. LAASSIRI Jalal / Dept 73

 Hiérarchies de classes

• Gérer la complexité
Arborescences de classes d’abstraction croissante
• Généralisation : Super-classes
• Spécialisation : Sous-classes

Classe plus
Super-classe générale

Classe plus
Sous-classe
spécialisée

pr. LAASSIRI Jalal / Dept 74

 Généralisation

Factoriser les éléments communs

attributs, opérations et contraintes

Abstraction plus générales

Véhicule

Véhicule terrestre Véhicule aérien

Voiture Camion Avion Hélicoptère

pr. LAASSIRI Jalal / Dept 75

 Spécialisation

Extension cohérente d'un ensemble de classes

Transmission

Continue Discrète

Variateur Dérailleur Boîte de vitesses

Extension par spécialisation

pr. LAASSIRI Jalal / Dept 76

 Propriétés de la généralisation

Signifie toujours : est un ou est une sorte de

Animal

Carnivore Herbivore

Lion Mouton Lapin

pr. LAASSIRI Jalal / Dept 77

 Propriétés de la généralisation

Non-réflexive, non-symétrique, transitive

A A

A
Impossible !!!
C

BC Impossible !!!

pr. LAASSIRI Jalal / Dept 78

 Généralisation multiple

Animal

Station Protection
Nourriture
Bipède Quadrupède Herbivore Carnivore A plumes A poils A écailles

Lapin

pr. LAASSIRI Jalal / Dept 79

 L’héritage

• Technique la plus utilisée pour réaliser la généralisation

• Construire une classe à partir d’une ou plusieurs autres classes, en partageant
des attributs, des opérations et parfois des contraintes, au sein d'une hiérarchie
de classes.

pr. LAASSIRI Jalal / Dept 80

 Exemple

CompteBancaire
Généralisation Spécialisation
crédit : nombre
débit : nombre
déposer(nombre)
retirer(nombre)
donner-solde

CompteÉpargne
taux :nombre
calculer-intérêts

pr. LAASSIRI Jalal / Dept 81

Héritage Multiple (Exemple)

pr. LAASSIRI Jalal / Dept 82

 Classe et Opération abstraites

• Classe qui ne peut avoir aucune instance directe ; on écrit son nom en italique

• Opération incomplète qui a besoin de sa classe fille pour fournir une

implémentation ; on écrit son nom en italique.

Forme

-Nom : string
+Calc-surface()
+Get-nom()

pr. LAASSIRI Jalal / Dept 83

 Polymorphisme

Forme

-Nom : string
+Calc-surface()
+Get-nom()

Rectangle Cercle
-Longueur : real -Rayon : real
-Largeur : real
+Calc-surface()
+Calc-surface()
Opération
polymorphe

pr. LAASSIRI Jalal / Dept 84

 Conclusion

• Les classes sont connectées par des relations

• L’association exprime une connexion sémantique
• L’agrégation est une forme d’association plus forte
• La généralisation permet d’ordonner les objets au sein de hiérarchies de classes

pr. LAASSIRI Jalal / Dept 85

UML : Vue structurelle
- Diagramme d’objets -

pr. LAASSIRI Jalal / Dept 86

 Définition

• Ils modélisent les instances d’éléments qui apparaissent sur les diagrammes de
classe.
• Ils montrent un ensemble d ’objets et leurs relations à un moment donné.
– Instances nommées

– Instances anonymes bouton1:Rectangle bouton2:

:Cercle
– Instances avec valeurs d’attributs

bouton3:Rectangle
Nom : string=“bouton-poussoir”
Longueur : real=13.5
Largeur : real=3.2

pr. LAASSIRI Jalal / Dept 87

 Association/Lien

• Une association est une abstraction des liens qui existent entre les objets
instances des classes associées
• Les associations se représentent de la même manière que les liens.

Une association
Université Étudiant

Amine Taki : Étudiant

Un lien
Ibntofail : Université
Un lien
Jamal kenitri : Étudiant

MohamedV : Université
Un lien
Latifa : Étudiant

pr. LAASSIRI Jalal / Dept 88

 Exemple

enseigne
Enseignant Matière
* 1..*

Laassiri:Enseignant
Génie-Logiciel:Matière

Hadi:Enseignant Réseaux:Matière

Système:Matière
Fakhri:Enseignant

pr. LAASSIRI Jalal / Dept 89

 UML : Vue fonctionnelle
- Diagramme des cas d’utilisation -

pr. LAASSIRI Jalal / Dept 90

 Objectifs

• Expression du comportement du système selon le point de vue de l’utilisateur

• Interaction entre le système informatique à développer et un utilisateur (ou
acteur) interagissant avec le système.
• Description d’une séquence d'actions réalisées par le système et qui produit un
résultat observable pour un acteur

pr. LAASSIRI Jalal / Dept 95

Relation d’inclusion <<Extends>> (1)
Relation d’inclusion <<include>> (1)
 Relation d’inclusion <<include>> (2)

<<include>> permet d’incorporer le comportement d’un autre cas d’utilisation

Monopoly

<<include>>

Joueur Jouer un coup Lancer les dés

Distribuer l'argent Banquier

pr. LAASSIRI Jalal / Dept 106

 Relation d’inclusion <<include>> (2)

<<include>> permet d’incorporer le comportement d’un autre cas d’utilisation

Monopoly

<<include>>

Joueur Jouer un coup Toucher de l'argent

<<include>>

Distribuer l'argent Banquier

pr. LAASSIRI Jalal / Dept 107

 Relation d’extension <<extend>>(2)

<<extend>> permet de modéliser la partie d’un cas d’utilisation considérée

comme facultative dans le comportement du système (cas d’exception)

Monopoly

<<extend>>

Joueur Jouer un coup Fin de partie

Distribuer l'argent Banquier

pr. LAASSIRI Jalal / Dept 108

 Relations entre cas d’utilisation

Relation d’utilisation : <<include>>

Le cas d’utilisation contient un autre cas d’utilisation
Relation d’extension : <<extend>>
Le cas d’utilisation étend (précise) les objectifs (le comportement) d’un autre
cas d’utilisation

UML 119
pr. LAASSIRI Jalal / Dept 109
 Exemple

Virement par internet

Client distant
<<extend>>

Virement

Client <<include>>
<<include>>

Identification Vérification solde

UML 120
pr. LAASSIRI Jalal / Dept 110
 Exemple 2 : La CBM

• La CBM (Computer Books by Mail) est une société de distribution d'ouvrages

d'informatique qui agit comme intermédiaire entre les librairies et les éditeurs.
• Elle prend des commandes en provenance des libraires, s'approvisionne (à prix
réduit) auprès des éditeurs concernés et livre ses clients à réception des
ouvrages.
• Il n'y a donc pas de stockage.
• Seules les commandes des clients solvables sont prises en compte.

pr. LAASSIRI Jalal / Dept 111

 Diagramme de cas d’utilisation

CBM

Enregistrer une commande

<<include>> <<extend>>
Passer une commande
Employé
urgente
Enregistrer un nouveau client

Enregistrer un nouveau livre

pr. LAASSIRI Jalal / Dept 112

 Spécification textuelle du cas Enregistrer une commande

1ère version : Rédaction par l’utilisateur

Système : CBM
Acteur primaire : l’employé de la coopérative
Objectif : enregistrer une commande de livres
Précondition : le libraire existe
Scénarios :
1 - l’employé vérifie la solvabilité du libraire
2 - l’employé vérifie l’existence du livre
3 - l’employé précise la quantité
Exception :
1a - le libraire n’est pas solvable (l’employé est informé)
2a - le livre n’existe pas (l’employé est informé)

pr. LAASSIRI Jalal / Dept 113

 Diagramme de classes

1ère version : Spécification simplifiée

COMMANDE LIBRAIRIE
1

*
LIVRE EDITEUR

pr. LAASSIRI Jalal / Dept 114

 Spécification textuelle du cas Enregistrer une commande
2ème version : Proposition technique

Système : CBM
Acteur primaire : l’employé de la coopérative
Objectif : enregistrer une commande de livres
Précondition : le libraire existe
Scénarios :
1 - l’employé vérifie la solvabilité du libraire
* une instance de commande est créée
2 - l’employé vérifie l’existence du livre
* un lien entre l'instance de commande et
une instance de livre est créé
3 - l’employé précise la quantité
* la quantité est ajoutée (classe associative)
Exception :
1a - le libraire n’est pas solvable
* un message est affiché
2a - le livre n’existe pas
* un message est affiché
pr. LAASSIRI Jalal / Dept 115
 Diagramme de classes
2ème version : Spécification intermédiaire

COMMANDE saLibrairie LIBRAIRIE

numéro 1 nom
date adresse
commande (libr) solvabilité
ajouterLivre (livre) isSolvable ()

LIGNE DE COMMANDE
quantité
putQuantité (qt)

sesLivres *
LIVRE EDITEUR
ISBN sesLivres nom
Titre * adresse
getTitre () getLivre (titre) : LIVRE

pr. LAASSIRI Jalal / Dept 116

 UML : Vue fonctionnelle
- Diagramme de collaboration et
diagramme de séquence -

pr. LAASSIRI Jalal / Dept 117

 Rôle

• Description de scénarios particuliers

• Représente le fonctionnement du système du point de vue du concepteur
• Mise en valeur des passages de messages (flots de données ou de contrôles,
évènements) entre acteur et objet, ou entre objets, de manière chronologique

• On représente le fonctionnement au niveau des instances

pr. LAASSIRI Jalal / Dept 118

 Diagramme de collaboration

• Comporte :
– des objets dans une situation donnée
– les liens qui relient les objets qui se connaissent
– les messages échangés entre les objets, représentés le long de ces
liens

• L'ordre d'envoi des messages est matérialisé par un numéro de séquence

pr. LAASSIRI Jalal / Dept 119

 Notation

• Un objet A envoie un message X à un objet B, puis l’objet B envoie un message

Y à un objet C, et enfin C s’envoie un message Z.

pr. LAASSIRI Jalal / Dept 120

 Exemple : La CBM

• Enregistre une commande de livres

COMMANDE LIBRAIRIE

2. commande (libr)
6. ligneDeCommande () 5. ajouterLivre (livre) 1. isSolvable ()
7. putQuantité(qt)

LIGNE DE COMMANDE CBM

3. getLivre (titre) :livre

4. getTitre ()
LIVRE EDITEUR

pr. LAASSIRI Jalal / Dept 121

 Diagramme de classes de la CBM
3ème version

COMMANDE saLibrairie LIBRAIRIE

numéro 1 nom
date sesCommandes adresse
commande (libr) * solvabilité
ajouterLivre (livre) isSolvable ()
sesLibrairies
*

sesLdC LIGNE DE COMMANDE

* quantité CBM
putQuantité (qt)

* sesEditeurs
sesLivres *
LIVRE EDITEUR
ISBN sesLivres nom
Titre * adresse
getTitre () getLivre (titre) : LIVRE

pr. LAASSIRI Jalal / Dept 122

 Diagramme de séquence

• Comme les DCO, comporte :

– des objets dans une situation donnée (instances)
– les messages échangés entre les objets

• A la différence des DCO :

– l'accent est mis sur la communication, au détriment de la structure
spatiale
– chaque objet est représenté par une barre verticale
– le temps s'écoule de haut en bas, de sorte que la numérotation des
messages est optionnelle
– Représentation temporelle des interactions entre les objets

pr. LAASSIRI Jalal / Dept 123

 Convention graphique

Acteur :
Objet :
:nom
Ligne de vie : nom:Classe

Bande d’activation :
Envoi de message :
Message()
Création dynamique :
Supprimer un objet : new() obj:Classe2

kill()

UML 136
pr. LAASSIRI Jalal / Dept 124
LAASSIRI
pr. LAASSIRI
Jalal
Jalal / Dept
LAASSIRI
pr. LAASSIRI
Jalal
Jalal / Dept
LAASSIRI
pr. LAASSIRI
Jalal
Jalal / Dept
 Convention graphique

Branchement conditionnel :

obj1:Classe obj2:Classe
Récursivité :

if x cas1()

else cas2()

endif

msg()

pr. LAASSIRI Jalal / Dept 128

 Comparaison DCO/DSE

8: M8
A B C

M1
3: M3 M2
5: M5
C
A M3
1: M1
4: M4 M4
10: M10
2: M2 M5
6: M6
9: M9
7: M7 M6
M7 M8
B
M9

M10

pr. LAASSIRI Jalal / Dept 129

 Notation : niveaux de détails
1er niveau : 2ème niveau :
documentation représentation précise
du cas d’utilisation des interactions entre objets

temps temps
appelant ligne appelé : Client : Cmd : Article
décroche

tonalité getValue

numérote getPrice

numérote

indication de sonnerie
getName
sonnerie
décroche

pr. LAASSIRI Jalal / Dept 130

 Notation : principes généraux
acteur objet du diagramme de classes
nom de l'instance nom de la classe

unA:ClasseA unB:ClasseB
toto:Acteur1

meth1(…)
message

meth2 (…)

SonTruc boolean

retour
•type
•nom d'une instance

activation ligne de vie (durée de l’interaction)

pr. LAASSIRI Jalal / Dept 131

pr. LAASSIRI Jalal / Dept
LAASSIRI
pr. LAASSIRI
Jalal
Jalal / Dept
 Notation : création, destruction

unA : ClasseA
toto:Acteur

meth1 (…)
ClasseB (…)
: ClasseB

unB

X
Création
Arrive sur la classe
Pas de nom d'instance au début
Suppression renvoie tj l'instance créée

pr. LAASSIRI Jalal / Dept 136

LAASSIRI
pr. LAASSIRI
Jalal
Jalal / Dept
LAASSIRI
pr. LAASSIRI
Jalal
Jalal / Dept
LAASSIRI
pr. LAASSIRI
Jalal
Jalal / Dept
LAASSIRI
pr. LAASSIRI
Jalal
Jalal / Dept
LAASSIRI
pr. LAASSIRI
Jalal
Jalal / Dept
pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
 COMMANDE saLibrairie LIBRAIRIE
numéro 1 nom
date sesCommandes adresse
commande (libr) * solvabilité
ajouterLivre (livre) isSolvable ()
sesLibrairies
*
sesLdC
*
LIGNE DE COMMANDE
quantité CBM
putQuantité (qt)

1 * sesEditeurs
sonLivre
LIVRE EDITEUR
ISBN sesLivres nom
titre * adresse
getLivre (titre) : LIVRE

pr. LAASSIRI Jalal / Dept 152

 Un cas d'utilisation

• "Communiquer les détails de toutes les commandes d'une librairie donnée"

• Méthode getDétailCommandes() de la classe LIBRAIRIE

pr. LAASSIRI Jalal / Dept 153

 Le DCO correspondant

1. getDate()
2. getInfosLdC

COMMANDE LIBRAIRIE

3. getQuantité()

LIGNE DE COMMANDE CBM

4. getTitre()

LIVRE EDITEUR

pr. LAASSIRI Jalal / Dept 154

 Un DSE : getDetailsCommandes V1
version 1 : délégation (propagation des messages)

Ahmed:Responsable LIBRAIRIE SesCommandes:COMMANDE SesLdC:LIGNEDECOMMANDE SonLivre:LIVRE

getDétailCommandes()
getSesCommandes()

sesCommandes
getDétailCommande()
getDate()

date

Pour chaque getSesLignes()

commande

sesLdC

getDétailLigne()
getLivre()

sonLivre
getTitre()
Pour chaque
ligne de com. titre
getQuantité()

date +{titre,quantité} {titre,quantité}

quantité
{date +{titre,quantité}}

pr. LAASSIRI Jalal / Dept 155

 Le DCL : nouvelle version (délégation)

COMMANDE sesCommandes saLibrairie LIBRAIRIE

numéro * 1
nom
date sesCommandes adresse
commande (libr) * solvabilité
ajouterLivre (livre) isSolvable ()
getDetailCommande() getDetailComma sesLibrairies
ndes() *
sesLdC
*
LIGNE DE COMMANDE
quantité CBM
putQuantité (qt)
getDétailLigne()

1 * sesEditeurs
sonLivre
LIVRE EDITEUR
ISBN sesLivres nom
titre * adresse
getLivre (titre) : LIVRE

pr. LAASSIRI Jalal / Dept 156

 Un DSE : getDetailsCommandes V2
version 2 : supervision (un objet envoie tous les messages)

LIBRAIRIE SesCommandes:COMMANDE SesLdC:LIGNEDECOMMANDE SonLivre:LIVRE

Ahmed:Responsable

getDétailCommandes()
getSesCommandes()

getDate()
date
getSesLignes()
Pour chaque
commande sesLdC
getQuantité()
quantité
getLivre()
Pour chaque ldc
de chaque com. sonLivre
getTitre()
titre
{date +{titre,quantité}}

pr. LAASSIRI Jalal / Dept 157

 Le DCL : nouvelle version (supervision)

COMMANDE sesCommandes saLibrairie LIBRAIRIE

numéro * 1
nom
date sesCommandes adresse
commande (libr) * solvabilité
ajouterLivre (livre) isSolvable ()
getDetailComma sesLibrairies
ndes() *
sesLdC
*
LIGNE DE COMMANDE
quantité CBM
putQuantité (qt)

1 * sesEditeurs
sonLivre
LIVRE EDITEUR
ISBN sesLivres nom
titre * adresse
getLivre (titre) : LIVRE

pr. LAASSIRI Jalal / Dept 158

 UML : Vue dynamique
- Diagramme d’états-transitions -

pr. LAASSIRI Jalal / Dept 159

pr. LAASSIRI Jalal / Dept
Diagramme états/transitions

pr. LAASSIRI Jalal / Dept

 Composition
Comporte 2 types d'informations :

des états :
initial
final
Intermédiaires
- ex : mineur et majeur

des transitions
induisant un changement d'état
- ex : naissance, anniversaire…

pr. LAASSIRI Jalal / Dept 162

pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
 État
• Un état correspond à la manière d’être d’un objet pendant un
intervalle de temps plus ou moins long.
• Un état se compose de plusieurs parties :
– le nom
– l'activité attachée à cet état
– les actions réalisées pendant cet état

• Exemple :

En alerte
entry/allumer lampe alerte
do/sonnerie toutes les 5 ''
4ème sonnerie/appel poste de garde
exit/éteindre lampe alerte

pr. LAASSIRI Jalal / Dept 169

 Action (Exemple1)

• Opération instantanée (durée négligeable)

Toujours intégralement réalisée → méthode de la classe
• exécutée :
– lors d'une transition eventi / actioni
– à l'entrée dans un état entry / actioni
– à la sortie d'un état exit / actioni
– interne, sans changer d'état eventi / actioni

Action à l'entrée
En alerte
entry/allumer lampe alerte Action interne
do/sonnerie toutes les 5 ''
4ème sonnerie/appel poste de garde
exit/éteindre lampe alerte Action à la sortie

pr. LAASSIRI Jalal / Dept 170

pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
 Activité
• opération qui nécessite un certain temps d’exécution
• peut être interrompue à chaque instant
• associée à un état (étati  "en train de faire ceci")
• exécutée :
entre l'entrée et la sortie de l'état do : activitéi

événement
EN-VEILLE EN-ALERTE

do : détecteur do : sonnerie
détectionPb / envoyer message
sous tension
poste de surveillance

activité
action
activité

pr. LAASSIRI Jalal / Dept 175

 Transition (1)
• Transition : passage unidirectionnel et instantané d’un état (source) dans un
autre état (cible)
• Déclenchée :
• par un événement
• automatiquement à la fin d'une activité (transition automatique)
• Syntaxe :
<NomÉvénement> [<Garde (ou contrainte)>]/<NomAction>
• Garde : condition booléenne qui valide ou non le déclenchement d'une
transition lors de l'occurrence d'un évènement
• Événement : provoque le changement d'état (il existe aussi des événements
internes à un état, dont l'action associée ne provoque pas de changement
d'état)
• Action : opération réalisée lors du changement d'état

pr. LAASSIRI Jalal / Dept 176

pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
 Exemple : Le réveil matin
• Réveil
– Heure d'alarme : on suppose que l'heure est fixée quand on met
l'alarme sur on
– Trois boutons : alarm on/off, arrêt sonnerie,
réglage alarme (événement interne)
• Événements : Appuis sur un bouton

alarm on [heure = H alarme]

désarmé armé do/sonner

alarm off arrêt sonnerie

alarm off
pr. LAASSIRI Jalal / Dept 180
pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
 Diagrammes hiérarchisés
•Permettent de structurer les DET complexes
•Factorisation des actions et activités
•Exemple :

pr. LAASSIRI Jalal / Dept

 Parallélisme et synchronisation

État composite

do/a1 do/a2

do/a3 do/a4

do/a5 do/a6

a1//a3//a5 - a2 après a1 - a4 après a3 - a6 après a5 - état final après a2, a4 et a6

pr. LAASSIRI Jalal / Dept 195

pr. LAASSIRI Jalal / Dept
UML : Vue dynamique
- Diagramme d’activité -

pr. LAASSIRI Jalal / Dept 197

Diagrammes d’activités

pr. LAASSIRI Jalal / Dept

Diagrammes d’activités (Définition)

pr. LAASSIRI Jalal / Dept

 Diagramme d'activité Exemple
• Cas particulier de DET, dans lequel à chaque état correspond une
activité constituant un élément d'une tâche globale à réaliser
• Mise en évidence des contraintes de séquentialité et de parallélisme.
• Exemple - Faire un café :

Chercher le café

Mettre un filtre
Remplir le
réservoir d'eau
Mettre du café
Prendre une tasse

Allumer la cafetière

Le café passe

servir
pr. LAASSIRI Jalal / Dept 201
Diagrammes d’activités

pr. LAASSIRI Jalal / Dept

Diagrammes d’activités

pr. LAASSIRI Jalal / Dept

pr. LAASSIRI Jalal / Dept
Diagrammes d’activités (Exemple2)

pr. LAASSIRI Jalal / Dept

Diagrammes d’activités

pr. LAASSIRI Jalal / Dept

Couloirs d’un Diagramme d’activités(1)

pr. LAASSIRI Jalal / Dept

Couloirs d’un Diagramme d’activités (2)–état d’objet

pr. LAASSIRI Jalal / Dept

 Exercice d’application: Recette de cuisine !

Recette simplifiée : commencer par casser le chocolat en morceaux, puis le faire fondre.
En parallèle, casser les œufs en séparant les blancs des jaunes.
Quand le chocolat est fondu, ajouter les jaunes d’oeuf.

Battre les blancs en neige jusqu’à ce qu’ils soient bien fermes.

Les incorporer délicatement à la préparation chocolat sans les briser.
Verser dans des ramequins individuels.

Mettre au frais au moins 3 heures au réfrigérateur avant de servir.

Représentez par un diagramme d’activité la recette de la mousse au chocolat…

pr. LAASSIRI Jalal / Dept

pr. LAASSIRI Jalal / Dept
 Les diagrammes de composants

# Permettent de décrire l'architecture physique et statique d'une application en terme de

modules : fichiers sources, librairies, exécutables, etc.

# Les dépendances entre composants permettent notamment d'identifier les contraintes de

compilation et de mettre en évidence la réutilisation de composants.

# Le composants peuvent être organisés en paquetages, qui définissent des sous-systèmes.

pr. LAASSIRI Jalal / Dept

Diagramme de composants

pr. LAASSIRI Jalal / Dept 213

 Diagramme 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.
* Les ressources matérielles sont représentées sous forme de noeuds.
* Les noeuds sont connectés entre eux, à l'aide d'un support de communication.
* La nature des lignes de communication et leurs caractéristiques peuvent être précisées.

* Les diagrammes de déploiement peuvent montrer des instances de noeuds (un matériel
précis), ou des classes de nœuds.

* Les diagrammes de déploiement correspondent à la vue de déploiement d'une architecture

logicielle

pr. LAASSIRI Jalal / Dept

Diagramme de déploiement

pr. LAASSIRI Jalal / Dept 215

Exercice 2 :
Le logiciel de gestion des réparations est destiné en priorité au chef d'atelier, Il devra
lui permettre de saisir les fiches de réparations et le travail effectué par les divers
employés de l'atelier.
Pour effectuer leur travail, les mécaniciens et autres employés de l'atelier vont
chercher des pièces de rechange au magasin. Lorsque le logiciel sera installé, les
magasiniers ne fourniront des pièces que pour les véhicules pour lesquels une fiche
de réparation est ouverte ; ils saisiront directement les pièces fournies depuis un
terminal installé au magasin.
Lorsqu'une réparation est terminée, le chef d'atelier va essayer la voiture. Si tout est
en ordre, il met la voiture sur le parc clientèle et bouclera la fiche de réparation
informatisée.
Les fiches de réparations bouclées par le chef d'atelier devront pouvoir être importées
par le comptable dans le logiciel comptable.

pr. LAASSIRI Jalal / Dept

1. Créer un diagramme d’activité pour tout le traitement d’une réparation.
Pour créer une fiche de réparation, le chef d’atelier saisit les critères de
recherche de voitures dans le système.
Le logiciel de gestion des réparations lui donne la liste des voitures
correspondant aux critères entrés. Si la voiture existe, le chef d’atelier va
sélectionner la voiture. Le logiciel va, ensuite, fournir les informations sur le
véhicule. Si la voiture est sous garantie, le chef devra saisir la date de demande
de réparation. Si la voiture n’existe pas, le chef va saisir les informations
concernant ce nouveau véhicule. Dans tous les cas, le chef d’atelier devra saisir
la date de réception et de restitution.

pr. LAASSIRI Jalal / Dept

Si le dommage de la voiture est payé par l’assurance, le logiciel va fournir une liste
d’assurances au Chef d’atelier. Ce dernier sélectionnera l’assurance adéquate.
Enfin, le logiciel enregistre la fiche de réparation.
2. Créer un diagramme d’activité pour le use case « Créer une fiche de réparation
»

pr. LAASSIRI Jalal / Dept

pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept
pr. LAASSIRI Jalal / Dept