M

1
Méthodologie objet

• Survol des concepts
• T. Libourel
• libourel_at_lirmm.fr
• Avec la complicité de M Huchard

2
Plan
Introduction - Généralités sur les méthodes
objet
Concepts objet et formalisme UML
3
Plan
Introduction - Généralités sur les méthodes
objet
4
Introduction
Évolution des besoins
Évolution des technologies
Évolution des paradigmes de programmation
5
Introduction

• Taille et complexité des systèmes importantes et
  croissantes
• les besoins et les fonctionnalités augmentent
• la technologie évolue rapidement
• les architectures se diversifient
• Problèmes des spécifications
• parfois imprécises, incomplètes, ou incohérentes
• assurer linterface avec le métier (domaine
  dapplication)

6
Introduction

• Évolution des applications
• évolution des besoins des utilisateurs
• réorientation de l'application
• évolution de l'environnement technique (matériel
  et logiciel)
• Problèmes liés à la gestion des équipes
• taille croissante des équipes
• spécialisation technique
• spécialisation métier

7
Introduction
Pourquoi des méthodes ?
Une nécessité
Outils Informatiques
Entreprise
8
Introduction
Pourquoi des méthodes ?
Démarche reproductible pour obtenir des
résultats fiables
Construire des modèles à partir d'éléments
(concepts) Possibilité de représenter à
partir de formalismes Mise en œuvre
9
Introduction
Pourquoi des méthodes ?

• Une méthode danalyse et de conception
• propose une démarche qui distingue les étapes du
  développement dans le cycle de vie du logiciel
  (modularité, réduction de la complexité,
  réutilisabilité éventuelle, abstraction)
• sappuie sur un formalisme de représentation qui
  facilite la communication, lorganisation et la
  vérification
• produit des documents (modèles) qui facilitent
  les retours sur conception et lévolution des
  applications

10
Historique
Méthodes cartésiennes Jackson, SADT,
Yourdon Méthodes systémiques Merise, Axial,
Information Engineering  Méthodes objet OOD,
HOOD, OMT, OOSE, OOA/OOD, etc.
11
Concepts généraux
Conceptualiser obtenir un énoncé du
problème (utilisateurs)
Analyser spécifier le problème
Concevoir une solution informatique
Implémenter réaliser la solution
informatique
12
Concepts généraux
Étapes
Résultats
Planification Schéma directeur Analyse des
besoins Modèle des besoins Spécification
formelle ou analyse Modèle conceptuel Spécificat
ion technique ou conception Modèle
logique Implémentation Modèle
physique Intégration et Tests Rapport de
cohérence logique Validation du
système Rapport de conformité Maintenance et
évolution
Documentation et trace
13
Pourquoi lapproche objet ?

• Simplicité
• Facilité pour coder et réutiliser
• Modèle plus proche de la réalité
• description plus précise des combinaisons
• (données, opérations)
• décomposition basée sur classification
  naturelle
• facile à comprendre et à maintenir
• Stabilité
• de petites évolutions peuvent être prises en
  compte sans changements massifs

14
Pourquoi lapproche objet ?

• Omniprésence technique de lObjet
• dans les langages de programmation, les bases de
  données, les interfaces graphiques, ... et les
  méthodes danalyse et de conception.
• Universalité de lObjet
• la notion dobjet, plus proche du monde réel,
• est compréhensible par tous et facilite la
  communication entre tous les intervenants dun
  projet.

15

• Au début des années 90, une cinquantaine de
  méthodes objet, liées uniquement par un consensus
  autour didées communes (objets, classes,
  sous-systèmes, ...)
• Recherche dun langage commun unique utilisable
  par toute méthode objet
• dans toutes les phases du cycle de vie,
• compatible avec les techniques de réalisation
  actuelles.

16
UML (Unified Modeling Language)
UML
OMG
OOPSLA
Autres
OMT (Rumbaugh)
OOD (Booch)
OOSE (Jacobson)
17
Plan
Concepts objet et formalisme UML
18
Concepts généraux
Points de vue sur le système
Vue   structurelle
Vue Implémentation
Vue Cas dutilisation
Vue Architecture (déploiement)
Vue dynamique
lt------- Logique Physique ------gt
19
Concepts généraux
Un modèle est une représentation abstraite
d une réalité, il fournit une image simplifiée
du monde réel. Il permet - de comprendre et
visualiser (en réduisant la complexité) - de
communiquer (à partir d un  langage  commun
à travers un nombre restreint de concepts) -
de valider (contrôle de la cohérence, simuler,
tester )
20
Concepts généraux
Diagrammes (représentations graphiques de
modèle)
Diagrammes
Diagrammes de collaboration de séquences
de classes d instances
d'états
Diagrammes de déploiement de composants
Diagrammes Cas d utilisation
21
Concepts généraux
Démarche uniforme sur le cycle de vie Même
notation
Analyse
Conception
Implémentation
22
Formalisme UML - Concepts objet

• Modèle dutilisation
• Modèle structurel
• Modèle dynamique
• Modèle dimplémentation

23
Modèle dutilisation

• Les   USE CASE 
• Modèles descriptifs du point de vue des
  utilisateurs
• Scénarios fonctionnels
• Focus
• la manière dutiliser le système

24
Modèle dutilisation

• On part de l analyse des besoins .
• Deux concepts
• Acteur
• toute entité extérieure au système et
  interagissant avec celui-ci.
• acteurs humains, acteurs  machine  (système
  extérieur communiquant avec le système étudié)
• Use case
• toute manière dutiliser le système
• suite d événements vue du point de vue de
  l utilisateur

25
Modèle dutilisation

• Deux concepts
• Acteur
• Use case

Acteur (rôle 2)
 communicate 
 communicate 
26
Modèle dutilisation

• Les cas d utilisation peuvent être liés par des
  relations
• - dutilisation  include  (on utilise une
  partie commune)
• - de raffinement  extends  (on traite des
  exceptions)

Acteur (rôle 2)
 include 
- de généralisation/spécialisation  generalizes 
 extends 
27
Modèle dutilisation

• Délimiter le système
• - ce qui est extérieur et qui communique avec le
  système
• - ce qui est interne au système
• Définir les fonctionnalités du système du point
  de vue des utilisateurs
• Donner une description cohérente de toutes les
  vues que l on peut avoir du système

28
Modèle structurel

• En UML, le modèle structurel ou statique est
  décrit à l'aide de deux sortes de diagrammes
• Diagrammes de classes
• (description de tout ou d'une partie du système
  d'une manière abstraite, en termes de classes, de
  structure et d'associations).
• Diagrammes d'objets
• (description d'exemples de configuration de tout
  ou partie du système, en termes d'objets, de
  valeurs et de liens).

29
Modèle structurel
Les objets
Objets informatiques
Objets du monde réel
Comportement visible
État Interne caché
30
Modèle structurel
Objet Etat ---gt évolue au cours du
temps Comportement ---gt actions et
réactions Identité ----gt essence
Comportement influe sur l'état Etat réflète les
comportements passés
31
Modèle structurel
BD
Deux objets ou instances
Luc
Système
Alain
Discipline
Sophie
Professeur
32
Modèle structurel

• Première abstraction
• Une classe peut être vue
• - la description en intention d'un groupe
  d'objets
• ayant même structure (même ensemble d'attributs),
• ayant même comportement (mêmes opérations),
• ayant une sémantique commune.
• - la  génitrice  des objets ou instances
• - le  conteneur  (extension) de toutes ses
  instances

33
Modèle structurel
Classe Attributs (propriétés)
Instance Valeurs d'attributs (État)
Voiture
Titine Voiture
type 205 Peugeot rouge
 Est-instance-de 
type string marque string couleur string
34
Modèle structurel
Opérations et méthodes
nom de la classe
attributs
Voiture
type string marque string couleur string
opérations
Implémentations
repeindre(c Couleur) déplacer (d longueur)
Méthodes
35
Modèle structurel

• Un objet est instance d'une (seule) classe
• il se conforme à la description que celle-ci
  fournit,
• il admet une valeur pour chaque attribut déclaré
  à son attention dans la classe,
• il est possible de lui appliquer toute opération
  définie à son attention dans la classe.
• Tout objet admet une identité qui le distingue
  pleinement des autres objets
• il peut être nommé et être référencé par un nom
  (mais son identité ne se limite pas à ça).

36
Modèle structurel
Association / Lien (analogie Classe /
Instance)
Pays
Ville
a-pour-capitale
nom
nom
Association
a-pour-capitale
Pays nomFrance
Ville nom Paris
Lien
37
Modèle structurel
Association en général binaire (degré 2) mais
..
nom d'association
Adhérent
Exemplaire
lire
association ternaire
association binaire
DispositifDeLecture
38
Modèle structurel
Multiplicité et rôles d'une association
emploie
employeur
employé
Personne
Société
1..

nom date de nais. nSS adresse
nom adresse
travaille-pour
chef
0..1
encadre
1..
travailleur
39
Modèle structurel
Multiplicité
exactement 1
1
Classe
au plus 1
0..1
Classe
aucun, 1 ou plusieurs (défaut)
0..
Classe
1..
au moins 1
Classe
2..4
de 2 à 4
Classe
2,4
Classe
2 ou 4
40
Classe association
Modèle structurel
Possède-des-actions
Entreprise
Personne

1..
nom date de nais. adresse
capital
nom adresse
actionnaire
Ligne de portefeuille
quantité
41
Classe association
Modèle structurel
Autorisé sur
Utilisateur
Station de travail
1..
1..
nom
nom
Autorisation
priorité droits
1..
répertoire de rattachement
Répertoire
42
Modèle structurel
Association qualifiée
est_client
Banque
Personne
1..
1..
Dossier_C
num_client
est_client
Banque
Personne
num_client
0..1
1..
43
Modèle structurel
D autres  abstractions 
- associations particulières (composition /
agrégation) - spécialisation / généralisation
44
Modèle structurel
Composition
Association particulière Tout /partie
Fenêtre
0..2
Barre Ascenseur
Barre titre
Fond
Frontière
2
Titre
Bouton Ferm
Indicateur
Flèche
45
Modèle structurel
Agrégation
Sémantique Collection/Élément
Pays
1
Forêt
1..n
1
Région
1
1..n
Arbre
1..n
Département
46
Modèle structurel
Composition / Agrégation
Contraintes - Exclusivité/Partage -
Dépendance/Indépendance Propagation/Diffusion
47
Modèle structurel
Généralisation / Spécialisation
Mécanismes dinférences intellectuelles de
caractéristiques Soit on affine
(spécialisation) Soit on abstrait
(généralisation) Sémantique Point de vue
ensembliste Point de vue logique
48
Modèle structurel
Généralisation / Spécialisation
49
Modèle structurel
Généralisation / Spécialisation
Équipement
Type d'équipement
...
Réservoir
Pompe
Échangeur
Type de pompe
Type de réservoir
...
Pompe Cent.
Pompe Imm.
Réservoir Press.
...
50
Modèle structurel
Généralisation / Spécialisation multiple
Véhicule
Véhicule aquatique
Véhicule terrestre
Auto
Véhicule amphibie
Bateau
51
Modèle structurel
Composition/Agrégation ou généralisation ?
Agrégation - lien entre instances
- un arbre d'agrégation est composé d'objets
qui sont parties d'un objet
composite Généralisation - lien entre
classes
52
Modèle structurel
Généralisation / Spécialisation

• Une sous-classe hérite de sa super-classe la
  description des instances
• les déclarations d'attributs,
• les définitions d'opérations,
• les associations définies sur la super-classe,
• les contraintes (on en parle plus tard).
• Une sous-classe peut redéfinir de façon plus
  spécialisée une partie ou la totalité de la
  description  héritée , mais il n'y a pas
  d'exception à l'héritage.

53
Modèle structurel
Classes abstraites

• Une classe abstraite est une classe non
  instanciable, c'est à dire qu'elle n'admet pas
  d'instances directes.
• Une classe abstraite est une description d'objets
  destinée à être  héritée  par des classes plus
  spécialisées.
• Pour être utile, une classe abstraite doit
  admettre des classes descendantes concrètes.
• La factorisation optimale des propriétés communes
  à plusieurs classes par généralisation nécessite
  le plus souvent l'utilisation de classes
  abstraites.

54
Modèle structurel
Opérations abstraites

• Une opération abstraite est une opération
  n'admettant pas d'implémentation au niveau de
  la classe dans laquelle est déclarée, on ne peut
  pas dire comment la réaliser.
• Les opérations abstraites sont particulièrement
  utiles pour mettre en œuvre le polymorphisme.
• Toute classe concrète sous-classe d'une classe
  abstraite doit concrétiser toutes les
  opérations abstraites de cette dernière.

55
Modèle structurel
Classes abstraites
FormeGéométrique
classe abstraite
centre Point
opération abstraite
dessiner()déplacer(delta Vecteur)
classe abstraite (dessiner() est héritée et non
concrétisée)
classe concrète
Polygone
Ellipse
régulier Boolean
grandDiam Vecteur petitDiam Vecteur
Polygone utile que si spécialisée

opération concrétisée
dessiner()
56
Modèle structurel
Interfaces
Deux notations pour l'utilisation d'une interface
réalise
MenuPopUp
uses
ApplicationFenêtrée
uses
MenuPopUp
ApplicationFenêtrée
BlocDeChoix
57
Modèle structurel
Les contraintes

• Les contraintes sont des prédicats, pouvant
  porter sur plusieurs éléments du modèle statique,
  qui doivent être vérifiés à tout instant.
• Les contraintes permettent de rendre compte de
  détails à un niveau de granularité très fin dans
  un diagramme de classe. Elles peuvent exprimer
  des conditions ou des restrictions.
• En UML, les contraintes sont exprimées sous forme
  textuelle, entre accolades et de préférence en
  OCL (Object Constraint Language).
• Les contraintes sont héritées.

58
Modèle structurel
Les contraintes
Exemples de contraintes sur associations
contrainte entre 2 associations
Chemin
membreDe
Personne
Comité



subset

1
ordered
1..
contrainte sur extrémité d'association
Arête
59
Modèle structurel
Les contraintes
actif passif
Exemple de contraintes à différents niveaux
contrainte sur classe
subordonné
employeur
Personne
Société

1..
0..1
Personne.employeur Personne.chef.employeur
actif Real value ? 0 passif Real
chef
0..1
diriger
contrainte sur attribut
contrainte sur 2 associations
60
Modèle structurel
Quelques compléments de notation
stéréotype
instance of
relation de dépendance

• Un stéréotype est un label qui permet d'apporter
  une précision supplémentaire à un élément de
  notation (classe, relation, )

• Une relation de dépendance peut être exprimée
  entre deux éléments de notation. Elle est le plus
  souvent stéréotypée. Il y a plusieurs stéréotypes
  de dépendance uses, instance of,

61
Modèle dynamique
Décrit les interactions entre objets et
les changements au cours du temps
- Aspects temporels, comportementaux Contrôle
- Stimuli des objets et leurs réponses
62
Modèle dynamique
Événement et État
État d'un objet valeurs de ses attributs et
de ses liens au cours du temps un objet peut
changer d'état Événement stimuli d'un objet
vers un autre objet
63
Modèle dynamique
diagrammes de séquences diagrammes
états-transitions diagrammes de
collaboration diagrammes d'activités (non
traités)
64
lappelant soulève le combinéla tonalité est
déclenchéelappelant compose le numéro 6la
tonalité sarrêtelappelant tape le chiffre
7lappelant tape le chiffre 1lappelant tape le
chiffre 4lappelant tape le chiffre 8lappelant
tape le chiffre 6lappelant tape le chiffre
6lappelant tape le chiffre 2le téléphone
appelé commence à sonnerla tonalité de sonnerie
commence dans le téléphone appelantlappelé
décrochele téléphone de lappelé cesse de
sonnerla tonalité de sonnerie cesse dans le
téléphone appelantles téléphones sont
connectéslappelé raccrocheles téléphones sont
déconnectéslappelant raccroche
Modèle dynamique
Scénarios Exemple
65
Modèle dynamique
Diagrammes de séquences
Appelant Personne
Ligne Téléphonique
Appelé Personne
lappelant soulève le combiné
la tonalité est déclenchée
lappelant compose le numéro 6
la tonalité sarrête
lappelant compose les numéros
le téléphone appelé commence à sonner
lappelant entend la sonnerie
lappelé décroche
le téléphone de lappelé cesse de sonner
la sonnerie cesse
connexion établie
connexion établie
lappelé raccroche
connexion interrompue
connexion interrompue
lappelant raccroche
66
Modèle dynamique
Les messages
Types
Synchronisation
simple synchrone dérobant minuté asynchrone
constructeurs destructeurs sélecteurs modificateu
rs itérateurs
67
Modèle dynamique
La ligne de vie
C1
 create 
op
Création par le message  create 
Activation de l objet qui exécute une opération
op
destroy
Destruction par un autre objet
68
Modèle dynamique
Diagrammes de collaboration Vue globale des
événements entre classes
Appelant Personne
Ligne téléphonique
Appelé Personne
1, 3, ..
5, ...
6,..
2, 4
69
Modèle dynamique
Diagrammes d'États Représentation
graphique état et événement
Graphe Nœud État Arc Transition nommées par
événement Une séquence d'événements chemin
dans le graphe
70
Modèle dynamique
Événement
pas de durée concurrence d'événements
classes d'événements - sans
attributs - avec attributs
départ vol (compagnie, num_vol, ville)
a pour instances
AirFrance vol 124 de Paris
Alitalia vol 352 de Rome
71
Modèle dynamique
État
abstraction des valeurs d'attributs et de liens
d'un objet  un état a une durée (intervalle de
temps entre deux événements) spécifie la
réponse à un événement état et événement sont
duaux un événement sépare deux états
un état sépare deux événements
72
Modèle dynamique
Etat initial
Diagrammes d'États
Libre
décroche
Tonalité
numérote
En numérotation
Exemple incomplet
numéro existant
En connexion
recherche réussie
Sonnerie
réponse appelé
Connectée
raccroché
raccroche
Déconnectée
73
Modèle dynamique
Diagrammes d'États
Transitions gardées
demande
création
fermeture
fermeture accomplie
en création
Ouvert
Fermé
retrait (s)
dépôt(s)
Solde gt0
Solde gt0
Créditeur
En retrait
En dépôt
Solde 0
Solde 0
Débiteur
74
Modèle dynamique
Opération Activité / Action
Événement 1 Cond1 / Action1 (attrib)
État 1 faire Activité 1
État 2 ...
75
Modèle dynamique
Opération elle peut être attachée à une
transition ou à un état. elle est exécutée
en réponse à l'événement ou à l'état.

Action opération instantanée, non
interruptible, souvent utilisée pour faire des
mises à jour de valeurs, attachée à une
transition. Envoyer un événement est une
action Activité opération qui prend du temps,
interruptible par un événement, perpétuelle ou
finie, nécessairement attachée à un état.

76
Modèle dynamique
Généralisation
permet une meilleure structuration des
diagrammes d'états Un objet dans un état du
diagramme général doit être dans un des états du
diagramme imbriqué (relation ou entre les
états)
E1
E4
E3
E2
E6
E5
77
Modèle dynamique
Agrégation
une classe "agrégat" aura un état défini par
l'agrégation des états de ses composants. Agréga
tion concurrente (relation et)
Ecomp1
Ecomp2
78
Modèle dynamique
Heuristiques délaboration du modèle dynamique
Utiliser les scénarios pour
commencer à construire les
diagrammes d'état Ne construire un
diagramme d'état que pour les classes
au comportement temporel significatif
Contrôler la cohérence Utiliser
des diagrammes structurés
79
Modèle d implémentation
Les packages
Un package ou sous-système est un regroupement
logique de classes, associations, contraintes
.. Un sous-système est généralement défini par
les services qu il rend Les liens entre
sous-systèmes sont des liens de dépendance Les
 packages  servent à structurer une application
Ils sont utilisés dans certains LPO (Java) ce
qui assure une bonne  traçabilité  de
l analyse à l implémentation
80
Modèle d implémentation
Les packages
Liens de dépendance
Classes avec fort couplage  sémantique