M

1
Méthodologie objetet IG ?

• T. Libourel
• libourel_at_lirmm.fr

2
Plan
Introduction - Généralités sur les méthodes
objet
Concepts objet et formalisme UML
Adéquation Discussion
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
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

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

12

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

13
UML (Unified Modeling Language)
UML
OMG
OOPSLA
Autres
OMT (Rumbaugh)
OOD (Booch)
OOSE (Jacobson)
14
UML 1.3
Version béta - fin 99
Version intermédiaire non publiée
UML 1.2
UML 1.1
Standardisation à lOMG - Novembre 97
UML 1.0
Soumission à lOMG - Janvier 97
Commentaires du public
UML 0.9 0.91
Juin 96 puis OOPSLA96
OOPSLA95
Unified Method 0.8
Booch93
OMT-2
Autres méthodes
Booch91
OMT-1
OOSE
Partenaires
15
Plan
Concepts objet et formalisme UML
16
Concepts généraux
Un modèle est une représentation abstraite
dune 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 )
17
Concepts généraux
Les modèles d'UML
modèle des classes ------gt
statique modèle des états
------gt dynamique des objets modèle des cas
d'utilisation ------gt besoins
utilisateur modèle d'interaction
------gt scénarios et flots de messages modèle
de réalisation ------gt unités de
travail modèle de déploiement ------gt
répartition des processus
18
Concepts généraux
La perception des modèles Les vues graphiques
(diagrammes )
diagrammes de classes diagrammes
d'objets diagrammes de séquences diagrammes de
collaboration diagrammes états-transitions diagra
mmes d'activités diagrammes de cas
d'utilisation diagrammes de composants diagrammes
de déploiement
19
Concepts généraux
Définir une architecture . divers points de
vue sur le système
Vue   structurelle
Vue Implémentation
Vue Cas d utilisation
Vue Architecture (déploiement)
Vue dynamique
lt------- Logique Physique ------gt
20
Formalisme UML - Concepts objet

• Modèle d utilisation
• Modèle structurel
• Modèle dynamique
• Modèle d implémentation

21
Modèle d utilisation

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

22
Modèle d utilisation

• Deux concepts
• Acteur
• Use case

Acteur (rôle 2)
23
Modèle d utilisation

• Les cas d utilisation peuvent être liés par des
  relations
• - d utilisation  use 
• - de raffinement  extend 

Acteur (rôle 2)
 use 
 extend 
24
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).

25
Modèle structurel
Les objets
Objets informatiques
Objets du monde réel
Comportement visible
État Interne caché
26
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
27
Modèle structurel
BD
Deux objets ou instances
Luc
Système
Alain
Discipline
Sophie
Professeur
28
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

29
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
30
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
31
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).

32
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
33
Modèle structurel
Association en général binaire (degré 2) mais
..
nom d'association
Adhérent
Exemplaire
lire
association ternaire
association binaire
DispositifDeLecture
34
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
35
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
36
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é
37
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
38
Classe association
Modèle structurel

• Une classe d'association permet de modéliser une
  association par une classe.
• Les liens d'une telle association sont alors des
  objets instances de cette classe.
• À ce titre, ils admettent une valeur pour tout
  attribut déclaré dans la classe d'association et
  on peut leur appliquer toute opération définie
  dans celle-ci.
• En tant que classe, une classe d'association peut
  à son tour être associée à d'autres classes
  (voire à elle-même par une association réflexive).

39
Modèle structurel
D autres  abstractions 
- associations particulières (composition /
agrégation) - spécialisation / généralisation
40
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
41
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
42
Modèle structurel
Composition / Agrégation
Contraintes - Exclusivité/Partage -
Dépendance/Indépendance Propagation/Diffusion
43
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
44
Modèle structurel
Généralisation / Spécialisation
45
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.
...
46
Modèle structurel
Généralisation / Spécialisation multiple
Véhicule
Véhicule aquatique
Véhicule terrestre
Auto
Véhicule amphibie
Bateau
47
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
48
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.

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

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

51
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()
52
Modèle structurel
Interfaces

• Une interface est une collection d'opérations
  utilisée pour spécifier un service offert par une
  classe.
• Une interface être vue comme une classe sans
  attributs et dont toutes les opérations sont
  abstraites.
• Une interface est destinée à être réalisée par
  une classe (celle-ci en hérite toutes les
  descriptions et concrétise les opérations
  abstraites).
• Une interface peut en spécialiser une autre, et
  intervenir dans des associations avec d'autres
  interfaces et d'autres classes.

53
Modèle structurel
Interfaces
interface BlocDeChoix
interface
BlocDeChoix
opérations abstraites
1..
setDefault(o Option) getChoice() Option
Option
choix
réalisation
choix
1..
opérations concrétisées
MenuPopUp
BoutonPopUp
1..
setDefault(o String) getChoice() String
setDefault(o Bouton) getChoice() Bouton
Bouton
choix
54
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
55
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.

56
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
57
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
58
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,

59
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
60
Modèle dynamique
diagrammes de collaboration diagrammes de
séquences diagrammes états-transitions
diagrammes d'activités (non traités)
61
Modèle dynamique
La communication
Systèmes informatiques Société d'objets
travaillant en synergie pour réaliser les
fonctions de l'application
Communication
Agent
Acteur
Serveur
message
62
Modèle dynamique
Les messages
Types
Synchronisation
simple synchrone dérobant minuté asynchrone
constructeurs destructeurs sélecteurs modificateu
rs itérateurs
63
Modèle dynamique
Diagramme de collaboration
2 M2
B
1 M1
5 M5
4 M4
A
C
6 M6
message
3 M3
64
Modèle dynamique
Diagramme de séquence
C
B
A
M1
M2
M3
M4
M5
M6
65
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
66
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
67
Modèle dynamique
Diagramme d état
Événement 1 Cond1 / Action1 (attrib)
État 1 faire Activité 1
État 2 ...
É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
68
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
69
Modèle d implémentation
Les packages
Liens de dépendance
Classes avec fort couplage  sémantique 
70
Plan
Adéquation Discussion
71
Adéquation aux BD  objet
Classes vs Types persistants vs éphémères
Points dentrée (racine de persistance)
Regroupements
Persistance
LDD, LMD, L Hôte équivalents LPO Langage de
requête like SQL Transactions
LDD, LMD, L Hôte
72
Adéquation aux BD  classiques
Traduction comme précédemment d. structurels
--gt schémas d. dynamiques --gt requêtes et
traitements
applicatifs divers Mais règles de  passage 
73
Sémantique des informations spatiales
Multiplicité des perceptions Visions discrète
vs continue Échelles
74
Sémantique des informations spatiales
Multiplicité des perceptions
polyligne
graphe
Cadastre
Trafic routier
Rue
Réseaux souterrains
Équipement
volume
surface
75
Sémantique des informations spatiales
Visions discrète vs continue température dens
ités de population, ...
Échelles pas un simple rapport taille du
support/terrain granularité de perception
76
Représentations

• Géométrie euclidienne
• point (dim 0) ligne (dim 1)
• aire (dim 2) volume (dim 3)
• Théorie des graphes
• nœud, arête, arc, chaîne
• Topologie
• relations spatiales

77
Représentations

• Géométrie euclidienne
• point (dim 0) ligne (dim 1)
• aire (dim 2) volume (dim 3)

A-pour-extrémité-gt
Segment
Point
0..1
2..2
X Y
Est-sur booleen
78
Représentations

• Géométrie euclidienne
• point (dim 0) ligne (dim 1)
• aire (dim 2) volume (dim 3)

ordre
Polyligne
Point
0..1
2..n
fermée
X Y
2..2
Segment
0..1
Est-sur booleen
1..n
0..1
79
Représentations

• Géométrie euclidienne
• point (dim 0) ligne (dim 1)
• aire (dim 2) volume (dim 3)

ordre
Polygone
Point
0..1
3..n
X Y
2..2
Segment
0..1
Appartient bool
3..n
2..2
80
Représentations

• Géométrie euclidienne
• point (dim 0) ligne (dim 1)
• aire (dim 2) volume (dim 3)

Polygone
Point
1..1
début
0..1
0..n
X Y
fin
Segment
1..1
1..2
Appartient bool
orientation
3..n
0..n
81
Représentations

• Théorie des graphes
• nœud, arête, arc, chaîne

Est-relié-à
0..n
0..n
Nœud
Arête
2..2
1..n
délimite
82
Représentations

• Théorie des graphes
• nœud, arête, arc, chaîne

Est-relié-à
0..n
0..n
Nœud
origine
Arc
1..1
1..n
extrémité
1..n
1..1
83
Représentations

• Topologie
• relations spatiales
• Adjacence, Inclusion, Proximité

84
Représentations

• Raster

1
1
1
1
1
1
1
3
1
1
3
3
3
2
2
3
2
2
2
3
3
2
2
2
3
3
3
3
2
2
85
Méthodes objet pour les SIG
GeoOOA (Kösters, Pagel, Six)
NETWORK
GEOCLASS
REGION
LINE
POINT
RASTER
opérations (intersection, inclusion, etc.)
86
Méthodes objet pour les SIG
Geo-OM (Tryfona, Pfoser, Hadzilacos)
SPACE POSITIONS classe agrégat construite sur
les classes SHAPE, SIZE, LOCATION, ORIENTATION
Classes
POSITIONS
is-located-at
1,n
GEOGRAPHIC OBJECT
1
at_spatial
SPACE
87
Méthodes objet pour les SIG
MADS (Parent, Spaccapietra, Zimanyi)
Objets spatiaux
Objets spatiaux simples
Objets spatiaux complexes
Ensemble de Points Ensemble de Lignes Ensemble de
Lignes orientées Aire complexe
Point Ligne Ligne orientée Aire simple
88
Méthodes objet pour les SIG
MADS
PST
Commune
Remembrement
source
est_composée_de
Partage
cible
PST
PST
Union
Parcelle
PST
Re-allocation
89
Méthodes objet pour les SIG
PERCEPTORY (Bedard U Laval Quebec)
UML Pictogrammes (Langage Visuel)
PST
90
Méthodes objet pour les SIG
POLLEN (Gayte, Libourel, Cheylan, Lardon)
Entité géographique
Thème
Spatial
Identification Essence
1..
1..
Classes opaques Spatiales Point, Ligne,
Aire Temporelles
Instant, Intervalle
91
Discussion
Des bienfaits de l encapsulation .
Données
Encapsulation
Messages
Opérations

• Proposer un service et réagir aux messages

92
Discussion
La méta-modélisation
Langage pour spécifier tout métamodèle
Meta-Class, Meta-Attribut, etc
Meta-Meta Modèle
Class, Attribut, etc
Langage pour spécifier un modèle
Meta-Modèle
Langage pour spécifier un domaine d information
Parcelle, Surface, etc
Modèle
A120, 50, etc
Définition spécifique d un domaine
Objets utilisateur
93
Discussion
Vers des  framework  ?
TAD spatiaux
Point Ligne Zone
TAD temporels
Instant Intervalle Ensemble dinstants
Ensemble dintervalles
94
Discussion
Mise en œuvre
SIG outils SGBD spatiaux
futur ..... SGBD spatio-temporels .....
Interopérabilité