Télécharger la présentation
La présentation est en train de télécharger. S'il vous plaît, attendez
1
Survol du formalisme UML
Méthodologie objet Survol du formalisme UML T. Libourel Avec la complicité de M Huchard
2
Plan • Introduction - Généralités sur les méthodes objet
• Concepts objet et formalisme UML • De l ’analyse à la réalisation aspects LPO aspects SI / BD
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
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écification 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
Concepts généraux • Cycles de développement - en cascade - en V
- en spirale - tridimensionnel
14
Modèle de cycle en cascade
Analyse Conception Implémentation Tests Maintenance
15
Modèle de cycle en cascade
Organisation séquentielle des phases du cycle de vie Une phase est structurée en un ensemble d'activités pouvant s'exécuter en parallèle par plusieurs personnes Le passage d'une phase à la suivante ne se fait que lorsque les sorties de la première ont été fournies
16
Modèle de cycle en cascade
Pour : Organisation simple et directe Contre : Retours sur les phases précédentes difficiles (rupture entre les phases) Visualisation et validation tardive
17
Modèle de cycle en V Expression des besoins Validation des besoins
Spécification fonctionnelle Validation fonctionnelle Conception du système Tests du système Conception des composants Tests des composants Implémentation
18
Modèle de cycle en V Approche descendante dans les phases précédents l’implémentation : on décompose le système au fur et à mesure qu’on le construit Approche ascendante dans les phases suivantes : on recompose le système en testant les parties Hiérarchie de tests : les différents tests provoquent un retour d’information directement sur la phase permettant de corriger les erreurs.
19
Modèle de cycle en V Pour : Contre :
Décomposition du système en sous-système Hiérarchie de tests et retours facilités Vérification ascendante Contre : Validation en fin de cycle (erreurs d’analyse coûteuses)
20
Modèle de cycle en spirale
Analyse Conception Spécifications Besoins Implémentation Validation Tests
21
Modèle de cycle en spirale
Modèle itératif On passe par toutes les phases du cycle de vie plusieurs fois Modèle incrémental On améliore à chaque passage Un passage peut aussi bien permettre d’évaluer un nombre réduit de fonctionnalités ou l’organisation générale du système de façon non détaillée
22
Modèle de cycle en spirale
Pour : Réalisation de plusieurs prototypes (versions) avant la réalisation du système réel (définitif) Validation progressive et précoce Souplesse dans le choix des prototypes Contre : Mise en œuvre parfois coûteuse Possibilité de divergence, nombre de prototypes difficile à déterminer
23
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
24
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.
25
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.
26
UML (Unified Modeling Language)
OMG OOPSLA Autres OOD (Booch) OMT (Rumbaugh) OOSE (Jacobson)
27
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
28
Plan • Concepts objet et formalisme UML
29
Concepts généraux Points de vue sur le système Vue structurelle Vue
Implémentation Vue Cas d’utilisation Vue Architecture (déploiement) Vue dynamique < Logique Physique >
30
Concepts généraux Quatre points de vue Types d'objets
et leurs relations Modèle structurel Modèle déploiement Modèle implémentation Stimuli des objets et leurs réponses Modèle Dynamique
31
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 …)
32
Concepts généraux Diagrammes (représentations graphiques de modèle)
de collaboration de séquences de classes d ’instances d'états Diagrammes de déploiement de composants Diagrammes Cas d ’utilisation
33
Concepts généraux Démarche uniforme sur le cycle de vie Même notation
Analyse Conception Implémentation
34
Formalisme UML - Concepts objet
Modèle d’utilisation Modèle structurel Modèle dynamique Modèle d’implémentation
35
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
36
Modèle d’utilisation 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 d’utiliser le système suite d ’événements vue du point de vue de l ’utilisateur
37
Modèle d’utilisation Deux concepts Acteur Use case Acteur (rôle 2)
« communicate » « communicate »
38
Modèle d’utilisation Les cas d ’utilisation peuvent être liés par des relations - d’utilisation « include » (on utilise une partie commune) - de raffinement « extends » (on traite des exceptions) Acteur (rôle 2) Acteur (rôle 1) - de généralisation/spécialisation « generalizes » « include » « extends »
39
Modèle d’utilisation 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
40
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).
41
Modèle structurel Les objets Objets informatiques Objets du monde réel
Comportement visible État Interne caché
42
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
43
Modèle structurel BD Luc Système Alain : Discipline Sophie
Deux objets ou instances Luc Système Alain : Discipline Sophie : Professeur
44
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
45
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
46
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
47
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).
48
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
49
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
50
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
51
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
52
Modèle structurel Conseils pour la modélisation d'association
- verbes candidats possibles - ne pas "dériver vers la conception" (pointeurs ou attributs référentiels)
53
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é
54
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
55
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).
56
Modèle structurel Association qualifiée est_client Banque Personne
1..* 1..* Dossier_C num_client est_client Banque Personne num_client 1..* 0..1
57
D ’autres « abstractions »
Modèle structurel D ’autres « abstractions » - associations particulières (composition / agrégation) - spécialisation / généralisation
58
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
59
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
60
Modèle structurel Composition / Agrégation Contraintes
- Exclusivité/Partage - Dépendance/Indépendance Propagation/Diffusion
61
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
62
Modèle structurel Généralisation / Spécialisation Personne nom adresse
Étudiant num_carte Enseignant grade enseigner {disjoint}
63
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. ...
64
Modèle structurel Généralisation / Spécialisation multiple Véhicule
Véhicule aquatique Véhicule terrestre Auto Véhicule amphibie Bateau
65
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
66
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.
67
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.
68
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.
69
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()
70
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.
71
Modèle structurel Interfaces BlocDeChoix Option String MenuPopUp
opérations abstraites setDefault(o : Option) getChoice() : Option 1..* Option choix String réalisation 1..* choix opérations concrétisées MenuPopUp MenuBouton setDefault(o : String) getChoice() : String setDefault(o : Bouton) getChoice() : Bouton 1..* Bouton choix
72
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
73
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.
74
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
75
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
76
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», …
77
Modèle structurel Heuristiques d’élaboration du modèle structurel • Bien comprendre le problème • Faire simple • Bien choisir les noms • Bien expliciter les associations • Ne pas trop “généraliser” • Relire • Documenter De nombreuses révisions sont nécessaires !
78
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
79
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
80
Modèle dynamique • diagrammes de séquences
• diagrammes états-transitions • diagrammes de collaboration • diagrammes d'activités (non traités)
81
Modèle dynamique Scénarios Exemple
l’appelant soulève le combiné la tonalité est déclenchée l’appelant compose le numéro 6 la tonalité s’arrête l’appelant tape le chiffre 7 l’appelant tape le chiffre 1 l’appelant tape le chiffre 4 l’appelant tape le chiffre 8 l’appelant tape le chiffre 6 l’appelant tape le chiffre 6 l’appelant tape le chiffre 2 le téléphone appelé commence à sonner la tonalité de sonnerie commence dans le téléphone appelant l’appelé décroche le téléphone de l’appelé cesse de sonner la tonalité de sonnerie cesse dans le téléphone appelant les téléphones sont connectés l’appelé raccroche les téléphones sont déconnectés l’appelant raccroche
82
Modèle dynamique Diagrammes de séquences Appelant : Personne
:Ligne Téléphonique Appelé : Personne l’appelant soulève le combiné la tonalité est déclenchée l’appelant compose le numéro 6 la tonalité s’arrête l’appelant compose les numéros l’appelant entend la sonnerie le téléphone appelé commence à sonner l’appelé décroche la sonnerie cesse le téléphone de l’appelé cesse de sonner connexion établie connexion établie l’appelé raccroche connexion interrompue connexion interrompue l’appelant raccroche
83
Modèle dynamique Les messages Types Synchronisation simple synchrone
dérobant minuté asynchrone constructeurs destructeurs sélecteurs modificateurs itérateurs
84
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
85
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
86
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
87
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
88
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
89
Modèle dynamique Diagrammes d'États Exemple incomplet Etat initial
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
90
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 >0] [Solde >0] Créditeur En retrait En dépôt [Solde ≤0] Débiteur [Solde ≤0]
91
Modèle dynamique Opération Activité / Action
Événement 1 [Cond1] / Action1 (attrib) État 1 faire : Activité 1 État 2 ...
92
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.
93
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 E3 E4 E2 E5 E6
94
Modèle dynamique Agrégation
une classe "agrégat" aura un état défini par l'agrégation des états de ses composants. Agrégation concurrente (relation et) Ecomp1 Ecomp2
95
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
96
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
97
Modèle d ’implémentation
Les packages Liens de dépendance Classes avec fort couplage « sémantique »
98
Plan • De l ’analyse à la réalisation
du modèle objet ….. à la programmation objet du modèle objet …… aux BD
99
Du modèle objet ... à la programmation
Classes Attributs, Opérations > Champs, Méthodes Accesseurs L/E Constructeurs, Destructeurs
100
Du modèle objet ... à la programmation
Classes note (peut contenir un complément de description, un commentaire, …) adhérent de la bibliothèque valeurs multiples Adhérent valeur initiale privé - adresse : String = 'adresse inconnue' - numeroINSEE[6] : Integer type d'attribut protégé # changeAdresse(nouvelleAdresse : String) + cotisationAJour() : Boolean type de paramètre public type du résultat de l'opération
101
Du modèle objet ... à la programmation
Classes Classes > classes abstraites vs classes concrètes C++ méthodes virtuelles pures Java Interfaces Héritage par réalisation
102
Du modèle objet ... à la programmation
Données Encapsulation Messages Opérations Proposer un service et réagir aux messages
103
Du modèle objet ... à la programmation
Encapsulation Consensuel privé implémentation public ... spécification En pratique à chaque langage ses particularismes Smalltalk attributs privés, méthodes publiques, ... Java package, protected ... C friends, protected, protection sur le lien d’héritage, ... Quelle philosophie adopter ?
104
Du modèle objet ... à la programmation
Associations PERSONNE ADRESSE N° Rue CP Ville nom .... 1 a 1 Class PERSONNE {Private : string nom;ADRESSE adr;....} rien de spécial dans ADRESSE Attrribut complexe
105
Du modèle objet ... à la programmation
Associations PERSONNE COMPTE nom .... 1 possède 0..n N° Type Class PERSONNE {Private : string nom; list <COMPTE> comptes;....} Class COMPTE PERSONNE possesseur;....} Conteneur Référence
106
Du modèle objet ... à la programmation
Associations PERSONNE BIBLIOTHEQUE 0..n adhère-> 0..n nom .... nom date adhésion type adhésion (mensuelle, annuelle) Class PERSONNE {Private : string nom;....} Class BIBLIOTHEQUE {Private : ....} Class ADHESION {Private : PERSONNE adhérent; BIBLIOTHEQUE biblio; DATE dateadhésion;....} Réification
107
Du modèle objet ... à la programmation
Héritage Implémentation de la relation de spécialisation par l’héritage, quelques problèmes .... • adéquation des deux relations • représentation et traitement des conflits • spécialisation des attributs • représentation de la surcharge et du masquage • utilisation de l’héritage à des fins d’implémentation ?
108
Du modèle objet ... à la programmation
Héritage : adéquation des deux relations Flot good() eof() ... Flot-Lecture lire(nbOctets) ... FlotEcriture écrire(blocOctets) ... FlotLectureEcriture Spécialisation multiple
109
Du modèle objet ... à la programmation
Héritage : adéquation des deux relations interface Flot interface FlotLecture interface FlotEcriture classe Flot interface FlotLectureEcriture classe FlotLecture classe FlotEcriture extends implements classe FlotLectureEcriture Cas de Java : héritage simple pour l’implémentation, multiple pour les interfaces ... côté classes, ... les méthodes de FlotLecture et FlotEcriture doivent être réécrites dans FlotLectureEcriture
110
Du modèle objet ... à la programmation
Spécialisation/Généralisation .... multiples Conflit portant sur le nom des propriétés Objet couleur (rouge, vert ...) Elément de jeu Carte à jouer Pion Dé couleur (coeur, trèfle, ...) Il y a clairement deux propriétés
111
Du modèle objet ... à la programmation
Spécialisation/Généralisation .... multiples Conflit portant sur les valeurs d’une propriété Objet couleur (rouge, vert ...) Jument Ane Mulet Le mulet n’a qu’une propriété couleur, mais quelle sera sa valeur ?
112
Du modèle objet ... à la programmation
Héritage : représentation et traitement d’un conflit de nom C++ Désignation explicite Objet::Couleur CarteAJouer::Couleur Smalltalk Java Donner deux noms différents pas d’accès possible à couleur d’objet autre qu’avec “super” (dans les méthodes) mieux vaut donner deux noms différents
113
Du modèle objet ... à la programmation
Héritage : spécialisation des attributs Animal nourriture (végétale, animale, minérale) Relation ensemblesImpliqués > 1 Herbivore nourriture (végétale) RelationBinaire ensemblesImpliqués = 2 Aucune représentation, ni en C++, ni en Smalltalk, ni en Java Seule issue : vérification des contraintes dans les méthodes ...
114
Du modèle objet ... à la programmation
Héritage : surcharge et masquage Surcharge coexistence de méthodes de même nom dans des classes différentes Masquage, (redéfinition) coexistence de méthodes de même nom dans des classes comparables Fenêtre Figure affiche affiche FenêtreAvecBord FenêtreAvecTitre affiche affiche
115
Du modèle objet ... à la programmation
Héritage : masquage C++ et Java masquage seulement si les signatures sont strictement identiques, on ne peut pas représenter directement : Magnitude <(Magnitude) Date <(Date) jour mois année Time <(Time) heure miniute secondes
116
Du modèle objet ... à la programmation
Héritage : à chacun sa surcharge Personne QuiSePorte habiller(Vêtement) habiller(Vêtement, Chaussure) Bijou Chaussure Vêtement Princesse habiller(Vêtement, Bijou) En Java : correctement interprété comme de la surcharge En C++ : habiller(Vêtement, Bijou) cache les deux autres
117
Du modèle objet ... à la programmation
Héritage : ... l’utiliser pour des raisons d’implémentation ? Liste ajoutFin A éviter dans tous les cas ... même si les livres en sont pleins ... Pile push pop top
118
Du modèle objet ... à la programmation
Vers la programmation : ... à partir du modèle dynamique (diagrammes de séquence, de collaboration, etc.) :C1 :C2 :C3 « create » Op1 Op 2 Op 3
119
Du modèle objet ... aux BD Adéquation aux BD « objet » Persistance
• Classes vs Types persistants vs éphémères • Points d’entrée (racine de persistance) • Regroupements
120
Du modèle objet ... aux BD Adéquation aux BD « objet »
LDD, LMD, L Hôte • LDD, LMD, L Hôte équivalents LPO • Langage de requête “like” SQL • Transactions
121
Du modèle objet ... aux BD 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 »
122
Du modèle objet ... aux BD Classes Schéma relationnel Attributs
ADRESSE N° Rue CP Ville Schéma relationnel Attributs Ajout de l ’identifiant Attribut Domaine Non Null Schéma Adresse Clé primaire Id_adresse Id_adresse Identifiant Oui N° Entier Non Rue String(30) Non …..
123
Du modèle objet ... aux BD Associations Attribut Domaine Non Null
PERSONNE ADRESSE N° Rue CP Ville nom .... 1 a 1 Schéma Personne Clé primaire Id_personne Clé étrangère Id_adresse Attribut Domaine Non Null Id_personne Identifiant Oui Nom String(35) Oui Id_adresse Identifiant Oui
124
Du modèle objet ... aux BD Associations Attribut Domaine Non Null
PERSONNE COMPTE nom .... 1 possède 0..n N° Type Schéma Personne Clé primaire Id_personne Clé étrangère NO Attribut Domaine Non Null Id_personne Identifiant Oui Nom String(35) Oui NO Identifiant Oui
125
Du modèle objet ... aux BD Associations Attribut Domaine Non Null
PERSONNE BIBLIOTHEQUE 0..n nom .... adhère-> 0..n nom date adhésion type adhésion (mensuelle, annuelle) Schéma Adhère Clé primaire Id_personne Id_bibliothèque Date Type Attribut Domaine Non Null Id_personne Identifiant Oui Id_bibliothèque Identifiant Oui Date_adhésion Date Oui Type_adhésion String(10) Oui
126
Du modèle objet ... aux BD Spécialisation Plusieurs choix
- « aplatir vers le haut » Schéma Personne Clé primaire Id_personne - « aplatir vers le bas » Schémas Etudiant, Enseignant - conserver les niveaux PERSONNE nom .... ETUDIANT ENSEIGNANT num .... grade ....
127
Processus de développement
Quatre phases • Analyse • Conception système • Conception objet • Implémentation Démarche Centrer l'effort sur l'analyse Processus itératif plutôt que séquentiel
128
Processus de développement
Objectifs de l'analyse • Obtenir une description initiale du problème et du système à réaliser (à partir des USE CASE) • Construire les modèles objet (structurel) et dynamique • Vérifier et itérer sur les modèles
129
Processus de développement
Conception système Décrire l'architecture générale du système • Organiser en sous systèmes • Grouper les objets en tâches concurrentes • Décider des communications inter-processus, du stockage des données, de l'implémentation du modèle dynamique
130
Processus de développement
Construire l'architecture générale du système Un sous-système est un ensemble de composants qui englobe des aspects similaires : - fonctionnalités semblables - même caractéristiques techniques - même emplacement physique Un sous-système fournit des services aux autres sous-systèmes.
131
Processus de développement
Construire l'architecture générale du système Chaque sous-système doit être le plus autonome possible. Un sous-système doit pouvoir être conçu indépendamment. Composants ?
132
Processus de développement
Construire l'architecture générale du système Le système peut être décomposé en couches et/ou en partitions Robustesse Sécurité Rapidité Répartition Multi-tâches IHM Batch Objets métier Gestionnaire base de données
133
Processus de développement
Conception objet Transposer les modèles d ’analyse Ecriture des algorithmes Il s ’agit de combiner modèles objet et dynamique …. En tenant compte des choix de la conception système
Présentations similaires
© 2024 SlidePlayer.fr Inc.
All rights reserved.