La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Formalismes et méthodes Objet 1 Méthodologie objet Survol du formalisme UML T. Libourel Avec la complicité de M Huchard.

Présentations similaires


Présentation au sujet: "Formalismes et méthodes Objet 1 Méthodologie objet Survol du formalisme UML T. Libourel Avec la complicité de M Huchard."— Transcription de la présentation:

1 Formalismes et méthodes Objet 1 Méthodologie objet Survol du formalisme UML T. Libourel Avec la complicité de M Huchard

2 Formalismes et méthodes Objet 2 Plan De l analyse à la réalisation aspects LPO aspects SI / BD Introduction - Généralités sur les méthodes objet Concepts objet et formalisme UML

3 Formalismes et méthodes Objet 3 Plan Introduction - Généralités sur les méthodes objet

4 Formalismes et méthodes Objet 4 Introduction Évolution des paradigmes de programmation Évolution des besoins Évolution des technologies

5 Formalismes et méthodes Objet 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 Formalismes et méthodes Objet 6 É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 Introduction

7 Formalismes et méthodes Objet 7 Introduction Pourquoi des méthodes ? Une nécessité Entreprise Outils Informatiques

8 Formalismes et méthodes Objet 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 Formalismes et méthodes Objet 9 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 Introduction Pourquoi des méthodes ?

10 Formalismes et méthodes Objet 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 Formalismes et méthodes Objet 11 Concepts généraux Conceptualiser obtenir un énoncé du problème (utilisateurs) Analyser spécifier le problème Implémenter réaliser la solution informatique Concevoir une solution informatique

12 Formalismes et méthodes Objet 12 Concepts généraux Étapes Résultats PlanificationSchéma directeur Analyse des besoinsModèle des besoins Spécification formelle ou analyseModèle conceptuel Spécification technique ou conceptionModèle logique ImplémentationModèle physique Intégration et TestsRapport de cohérence logique Validation du systèmeRapport de conformité Maintenance et évolution Documentation et trace

13 Formalismes et méthodes Objet 13 Concepts généraux Cycles de développement - en cascade - en V - en spirale - tridimensionnel

14 Formalismes et méthodes Objet 14 Analyse Conception Implémentation Tests Maintenance Modèle de cycle en cascade

15 Formalismes et méthodes Objet 15 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 Modèle de cycle en cascade

16 Formalismes et méthodes Objet 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 Formalismes et méthodes Objet 17 Implémentation Expression des besoins Validation des besoins Validation fonctionnelle Spécification fonctionnelle Conception du système Tests du système Tests des composants Conception des composants Modèle de cycle en V

18 Formalismes et méthodes Objet 18 Modèle de cycle en V Approche descendante dans les phases précédents limplémentation : on décompose le système au fur et à mesure quon 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 dinformation directement sur la phase permettant de corriger les erreurs.

19 Formalismes et méthodes Objet 19 Modèle de cycle en V Pour : –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 danalyse coûteuses)

20 Formalismes et méthodes Objet 20 Conception Analyse Spécifications Besoins Validation Tests Implémentation Modèle de cycle en spirale

21 Formalismes et méthodes Objet 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 lorganisation générale du système de façon non détaillée

22 Formalismes et méthodes Objet 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 Formalismes et méthodes Objet 23 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 Pourquoi lapproche objet ?

24 Formalismes et méthodes Objet 24 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. Pourquoi lapproche objet ?

25 Formalismes et méthodes Objet 25 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.

26 Formalismes et méthodes Objet 26 UML (Unified Modeling Language) OOD (Booch) OMT (Rumbaugh) OOSE (Jacobson) OOPSLA OMG UML Autres

27 Formalismes et méthodes Objet 27 Autres méthodesBooch91OMT-1OOSEPartenaires Booch93OMT-2 OOPSLA95 Unified Method 0.8 Commentaires du public UML 0.9 & 0.91 Juin 96 puis OOPSLA96 UML 1.0 Soumission à lOMG - Janvier 97 UML 1.1 UML 1.2 UML 1.3 Standardisation à lOMG - Novembre 97 Version intermédiaire non publiée Version béta - fin 99

28 Formalismes et méthodes Objet 28 Plan Concepts objet et formalisme UML

29 Formalismes et méthodes Objet 29 Vue Cas dutilisation Vue structurelle Vue Architecture (déploiement) Vue dynamique Points de vue sur le système Concepts généraux Vue Implémentation

30 Formalismes et méthodes Objet 30 Modèle déploiement Modèle Dynamique Modèle structurel Quatre points de vue Types d'objets et leurs relations Stimuli des objets et leurs réponses Modèle implémentation Concepts généraux

31 Formalismes et méthodes Objet 31 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 …) Concepts généraux

32 Formalismes et méthodes Objet 32 Diagrammes (représentations graphiques de modèle) de classes d instances d'états Diagrammes de déploiement de composants Diagrammes de collaboration de séquences Diagrammes Cas d utilisation Concepts généraux

33 Formalismes et méthodes Objet 33 AnalyseConceptionImplémentation Démarche uniforme sur le cycle de vie Même notation Concepts généraux

34 Formalismes et méthodes Objet 34 Formalisme UML - Concepts objet Modèle dutilisation Modèle structurel Modèle dynamique Modèle dimplémentation

35 Formalismes et méthodes Objet 35 Modèle dutilisation Les « USE CASE » Modèles descriptifs du point de vue des utilisateurs Scénarios fonctionnels Focus la manière dutiliser le système

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

37 Formalismes et méthodes Objet 37 Modèle dutilisation Deux concepts Acteur Use case Acteur (rôle 1) Acteur (rôle 2) « communicate »

38 Formalismes et méthodes Objet 38 Modèle dutilisation Acteur (rôle 1) Acteur (rôle 2) Les cas d utilisation peuvent être liés par des relations - dutilisation « include » (on utilise une partie commune) - de raffinement « extends » (on traite des exceptions) « include » « extends » - de généralisation/spécialisation « generalizes »

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

40 Formalismes et méthodes Objet 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 Formalismes et méthodes Objet 41 Modèle structurel Objets du monde réel Objets informatiques État Interne caché Comportement visible Les objets

42 Formalismes et méthodes Objet 42 Modèle structurel Comportement influe sur l'état Etat réflète les comportements passés Objet Etat---> évolue au cours du temps Comportement---> actions et réactions Identité----> essence

43 Formalismes et méthodes Objet 43 Sophie Alain Système BD Luc : Professeur : Discipline Deux objets ou instances Modèle structurel

44 Formalismes et méthodes Objet 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 Formalismes et méthodes Objet 45 Classe Attributs (propriétés) Voiture type : string marque : string couleur : string Titine :Voiture type =205 Peugeot rouge Modèle structurel Instance Valeurs d'attributs (État) « Est-instance-de »

46 Formalismes et méthodes Objet 46 Opérations et méthodes Voiture type : string marque : string couleur : string repeindre(c: Couleur) déplacer (d : longueur) Méthodes Implémentations Modèle structurel nom de la classe attributs opérations

47 Formalismes et méthodes Objet 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 Formalismes et méthodes Objet 48 Association / Lien (analogie Classe / Instance) Pays Ville nom a-pour-capitale Association : Pays nom=France :Ville nom = Paris a-pour-capitale Lien Modèle structurel

49 Formalismes et méthodes Objet 49 Modèle structurel Association en général binaire (degré = 2) mais.. AdhérentExemplaire emprunte DispositifDeLecture lire nom d'association association binaire association ternaire

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

51 Formalismes et méthodes Objet 51 Modèle structurel exactement 1 Classe Classe 0..* Classe 1..* Classe 2..4 Classe 2,4 au plus 1 aucun, 1 ou plusieurs (défaut) au moins 1 de 2 à 4 2 ou 4 Multiplicité Classe

52 Formalismes et méthodes Objet 52 Conseils pour la modélisation d'association - verbes candidats possibles - ne pas "dériver vers la conception" (pointeurs ou attributs référentiels) Modèle structurel

53 Formalismes et méthodes Objet 53 Entreprise Personne nom adresse nom date de nais. adresse quantité Possède-des-actions capital actionnaire Modèle structurel Classe association Ligne de portefeuille *1..*

54 Formalismes et méthodes Objet 54 Classe association Utilisateur Station de travail nom Autorisation Autorisé sur priorité droits Répertoire répertoire de rattachement Modèle structurel 1..*

55 Formalismes et méthodes Objet 55 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).

56 Formalismes et méthodes Objet 56 Association qualifiée Banque Personne num_client est_client Modèle structurel Dossier_C 1..* Banque Personne num_client est_client 1..* 0..1

57 Formalismes et méthodes Objet 57 Modèle structurel D autres « abstractions » - associations particulières (composition / agrégation) - spécialisation / généralisation

58 Formalismes et méthodes Objet 58 Association particulière Tout /partie Barre titreFond Barre Ascenseur Frontière Indicateur TitreBouton Ferm Flèche Fenêtre Modèle structurel Composition

59 Formalismes et méthodes Objet 59 Agrégation Sémantique Collection/Élément Arbre Département Forêt 1 1..n Région Pays 1 1..n 1 Modèle structurel

60 Formalismes et méthodes Objet 60 Composition / Agrégation Modèle structurel Contraintes - Exclusivité/Partage - Dépendance/Indépendance Propagation/Diffusion

61 Formalismes et méthodes Objet 61 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

62 Formalismes et méthodes Objet 62 Personne nom adresse Étudiant num_carte adresse Enseignant grade adresse enseigner {disjoint} Modèle structurel Généralisation / Spécialisation

63 Formalismes et méthodes Objet 63 Généralisation / Spécialisation Pompe Échangeur Réservoir Pompe Cent.Pompe Imm. Réservoir Press. Équipement... Type d'équipement... Type de pompe... Type de réservoir Modèle structurel

64 Formalismes et méthodes Objet 64 Généralisation / Spécialisation multiple Modèle structurel Véhicule terrestre Véhicule aquatique Auto Véhicule amphibie Bateau Véhicule

65 Formalismes et méthodes Objet 65 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 Modèle structurel

66 Formalismes et méthodes Objet 66 Généralisation / Spécialisation Modèle structurel 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 Formalismes et méthodes Objet 67 Classes abstraites Modèle structurel 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 Formalismes et méthodes Objet 68 Opérations abstraites Modèle structurel 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 Formalismes et méthodes Objet 69 Classes abstraites Modèle structurel FormeGéométrique dessiner() déplacer(delta : Vecteur) centre : Point régulier : Boolean Polygone grandDiam : Vecteur petitDiam : Vecteur dessiner() opération abstraite classe abstraite classe abstraite (dessiner() est héritée et non concrétisée) opération concrétisée classe concrète Polygone utile que si spécialisée Ellipse

70 Formalismes et méthodes Objet 70 Interfaces Modèle structurel 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 Formalismes et méthodes Objet 71 Interfaces Modèle structurel MenuPopUp BlocDeChoix setDefault(o : Option) getChoice() : Option Option choix 1..* setDefault(o : String) getChoice() : String setDefault(o : Bouton) getChoice() : Bouton Bouton choix 1..* String choix 1..* opérations concrétisées «interface» interface opérations abstraites réalisation MenuBouton

72 Formalismes et méthodes Objet 72 Interfaces Modèle structurel Deux notations pour l'utilisation d'une interface MenuPopUp setDefault(o : Option) getChoice() : Option «interface» BlocDeChoix MenuPopUp ApplicationFenêtrée «uses» ApplicationFenêtrée «uses» BlocDeChoix interface classe utilisatrice utilisation réalise

73 Formalismes et méthodes Objet 73 Les contraintes Modèle structurel 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 Formalismes et méthodes Objet 74 Les contraintes Modèle structurel Exemples de contraintes sur associations Chemin Arête * 1..* PersonneComité préside *1 membreDe ** {subset} {ordered} contrainte sur extrémité d'association contrainte entre 2 associations

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

76 Formalismes et méthodes Objet 76 Quelques compléments de notation Modèle structurel 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», … «instance of» relation de dépendance stéréotype Un stéréotype est un label qui permet d'apporter une précision supplémentaire à un élément de notation (classe, relation, …)

77 Formalismes et méthodes Objet 77 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 ! Modèle structurel

78 Formalismes et méthodes Objet 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 Formalismes et méthodes Objet 79 É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 Modèle dynamique

80 Formalismes et méthodes Objet 80 Modèle dynamique diagrammes de séquences diagrammes états-transitions diagrammes de collaboration diagrammes d'activités (non traités)

81 Formalismes et méthodes Objet 81 lappelant soulève le combiné la tonalité est déclenchée lappelant compose le numéro 6 la tonalité sarrête lappelant tape le chiffre 7 lappelant tape le chiffre 1 lappelant tape le chiffre 4 lappelant tape le chiffre 8 lappelant tape le chiffre 6 lappelant tape le chiffre 6 lappelant tape le chiffre 2 le téléphone appelé commence à sonner la tonalité de sonnerie commence dans le téléphone appelant lappelé décroche le téléphone de lappelé cesse de sonner la tonalité de sonnerie cesse dans le téléphone appelant les téléphones sont connectés lappelé raccroche les téléphones sont déconnectés lappelant raccroche Scénarios Exemple Modèle dynamique

82 Formalismes et méthodes Objet 82 Diagrammes de séquences Appelant : Personne:Ligne TéléphoniqueAppelé : Personne lappelant soulève le combiné la tonalité est déclenchée la tonalité sarrête lappelant compose le numéro 6 lappelant compose les numéros le téléphone appelé commence à sonner lappelant entend la sonnerie lappelé décroche le téléphone de lappelé cesse de sonner la sonnerie cesse connexion établie connexion interrompue lappelé raccroche lappelant raccroche Modèle dynamique

83 Formalismes et méthodes Objet 83 constructeurs destructeurs sélecteurs modificateurs itérateurs Types Synchronisation simple synchrone dérobant minuté asynchrone Les messages Modèle dynamique

84 Formalismes et méthodes Objet 84 Modèle dynamique La ligne de vie :C1 « create » Création par le message « create » Activation de l objet qui exécute une opération op Destruction par un autre objet « destroy » op

85 Formalismes et méthodes Objet 85 Diagrammes de collaboration Vue globale des événements entre classes Appelant : Personne :Ligne téléphonique Appelé: Personne Modèle dynamique 1, 3,.. 2, 4 5,... 6,..

86 Formalismes et méthodes Objet 86 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 Modèle dynamique

87 Formalismes et méthodes Objet 87 É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 Modèle dynamique

88 Formalismes et méthodes Objet 88 É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 Modèle dynamique

89 Formalismes et méthodes Objet 89 Diagrammes d'États Libre Tonalité En numérotation En connexion décroche numérote recherche réussie Sonnerie Connectée Déconnectée numéro existant réponse appelé raccroche raccroché Exemple incomplet Modèle dynamique Etat initial

90 Formalismes et méthodes Objet 90 Diagrammes d'États Transitions gardées en création Ouvert Fermé demande création fermeture accomplie En retrait En dépôt Débiteur fermeture retrait (s) dépôt(s) Créditeur [Solde >0] [Solde 0] Modèle dynamique

91 Formalismes et méthodes Objet 91 État 1 faire : Activité 1 Événement 1 [Cond1] / Action1 (attrib) État 2... Opération Activité / Action Modèle dynamique

92 Formalismes et méthodes Objet 92 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. 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. Modèle dynamique

93 Formalismes et méthodes Objet 93 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 E2 E5 E4E3 E6 Modèle dynamique

94 Formalismes et méthodes Objet 94 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) Modèle dynamique Ecomp1Ecomp2

95 Formalismes et méthodes Objet 95 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 Modèle dynamique

96 Formalismes et méthodes Objet 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 Formalismes et méthodes Objet 97 Modèle d implémentation Les packages Classes avec fort couplage « sémantique » Liens de dépendance

98 Formalismes et méthodes Objet 98 Plan De l analyse à la réalisation du modèle objet ….. à la programmation objet du modèle objet …… aux BD

99 Formalismes et méthodes Objet 99 Du modèle objet... à la programmation Classes Attributs, Opérations > Champs, Méthodes Accesseurs L/E Constructeurs, Destructeurs

100 Formalismes et méthodes Objet 100 Du modèle objet... à la programmation Classes - adresse : String = 'adresse inconnue' - numeroINSEE[6] : Integer # changeAdresse(nouvelleAdresse : String) + cotisationAJour() : Boolean Adhérent note (peut contenir un complément de description, un commentaire, …) type d'attribut valeur initiale type de paramètre type du résultat de l'opération privé protégé public adhérent de la bibliothèque valeurs multiples

101 Formalismes et méthodes Objet 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 Formalismes et méthodes Objet 102 Du modèle objet... à la programmation Proposer un service et réagir aux messages Opérations Données Messages Encapsulation Objet

103 Formalismes et méthodes Objet 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 dhéritage,... Quelle philosophie adopter ?

104 Formalismes et méthodes Objet 104 Du modèle objet... à la programmation Associations PERSONNE ADRESSE nom.... N° Rue CP Ville 1 1 a Class PERSONNE {Private : string nom;ADRESSE adr;....} rien de spécial dans ADRESSE Attrribut complexe

105 Formalismes et méthodes Objet 105 Du modèle objet... à la programmation Associations PERSONNE COMPTE nom.... N° Type 1 0..n possède Class PERSONNE {Private : string nom; list comptes;....} Class COMPTE {Private : PERSONNE possesseur;....} Conteneur Référence

106 Formalismes et méthodes Objet 106 Du modèle objet... à la programmation Associations PERSONNE BIBLIOTHEQUE nom.... nom 0..n adhère-> Class PERSONNE {Private : string nom;....} Class BIBLIOTHEQUE {Private :....} Class ADHESION {Private : PERSONNE adhérent; BIBLIOTHEQUE biblio; DATE dateadhésion;....} Réification 0..n date adhésion type adhésion (mensuelle, annuelle)

107 Formalismes et méthodes Objet 107 Du modèle objet... à la programmation Héritage 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 lhéritage à des fins dimplémentation ? Implémentation de la relation de spécialisation par lhéritage, quelques problèmes....

108 Formalismes et méthodes Objet 108 Du modèle objet... à la programmation Héritage : adéquation des deux relations Spécialisation multiple Flot good() eof()... FlotEcriture écrire(blocOctets)... Flot-Lecture lire(nbOctets)... FlotLectureEcriture

109 Formalismes et méthodes Objet 109 Cas de Java : héritage simple pour limplémentation, multiple pour les interfaces... côté classes,... les méthodes de FlotLecture et FlotEcriture doivent être réécrites dans FlotLectureEcriture Du modèle objet... à la programmation Héritage : adéquation des deux relations interface Flot interface FlotEcriture interface FlotLecture interface FlotLectureEcriture classe Flot classe FlotLecture classe FlotLectureEcriture classe FlotEcriture extends implements

110 Formalismes et méthodes Objet 110 Du modèle objet... à la programmation Spécialisation/Généralisation.... multiples Conflit portant sur le nom des propriétés Il y a clairement deux propriétés Objet couleur (rouge, vert...) Elément de jeu Pion Dé Carte à jouer couleur (coeur, trèfle,...)

111 Formalismes et méthodes Objet 111 Du modèle objet... à la programmation Spécialisation/Généralisation.... multiples Conflit portant sur les valeurs dune propriété Le mulet na quune propriété couleur, mais quelle sera sa valeur ? Objet couleur (rouge, vert...) Jument Ane Mulet

112 Formalismes et méthodes Objet 112 Du modèle objet... à la programmation Héritage : représentation et traitement dun conflit de nom Smalltalk Java C++ Désignation explicite Objet::Couleur CarteAJouer::Couleur Donner deux noms différents pas daccès possible à couleur dobjet autre quavec super (dans les méthodes) mieux vaut donner deux noms différents

113 Formalismes et méthodes Objet 113 Du modèle objet... à la programmation Héritage : spécialisation des attributs Animal nourriture (végétale, animale, minérale) Herbivore nourriture (végétale) Relation ensemblesImpliqués > 1 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 Formalismes et méthodes Objet 114 Du modèle objet... à la programmation Héritage : surcharge et masquage Masquage, (redéfinition) coexistence de méthodes de même nom dans des classes comparables Fenêtre FenêtreAvecBordFenêtreAvecTitre affiche Figure affiche Surcharge coexistence de méthodes de même nom dans des classes différentes

115 Formalismes et méthodes Objet 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) Time <(Time) heure miniute secondes Date <(Date) jour mois année

116 Formalismes et méthodes Objet 116 Du modèle objet... à la programmation Héritage : à chacun sa surcharge Personne Princesse habiller(Vêtement) habiller(Vêtement, Chaussure) habiller(Vêtement, Bijou) Vêtement Chaussure Bijou QuiSePorte En Java : correctement interprété comme de la surcharge En C++ : habiller(Vêtement, Bijou) cache les deux autres

117 Formalismes et méthodes Objet 117 Du modèle objet... à la programmation Héritage :... lutiliser pour des raisons dimplémentation ? Liste ajoutFin Pile push pop top A éviter dans tous les cas... même si les livres en sont pleins...

118 Formalismes et méthodes Objet 118 Du modèle objet... à la programmation Vers la programmation :... à partir du modèle dynamique (diagrammes de séquence, de collaboration, etc.) :C2 « create » Op1 :C1 :C3 Op 2 Op 3

119 Formalismes et méthodes Objet 119 Persistance Classes vs Types persistants vs éphémères Points dentrée (racine de persistance) Regroupements Du modèle objet... aux BD Adéquation aux BD « objet »

120 Formalismes et méthodes Objet 120 LDD, LMD, L Hôte LDD, LMD, L Hôte équivalents LPO Langage de requête like SQL Transactions Du modèle objet... aux BD Adéquation aux BD « objet »

121 Formalismes et méthodes Objet 121 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 » Du modèle objet... aux BD

122 Formalismes et méthodes Objet 122 Classes Attributs Ajout de l identifiant Schéma relationnel ADRESSE N° Rue CP Ville Attribut Domaine Non Null Id_adresse Identifiant Oui N° Entier Non Rue String(30) Non ….. Schéma Adresse Clé primaire Id_adresse Du modèle objet... aux BD

123 Formalismes et méthodes Objet 123 Associations PERSONNE ADRESSE nom.... N° Rue CP Ville 1 1 a Attribut Domaine Non Null Id_personne Identifiant Oui Nom String(35) Oui Id_adresse Identifiant Oui Schéma Personne Clé primaire Id_personne Clé étrangère Id_adresse Du modèle objet... aux BD

124 Formalismes et méthodes Objet 124 Associations PERSONNE COMPTE nom.... N° Type 1 0..n possède Attribut Domaine Non Null Id_personne Identifiant Oui Nom String(35) Oui NO Identifiant Oui Schéma Personne Clé primaire Id_personne Clé étrangère NO Du modèle objet... aux BD

125 Formalismes et méthodes Objet 125 Associations PERSONNE BIBLIOTHEQUE nom.... nom 0..n adhère-> 0..n date adhésion type adhésion (mensuelle, annuelle) Attribut Domaine Non Null Id_personne Identifiant Oui Id_bibliothèque Identifiant Oui Date_adhésion Date Oui Type_adhésion String(10) Oui Schéma Adhère Clé primaire Id_personne Id_bibliothèque Date Type Du modèle objet... aux BD

126 Formalismes et méthodes Objet 126 Spécialisation PERSONNE nom.... ETUDIANT num.... ENSEIGNANT grade.... Plusieurs choix - « aplatir vers le haut » Schéma Personne Clé primaire Id_personne - « aplatir vers le bas » Schémas Etudiant, Enseignant Clé primaire Id_personne - conserver les niveaux Du modèle objet... aux BD

127 Formalismes et méthodes Objet 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 Formalismes et méthodes Objet 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 Formalismes et méthodes Objet 129 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 Processus de développement

130 Formalismes et méthodes Objet 130 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. Processus de développement

131 Formalismes et méthodes Objet 131 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 ? Processus de développement

132 Formalismes et méthodes Objet 132 Construire l'architecture générale du système Le système peut être décomposé en couches et/ou en partitions Processus de développement Gestionnaire base de données Objets métier BatchIHM Robustesse Sécurité Rapidité Répartition Multi-tâches

133 Formalismes et méthodes Objet 133 Conception objet Processus de développement 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


Télécharger ppt "Formalismes et méthodes Objet 1 Méthodologie objet Survol du formalisme UML T. Libourel Avec la complicité de M Huchard."

Présentations similaires


Annonces Google