Méthodologie objet et IG ?

Présentation au sujet: "Méthodologie objet et IG ?"— Transcription de la présentation:

1 Méthodologie objet et IG ?
T. Libourel

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 l’interface avec le métier (domaine d’application)

6 Évolution des applications
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 d’analyse 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) s’appuie sur un formalisme de représentation qui facilite la communication, l’organisation et la vérification produit des documents (modèles) qui facilitent les retours sur conception et l’évolution des applications

10 Pourquoi l’approche 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 l’approche objet ?
Omniprésence technique de l’Objet dans les langages de programmation, les bases de données, les interfaces graphiques, ... et les méthodes d’analyse et de conception. Universalité de l’Objet la notion d’objet, plus proche du monde réel, est compréhensible par tous et facilite la communication entre tous les intervenants d’un projet.

12 Au début des années 90, une cinquantaine de méthodes objet, liées uniquement par un consensus autour d’idées communes (objets, classes, sous-systèmes, ...) Recherche d’un 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)
OMG OOPSLA Autres OOD (Booch) OMT (Rumbaugh) OOSE (Jacobson)

14 Version intermédiaire non publiée UML 1.2
Version béta - fin 99 UML 1.3 Version intermédiaire non publiée UML 1.2 Standardisation à l’OMG - Novembre 97 UML 1.1 Soumission à l’OMG - Janvier 97 UML 1.0 Commentaires du public Juin 96 puis OOPSLA’96 UML 0.9 & 0.91 OOPSLA’95 Unified Method 0.8 Booch’93 OMT-2 Autres méthodes Booch’91 OMT-1 OOSE Partenaires

15 Plan • Concepts objet et formalisme UML

16 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 …)

17 Concepts généraux Les modèles d'UML
modèle des classes > statique modèle des états > dynamique des objets modèle des cas d'utilisation > besoins utilisateur modèle d'interaction > scénarios et flots de messages modèle de réalisation > unités de travail modèle de déploiement > 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 diagrammes 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 < Logique Physique >

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) Acteur (rôle 1) « 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 ---> évolue au cours du temps
Comportement ---> actions et réactions Identité > essence Comportement influe sur l'état Etat réflète les comportements passés

27 Modèle structurel BD Luc Système Alain : Discipline Sophie
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 Instance Attributs (propriétés)
Valeurs d'attributs (État) Voiture Titine :Voiture « Est-instance-de » type =205 Peugeot rouge type : string marque : string couleur : string

30 Modèle structurel Opérations et méthodes nom de la classe Voiture
attributs 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 nom=France :Ville nom = Paris Lien

33 Modèle structurel Association en général binaire (degré = 2) mais ..
nom d'association emprunte Adhérent Exemplaire lire association ternaire association binaire DispositifDeLecture

34 Modèle structurel Multiplicité et rôles d'une association emploie
employeur employé Société Personne 1..* * nom adresse nom date de nais. n°SS adresse travaille-pour chef 0..1 encadre 1..* travailleur

35 aucun, 1 ou plusieurs (défaut)
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 Modèle structurel Classe association Possède-des-actions Entreprise
Personne * 1..* nom adresse capital actionnaire nom date de nais. adresse Ligne de portefeuille quantité

37 Modèle structurel Classe association Autorisé sur Utilisateur
1..* 1..* Station de travail nom nom Autorisation priorité droits 1..* répertoire de rattachement Répertoire

38 Modèle structurel Classe association
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 D ’autres « abstractions »
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 titre Fond Frontière Barre Ascenseur 2 Titre Bouton Ferm Flèche Indicateur

41 Modèle structurel Agrégation Sémantique Collection/Élément Pays Forêt
1 Forêt 1..n 1 Région 1..n 1 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 d’infé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 Personne nom adresse
Étudiant num_carte Enseignant grade enseigner {disjoint}

45 Modèle structurel ... ... ... Généralisation / Spécialisation
Équipement Type d'équipement Pompe ... Réservoir É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 ?
- 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 Polygone Ellipse
classe abstraite FormeGéométrique 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 Polygone utile que si spécialisée régulier : Boolean grandDiam : Vecteur petitDiam : Vecteur 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 BlocDeChoix BlocDeChoix Option String
opérations abstraites setDefault(o : Option) getChoice() : Option 1..* Option choix String réalisation 1..* choix opérations concrétisées MenuPopUp BoutonPopUp setDefault(o : String) getChoice() : String setDefault(o : Bouton) getChoice() : Bouton 1..* Bouton choix

54 Deux notations pour l'utilisation d'une interface
Modèle structurel Interfaces Deux notations pour l'utilisation d'une interface setDefault(o : Option) getChoice() : Option «interface» BlocDeChoix réalise MenuPopUp «uses» ApplicationFenêtrée utilisation interface classe utilisatrice «uses» ApplicationFenêtrée MenuPopUp 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} préside 1 * 1..* {ordered} contrainte sur extrémité d'association Arête

57 Modèle structurel Les contraintes
Exemple de contraintes à différents niveaux { actif = passif } contrainte sur classe subordonné employeur Personne Société * 1..* 0..1 0..1 chef { Personne.employeur = Personne.chef.employeur } actif : Real {value  0} passif : Real diriger contrainte sur attribut contrainte sur 2 associations

58 relation de dépendance
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 modificateurs itérateurs

63 Modèle dynamique Diagramme de collaboration 2: M2 B 1: M1 5: M5 4: M4
message 3: M3

64 Modèle dynamique Diagramme de séquence B C A M1 M2 M3 M4 M5 M6

65 Modèle dynamique La ligne de vie :C1 « create » op « destroy »
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 d’entré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 --> schémas d. dynamiques --> 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 densités de population, ... Échelles pas un simple rapport taille du support/terrain granularité de perception

76 Représentations Géométrie euclidienne Théorie des graphes Topologie
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é-> 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 Nœud
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 Nœud Arc
Est-relié-à 0..n 0..n Nœud origine Arc 1..1 1..n extrémité 1..1 1..n

83 Représentations Topologie relations spatiales
Adjacence, Inclusion, Proximité …

84 Représentations Raster 1 1 1 1 1 1 1 1 1 3 3 3 2 2 2 2 3 3 2 2 2 2 3 3

85 Méthodes objet pour les SIG
GeoOOA (Kösters, Pagel, Six) GEOCLASS NETWORK POINT LINE REGION 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 cible Partage PST Union PST 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 Spatial Identification Essence Thème 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 Meta-Class,
tout métamodèle Meta-Class, Meta-Attribut, etc Meta-Meta Modèle Langage pour spécifier un modèle Class, Attribut, etc Meta-Modèle Langage pour spécifier un domaine d ’information Parcelle, Surface, etc Modèle Définition spécifique d ’un domaine A120, 50, etc Objets utilisateur

93 Discussion Vers des « framework » ? TAD spatiaux TAD temporels
Point Ligne Zone TAD temporels Instant Intervalle Ensemble d’instants Ensemble d’intervalles

94 Discussion Mise en œuvre SIG outils SGBD spatiaux
futur SGBD spatio-temporels ..... Interopérabilité