Introduction a UML Jean-Paul Comet (projet Bioinfo Formelle ...GL & UML J-P Comet Introduction Les 14 Diag. (1) Utilisateurs (2) Fonctionnel-log. (3) Fonctionnel-proc. (4) Archi-comp

GL & UML

J-P Comet

IntroductionLes 14 Diag.(1) Utilisateurs(2) Fonctionnel-log.(3) Fonctionnel-proc.(4) Archi-comp.(5) Archi-depl.

Principes OOObjetsClassesConcepts

Diag. d’Util.Les acteursRelations entre CUScenariosCas d’etude

Diag. d’ObjetsNotations communesDiagramme d’objetsCommunicationExercice

Diag. ClassesRepresentationAssociationsProprietes/contraintesGeneral./Special.Interface

1/141

Genie Logiciel et UMLIntroduction a UML

Jean-Paul Comet (projet Bioinfo Formelle)

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

octobre 2020

GL & UML

J-P Comet






3/141

Introduction a UML

Lorsqu’on cherche a realiser un projet, qu’il soit informatique ou non, on passepar plusieurs phases dont les deux premieres sont la phase d’analyse, et celle deconception.

phase d’analyse : faire comprendre les besoins des utilisateurs et/ou clients.

Que souhaitent-ils faire avec le logiciel ?Quelles fonctionnalites veulent-ils ? Pour quel usage ?Comment l’action devrait-elle fonctionner ?

C’est ce qu’on appelle � l’analyse des besoins �. Apres validation de cettecomprehension du besoin, on peut passer a la phase de d’� analyse de lasolution �, au cours de laquelle on imagine la solution.La phase d’analyse est donc la comprehension en profondeur des exigencesa partir de la construction de modelesphase de conception : apporte plus de detailsclarifier des aspects techniques, comme l’installation des differentes partieslogicielles sur du materiel.

GL & UML

J-P Comet






4/141

Qu’est-ce qu’UML ?

UML = Unified Modeling LanguageUML = Langage unifie pour lamodelisation objet

DefinitionDefinition d’UML selon l’OMG Langage visuel dedie a laspecification, la construction et la documentation d’un systemelogiciel

OMG = Object Management Group (www.omg.org) : Fonde en1989 pour standardiser et promouvoir l’objet

GL & UML

J-P Comet






4/141



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






4/141



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






4/141



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






4/141



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






4/141



GL & UML

J-P Comet






5/141

But du cours

Decrire le langage UML et ses outils (les diagrammes)Diagrammes : contribuent a chacune des phases d’unprojet, de la phase d’analyse des besoins a la maintenance.Chaque diagramme donne une vision differente du projet.Ils permettent de representer le logiciel a developper : sonfonctionnement, sa mise en route, les actions susceptiblesd’etre effectuees par le logiciel, etc.

Realiser ces diagrammes=

modeliser les besoins du logiciel

GL & UML

J-P Comet






6/141

Un panorama d’UML avec ses 14 diagrammes

Tout comme la construction d’une maison necessite des plans a differentsniveaux (vision exterieure, plan des differents etages, plans techniques...),la realisation d’une application informatique ou d’un ensemble d’applica-tions est basee sur plusieurs diagrammes.

Les 14 diagrammes peuvent etre regroupes selon les trois aspects suivants :1 Les aspects fonctionnels : Qui utilisera le logiciel et pour quoi faire ?

Comment les actions devront-elles se derouler ? Quelles informationsseront utilisees pour cela ?

2 Les aspects lies a l’architecture (statique) : Quels seront les differentscomposants logiciels a utiliser (base de donnees, librairies, interfaces,etc.) ? Sur quel materiel chacun des composants sera installe ?

3 Les aspects dynamiques : Quels sont les differents etats que peutprendre un objet, dans quel ordre ? quels sont les enchaınements demessages envisageables...

GL & UML

J-P Comet






7/141

Les 4+1 vues d’un systeme

Aspects fonctionnels Architecture

Vue dudéploiement

composantsVue des(2)

(3)

Vue logique

Vue desprocessus

(4)

(5)

(1)

utilisateurs

Besoins des

Representation des aspects fonctionnels et d’architecturepar le schema de 4 vues, axees sur les besoins des utilisateurs

GL & UML

J-P Comet






8/141

1 Introduction

2 Un panorama d’UML avec ses 14 diagrammes(1) Utilisateurs(2) Aspects fonctionnels - vue logique(3) Aspects fonctionnels - vue des processus(4) Architecture - vue des composants(5) Architecture - vue du deploiement

3 Principes des methodes Orientees Objet

4 Diagrammes d’Utilisation

5 Diagrammes d’Objets

6 Diagrammes de Classes

GL & UML

J-P Comet






9/141

Le diagramme de contexte

Le situer dans son environnement (ce qui le concerne et cequi ne le concerne pas)Identifier ses flux d’informations avec son environnementDelimiter ce qu’il y a a faire et ne pas faire

GL & UML

J-P Comet






10/141

Le diagramme de package

Un acteur

"package"

Une partie ou

Commercial

Expédition

Service Achats

Réception

Stockage

Clientgestion commandesclient

gestion des stocks

Système

gestion des achats

decomposer le systeme en categories ou parties plusfacilement observables, appeles � packages �.

GL & UML

J-P Comet






11/141

Le diagramme de cas d’utilisation

Un cas d’utilisation (une fonctionnalité)

Stockage

<<system>>Compta Fournisseurs

Réception

Expédition

Système

<<extend>>

<<include>>

<<include>>

Recevoir produit

StockerProduit

MettreAJourStock

ExpedierCommande

represente les fonctionnalites ou cas d’utilisation,necessaires aux utilisateurs

GL & UML

J-P Comet






12/141

1 Introduction






GL & UML

J-P Comet






13/141

Le diagramme de classes

LivraisonFournisseur LivraisonClient

+Nom+Adresse+TauxRemise

+AttribuerRemise()

Client

Livraison

+AutoriserLivraison()

+PréparerLivraison()

+Transporter()

+DateLivraison+Destination+Transporteur

ProduitAssemblé ProduitFournisseur

Emplacement

+Couloir+Armoire+Rayon

+DateCommande

+Vendeur

+EnregistrerCommande()

Commande

LigneArticle

+Quantité

Produit

+NoSérie+Description+Précaution

+StockerProduit()+RéserverProduit()

0..*

1..* 0..*

1

0..*

1..*

0..*

0..1

génère >

0..*1

passe >

livre >

Dans la phase d’analyse, ce diagramme represente les entites (desinformations) manipulees par les utilisateurs.Dans la phase de conception, il represente la structure objet d’undeveloppement oriente objet.

GL & UML

J-P Comet






14/141

Le diagramme d’objets

Bus Personne

Destination

:Personne

:Personne:Destination

Conducteur

Passager

*

1

1

*

:Bus Passager

Conducteur

But : illustrer les classes complexes en utilisant des exemples d’instances.Une instance est un exemple concret de contenu d’une classe.En illustrant une partie des classes avec des exemples, on comprend plusclairement les liens necessaires.Cette illustration permet d’apprendre le besoin par l’exemple en evitant dedemander aux interlocuteurs d’etre tout de suite au niveau plus abstrait querepresente le diagramme de classe

GL & UML

J-P Comet






15/141

1 Introduction






GL & UML

J-P Comet






16/141

Le diagramme global d’interaction

enregistrer commande client

Préparer livraison

enregistrer achats

mise à jour stock

recevoir produit

stock insuffisant

stock suffisant

commandes clienten attente

permet de donner unevue d’ensemble desinteractions du systeme.realise avec le memegraphisme que lediagramme d’activite.Chaque element dudiagramme peut ensuiteetre detaille a l’aide d’undiagramme de sequenceou d’un diagrammed’activite.

GL & UML

J-P Comet






17/141

Le diagramme d’activite

Utilisateur Système

produits restants

tous les produits traités

critèreaucun

critères saisis

commandes à livrerSaisie critères recherche

commandes à livrerSaisie critères recherche

commandes à livrerRecherche toutes

Recherche commandes à livreravec critère

Affichage listecommandes à livrer

Sélection d’une commandeà préparer

Recherche produitsà livrer (Cde)

Recherche stock (produit)

Affichage infos produits à livrer +stock

Enregistrement livraison

Validation livraison

Mise à jour stock

represente le deroulementdes actions, sans utiliserles objets.En phase d’analyse, il estutilise pour consolider lesspecifications d’un casd’utilisation.

GL & UML

J-P Comet






18/141

Le diagramme de sequences

:expédition

LOOP−Produits

Système :Produit:commande :client :ligneArticle :livraison

1: saisie critère recherche

commandes 2:Recherche Commandes

à livrer3: RechercheClient

de la commande

4: infos client5: infos commandes

à livrer

6: affichage liste

commandes à livrer

7: sélection commande8: recherche produits Commande

9: rechercherQtéStock

10: RetourInfosStockProduits11: retour produits commandés et stock

12: Affichage infos préparation Cde

13: Enregistrement livraison

14: Message livraison préparée

LOOP_Cde

permet de decrire les differents scenarios d’utilisation du systeme.montre quels sont les objets mis en jeu aux differents moments del’execution de la sequence.

GL & UML

J-P Comet






19/141

Le diagramme de communication (collaboration)

UnEmployé

Système

BDCommande Stock

UneCommande

12:notifStockMaj

1:askNoCmd

5:afficheCmd

3:getCmd() 4:retourne Cmd 1234

11:reduireStock()

8:getStockProduit()

9:retourneStockProduit

13:MsgStockMaj10:reserverProduit()

6:getRefProduit()

7:retourneRefProduit

2:retourne 1234

14:afficheMsgCmdTraitee

permet de mettre en evidence les echanges de messages entre objets.peut aider a completer, si besoin, les diagrammes de sequences et declasses.

GL & UML

J-P Comet






20/141

Le diagramme machines a etats (etats-transitions)

EnCommande

CdeClient

entry/AchatFournisseur

Reçu

Livré

réception

Expédié préparation

Préparé

En stock

entry / StockerProduit

Vendu

entry/RéserverProduit

RetourLivraison

decrire le cycle de vie des objets d’une classe.ici : objet de la classe produit

GL & UML

J-P Comet






21/141

Le diagramme de temps

destine a l’analyse/conception de systemesayant des contraintes temps-reel.

30 sec. 10 sec. 30 sec.

reprise carte

saisie opération

saisie code

attente carte

inactif

inactifattentecarte

saisiecode

30 sec. 10 sec.

opérationsaisie

informationsaffichage

inactif

30 sec.

reprisecarte

GL & UML

J-P Comet






22/141

1 Introduction






GL & UML

J-P Comet






23/141

Le diagramme de structure

Le diagramme de structure composite permet de decrire lastructure interne d’un objet complexe lors de son execution.

Voiture

moteur : Moteur rouesAvants : Roue[2]

rouesArrières : Roue[2]

actionne

GL & UML

J-P Comet






24/141

Le diagramme de composants

Le diagramme de composants decrit l’organisation du systeme du point devue des elements logiciels comme les modules (paquetages, fichiers sources,bibliotheques, executables), des donnees (fichiers, bases de donnees) ouencore d’elements de configuration (parametres, scripts, fichiers decommandes).Ce diagramme permet de mettre en evidence les dependances entre lescomposants (qui utilise quoi).

<<EXE>>

reception.exe

<<librairie>>

BonCde.exe

<<librairie>>

produit.dll

<<librairie>>

stock.dll

<<EXE>>

UI.exe

BC

GL & UML

J-P Comet






25/141

1 Introduction






GL & UML

J-P Comet






26/141

Le diagramme de deploiement

La vue de deploiement decrit les ressources materielles et la repartition desparties du logiciel sur ces elements.Le diagramme de deploiement correspond a la description del’environnement d’execution du systeme (materiel, reseau...) et de la facondont les composants y sont installes

<<interface utilisateur>>EntreeCdeUI.exe

<<table>>BD

<<EXE>>SGBD

<<EXE>>reception.exe

<<librairie>>stock.dll

<<librairie>>produit.dll

<<librairie>>BonCde.dll

<<librairie>>

BDinterface.dll

<<Processeur>>PC Client

<<Processeur>>ServeurBD

<<Processeur>>

ServeurTierMedian

<<Ethernet>>

1..* 1

1

1

<<Ethernet>>

GL & UML

J-P Comet






27/141

En resume

Diagrammes (diagram) BesoinsUtilisateurs

VueLogique

Vue desprocessus

Vue descomposants

Vue dudeploiement

paquetages (Package) Scas d’utilisation (use case) Dde classes (Class) Sd’objets (Object) Sd’etats-transitions D(State machine)d’activites (Activity) Dde sequence (Sequence) Dglobal d’interaction D(Interaction overview)de temps (Timing) Dde communication (Com-munication)

D

de structures composites S(Composite structure)composants (Component) Sdeploiement (Deployment) Sde profil (Profil) S

GL & UML

J-P Comet






27/141

En resumedécrit les classes d’une

application et leurs

relations statiques

représente les objets

et leurs liens à un

instant donné

UseCase Diagram

DiagramState Machine

Interaction Diagram

Sequence Diagram

DiagramCommunication

Timing Diagram

DiagramInteraction Overview possibles entre

les diagrammes

de séquences

enchainements

décrivent les services rendus

par le système du point de vue

de l’utilisateur

comportement

d’une opération

représenation du

comportement d’un

d’un automate à états

objet sous la forme

représetation du

représentation temporelle

des interactions entres objets

représentation

spaciale des

interactions

entre objets

donnée au

cours du temps

variations d’une

Class Diagram

Object Diagram

Package Diagram

Model Diagram

DiagramComposite Structure

Component Diagram

Manifestation Diagram

Deployment Diagram

DiagramNetwork Architecture

Profile Diagram

représente des

conteneurs logiques

regroupant

des éléments

vue simplifiée des

relations entre

composants d’une classe

représente les

composants d’un point

de vue physique

matériel (ordinateurs,

périphériques)

modélise l’aspect

UML 2.4 Diagram

Structure Diagram Behavior Diagram

vue dynamique

Activity Diagram

vue statique

GL & UML

J-P Comet






27/141

En resume

Diagramme de cas d’utilisation

Diagramme de séquences

Diagramme d’activités

FONCTIONNEL

Diagrammes de composants

Diagrammes de déploiement

Diagrammes d’objets

Diagramme de classes

STATIQUE

Diagrammes d’états−transitions

Diagrammes de séquences

Diagrammes de collaborations

Diagrammes d’activités

DYNAMIQUE

GL & UML

J-P Comet






27/141

En resume

Objects

Diagrams

Class

Diagrams

Sequence

Diagrams

Collaboration

Diagrams Statechart

Diagrams

Activity

Diagrams

Deployment

Diagrams

Use Case

DiagramsDiagrams

Component

Utilisateur

Implémentation

EnvironnementComportement

Structure

GL & UML

J-P Comet






28/141

1 Introduction2 Un panorama d’UML avec ses 14 diagrammes

(1) Utilisateurs(2) Aspects fonctionnels - vue logique(3) Aspects fonctionnels - vue des processus(4) Architecture - vue des composants(5) Architecture - vue du deploiement

3 Principes des methodes Orientees ObjetNotion d’objets informatiquesNotion de ClassesConcepts importants en OO

4 Diagrammes d’UtilisationLes acteursRelations entre CUScenariosCas d’etude

5 Diagrammes d’ObjetsNotations communes a tous les diagrammesDiagramme d’objetsCommunication entre objetsExercice

6 Diagrammes de ClassesRepresentationAssociationsProprietes et contraintesGeneralisation/SpecialisationInterface

GL & UML

J-P Comet






30/141

Notion d’objet informatique

Peut correspondre a une entite «concrete» (animal,vehicule, ...) ou «abstraite», «conceptuelle» (compteutilisateur, unite d’enseignement, ...)Regrouper dans un composant

des caracteristiques qui concernent une entite informatiquestructure de donneesensemble d’attributsvariables avec nom, type, valeur

les operations liees a cette entiteensemble de fonctions appelees methodesnom, valeur de retour, parametres

GL & UML

J-P Comet






31/141

Qu’est-ce qu’un objet

Objet = Etat + Comportement + Identité

Etat d’un objetEnsemble des valeurs des attributs de l’objet a un instantdonne

L’etat d’un objet evolue au cours du tempsLes valeurs sont egalement des objets (→ liens entreobjets)

Ma voiture

Marque : "Fiat"

Couleur : bleu

Masse : 943kg

Volume essence : 31 litres

Ma voiture

Marque : "Fiat"

Couleur : bleu

Masse : 943kg

Volume essence : 32 litres

GL & UML

J-P Comet






32/141



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






33/141



Identite d’un objetExistence propre de l’objet

Ce qui identifie l’objet de maniere non-ambigueIndependante de l’etat → 2 objets differents peuvent avoir lememe etatAttribuee implicitement a la creation de l’objet

Ma voiture

Marque : "Fiat"Couleur : bleuMasse : 943kgVolume essence : 32 litres

Une−de−plus

Marque : "Fiat"Couleur : rougeMasse : 943kgVolume essence : 32 litres

Encore−une

Marque : "Peugeot"Couleur : rougeMasse : 867kgVolume essence : 12 litres

Sa voiture

Marque : "Fiat"Couleur : rougeMasse : 943kgVolume essence : 56 litres

ref15 ref56

ref3ref23

GL & UML

J-P Comet






34/141

Liens entre objets

Pour envoyer un message a un objet, il faut le «connaıtre»L’objet Le conducteur connaıt l’objet Ma voitureConnaıtre un objet revient a avoir une reference qui luicorrespondAttributs, variables, parametres de methodes, ...

Ma voiture

Marque : "Fiat"Couleur : bleuMasse : 943kgVolume essence : 32 litresConducteur : ref67

Encore−une

Marque : "Peugeot"Couleur : rougeMasse : 867kgVolume essence : 12 litres

Le conducteur

Sexe : MCouleur_yeux : bleuAge : 45Voitures : (ref15, ref3)

ref3ref15 ref67

GL & UML

J-P Comet






35/141

Les objets : en bref

Coherence interne des objetsdonnees + traitementsFaible couplage entre l’objet et l’environnementenvoi de messages entre objets qui se connaissentInsertion dans un scenario de communication par envoi demessages

objets clients : a l’origine d’une interactionobjets serveurs : repondent a la sollicitationen general : client et serveur

GL & UML

J-P Comet






35/141

Les objets : en bref

Coherence interne des objetsdonnees + traitementsFaible couplage entre l’objet et l’environnementenvoi de messages entre objets qui se connaissentInsertion dans un scenario de communication par envoi demessages

objets clients : a l’origine d’une interactionobjets serveurs : repondent a la sollicitationen general : client et serveur

Que nous manque-t-il ?Decrire abstraitement de la meme maniere des objets ayant

memes structures de donnees (attributs)meme comportement (methodes)

GL & UML

J-P Comet






36/141

1 Introduction

2 Un panorama d’UML avec ses 14 diagrammes





GL & UML

J-P Comet






37/141

Les classes

Regroupement d’objets ayant le meme comportementAbstraction decrivant les proprietes communes des objetsqui en sont des instancesUne classe peut decrire une infinite d’instancesUn objet sait toujours a quelle classe il appartient

Marque : StringCouleur : [bleu,rouge,...]Masse : 943kg

Démarrer()

VoitureTa 205

Marque : "Peugeot"Couleur : rouge

Démarrer()

Ma R12

Marque : "Renault"Couleur : bleu

Démarrer()

une voiture

Marque : "..."Couleur : rouge

Démarrer()

une autre voiture

Marque : "..."Couleur : rouge

Démarrer()

Instanciations

UML : nom de la classe

GL & UML

J-P Comet






38/141

Les classes : implementation Java

Student.java

...public class Student {// Attributsprivate int number ;private String surname ;...// Methodespublic Student () {

number = 0 ;surname = "STUDENT" ;

}public void setNumber (int n) {

number = n ;}public int getNumber (){

return number ;}...} ;

Mode d’acces (public, private,protected), egalement appelevisibilite, specifie avant chaqueattributs ou methodes (cf.encapsulation)Definition des methodes (ecrituredu corps des fonctions) dans ladefinition de la classe, dans ununique fichier .javaObligatoirement un source .javapar classe

GL & UML

J-P Comet






39/141

Les classes : objet courant this

Acces a l’objet courant au sein d’une methode...public Student () {this . number = 0 ;this . surname = "STUDENT" ;}...

Peut etre omis la plupart du tempsUtile pour lever l’ambiguıte, lorsqu’un parametre porte lememe nom qu’un attribut

GL & UML

J-P Comet






40/141

Les classes : Instanciation et appel de methodes

Une variable de type Student allouee = une instance de laclasse StudentJava ne supporte que l’allocation dynamique de memoire(allocation dans le TAS).

Student st1 = new Student () ; // Creation dynamiquement// dans le TAS)

st1.setNumber (20121080) ;

GL & UML

J-P Comet






41/141

Dans un programme OO

On definit des classesleurs attributs, et visibiliteleurs methodes, et visibiliteOn instancie des objets a partir des classesOn lance/gere la collaborationenvoi de messages a des objetsExecution du programme : des objets qui s’envoient des messages quichangent d’etat

Objet = etat + comportement + identiteAttributsMethodes(reference)

ClasseAbstractionDefinit une infinite d’objets instances

GL & UML

J-P Comet






42/141

1 Introduction






GL & UML

J-P Comet






43/141

Les Concepts importants de la POO

1 Encapsulation2 Heritage3 Polymorphisme

GL & UML

J-P Comet






44/141

Encapsulation

Concept fondamental : protection de l’information contenuedans un objet

1 Garantit l’integrite de l’objet (exemple : evite lesaffectations par erreur, = au lieu de == !)

2 Garantit la coherence eventuelle entre plusieurs attributsinter-dependants (exemple : un tableau dynamique et sataille)

3 Masque en partie le fonctionnement interne d’une classe :respecte la notion de Type Abstrait de Donnees (facilite laprise en main du code dans un premier temps)

GL & UML

J-P Comet






45/141

Visibilite

Notion de visibiliteL’acces aux membres de la classe est different selon quel’on se trouve a l’interieur ou a l’exterieur de la classeA l’interieur de la classe : tout est permisA l exterieur de la classe : le programmeur ne «voit» quece que la classe «veut bien lui montrer»3 niveaux de «visibilite» pour les membres (attributs etmethodes) :- public : accessibles a tous- protected : accessibles seulement aux classes derivees

(voir heritage)- private : accessibles seulement au sein de la classeelle-meme

GL & UML

J-P Comet






46/141

Visibilite

Student.javaclass Student{ // Attributs

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

// Methodespublic :

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

} ;

StudentPair.javapublic class StudentPair {

private Student st1 , st2 ;...public String getSurnames ( ){

String s ;s = st1 . surname + " " +

st2 . surname ;}// ???

} ;

GL & UML

J-P Comet






47/141

Encapsulation : Accesseurs et mutateurs

AccesseursMethodes get...() : lecture d’un attributObjet non modifieRetour = une copie (valeur) de l’attribut

MutateursMethodes set...() : ecriture d’un attribut (eteventuellement, d’attributs dependants)Objet modifieType de retour = void ou un type indiquant un statut(modification effectuee ou non, ...)

Si possible, un couple accesseur/mutateur par attribut

GL & UML

J-P Comet






48/141

Encapsulation : Accesseurs et mutateurs

Student.java

public class Student {...private String surname ;...public String getSurname () {return surname ;

}public void setSurname (String s) {surname = new String (s) ;

}...

} ;

GL & UML

J-P Comet






49/141

Membre statique

Un membre statique est partage par toutes les instances de la classe Utilepour implementer une propriete (variable ou constante) commune a toutesles entites d’une meme classe :attributs / methodes de classeSimilaire a une variable ou fonction globale, mais interne a une classeAcces possible avec ou sans instance de la classeExemple : tout etudiant doit obtenir 180 credits pour valider une licence

Student.javapublic class Student {

...public static int credits = 180;...

} ;...

StudentPair.java...Student st1 = new Student () ;Student st2 = new Student () ;System.out.println (Student.credits) ; // 180System.out.println (st1.credits) ; // 180System.out.println (st2.credits) ; // 180Student.credits= 100;...

GL & UML

J-P Comet






50/141

Heritage

Concept fondamental : transmission des caracteristiques d’uneclasse vers une sous-classe en faisant deriver une nouvelle classed’une classe existante

Mise en place d’une hierarchie de classes (specialisation,generalisation)Une sous-classe herite des attributs et des methodes de sasuper-classeUne sous-classe peut ajouter/adapter des caracteristiques(attributs et methodes)

Evite la duplication et encourage la reutilisation

GL & UML

J-P Comet






51/141

Heritage simple : implementation

Conserve la visibiliteUn membre prive sera inaccessible meme dans les classesderiveesEn Java, par defaut, toute classe herite de Object

A.javapublic class A {

private int i ;protected int j ;public int k ;public A() {

i = 0;j = 0;k = 0;

}};

B.javapublic class B extends A {

public B() {i = 0 ; // ? ? ?j = 0 ; // ? ? ?k = 0 ; // ? ? ?

}};

Autre.java

public class Autre {private A a ;private B b ; // a et b alloues

// dans le constructeur...public void setAllToOne () {

a.i = 1 ; // ???a.j = 1 ; // ???a.k = 1 ; // ???b.i = 1 ; // ???b.j = 1 ; // ???b.k = 1 ; // ???

}};

GL & UML

J-P Comet






52/141

Polymorphisme

Concept fondamental : une meme operation peuts’appliquer a des objets de classes differentes et avoir uncomportement adapte a ces objetsAugmente la genericite et la qualite du code2 types de polymorphisme :

polymorphisme de traitement (ad-doc, overloading ) :mecanisme de surcharge des methodespolymorphisme de donnees

polymorphisme d’heritage (redefinition, sous-typage,masquage, inclusion, specialisation ... overriding ) : unmeme code peut etre applique a des donnees de typesdifferents liees entre elles par une relation d’heritagepolymorphisme parametrique (genericite, template) : unmeme code peut etre applique a n’importe quel type

GL & UML

J-P Comet






53/141

Polymorphisme de traitement : surcharge de methodes

Definir deux methodes ayant le meme nom, mais pas lameme signature (type et/ou nombre arguments differents)Le compilateur choisit la methode a utiliser en fonction dutype des parametres

private static int addition ( int x , int y) {System.out.println ( "additionne des int" ) ;return x + y ;

}private static float addition ( float x , float y) {

System.out.println ( "additionne des float" ) ;return x + y ;

}

GL & UML

J-P Comet






54/141

Polymorphisme d’heritage : redefinition de methodes

Possibilite de definir le comportement d’une methodeselon le type d’objet l’invoquantMethode redefinie donne une nouvelle implementation aune methode heritee sans changer sa signatureUne methode redefinie peut etre completement differentede la methode de base, ou bien reutiliser celle-ci eneffectuant des operations supplementaires (super en Java)

Point.java

public class Point {private int x , y ; //Attributs...public Point () { ... } ;public void affiche () {

System.out.println ( x+" , "+y);}

}

PointCouleur.java

public class PointCouleur extends Point {private int couleur ; // Attributs supplementaires...@Overridepublic void affiche () {

super.affiche () ;System.out.println("Couleur:"+ this.couleur);

}}

GL & UML

J-P Comet






55/141

Polymorphisme d’heritage : methode virtuelle

Methode virtuelle est destinee a etre redefinie dans uneclasse deriveeLe type d’instance (classe fille ou mere) determine lamethode reelle a appeler lors de l’execution (resolutiondynamique de liens)

Point p ;if (...)p = new PointCouleur () ;elsep = new Point () ;p.affiche () ;

En Java, les methodes sont virtuelles par defaut. p.affiche()fait appel a la methode de la classe reellement instanciee avecnew meme si p a ete declare de type Point.

GL & UML

J-P Comet






56/141

Polymorphisme d’heritage : meth. virt. pure, classe abstraite

Une methode virtuelle pure ou abstraite est declaree sans etre definie, et estdonc destinee a etre obligatoirement (re)definie dans une classe derivee(abstract en Java)

Une classe est dite abstraite si elle contient au moins une methode virtuellepure (abstract en Java)

Sert a definir des concepts incomplets qui seront completes dans lessous-classes.Ne peut pas etre instanciee, et est donc destinee a etre derivee.En java, une classe peut etre declaree abstraite sans contenir demethode abstraite

public abstract class Point () {private int x , y ;...public POINT () {...} ;public abstract void affiche();

}

GL & UML

J-P Comet






57/141

Interface

Heritage multiple impossible en Java : utilisationd’interfacesUne interface est un prototype de classe. Elle definit lasignature des methodes qui doivent etre implementeesdans les classes construites a partir de ce prototype.Une interface est une “classe” purement abstraite donttoutes les methodes sont abstraites et publiques.Une classe peut implementer plusieurs interfaces

Terrestre.javapublic interface Terrestre {

...public void move () ;

} ;

Aquatique.javapublic interface Aquatique {

...public void swim () ;

}

Amphibie.javapublic class Amphibie implements Terrestre , Aquatique {

// Amphibian doit definir les methodes move () et swim ( )public void move () { ... }public void swim () { ... }

}

GL & UML

J-P Comet






58/141

En resume

OO =

modularite+

encapsulation+

heritage+

polymorphisme

GL & UML

J-P Comet






59/141

Les Diagrammes d’Utilisation

Decrivent les services rendus par le systeme du point devue de l’utilisateurTechnique pour capturer les exigences fonctionnelles d’unsysteme

Determiner ses limitesDeterminer le comportement du systeme : ce que doit fairele systeme sans specifier comment il le faitComprendre l’attente des utilisateurs et les experts dudomaine

Instruments de validation et de tests du systeme

GL & UML

J-P Comet






60/141

Les Diagrammes d’Utilisation

Un diagramme de cas d’utilisation definit :le systemeles acteurs qui interagissent avec le systemeles cas d’utilisationsles relations entre acteurs et cas d’utilisations

GL & UML

J-P Comet






61/141






GL & UML

J-P Comet






62/141

Les acteurs

Un acteur represente un role joue par une entite exterieureau systeme (humain ou autre systeme) et qui interagitdirectement avec le systeme etudie

Permet de determiner les limites du systemeUn utilisateur peut etre represente par plusieurs acteursPlusieurs utilisateurs peuvent etre representes par le memeacteur

Categories d’acteurs :acteurs principaux : utilisent les fonctions principales dusysteme, un par CUacteurs secondaires : taches administratives, maintenancemateriel externe : dispositif materiel qui doivent etreutilises (peripheriques)autres systemes avec lesquels le systeme doit interagir

GL & UML

J-P Comet






63/141

Les acteurs

Relations entre acteurs : generalisation (heritage)

GL & UML

J-P Comet






64/141

Cas d’utilisation

Un cas d’utilisation represente un service complet attendudu systemeUn cas d’utilisation represente une suite d’interactionsentre un acteur et le systeme qui produisent un resultatobservable interessant pour un acteur particulierChaque cas d’utilisation correspond a une fonction metierdu systeme, selon le point de vue d’un de ses acteursUn cas d’utilisation a un debut et une fin clairementidentifiesUn cas d’utilisation est decrit par une forme verbale

GL & UML

J-P Comet






65/141

Ex. de cas d’utilisation : distributeur de boissons

GL & UML

J-P Comet






66/141






GL & UML

J-P Comet






67/141

Relations entre cas d’utilisation

Inclusion : precise qu’un cas d’utilisation contient le comportement definidans un autre cas d’utilisation.Mise en commun des comportements communs a plusieurs CU(decomposer, definir des comportements partageables entre plusieurs CU,factorisation des services rendus)

Extension : precise qu’un CU (source) peut dans certains cas s’ajouter aucomportement d’un autre CU (destination)

Extension soumise a une condition d’extensionComportement ajoute insere au niveau d’un point d’extension definidans le CU destination

GL & UML

J-P Comet






68/141

Relations entre cas d’utilisation

Generalisation : heritage du comportement de base

GL & UML

J-P Comet






69/141

Relations entre cas d’utilisation : exercice

1 Une agence de voyages organise des voyages ou l’hebergementse fait en hotel. Le client doit disposer d’un taxi quand il arrivea la gare pour se rendre a l’hotel. Completer de diagramme deCU suivant.

2 Certains clients demandent a l’agent de voyages d’etablir unefacture detaillee. Cela donne lieu a un nouveau cas d’utilisationappele « Etablir une facture detaillee ». Comment mettre ce casen relation avec les cas existants ?

3 Le voyage se fait soit par avion, soit par train. Commentmodeliser cela ?

GL & UML

J-P Comet






71/141






GL & UML

J-P Comet






72/141

Scenarios d’un cas d’utilisation

La description d’un CU se fait par des scenarios quidefinissent la suite logique des interactions qui constituentce CUTous les scenarios d’un CU sont issus du meme acteur etont le meme objectifUn CU contient en general un scenario nominal etplusieurs scenarios alternatifs (qui se terminent de faconnormale) ou d’erreur (qui se terminent en echec).

GL & UML

J-P Comet






73/141

Modelisation fonctionnelle

Identification des acteursIdentification des cas d’utilisationDiagrammes de cas d’utilisationDescription textuelle des cas d’utilisation :

Identification (titre du cas, acteurs concernes, responsable,date, etc.)PreconditionsScenario nominal : suite d’etapes avec objectifs de l’acteurbien identifies et menes a bienEnchainements alternatifsEnchainements d’erreursPostconditions

Description de ces scenarios par des diagrammes desequence (systeme), d’activites.

GL & UML

J-P Comet






74/141






GL & UML

J-P Comet






75/141

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

Retrait d’argent au distributeur automatique de billets (DAB)de la banque pour les porteurs d’une carte bancaire ;Consultation de solde de compte et retrait d’argent audistributeur automatique de billets (DAB) de la banque pour lesporteurs d’une carte bancaire ;Les clients porteurs d’une carte bancaire peuvent faire un depoten numeraire ou en cheques et consulter leurs comptes surinternet.Un client qui effectue un virement peut demander a verifier lesolde de son compte. Cette demande est autorisee si le solde estsuperieur a 15 euros.Toute transaction est securisee et necessite par consequent uneauthentification.

Proposer un diagramme de CU.

GL & UML

J-P Comet






76/141

Identification des acteurs

Quelles sont les entites externes qui interagissent directementavec le DAB ?

Porteur de carte bancaireClient de la banqueCyber-client de la banqueSI banque

GL & UML

J-P Comet






77/141

Diagramme des cas d’utilisation

GL & UML

J-P Comet






78/141

Description textuelle du CU : Retirer de l’argent sur DAB

IdentificationTitre : retirer de l’argent sur DABResume : ce cas d’utilisation permet a un Porteur de cartebancaire de retirer de l’argent liquide a un DAB.Acteur principal : porteur de carte bancaireActeur secondiare : SI banqueDate : 28-09-2020Responsable : ...

GL & UML

J-P Comet






79/141

Description textuelle du CU : Retirer de l’argent sur DAB

PreconditionsLe DAB contient des billetsAucune carte ne se trouve deja coincee dans le lecteurLa connexion avec le SI banque est operationnelle

PostconditionsLa DAB contient moins de billets qu’au debut du casd’utilisationUne transaction de retrait a ete enregistree par le DABavec toutes les informations pertinentes (montant, numerode carte, date, etc.).Les details de la transaction doivent etre enregistres aussibien en cas de succes que d’echec.

GL & UML

J-P Comet






80/141

Description du scenario nominal

1. Le porteur de CB introduit sa cartedans le lecteur du DAB

2. Le DAB verifie que la carte est bienune CB.3. Le DAB demande au porteur de CBde saisir son code d’identification.

4. Le porteur de CB saisit son code.

5. Le DAB verifie le code.6. Le DAB demande une autorisa-tion au SI banque.

7. Le SI banque donne son accord et in-dique le solde hebdomadaire.

8. Le DAB demande au porteur de CBde saisir le montant desire du retrait.

9. Le porteur de CB saisit le montant.10. Le DAB controle le montantpar rapport au solde hebdomadaire.11. Le DAB demande au porteur de cartes’il veut un ticket.

12. Le porteur de CB veut un ticket. 13. Le DAB ejecte la carte.14. Le porteur CB reprend sa carte. 15. Le DAB delivre ticket/billets.16. Le porteur CB prend son ticket et sesbillets.

GL & UML

J-P Comet






81/141

Description du scenario nominal

1. Le porteur de CB introduit sa cartedans le lecteur du DAB

2. Appel du cas « s’authentifier »3. Le DAB demande une autorisation auSI gestion CB

4. Le SI gestion CB donne son accord etindique le solde hebdomadaire.

5. Le DAB demande au porteur de CBde saisir le montant desire du retrait.

6. Le porteur de CB saisit le montant.7. Le DAB controle le montantpar rapport au solde hebdomadaire.8. Le DAB demande au porteur de cartes’il veut un ticket.

9. Le porteur de CB veut un ticket. 10. Le DAB ejecte la carte.11. Le porteur CB reprend sa carte. 12. Le DAB delivre ticket/billets.13. Le porteur CB prend son ticket et sesbillets.

GL & UML

J-P Comet






82/141

Description des scenarii alternatifs

A1 : code d’identification provisoirement erroneDemarre au point 5 : Le DAB indique au porteur de CB que le code esterrone, pour la premiere ou deuxieme fois, puis enregistre l’echec sur lacarte. Le scenario reprend au point 3.A2 : montant demande superieur au solde hebdomadaireDemarre au point 10 : Le DAB indique au porteur de carte que le montantdemande est superieur au solde hebdomadaire. Le scenario nominal reprendau point 8.A3 : ticket refuseDemarre au point 11 : ...

GL & UML

J-P Comet






83/141

Enchainements d’erreurs

E1 : carte non-valideDemarre au point 2 : Le DAB indique au porteur de CB que sa carte n’estpas valide (illisible, perimee, etc.), la confisque. Le CU se termine en echec.E2 : code d’identification definitivement erroneDemarre au point 5 : Le DAB indique au porteur de CB que le code esterrone, pour la troisieme fois. Le DAB confisque la carte. Le SI est informe ;le cas d’utilisation se termine en echec.E3 : retrait non autorise Demarre au point 6 : Le SI interdit tout retrait. LeDAB ejecte la carte ; le CU se termine en echec.E4 : carte non reprise ...E5 : billets non pris ...E6 : annulation de la transactionDemarre entre points 4 et 12 : ...

GL & UML

J-P Comet






84/141




GL & UML

J-P Comet






85/141

Notations communes a tous les diagrammes

ClasseurUn classeur est un element de modele qui est dote d’une identite, possede descaracteristiques structurelles (attributs, participation a des relations) etcomportementales (operations).

Cas d’utilisation

Class

Node Component

Paquetage (package)

Un paquetage est un regroupementd’elements de modele ou de diagrammes.

Class A

Class BActor

Cas d’utilisation

PackageModélisation des besoins

GL & UML

J-P Comet






86/141

Notations communes

StereotypesAnnotation s’appliquant sur un element de modeleUtilisation particuliere d’elements de modelisation avec interpretation(semantique) particuliereModification de la signification d’un elementNotation : « nomDuStereotype » avant le nom de l’element auquel ils’applique ou icone associeePredefinis : «actor», «includes», «use case», «interface», «include» ...«class» stereotype par defaut d’un classeur

Cas d’utilisation 2

Cas d’utilisation <<include>>

<<actor>>

Acteur

<<use case>>

Cas d’utilisation

<<Classe>>

GL & UML

J-P Comet






87/141

Notations communes

CommentairesInformation textuelle (explication utile, observations, renvoi versdocument), pas de contenu semantique

Notation :

Relations de dependanceModification de la cible peut impliquer une modification de la sourceLa source «depend» de la cibleNotation :

[source] ------> [cible]

IHM Métier

<< le paquetage IHM est dépendant du paquetage Métier>>

Toute modif dans paquetage metier peut avoir des consequences sur paquetage IHM. Toute modifdans paquetage IHM n’a au vu de cette dependance pas de consequence sur paquetage metier.

Nombreux stereotypes predefinis : «extend», «include», ...

GL & UML

J-P Comet






88/141

Contraintes

Relation entre elements de modelisationDefinition de proprietes devant etre verifiees pour garantir la validite dusysteme modeliseNotation : {contrainte}3 types de contraintes :

Contraintes predefinies : disjoint, overlapping, xor, ...Contraintes exprimees en langue naturelle (commentaires)Contraintes exprimees avec OCL (Object Constraint Language)

Stereotypes : «precondition», «postcondition»

< 10ms}{temps d’exécution

e−mail

coordonnées postales

lettrejournal

{incomplet}

Information

+ envoie()

{xor}

GL & UML

J-P Comet






89/141




GL & UML

J-P Comet






90/141

Les Diagrammes d’Objets

Classes, objets et instancesClasse = description formelle d’un ensemble d’objets ayant unesemantique/caracteristiques communesObjet ou instance de classe = concretisation d’une classe

Instance = toute concretisation d’un concept abstraitinstance de classe : objetinstance d’association entre classes : lien

classes

relations

instance de

instance de

relie relie

*

**

* objets

relations

diagramme de classes diagramme d’objets

extrait simplifié du méta−modèle d’UML

GL & UML

J-P Comet






91/141

Les Diagrammes d’Objets

ObjectifsRepresente les objets et leurs liens a un instant donneModelise les instances

Representation UML des objets

GL & UML

J-P Comet






92/141




GL & UML

J-P Comet






93/141

Communication entre Objets

Liens entre objetsComportement global d’une application reside sur lacommunication entre les objets qui la composent

→ reduction du couplage entre l’objet et l’environnement parenvoi de messages entre objets qui se connaissent

Unite de communication = messageLien entre objets

un objet connaıt un autre objet → avoir une reference quilui correspond (attributs, parametres de methodes, ...)peut envoyer un message a l’autre objet

GL & UML

J-P Comet






94/141

Representation UML des liens

Lien binaire : entre 2 objetsLien n-aire : entre n objetsPossibilite de decorer les liens (nom, nom des roles)La multiplicite se represente de maniere explicite par lesliens

Canada Ottawa

SNCFLucien

Lucien

:Salle

:Professeur

:Etudiant

p1:Personne :Personne p2:Personne

travailler pourtravailler pour

travailler pour

entrep:Entreprise

nom:string="PERTNE"

a−pour−capitale

employé

employeur

employé

UML : nom de lien

employeur

UML : noms de rôle

GL & UML

J-P Comet






95/141

Diagramme d’objets

Utilise pourPreciser une structure complexe trop difficile a comprendre avec undiagramme de classes→ Illustrer un modele de classes en montrant un exemple qui explique lemodele→ Preciser certains aspects du systeme→ Exprimer une exception en modelisant des cas particuliers ou desconnaissances non generalisablesPrendre une image (snapshot) d’un systeme a un moment donneDocumenter des cas de test, analyser des exemplesMontrer un contexte (collaborations sans messages)

Ne montre pasL’evolution du systeme dans le temps.

GL & UML

J-P Comet






97/141

Exercice

Modeliser ceci par un diagramme d’objets :Pierre, Paul, Jack, Marie et Anne sont des etudiants audepartement GB de polytechRobert et Suzie sont enseignants au departement GB.Robert enseigne la BioCh et le Bio Cell ; Suzie enseignel’anglais et les maths.Pierre et Paul suivent les cours de BioCh ; Pierre suit lecours de Bio Cell ; Marie et Anne suivent le coursd’anglais ; Anne suit le cours de maths.

GL & UML

J-P Comet






99/141




GL & UML

J-P Comet






100/141

Diagramme de Classes

ObjectifDecrire les classes d’une application et leurs relations statiques

Tres nombreuses utilisations, a differents niveauxDiagrammes fondamentaux : les plus connus, les plus utilisesPermettent de modeliser plusieurs niveaux :→ conceptuel (domaine, analyse) (Modele du domaine)→ implementation (code) (Modele de conception)

Qu’est ce qu’une classe d’objets ?Classe = regroupement d’objets similaires (appeles instance)

Toutes les instances d’une classe ont les memes attributs et operationsAbstraction : factorisation des caracteristiques communes a une categoried’objetsUne classe decrit une infinite d’instances

GL & UML

J-P Comet






101/141

Representation UML des classes

Rectangle compose de compartimentsCompartiment 1 : Nom de la classe (commence par une majuscule, en gras)Compartiment 2 : AttributsCompartiment 3 : OperationsPossibilite d’ajouter des compartiments (exceptions, ...)

Differents niveaux de detail possiblesPossibilite d’omettre attributs et/ou operations

Personne

− prénom : string− dateNaissance : Date− sexe : {’M’,’F’}

+ calculAge() : Int+ renvoyerNom() : String+ modifierNom(String)

NomClasse1

attr1 : Chaineattr2 : Entier..

op1(p1:Entier): Entierop2() : Chaine...

NomClasse2

attr1attr2

NomClasse3

Le nom de classe doit etre significatif, complet, et commencer par une majuscule. S’il est composé deplusieurs mots, la 1ère lettre de chaque mot doit etreune majuscule

(visibilité) éventuelsListe des attributs avec les modes d’accès

Liste des méthodes avec les modes d’accès(visibilité) éventuels.

GL & UML

J-P Comet






102/141

Nom de la classe

Tout est facultatif sauf le nom de la classe

<<stereotype>> NomPaquetage1:: ... ::NomPaquetageN::NomClasse{abstract} {auteur : valeur, etat : valeur, ...}

ClientBanque

java::util::vector

Personne<<interface>>

véhiculeanimal {abstract}

Math::Geometry::Surface

{auteur: Robert, état: validée}

GL & UML

J-P Comet






103/141

Attributs et Operations

Encapsulation et visibilite des attributs et des operationsMecanisme consistant a rassembler les donnees et les methodes au sein d’unestructure en cachant l’implementation de l’objet. 4 niveaux

Public : attributs accessibles et modifiables par n’importe quelle autreclasse, operations utilisables par n’importe quelle autre classe,Prive : attributs inaccessibles pour toute autre classe, operationsinutilisables pour toute autre classeProtege : attributs accessibles et modifiables uniquement par les classesderivees, operations utilisables uniquement par les classes derivees.Aucun caractere, ni mot-cle : propriete ou classe visible uniquement dans lepaquetage ou la classe est definie

Attributs / Operations de classeAttributs (ou operations) communs a l’ensemble des instances d’une classe(static)

GL & UML

J-P Comet






104/141

Representation UML des attributs

Format de description d’un attribut :

Attributs de classe (statiques) soulignesAttributs derives (calcules) precedes de “/”Enumeration : stereotype «enumeration»

GL & UML

J-P Comet






105/141

Representation UML des operations

Format de description d’une operation :

operations abstraites (non implementees) / operations de classe (statiques)Proprietes : abstract, query (l’operation n’altere pas l’etat de l’instanceconcernee), pre- et post-conditions, description du contenu (commentaires,OCL)Stereotypes d’operations : constructeur «create», destructeur «destroy»

GL & UML

J-P Comet






106/141




GL & UML

J-P Comet






107/141

Associations entre classesAbstraction des relations definies par les liens entre objets

il y a exactement un C2 associe a tout C3il y a au maximum un C3 associe a tout C2

GL & UML

J-P Comet






108/141

Associations entre classes : notions

Notion d’associationsRelation entre deux classes (binaire) ou plus (n-aire).Decrit les connexions structurelles entre les instances des classes associees2 facons de modeliser une association

Les associations sont utilisees pour materialiser les relations entre elementsqui font partie de la modelisation.Les attributs sont utilises pour modeliser des types de donnees depourvusd’identite.

GL & UML

J-P Comet






109/141

Associations entre classes : Nom, role et multiplicite

Nom : forme verbaleSens de lecture de l’association indique eventuellement par une flecheMultiplicite : nombre (ou intervalle de nombres) d’instance(s) quel’association peut impliquer.→ exactement un se note 1 ou 1..1→ plusieurs se note * ou 0..→ au moins un se note 1..→ de un a six se note 1..6Role : forme nominale decrivant le statut de la classe dans l’association.Peut contenir un mode d’acces.

GL & UML

J-P Comet






110/141

Associations entre classes : Nom, role et multiplicite

Exemple : une personne travaille pour une et une seule entreprise. L’entrepriseemploie au moins une personne. L’entreprise est l’employeur des personnes quitravaillent pour elle et une personne a un statut d’employe dans l’entreprise.

1..*

employé

Personne 1

employeur

Entreprisetravaille pour

Incidence sur l’implementation :La classe Personne a un attribut de nom employeur → Type =EntrepriseLa classe Entreprise a un attribut de nom employe → Type =collection de Personne

GL & UML

J-P Comet






111/141

Associations entre classes : Associations n-aires

Association entre au moins trois classesChaque instance de l’association est un tuple de valeurs provenant chacunede leurs classes respectivesExemple : un etudiant suit le cours d’un professeur responsable pendant unsemestre. Il peut suivre plusieurs cours d’un meme professeur responsablePour une paire (cours, etudiant), il n’existe qu’un professeur. Pour unepaire (etudiant, professeur), il existe plusieurs cours. Pour une paire (cours,professeur), il existe plusieurs etudiants

Cours Professeur

Etudiant

* 1

*

Inscription

responsable

inscrit

GL & UML

J-P Comet






112/141

exercice 1 : instanciation de diagrammes de classes

Proposer le plus petit diagramme d’objets respectant le diagrammede classes :

GL & UML

J-P Comet






114/141

Associations entre classes : Reflexivite, symetrie/asymetrie

Exemple : une personne peut etre parent d’autres personnes et enfant d’auplus deux personnes connues. Deux personnes peuvent etre amies (onconsidere que l’amitie est reciproque).Les associations de parente et d’amitie sont reflexives : elles associent laclasse Personne avec elle-memeLa relation de parente est asymetrique, donc orientee (si une instance A estparent d’une instance B, l’inverse ne peut pas etre possible simultanement)La relation d’amitie est symetrique (=non-orientee). Il est inutile despecifier des roles dans ce cas.

Une instance de la classe impliquee peut etre reliee a elle-meme ou ad’autres instances de cette meme classe.

GL & UML

J-P Comet






115/141

Associations entre classes : Navigabilite

Indique s’il est possible de traverser une associationSi un lien est naviguable d’un objet A vers un objet B, alors A aconnaissance de B et peut solliciter l’interface de BPar defaut : Navigabilite dans les deux sensExemple : un polygone est defini par au moins 3 points jouant le role desommets. Un point peut etre sommet de plusieurs polygones. Les sommetsdu polygone ne sont accessibles que par la classe et ses descendants. Onconsidere qu’il est inutile que les points aient un lien vers les polygonesdans lesquels ils sont sommets.

Polygone Point

* 3..*

a pour sommet #sommet

Navigation possible uniquement du polygone vers les points : un polygoneconnaıt les points qui lui servent de sommets, mais un point ne connaıt pasles polygones dans lesquels il est sommetIncidence sur l’implementation : la classe Polygone contiendra unecollection de Point. La classe Point ne contiendra aucun attribut detype Polygone.

GL & UML

J-P Comet






116/141

Associations particulieres : agregation

AgregationModeliser regroupement de parties dans un tout

Association non-symetriqueRelation de dominance et de subordinationUne classe fait partie d’une autre classeUne action sur une classe implique une action sur une autre classe

Une classe peut appartenir a plusieurs agregats

Annuaire Individu

1 0..*

Segment Point

1 2

Segment Point

1 2

Polygone

3..* 1

Personne Immeuble

1..* 0..*

Propriétaire

GL & UML

J-P Comet






117/141

Associations particulieres : composition

compositionAgregation forteContenance structurelle Creation/Copie/Destruction du composite →Creation/Copie/Destruction de ses composantsUn composant appartient a au plus un composite(mult. cote conteneur max 1)

GL & UML

J-P Comet






118/141

Composition, Agregation et Association

Quelques questions a se poser :assymetrie et lien de subordination entre instances des deux classes(→ agregation/composition)ou independance des objets (→ association) ?Propagation d’attributs ou d’operations du tout vers les parties ?→ agregation/compositionCreation et destruction des parties avec le tout ?→ composition

Remarques importantes :Dans le doute, toujours utiliser une association (c’est la moinscontrainte)Choix entre composition et agregation peut etre laisse a la phase deconception

GL & UML

J-P Comet






119/141

Exercice 2 : Identification des classes et relations

Une voiture est caracterisee par une marque, un modele et unemotorisation. La marque d’une voiture est forcement l’une des suivantes :Citroen, Fiat, Ford, Nissan, Peugeot, Renault, Toyota ou Volkswagen.Le moteur d’une voiture est caracterise par une designation et unepuissance.Une voiture possede 4 roues et le moteur actionne deux de ces roues.

1 Modeliser cette situation a l’aide d’un diagramme de classes.2 Proposer un diagramme d’objets compatible avec ce diagramme de classes

et comportant un seul objet Voiture.

GL & UML

J-P Comet






121/141




GL & UML

J-P Comet






122/141

Associations : proprietes et contraintes

Contraintes predefinies (Utilisation du langage OCL)Sur une extremite : relation d’ordre ordered, ...Entre 2 associations : inclusion subset, exclusion xor, ...

1 Les sommets dans un polygonesont ordonnes :

2 Une personne travaille dans unservice, et elle peut, en plus,gerer ce service. Plusieursemployes peuvent cogerer unservice.

3 Une personne (etudiant ouenseignant) est associee a unematiere, soit parce qu’ellel’enseigne, soit parce qu’elle lasuit (mais jamais les deuxsimultanement)

4 Un vehicule a des attributspropres (sa charge par ex.) etest d’une certaine categorie. Lacharge max autorisee pour unvehicule depend que de lacategorie, pas du vehicule lui-m.

PointPolygone

*

a pour sommet#sommet

3..*{ordered}

Servicetravaille dans1..* 1

{subset}1..* 1

gère

Personne

Matière1..*

1..*

suit

Personne enseigne

{xor}

0..*

0..*

Catégorie*Véhicule est de type 1

charge: Int {Véhicule.charge<Catégorie.chargeMax} chargeMax:Int

GL & UML

J-P Comet






123/141

Associations : proprietes et contraintes

Proprietes sur extremites d’associations{variable} : instance modifiable (par defaut){frozen} : instance non modifiable{addOnly} : instances ajoutables mais non retirables (si mult. >1)

{frozen}

2..*Véhicule Roue

La contrainte {frozen} precise que le nombre de roues d’un vehicule ne peut pasvarier.

GL & UML

J-P Comet






124/141

Exercice sur les proprietes et contraintes :

Modeliser avec un diagramme de classes les enonces suivants (il y a toujours aumoins un classe Personne) :

Un comite est compose d’au moins 2 personnes qui sont ses membres.L’unique president du comite est egalement un membre du comite.Un hotel a plusieurs clients et un ou plusieurs employes. Les employes del’hotel n’ont pas le droit de prendre une chambre dans ce meme hotel.Une personne est nee dans un pays et cela ne peut etre modifie. Unepersonne a visite un certain nombre de pays, dans un ordre donne, et lenombre de pays visites ne peut que croıtre. Une personne aimerait encorevisiter toute une liste de pays, et selon un ordre de preference.

GL & UML

J-P Comet






126/141

Classes-Associations

Une association peut etre raffinee et avoir ses propres proprietes, qui nesont disponibles dans aucune des classes qu’elle lie.Une association peut etre representee par une classe pour ajouter attributset operations a des associationsExemple : une personne a travaille dans des entreprises, a des periodesdonnees et avec un certain salaire.

Personne Entreprisetravaille dans1..* 1..*

employé employeur

Poste

salaire: RealdateDeb: DatedateFin: Date

GL & UML

J-P Comet






127/141

Classes-Associations

Une classe-association peut etre remplacee par une classe intermediaire quisert de pivot (on separe la relation initiale : attention au changement demultiplicite par rapport a la version avec classe-association)

Souvent lorsque relation de plusieurs a plusieurs : reduction des associationsn-aires

GL & UML

J-P Comet






128/141

Associations qualifiees

Parfois preferable de restreindre la portee de l’association a quelqueselements cibles (comme un ou plusieurs attributs) de la classe : qualificatifUn qualificatif permet de selectionner un sous-ensemble d’instances : objetsciblesUn qualificatif agit toujours sur une association dont la multiplicite estplusieurs (avant que l’association ne soit qualifiee) du cote cible.

Case

Echiquier1

64Case11

Classe qualifiee

qualificatif

Classe cible

Echiquierrangee : Rangeecolonne : Colonne

GL & UML

J-P Comet






129/141




GL & UML

J-P Comet






130/141

Generalisation/Specialisation

Deux interpretationsNiveau conceptuel- Relation transitive, non reflexive, et non symetrique- Un concept est plus general qu’un autre : hierarchie de classesNiveau implementation : Heritage- La sous-classe herite des attributs et methodes de sa super-classe- La sous-classe est une «sorte» de la super classe :

Toute instance de la sous-classe est instance de la super-classe- Ajout d’elements propres, redefinition

Individu

NomPrénomAge

Enseignant

SpécialitéAncienneté

SoldeCréation

Compte Bancaire

Taux d’intérêt

Compte épargne

Véhiculeabstrait

Voiture

Spéc

iali

sati

on

par

exte

nsi

on

Gén

éral

isat

ion

GL & UML

J-P Comet






131/141


ContraintesLes seules contraintes pre-definies en UML pour la generalisation sont :

{disjoint} (par defaut) = les sous-classes n’ont aucune instance encommun{overlapping} = les sous-classes peuvent avoir une ou plusieurs instancesen commun

VoitureVoiture amphibieBateau

Vehicule terrestrevehicule marin

Vehicule

Voiture amphibie Vehicule terrestrevehicule marin

Bateau

Vehicule

Voiture

overlapping

{overlapping} precise ici qu’il existe des vehicules amphibiesqui sont issus d’un croisement des sous-classes de vehicule.

GL & UML

J-P Comet






132/141


ContraintesLes seules contraintes pre-definies en UML pour la generalisation sont :

{complete} (liste exhaustive de classe) / {incomplete} (les sous-classesspecifiees ne couvrent pas la super-classe)

{disjoint,complete}

{disjoint,incomplete}

PersonnenomnumSecu

Avocat Vendeur EnseignantnbAffairesadressCabinet

anciennetenomDuStand

nbCoursspecialite

PermanentnumBureau

VacatairenbVacations

{incomplete} exprime l’idee que des instances de la classe Personne sont desavocats, des vendeurs, des enseignants ou d’autres personnes ...{complete} exprime l’idee qu’un enseignant ne peut etre autre chose qu’unpermanent ou vacataire.

GL & UML

J-P Comet






133/141




GL & UML

J-P Comet






134/141

Interface

Qu’est-ce qu’une interface ?Classe sans attributs dont toutes les operations sont abstraites (classe abstraitepure)

Liste de services, savoir faireNe peut etre instancieeDoit etre realisee (implementee) par des classes non abstraitesPeut heriter d’une autre interface

Stereotype <<realize>> facultatif

GL & UML

J-P Comet






135/141

Interface

Une classe peut aussi simplement dependre d’une interface (interface requise).

GL & UML

J-P Comet






136/141

Classes generiques/parametrables

Objectif : regrouper les comportements associes a la structure de la classeindependamment des objets qu’elle contient

Souvent utilisee pour les classes correspondant a des “collections”d’element(s) : tableau dynamique, liste (simplement chainee, doublementchainee, triee ou non, ...), table de hashage, ensemble, ...→ le parametre est alors le type d’objet contenuDisponible en C++ (patrons de classe = templates) et en Java (depuis laversion 1.5 classes generiques)

ListeChaineeTriee

+insererElement(elem : T)+enleverElement(elem : T)+vider()...

T

GL & UML

J-P Comet






137/141

Classes generiques/parametrables

Parametrisation d’une classe parametrable = instanciation des parametres(binding). Deux notations possibles.

ListeChaineeTriee


ListeChaineeTriee


ListeChaineeTrieeEntiers

ListeChaineeTrieeEntiers<T→Int>

«bind»T→ Entier

T

T

Differents parametres possibles (type specifie ou non (ex : T))

VecteurND-array : T[n]

+normeL2() : T+produitScalaire(v :VecteurND) : T

Point3D«bind»T→Realn→3

Un point ou vecteur de l’espace reel

T, n : Entier

GL & UML

J-P Comet






138/141

Exercices : associations entre classes

Modeliser les phrases suivantes par un diagramme de classes, notammentdeterminez la relation statique appropriee (generalisation, composition, agregationou association)

1 Un repertoire contient des fichiers.2 Une piece a des murs.3 A l’universite, un batiment d’enseignement dispose d’un certain nombre de

salles et de chaises. A un instant donne, une chaise est obligatoirement al’interieur d’une salle. Une chaise peut etre deplacee dans une autre salleselon les besoins.

4 Les modems et les claviers sont des peripheriques d’entree/sortie (il enexiste d’autres).

5 Une transaction boursiere est un achat ou une vente.6 Un compte bancaire peut appartenir a une personne physique ou morale.7 Deux personnes peuvent etre mariees.8 Un pays possede plusieurs villes et une seule capitale.

GL & UML

J-P Comet






141/141

Exercices : Interfaces et heritage multiple

Les etudiants sont des personnes qui peuvent s’incrire et se desinscrire al’universite.Les enseignants, identifies par un numero, sont des personnes qui dispensent descours a l’universite. Un cours, caracterise par son intitule et ses credits, n’estdispense que par un seul enseignant.Les doctorants peuvent s’inscrire et se desinscrire a l’universite comme lesetudiants et dispenser des cours comme les enseignants.

Proposer une modelisation de cette situation en utilisant l’heritage multiple.Proposer une modelisation de cette situation en utilisant une interface pours’affranchir de l’heritage multiple.

Documents

Introduction a UML Jean-Paul Comet (projet Bioinfo Formelle ...GL & UML J-P Comet Introduction Les 14 Diag. (1) Utilisateurs (2) Fonctionnel-log. (3) Fonctionnel-proc. (4) Archi-comp