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

UML T. Libourel Autour des objets T. Libourel

Présentations similaires


Présentation au sujet: "UML T. Libourel Autour des objets T. Libourel"— Transcription de la présentation:

1

2 UML T. Libourel Autour des objets T. Libourel

3 UML T. Libourel PLAN è Introduction –Modèles mathématiques versus modèles objets –Systèmes et objets –Pourquoi des méthodes ? è Approche objet –Atouts –Historique è Concepts objet et formalisme UML –Concepts généraux –Modèle fonctionnel –Modèle structurel –Modèle dynamique è Discussion

4 UML T. Libourel PLAN è Introduction –Modèles mathématiques versus modèles objets –Systèmes et objets –Pourquoi des méthodes ? è Approche objet –Atouts –Historique è Concepts objet et formalisme UML –Concepts généraux –Modèle fonctionnel –Modèle structurel –Modèle dynamique è Discussion

5 UML T. Libourel Modèles mathématiques versus modèles objets è L'approche mathématique –Représentation de types, de variables et de fonctions. –Culture scientifique è L'approche objet –Représentation abstraite d'entités ayant une existence matérielle (arbre, personne) ou virtuelle (sécurité sociale, compte bancaire,...). –Culture implicite et philosophique –Confluent de plusieurs disciplines informatiques

6 UML T. Libourel Systèmes et objets è 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)

7 UML T. Libourel Systèmes et objets è É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

8 UML T. Libourel Besoin de méthodologie Entreprise Outils Informatiques Pourquoi des méthodes ? Rien ne dicte a priori comment modéliser un système de manière pertinente

9 UML T. Libourel 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

10 UML T. Libourel Pourquoi des méthodes ? è Démarche qui distingue les étapes du développement dans le cycle de vie du logiciel –Modularité, réduction de la complexité, réutilisabilité, abstraction –Un formalisme de représentation qui facilite la communication, lorganisation et la vérification –Production de documents (modèles) qui facilitent les retours sur conception et lévolution des applications

11 UML T. Libourel PLAN è Introduction –Modèles mathématiques versus modèles objets –Systèmes et objets –Pourquoi des méthodes ? è Approche objet –Atouts –Historique è Concepts objet et formalisme UML –Concepts généraux –Modèle fonctionnel –Modèle structurel –Modèle dynamique è Discussion

12 UML T. Libourel Atouts è 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. è 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.

13 UML T. Libourel Historique è Plus de 50 méthodes objet sont apparues durant la période 90-95: Booch, Classe-Relation, OMT, OOA, OOD, OOM, OOSE... –Grady Booch : OOD, BOOCH'93 ( Société RATIONAL ) 1987 pour ADA, 1990 générale –James Rumbaugh : OMT "Object Modeling Techniques" General Electric –Ivar Jacobson : Objectory 1992, Ericsson, suite de OOSE "Object Oriented Software Engineering" èRegroupement de BOOCH-OMT puis Objectory

14 UML T. Libourel Historique è 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. è UML (Unified Modeling Language)

15 UML T. Libourel PLAN è Introduction –Modèles mathématiques versus modèles objets –Systèmes et objets –Pourquoi des méthodes ? è Approche objet –Atouts –Historique è Concepts objet et formalisme UML –Concepts généraux –Modèle fonctionnel –Modèle structurel –Modèle dynamique è Discussion

16 UML T. Libourel Concepts généraux è Un modèle est une représentation abstraite dune réalité, è Il fournit une image simplifiée du monde réel. è Il permet –de comprendre et visualiser (en réduisant la complexité) –de communiquer (à partir d un « langage » commun à travers un nombre restreint de concepts) –de valider (contrôle de la cohérence, simuler, tester …)

17 UML T. Libourel 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 Concepts généraux

18 UML T. Libourel 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 Concepts généraux

19 UML T. Libourel Vue Cas d utilisation Vue structurelle Vue Architecture (déploiement) Vue dynamique Définir une architecture ……. divers points de vue sur le système Vue Implémentation Concepts généraux

20 UML T. Libourel Analyse Tests - Maintenance Réalisation Même formalisme lors de toutes les phases du cycle de vie Conception Processus incrémental Concepts généraux

21 UML T. Libourel Modèle fonctionnel è Modèles descriptifs du point de vue des utilisateurs è Scénarios fonctionnels è Focus La manière dutiliser le système Les « USE CASE »

22 UML T. Libourel Deux concepts Acteur Use case Acteur (rôle 1) Acteur (rôle 2) Modèle fonctionnel Ex: distributeur CB

23 UML T. Libourel Acteur (rôle 1) Acteur (rôle 2) « use » « extend » Modèle fonctionnel è Les cas dutilisation peuvent être liés par des relations –dutilisation « use » (décomposition) –de raffinement « extend » (traitement dexceptions)

24 UML T. Libourel è 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. Modèle structurel

25 UML T. Libourel Objets du monde réel Objets informatiques État Interne caché Comportement visible Les objets Modèle structurel

26 UML T. Libourel Comportement influe sur l'état Etat reflète les comportements passés Objet Etat évolue au cours du temps Comportement actions et réactions Identité essence Modèle structurel

27 UML T. Libourel Sophie Alain Système BD Luc : Professeur : Discipline Deux objets ou instances Modèle structurel

28 UML T. Libourel Première abstraction èUne classe peut être vue –la description en intension 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 Modèle structurel

29 UML T. Libourel Classe Attributs (propriétés) Voiture type : string marque : string couleur : string titine :Voiture type =205 Peugeot rouge Instance Valeurs d'attributs (État) « Est-instance-de » Modèle structurel

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

31 UML T. Libourel è Représentation graphique : « les boites » (à différents niveaux de détail) è Les types sont optionnels et ne figent pas les choix d'implémentation è La description des opérations sera complétée dans les phases de conception Modèle structurel

32 UML T. Libourel è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). Modèle structurel

33 UML T. Libourel 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

34 UML T. Libourel Association en général binaire (degré = 2) mais.. AdhérentExemplaire emprunte DispositifDeLecture lire nom d'association association binaire association ternaire Modèle structurel

35 UML T. Libourel 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 * 1..* 0..1 Modèle structurel

36 UML T. Libourel exactement 1 Classe * 1..* ,4 au plus 1 aucun, 1 ou plusieurs (défaut) au moins 1 de 2 à 4 2 ou 4 Multiplicité Classe Modèle structurel

37 UML T. Libourel Entreprise Personne nom adresse nom date de nais. adresse quantité Possède-des-actions capital actionnaire Classe association Possession Ligne de portefeuille * 1..* Modèle structurel

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

39 UML T. Libourel D autres « abstractions » Modèle structurel èassociations particulières –(composition / agrégation) èspécialisation / généralisation

40 UML T. Libourel Association particulière Tout /partie Barre titreFond Barre Ascenseur Frontière Indicateur TitreBouton Ferm Flèche Fenêtre Composition Modèle structurel

41 UML T. Libourel 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

42 UML T. Libourel Composition / Agrégation Contraintes - Exclusivité / Partage - Dépendance / Indépendance Propagation / Diffusion Modèle structurel

43 UML T. Libourel 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 Modèle structurel

44 UML T. Libourel Personne nom adresse Enseignant grade adresse enseigner {disjoint} Étudiant num_carte adresse Modèle structurel Généralisation / Spécialisation

45 UML T. Libourel 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 Généralisation / Spécialisation

46 UML T. Libourel Véhicule terrestre Véhicule aquatique Auto Véhicule amphibie Bateau Véhicule Modèle structurel Généralisation / Spécialisation multiple

47 UML T. Libourel Composition/Agrégation ou généralisation ? Modèle structurel èAgrégation –lien entre instances –un arbre d'agrégation est composé d'objets qui sont parties d'un objet composite èGénéralisation –lien entre classes

48 UML T. Libourel è Une sous-classe hérite des descriptions de sa super-classe : –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 ». Modèle structurel Généralisation / Spécialisation

49 UML T. Libourel 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. Modèle structurel

50 UML T. Libourel Les contraintes: 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 Modèle structurel

51 UML T. Libourel actif : Real {value 0} passif : Real Les contraintes: Exemple de contraintes à différents niveaux contrainte sur classe Personne chef subordonné

52 UML T. Libourel 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 Modèle dynamique

53 UML T. Libourel Modèle dynamique è diagrammes de collaboration è diagrammes de séquences è diagrammes états-transitions è diagrammes d'activités (non traités)

54 UML T. Libourel La communication Systèmes informatiques : Société d'objets travaillant en synergie pour réaliser les fonctions de l'application Communication Client Serveur message Acteur Modèle dynamique

55 UML T. Libourel constructeurs destructeurs sélecteurs modificateurs itérateurs Types Synchronisation Les messages Modèle dynamique asynchrone synchrone retour

56 UML T. Libourel Diagramme de collaboration B C message A 1: M1 2: M2 3: M3 4: M4 6: M6 5: M5 Modèle dynamique

57 UML T. Libourel Diagramme de séquence B C A M1 M2 M3 M4 M6 M5 Modèle dynamique TEMPS

58 UML T. Libourel La ligne de vie « create » Création par le message «create» Activation de lobjet qui exécute une opération op Destruction par un autre objet :C1 « destroy » op Modèle dynamique

59 UML T. Libourel Modèle dynamique Poitou:Région France:Pays 4: m4 Bretagne:Région LR:Région Gard: Départ Hérault: Départ Aude:Départ Pays Région Départ …. 1:Population() 1.2:Population() 1.3:Population() 1.1:Population() 1.3.1:Population() 1.3.2:Population() 1.3.3:Population()

60 UML T. Libourel Modèle dynamique France Poitou Bretagne LR temps A HG Popul()

61 UML T. Libourel Événement et État Modèle dynamique è É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

62 UML T. Libourel État 1 faire : Activité 1 Événement 1 [Cond1] / Action1 (attrib) État 2... Diagramme détat Modèle dynamique Graphe : Nœuds (Etat) Arcs (Transitions)

63 UML T. Libourel Modèle dynamique Initial Final Simple Complexe Créditeur Nom état entry/op1 exit/ op2 on evt1/ op3 on evt2/ op4 do/ activité au début à la fin lors devt tout le temps Activités internes Notation des états

64 UML T. Libourel Notation des arcs Modèle dynamique étiquette événement(paramètres) [condition] /action

65 UML T. Libourel Modèle dynamique 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.

66 UML T. Libourel Modèle dynamique Diagrammes d'États Etats dun compte bancaire transitions gardées sous-état Ouvert Fermé demandeCréat() Débiteur on retrait/ agios on dépôt/ augmenter solde fermer() Créditeur on retrait/ debiter solde on dépôt/ augmenter solde [Solde >=0] [Solde < 0] ouvert

67 UML T. Libourel 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 E2 E5 E4E3 E6

68 UML T. Libourel 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) Arrêt Portière Marche point mort Moteur Ouverte Fermée gonflée Marche avant Marche arrière Roue crevée Auto Moteur portièreroue

69 UML T. Libourel Les packages Modèle dimplémentation è 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 quil 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

70 UML T. Libourel Les packages Classes avec fort couplage « sémantique » Liens de dépendance Modèle dimplémentation

71 UML T. Libourel PLAN è Introduction –Modèles mathématiques versus modèles objets –Systèmes et objets –Pourquoi des méthodes ? è Approche objet –Atouts –Historique è Concepts objet et formalisme UML –Concepts généraux –Modèle fonctionnel –Modèle structurel –Modèle dynamique è Discussion

72 UML T. Libourel Des bienfaits de l encapsulation …. Proposer un service et réagir aux messages Opérations Données Messages Encapsulation Discussion

73 UML T. Libourel La méta-modélisation Meta-Meta Modèle Meta-Modèle Modèle Objets utilisateur Meta-Class, Meta-Attribut, etc Class, Attribut, etc Parcelle, Surface, etc A120, 50, etc Langage pour spécifier tout métamodèle Langage pour spécifier un modèle Langage pour spécifier un domaine dinformation Définition spécifique dun domaine Discussion

74 UML T. Libourel UML et Merise èUML nest pas une méthode comme Merise –Ne dit rien sur le processus de mise en œuvre ; chaque société peut proposer son processus: RUP « Rational Unified Process » (Rational) EAI (Valtech) MEGA Process (MEGA) èUML cible toute application informatique, alors que Merise cible les SI Discussion

75 UML T. Libourel Les outils Langages JAVA, C++,.. Modèles UML,... AGL Environnement de développement: Visual Age (IBM), Delphi, Visual J++, J Builder, VisualWorks, Objets SGBD-R ou SGBD-OO re-engineering Squelette de code Schéma de la base relationnelle ou objet Discussion

76 UML T. Libourel è Outil de dialogue : –langage de représentation des modèles –graphique et simple –formel et normalisé (OMG) è Outil ouvert –Indépendant des langages de programmation –Pas un processus d'élaboration des modèles –Adaptable (stéréotype) Discussion

77 UML T. Libourel Livres UML (1) è Booch Grady, Rumbaugh James, and Jacobson Ivar, The Unified Modeling Language User Guide, , Addison Wesley, Fall 1998, traduit : Le guide de l'utilisateur UML, Eyrolles è Jacobson Ivar, Booch Grady and Rumbaugh James, The Unified Software Development Process, , Addison Wesley, Fall 1998, traduit : Le processus unifié de développement logiciel, Eyrolles è Rumbaugh James, Jacobson Ivar, and Booch Grady, The Unified Modeling Language Reference Manual, X, Addison Wesley, Fall 1998

78 UML T. Libourel Livres UML (2) –Conallen Jim, Concevoir des applications Web avec UML, Eyrolles, –Douglass Bruce Powell, Doing Hard Time : Developping Real-Time Systems with UML, Addison Wesley, –Eriksson, UML Toolkit, Wiley, 1997 –Fowler Martin, UML Distilled, Applying the Standard Object Modeling Language Addison Wesley, 1997 –Kettany N et al, De Merise à UML,Eyrolles, 1998 –Larman Craig, Applying UML and Patterns,Prentice Hall, 1998 –Lee R, Tepfenhart W, UML et C++, Simon et Schuste, 1998 –Lopez N, Intégrer UML dans vos projets, Eyrolles, 1997 –Muller Pierre-Alain, Modélisation objet avec UML, Eyrolles, 1997 –Roques Pascal, Vallée Franck, UML en action, Eyrolles, –Roques Pascal, UML par la pratique, Eyrolles, –Schmuller Joseph, Teach Yourself UML in 24 Hours, Sams Publishing, 1999 –Texel Williams, Uses cases combined with Booch/OMT/UML, Prentice Hall, 1998


Télécharger ppt "UML T. Libourel Autour des objets T. Libourel"

Présentations similaires


Annonces Google