M - PowerPoint PPT Presentation

Loading...

PPT – M PowerPoint presentation | free to view - id: 2a6c86-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

M

Description:

Introduction - G n ralit s sur les m thodes objet. Concepts objet et formalisme UML ... Taille et complexit des syst mes importantes et croissantes ... – PowerPoint PPT presentation

Number of Views:104
Avg rating:3.0/5.0
Slides: 95
Provided by: thrseli
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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é
About PowerShow.com