View
1
Download
0
Category
Preview:
Citation preview
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
1/141
Genie Logiciel et UMLIntroduction a UML
Jean-Paul Comet (projet Bioinfo Formelle)
EPU dept GB-BIMB - 5eme annee / Master 2 SV-BIMUniversite de Nice Sophia-Antipolis
octobre 2020
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
3/141
Introduction a UML
Lorsqu’on cherche a realiser un projet, qu’il soit informatique ou non, on passepar plusieurs phases dont les deux premieres sont la phase d’analyse, et celle deconception.
phase d’analyse : faire comprendre les besoins des utilisateurs et/ou clients.
Que souhaitent-ils faire avec le logiciel ?Quelles fonctionnalites veulent-ils ? Pour quel usage ?Comment l’action devrait-elle fonctionner ?
C’est ce qu’on appelle � l’analyse des besoins �. Apres validation de cettecomprehension du besoin, on peut passer a la phase de d’� analyse de lasolution �, au cours de laquelle on imagine la solution.La phase d’analyse est donc la comprehension en profondeur des exigencesa partir de la construction de modelesphase de conception : apporte plus de detailsclarifier des aspects techniques, comme l’installation des differentes partieslogicielles sur du materiel.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
4/141
Qu’est-ce qu’UML ?
UML = Unified Modeling LanguageUML = Langage unifie pour lamodelisation objet
DefinitionDefinition d’UML selon l’OMG Langage visuel dedie a laspecification, la construction et la documentation d’un systemelogiciel
OMG = Object Management Group (www.omg.org) : Fonde en1989 pour standardiser et promouvoir l’objet
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
4/141
Qu’est-ce qu’UML ?
UML = Unified Modeling LanguageUML = Langage unifie pour lamodelisation objet
UML est un langage universel de modelisation objet ... pas unemethodeDifference Langage – MethodeLangage de modelisation = notations, grammaire, semantiqueMethode = comment utiliser le langage de modelisation(recueil des besoins, analyse, conception, mise en oeuvre,validation, ...)
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
4/141
Qu’est-ce qu’UML ?
UML = Unified Modeling LanguageUML = Langage unifie pour lamodelisation objet
UML est un langage universel de modelisation objet ... pasune methodePourquoi modeliser ?
La description de la POO necessite un travail conceptuel :definition des classes, de leurs relations, des attributs, desoperations (implementees par des methodes), desinterfaces, ...Il faut organiser ses idees, les documenter, organiser larealisation, definir des modules, ...Modelisation = demarche anterieure a l’implementation
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
4/141
Qu’est-ce qu’UML ?
UML = Unified Modeling LanguageUML = Langage unifie pour lamodelisation objet
UML est un langage universel de modelisation objetUML est une notation, un outil de communication visuelle (diagrammes)UML est un langage de modelisation des applications construites a l’aided’objetsUML n’est pas un langage de programmationUML n’est pas un processus de developpementUML est independant d’un langage de programmationUML est une norme maintenue par l’OMGDescription exacte : http ://www.omg.org/uml
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
4/141
Qu’est-ce qu’UML ?
UML = Unified Modeling LanguageUML = Langage unifie pour lamodelisation objet
UML est un langage universel de modelisation objetGuerre des methodes : OMT, Booch, OOSE, Fusion, ROOM, HOOD...Concepts OO proches mais notations graphiques differentes.La guerre des methodes ne fait plus avancer la technologie des objets.Or l’industrie a besoin de standards.
Recherche d’un langage commun uniqueUtilisable par toutes les methodesAdapte a toutes les phases du developpementCompatible avec toutes les techniques de realisation
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
4/141
Qu’est-ce qu’UML ?
UML = Unified Modeling LanguageUML = Langage unifie pour lamodelisation objet
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
5/141
But du cours
Decrire le langage UML et ses outils (les diagrammes)Diagrammes : contribuent a chacune des phases d’unprojet, de la phase d’analyse des besoins a la maintenance.Chaque diagramme donne une vision differente du projet.Ils permettent de representer le logiciel a developper : sonfonctionnement, sa mise en route, les actions susceptiblesd’etre effectuees par le logiciel, etc.
Realiser ces diagrammes=
modeliser les besoins du logiciel
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
6/141
Un panorama d’UML avec ses 14 diagrammes
Tout comme la construction d’une maison necessite des plans a differentsniveaux (vision exterieure, plan des differents etages, plans techniques...),la realisation d’une application informatique ou d’un ensemble d’applica-tions est basee sur plusieurs diagrammes.
Les 14 diagrammes peuvent etre regroupes selon les trois aspects suivants :1 Les aspects fonctionnels : Qui utilisera le logiciel et pour quoi faire ?
Comment les actions devront-elles se derouler ? Quelles informationsseront utilisees pour cela ?
2 Les aspects lies a l’architecture (statique) : Quels seront les differentscomposants logiciels a utiliser (base de donnees, librairies, interfaces,etc.) ? Sur quel materiel chacun des composants sera installe ?
3 Les aspects dynamiques : Quels sont les differents etats que peutprendre un objet, dans quel ordre ? quels sont les enchaınements demessages envisageables...
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
7/141
Les 4+1 vues d’un systeme
Aspects fonctionnels Architecture
Vue dudéploiement
composantsVue des(2)
(3)
Vue logique
Vue desprocessus
(4)
(5)
(1)
utilisateurs
Besoins des
Representation des aspects fonctionnels et d’architecturepar le schema de 4 vues, axees sur les besoins des utilisateurs
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
8/141
1 Introduction
2 Un panorama d’UML avec ses 14 diagrammes(1) Utilisateurs(2) Aspects fonctionnels - vue logique(3) Aspects fonctionnels - vue des processus(4) Architecture - vue des composants(5) Architecture - vue du deploiement
3 Principes des methodes Orientees Objet
4 Diagrammes d’Utilisation
5 Diagrammes d’Objets
6 Diagrammes de Classes
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
9/141
Le diagramme de contexte
Le situer dans son environnement (ce qui le concerne et cequi ne le concerne pas)Identifier ses flux d’informations avec son environnementDelimiter ce qu’il y a a faire et ne pas faire
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
10/141
Le diagramme de package
Un acteur
"package"
Une partie ou
Commercial
Expédition
Service Achats
Réception
Stockage
Clientgestion commandesclient
gestion des stocks
Système
gestion des achats
decomposer le systeme en categories ou parties plusfacilement observables, appeles � packages �.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
11/141
Le diagramme de cas d’utilisation
Un cas d’utilisation (une fonctionnalité)
Stockage
<<system>>Compta Fournisseurs
Réception
Expédition
Système
<<extend>>
<<include>>
<<include>>
Recevoir produit
StockerProduit
MettreAJourStock
ExpedierCommande
represente les fonctionnalites ou cas d’utilisation,necessaires aux utilisateurs
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
12/141
1 Introduction
2 Un panorama d’UML avec ses 14 diagrammes(1) Utilisateurs(2) Aspects fonctionnels - vue logique(3) Aspects fonctionnels - vue des processus(4) Architecture - vue des composants(5) Architecture - vue du deploiement
3 Principes des methodes Orientees Objet
4 Diagrammes d’Utilisation
5 Diagrammes d’Objets
6 Diagrammes de Classes
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
13/141
Le diagramme de classes
LivraisonFournisseur LivraisonClient
+Nom+Adresse+TauxRemise
+AttribuerRemise()
Client
Livraison
+AutoriserLivraison()
+PréparerLivraison()
+Transporter()
+DateLivraison+Destination+Transporteur
ProduitAssemblé ProduitFournisseur
Emplacement
+Couloir+Armoire+Rayon
+DateCommande
+Vendeur
+EnregistrerCommande()
Commande
LigneArticle
+Quantité
Produit
+NoSérie+Description+Précaution
+StockerProduit()+RéserverProduit()
0..*
1..* 0..*
1
0..*
1..*
0..*
0..1
génère >
0..*1
passe >
livre >
Dans la phase d’analyse, ce diagramme represente les entites (desinformations) manipulees par les utilisateurs.Dans la phase de conception, il represente la structure objet d’undeveloppement oriente objet.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
14/141
Le diagramme d’objets
Bus Personne
Destination
:Personne
:Personne:Destination
Conducteur
Passager
*
1
1
*
:Bus Passager
Conducteur
But : illustrer les classes complexes en utilisant des exemples d’instances.Une instance est un exemple concret de contenu d’une classe.En illustrant une partie des classes avec des exemples, on comprend plusclairement les liens necessaires.Cette illustration permet d’apprendre le besoin par l’exemple en evitant dedemander aux interlocuteurs d’etre tout de suite au niveau plus abstrait querepresente le diagramme de classe
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
15/141
1 Introduction
2 Un panorama d’UML avec ses 14 diagrammes(1) Utilisateurs(2) Aspects fonctionnels - vue logique(3) Aspects fonctionnels - vue des processus(4) Architecture - vue des composants(5) Architecture - vue du deploiement
3 Principes des methodes Orientees Objet
4 Diagrammes d’Utilisation
5 Diagrammes d’Objets
6 Diagrammes de Classes
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
16/141
Le diagramme global d’interaction
enregistrer commande client
Préparer livraison
enregistrer achats
mise à jour stock
recevoir produit
stock insuffisant
stock suffisant
commandes clienten attente
permet de donner unevue d’ensemble desinteractions du systeme.realise avec le memegraphisme que lediagramme d’activite.Chaque element dudiagramme peut ensuiteetre detaille a l’aide d’undiagramme de sequenceou d’un diagrammed’activite.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
17/141
Le diagramme d’activite
Utilisateur Système
produits restants
tous les produits traités
critèreaucun
critères saisis
commandes à livrerSaisie critères recherche
commandes à livrerSaisie critères recherche
commandes à livrerRecherche toutes
Recherche commandes à livreravec critère
Affichage listecommandes à livrer
Sélection d’une commandeà préparer
Recherche produitsà livrer (Cde)
Recherche stock (produit)
Affichage infos produits à livrer +stock
Enregistrement livraison
Validation livraison
Mise à jour stock
represente le deroulementdes actions, sans utiliserles objets.En phase d’analyse, il estutilise pour consolider lesspecifications d’un casd’utilisation.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
18/141
Le diagramme de sequences
:expédition
LOOP−Produits
Système :Produit:commande :client :ligneArticle :livraison
1: saisie critère recherche
commandes 2:Recherche Commandes
à livrer3: RechercheClient
de la commande
4: infos client5: infos commandes
à livrer
6: affichage liste
commandes à livrer
7: sélection commande8: recherche produits Commande
9: rechercherQtéStock
10: RetourInfosStockProduits11: retour produits commandés et stock
12: Affichage infos préparation Cde
13: Enregistrement livraison
14: Message livraison préparée
LOOP_Cde
permet de decrire les differents scenarios d’utilisation du systeme.montre quels sont les objets mis en jeu aux differents moments del’execution de la sequence.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
19/141
Le diagramme de communication (collaboration)
UnEmployé
Système
BDCommande Stock
UneCommande
12:notifStockMaj
1:askNoCmd
5:afficheCmd
3:getCmd() 4:retourne Cmd 1234
11:reduireStock()
8:getStockProduit()
9:retourneStockProduit
13:MsgStockMaj10:reserverProduit()
6:getRefProduit()
7:retourneRefProduit
2:retourne 1234
14:afficheMsgCmdTraitee
permet de mettre en evidence les echanges de messages entre objets.peut aider a completer, si besoin, les diagrammes de sequences et declasses.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
20/141
Le diagramme machines a etats (etats-transitions)
EnCommande
CdeClient
entry/AchatFournisseur
Reçu
Livré
réception
Expédié préparation
Préparé
En stock
entry / StockerProduit
Vendu
entry/RéserverProduit
RetourLivraison
decrire le cycle de vie des objets d’une classe.ici : objet de la classe produit
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
21/141
Le diagramme de temps
destine a l’analyse/conception de systemesayant des contraintes temps-reel.
30 sec. 10 sec. 30 sec.
reprise carte
saisie opération
saisie code
attente carte
inactif
inactifattentecarte
saisiecode
30 sec. 10 sec.
opérationsaisie
informationsaffichage
inactif
30 sec.
reprisecarte
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
22/141
1 Introduction
2 Un panorama d’UML avec ses 14 diagrammes(1) Utilisateurs(2) Aspects fonctionnels - vue logique(3) Aspects fonctionnels - vue des processus(4) Architecture - vue des composants(5) Architecture - vue du deploiement
3 Principes des methodes Orientees Objet
4 Diagrammes d’Utilisation
5 Diagrammes d’Objets
6 Diagrammes de Classes
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
23/141
Le diagramme de structure
Le diagramme de structure composite permet de decrire lastructure interne d’un objet complexe lors de son execution.
Voiture
moteur : Moteur rouesAvants : Roue[2]
rouesArrières : Roue[2]
actionne
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
24/141
Le diagramme de composants
Le diagramme de composants decrit l’organisation du systeme du point devue des elements logiciels comme les modules (paquetages, fichiers sources,bibliotheques, executables), des donnees (fichiers, bases de donnees) ouencore d’elements de configuration (parametres, scripts, fichiers decommandes).Ce diagramme permet de mettre en evidence les dependances entre lescomposants (qui utilise quoi).
<<EXE>>
reception.exe
<<librairie>>
BonCde.exe
<<librairie>>
produit.dll
<<librairie>>
stock.dll
<<EXE>>
UI.exe
BC
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
25/141
1 Introduction
2 Un panorama d’UML avec ses 14 diagrammes(1) Utilisateurs(2) Aspects fonctionnels - vue logique(3) Aspects fonctionnels - vue des processus(4) Architecture - vue des composants(5) Architecture - vue du deploiement
3 Principes des methodes Orientees Objet
4 Diagrammes d’Utilisation
5 Diagrammes d’Objets
6 Diagrammes de Classes
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
26/141
Le diagramme de deploiement
La vue de deploiement decrit les ressources materielles et la repartition desparties du logiciel sur ces elements.Le diagramme de deploiement correspond a la description del’environnement d’execution du systeme (materiel, reseau...) et de la facondont les composants y sont installes
<<interface utilisateur>>EntreeCdeUI.exe
<<table>>BD
<<EXE>>SGBD
<<EXE>>reception.exe
<<librairie>>stock.dll
<<librairie>>produit.dll
<<librairie>>BonCde.dll
<<librairie>>
BDinterface.dll
<<Processeur>>PC Client
<<Processeur>>ServeurBD
<<Processeur>>
ServeurTierMedian
<<Ethernet>>
1..* 1
1
1
<<Ethernet>>
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
27/141
En resume
Diagrammes (diagram) BesoinsUtilisateurs
VueLogique
Vue desprocessus
Vue descomposants
Vue dudeploiement
paquetages (Package) Scas d’utilisation (use case) Dde classes (Class) Sd’objets (Object) Sd’etats-transitions D(State machine)d’activites (Activity) Dde sequence (Sequence) Dglobal d’interaction D(Interaction overview)de temps (Timing) Dde communication (Com-munication)
D
de structures composites S(Composite structure)composants (Component) Sdeploiement (Deployment) Sde profil (Profil) S
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
27/141
En resumedécrit les classes d’une
application et leurs
relations statiques
représente les objets
et leurs liens à un
instant donné
UseCase Diagram
DiagramState Machine
Interaction Diagram
Sequence Diagram
DiagramCommunication
Timing Diagram
DiagramInteraction Overview possibles entre
les diagrammes
de séquences
enchainements
décrivent les services rendus
par le système du point de vue
de l’utilisateur
comportement
d’une opération
représenation du
comportement d’un
d’un automate à états
objet sous la forme
représetation du
représentation temporelle
des interactions entres objets
représentation
spaciale des
interactions
entre objets
donnée au
cours du temps
variations d’une
Class Diagram
Object Diagram
Package Diagram
Model Diagram
DiagramComposite Structure
Component Diagram
Manifestation Diagram
Deployment Diagram
DiagramNetwork Architecture
Profile Diagram
représente des
conteneurs logiques
regroupant
des éléments
vue simplifiée des
relations entre
composants d’une classe
représente les
composants d’un point
de vue physique
matériel (ordinateurs,
périphériques)
modélise l’aspect
UML 2.4 Diagram
Structure Diagram Behavior Diagram
vue dynamique
Activity Diagram
vue statique
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
27/141
En resume
Diagramme de cas d’utilisation
Diagramme de séquences
Diagramme d’activités
FONCTIONNEL
Diagrammes de composants
Diagrammes de déploiement
Diagrammes d’objets
Diagramme de classes
STATIQUE
Diagrammes d’états−transitions
Diagrammes de séquences
Diagrammes de collaborations
Diagrammes d’activités
DYNAMIQUE
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
27/141
En resume
Objects
Diagrams
Class
Diagrams
Sequence
Diagrams
Collaboration
Diagrams Statechart
Diagrams
Activity
Diagrams
Deployment
Diagrams
Use Case
DiagramsDiagrams
Component
Utilisateur
Implémentation
EnvironnementComportement
Structure
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
28/141
1 Introduction2 Un panorama d’UML avec ses 14 diagrammes
(1) Utilisateurs(2) Aspects fonctionnels - vue logique(3) Aspects fonctionnels - vue des processus(4) Architecture - vue des composants(5) Architecture - vue du deploiement
3 Principes des methodes Orientees ObjetNotion d’objets informatiquesNotion de ClassesConcepts importants en OO
4 Diagrammes d’UtilisationLes acteursRelations entre CUScenariosCas d’etude
5 Diagrammes d’ObjetsNotations communes a tous les diagrammesDiagramme d’objetsCommunication entre objetsExercice
6 Diagrammes de ClassesRepresentationAssociationsProprietes et contraintesGeneralisation/SpecialisationInterface
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
30/141
Notion d’objet informatique
Peut correspondre a une entite «concrete» (animal,vehicule, ...) ou «abstraite», «conceptuelle» (compteutilisateur, unite d’enseignement, ...)Regrouper dans un composant
des caracteristiques qui concernent une entite informatiquestructure de donneesensemble d’attributsvariables avec nom, type, valeur
les operations liees a cette entiteensemble de fonctions appelees methodesnom, valeur de retour, parametres
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
31/141
Qu’est-ce qu’un objet
Objet = Etat + Comportement + Identité
Etat d’un objetEnsemble des valeurs des attributs de l’objet a un instantdonne
L’etat d’un objet evolue au cours du tempsLes valeurs sont egalement des objets (→ liens entreobjets)
Ma voiture
Marque : "Fiat"
Couleur : bleu
Masse : 943kg
Volume essence : 31 litres
Ma voiture
Marque : "Fiat"
Couleur : bleu
Masse : 943kg
Volume essence : 32 litres
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
32/141
Qu’est-ce qu’un objet
Objet = Etat + Comportement + Identité
Comportement d’un objetRegroupe les competences d’un objet et decrit les actions etreactions de cet objet
Ensemble d’operations/methodes que l’objet peuteffectuer
demarrer, rouler, stopper, ajouter essenceChaque operation est declenchee par l’envoi d’un message
mavoiture.demarrer(), mavoiture.ajouter essence(15)Etat et comportement lies
l’etat est modifie par le comportementle comportement a un instant donne depend de l’etatcourant
mavoiture.demarrer() ne marchera pas simavoiture.volume essence==0
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
33/141
Qu’est-ce qu’un objet
Objet = Etat + Comportement + Identité
Identite d’un objetExistence propre de l’objet
Ce qui identifie l’objet de maniere non-ambigueIndependante de l’etat → 2 objets differents peuvent avoir lememe etatAttribuee implicitement a la creation de l’objet
Ma voiture
Marque : "Fiat"Couleur : bleuMasse : 943kgVolume essence : 32 litres
Une−de−plus
Marque : "Fiat"Couleur : rougeMasse : 943kgVolume essence : 32 litres
Encore−une
Marque : "Peugeot"Couleur : rougeMasse : 867kgVolume essence : 12 litres
Sa voiture
Marque : "Fiat"Couleur : rougeMasse : 943kgVolume essence : 56 litres
ref15 ref56
ref3ref23
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
34/141
Liens entre objets
Pour envoyer un message a un objet, il faut le «connaıtre»L’objet Le conducteur connaıt l’objet Ma voitureConnaıtre un objet revient a avoir une reference qui luicorrespondAttributs, variables, parametres de methodes, ...
Ma voiture
Marque : "Fiat"Couleur : bleuMasse : 943kgVolume essence : 32 litresConducteur : ref67
Encore−une
Marque : "Peugeot"Couleur : rougeMasse : 867kgVolume essence : 12 litres
Le conducteur
Sexe : MCouleur_yeux : bleuAge : 45Voitures : (ref15, ref3)
ref3ref15 ref67
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
35/141
Les objets : en bref
Coherence interne des objetsdonnees + traitementsFaible couplage entre l’objet et l’environnementenvoi de messages entre objets qui se connaissentInsertion dans un scenario de communication par envoi demessages
objets clients : a l’origine d’une interactionobjets serveurs : repondent a la sollicitationen general : client et serveur
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
35/141
Les objets : en bref
Coherence interne des objetsdonnees + traitementsFaible couplage entre l’objet et l’environnementenvoi de messages entre objets qui se connaissentInsertion dans un scenario de communication par envoi demessages
objets clients : a l’origine d’une interactionobjets serveurs : repondent a la sollicitationen general : client et serveur
Que nous manque-t-il ?Decrire abstraitement de la meme maniere des objets ayant
memes structures de donnees (attributs)meme comportement (methodes)
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
36/141
1 Introduction
2 Un panorama d’UML avec ses 14 diagrammes
3 Principes des methodes Orientees ObjetNotion d’objets informatiquesNotion de ClassesConcepts importants en OO
4 Diagrammes d’Utilisation
5 Diagrammes d’Objets
6 Diagrammes de Classes
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
37/141
Les classes
Regroupement d’objets ayant le meme comportementAbstraction decrivant les proprietes communes des objetsqui en sont des instancesUne classe peut decrire une infinite d’instancesUn objet sait toujours a quelle classe il appartient
Marque : StringCouleur : [bleu,rouge,...]Masse : 943kg
Démarrer()
VoitureTa 205
Marque : "Peugeot"Couleur : rouge
Démarrer()
Ma R12
Marque : "Renault"Couleur : bleu
Démarrer()
une voiture
Marque : "..."Couleur : rouge
Démarrer()
une autre voiture
Marque : "..."Couleur : rouge
Démarrer()
Instanciations
UML : nom de la classe
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
38/141
Les classes : implementation Java
Student.java
...public class Student {// Attributsprivate int number ;private String surname ;...// Methodespublic Student () {
number = 0 ;surname = "STUDENT" ;
}public void setNumber (int n) {
number = n ;}public int getNumber (){
return number ;}...} ;
Mode d’acces (public, private,protected), egalement appelevisibilite, specifie avant chaqueattributs ou methodes (cf.encapsulation)Definition des methodes (ecrituredu corps des fonctions) dans ladefinition de la classe, dans ununique fichier .javaObligatoirement un source .javapar classe
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
39/141
Les classes : objet courant this
Acces a l’objet courant au sein d’une methode...public Student () {this . number = 0 ;this . surname = "STUDENT" ;}...
Peut etre omis la plupart du tempsUtile pour lever l’ambiguıte, lorsqu’un parametre porte lememe nom qu’un attribut
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
40/141
Les classes : Instanciation et appel de methodes
Une variable de type Student allouee = une instance de laclasse StudentJava ne supporte que l’allocation dynamique de memoire(allocation dans le TAS).
Student st1 = new Student () ; // Creation dynamiquement// dans le TAS)
st1.setNumber (20121080) ;
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
41/141
Dans un programme OO
On definit des classesleurs attributs, et visibiliteleurs methodes, et visibiliteOn instancie des objets a partir des classesOn lance/gere la collaborationenvoi de messages a des objetsExecution du programme : des objets qui s’envoient des messages quichangent d’etat
Objet = etat + comportement + identiteAttributsMethodes(reference)
ClasseAbstractionDefinit une infinite d’objets instances
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
42/141
1 Introduction
2 Un panorama d’UML avec ses 14 diagrammes
3 Principes des methodes Orientees ObjetNotion d’objets informatiquesNotion de ClassesConcepts importants en OO
4 Diagrammes d’Utilisation
5 Diagrammes d’Objets
6 Diagrammes de Classes
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
43/141
Les Concepts importants de la POO
1 Encapsulation2 Heritage3 Polymorphisme
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
44/141
Encapsulation
Concept fondamental : protection de l’information contenuedans un objet
1 Garantit l’integrite de l’objet (exemple : evite lesaffectations par erreur, = au lieu de == !)
2 Garantit la coherence eventuelle entre plusieurs attributsinter-dependants (exemple : un tableau dynamique et sataille)
3 Masque en partie le fonctionnement interne d’une classe :respecte la notion de Type Abstrait de Donnees (facilite laprise en main du code dans un premier temps)
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
45/141
Visibilite
Notion de visibiliteL’acces aux membres de la classe est different selon quel’on se trouve a l’interieur ou a l’exterieur de la classeA l’interieur de la classe : tout est permisA l exterieur de la classe : le programmeur ne «voit» quece que la classe «veut bien lui montrer»3 niveaux de «visibilite» pour les membres (attributs etmethodes) :- public : accessibles a tous- protected : accessibles seulement aux classes derivees
(voir heritage)- private : accessibles seulement au sein de la classeelle-meme
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
46/141
Visibilite
Student.javaclass Student{ // Attributs
private :int number ;std::string surname ;...
// Methodespublic :
Student () ;void SetNumber ( int n ) ;int GetNumber () ;...
} ;
StudentPair.javapublic class StudentPair {
private Student st1 , st2 ;...public String getSurnames ( ){
String s ;s = st1 . surname + " " +
st2 . surname ;}// ???
} ;
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
47/141
Encapsulation : Accesseurs et mutateurs
AccesseursMethodes get...() : lecture d’un attributObjet non modifieRetour = une copie (valeur) de l’attribut
MutateursMethodes set...() : ecriture d’un attribut (eteventuellement, d’attributs dependants)Objet modifieType de retour = void ou un type indiquant un statut(modification effectuee ou non, ...)
Si possible, un couple accesseur/mutateur par attribut
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
48/141
Encapsulation : Accesseurs et mutateurs
Student.java
public class Student {...private String surname ;...public String getSurname () {return surname ;
}public void setSurname (String s) {surname = new String (s) ;
}...
} ;
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
49/141
Membre statique
Un membre statique est partage par toutes les instances de la classe Utilepour implementer une propriete (variable ou constante) commune a toutesles entites d’une meme classe :attributs / methodes de classeSimilaire a une variable ou fonction globale, mais interne a une classeAcces possible avec ou sans instance de la classeExemple : tout etudiant doit obtenir 180 credits pour valider une licence
Student.javapublic class Student {
...public static int credits = 180;...
} ;...
StudentPair.java...Student st1 = new Student () ;Student st2 = new Student () ;System.out.println (Student.credits) ; // 180System.out.println (st1.credits) ; // 180System.out.println (st2.credits) ; // 180Student.credits= 100;...
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
50/141
Heritage
Concept fondamental : transmission des caracteristiques d’uneclasse vers une sous-classe en faisant deriver une nouvelle classed’une classe existante
Mise en place d’une hierarchie de classes (specialisation,generalisation)Une sous-classe herite des attributs et des methodes de sasuper-classeUne sous-classe peut ajouter/adapter des caracteristiques(attributs et methodes)
Evite la duplication et encourage la reutilisation
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
51/141
Heritage simple : implementation
Conserve la visibiliteUn membre prive sera inaccessible meme dans les classesderiveesEn Java, par defaut, toute classe herite de Object
A.javapublic class A {
private int i ;protected int j ;public int k ;public A() {
i = 0;j = 0;k = 0;
}};
B.javapublic class B extends A {
public B() {i = 0 ; // ? ? ?j = 0 ; // ? ? ?k = 0 ; // ? ? ?
}};
Autre.java
public class Autre {private A a ;private B b ; // a et b alloues
// dans le constructeur...public void setAllToOne () {
a.i = 1 ; // ???a.j = 1 ; // ???a.k = 1 ; // ???b.i = 1 ; // ???b.j = 1 ; // ???b.k = 1 ; // ???
}};
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
52/141
Polymorphisme
Concept fondamental : une meme operation peuts’appliquer a des objets de classes differentes et avoir uncomportement adapte a ces objetsAugmente la genericite et la qualite du code2 types de polymorphisme :
polymorphisme de traitement (ad-doc, overloading ) :mecanisme de surcharge des methodespolymorphisme de donnees
polymorphisme d’heritage (redefinition, sous-typage,masquage, inclusion, specialisation ... overriding ) : unmeme code peut etre applique a des donnees de typesdifferents liees entre elles par une relation d’heritagepolymorphisme parametrique (genericite, template) : unmeme code peut etre applique a n’importe quel type
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
53/141
Polymorphisme de traitement : surcharge de methodes
Definir deux methodes ayant le meme nom, mais pas lameme signature (type et/ou nombre arguments differents)Le compilateur choisit la methode a utiliser en fonction dutype des parametres
private static int addition ( int x , int y) {System.out.println ( "additionne des int" ) ;return x + y ;
}private static float addition ( float x , float y) {
System.out.println ( "additionne des float" ) ;return x + y ;
}
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
54/141
Polymorphisme d’heritage : redefinition de methodes
Possibilite de definir le comportement d’une methodeselon le type d’objet l’invoquantMethode redefinie donne une nouvelle implementation aune methode heritee sans changer sa signatureUne methode redefinie peut etre completement differentede la methode de base, ou bien reutiliser celle-ci eneffectuant des operations supplementaires (super en Java)
Point.java
public class Point {private int x , y ; //Attributs...public Point () { ... } ;public void affiche () {
System.out.println ( x+" , "+y);}
}
PointCouleur.java
public class PointCouleur extends Point {private int couleur ; // Attributs supplementaires...@Overridepublic void affiche () {
super.affiche () ;System.out.println("Couleur:"+ this.couleur);
}}
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
55/141
Polymorphisme d’heritage : methode virtuelle
Methode virtuelle est destinee a etre redefinie dans uneclasse deriveeLe type d’instance (classe fille ou mere) determine lamethode reelle a appeler lors de l’execution (resolutiondynamique de liens)
Point p ;if (...)p = new PointCouleur () ;elsep = new Point () ;p.affiche () ;
En Java, les methodes sont virtuelles par defaut. p.affiche()fait appel a la methode de la classe reellement instanciee avecnew meme si p a ete declare de type Point.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
56/141
Polymorphisme d’heritage : meth. virt. pure, classe abstraite
Une methode virtuelle pure ou abstraite est declaree sans etre definie, et estdonc destinee a etre obligatoirement (re)definie dans une classe derivee(abstract en Java)
Une classe est dite abstraite si elle contient au moins une methode virtuellepure (abstract en Java)
Sert a definir des concepts incomplets qui seront completes dans lessous-classes.Ne peut pas etre instanciee, et est donc destinee a etre derivee.En java, une classe peut etre declaree abstraite sans contenir demethode abstraite
public abstract class Point () {private int x , y ;...public POINT () {...} ;public abstract void affiche();
}
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
57/141
Interface
Heritage multiple impossible en Java : utilisationd’interfacesUne interface est un prototype de classe. Elle definit lasignature des methodes qui doivent etre implementeesdans les classes construites a partir de ce prototype.Une interface est une “classe” purement abstraite donttoutes les methodes sont abstraites et publiques.Une classe peut implementer plusieurs interfaces
Terrestre.javapublic interface Terrestre {
...public void move () ;
} ;
Aquatique.javapublic interface Aquatique {
...public void swim () ;
}
Amphibie.javapublic class Amphibie implements Terrestre , Aquatique {
// Amphibian doit definir les methodes move () et swim ( )public void move () { ... }public void swim () { ... }
}
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
58/141
En resume
OO =
modularite+
encapsulation+
heritage+
polymorphisme
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
59/141
Les Diagrammes d’Utilisation
Decrivent les services rendus par le systeme du point devue de l’utilisateurTechnique pour capturer les exigences fonctionnelles d’unsysteme
Determiner ses limitesDeterminer le comportement du systeme : ce que doit fairele systeme sans specifier comment il le faitComprendre l’attente des utilisateurs et les experts dudomaine
Instruments de validation et de tests du systeme
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
60/141
Les Diagrammes d’Utilisation
Un diagramme de cas d’utilisation definit :le systemeles acteurs qui interagissent avec le systemeles cas d’utilisationsles relations entre acteurs et cas d’utilisations
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
61/141
2 Un panorama d’UML avec ses 14 diagrammes
3 Principes des methodes Orientees Objet
4 Diagrammes d’UtilisationLes acteursRelations entre CUScenariosCas d’etude
5 Diagrammes d’Objets
6 Diagrammes de Classes
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
62/141
Les acteurs
Un acteur represente un role joue par une entite exterieureau systeme (humain ou autre systeme) et qui interagitdirectement avec le systeme etudie
Permet de determiner les limites du systemeUn utilisateur peut etre represente par plusieurs acteursPlusieurs utilisateurs peuvent etre representes par le memeacteur
Categories d’acteurs :acteurs principaux : utilisent les fonctions principales dusysteme, un par CUacteurs secondaires : taches administratives, maintenancemateriel externe : dispositif materiel qui doivent etreutilises (peripheriques)autres systemes avec lesquels le systeme doit interagir
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
63/141
Les acteurs
Relations entre acteurs : generalisation (heritage)
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
64/141
Cas d’utilisation
Un cas d’utilisation represente un service complet attendudu systemeUn cas d’utilisation represente une suite d’interactionsentre un acteur et le systeme qui produisent un resultatobservable interessant pour un acteur particulierChaque cas d’utilisation correspond a une fonction metierdu systeme, selon le point de vue d’un de ses acteursUn cas d’utilisation a un debut et une fin clairementidentifiesUn cas d’utilisation est decrit par une forme verbale
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
65/141
Ex. de cas d’utilisation : distributeur de boissons
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
66/141
2 Un panorama d’UML avec ses 14 diagrammes
3 Principes des methodes Orientees Objet
4 Diagrammes d’UtilisationLes acteursRelations entre CUScenariosCas d’etude
5 Diagrammes d’Objets
6 Diagrammes de Classes
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
67/141
Relations entre cas d’utilisation
Inclusion : precise qu’un cas d’utilisation contient le comportement definidans un autre cas d’utilisation.Mise en commun des comportements communs a plusieurs CU(decomposer, definir des comportements partageables entre plusieurs CU,factorisation des services rendus)
Extension : precise qu’un CU (source) peut dans certains cas s’ajouter aucomportement d’un autre CU (destination)
Extension soumise a une condition d’extensionComportement ajoute insere au niveau d’un point d’extension definidans le CU destination
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
68/141
Relations entre cas d’utilisation
Generalisation : heritage du comportement de base
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
69/141
Relations entre cas d’utilisation : exercice
1 Une agence de voyages organise des voyages ou l’hebergementse fait en hotel. Le client doit disposer d’un taxi quand il arrivea la gare pour se rendre a l’hotel. Completer de diagramme deCU suivant.
2 Certains clients demandent a l’agent de voyages d’etablir unefacture detaillee. Cela donne lieu a un nouveau cas d’utilisationappele « Etablir une facture detaillee ». Comment mettre ce casen relation avec les cas existants ?
3 Le voyage se fait soit par avion, soit par train. Commentmodeliser cela ?
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
71/141
2 Un panorama d’UML avec ses 14 diagrammes
3 Principes des methodes Orientees Objet
4 Diagrammes d’UtilisationLes acteursRelations entre CUScenariosCas d’etude
5 Diagrammes d’Objets
6 Diagrammes de Classes
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
72/141
Scenarios d’un cas d’utilisation
La description d’un CU se fait par des scenarios quidefinissent la suite logique des interactions qui constituentce CUTous les scenarios d’un CU sont issus du meme acteur etont le meme objectifUn CU contient en general un scenario nominal etplusieurs scenarios alternatifs (qui se terminent de faconnormale) ou d’erreur (qui se terminent en echec).
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
73/141
Modelisation fonctionnelle
Identification des acteursIdentification des cas d’utilisationDiagrammes de cas d’utilisationDescription textuelle des cas d’utilisation :
Identification (titre du cas, acteurs concernes, responsable,date, etc.)PreconditionsScenario nominal : suite d’etapes avec objectifs de l’acteurbien identifies et menes a bienEnchainements alternatifsEnchainements d’erreursPostconditions
Description de ces scenarios par des diagrammes desequence (systeme), d’activites.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
74/141
2 Un panorama d’UML avec ses 14 diagrammes
3 Principes des methodes Orientees Objet
4 Diagrammes d’UtilisationLes acteursRelations entre CUScenariosCas d’etude
5 Diagrammes d’Objets
6 Diagrammes de Classes
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
75/141
Un systeme de gestion de comptes bancairescahier des charges : Cette etude de cas concerne un systemesimplifie de gestion des comptes bancaires offrant les servicessuivants :
Retrait d’argent au distributeur automatique de billets (DAB)de la banque pour les porteurs d’une carte bancaire ;Consultation de solde de compte et retrait d’argent audistributeur automatique de billets (DAB) de la banque pour lesporteurs d’une carte bancaire ;Les clients porteurs d’une carte bancaire peuvent faire un depoten numeraire ou en cheques et consulter leurs comptes surinternet.Un client qui effectue un virement peut demander a verifier lesolde de son compte. Cette demande est autorisee si le solde estsuperieur a 15 euros.Toute transaction est securisee et necessite par consequent uneauthentification.
Proposer un diagramme de CU.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
76/141
Identification des acteurs
Quelles sont les entites externes qui interagissent directementavec le DAB ?
Porteur de carte bancaireClient de la banqueCyber-client de la banqueSI banque
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
77/141
Diagramme des cas d’utilisation
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
78/141
Description textuelle du CU : Retirer de l’argent sur DAB
IdentificationTitre : retirer de l’argent sur DABResume : ce cas d’utilisation permet a un Porteur de cartebancaire de retirer de l’argent liquide a un DAB.Acteur principal : porteur de carte bancaireActeur secondiare : SI banqueDate : 28-09-2020Responsable : ...
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
79/141
Description textuelle du CU : Retirer de l’argent sur DAB
PreconditionsLe DAB contient des billetsAucune carte ne se trouve deja coincee dans le lecteurLa connexion avec le SI banque est operationnelle
PostconditionsLa DAB contient moins de billets qu’au debut du casd’utilisationUne transaction de retrait a ete enregistree par le DABavec toutes les informations pertinentes (montant, numerode carte, date, etc.).Les details de la transaction doivent etre enregistres aussibien en cas de succes que d’echec.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
80/141
Description du scenario nominal
1. Le porteur de CB introduit sa cartedans le lecteur du DAB
2. Le DAB verifie que la carte est bienune CB.3. Le DAB demande au porteur de CBde saisir son code d’identification.
4. Le porteur de CB saisit son code.
5. Le DAB verifie le code.6. Le DAB demande une autorisa-tion au SI banque.
7. Le SI banque donne son accord et in-dique le solde hebdomadaire.
8. Le DAB demande au porteur de CBde saisir le montant desire du retrait.
9. Le porteur de CB saisit le montant.10. Le DAB controle le montantpar rapport au solde hebdomadaire.11. Le DAB demande au porteur de cartes’il veut un ticket.
12. Le porteur de CB veut un ticket. 13. Le DAB ejecte la carte.14. Le porteur CB reprend sa carte. 15. Le DAB delivre ticket/billets.16. Le porteur CB prend son ticket et sesbillets.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
81/141
Description du scenario nominal
1. Le porteur de CB introduit sa cartedans le lecteur du DAB
2. Appel du cas « s’authentifier »3. Le DAB demande une autorisation auSI gestion CB
4. Le SI gestion CB donne son accord etindique le solde hebdomadaire.
5. Le DAB demande au porteur de CBde saisir le montant desire du retrait.
6. Le porteur de CB saisit le montant.7. Le DAB controle le montantpar rapport au solde hebdomadaire.8. Le DAB demande au porteur de cartes’il veut un ticket.
9. Le porteur de CB veut un ticket. 10. Le DAB ejecte la carte.11. Le porteur CB reprend sa carte. 12. Le DAB delivre ticket/billets.13. Le porteur CB prend son ticket et sesbillets.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
82/141
Description des scenarii alternatifs
A1 : code d’identification provisoirement erroneDemarre au point 5 : Le DAB indique au porteur de CB que le code esterrone, pour la premiere ou deuxieme fois, puis enregistre l’echec sur lacarte. Le scenario reprend au point 3.A2 : montant demande superieur au solde hebdomadaireDemarre au point 10 : Le DAB indique au porteur de carte que le montantdemande est superieur au solde hebdomadaire. Le scenario nominal reprendau point 8.A3 : ticket refuseDemarre au point 11 : ...
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
83/141
Enchainements d’erreurs
E1 : carte non-valideDemarre au point 2 : Le DAB indique au porteur de CB que sa carte n’estpas valide (illisible, perimee, etc.), la confisque. Le CU se termine en echec.E2 : code d’identification definitivement erroneDemarre au point 5 : Le DAB indique au porteur de CB que le code esterrone, pour la troisieme fois. Le DAB confisque la carte. Le SI est informe ;le cas d’utilisation se termine en echec.E3 : retrait non autorise Demarre au point 6 : Le SI interdit tout retrait. LeDAB ejecte la carte ; le CU se termine en echec.E4 : carte non reprise ...E5 : billets non pris ...E6 : annulation de la transactionDemarre entre points 4 et 12 : ...
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
84/141
4 Diagrammes d’Utilisation
5 Diagrammes d’ObjetsNotations communes a tous les diagrammesDiagramme d’objetsCommunication entre objetsExercice
6 Diagrammes de Classes
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
85/141
Notations communes a tous les diagrammes
ClasseurUn classeur est un element de modele qui est dote d’une identite, possede descaracteristiques structurelles (attributs, participation a des relations) etcomportementales (operations).
Cas d’utilisation
Class
Node Component
Paquetage (package)
Un paquetage est un regroupementd’elements de modele ou de diagrammes.
Class A
Class BActor
Cas d’utilisation
PackageModélisation des besoins
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
86/141
Notations communes
StereotypesAnnotation s’appliquant sur un element de modeleUtilisation particuliere d’elements de modelisation avec interpretation(semantique) particuliereModification de la signification d’un elementNotation : « nomDuStereotype » avant le nom de l’element auquel ils’applique ou icone associeePredefinis : «actor», «includes», «use case», «interface», «include» ...«class» stereotype par defaut d’un classeur
Cas d’utilisation 2
Cas d’utilisation <<include>>
<<actor>>
Acteur
<<use case>>
Cas d’utilisation
<<Classe>>
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
87/141
Notations communes
CommentairesInformation textuelle (explication utile, observations, renvoi versdocument), pas de contenu semantique
Notation :
Relations de dependanceModification de la cible peut impliquer une modification de la sourceLa source «depend» de la cibleNotation :
[source] ------> [cible]
IHM Métier
<< le paquetage IHM est dépendant du paquetage Métier>>
Toute modif dans paquetage metier peut avoir des consequences sur paquetage IHM. Toute modifdans paquetage IHM n’a au vu de cette dependance pas de consequence sur paquetage metier.
Nombreux stereotypes predefinis : «extend», «include», ...
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
88/141
Contraintes
Relation entre elements de modelisationDefinition de proprietes devant etre verifiees pour garantir la validite dusysteme modeliseNotation : {contrainte}3 types de contraintes :
Contraintes predefinies : disjoint, overlapping, xor, ...Contraintes exprimees en langue naturelle (commentaires)Contraintes exprimees avec OCL (Object Constraint Language)
Stereotypes : «precondition», «postcondition»
< 10ms}{temps d’exécution
e−mail
coordonnées postales
lettrejournal
{incomplet}
Information
+ envoie()
{xor}
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
89/141
4 Diagrammes d’Utilisation
5 Diagrammes d’ObjetsNotations communes a tous les diagrammesDiagramme d’objetsCommunication entre objetsExercice
6 Diagrammes de Classes
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
90/141
Les Diagrammes d’Objets
Classes, objets et instancesClasse = description formelle d’un ensemble d’objets ayant unesemantique/caracteristiques communesObjet ou instance de classe = concretisation d’une classe
Instance = toute concretisation d’un concept abstraitinstance de classe : objetinstance d’association entre classes : lien
classes
relations
instance de
instance de
relie relie
*
**
* objets
relations
diagramme de classes diagramme d’objets
extrait simplifié du méta−modèle d’UML
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
91/141
Les Diagrammes d’Objets
ObjectifsRepresente les objets et leurs liens a un instant donneModelise les instances
Representation UML des objets
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
92/141
4 Diagrammes d’Utilisation
5 Diagrammes d’ObjetsNotations communes a tous les diagrammesDiagramme d’objetsCommunication entre objetsExercice
6 Diagrammes de Classes
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
93/141
Communication entre Objets
Liens entre objetsComportement global d’une application reside sur lacommunication entre les objets qui la composent
→ reduction du couplage entre l’objet et l’environnement parenvoi de messages entre objets qui se connaissent
Unite de communication = messageLien entre objets
un objet connaıt un autre objet → avoir une reference quilui correspond (attributs, parametres de methodes, ...)peut envoyer un message a l’autre objet
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
94/141
Representation UML des liens
Lien binaire : entre 2 objetsLien n-aire : entre n objetsPossibilite de decorer les liens (nom, nom des roles)La multiplicite se represente de maniere explicite par lesliens
Canada Ottawa
SNCFLucien
Lucien
:Salle
:Professeur
:Etudiant
p1:Personne :Personne p2:Personne
travailler pourtravailler pour
travailler pour
entrep:Entreprise
nom:string="PERTNE"
a−pour−capitale
employé
employeur
employé
UML : nom de lien
employeur
UML : noms de rôle
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
95/141
Diagramme d’objets
Utilise pourPreciser une structure complexe trop difficile a comprendre avec undiagramme de classes→ Illustrer un modele de classes en montrant un exemple qui explique lemodele→ Preciser certains aspects du systeme→ Exprimer une exception en modelisant des cas particuliers ou desconnaissances non generalisablesPrendre une image (snapshot) d’un systeme a un moment donneDocumenter des cas de test, analyser des exemplesMontrer un contexte (collaborations sans messages)
Ne montre pasL’evolution du systeme dans le temps.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
97/141
Exercice
Modeliser ceci par un diagramme d’objets :Pierre, Paul, Jack, Marie et Anne sont des etudiants audepartement GB de polytechRobert et Suzie sont enseignants au departement GB.Robert enseigne la BioCh et le Bio Cell ; Suzie enseignel’anglais et les maths.Pierre et Paul suivent les cours de BioCh ; Pierre suit lecours de Bio Cell ; Marie et Anne suivent le coursd’anglais ; Anne suit le cours de maths.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
99/141
4 Diagrammes d’Utilisation
5 Diagrammes d’Objets
6 Diagrammes de ClassesRepresentationAssociationsProprietes et contraintesGeneralisation/SpecialisationInterface
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
100/141
Diagramme de Classes
ObjectifDecrire les classes d’une application et leurs relations statiques
Tres nombreuses utilisations, a differents niveauxDiagrammes fondamentaux : les plus connus, les plus utilisesPermettent de modeliser plusieurs niveaux :→ conceptuel (domaine, analyse) (Modele du domaine)→ implementation (code) (Modele de conception)
Qu’est ce qu’une classe d’objets ?Classe = regroupement d’objets similaires (appeles instance)
Toutes les instances d’une classe ont les memes attributs et operationsAbstraction : factorisation des caracteristiques communes a une categoried’objetsUne classe decrit une infinite d’instances
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
101/141
Representation UML des classes
Rectangle compose de compartimentsCompartiment 1 : Nom de la classe (commence par une majuscule, en gras)Compartiment 2 : AttributsCompartiment 3 : OperationsPossibilite d’ajouter des compartiments (exceptions, ...)
Differents niveaux de detail possiblesPossibilite d’omettre attributs et/ou operations
Personne
− prénom : string− dateNaissance : Date− sexe : {’M’,’F’}
+ calculAge() : Int+ renvoyerNom() : String+ modifierNom(String)
NomClasse1
attr1 : Chaineattr2 : Entier..
op1(p1:Entier): Entierop2() : Chaine...
NomClasse2
attr1attr2
NomClasse3
Le nom de classe doit etre significatif, complet, et commencer par une majuscule. S’il est composé deplusieurs mots, la 1ère lettre de chaque mot doit etreune majuscule
(visibilité) éventuelsListe des attributs avec les modes d’accès
Liste des méthodes avec les modes d’accès(visibilité) éventuels.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
102/141
Nom de la classe
Tout est facultatif sauf le nom de la classe
<<stereotype>> NomPaquetage1:: ... ::NomPaquetageN::NomClasse{abstract} {auteur : valeur, etat : valeur, ...}
ClientBanque
java::util::vector
Personne<<interface>>
véhiculeanimal {abstract}
Math::Geometry::Surface
{auteur: Robert, état: validée}
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
103/141
Attributs et Operations
Encapsulation et visibilite des attributs et des operationsMecanisme consistant a rassembler les donnees et les methodes au sein d’unestructure en cachant l’implementation de l’objet. 4 niveaux
Public : attributs accessibles et modifiables par n’importe quelle autreclasse, operations utilisables par n’importe quelle autre classe,Prive : attributs inaccessibles pour toute autre classe, operationsinutilisables pour toute autre classeProtege : attributs accessibles et modifiables uniquement par les classesderivees, operations utilisables uniquement par les classes derivees.Aucun caractere, ni mot-cle : propriete ou classe visible uniquement dans lepaquetage ou la classe est definie
Attributs / Operations de classeAttributs (ou operations) communs a l’ensemble des instances d’une classe(static)
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
104/141
Representation UML des attributs
Format de description d’un attribut :
Attributs de classe (statiques) soulignesAttributs derives (calcules) precedes de “/”Enumeration : stereotype «enumeration»
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
105/141
Representation UML des operations
Format de description d’une operation :
operations abstraites (non implementees) / operations de classe (statiques)Proprietes : abstract, query (l’operation n’altere pas l’etat de l’instanceconcernee), pre- et post-conditions, description du contenu (commentaires,OCL)Stereotypes d’operations : constructeur «create», destructeur «destroy»
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
106/141
4 Diagrammes d’Utilisation
5 Diagrammes d’Objets
6 Diagrammes de ClassesRepresentationAssociationsProprietes et contraintesGeneralisation/SpecialisationInterface
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
107/141
Associations entre classesAbstraction des relations definies par les liens entre objets
il y a exactement un C2 associe a tout C3il y a au maximum un C3 associe a tout C2
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
108/141
Associations entre classes : notions
Notion d’associationsRelation entre deux classes (binaire) ou plus (n-aire).Decrit les connexions structurelles entre les instances des classes associees2 facons de modeliser une association
Les associations sont utilisees pour materialiser les relations entre elementsqui font partie de la modelisation.Les attributs sont utilises pour modeliser des types de donnees depourvusd’identite.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
109/141
Associations entre classes : Nom, role et multiplicite
Nom : forme verbaleSens de lecture de l’association indique eventuellement par une flecheMultiplicite : nombre (ou intervalle de nombres) d’instance(s) quel’association peut impliquer.→ exactement un se note 1 ou 1..1→ plusieurs se note * ou 0..→ au moins un se note 1..→ de un a six se note 1..6Role : forme nominale decrivant le statut de la classe dans l’association.Peut contenir un mode d’acces.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
110/141
Associations entre classes : Nom, role et multiplicite
Exemple : une personne travaille pour une et une seule entreprise. L’entrepriseemploie au moins une personne. L’entreprise est l’employeur des personnes quitravaillent pour elle et une personne a un statut d’employe dans l’entreprise.
1..*
employé
Personne 1
employeur
Entreprisetravaille pour
Incidence sur l’implementation :La classe Personne a un attribut de nom employeur → Type =EntrepriseLa classe Entreprise a un attribut de nom employe → Type =collection de Personne
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
111/141
Associations entre classes : Associations n-aires
Association entre au moins trois classesChaque instance de l’association est un tuple de valeurs provenant chacunede leurs classes respectivesExemple : un etudiant suit le cours d’un professeur responsable pendant unsemestre. Il peut suivre plusieurs cours d’un meme professeur responsablePour une paire (cours, etudiant), il n’existe qu’un professeur. Pour unepaire (etudiant, professeur), il existe plusieurs cours. Pour une paire (cours,professeur), il existe plusieurs etudiants
Cours Professeur
Etudiant
* 1
*
Inscription
responsable
inscrit
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
112/141
exercice 1 : instanciation de diagrammes de classes
Proposer le plus petit diagramme d’objets respectant le diagrammede classes :
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
114/141
Associations entre classes : Reflexivite, symetrie/asymetrie
Exemple : une personne peut etre parent d’autres personnes et enfant d’auplus deux personnes connues. Deux personnes peuvent etre amies (onconsidere que l’amitie est reciproque).Les associations de parente et d’amitie sont reflexives : elles associent laclasse Personne avec elle-memeLa relation de parente est asymetrique, donc orientee (si une instance A estparent d’une instance B, l’inverse ne peut pas etre possible simultanement)La relation d’amitie est symetrique (=non-orientee). Il est inutile despecifier des roles dans ce cas.
Une instance de la classe impliquee peut etre reliee a elle-meme ou ad’autres instances de cette meme classe.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
115/141
Associations entre classes : Navigabilite
Indique s’il est possible de traverser une associationSi un lien est naviguable d’un objet A vers un objet B, alors A aconnaissance de B et peut solliciter l’interface de BPar defaut : Navigabilite dans les deux sensExemple : un polygone est defini par au moins 3 points jouant le role desommets. Un point peut etre sommet de plusieurs polygones. Les sommetsdu polygone ne sont accessibles que par la classe et ses descendants. Onconsidere qu’il est inutile que les points aient un lien vers les polygonesdans lesquels ils sont sommets.
Polygone Point
* 3..*
a pour sommet #sommet
Navigation possible uniquement du polygone vers les points : un polygoneconnaıt les points qui lui servent de sommets, mais un point ne connaıt pasles polygones dans lesquels il est sommetIncidence sur l’implementation : la classe Polygone contiendra unecollection de Point. La classe Point ne contiendra aucun attribut detype Polygone.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
116/141
Associations particulieres : agregation
AgregationModeliser regroupement de parties dans un tout
Association non-symetriqueRelation de dominance et de subordinationUne classe fait partie d’une autre classeUne action sur une classe implique une action sur une autre classe
Une classe peut appartenir a plusieurs agregats
Annuaire Individu
1 0..*
Segment Point
1 2
Segment Point
1 2
Polygone
3..* 1
Personne Immeuble
1..* 0..*
Propriétaire
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
117/141
Associations particulieres : composition
compositionAgregation forteContenance structurelle Creation/Copie/Destruction du composite →Creation/Copie/Destruction de ses composantsUn composant appartient a au plus un composite(mult. cote conteneur max 1)
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
118/141
Composition, Agregation et Association
Quelques questions a se poser :assymetrie et lien de subordination entre instances des deux classes(→ agregation/composition)ou independance des objets (→ association) ?Propagation d’attributs ou d’operations du tout vers les parties ?→ agregation/compositionCreation et destruction des parties avec le tout ?→ composition
Remarques importantes :Dans le doute, toujours utiliser une association (c’est la moinscontrainte)Choix entre composition et agregation peut etre laisse a la phase deconception
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
119/141
Exercice 2 : Identification des classes et relations
Une voiture est caracterisee par une marque, un modele et unemotorisation. La marque d’une voiture est forcement l’une des suivantes :Citroen, Fiat, Ford, Nissan, Peugeot, Renault, Toyota ou Volkswagen.Le moteur d’une voiture est caracterise par une designation et unepuissance.Une voiture possede 4 roues et le moteur actionne deux de ces roues.
1 Modeliser cette situation a l’aide d’un diagramme de classes.2 Proposer un diagramme d’objets compatible avec ce diagramme de classes
et comportant un seul objet Voiture.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
121/141
4 Diagrammes d’Utilisation
5 Diagrammes d’Objets
6 Diagrammes de ClassesRepresentationAssociationsProprietes et contraintesGeneralisation/SpecialisationInterface
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
122/141
Associations : proprietes et contraintes
Contraintes predefinies (Utilisation du langage OCL)Sur une extremite : relation d’ordre ordered, ...Entre 2 associations : inclusion subset, exclusion xor, ...
1 Les sommets dans un polygonesont ordonnes :
2 Une personne travaille dans unservice, et elle peut, en plus,gerer ce service. Plusieursemployes peuvent cogerer unservice.
3 Une personne (etudiant ouenseignant) est associee a unematiere, soit parce qu’ellel’enseigne, soit parce qu’elle lasuit (mais jamais les deuxsimultanement)
4 Un vehicule a des attributspropres (sa charge par ex.) etest d’une certaine categorie. Lacharge max autorisee pour unvehicule depend que de lacategorie, pas du vehicule lui-m.
PointPolygone
*
a pour sommet#sommet
3..*{ordered}
Servicetravaille dans1..* 1
{subset}1..* 1
gère
Personne
Matière1..*
1..*
suit
Personne enseigne
{xor}
0..*
0..*
Catégorie*Véhicule est de type 1
charge: Int {Véhicule.charge<Catégorie.chargeMax} chargeMax:Int
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
123/141
Associations : proprietes et contraintes
Proprietes sur extremites d’associations{variable} : instance modifiable (par defaut){frozen} : instance non modifiable{addOnly} : instances ajoutables mais non retirables (si mult. >1)
{frozen}
2..*Véhicule Roue
La contrainte {frozen} precise que le nombre de roues d’un vehicule ne peut pasvarier.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
124/141
Exercice sur les proprietes et contraintes :
Modeliser avec un diagramme de classes les enonces suivants (il y a toujours aumoins un classe Personne) :
Un comite est compose d’au moins 2 personnes qui sont ses membres.L’unique president du comite est egalement un membre du comite.Un hotel a plusieurs clients et un ou plusieurs employes. Les employes del’hotel n’ont pas le droit de prendre une chambre dans ce meme hotel.Une personne est nee dans un pays et cela ne peut etre modifie. Unepersonne a visite un certain nombre de pays, dans un ordre donne, et lenombre de pays visites ne peut que croıtre. Une personne aimerait encorevisiter toute une liste de pays, et selon un ordre de preference.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
126/141
Classes-Associations
Une association peut etre raffinee et avoir ses propres proprietes, qui nesont disponibles dans aucune des classes qu’elle lie.Une association peut etre representee par une classe pour ajouter attributset operations a des associationsExemple : une personne a travaille dans des entreprises, a des periodesdonnees et avec un certain salaire.
Personne Entreprisetravaille dans1..* 1..*
employé employeur
Poste
salaire: RealdateDeb: DatedateFin: Date
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
127/141
Classes-Associations
Une classe-association peut etre remplacee par une classe intermediaire quisert de pivot (on separe la relation initiale : attention au changement demultiplicite par rapport a la version avec classe-association)
Souvent lorsque relation de plusieurs a plusieurs : reduction des associationsn-aires
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
128/141
Associations qualifiees
Parfois preferable de restreindre la portee de l’association a quelqueselements cibles (comme un ou plusieurs attributs) de la classe : qualificatifUn qualificatif permet de selectionner un sous-ensemble d’instances : objetsciblesUn qualificatif agit toujours sur une association dont la multiplicite estplusieurs (avant que l’association ne soit qualifiee) du cote cible.
Case
Echiquier1
64Case11
Classe qualifiee
qualificatif
Classe cible
Echiquierrangee : Rangeecolonne : Colonne
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
129/141
4 Diagrammes d’Utilisation
5 Diagrammes d’Objets
6 Diagrammes de ClassesRepresentationAssociationsProprietes et contraintesGeneralisation/SpecialisationInterface
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
130/141
Generalisation/Specialisation
Deux interpretationsNiveau conceptuel- Relation transitive, non reflexive, et non symetrique- Un concept est plus general qu’un autre : hierarchie de classesNiveau implementation : Heritage- La sous-classe herite des attributs et methodes de sa super-classe- La sous-classe est une «sorte» de la super classe :
Toute instance de la sous-classe est instance de la super-classe- Ajout d’elements propres, redefinition
Individu
NomPrénomAge
Enseignant
SpécialitéAncienneté
SoldeCréation
Compte Bancaire
Taux d’intérêt
Compte épargne
Véhiculeabstrait
Voiture
Spéc
iali
sati
on
par
exte
nsi
on
Gén
éral
isat
ion
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
131/141
Generalisation/Specialisation
ContraintesLes seules contraintes pre-definies en UML pour la generalisation sont :
{disjoint} (par defaut) = les sous-classes n’ont aucune instance encommun{overlapping} = les sous-classes peuvent avoir une ou plusieurs instancesen commun
VoitureVoiture amphibieBateau
Vehicule terrestrevehicule marin
Vehicule
Voiture amphibie Vehicule terrestrevehicule marin
Bateau
Vehicule
Voiture
overlapping
{overlapping} precise ici qu’il existe des vehicules amphibiesqui sont issus d’un croisement des sous-classes de vehicule.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
132/141
Generalisation/Specialisation
ContraintesLes seules contraintes pre-definies en UML pour la generalisation sont :
{complete} (liste exhaustive de classe) / {incomplete} (les sous-classesspecifiees ne couvrent pas la super-classe)
{disjoint,complete}
{disjoint,incomplete}
PersonnenomnumSecu
Avocat Vendeur EnseignantnbAffairesadressCabinet
anciennetenomDuStand
nbCoursspecialite
PermanentnumBureau
VacatairenbVacations
{incomplete} exprime l’idee que des instances de la classe Personne sont desavocats, des vendeurs, des enseignants ou d’autres personnes ...{complete} exprime l’idee qu’un enseignant ne peut etre autre chose qu’unpermanent ou vacataire.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
133/141
4 Diagrammes d’Utilisation
5 Diagrammes d’Objets
6 Diagrammes de ClassesRepresentationAssociationsProprietes et contraintesGeneralisation/SpecialisationInterface
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
134/141
Interface
Qu’est-ce qu’une interface ?Classe sans attributs dont toutes les operations sont abstraites (classe abstraitepure)
Liste de services, savoir faireNe peut etre instancieeDoit etre realisee (implementee) par des classes non abstraitesPeut heriter d’une autre interface
Stereotype <<realize>> facultatif
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
135/141
Interface
Une classe peut aussi simplement dependre d’une interface (interface requise).
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
136/141
Classes generiques/parametrables
Objectif : regrouper les comportements associes a la structure de la classeindependamment des objets qu’elle contient
Souvent utilisee pour les classes correspondant a des “collections”d’element(s) : tableau dynamique, liste (simplement chainee, doublementchainee, triee ou non, ...), table de hashage, ensemble, ...→ le parametre est alors le type d’objet contenuDisponible en C++ (patrons de classe = templates) et en Java (depuis laversion 1.5 classes generiques)
ListeChaineeTriee
+insererElement(elem : T)+enleverElement(elem : T)+vider()...
T
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
137/141
Classes generiques/parametrables
Parametrisation d’une classe parametrable = instanciation des parametres(binding). Deux notations possibles.
ListeChaineeTriee
+insererElement(elem : T)+enleverElement(elem : T)+vider()...
ListeChaineeTriee
+insererElement(elem : T)+enleverElement(elem : T)+vider()...
ListeChaineeTrieeEntiers
ListeChaineeTrieeEntiers<T→Int>
«bind»T→ Entier
T
T
Differents parametres possibles (type specifie ou non (ex : T))
VecteurND-array : T[n]
+normeL2() : T+produitScalaire(v :VecteurND) : T
Point3D«bind»T→Realn→3
Un point ou vecteur de l’espace reel
T, n : Entier
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
138/141
Exercices : associations entre classes
Modeliser les phrases suivantes par un diagramme de classes, notammentdeterminez la relation statique appropriee (generalisation, composition, agregationou association)
1 Un repertoire contient des fichiers.2 Une piece a des murs.3 A l’universite, un batiment d’enseignement dispose d’un certain nombre de
salles et de chaises. A un instant donne, une chaise est obligatoirement al’interieur d’une salle. Une chaise peut etre deplacee dans une autre salleselon les besoins.
4 Les modems et les claviers sont des peripheriques d’entree/sortie (il enexiste d’autres).
5 Une transaction boursiere est un achat ou une vente.6 Un compte bancaire peut appartenir a une personne physique ou morale.7 Deux personnes peuvent etre mariees.8 Un pays possede plusieurs villes et une seule capitale.
GL & UML
J-P Comet
IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.
Principes OOObjetsClassesConcepts
Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude
Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice
Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface
141/141
Exercices : Interfaces et heritage multiple
Les etudiants sont des personnes qui peuvent s’incrire et se desinscrire al’universite.Les enseignants, identifies par un numero, sont des personnes qui dispensent descours a l’universite. Un cours, caracterise par son intitule et ses credits, n’estdispense que par un seul enseignant.Les doctorants peuvent s’inscrire et se desinscrire a l’universite comme lesetudiants et dispenser des cours comme les enseignants.
Proposer une modelisation de cette situation en utilisant l’heritage multiple.Proposer une modelisation de cette situation en utilisant une interface pours’affranchir de l’heritage multiple.
Recommended