Vous êtes sur la page 1sur 82

Modélisation avec UML

Mod élisation avec UML 1 Mod élisation avec UML © Robert Ogor

Modélisation

avec UML

1

Mod élisation avec UML 1 Mod élisation avec UML © Robert Ogor

Modélisation avec UML

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 2 Vue g énérale du cours 1) Introduction au langage de

Modélisation

avec UML

2

Mod élisation avec UML 2 Vue g énérale du cours 1) Introduction au langage de mod

Vue générale du cours

1) Introduction au langage de modélisation UML

• points de vue et diagrammes

• cas d'utilisation, analyse, conception, implémentation 2) Le diagramme des cas d’utilisations

• acteur

• cas d'utilisation et scénario

3) Notion de classes et objets et leur diagramme

• introduction aux classes, aux objets

• notion de relation, de composition et d'héritage

• recherche d'un diagramme de classes à partir du cahier des charges

4) Modèle dynamique

• diagramme de séquences, de collaboration, d'état et d'activité

• réalisation des cas d'utilisation par les diagrammes de séquences

• réalisation des cas d'utilisation par les diagrammes de collaboration 5) Conception

• diagramme de déploiement et de composants 6) Le langage de contrainte OCL

© Robert Ogor
© Robert Ogor
Conception • diagramme de déploiement et de composants 6) Le langage de contrainte OCL © Robert

1

mai 2003

Modélisation avec UML

Mod élisation avec UML 3 1) Introduction au langage de mod élisation UML © Robert

Modélisation

avec UML

3

Mod élisation avec UML 3 1) Introduction au langage de mod élisation UML © Robert Ogor

1) Introduction au langage de modélisation UML

© Robert Ogor
© Robert Ogor
Modélisation avec UML 4 Unified Modeling language OMT-2 Booch’93 OOSE James Grady Booch Ivar Jacobson
Modélisation
avec UML
4
Unified Modeling language
OMT-2
Booch’93
OOSE
James
Grady Booch
Ivar Jacobson
Rumbaugh
OOPSLA 95
UML 0.8
Partenaires Divers
Task Force
WWW Juin96
UML 0.9
UML 1.2
Proposé à un standard OMG fin1997
UML 1.0
1998
UML 1.3
2001
UML 1.4
Standard OMG, ADTF fin1997
UML 1.1
2003
UML 1.5
2005
UML 2.0
© Robert Ogor
1998 UML 1.3 2001 UML 1.4 Standard OMG, ADTF fin1997 UML 1.1 2003 UML 1.5 2005

2

mai 2003

Modélisation avec UML

Mod élisation avec UML 5 Pourquoi mod éliser Un mod èle est une simplification de

Modélisation

avec UML

5

Mod élisation avec UML 5 Pourquoi mod éliser Un mod èle est une simplification de la

Pourquoi modéliser

Un modèle est une simplification de la réalité qui permet de mieux comprendre le système à développer.

Il permet

- De visualiser le système comme il est ou comme il devrait l'être.

- De valider le modèle vis à vis des clients

- De spécifier les structures de données et le comportement du système.

- De fournir un guide pour la construction du système.

- De documenter le système et les décisions prises.

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 6 Les principes de la mod élisation 1) Le mod èle

Modélisation

avec UML

6

Mod élisation avec UML 6 Les principes de la mod élisation 1) Le mod èle doit

Les principes de la modélisation

1) Le modèle doit être connecté au monde réel

2) Un modèle peut être exprimé avec différents niveaux de précision

3) Un simple modèle n'est pas suffisant, il y a plusieurs façons de voir un système.

plan de masse vue de face, de coté, … plan des niveaux plan électrique plan de plomberie plan des calculs de construction

© Robert Ogor
© Robert Ogor
plan des niveaux plan électrique plan de plomberie plan des calculs de construction © Robert Ogor

3

mai 2003

Modélisation avec UML

Mod élisation avec UML 7 Qu’apporte la mod élisation objet Plus grande ind épendance du

Modélisation

avec UML

7

Mod élisation avec UML 7 Qu’apporte la mod élisation objet Plus grande ind épendance du modèle

Qu’apporte la modélisation objet

Plus grande indépendance du modèle par rapport aux fonctionnalités demandées.

Des fonctionnalités peuvent être rajoutées ou modifiées, le modèle objet ne change pas.

Plus proche du monde réel.

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 8 Les objectifs d ’UML • Représenter des systèmes entiers •

Modélisation

avec UML

8

Mod élisation avec UML 8 Les objectifs d ’UML • Représenter des systèmes entiers • Etablir

Les objectifs d’UML

• Représenter des systèmes entiers

• Etablir un couplage explicite entre les concepts et les artefacts exécutables

• Prendre en compte les facteurs d’échelle

de modélisation utilisable à la fois

par les humains et les machines

• Créer un langage

Recherche d’un langage commun :

Utilisable par toutes les méthodes

Adapté à toutes les phases du développement

Compatible avec toutes les techniques de réalisation

© Robert Ogor
© Robert Ogor
les phases du développement Compatible avec toutes les techniques de réalisation © Robert Ogor 4 mai

4

mai 2003

Modélisation avec UML

Mod élisation avec UML 9 UML un langage UML n ’est pas une méthode UML

Modélisation

avec UML

9

Mod élisation avec UML 9 UML un langage UML n ’est pas une méthode UML est

UML un langage

UML n ’est pas une méthode

UML est un langage de modélisation objet

UML a été adopté par toutes les méthodes objet

UML est dans le domaine public, c’est une norme

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 10 UML un langage pour visualiser chaque symbole graphique a une

Modélisation

avec UML

10

Mod élisation avec UML 10 UML un langage pour visualiser chaque symbole graphique a une s

UML un langage pour

visualiser

chaque symbole graphique a une sémantique

spécifier

de manière précise et complète, sans ambiguïté,

construire

les classes, les relations SQL peuvent être générées automatiquement

documenter

les différents diagrammes, notes, contraintes, exigences seront présentés dans un document.

© Robert Ogor
© Robert Ogor
les différents diagrammes, notes, contraintes, exigences seront présentés dans un document. © Robert Ogor 5 mai

5

mai 2003

Modélisation avec UML

Mod élisation avec UML 11 UML et les domaines d’utilisation Syst èmes d'information des entreprises

Modélisation

avec UML

11

Mod élisation avec UML 11 UML et les domaines d’utilisation Syst èmes d'information des entreprises Les

UML et les domaines d’utilisation

Systèmes d'information des entreprises Les Banques et les services financiers Télécommunications Transport Défense et aérospatiale Scientifique Applications distribuées par le WEB

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 12 Les trois éléments de base en UML 1) les blocs

Modélisation

avec UML

12

Mod élisation avec UML 12 Les trois éléments de base en UML 1) les blocs de

Les trois éléments de base en UML

1) les blocs de base pour construire

les entités utilisées

la notion de relation les diagrammes

Entités structurelles Entités de comportement Entités de regroupement Entité d'annotation

Entités de regroupement Entité d'annotation 2) les r ègles à observer pour utiliser ces blocs de

2) les règles à observer pour utiliser ces blocs de base

règles sémantiques

règles de présentation

3) les mécanismes communs

spécification

présentation extension des modèles

© Robert Ogor
© Robert Ogor
3) les m écanismes communs sp écification présentation extension des modèles © Robert Ogor 6 mai

6

mai 2003

Modélisation avec UML

Mod élisation avec UML 13 Les entit és structurelles Chien C o m p a

Modélisation

avec UML

13

Mod élisation avec UML 13 Les entit és structurelles Chien C o m p a r

Les entités structurelles

Chien

C o m p a r a b l e

Comparable

race

age

 

couleur

Interface

aboyer()

mordre ()

obéir ()

Classe

Producteur suspend() run() Classe Active
Producteur
suspend()
run()
Classe Active

observateur() Classe Producteur suspend() run() Classe Active Collaboration Noyau Composant emprunte Cas d’utilisation

Collaboration

Noyau suspend() run() Classe Active observateur Collaboration Composant emprunte Cas d’utilisation Serveur N œud ©

Composant

emprunte Cas d’utilisation Serveur
emprunte
Cas d’utilisation
Serveur

Nœud

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 14 Les entit és de comportement appel Message emprunt é Etat

Modélisation

avec UML

14

Mod élisation avec UML 14 Les entit és de comportement appel Message emprunt é Etat Les

Les entités de comportement

appel

élisation avec UML 14 Les entit és de comportement appel Message emprunt é Etat Les entit

Message

emprunté

Etat

Les entités de groupement

Accès BD Paquetage
Accès BD
Paquetage
Le livre a été emprunté Note
Le livre a été
emprunté
Note

Les entités de notation

© Robert Ogor
© Robert Ogor
Accès BD Paquetage Le livre a été emprunté Note Les entit és de notation © Robert

7

mai 2003

Modélisation avec UML

Mod élisation avec UML 15 Les relations d épendance association héritage réalisation © Robert Ogor

Modélisation

avec UML

15

Mod élisation avec UML 15 Les relations d épendance association héritage réalisation © Robert Ogor

Les relations

Mod élisation avec UML 15 Les relations d épendance association héritage réalisation © Robert Ogor
Mod élisation avec UML 15 Les relations d épendance association héritage réalisation © Robert Ogor
Mod élisation avec UML 15 Les relations d épendance association héritage réalisation © Robert Ogor

dépendance

association

héritage

réalisation

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 16 St éréotypes et icônes associées <<contrôle>> Gestion Commande

Modélisation

avec UML

16

Mod élisation avec UML 16 St éréotypes et icônes associées <<contrôle>> Gestion Commande

Stéréotypes et icônes associées

<<contrôle>>

Gestion Commande

<<entité>> Stockage Commande

<<frontière>> Réception Commande

Commande <<frontière>> Réception Commande gestion Commande stockage Commande réception Commande ©

gestion Commande

<<frontière>> Réception Commande gestion Commande stockage Commande réception Commande © Robert Ogor

stockage Commande

<<frontière>> Réception Commande gestion Commande stockage Commande réception Commande © Robert Ogor

réception Commande

© Robert Ogor
© Robert Ogor
Réception Commande gestion Commande stockage Commande réception Commande © Robert Ogor 8 mai 2003

8

mai 2003

Modélisation avec UML

Modélisation avec UML 17 Les 9 diagrammes en UML Diagrammes Cas Classes Etats- Activité Déploiement
Modélisation
avec UML
17
Les 9 diagrammes en UML
Diagrammes
Cas
Classes
Etats-
Activité
Déploiement
d'utilisation
Transitions
Objets
Séquences
Collaboration
Composants
© Robert Ogor
Modélisation avec UML 18 5 façons de voir un système (4+1 vues de Kruchten) Aspect
Modélisation
avec UML
18
5 façons de voir un système
(4+1 vues de Kruchten)
Aspect dynamique :
Aspect statique :
Aspect statique :
classes et objets
paquetages
d'interaction
(séquences, collaboration),
d'états-transitions et d'activité
les paquetages
les méthodes
les threads
Vue implantation
Vue logique
Vue des cas
d'utilisation
Vue des processus
Vue de déploiement
Aspect fonctionnel :
Aspect parallélisme :
Aspect répartition :
Cas d'utilisations
threads
diagramme de
acteurs
processus
déploiement
classes
tâches
nœuds, modules
collaboration
interactions
© Robert Ogor
processus déploiement classes tâches nœuds, modules collaboration interactions © Robert Ogor 9 mai 2003

9

mai 2003

Modélisation avec UML

Mod élisation avec UML 19 Point de vue des cas d’utilisation Vue du syst ème

Modélisation

avec UML

19

Mod élisation avec UML 19 Point de vue des cas d’utilisation Vue du syst ème par

Point de vue des cas d’utilisation

Vue du système par ses utilisateurs finaux

Regroupe le comportement du système selon Priorité: critique, important, accessoire Risques à circonscrire Options disponibles Couverture de l’architecture Autres objectifs tactiques et contraintes

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 20 Point de vue logique D écomposition orientée-objet Décomposition en objets

Modélisation

avec UML

20

Mod élisation avec UML 20 Point de vue logique D écomposition orientée-objet Décomposition en objets et

Point de vue logique

Décomposition orientée-objet

Décomposition en objets et classes

Regroupement en paquetages.

Connexions par héritage, association, etc.

Accent sur l’abstraction, l’encapsulation, l’uniformité.

Réalisation des scénarios des cas d'utilisation.

© Robert Ogor
© Robert Ogor
l’uniformité. Réalisation des scénarios des cas d'utilisation. © Robert Ogor 10 mai 2003

10

mai 2003

Modélisation avec UML

Mod élisation avec UML 21 Point de vue processus D écomposition en tâches et processus

Modélisation

avec UML

21

Mod élisation avec UML 21 Point de vue processus D écomposition en tâches et processus Regroupement

Point de vue processus

Décomposition en tâches et processus Regroupement des groupes de processus Communication Information sur les caractéristiques suivantes Disponibilité, fiabilité Intégrité, performance Contrôle

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 22 Point de vue implantation D écomposition en modules et niveaux

Modélisation

avec UML

22

Mod élisation avec UML 22 Point de vue implantation D écomposition en modules et niveaux Regroupement

Point de vue implantation

Décomposition en modules et niveaux

Regroupement de modules en paquetages

Organisation des sous-systèmes en niveaux pour :

Réduire le couplage et la visibilité

Augmenter la robustesse

Information sur les caractéristiques suivantes :

Facilité de développement

Potentiel de réutilisation

Gestion de configuration

© Robert Ogor
© Robert Ogor
Facilité de développement Potentiel de réutilisation Gestion de configuration © Robert Ogor 11 mai 2003

11

mai 2003

Modélisation avec UML

Mod élisation avec UML 23 Point de vue d éploiement D écomposition en nœuds d’exécution

Modélisation

avec UML

23

Mod élisation avec UML 23 Point de vue d éploiement D écomposition en nœuds d’exécution Rôle

Point de vue déploiement

Décomposition en nœuds d’exécution Rôle d’un nœud Inter-connectivité, topologie Information sur les caractéristiques suivantes :

Performance, disponibilité Installation, maintenance

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 24 Les trois composantes d’une mod élisation Modèle Fonctionnel Que fait

Modélisation

avec UML

24

Mod élisation avec UML 24 Les trois composantes d’une mod élisation Modèle Fonctionnel Que fait le

Les trois composantes d’une modélisation

Modèle Fonctionnel Que fait le système Aspect fonctionnel : Sur quoi le système agit
Modèle Fonctionnel
Que fait le système
Aspect fonctionnel :
Sur quoi le système agit

Aspect dynamique :

diagrammes d'interaction (séquences, collaboration), d'états-transitions et d'activité

diagrammes des cas d'utilisation

Séquencement des actions dans le système

Modèle structurel (objet)

Modèle temporel

Aspect statique :

diagramme de classes et d'objets

© Robert Ogor
© Robert Ogor
(objet) Mod èle temporel Aspect statique : diagramme de classes et d'objets © Robert Ogor 12

12

mai 2003

Modélisation avec UML

Mod élisation avec UML 25 Cahier des charges Phases de la mod élisation S ’accorder

Modélisation

avec UML

25

Mod élisation avec UML 25 Cahier des charges Phases de la mod élisation S ’accorder sur
Cahier des charges
Cahier des
charges

Phases de la modélisation

S ’accorder sur ce qui doit être fait dans le système Expression des besoins Analyse
S ’accorder sur ce qui doit être fait dans le système
Expression des besoins
Analyse
Comprendre les besoins et les décrire dans le système
Conception
S ’accorder sur la manière dont le système doit être construit
Implémentation
Codage du résultat de la conception
Test
Le système est-il conforme au cahier des charges ?
Code
exécutable
© Robert Ogor
Mod élisation avec UML 26 Rôle de l'expression des besoins Permettre une meilleure compr éhension

Modélisation

avec UML

26

Mod élisation avec UML 26 Rôle de l'expression des besoins Permettre une meilleure compr éhension du

Rôle de l'expression des besoins

Permettre une meilleure compréhension du système

Comprendre et structurer les besoins du client

clarifier, filtrer et organiser les besoins, ne pas chercher l’exhaustivité

Une fois identifiés et structurés, ces besoins :

définissent le contour du système à modéliser (ils précisent le but à atteindre), permettent d'identifier les fonctionnalités principales (critiques) du système.

© Robert Ogor
© Robert Ogor
permettent d'identifier les fonctionnalités principales (critiques) du système. © Robert Ogor 13 mai 2003

13

mai 2003

Modélisation avec UML

Mod élisation avec UML 27 Expression des besoins Comprendre le contexte du syst ème en

Modélisation

avec UML

27

Mod élisation avec UML 27 Expression des besoins Comprendre le contexte du syst ème en définissant

Expression des besoins

Comprendre le contexte du système en définissant un modèle du domaine et du métier Recenser les besoins fonctionnels et les définir par des cas d'utilisations Noter les contraintes, exigences non fonctionnelles.

Le modèle du domaine regroupe les objets qui se situent dans le contexte du système :

- entités existantes ou événements qui s'y produisent.

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 28 Exigences non fonctionnelles Contraintes de concurrence Contraintes de temps de

Modélisation

avec UML

28

Mod élisation avec UML 28 Exigences non fonctionnelles Contraintes de concurrence Contraintes de temps de r

Exigences non fonctionnelles

Contraintes de concurrence Contraintes de temps de réponse Contraintes de distribution Contraintes de performance Contraintes de répartition

© Robert Ogor
© Robert Ogor
Contraintes de distribution Contraintes de performance Contraintes de répartition © Robert Ogor 14 mai 2003

14

mai 2003

Modélisation avec UML

Mod élisation avec UML 30 D épendances entre phases de modélisation modèle cas d'utilisation vérifié

Modélisation

avec UML

30

Mod élisation avec UML 30 D épendances entre phases de modélisation modèle cas d'utilisation vérifié par

Dépendances entre phases de modélisation

modèle cas

d'utilisation

vérifié par Modèle de test implémenté par réalisé par Modèle Modèle de conception
vérifié par
Modèle
de test
implémenté par
réalisé par
Modèle
Modèle de
conception
spécifié par Modèle d'analyse
spécifié par
Modèle
d'analyse
d'implémentation

d'implémentation

d'implémentation
© Robert Ogor
© Robert Ogor
Mod élisation avec UML 31 L’analyse Le but de l’analyse est de traduire dans un

Modélisation

avec UML

31

Mod élisation avec UML 31 L’analyse Le but de l’analyse est de traduire dans un langage

L’analyse

Le but de l’analyse est de traduire dans un langage proche de celui des informaticiens les modèles exprimés dans l'expression des besoins.

Cependant pour rester compréhensible par les clients ou utilisateurs, il n'intervient que des entités du domaine (métier) considéré.

Elle sert d'interface, avec l'expression des besoins, aux dialogues et aux contrats avec les clients et les utilisateurs.

L'analyse doit servir de support pour la conception, l'implémentation et la maintenance.

© Robert Ogor
© Robert Ogor
doit servir de support pour la conception, l'implémentation et la maintenance. © Robert Ogor 15 mai

15

mai 2003

Modélisation avec UML

Mod élisation avec UML 32 Expression des besoins : vue orient ée utilisateur Cas d’utilisation

Modélisation

avec UML

32

Mod élisation avec UML 32 Expression des besoins : vue orient ée utilisateur Cas d’utilisation Scénarios

Expression des besoins :

vue orientée utilisateur

Cas d’utilisation Scénarios d'utilisation
Cas
d’utilisation
Scénarios
d'utilisation
Cahier des charges Dialogue clients et futurs utilisateurs Système Définition des fonctionnalités du système
Cahier des
charges
Dialogue clients et
futurs utilisateurs
Système
Définition
des
fonctionnalités
du système
© Robert Ogor
© Robert Ogor
Analyse du syst ème Mod élisation avec UML 33 Cahier des charges Diagramme de classes

Analyse du système

Modélisation

avec UML

33

Analyse du syst ème Mod élisation avec UML 33 Cahier des charges Diagramme de classes Système
Cahier des charges
Cahier des
charges

Diagramme

de

classes

avec UML 33 Cahier des charges Diagramme de classes Système Cas d’utilisation Propagation des événements
Système Cas d’utilisation
Système
Cas
d’utilisation
charges Diagramme de classes Système Cas d’utilisation Propagation des événements dans le système Diagramme de
Propagation des événements dans le système
Propagation des
événements
dans le système

Diagramme de collaboration ou de séquences

Diagramme de collaboration ou de séquences
dans le système Diagramme de collaboration ou de séquences Diagramme d'états-transitions © Robert Ogor

Diagramme

d'états-transitions

© Robert Ogor
© Robert Ogor
Diagramme de collaboration ou de séquences Diagramme d'états-transitions © Robert Ogor 16 mai 2003

16

mai 2003

Modélisation avec UML

Mod élisation avec UML 34 La notation graphique BUT : Mod éliser les objets, les

Modélisation

avec UML

34

Mod élisation avec UML 34 La notation graphique BUT : Mod éliser les objets, les relations

La notation graphique

BUT :

Modéliser les objets, les relations entre objets, les interactions avec le système.

Servir de support de communication entre l'analyste, le client, et les utilisateurs.

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 35 Cahier des charges : gestion de biblioth èque Un g

Modélisation

avec UML

35

Mod élisation avec UML 35 Cahier des charges : gestion de biblioth èque Un g érant

Cahier des charges : gestion de bibliothèque

Un gérant de bibliothèque désire automatiser la gestion des prêts.

Il commande un logiciel permettant aux utilisateurs de connaître les livres présents, d'en réserver jusqu'à 2. L'adhérent peut connaître la liste des livres qu'il a empruntés ou réservés.

L'adhérent possède un mot de passe qui lui est donné à son inscription.

L'emprunt est toujours réalisé par les employés qui travaillent à la bibliothèque. Après avoir identifié l'emprunteur, ils savent si le prêt est possible (nombre max de prêts = 5), et s'il a la priorité (il est celui qui a réservé le livre).

Ce sont les employés qui mettent en bibliothèque les livres rendus et les nouveaux livres. Il leur est possible de connaître l'ensemble des prêts réalisés dans la bibliothèque.

© Robert Ogor
© Robert Ogor
leur est possible de connaître l'ensemble des prêts réalisés dans la bibliothèque. © Robert Ogor 17

17

mai 2003

Modélisation avec UML

Mod élisation avec UML 36 2) Le diagramme des Use Cases ou des cas d

Modélisation

avec UML

36

Mod élisation avec UML 36 2) Le diagramme des Use Cases ou des cas d ’utilisation

2) Le diagramme des Use Cases

ou

des

cas d ’utilisation

Ce que doit faire le système sans spécifier comment il le fait

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 37 But des Use Cases Les cas d'utilisation représentent les fonctionnalités

Modélisation

avec UML

37

Mod élisation avec UML 37 But des Use Cases Les cas d'utilisation représentent les fonctionnalités que

But des Use Cases

Les cas d'utilisation représentent les fonctionnalités que le système doit savoir faire.

Chaque cas d'utilisation peut être complèté par un ensemble d'interactions successives d'une entité en dehors du système (l’utilisateur) avec le système lui même.

du système (l’utilisateur) avec le système lui même. Système Les Uses Cases permettent : • De
Système
Système

Les Uses Cases permettent :

• De connaître le comportement du système sans spécifier comment ce

comportement sera réalisé.

• De définir les limites précises du système

• Au développeur de bien comprendre l'attente des utilisateurs et les experts du domaine.

De plus les Use Cases sont :

• Des instruments de validation et de test du système en cours et en fin de construction.

© Robert Ogor
© Robert Ogor
Des instruments de validation et de test du système en cours et en fin de construction.

18

mai 2003

Modélisation avec UML

Mod élisation avec UML 38 Mod èle des cas d'utilisations Un diagramme de cas d’utilisation

Modélisation

avec UML

38

Mod élisation avec UML 38 Mod èle des cas d'utilisations Un diagramme de cas d’utilisation d

Modèle des cas d'utilisations

Un diagramme de cas d’utilisation définit :

le système les acteurs les cas d'utilisations les liens entre acteurs et cas d'utilisations

Un modèle de cas d'utilisation se définit par :

des diagrammes de cas d’utilisation une description textuelle des scénarios d'utilisation une description de ces scénarios par :

les diagrammes de séquences les diagrammes de collaboration

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 39 Les Acteurs Un acteur repr ésente une personne ou un

Modélisation

avec UML

39

Mod élisation avec UML 39 Les Acteurs Un acteur repr ésente une personne ou un périphérique

Les Acteurs

Un acteur représente une personne ou un périphérique qui joue un rôle (interagit) avec le système. Relation entre acteurs : généralisation (héritage)

Relation entre acteurs : généralisation (héritage) abonn é bibliothécaire Acteur abonné Héritage relation

abonné

bibliothécaire

Acteur
Acteur
généralisation (héritage) abonn é bibliothécaire Acteur abonné Héritage relation entre acteurs un bibliothécaire

abonné

Héritage relation entre acteurs un bibliothécaire est un abonné

un administrateur est un bibliothécaire un administrateur est un abonné

un administrateur est un bibliothécaire un administrateur est un abonné bibliothécaire administrateur © Robert Ogor
un administrateur est un bibliothécaire un administrateur est un abonné bibliothécaire administrateur © Robert Ogor

bibliothécaire

administrateur

© Robert Ogor
© Robert Ogor
est un bibliothécaire un administrateur est un abonné bibliothécaire administrateur © Robert Ogor 19 mai 2003

19

mai 2003

Modélisation avec UML

Mod élisation avec UML 40 Les cas d’utilisation (use-case) Un cas d’utilisation est un moyen

Modélisation

avec UML

40

Mod élisation avec UML 40 Les cas d’utilisation (use-case) Un cas d’utilisation est un moyen de

Les cas d’utilisation (use-case)

Un cas d’utilisation est un moyen de représenter les différentes possibilités d'utiliser un système. Il exprime toujours une suite d'interactions entre un acteur et l'application. Il définit une fonctionnalité utilisable par un acteur.

Emprunter Réserver
Emprunter
Réserver
Regarder la liste des livres
Regarder la liste
des livres
© Robert Ogor
© Robert Ogor
Mod élisation avec UML 41 Organisation des Use Cases : include La relation " include

Modélisation

avec UML

41

Mod élisation avec UML 41 Organisation des Use Cases : include La relation " include "

Organisation des Use Cases :

include

La relation "include" précise qu'un cas d’utilisation contient le comportement défini dans un autre cas d’utilisation.

Cette

relation

permet

de

mettre

en

commun

des

comportements communs à plusieurs cas d'utilisation

Emprunt <<include>> Identification abonné <<include>> Réservation
Emprunt
<<include>>
Identification
abonné
<<include>>
Réservation
© Robert Ogor
© Robert Ogor
Identification abonné <<include>> Réservation © Robert Ogor 20 mai 2003

20

mai 2003

Modélisation avec UML

Mod élisation avec UML 42 Organisation des Use Cases : extend La relation " extend

Modélisation

avec UML

42

Mod élisation avec UML 42 Organisation des Use Cases : extend La relation " extend "

Organisation des Use Cases :

extend

La relation "extend" précise qu'un cas d’utilisation peut dans certains cas augmenter le comportement d'un autre cas d'utilisation. Une condition devra valider cette augmentation. Le point d'utilisation de cette augmentation peut être défini dans un "point d'extension".

Réservation Extensionpoints avant le choix du livre
Réservation
Extensionpoints
avant le choix du livre
Regarder liste des livres
Regarder liste des
livres

<<extend>> avant le choix du livre

Dans cet exemple, le cas d'utilisation "Regarder la liste des livres" augmente le cas d'utilisation d'une réservation, avant le choix du livre, si l'utilisateur en fait la demande.

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 43 Organisation des Use Cases : g énéralisation Cette relation "

Modélisation

avec UML

43

Mod élisation avec UML 43 Organisation des Use Cases : g énéralisation Cette relation " est

Organisation des Use Cases :

généralisation

Cette relation "est un" introduit la notion d’héritage. Les cas d'utilisation "Vérification par mot passe" et "Vérification par carte" sont des spécialisations du cas d'utilisation "Identification abonné".

Autrement dit : si l'on dit que l'on fait une "Identification abonné", ce peut être une "Vérification par carte" ou une "Vérification par mot

passe".

héritage

Vérification par mot passe Identification abonné Vérification par carte
Vérification par
mot passe
Identification
abonné
Vérification par
carte
© Robert Ogor
© Robert Ogor
éritage Vérification par mot passe Identification abonné Vérification par carte © Robert Ogor 21 mai 2003

21

mai 2003

Modélisation avec UML

Mod élisation avec UML 44 Mod élisation d’un système: obtenir les cas d'utilisation Identifier les

Modélisation

avec UML

44

Mod élisation avec UML 44 Mod élisation d’un système: obtenir les cas d'utilisation Identifier les acteurs

Modélisation d’un système:

obtenir les cas d'utilisation

Identifier les acteurs qui utilisent, qui gèrent, qui exécutent des fonctions spécifiques. Organiser les acteurs par relation d’héritage. Pour chaque acteur, rechercher les cas d’utilisation avec le système. En particulier, ceux qui modifient l’état du système ou qui attendent une réponse du système. Ne pas oublier les variantes d’interactions (cas d’erreur, cas interdits). Organiser ces interactions par héritage, par utilisation et par extension.

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 45 Le syst ème Le syst ème définit l'application informatique, il

Modélisation

avec UML

45

Mod élisation avec UML 45 Le syst ème Le syst ème définit l'application informatique, il ne

Le système

Le système définit l'application informatique, il ne contient donc pas les acteurs, mais les cas d'utilisation et leur associations

Gestion de bibliothèque

Réserver un livre
Réserver un livre
Connaître les livres empruntés
Connaître les livres empruntés
Connaître les livres présents
Connaître les livres présents
Ajouter de nouveaux livres
Ajouter de nouveaux livres
Remettre un livre Réaliser un emprunt
Remettre un livre
Réaliser un emprunt
© Robert Ogor
© Robert Ogor
présents Ajouter de nouveaux livres Remettre un livre Réaliser un emprunt © Robert Ogor 22 mai

22

mai 2003

Modélisation avec UML Modélisation avec UML 46 Les diagrammes de cas d’utilisation Bibliothèque Réserver un
Modélisation avec UML
Modélisation
avec UML
46
Les diagrammes de cas d’utilisation
Bibliothèque
Réserver un livre
Cas
d ’utilisation
Connaître les livres empruntés
Client
Acteurs
Connaître les livres présents
Ajouter de nouveaux livres
Remettre un livre
Employé
Réaliser un emprunt
© Robert Ogor
Modélisation avec UML 47 Les diagrammes de cas d’utilisation Bibliothèque Connaître les livres empruntés
Modélisation
avec UML
47
Les diagrammes de cas d’utilisation
Bibliothèque
Connaître les livres empruntés
<< include >>
Réserver un livre
<<include>>
Extension point
avant la réservation
Identification
Client
<<extends>>
Identification
Connaître les livres présents
par carte
Ajouter de nouveaux livres
Identification
par mot de passe
Remettre un livre
Employé
Réaliser un emprunt
© Robert Ogor
livres Identification par mot de passe Remettre un livre Employé Réaliser un emprunt © Robert Ogor

23

mai 2003

Modélisation avec UML

Mod élisation avec UML 48 Sc énarios d'un cas d'utilisation La description d’un cas d’utilisation

Modélisation

avec UML

48

Mod élisation avec UML 48 Sc énarios d'un cas d'utilisation La description d’un cas d’utilisation se

Scénarios d'un cas d'utilisation

La description d’un cas d’utilisation se fait par des scénarios qui définissent la suite logique des interactions qui constituent ce cas. On peut définir des scénarios simples ou des scénarios plus détaillés faisant intervenir les variantes, les cas d'erreurs, etc. Cette description se fait de manière simple, par un texte compréhensible par les personnes du domaine de l'application. Elle précise ce que fait l'acteur et ce que fait le système La description détaillée pourra préciser les contraintes de l'acteur et celles du système.

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 49 Sc énarios d'un cas d'utilisation Réservation d'un livre description simplifi

Modélisation

avec UML

49

Mod élisation avec UML 49 Sc énarios d'un cas d'utilisation Réservation d'un livre description simplifi ée

Scénarios d'un cas d'utilisation

Réservation d'un livre
Réservation d'un livre

description simplifiée

Le client se présente devant un terminal:

• (1) Le système affiche un message d ’accueil.

• (2) Le client choisit l’opération réservation parmi les différentes opérations proposées.

• (3) Le système lui demande de s'authentifier.

• (4) Le client donne son identification (nom, mot de passe).

• (5) Le système lui demande de choisir un livre.

• (6) Le client précise le livre qu'il désire.

• (7) Le système lui précise si un exemplaire du livre lui est réservé.

© Robert Ogor
© Robert Ogor
désire. • (7) Le système lui précise si un exemplaire du livre lui est réservé. ©

24

mai 2003

Modélisation avec UML

Mod élisation avec UML 50 Sc énarios d'un cas d'utilisation Réservation d'un livre description d

Modélisation

avec UML

50

Mod élisation avec UML 50 Sc énarios d'un cas d'utilisation Réservation d'un livre description d étaillée

Scénarios d'un cas d'utilisation

Réservation d'un livre
Réservation d'un livre

description détaillée

Pré-conditions: Le client doit être inscrit à la bibliothèque Le client ne doit pas avoir atteint le nombre maximum de réservation Un exemplaire du livre doit être enregistré

Post-conditions: (Si l'opération s'est bien déroulée) Le client a une réservation supplémentaire Le nombre d'exemplaires disponibles du livre est décrémenté de 1

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 51 Sc énarios d'un cas d'utilisation Réservation d'un livre Cas normal

Modélisation

avec UML

51

Mod élisation avec UML 51 Sc énarios d'un cas d'utilisation Réservation d'un livre Cas normal description

Scénarios d'un cas d'utilisation

Réservation d'un livre
Réservation d'un livre

Cas normal

description détaillée

1.

(1) Le système affiche un message d ’accueil sur le terminal avec un choix d'opérations

2.

(2) Le client choisit l’opération réservation parmi les différentes opérations proposées.

3.

(3) Le système lui demande de s'authentifier.

4.

(4) Le client donne son identification (nom, mot de passe).

5.

(5) Le système demande le titre du livre en donnant la possibilité de choisir dans une liste.

6.

(6) Le client précise le livre qu'il désire.

7.

(7) Le système lui précise que un exemplaire du livre lui est réservé.

variante 1 variante 2
variante 1
variante 2

en (6) le client demande à connaître les livres présents

 
 

en (4) le client n'est pas reconnu, dans ce cas, tant qu'il n'est pas reconnu, on lui redemande de s'authentifier

variante 3
variante 3

en (4) le client est reconnu, mais le mot de passe est incorrect, il peut avoir 5 essais, par la suite le client sera interdit pendant 1 heure.

variante 4
variante 4

en (4) le client n'a plus le droit de réserver

 
variante 5
variante 5

en (7) le livre n'est pas libre

© Robert Ogor
© Robert Ogor
plus le droit de réserver   variante 5 en (7) le livre n'est pas libre ©

25

mai 2003

Modélisation avec UML

Mod élisation avec UML 52 Sc énario par diagramme de séquences Suite aux descriptions textuelles,

Modélisation

avec UML

52

Mod élisation avec UML 52 Sc énario par diagramme de séquences Suite aux descriptions textuelles, le

Scénario par diagramme de séquences

Suite aux descriptions textuelles, le scénario peut être représenté en utilisant un diagramme de séquences. Le diagramme de séquences permet :

de visualiser l’aspect temporel des interactions de connaître le sens des interactions (acteur vers système ou contraire)

le sens des interactions (acteur vers système ou contraire) :Système de prêts Afficher message d ’accueil
:Système de prêts Afficher message d ’accueil Choix de l ’opération réservation Demande d ’identification
:Système de prêts
Afficher message d ’accueil
Choix de l ’opération réservation
Demande d ’identification du client
Identification du client
Demande identification du livre
Identification du livre
Message « le livre est réservé »

Client

temps

Réserver un livre
Réserver un livre
© Robert Ogor
© Robert Ogor
Mod élisation avec UML 53 Variation du sc énario Afficher message d ’accueil Choix de

Modélisation

avec UML

53

Mod élisation avec UML 53 Variation du sc énario Afficher message d ’accueil Choix de l

Variation du scénario

Mod élisation avec UML 53 Variation du sc énario Afficher message d ’accueil Choix de l

Afficher message d ’accueil Choix de l ’opération réservation Demande d ’identification du client Identification du client

d ’identification du client Identification du client Refus trop de livres réservés :Syst ème de prêts
d ’identification du client Identification du client Refus trop de livres réservés :Syst ème de prêts

Refus trop de livres réservés

Identification du client Refus trop de livres réservés :Syst ème de prêts Client Réserver un livre

:Système de prêts

Client

Réserver un livre
Réserver un livre
© Robert Ogor
© Robert Ogor
Refus trop de livres réservés :Syst ème de prêts Client Réserver un livre © Robert Ogor

26

mai 2003

Modélisation avec UML Modélisation avec UML 54 Cas d ’utilisation: Distributeur de billets Cas d’utilisation
Modélisation avec UML
Modélisation
avec UML
54
Cas d ’utilisation:
Distributeur de billets
Cas
d’utilisation
Distributeur de billets
Effectuer un virement
Retirer l ’argent
Client
Banque
Consulter un compte
Acteurs
Acteur
gestionnaires
client
Gérer le distributeur
Effectuer la Maintenance
Employé
© Robert Ogor
Mod élisation avec UML 55 Diagramme de s équences Use Case Retirer de l'argent Client

Modélisation

avec UML

55

Mod élisation avec UML 55 Diagramme de s équences Use Case Retirer de l'argent Client Afficher

Diagramme de séquences Use Case Retirer de l'argent

Client

Afficher message d ’accueil Insère la carte Demande de mot de passe Entre mot de
Afficher message d ’accueil
Insère la carte
Demande de mot de passe
Entre mot de passe
Demande type opération
Entre demande retrait
Demande somme
Entre somme
Distribue l'argent
Demande prendre les billets
Prendre les billets
Imprimer le reçu
Ejecter la carte
Demande de prendre la carte
Prendre la carte
Afficher message d ’accueil

:Distributeur de billets

:Distributeur de billets
Retirer l ’argent
Retirer
l ’argent
© Robert Ogor
© Robert Ogor
carte Afficher message d ’accueil :Distributeur de billets Retirer l ’argent © Robert Ogor 27 mai

27

mai 2003

Modélisation avec UML

Mod élisation avec UML 56 3) Concepts objets et diagrammes de classes © Robert Ogor

Modélisation

avec UML

56

Mod élisation avec UML 56 3) Concepts objets et diagrammes de classes © Robert Ogor

3) Concepts objets et diagrammes de classes

© Robert Ogor
© Robert Ogor
Modélisation avec UML 57 La classe Caractéristiques attributs données membres informations propriétés CLASSE

Modélisation

avec UML

57

Modélisation avec UML 57 La classe Caractéristiques attributs données membres informations propriétés CLASSE

La classe

Caractéristiques

attributs

données membres

informations

propriétés

CLASSE

Personne

nom age adresse mot de passe nbre livres empruntés

changerAdresse()

donnerAge()

donnerAdresse()

vérifierMotDePasse()

donnerAge() donnerAdresse() vérifierMotDePasse() Famille d'objets ayant mêmes caractéristiques et même
donnerAge() donnerAdresse() vérifierMotDePasse() Famille d'objets ayant mêmes caractéristiques et même

Famille d'objets ayant mêmes caractéristiques et même comportement

CLASSE

Personneayant mêmes caractéristiques et même comportement CLASSE Comportement opérations méthodes fonctions

Comportement

opérations

méthodes

fonctions

procédures

messages

services

© Robert Ogor
© Robert Ogor
Comportement opérations méthodes fonctions procédures messages services © Robert Ogor 28 mai 2003

28

mai 2003

Modélisation avec UML

Mod élisation avec UML 58 La classe et ses membres Personne nom : String âge

Modélisation

avec UML

58

Mod élisation avec UML 58 La classe et ses membres Personne nom : String âge :

La classe et ses membres

Personne nom : String âge : Integer adresse : String mot de passe : String
Personne
nom : String
âge : Integer
adresse : String
mot de passe : String
nbre livres empruntés : Integer
0<= nbre livres empruntés <=5
<<constructeur>>
Personne(nom:String, âge : Integer
adresse:String, motDePasse:String)
<<caractéristiques>>
changerAdresse (String)
<<authentification>>
vérifierMotDePasse(String) : Boolean
changerMotDePasse(old:String,
new:String)
© Robert Ogor
© Robert Ogor
Modélisation avec UML 59 instance de La classe et l’objet un objet CLASSE :Personne Personne
Modélisation
avec UML
59
instance de
La classe et l’objet
un objet
CLASSE
:Personne
Personne
nom
age
adresse
mot de passe
nbre livres empruntés
Attributs
nom = Alain Dupont
age = 45
adresse = France
mot de passe = 4RSA67
nbre livres empruntés = 4
changerAdresse()
Comportement
: Personne
obtenirAge()
obtenirAdresse()
André Roué
vérifierMotDePasse()
25
France
6FT34
0
:Personne
© Robert Ogor
obtenirAdresse() André Roué vérifierMotDePasse() 25 France 6FT34 0 :Personne © Robert Ogor 29 mai 2003

29

mai 2003

Modélisation avec UML

Mod élisation avec UML 60 Protection des attributs et des op érations : principe de

Modélisation

avec UML

60

Mod élisation avec UML 60 Protection des attributs et des op érations : principe de l'encapsulation

Protection des attributs et des opérations : principe de l'encapsulation

Peut-on accéder à tous les attributs ou à toutes les

méthodes d'un objet ?

NON

La classe définit ce qui est accessible. C'est le principe de l'encapsulation. Un objet complexe ne peut être utilisé qu'au travers de ce qui est accessible. Exemple :

On ne peut utiliser une voiture qu'à travers son volant, son frein, son accélérateur, etc. L’accès au carburateur est impossible sauf par les méthodes qui le font de manière cohérente (méthode accélérer de l’accélérateur).

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 61 Protection des attributs et des op érations : usage et

Modélisation

avec UML

61

Mod élisation avec UML 61 Protection des attributs et des op érations : usage et notation

Protection des attributs et des opérations : usage et notation

Les attributs sont en général inaccessibles (secret).

Ils sont alors qualifiés de :

"protected" (notation UML : # ) ou "private" (notation UML: - )

Leur lecture ou modification n'est possible qu'au travers de certaines opérations (accesseurs : changerAdresse(), obtenirAge(), etc.)

Les opérations sont en général accessibles (publiques) :

Elles sont alors qualifiées de :

"public" (notation UML: + )

Certaines opérations peuvent cependant être privées et certains attributs peuvent être publics (non souhaitable / principe d’encapsulation)

© Robert Ogor
© Robert Ogor
et certains attributs peuvent être publics (non souhaitable / principe d’encapsulation) © Robert Ogor 30 mai

30

mai 2003

Modélisation avec UML

Mod élisation avec UML 62 Protection des attributs et des op érations : notation UML

Modélisation

avec UML

62

Mod élisation avec UML 62 Protection des attributs et des op érations : notation UML CLASSE

Protection des attributs et des opérations : notation UML

CLASSE

Personne

- nom

- âge

- adresse

# changerAdresse()

# obtenirRue()

+ obtenirAge()

+ : attribut public

# : attribut protected

- : attribut private

+ : opération public

# : opération protected

- : opération private

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 63 Attributs et op érations de classe Personne - nom -

Modélisation

avec UML

63

Mod élisation avec UML 63 Attributs et op érations de classe Personne - nom - age

Attributs et opérations de classe

Personne - nom - age Le nombre de livres empruntables n'est pas une caractéristique d'Alain
Personne
- nom
- age
Le nombre de livres empruntables n'est pas
une caractéristique d'Alain Dupont (objet).
C'est une caractéristique valable pour
l'ensemble des personnes (la classe).
- adresse
- mot de passe
-
nbreLivresEmpruntés
- nbreLivresEmpruntables = 5
une_personne:Personne
+ changerAdresse()
+ obtenirAge()
+ obtenirAdresse()
+ vérifierMotDePasse()
+ getNbLivresEmpruntables()
nom = Alain Dupont
age = 45
adresse = France
mot de passe = 4RSA67
nbreLivresEmpruntés= 4
La méthode getNbLivresEmpruntables() utilise la valeur
nbreLivresEmpruntables connue par la classe. Cette méthode peut être
appliquée directement à la classe Personne et bien sûr aussi aux objets
instances de Personne.
© Robert Ogor
directement à la classe Personne et bien sûr aussi aux objets instances de Personne. © Robert

31

mai 2003

Modélisation avec UML

Mod élisation avec UML 64 Attributs et op érations de classe Notation UML CLASSE Personne

Modélisation

avec UML

64

Mod élisation avec UML 64 Attributs et op érations de classe Notation UML CLASSE Personne -

Attributs et opérations de classe Notation UML

CLASSE

Personne

- nom

- âge

- adresse

- nombrePersonne

# changerAdresse()

# obtenirRue()

+ obtenirAge() +obtenirNombrePersonne()

+ : attribut public

# : attribut protected

- attribut private

attribut de classe

:

:

+ : opération public

# opération protected

:

- opération private

:

:

opération de classe

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 65 La r éification Chien Mariage race époux age épouse couleur

Modélisation

avec UML

65

Mod élisation avec UML 65 La r éification Chien Mariage race époux age épouse couleur date

La réification

Chien Mariage race époux age épouse couleur date entité physique événement aboyer() seMarier () mordre
Chien
Mariage
race
époux
age
épouse
couleur
date
entité physique
événement
aboyer()
seMarier ()
mordre ()
divorcer ()
obéir ()
Cours
Appartenir
professeur
propriétaire
salle
date
élèves
voiture
situation
relation
assister ()
vendre ()
quitter ()
acheter ()
prêter ()
© Robert Ogor
voiture situation relation assister () vendre () quitter () acheter () prêter () © Robert Ogor

32

mai 2003

Modélisation avec UML

Mod élisation avec UML 66 Mod èle du type abstrait Pile PileEntier - contenu -

Modélisation

avec UML

66

Mod élisation avec UML 66 Mod èle du type abstrait Pile PileEntier - contenu - hauteur

Modèle du type abstrait Pile

PileEntier

- contenu

- hauteur

- taille

+empiler (valeur : Integer) +dépiler () +elementSommet () : Integer +nombreElements : Integer +estVide : Boolean

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 67 Surcharge et polymorphisme Personne nom : String age : Integer

Modélisation

avec UML

67

Mod élisation avec UML 67 Surcharge et polymorphisme Personne nom : String age : Integer adresse

Surcharge et polymorphisme

Personne

nom : String age : Integer adresse : String

changerAdresse(sonAdresse : String) obtenirAge() : entier obtenirAdresse() : String

imprimer()

notions :

polymorphisme

surcharge

signature

Fichier

nom : String taille : Integer propriétaire : String

imprimer()
imprimer()

imprimer(nombreLignes : entier

)

© Robert Ogor
© Robert Ogor
: Integer propri étaire : String imprimer() imprimer(nombreLignes : entier ) © Robert Ogor 33 mai

33

mai 2003

Modélisation avec UML

Mod élisation avec UML 68 Classes param étrables Element taille : Integer Pile +Pile() +empiler(valeur

Modélisation

avec UML

68

Mod élisation avec UML 68 Classes param étrables Element taille : Integer Pile +Pile() +empiler(valeur :

Classes paramétrables

Element taille : Integer Pile +Pile() +empiler(valeur : Element) +dépiler () : Element +nombreElements() :
Element
taille : Integer
Pile
+Pile()
+empiler(valeur : Element)
+dépiler () : Element
+nombreElements() : Integer
+estVide (): Boolean
+estPleine() : Boolean
return
nombreElements() ==taille

Pile

<Integer,34>

Pile

<Point,20>

<<bind>>(Personne, 100)

Guichet

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 69 Association entre classes Nom d’association Sens de lecture du nom

Modélisation

avec UML

69

Association entre classes
Association entre classes
Nom d’association Sens de lecture du nom d’association Livre aPourAuteur Auteur titre nom unLivre :
Nom d’association
Sens de lecture
du nom d’association
Livre
aPourAuteur
Auteur
titre
nom
unLivre : Livre
aPourAuteur
unHomme : Auteur
titre = La peste
nom = Camus
© Robert Ogor
© Robert Ogor
titre nom unLivre : Livre aPourAuteur unHomme : Auteur titre = La peste nom = Camus

34

mai 2003

Modélisation avec UML

Mod élisation avec UML 70 Multiplicit é, nom d’association, nom de rôle nom de rôle

Modélisation

avec UML

70

Mod élisation avec UML 70 Multiplicit é, nom d’association, nom de rôle nom de rôle Société

Multiplicité, nom d’association, nom de rôle

nom de rôle Société Personne employeur employé nom patron patron nom adresse 0 1 0
nom de rôle
Société
Personne
employeur
employé
nom
patron patron
nom
adresse
0
1
0
1
emploie
*
adresse
estEmployée
grade
1
(par défaut)
ouvrier
ouvrier
*
1
1
(explicite)
3
3
dirige
0
1
0
ou 1
nom d’association
multiplicité
* 0
ou plusieurs
1
* ou plusieurs
1
6
28
intervalle
© Robert Ogor
Mod élisation avec UML 71 Lien entre objets constructeur : Soci été   emploie  

Modélisation

avec UML

71

Mod élisation avec UML 71 Lien entre objets constructeur : Soci été   emploie   nom

Lien entre objets

constructeur : Société

 

emploie

emploie
 

nom : Peugeot adresse : Sochaux

 

contremaître : Personne

 

employeur

employé

 

nom = Dupont

 
© Robert Ogor
© Robert Ogor
: Personne   employeur employ é   nom = Dupont   © Robert Ogor 35 mai

35

mai 2003

Modélisation avec UML

Mod élisation avec UML 72 Lien entre objets estEmploy ée constructeur : emploie patron  

Modélisation

avec UML

72

Mod élisation avec UML 72 Lien entre objets estEmploy ée constructeur : emploie patron    

Lien entre objets

Mod élisation avec UML 72 Lien entre objets estEmploy ée constructeur : emploie patron    

estEmployée

constructeur :

emploie

constructeur : emploie patron

patron

   

leDirecteur : Personne

Nom Société : Peugeot adresse : Sochaux

employeur

 

nom = Madec

     
   

d

   
 

e

 

i

m

r

p

i

 

unContremaître : Personne

 

l

 

g

o

i

nom = Simon

 

e

e

e

 

ouvrier

   
   
   

unCadre : Personne

ouvrier

 

nom = Dupont

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 73 Classe d’association Soci été     Personne     emploie

Modélisation

avec UML

73

Mod élisation avec UML 73 Classe d’association Soci été     Personne     emploie

Classe d’association

Société

 
 

Personne

   

emploie

emploie
 

Nom

Nom

adresse

0

1

 

*

adresse

     
grade salaire
grade
salaire
 
 

Emploi

   

grade

 

salaire

Classe d’association

© Robert Ogor
© Robert Ogor
  Emploi     grade   salaire Classe d ’association © Robert Ogor 36 mai 2003

36

mai 2003

Modélisation avec UML

Mod élisation avec UML 74 Qualificateurs : restriction de la cardinalit é   g ère

Modélisation

avec UML

74

Mod élisation avec UML 74 Qualificateurs : restriction de la cardinalit é   g ère  

Qualificateurs : restriction de la cardinalité

 

gère

 

CompteBancaire

Banque

1

 

*

 

numéroCompte

 

Banque

numéroCompte

 

gère

1

CompteBancaire

 

1

 
 

gère

 

Fichier

Répertoire

1

 

*

 

nom

 

gère

 
   

1

 

1

Fichier

Répertoire

nom

 
© Robert Ogor
© Robert Ogor
Modélisation avec UML 75 Contraintes sur les associations CompteChèque {or} Société * 1 assiste *
Modélisation
avec UML
75
Contraintes sur les associations
CompteChèque
{or}
Société
*
1 assiste
*
Conférence
Personne
{sous-ensemble}
1
*
organise
© Robert Ogor

*

appartient

1

Personne

* appartient 1 Personne
* Conférence Personne {sous-ensemble} 1 * organise © Robert Ogor * appartient 1 Personne 37 mai

37

mai 2003

Modélisation avec UML

Mod élisation avec UML 77 Attribut d érivé {Contexte Personne Inv : age = dateCourante

Modélisation

avec UML

77

Mod élisation avec UML 77 Attribut d érivé {Contexte Personne Inv : age = dateCourante -

Attribut dérivé

{Contexte Personne Inv : age = dateCourante - dateNaissance }
{Contexte Personne
Inv : age = dateCourante - dateNaissance }

Attribut dérivé

© Robert Ogor
© Robert Ogor

Personne

Nom

adresse

grade

dateNaissance

/age

Mod élisation avec UML 78 Les associations ternaires Cours Cours Enseignant Salle Elève © Robert

Modélisation

avec UML

78

Mod élisation avec UML 78 Les associations ternaires Cours Cours Enseignant Salle Elève © Robert Ogor

Les associations ternaires

Cours Cours Enseignant Salle Elève © Robert Ogor
Cours
Cours
Enseignant
Salle
Elève
© Robert Ogor
avec UML 78 Les associations ternaires Cours Cours Enseignant Salle Elève © Robert Ogor 38 mai

38

mai 2003

Modélisation avec UML

Modélisation avec UML 79 Agrégation 3 * Polygone Point {ordonnés} C'est une association qui exprime
Modélisation
avec UML
79
Agrégation
3
*
Polygone
Point
{ordonnés}
C'est une association qui exprime un
couplage fort lié à une relation de
subordination, elle est asymétrique du
type ensemble/élément.
1
Titre
1
1
*
Destinataire
Règles permettant de choisir une agrégation :
*
•Est ce une partie de?
•Les opérations appliquées à l'ensemble sont
elles appliquées à l'élément?
•Les changements d'états sont-ils liés ?
E-mail
1
Texte
1
*
1
attaché
Mais
Fichier
• un élément agrégé peut être lié à d'autres classes
*
• la suppression de l'ensemble n'entraîne pas celle de l'élément
*
*
Polycopié
© Robert Ogor
Mod élisation avec UML 80 Composition : agr égation forte La composition est une agr

Modélisation

avec UML

80

Mod élisation avec UML 80 Composition : agr égation forte La composition est une agr égation

Composition : agrégation forte

La composition est une agrégation forte qui lie les cycles de vie entre le composé (ensemble) et les composants (élements).

Le choix entre composition et agrégation peut être laissé à la phase de conception.

Document * Paragraphe * Phrase
Document
* Paragraphe
*
Phrase
4 Voiture Roue 1 2-5 Carrosserie Porte 1 Habitacle 1 Moteur © Robert Ogor
4
Voiture
Roue
1
2-5
Carrosserie
Porte
1
Habitacle
1
Moteur
© Robert Ogor
* Phrase 4 Voiture Roue 1 2-5 Carrosserie Porte 1 Habitacle 1 Moteur © Robert Ogor

39

mai 2003

Modélisation avec UML

Mod élisation avec UML 81 Association, agr égation ou composition ? 1. R ègles obligatoires

Modélisation

avec UML

81

Mod élisation avec UML 81 Association, agr égation ou composition ? 1. R ègles obligatoires pour

Association, agrégation ou composition ?

1. Règles obligatoires pour l'agrégation :

• Est ce une partie de?

• Les opérations appliquées au composé sont elles appliquées au composant?

• Les changements d'états sont-ils liés ?

2. Règles obligatoires pour la composition :

• La suppression du composé entraîne t-elle la suppression des composants ?

• Les attributs du composé sont-ils utilisés dans les composants ?

• Les composants sont des instances du composé ?

• Un composant ne peut pas être en relation avec d'autres classes externes au composé.

???
???

gère

avec d'autres classes externes au composé. ??? gère Magasin * Client gère Magasin * Client gère
Magasin * Client gère Magasin * Client
Magasin
*
Client
gère
Magasin
*
Client
gère Magasin * Client
gère
Magasin
*
Client
© Robert Ogor
© Robert Ogor
Mod élisation avec UML 82 Composition Fenêtre scollbar 1 contrôle contenu 2 1 Ascenceur Bordure

Modélisation

avec UML

82

Mod élisation avec UML 82 Composition Fenêtre scollbar 1 contrôle contenu 2 1 Ascenceur Bordure Panel

Composition

Fenêtre scollbar 1 contrôle contenu 2 1 Ascenceur Bordure Panel
Fenêtre
scollbar
1 contrôle
contenu
2
1
Ascenceur
Bordure
Panel

Fenêtre

scollbar [2]: Ascenceur

contrôle : Bordure

contenu : Panel

© Robert Ogor
© Robert Ogor
Panel Fenêtre scollbar [2]: Ascenceur contrôle : Bordure contenu : Panel © Robert Ogor 40 mai

40

mai 2003

Modélisation avec UML Modélisation avec UML 83 Navigabilité Par défaut une association est bidirectionnelle. Il
Modélisation avec UML
Modélisation
avec UML
83
Navigabilité
Par défaut une association est bidirectionnelle.
Il est possible de réduire la portée en la rendant unidirectionnelle.
En général, ce choix se fait dans la phase de conception.
Agenda
Réunion
*
aLieu
TrancheHoraire
fin
début
Flèche de navigabilité :
Date
Association unidirectionnelle
© Robert Ogor
Mod élisation avec UML 84 Eléments sur une association navigabilité cardinalité ordonnancement 1 {ordered} 3

Modélisation

avec UML

84

Mod élisation avec UML 84 Eléments sur une association navigabilité cardinalité ordonnancement 1 {ordered} 3 *
Eléments sur une association navigabilité cardinalité ordonnancement 1 {ordered} 3 * rôle Polygone Point
Eléments sur une association
navigabilité
cardinalité
ordonnancement
1
{ordered}
3
*
rôle
Polygone
Point
+contenu
1
1
nom d’association
agrégation
montre
qualificateur
composition
1
- support
1
Présentation
{frozen}
Canevas
visibilité
couleur
texture
changeable
densité
© Robert Ogor
numéro
Présentation {frozen} Canevas visibilité couleur texture changeable densité © Robert Ogor numéro 41 mai 2003

41

mai 2003

Modélisation avec UML

Mod élisation avec UML 85 3) Concepts objets et diagrammes de classes H éritage ©

Modélisation

avec UML

85

Mod élisation avec UML 85 3) Concepts objets et diagrammes de classes H éritage © Robert

3) Concepts objets et diagrammes de classes

Mod élisation avec UML 85 3) Concepts objets et diagrammes de classes H éritage © Robert

Héritage

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 86 H éritage : buts et principes 1/3 Nouvelles classes dérivées

Modélisation

avec UML

86

Mod élisation avec UML 86 H éritage : buts et principes 1/3 Nouvelles classes dérivées de

Héritage : buts et principes 1/3 Nouvelles classes dérivées de classes existantes

BUT

Permettre une réutilisation optimale des classes déjà écrites, utilisées et validées réutilisation de la structure des données héritées réutilisation du code des services hérités

PRINCIPE

Ne pas modifier les classes déjà écrites cela modifierait l'utilisation qui en est faite.

ne pas hésiter à créer des classes, extensions d'autres déjà validées

© Robert Ogor
© Robert Ogor
faite. ne pas h ésiter à créer des classes, extensions d'autres déjà validées © Robert Ogor

42

mai 2003

Modélisation avec UML

Modélisation avec UML 87 Héritage : adaptation Hérite MoyenTransport vitesseLimite est un est une sorte
Modélisation
avec UML
87
Héritage : adaptation
Hérite
MoyenTransport
vitesseLimite
est un
est une sorte de
désignation
prixHT
annéeConstruction
prixTTC()
obtenirVitesse()
changerPrix()
obtenirAge()
Camion
Voiture
Tramway
nombreEssieux
nombrePortes
nombrePassagers
capacité
niveauBruit
couleur
charge
nombrePassagers()
estPlein()
prixTTC()
VoitureEssence
VoitureDiesel
redéfinition
typeInjecteur
nombreBougies
© Robert Ogor
© Robert Ogor
Mod élisation avec UML 88 H éritage : buts et principes 2/3 Ajout d’une classe

Modélisation

avec UML

88

Mod élisation avec UML 88 H éritage : buts et principes 2/3 Ajout d’une classe de

Héritage : buts et principes 2/3 Ajout d’une classe de base (analyse)

BUT 2

Permettre une factorisation des caractéristiques et des comportements communs à plusieurs classes

mise en commun des structure des données mise en commun du code des services

PRINCIPE

Lorsque plusieurs classes ont des caractéristiques et des comportements communs la création d'une classe ancêtre permet de regrouper ce qui est commun. Cette classe ancêtre peut correspondre à une classe concrète ou à une classe abstraite

© Robert Ogor
© Robert Ogor
Cette classe ancêtre peut correspondre à une classe concrète ou à une classe abstraite © Robert

43

mai 2003

Modélisation avec UML

Mod élisation avec UML 89 H éritage : généralisation Factorisation des propriétés Permanent numéroBureau

Modélisation

avec UML

89

Mod élisation avec UML 89 H éritage : généralisation Factorisation des propriétés Permanent numéroBureau

Héritage : généralisation Factorisation des propriétés

Permanent numéroBureau spécialité nombreCours nom numéroSécu
Permanent
numéroBureau
spécialité
nombreCours
nom
numéroSécu

Vacataire

nombreVacation

nombreCours

spécialité

nom

numéroSécu

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 90 H éritage : généralisation Factorisation des propriétés Enseignant nombreCours

Modélisation

avec UML

90

Mod élisation avec UML 90 H éritage : généralisation Factorisation des propriétés Enseignant nombreCours

Héritage : généralisation Factorisation des propriétés

Enseignant nombreCours Spécialité nom numéroSécu Permanent Vacataire numéroBureau nombreVacation
Enseignant
nombreCours
Spécialité
nom
numéroSécu
Permanent
Vacataire
numéroBureau
nombreVacation
© Robert Ogor
© Robert Ogor
Spécialité nom numéroSécu Permanent Vacataire numéroBureau nombreVacation © Robert Ogor 44 mai 2003

44

mai 2003

Modélisation avec UML

Mod élisation avec UML 91 H éritage : généralisation Factorisation des propriétés Avocat nombreAffaires

Modélisation

avec UML

91

Mod élisation avec UML 91 H éritage : généralisation Factorisation des propriétés Avocat nombreAffaires

Héritage : généralisation Factorisation des propriétés

Avocat nombreAffaires adresseCabinet nom numéroSécu
Avocat
nombreAffaires
adresseCabinet
nom
numéroSécu
Vendeur Enseignant ancienneté nombreCours nomDuStand Spécialité nom nom numéroSécu numéroSécu Permanent
Vendeur
Enseignant
ancienneté
nombreCours
nomDuStand
Spécialité
nom
nom
numéroSécu
numéroSécu
Permanent
Vacataire
numéroBureau
nombreVacation
© Robert Ogor
© Robert Ogor
Mod élisation avec UML 92 H éritage : généralisation Factorisation des propriétés Personne nom numéroSecu

Modélisation

avec UML

92

Mod élisation avec UML 92 H éritage : généralisation Factorisation des propriétés Personne nom numéroSecu

Héritage : généralisation Factorisation des propriétés

Personne nom numéroSecu {disjoint,incomplete} Avocat Vendeur Enseignant nombreAffaires ancienneté nombreCours
Personne
nom
numéroSecu
{disjoint,incomplete}
Avocat
Vendeur
Enseignant
nombreAffaires
ancienneté
nombreCours
adresseCabinet
nomDuStand
spécialité
{disjoint,complete}
Permanent
Vacataire
numéroBureau
nombreVacation
© Robert Ogor
spécialité {disjoint,complete} Permanent Vacataire numéroBureau nombreVacation © Robert Ogor 45 mai 2003

45

mai 2003

Modélisation avec UML

Mod élisation avec UML 93 H éritage multiple et répété Véhicule {overlapping} Véhicule terrestre Véhicule

Modélisation

avec UML

93

Mod élisation avec UML 93 H éritage multiple et répété Véhicule {overlapping} Véhicule terrestre Véhicule marin

Héritage multiple et répété

Véhicule {overlapping} Véhicule terrestre Véhicule marin Voiture Voiture amphibie Bateau
Véhicule
{overlapping}
Véhicule terrestre
Véhicule marin
Voiture
Voiture amphibie
Bateau
Véhicule Véhicule marin Véhicule terrestre Voiture amphibie Voiture Bateau © Robert Ogor
Véhicule
Véhicule marin
Véhicule terrestre
Voiture amphibie
Voiture
Bateau
© Robert Ogor
Modélisation avec UML 94 Notation UML : Classe abstraite nom de classe italique ou stéréotype
Modélisation
avec UML
94
Notation UML :
Classe abstraite
nom de classe italique
ou stéréotype <<abstract>>
Un média peut être transporté, dupliqué, affiché.
Le transport et la duplication sont indépendants
du type du média (copie de fichiers).
Par contre, tout média peut être affiché et ce n'est
pas la même chose pour l'audio, la vidéo, le
graphisme, le texte.
Un média ne peut pas définir comment s'afficher
tant qu'il ne sait pas ce qu'il est.
Média
auteur
titre
date création
transporter()
dupliquer()
afficher()
Il n'y a pas d'instance de la
classe média .
Un média n’existe qu’en
tant que livre, chanson,
graphique ou vidéo.
Livre
Graphique
Vidéo
Chanson
durée
durée
largeur
hauteur
afficher()
afficher()
afficher()
afficher()
© Robert Ogor
© Robert Ogor
Chanson durée durée largeur hauteur afficher() afficher() afficher() afficher() © Robert Ogor 46 mai 2003

46

mai 2003

Modélisation avec UML

Modélisation avec UML 95 Classe abstraite Figure couleur position trait bouger tourner afficher 2_dimensions
Modélisation
avec UML
95
Classe abstraite
Figure
couleur
position
trait
bouger
tourner
afficher
2_dimensions
0_dimension
1_dimension
remplissage
orientation
orientation
agrandir
agrandir
afficher
remplir
afficher
afficher
Point
Ligne
Arc
Polygone
Courbe
rayon
angleArc
afficher
afficher
angleDépart
afficher
afficher
afficher
© Robert Ogor
Mod élisation avec UML 96 H éritage : buts et principes 3/3 Polymorphisme BUT 3

Modélisation

avec UML

96

Mod élisation avec UML 96 H éritage : buts et principes 3/3 Polymorphisme BUT 3 Cr

Héritage : buts et principes 3/3 Polymorphisme

BUT 3

Créer des sous-types (sous-classes). Une sous-classe sera du même type que la classe dont elle hérite (super-classe). Ceci permet de mettre en œ uvre le polymorphisme et la liaison dynamique

PRINCIPE

Un objet d'une classe donnée pourra toujours faire référence à des objets de ses sous classes (polymorphisme ).

Une opération exécutée par un objet sera celle que connaît l'objet dont il fait référence (liaison dynamique).

© Robert Ogor
© Robert Ogor
un objet sera celle que connaît l'objet dont il fait référence (liaison dynamique). © Robert Ogor

47

mai 2003

Modélisation avec UML

Mod élisation avec UML 97 Red éfinition et liaison dynamique Personne nom numéroSecu changerAdresse() Avocat

Modélisation

avec UML

97

Mod élisation avec UML 97 Red éfinition et liaison dynamique Personne nom numéroSecu changerAdresse() Avocat

Redéfinition et liaison dynamique

Personne nom numéroSecu
Personne
nom
numéroSecu

changerAdresse()éfinition et liaison dynamique Personne nom numéroSecu Avocat Vendeur Enseignant nombreAffaires

Avocat

Vendeur

Enseignant

nombreAffaires

ancienneté

nombreCours

adresse

nomDuStand

spécialité

cabinet

changerAdresse()

 

changerAdresse()

Permanent Vacataire numéroBureau nombreVacation Redéfinition
Permanent
Vacataire
numéroBureau
nombreVacation
Redéfinition
© Robert Ogor
© Robert Ogor
Mod élisation avec UML 98 H éritage et sous typage Personne Vendeur Enseignant Avocat Permanent

Modélisation

avec UML

98

Mod élisation avec UML 98 H éritage et sous typage Personne Vendeur Enseignant Avocat Permanent Vacataire

Héritage et sous typage

Personne Vendeur Enseignant Avocat Permanent Vacataire
Personne
Vendeur
Enseignant
Avocat
Permanent
Vacataire

Un objet Personne peut désigner une instance des classes :

Personne

Avocat

Vendeur

Enseignant

Vacataire

Permanent

Conformante
Conformante

Un objet Enseignant peut désigner une instance des classes :

Enseignant Vacataire Permanent Il ne peut pas désigner une instance des classes :

Personne

Avocat

Vendeur

© Robert Ogor
© Robert Ogor
Permanent Il ne peut pas désigner une instance des classes : Personne Avocat Vendeur © Robert

48

mai 2003

Modélisation avec UML

Mod élisation avec UML 99 Conformante Premi ère définition : Se dit d’une classe plus

Modélisation

avec UML

99

Mod élisation avec UML 99 Conformante Premi ère définition : Se dit d’une classe plus sp

Conformante

Première définition :

Se dit d’une classe plus spécialisée

Exemple

Un Enseignant est conformant à une Personne

Utilisation

Un objet conformant à un autre peut être utilisé à sa place sans pour autant déclencher d'erreur de type

étant plus spécialisé, il hérite de tous les services fournis par sa super-classe

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 100 Exemple de conformante void acheterMaison(Personne acheteur) { … acheteur.changerAdresse();

Modélisation

avec UML

100

Mod élisation avec UML 100 Exemple de conformante void acheterMaison(Personne acheteur) { … acheteur.changerAdresse();

Exemple de conformante

void acheterMaison(Personne acheteur)

{

acheteur.changerAdresse();

};

Personne jean; Avocat pierre; Vacataire paul;

Le paramètre peut être abstrait ou concret

acheterMaison(jean) ;

acheterMaison(pierre) ; // licite car pierre est conformant à Personne

acheterMaison(paul) ;

// licite car jean est une Personne

// licite car paul est conformant à Personne

© Robert Ogor
© Robert Ogor
; // licite car jean est une Personne // licite car paul est conformant à Personne

49

mai 2003

Modélisation avec UML

Mod élisation avec UML 101 Conformante et liaison dynamique Personne nom numéroSecu changerAdresse() Avocat

Modélisation

avec UML

101

Mod élisation avec UML 101 Conformante et liaison dynamique Personne nom numéroSecu changerAdresse() Avocat

Conformante et liaison dynamique

Personne nom numéroSecu changerAdresse() Avocat nombreAffaires adresseCabinet Enseignant changerAdresse()
Personne
nom
numéroSecu
changerAdresse()
Avocat
nombreAffaires
adresseCabinet
Enseignant
changerAdresse()
nombre_cours
spécialité
changerAdresse()
Vacataire
Quelle méthode ?
nombreVacation

void acheterMaison(Personne acheteur) {

acheteur.changerAdresse();

};

Personne jean;

Avocat pierre;

Vacataire paul;

acheterMaison(jean) ; acheterMaison(pierre) ; acheterMaison(paul) ;

© Robert Ogor
© Robert Ogor
Modélisation avec UML 102 Liaison dynamique et classe abstraite void acheterŒuvre ( Media achat )
Modélisation
avec UML
102
Liaison dynamique et classe
abstraite
void acheterŒuvre ( Media achat )
{…
Media
auteur
achat.afficher();
titre
date création
};
transporter()
dupliquer()
Vidéo lesVisiteurs;
afficher()
Chanson letItBe;
Livre laPeste;
Livre
Graphique
Vidéo
Chanson
acheterŒuvre (lesVisiteurs);
acheterŒuvre (letItBe);
acheterŒuvre (laPeste);
durée
durée
largeur
hauteur
afficher()
afficher()
afficher()
afficher()
© Robert Ogor
© Robert Ogor
durée durée largeur hauteur afficher() afficher() afficher() afficher() © Robert Ogor 50 mai 2003

50

mai 2003

Modélisation avec UML

Mod élisation avec UML 103 Les Interfaces Une interface permet de d écrire le comportement

Modélisation

avec UML

103

Mod élisation avec UML 103 Les Interfaces Une interface permet de d écrire le comportement d'une

Les Interfaces

Une interface permet de décrire le comportement d'une entité (classe, paquetage ou composant ), c'est à dire un savoir faire sous la forme d’une liste d’opérations.

Une interface ne peut donner lieu à aucune implémentation.

Une interface est équivalente à une classe abstraite sans attributs où toutes les méthodes sont abstraites.

Une classe peut déclarer qu'elle implémente une interface. Elle doit alors implémenter toutes les opérations de cette interface. Elle peut ensuite être utilisée partout où ce comportement est exigé.

© Robert Ogor
© Robert Ogor
Mod élisation avec UML 104 Interface op ération, méthode, service sans corps <<interface>> D

Modélisation

avec UML

104

Mod élisation avec UML 104 Interface op ération, méthode, service sans corps <<interface>> D

Interface

opération,

méthode,

service

sans corps

Interface op ération, méthode, service sans corps <<interface>> D éplaçable saPlace ()

<<interface>>

Déplaçable

saPlace ()

avancer ()

reculer ()

monter ()

descendre ()

Une interface n’est PAS une classe C’est une liste de services