duction uml g uml - laboratoire d'informatique, signaux et...

33
GL & UML J-P Comet Introduction Les 14 Diag. (1) Utilisateurs (2) Fonctionnel-log. (3) Fonctionnel-proc. (4) Archi-comp. (5) Archi-d´ epl. Principes OO Objets Classes Concepts Diag. d’Util. Les acteurs Relations entre CU Sc´ enarios Cas d’´ etude Diag. d’Objets Notations communes Diagramme d’objets Communication Exercice Diag. Classes Repr´ esentation Associations Propri´ et´ es/contraintes en´ eral./Sp´ ecial. Interface 1/138 enie Logiciel et UML Introduction ` a UML Jean-Paul Comet (projet Bioinfo Formelle) EPU dept GB-BIMB - 5` eme ann´ ee / Master 2 SVS-BIM Universit´ e de Nice Sophia-Antipolis 4 septembre 2017 GL & UML J-P Comet Introduction Les 14 Diag. (1) Utilisateurs (2) Fonctionnel-log. (3) Fonctionnel-proc. (4) Archi-comp. (5) Archi-d´ epl. Principes OO Objets Classes Concepts Diag. d’Util. Les acteurs Relations entre CU Sc´ enarios Cas d’´ etude Diag. d’Objets Notations communes Diagramme d’objets Communication Exercice Diag. Classes Repr´ esentation Associations Propri´ et´ es/contraintes en´ eral./Sp´ ecial. Interface 3/138 Introduction ` a UML Lorsqu’on cherche ` a r´ ealiser un projet, qu’il soit informatique ou non, on passe par plusieurs phases dont les deux premi` eres sont la phase d’analyse, et celle de conception. phase d’analyse : faire comprendre les besoins des utilisateurs et/ou clients. Que souhaitent-ils faire avec le logiciel ? Quelles fonctionnalit´ es veulent-ils ? Pour quel usage ? Comment l’action devrait-elle fonctionner ? C’est ce qu’on appelle l’analyse des besoins . Apr` es validation de cette compr´ ehension du besoin, on peut passer ` a la phase de d’ analyse de la solution , au cours de laquelle on imagine la solution. La phase d’analyse est donc la compr´ ehension en profondeur des exigences ` a partir de la construction de mod` eles phase de conception : apporte plus de d´ etails clarifier des aspects techniques, comme l’installation des diff´ erentes parties logicielles sur du mat´ eriel. GL & UML J-P Comet Introduction Les 14 Diag. (1) Utilisateurs (2) Fonctionnel-log. (3) Fonctionnel-proc. (4) Archi-comp. (5) Archi-d´ epl. Principes OO Objets Classes Concepts Diag. d’Util. Les acteurs Relations entre CU Sc´ enarios Cas d’´ etude Diag. d’Objets Notations communes Diagramme d’objets Communication Exercice Diag. Classes Repr´ esentation Associations Propri´ et´ es/contraintes en´ eral./Sp´ ecial. Interface 4/138 Qu’est-ce qu’UML ? UML = Unified Modeling Language UML = Langage unifi´ e pour la mod´ elisation objet Definition efinition d’UML selon l’OMG Langage visuel d´ edi´ e` a la sp´ ecification, la construction et la documentation d’un syst` eme logiciel OMG = Object Management Group (www.omg.org) : Fond´ e en 1989 pour standardiser et promouvoir l’objet GL & UML J-P Comet Introduction Les 14 Diag. (1) Utilisateurs (2) Fonctionnel-log. (3) Fonctionnel-proc. (4) Archi-comp. (5) Archi-d´ epl. Principes OO Objets Classes Concepts Diag. d’Util. Les acteurs Relations entre CU Sc´ enarios Cas d’´ etude Diag. d’Objets Notations communes Diagramme d’objets Communication Exercice Diag. Classes Repr´ esentation Associations Propri´ et´ es/contraintes en´ eral./Sp´ ecial. Interface 4/138 Qu’est-ce qu’UML ? UML = Unified Modeling Language UML = Langage unifi´ e pour la mod´ elisation objet UML est un langage universel de mod´ elisation objet ... pas une ethode Diff´ erence Langage – M´ ethode Langage de mod´ elisation = notations, grammaire, s´ emantique ethode = comment utiliser le langage de mod´ elisation (recueil des besoins, analyse, conception, mise en oeuvre, validation, ...)

Upload: vuongkhanh

Post on 18-Oct-2018

217 views

Category:

Documents


0 download

TRANSCRIPT

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/138

Genie Logiciel et UMLIntroduction a UML

Jean-Paul Comet (projet Bioinfo Formelle)

EPU dept GB-BIMB - 5eme annee / Master 2 SVS-BIMUniversite de Nice Sophia-Antipolis

4 septembre 2017

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/138

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/138

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/138

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/138

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/138

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/138

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/138

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/138

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/138

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/138

Les 4+1 vues d’un systeme

Aspects fonctionnels Architecture

(3)Vue dudéploiement

composants(2)Vue des(2)

(3)

Vue logique

Vue desprocessus

(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/138

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/138

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/138

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/138

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/138

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/138

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/138

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/138

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

17/138

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/138

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

21/138

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/138

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/138

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/138

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/138

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/138

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/138

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/138

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/138

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

28/138

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/138

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/138

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/138

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

34/138

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/138

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/138

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 ?

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/138

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/138

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/138

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

40/138

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

42/138

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

44/138

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

46/138

Visibilite

Student.javaclass Student{ // Attributs

private :int number ;std::string surname ;...

// Methodespublic :

Student () ;void SetNumber ( int n ) ;int GetNumber () const ;...

} ;

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

48/138

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/138

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 . c r e d i t s = 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/138

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/138

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/138

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/138

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/138

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/138

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/138

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/138

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/138

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/138

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/138

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/138

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/138

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/138

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/138

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/138

Exemple des cas d’utilisation d’un distributeur deboissons

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/138

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/138

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

70/138

Relations entre cas d’utilisation : exerciceGL & 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/138

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/138

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/138

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/138

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/138

Un systeme de gestion de comptes bancaires

cahier des charges : Cette etude de cas concerne un systemesimplifie de gestion des comptes bancaires offrant les servicessuivants :

Consultation de solde de compte et retrait d’argent audistributeur automatique de billets (DAB) de la banque pour lesclients porteurs d’une carte bancaire ;Les clients porteurs d’une carte bancaire de la banque peuventeffectuer un virement depuis le DAB de la banque ou depuisinternet. Ils peuvent aussi faire un depot en numeraire ou encheques et consulter leurs comptes sur internet.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/138

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/138

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/138

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-01-2013Responsable : ...

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/138

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/138

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 de-mande au porteur de CB de saisir soncode 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/138

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

82/138

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/138

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/138

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/138

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

88/138

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/138

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/138

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/138

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/138

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/138

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/138

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/138

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/138

Exercice

Modeliser ceci par un diagramme d’objets :Pierre, Paul, Jacques, 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

98/138

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

99/138

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

102/138

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

103/138

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

104/138

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

105/138

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

106/138

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

107/138

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

108/138

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

109/138

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

110/138

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

Cours

* 1

*

Inscriptionresponsable

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

111/138

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

112/138

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

113/138

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

114/138

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

115/138

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

116/138

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

117/138

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

118/138

Exercice 2 : Identification des classes et relations

Roue 1

Roue 4Roue 2

Roue 3

Roue 2b Roue 4b

Roue 1b Roue 3b

marque

modèle

motorisation

Voiture

Moteur

Roue

désignationpuissance

4

0..1

21

1

1actionne

Moteur 1

Voiture 1

Moteur 2

Voiture 2

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/138

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

120/138

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

122/138

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

123/138

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

124/138

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

125/138

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.

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/138

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

127/138

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

128/138

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

{overlapping} precise ici qu’il existe des vehicules amphibiequi 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

129/138

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)

{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’un permanent ouvacataire.

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/138

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

131/138

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

132/138

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

133/138

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)

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/138

Classes generiques/parametrablesParametrisation d’une classe parametrable = instanciation des parametres(binding). Deux notations possibles.

Differents parametres possibles (type specifie ou non (ex : 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

135/138

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

136/138

Exercices : associations entre classes

1 Un repertoire contient des fichiers.

2 Une piece a des murs.

3 Batiments / Classes / chaises.

4 peripheriquesd’entree/sortie

5 transaction boursiere

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/138

Exercices : associations entre classes

1 Un repertoire contient des fichiers.

2 Une piece a des murs.

3 Batiments / Classes / chaises.

4 peripheriquesd’entree/sortie

5 transaction boursiere

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/138

Exercices : associations entre classes

1 Un repertoire contient des fichiers.

2 Une piece a des murs.

3 Batiments / Classes / chaises.

4 peripheriquesd’entree/sortie

5 transaction boursiere

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/138

Exercices : associations entre classes

1 Un repertoire contient des fichiers.

2 Une piece a des murs.

3 Batiments / Classes / chaises.

4 peripheriquesd’entree/sortie

5 transaction boursiere

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/138

Exercices : associations entre classes

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

137/138

Exercices : associations entre classes

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

137/138

Exercices : associations entre classes

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

138/138

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.