conception orientée objet avec uml - lsis.org · vocabulaire orienté objet classification:...
TRANSCRIPT
POEC PHP 2017
Conception Orientée
Objet
avec UML
HistoriqueOMT
(Object Modeling
Technique - 1991)
de James Rumbaugh
OOSE
de Ivar Jacobson
BOOCH
de Grady Booch
UML - Unified Modeling Language
Standard de modélisation objet
adopté en 1997 par l’Object Management Group (OMG)
▪ Révision des spécifications initiales en 2001 – UML1
▪ Approbation de la version UML 2.0 en 2004
▪ Depuis 2015 : UML2.5
Trois modèles▪ Modèle de classes
• Description de la structure statique des objets du système et de leurs relations
• Diagramme de classes : graphe avec pour sommets les classes et pour arcs les relations entre les classes
▪ Modèle d’états
• Description des états successifs d’un objet au cours du temps
• Diagramme d’états : graphe avec pour sommets les états et pour arcs les transitions entre états déclenchées par des événements
▪ Modèles d’interactions
• Description de la manière de coopérer des objets pour obtenir un
résultat
• Diagramme de cas d’utilisation axé sur une fonctionnalité
• Diagramme de séquence : représentation des interactions entre
objets et ordonnancement des interactions
• Diagramme d’activités : détails des étapes importantes du traitement
Modèle de
Classes
Vocabulaire orienté objet
▪ Classification : regroupement des objets ayant même
structure de données (attributs) et même comportement
(méthodes)
▪ Classe : abstraction décrivant un ensemble d’objets
potentiellement infini
6
Vocabulaire orienté objet
▪ Instance d’une classe : objet appartenant à la classe
▪ Héritage : partage de propriétés entre classes sur la base d’unerelation hiérarchique
• Super-classe (classe mère)
• Sous-classe (classe fille) : spécialisation de la super-classe Héritage des propriétés de la super-classe
▪ Polymorphisme : possibilité de comportements différents d’une même opération dans différentes classes
Modèle de classes
▪ Diagrammes de classes : Notation graphique
permettant la modélisation des classes et de
leurs relations
▪ Diagrammes de Package : Notation graphique
permettant le regroupement de plusieurs classes
▪ Diagrammes d’objets : Représentation des
objets individuels et de leurs relations
Enseignant
Classe
AchrefElMouelhi:Enseignant
Objet 7
Modèle de classes
▪ Attribut : propriété nommée d’une classe
nom:string
prénom:string
Classe avec des attributs
décrivant le type d’une valeur contenue dans
chaque objet de la classe
▪ « Un objet est à une classe ce qu’une valeur
est à un attribut » [BR05]
Enseignant AchrefElMouelhi:Enseignant
nom="ElMouelhi"
prénom="Achref"
Objet avec des valeurs
8
Modèle de classes
▪ Identifiant implicite n’existe pas.
▪ Ne pas confondre identifiant interne et attribut
EnseignantID:ID
nom:string
prénom:string
d’identification ayant une contrepartie dans le monde
réel
Enseignant Enseignant
nom:string
prénom:string
Enseignant
NUMEN:integer
nom:string
prénom:string
9
10
Modèle de classes
▪ Méthode : implémentation d’une fonction pour
réaliser une tâche pour la classe ou ses objets.
Enseignant
nom:string
prénom:string
affecterEnseignement (e:Enseignement)
nombreHeuresEnseignement: integer
Fichier
nom:string
localisation:string
imprimer
FichierPowerPoint
nombreTransparents:integer
imprimer
11
Modèle de classes
Liens et associations
Enseignant
Enseigne
Cours
nom:string
prénom:string
intitulé:string
nombreHeures:real* *
▪ Lien : connexion physique ou conceptuelle entre objetsEx. AchrefElMouelhi Enseigne la Programmation
▪ Association : généralisation des liens existants entre
deux classes d’objetsEx. un Enseignant Enseigne un Cours
Diagramme de classes :
AchrefElMouelhi:Enseignant La Programmation:Cours
nom="ElMouelhi"
prénom="Achref"
Intitulé="la Programmation"
nombreHeures=10
Diagramme d’objets :
Modèle de classes Cardinalitété (Multiplicité)
Nombre d’instances d’une classe pouvant être liées à une instance d’une autre classe / contrainte sur le nombre d’objets liés
▪ « un-à-un »
▪ « zéro-à-un »
▪ « plusieurs-à-plusieurs »
Enseignant
EstAffectéA PosteTéléphoniquenom:string
prénom:stringnuméro:string1 1
Enseignant
nom:string
prénom:string 0..1
APourBureau
1
Bureau
numéro:integer
bâtiment:char
Enseignant
Enseigne
Cours
nom:string
prénom:string
intitulé:string
nombreHeures:integer* * 12
Modèle de classes – Noms d’extrémité
Transparent
contenu conteneur FichierPowerPointtitre:string
…nom:string
…* AppartientA 1
Personne estEnfant
titre:string
…*
estParent 2
▪ Possibilité de nommer les extrémités d’association
13
▪ Indispensable pour les associations entre objets de
même classe
Modèle de classes – Noms d’extrémité
Entreprise
Fait travailler> 1..nFonctionnaire
nomEntreprise:string
adresse:stringnomFonctionnaire:string
téléphone:nombre1 < travaille
▪ Possibilité d’indiquer le sens de l’association
14
15
Modèle de classes
Ordonnancement, bags et séquences
Transparent
{ordered} FichierPowerPointtitre:string
…nom:string
…* AppartientA 1
Enseignement{sequence}
Séance1 1..*
*{bag} Polycopié
*
d’une▪ Ordonnancement des objets situés à l’extrémité association « plusieurs »
▪ Bag (sac) : collection non ordonnée avec autorisation de
doublons
▪ Séquence : collection ordonnée avec autorisation de doublons
Modèle de classes - Classe-association
▪ Association qui est également une classe
▪ Caractérisée par des attributs et des méthodes
* *
*
Cours
intitulé:string
nombreHeures:integer
*
Enseigne
*
*
FaitRéférenceA
16
IntervientDans
nombreHeures:integer
imprimerDecompteHeuresDépartement
Enseignantnom:string
nom:string
prénom:string
Modèle de classes - Classe-association
▪ Association qui est également une classe
▪ Caractérisée par des attributs et des méthodes
17
LigneCommande
# quantité : int
+ caIcuIerMontantLigne ()
▪ Les éléments dans LigneCommande ne peuvent
être enregistrés ni dans Commande ni dans article
18
Modèle de classes (17/20)
Généralisation et héritage
▪ Généralisation : relation hiérarchique entre uneclasse (la super-classe) et une ou plusieursvariantes de cette classe (les sous-classes) [BR05]
▪ Super-classe (ou classe-mère) : attributs,méthodes et associations communes
▪ Sous-classe (ou classe fille) : attributs, méthodeset associations spécifiques
▪ Héritage des propriétés de la super-classe par ses
sous-classes
Modèle de classes
Généralisation et héritage
Etudiant
numCarteEtudiant:integer
inscrire(formation:Formation)
Enseignant
grade:string
Est
Insc
ritD
ans
*
Personne
Téléphonenom:string
prénom:string
dateDeNaissance:date
numéro:string
type:string1 *
calculerAge:integer
19
{Note : Un
enseignant peut
être étudiant}
Formation
1
20
Modèle de classes
Généralisation et héritage
Objectifs de la généralisation :
▪ Prise en charge du polymorphisme
▪ Meilleure Structuration
▪ Possibilité de réutiliser du code
Modèle de classes (20/20)
Généralisation et héritage
Redéfinition des propriétés :
Transparent
titre:string
…
imprimer
TransparentFixe TransparentAvecAnimation
imprimer
!Les signatures des
opérations et les types des
attributs redéfinis dans les
sous-classes doivent être
compatibles avec ceux de la
super-classe
21
Modèle de classes
Visibilité : aptitude d’une méthode à référencer une
propriété depuis une autre classe
▪ public (+) : propriété accessible par n’importe quelle méthode
▪ protected (#) : propriété protégée d’une classe uniquement
visible par les méthodes de la classe et de ses sous-classes
▪ private (-) : propriété uniquement visible par les méthodes de
la classe où elle a été définie
Signification pouvant varier en fonction du langage de
programmation
Possibilité d’appliquer la visibilité aux extrémités d’association
!
22
Modèle de classes
Classe abstraite : classe ne pouvant pas être
instanciée en tant que telle
▪ Sous-classes d’une classe abstraite :
obligatoirement concrètes
▪ Possibilité d’utiliser {abstract}
23
Modèle de classes
Héritage multiple : héritage permettant à une
classe d’avoir plusieurs super-classes et d’hériter
des propriétés de tous ses parents
MembreUniversité
Étudiant
Doctorant
Enseignant Administratif
Doctorant hérite des
propriétés de Enseignant
et d’Etudiant et une seule
fois des propriétés de
MembreUniversité.
difficultés
d’implémentation
!
24
Modèle de classes
Contrainte : condition booléenne s’appliquant
aux éléments d’un modèle UML
MembreUniversité
ÉtudiantEnseignant Administratif
{incomplete}
Cours
Contrainte sur les objets : Contrainte sur les associations :
EstMembreDe
intitulé:string
nombreHeures:real
{nombreHeures 1,5}
Dirige
Contrainte sur les ensembles de généralisation :
1..* 0..1
{subset} Laboratoire
1 0..1
25
Enseignant
Modèle de classes
Élément dérivé : donnée définie en terme
d’autres éléments
Étudiant
nom
prénom
dateDeNaissance
Cours
intitulé
nombreHeures
1..**
Évaluation
noteCC
notePartiel
noteExam
/noteFinale
{noteFinale=noteCC*0,3+notePartiel*0,3+noteExam*0,4}!
26
Modèle de classes
Package : groupe d’éléments partageant un thème
commun
Scolarité
Enseignant
Bâtiment
27
Matière
28
Modèle de classes
Package :
▪ Utile pour organiser les grands modèles
▪ Ne définir une classe (i.e. représenter ses
propriétés) que dans un seul package
▪ Référencer une classe d’un autre package en
n’utilisant que le nom de la classe
29
Exercice :
1. Existera-t-il une méthode (autre que le constructeur) dans un objet de
type Poche?
2. La classe Broché n’a pas d’attribut propre, pourrait-elle être
implémentée?
3. Pourrait-on ajouter une relation d’héritage entre Poche et Article?
4. Un livre peut-il être Broché et de Poche?
Modèle de classes
30
Corrigé :
1. Existera-t-il une méthode (autre que le constructeur) dans un objet de
type Poche? Oui, acheter().
2. La classe Broché n’a pas d’attribut propre, pourrait-elle être
implémentée? Oui, elle héritera de Livre et Article.
3. Pourrait-on ajouter une relation d’héritage entre Poche et Article?
Non
4. Un livre peut-il être Broché et de Poche? Non.
Modèle de classes
31
Exercice :1. Combien de Chaises sont contenues dans une Pièce ?
2. Une Table peut-elle appartenir à plusieurs Pièces ?
3. Si une Pièce est détruite, les Chaises associées devront également être
détruites ?
4. Si une Pièce est détruite, les Portes associées devront également être
détruites ?
Modèle de classes
32
Corrigé :1. Combien de Chaises sont contenues dans une Pièce ? 0 ou plusieurs
2. Une Table peut-elle appartenir à plusieurs Pièces ? Non (cardinalité =1)
3. Si une Pièce est détruite, les Chaises associées devront également être
détruites ? Non
4. Si une Pièce est détruite, les Portes associées devront également être
détruites ? Oui
Modèle de classes
Spécifications initiales
▪ Questions à se poser :
• A qui l’application est-elle destinée ?
• Quels problèmes l’application résoudra-t-elle ?
• Quelles seront les conditions d’utilisation de l’application ?
• Quand l’application est-elle attendue ?
• Pourquoi l’application est-elle attendue ?
• Comment l’application fonctionnera-t-elle ?
Spécifications initiales
« Préciser ce qui doit être réalisé et non comment
l’implémentation doit le réaliser » [BR05] :
Exigences
▪ Périmètre du système
▪ Définition de ce qui est exigé
▪ Contexte de l’application
▪ Hypothèses
▪ Besoins de performances
Conception
▪ Approche générale
▪ Algorithmes
▪ Structures de données
▪ Architecture
▪ Optimisation
▪ Planification des ressources
Implémentation
▪ Plates-formes
▪ Spécifications matérielles
▪ Bibliothèques logicielles
Modèle de classes
1. Identifier les classes et conserver les classes pertinentes
2. Préparer un dictionnaire de données
3. Identifier les associations et conserver les associations pertinentes
4. Identifier les attributs des objets et les liens
5. Organiser et simplifier les classes en utilisant l’héritage
6. Vérifier que tous les chemins d’accès existent pour les requêtes probables
7. Itérer et affiner le modèle
8. Regrouper les classes en package
Comment ?!
Identifier les classes : trouver les classes pertinentes
pour les objets du domaine de l’application
▪ Au départ, ne pas être trop sélectif et noter tout
▪ Ne pas se soucier trop de l’héritage ni des
classes de haut niveau
Exigences
sources
Classes
candidates
ClassesExtraction
des noms
Élimination
des classes
inappropriées
1
Comment ?!
Conserver les classes pertinentes
Par élimination des :
▪ Classes redondantes : classes exprimant le même concept /Conservation du nom le plus évocateur
▪ Classes sans intérêt : classe sans lien avec le contexte ou ne faisant pas partie du périmètre du logiciel
▪ Classes vagues : classes ayant des frontières mal définies ou une portée trop large
▪ Attributs : re-formulation des noms décrivant originellement des objets individuels sous la forme d’attributs
▪ Opérations : appliquées à des objets et non manipulées en tant qu’opérations
▪ Classes dérivées
Comment ?!
Identifier les associations et conserver les associationspertinentes
Par élimination des :
Associations ternaires par décomposition en trois
associations binaires
définies en termesAssociations dérivées : associations d’autres associations (car redondance)
Comment ?!
Trouver les attributs et conserver les attributs pertinents
▪ Ne pas pousser la recherche des attributs à l’extrême.
▪ Ne considérer que les attributs pertinents pour l’application
▪ Rechercher en premier les attributs les plus importants ; repousser les détails à plus tard
▪ Omettre les attributs dérivés
▪ Rechercher les attributs des associations
Élimination des attributs inutiles ou incorrects
Comment ?!
Organiser et simplifier les classes en utilisant l’héritage
▪ Par généralisation ascendante : en recherchant les classes ayant des attributs,
des associations ou des opérations similaires
▪ Par spécialisation descendante : en évitant les raffinements excessifs
Comment ?!
Itérer sur le modèle de classes
▪ Pas d’exactitude du modèle à la première passe
▪ Nécessité de réaliser des itérations continuelles
▪ Possibilité d’avoir différentes parties du modèle à différents stades d’achèvement
▪ Possibilité de revenir à un stade antérieur pour corriger une anomalie détectée
▪ Raffinements probables après l’achèvement des modèles d’états et d’interactions
Comment ?!
Grouper les classes en packages
Regroupement des éléments (classes, associations, généralisationet autres packages de niveau inférieur) ayant un thème commun oufortement couplés afin de plus facilement tracer et visualiser lemodèle
Comptabilité Service comptable ;
Facture
Demandes de formation Demande de formation ;
Employé ; Inscription ; Réponse ;
Accord; Désaccord
Catalogue de formations Catalogue ; Organisme de
formation ; Formation; SessionEntités
métier
Comment ?!
43
On souhaite gérer les réservations de vols effectués dans une agence.
1. Les compagnies aériennes proposent différents vols
2. Un vol est ouvert à la réservation et refermé sur ordre de la compagnie
3. Un client peut réserver un ou plusieurs vols, pour des passagers différents
4. Une réservation concerne un seul vol et un seul passager
5. Une réservation peut être confirmée ou annulée
6. Un vol a un aéroport de départ et un aéroport d’arrivée
7. Un vol a un jour et une heure de départ, et un jour et une heure d’arrivée
8. Un vol peut comporter des escales dans un ou plusieurs aéroport(s)
9. Une escale a une heure de départ et une heure d’arrivée
10. Chaque aéroport dessert une ou plusieurs villes
Modèle de classes
Modèle d’états
45
Modèle d’états
▪ Description des aspects d’un système relatifs à la
durée et au séquençage des opérations
▪ Composé d’autant de diagrammes d’états que de
classes dotées d’un comportement temporel significatif
pour l’application
▪ Vocabulaire :
• Événements
• États
• Transitions et conditions de franchissement
46
Modèle d’états - Évènement
▪ Occurrence ou fait ayant lieu à un moment donné qui
va générer un changement d’état chez l’objet.
▪ Modification intervenue dans l’environnementEx. Réservation annulée, Retrait d’argent…
▪ Vérification de conditions d’erreurEx. nombre d’emprunts > 6
Modèle d’états - État
▪ Abstraction de valeurs et de liens d’un objet
▪ Spécification de la réponse d’un objet à des
événements entrants
▪ État vs Événement :
• Évènement : représentation d’un moment précis dans le temps
• État : intervalle séparant la réception de deux
événements par un objet
47
LivreEmpruntéChambreOccupéChambreHorsService
Modèle d’états - État
51
État : LivreEmprunté
Description : Le livre est emprunté par l’emprunteur d’identifiant numéroEmprunteur, à
la date dateEmprunt
Séquence d’événements qui produit l’état :
Emprunt(numéroEmprunteur,dateEmprunt)
Condition qui caractérise l’état :
Emprunteur.nbreEmprunt < NbreMaxEmprunt et Emprunteur non pénalisé
Évènements acceptés dans l’état :
événement action état suivant
retourLivre terminerEmprunt LivreDisponible
Caractérisation d’un état
Modèle d’états
Transition et conditions de franchissement
▪ Transition : passage instantané d’un état à un autre
▪ Condition de franchissement (guard condition) :
expression booléenne devant être vraie pour le
franchissement de la transition
LivreDisponible LivreEmprunté
49
Attention : Condition de franchissement Événement
Emprunt(numéroEmprunteur,dateEmprunt)
[ NbreEmprunt < NbreMaxEmprunt ]
Modèle d’états - Diagramme d’états
▪ Graphe orienté dont les sommets sont les états et les
arcs les transitions entre les états
▪ Spécification des successions d’états provoqués par
des successions d’évènements
▪ Associé à une classe
event (attributs) [condition de franchissement]État2
Nom du diagramme
État1
50
Modèle d’états - Diagramme d’états
▪ Entrée dans l’état initial à la création de l’objet
▪ Destruction de l’objet à l’état final
LivreDisponible
LivreEmprunté
achat
miseA
uP
ilon
emprunt miseEnRéserve
livreDem
an
dé
retourLivreLivreEnRéserve
EmpruntDeLivre
51
Modèle d’états - Diagramme d’états
Emprunteur
InscritinscriptionAutorisée
Exclu
sA
ya
ntP
risQu
itus
Déb
ut
demandeDeQuitus
[nbEmprunt=0]
Empruntant
retourLivre
[dateActuelle dateRetour et
nbreEmprunt=1]
emprunt
[nbreEmprunt<nbreMaxEmprunt]
exclusion [Penalité>MaxPénalité]
PénaliséretourLivre
[dateActuelle > dateRetour]
emprunt[nbreEmprunt<
nbreMaxEmprunt
et nbEmprunt>1 ]
finPénalisation [nbEmprunt>1]
52
finP
énali
sati
on
[nb
Em
pru
nt=
0]
53
Modèle d’états
Conseils pratiques [BR05] :
▪ Ne construire de diagrammes d’états que pour lesclasses ayant un comportement temporelsignificatif, i.e. les classes répondant différemmentà différents événements ou ayant plus d’un état
▪ Pas de nécessité de construire un diagrammed’états pour toutes les classes
▪ Bien concevoir les conditions de franchissementpour ne pas bloquer un objet dans un état
Modèle d’états
Diagrammes d’états imbriqués
LivreAuDépot
LivreAu1erSousSol
LivreEnRéserve
[dateActuelle>dateDernier
Emprunt+180 jours]
[dateActuelle>dateDernierEmprunt+365 jours]
LivreDisponible
livreDemandé
État imbriqué
État imbriqué
État composite
Possibilité d’états imbriqués
Chacun des états imbriqués « reçoit »
les transitions sortantes de son état
composite [BR05]
A utiliser quand une même transition s’applique à plusieurs états [BR05]54
Modèle d’états
Concurrence :
▪ Concurrence d’agrégation
= collection desDiagramme d’état d’un assemblagediagrammes d’états de ses sous-parties
▪ Concurrence à l’intérieur d’un objet
Possibilité de partitionner un objet en sous-ensemblesd’attributs et de liens, chacun des sous-ensembles ayant undiagramme d’états
LivreDisponible
LivreEnRayonLivreDérangérangement
LivreEnRayonLivreRetournérangement
55
56
Modèle d’états
Relations modèle de classes – modèle d’états
▪ Modèle de classes :
• Description des objets, valeurs et liens pouvant existerdans un système
• Modélisation des différences intrinsèques entre objets
ou partie du▪ Diagramme d’états = description de toutcomportement des objets d’une classe donnée
▪ État = valeurs et liens détenus par un objet
Modèle d’états
▪ Description du cycle de vie des objets decertaines classes
▪ Étapes à suivre :
1. Identifier les classes ayant des états
2. Trouver les états
3. Trouver les événements
4. Construire les diagrammes d’états
5. Évaluer les diagrammes d’états
Comment ?!
1. Identifier les classes ayant des états
Recherche des classes ayant un cycle de vie distinct(classes caractérisées par une progression ou représentantun comportement cyclique)
Livre
Réservé
2. Trouver les états
Recherche des états à partir des différences qualitativesdans le comportement, les attributs ou les associations desclasses dynamiques
Disponible Emprunté
Déchiré Perdu
Comment ?!
3. Trouver les événements
▪ Recherche des événements déclenchant les transitions
entre les états
▪ Capturer les informations véhiculées par un événement
sous la forme d’une liste de paramètres
4. Construire les diagrammes d’états
Comment ?!
5. Évaluer les diagrammes d’états
▪ Examiner chaque modèle d’états et vérifier laconnexion de tous les états
▪ Prêter une attention particulière aux chemins d’accès(y-a-t-il un chemin conduisant de l’état initial à un étatfinal ?)
▪ Vérifier la présence des variations attendues
▪ En cas de classe cyclique, vérifier la présence de laboucle principale
▪ Ajouter les états manquants (identifiés par les cheminsmanquants)
Comment ?!
Modèle
d’interactions
62
Modèle d’interactions▪ Modèle de classes = représentation des objets et de leurs
relations
▪ Modèle d’états = description du cycle de vie des objets
▪ Modèle d’interactions = expression de la façon dont lesobjets interagissent pour produire des résultats utiles àl’application [BR05]
▪ Plusieurs niveaux d’abstraction du modèle d’interactions :
• Cas d’utilisation : description de l’interaction du systèmeavec les acteurs extérieurs
• Diagrammes de séquence : représentation des messageséchangés entre ensemble d’objets au fil du temps
• Diagramme d’activités : représentation du flux de contrôle entre les étapes de traitement
63
Modèle d’interactions
Cas d’utilisation
▪ Acteur
Utilisateur externe direct du système
Objet ou ensemble d’objets communiquant directementavec le système sans en faire partie
Tout ce qui interagit directement avec le système
Ex. Un employé d’une bibliothèque (SG de Biblio)
Ex. Un client et la banque (S de Ventes en ligne)
▪ Un acteur principal est à l’origine d’actions sur le système
▪ Un acteur secondaire est sollicité par le système
▪ Pour les distinguer, on ajoute Ie stéréotype <<secondary>>
Paiement CB
Client Banque
<<secondary>>
64
Modèle d’interactions
Cas d’utilisation
▪ Cas d’utilisation
• Identification des fonctionnalités pouvant être fournies par un système en interagissant avec les acteurs
Ex. L’employé enregistre un emprunt
Ex. Le client passe une commande
65
Modèle d’interactions – Cas d’utilisation
Un acteur peut être lié à un ou plusieurs cas par association
Ajouter un article au panier
Passer une commande
Suivre une commande
Client
Achat en ligne
Diagramme d’un cas d’utilisation d’Achat en ligne
Modèle d’interactions – Cas d’utilisation
Diagramme d’un cas d’utilisation d’un système de
gestion d’une bibliothèque
Insérer un livre
Enregistrer un placement en réserve
Enregistrer un emprunt
Enregistrer un retour de livre
Gestionnaire de bibliothèque
Voir la liste des livres de la bibliothèque
Chercher un livre
Membre
Employé
67
Modèle d’interaction
Relation include
▪ Insertion d’un cas d’utilisation dans la séquence de
comportements d’un autre cas d’utilisation
▪ Mise en commun de comportements communs à plusieurs cas
d’utilisation
▪ Si le cas B inclut le cas A, alors A est une partie obligatoire
de B.
A B« include »
Modèle d’interaction
Insérer un livre
Enregistrer un retour de livre
Enregistrer un placement en réserve
Enregistrer un emprunt
S’authentifier
« include »
68
« include »
« include »
« include »
Relation include
Modèle d’interaction
Relation extend
▪ Ajout d’un comportement incrémental à un cas d’utilisation
▪ Extension possible d’un cas d’utilisation de base
▪ Association d’une condition à la relation « extend »
▪ Si le cas B étend le cas A, alors B est une partie optionnelle
de A.
A B« extend »
69
Modèle d’interaction
Relation extend
Chercher un livre Réserver un livre« extend »
Enregistrer un emprunt Vérifier les réservations« extend »
70
Modèle d’interactionGénéralisation des cas d’utilisation
▪ Représentation des variantes d’un cas d’utilisation
▪ Cas d’utilisation parent = représentation d’une séquence de comportements générale
▪ Cas d’utilisation enfant = insertion d’étapes supplémentaires ouaffinage de certaines étapes du cas d’utilisation parent
Chercher un livre
Rechercher à partir
d’un nom d’auteur
Rechercher à partir
d’un mot-clé
Rechercher à partir
d’un identifiant
71
Organiser les acteurs et les cas d’utilisation
▪ Pour les systèmes de grande taille ou les systèmes
complexes, organiser les cas d’utilisation à l’aide des
relations include et extend
▪ Possibilité d’organiser les acteurs par des
généralisations
Employé
Responsable de
formation
Demander une formation
Gérer ses demandes
Traiter les demandes
S’identifier
Consulter le catalogue
« include »
« include »
« include »
« extend»SGDF
Comment ?!
Comment ?!
▪ Objectif : ajouter les « artefacts majeurs » au modèle du domaine
▪ Concentration de l’attention sur les détails de l’application et prise en compte des interactions
▪ Étapes à suivre pour le modèle d’interactions :
1. Trouver les acteurs (et les classifier)
2. Trouver les cas d’utilisation
3. Trouver les événements initiaux et finaux
4. Rédiger les scénarios standards
5. Ajouter des scénarios de variations et d’exceptions
6. Préparer des diagrammes d’activités pour les
cas d’utilisations complexes
7. Organiser les acteurs et les cas d’utilisation
8. Vérifier avec le modèle de classes du domaine
Trouver les acteurs
▪ Identification des objets externes agissant avec le système
▪ Recherche d’archétypes de comportement (et non pas
d’individus)
▪ Correspondance possible entre un acteur et plusieurs
objets extérieurs ou un objet extérieur et plusieurs acteurs
Employé Responsable de
formation
Organisme de
formation
Service
comptable
Comment ?!
Responsable de
formationTraiter les demandes
Trouver les cas d’utilisation
▪ Dresser, pour chaque acteur, la liste de ses façons
fondamentalement différentes d’utiliser le système
▪ Représenter un cas d’utilisation pour chaque type de service
fourni par le système
▪ Conserver un niveau de détails similaire pour tous les cas
d’utilisation
▪ Tracer un diagramme de cas d’utilisation préliminaire
SGDF
Demander une formation
Employé
Gérer ses demandes
Comment ?!
76
Modèle d’interactions
Cas d’utilisation
Exercice :
1. Le système permet-il au client de payer ses commandes?
2. Le système permet-il au client de suivre ses commandes?
3. Le client est-il obligé de valider son panier avant de se payer son
panier?
4. Le client est-il obligé de payer pour passer sa commande?
++
77
Modèle d’interactions
Cas d’utilisation
Corrigé :
1. Le système permet-il au client de payer ses commandes? Oui
2. Le système permet-il au client de suivre ses commandes? Non
3. Le client est-il obligé de valider son panier avant de se payer son
panier? Non
4. Le client est-il obligé de payer pour passer sa commande? Oui
++
78
Modèle d’interactions
Cas d’utilisation
Exercice :
1. Ajouter un article au panier
2. Passer une commande (valider panier, saisir code promo et payer)
3. Suivre une commande
4. Les deux opérations précédentes nécessitent l’authentification
5. Le paiement se fait par carte bancaire ou par virement et les deux passent par
l’intermédiaire de la banque
79
Modèle d’interactions
Cas d’utilisation
Ajoute
article au
panier
Passer
commande
Payer
Valider
panier
Saisir
code
promo
Paiement
CB
Virement
Client
Banque
S’authentifier
Suivre
commande
Achat en ligne
Correction :
80
Modèle d’interactions
Cas d’utilisation
Exercice :
1. Déterminer les cas d’utilisation d’un distributeur de billets
2. On considère les scénarios où un client désire retirer de l’argent en euros ou en
dollars
3. Il faut traiter la situation où le stock de billets est insuffisant
81
Modèle d’interactions
Cas d’utilisation
Correction :
Système central
82
Modèle d’interactions
Cas d’utilisation
Exercice :
1. Déterminer les cas d’utilisation d’une caisse enregistreuse.
2. Le caissier enregistre les articles. Ensuite, et pour signaler la fin de vente, il faut
payer le montant correspondant à cette vente. Il est possible d’utiliser un
coupon de réduction avant de payer.
3. Trois modes de paiements sont autorisés : liquide, chèque et CB. Sachant que ce
dernier nécessite de contacter le centre d’autorisation bancaire.
4. Pour chaque vente, et avant de payer, il faut transmettre les infos au
Gestionnaire de stock.
83
Modèle d’interactions
Cas d’utilisation
Correction :
84
Modèle d’interactions - Modèles de séquences
▪ Que va décrire un diagramme de séquence?
85
Modèle d’interactions - Modèles de séquences
▪ Précision des thèmes fonctionnels introduits parles cas d’utilisation
▪ Ajout de détails et précision de la description
informelle des cas d’utilisation
Diagrammes de séquence : Représentation des
participants à une interaction et de leurs messages
échangés
▪ Les sélecteurs (en haut de ligne de vie) : nomClassou acteur
▪ Les messages : échange entre sélecteurs
86
Modèle d’interactions - Modèles de séquences
Comment représenter une ligne de vie?▪ De haut en bas sur une ligne
87
Modèle d’interactions - Modèles de séquences
Qu’est-ce qu’un message?
▪ Représenté par une flèche
▪ Définit une communication entre lignes de vie
▪ Déclenche une période d’activité sur une ligne
▪ Possède un nom (opération, méthode, signal…)
▪ Peut avoir des paramètres
88
Modèle d’interactions - Modèles de séquences
Qu’est-ce qu’un message synchrone?
▪ Bloque l’expéditeur▪ Le récepteur rend la main à l’émetteur par un
message de retour (sa représentation est optionnelle).▪ Peut spécifier le résultat de la méthode invoquée.
89
Modèle d’interactions - Modèles de séquences
Qu’est-ce qu’un message asynchrone?
▪ Ne bloque pas l’expéditeur
90
Modèle d’interactions - Modèles de séquences
Qu’arrive t-il en cas de messages concomitants?
▪ Si un objet est actif, l’arrivé d’un nouveau message entraînera une nouvelle activité.
▪ La nouvelle activité sera représentée par un rectangle chevauchant le premier
91
Modèle d’interactions - Modèles de séquences
Comment sont crées et détruites les lignes de vie?
▪ La création d’un nouvel objet <=> une nouvelle ligne de vie (stéréotypée par un <<create>>.
▪ La destruction d’un objet <=> la destruction d’uneligne de vie (stéréotypée par un <<destroy>>.
▪ La croix symbolise la fin de la ligne de vie de l’objet.
92
Modèle d’interactions - Modèles de séquences
Qu’est-ce qu’un message complet, perdu ou trouvé?
▪ Complet : évènements d’envoi et réception connus▪ Perdu : on a un évènement d’envoi, mais pas de
réception connue.▪ Trouvé : on a un évènement de réception, mais pas
d’envoi connu.
93
Exercice :
1. Lequel de ces 2 diagrammes correspond à l’envoi d’un
message asynchrone ?
2. Ne pas représenter un retour de message synchrone signifie-
t-il que le retour est ’void’ ?
3. “obj1” est un acteur, car seuls les acteurs peuvent envoyer
des messages ?
4. “obj1” est le type de l’acteur qui envoie un message ?
5. La ligne de vie de ”obj1” dans le diagramme B prendra
fin après sa période d’activité ?
Modèle d’interactions - Modèles de séquences
94
Corrigé :
1. Lequel de ces 2 diagrammes correspond à l’envoi d’un
message asynchrone ? A
2. Ne pas représenter un retour de message synchrone signifie-
t-il que le retour est ’void’ ? Non
3. “obj1” est un acteur, car seuls les acteurs peuvent envoyer
des messages ? Non
4. “obj1” est le type de l’acteur qui envoie un message ? Non
5. La ligne de vie de ”obj1” dans le diagramme B prendra
fin après sa période d’activité ? Non
Modèle d’interactions - Modèles de séquences
95
Modèle d’interactions - Modèle d’activités
Diagramme d’activités :
▪ Représentation des étapes d’un processus complexe et
des contraintes de séquencement
▪ Expression du flux de contrôle, comme un diagramme de
séquences, mais avec une attention particulière sur les
opérations plutôt que les objets
▪ Suite d’étapes correspondant aux activités décrites dans
le modèle d’états
Modèle d’interaction - Modèle d’activités
afficher écheclire carte membre
[membre autorisé à
emprunter]
lire code barre livre
[livre autorisé à
l’emprunt]
enregistrer Emprunt modifier NbreEmprunt
[membre exclu ou pénalisé ou dont
nbreEmprunt > maxNbreEmprunt]
afficher date de retour et nombre livres pouvant être empruntés
activités Point de décision ou
Branchement conditionnel
Scission ou
fusion de fils
d’exécution
(thread)
96
97
Exercice :
1. Déterminer le diagramme d’activité lié à une opération de retrait d’argent d’un
distributeur en traitant les différents cas possibles (vérification carte, code…)
Modèle d’interaction - Modèle d’activités
98
Corrigé :
Modèle d’interaction - Modèle d’activités
99
Modèle d’interaction
▪ Cas d’utilisation : partition d’un système enfonctionnalités discrètes et significatives pour lesacteurs (extérieurs au système)
▪ Possibilité de détailler les cas d’utilisation par des
diagrammes de séquence
▪ Diagramme de séquence : représentation clairedes objets participant à une interaction et desmessages émis ou reçus par ces objets
▪ Diagramme d’activités : description des détailsd’un traitement
Modèle d’interaction
Diagramme de séquence avec objets passifs
▪ Notation dédiée permettant d’illustrer les appels de
procédures
▪ Déclenchement d’un comportement d’un objet passif
activation de l’objet passif
:SystèmeDeGestionDeBibliothèque :BaseDeLivres
rechercherLivre (listeParamètresDeRecherche)
livre
Pério
de
d’a
ctivatio
n
100
Modèle d’interaction
insérerLivre ()
Diagramme de séquence avec objets temporaires
:SystèmeDeGestionDeBibliothèque :BaseDeLivres
:LivrecréerLivre()
Fin de vie de l’objet
!101
Ne représenter les détails d’implémentations que pour les diagrammes difficiles
ou particulièrement importants [BR05]
saisieDonnéesDuLivre ()
données
{traiter données}
insérerNuplet(arg)
EmployéResponsable de
formation
« system »
: SGDF
{employé authentifié}
consulterCatalogue()
thèmes
choisirThème()
formations du thème
choisirFormation()
sessions disponibles
choisirSession()
infos sessions
validerDemande() enregistrerDemande
nouvelleDemande()
Comment ?!
EmployéResponsable de
formation
« system »
: SGDF
{employé authentifié}
consulterCatalogue()
thèmes
choisirThème()
formations du thème
choisirFormation()
sessions disponibles
choisirSession()
infos sessions
validerDemande() enregistrerDemande
nouvelleDemande()
Boucle pour
demandes multiples
Comment ?!
EmployéResponsable de
formation
« system »
: SGDF
{employé authentifié}
consulterCatalogue()
thèmes
choisirThème()
formations du thème
choisirFormation()
sessions disponibles
choisirSession()
infos sessions
validerDemande() enregistrerDemande
nouvelleDemande()
Boucle pour
demandes multiples
Opt.
Comment ?!
EmployéResponsable de
formation
« system »
: SGDF
{employé authentifié}
consulterCatalogue()
thèmes
choisirThème()
formations du thème
sessions disponibles
choisirFormation()
infos sessions
choisirSession()
validerDemande() enregistrerDemande
nouvelleDemande()
Boucle pour
demandes multiples
Opt.
Opt.
Comment ?!
Modèle d’interaction
signaux dans lesÉmission et réception de
diagrammes d’activités
saisir commande de livre
demander validation
système de
comptabilitéattendre réponse
recevoir confirmation
envoyer commande
émission de signal
réception de signal
Modèle d’interaction
Couloir d’activités : répartition des activités aux entités
organisationnelles
insérer livre dans la base imprimer étiquette
coller étiquette ranger livre en rayon
Personnel des commandes
107
Personnel des prêts Personnel des rayons
les casPréparer des diagrammes d’activité pour
d’utilisation complexe
Inscrire stagiaireSuivre formation
Émettre facture
Contrôler facturePayer facture
Rédiger demande
Analyser demande
[demande
refusée] [demande
acceptée]
Chercher Stage
Sélectionner sessions
Commander stage
Comment ?!
Préparer des diagrammes d’activité pour
d’utilisation complexe
Inscrire stagiaireSuivre formation
Émettre facture
Contrôler facturePayer facture
Rédiger demande
Analyser demande
[demande
refusée] [demande
acceptée]
Chercher Stage
Sélectionner sessions
Commander stage
:Employé :ResponsableDeFormation :OrganismeFormation
les cas
:ServiceCompta
Comment ?!
Résumé
Trois points de vue différents mais apparentés :
▪ Modèle de classes : description des objets d’un
système et de leurs relations
▪ Modèle d’états : description du cycle de vie des
objets
▪ Modèle d’interactions : description de la façon dont
les objets interagissent
111
Résumé
Modèle de classes
▪ Description de la structure statique des objets :identité, relations avec les autres objets, attributs etopérations
▪ Cadre d’insertion pour les modèles d’états etd’interactions
▪ Concepts importants :
• Classe : ensemble d’objets similaires
• Association : ensemble de liens similaires entre objets
• Généralisation : structuration de la description desobjets en les organisant en fonction de leurs différenceset de leurs similarités
112
Résumé
Modèle d’états
▪ Description des aspects temporels d’un objet
▪ Représentation des séquences d’états et d’événements pour
une classe d’objets donnée
▪ Description du comportement générique d’une classe
▪ Événement :
• Marque d’un changement
▪ État :
• Définition du contexte d’un événement
• Valeurs d’un objet
RésuméModèle d’interactions
▪ Description de la façon dont les objets collaborent pourobtenir des résultats
▪ Complément du modèle d’états
▪ Différents niveaux d’abstraction pour modéliser les
interactions :
• Cas d’utilisation : représentation des interactions du système avec les acteurs extérieurs
• Diagrammes de séquence : représentation desinteractions entre objets et de leur succession dans letemps
• Diagramme d’activités : représentation des interactionsavec mise en évidence du flux de contrôle entre lesdifférentes étapes de traitement+
-
Niv
eau
de
dét
ails
114
Résumé
Relations entre les 3 modèles
▪ Mêmes concepts (données, séquencement et opérations) mais avec accentuation différente
▪ Modèle de classes :• Description de la structure des données sur lesquelles les modèles
d’états et d’interactions opèrent
• Correspondance entre les opérations du modèle de classe et les événements, les conditions et les activités
▪ Modèle d’états :• Description de la structure du contrôle des objets
• Représentation des décisions dépendant des valeurs des objets,entraînant les modifications de ces valeurs et les changementsd’états
▪ Modèle d’interactions :• Concentration sur les échanges entre les objets
• Vue globale du système