T. Libourel libourel@lirmm.fr Autour des objets T. Libourel libourel@lirmm.fr.

Présentation au sujet: "T. Libourel libourel@lirmm.fr Autour des objets T. Libourel libourel@lirmm.fr."— Transcription de la présentation:

1 T. Libourel libourel@lirmm.fr
Autour des objets T. Libourel

2 Introduction Approche objet Concepts objet et formalisme UML
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

3 Introduction Approche objet Concepts objet et formalisme UML
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 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

5 Taille et complexité des systèmes importantes et croissantes
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 l’interface avec le métier (domaine d’application)

6 Évolution des applications
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

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

8 Démarche reproductible pour obtenir des résultats fiables
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 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, l’organisation et la vérification Production de documents (modèles) qui facilitent les retours sur conception et l’évolution des applications

10 Introduction Approche objet Concepts objet et formalisme UML
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

11 Universalité de l’Objet
Atouts 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. 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.

12 Regroupement de BOOCH-OMT puis Objectory
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

13 UML (Unified Modeling Language)
Historique 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. UML (Unified Modeling Language)

14 Introduction Approche objet Concepts objet et formalisme UML
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

15 Un modèle est une représentation abstraite d’une réalité,
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 …)

16 Les modèles d'UML Concepts généraux 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

17 La perception des modèles Les vues graphiques (diagrammes )
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

18 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 >

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

20 Modèles descriptifs du point de vue des utilisateurs
Modèle fonctionnel Les «  USE CASE » Modèles descriptifs du point de vue des utilisateurs Scénarios fonctionnels Focus La manière d’utiliser le système

21 Deux concepts Acteur Use case Modèle fonctionnel Acteur (rôle 2)
Ex: distributeur CB Deux concepts Acteur Use case Acteur (rôle 2) Acteur (rôle 1)

22 Les cas d’utilisation peuvent être liés par des relations
Modèle fonctionnel Les cas d’utilisation peuvent être liés par des relations d’utilisation « use » (décomposition) de raffinement « extend » (traitement d’exceptions) Acteur (rôle 2) Acteur (rôle 1) « use » « extend »

23 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.

24 Les objets Modèle structurel Objets du monde réel Objets informatiques
Comportement visible État Interne caché

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

26 Modèle structurel BD Luc Système Alain : Discipline Sophie
Deux objets ou instances Luc Système Alain : Discipline Sophie : Professeur

27 Première abstraction Une classe peut être vue Modèle structurel
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

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

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

30 Les types sont optionnels et ne figent pas les choix d'implémentation
Modèle structurel 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

31 Un objet est instance d'une (seule) classe :
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 (analogie Classe / Instance)
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 Association en général binaire (degré = 2) mais ..
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 Multiplicité et rôles d'une association
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 Possession Ligne de portefeuille
Modèle structurel Classe association Possède-des-actions Entreprise Personne * 1..* nom adresse capital actionnaire nom date de nais. adresse Possession Ligne de portefeuille quantité

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

38 D ’autres « abstractions »
Modèle structurel D ’autres « abstractions » associations particulières (composition / agrégation) spécialisation / généralisation

39 Composition Modèle structurel Association particulière Tout /partie
Fenêtre 0..2 Barre titre Fond Frontière Barre Ascenseur 2 Titre Bouton Ferm Flèche Indicateur

40 Agrégation Modèle structurel Sémantique Collection/Élément Pays Forêt
1 Forêt 1..n 1 Région 1..n 1 Arbre 1..n Département

41 Composition / Agrégation
Modèle structurel Composition / Agrégation Contraintes - Exclusivité / Partage - Dépendance / Indépendance Propagation / Diffusion

42 Mécanismes d’inférences intellectuelles de caractéristiques
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

43 Généralisation / Spécialisation
Modèle structurel Généralisation / Spécialisation Personne nom adresse {disjoint} Étudiant num_carte adresse Enseignant grade adresse enseigner

44 ... ... ... Généralisation / Spécialisation Modèle structurel
Équipement Type d'équipement ... Pompe Réservoir Échangeur Type de pompe Type de réservoir ... ... Pompe Cent. Pompe Imm. Réservoir Press.

45 Généralisation / Spécialisation multiple
Modèle structurel Généralisation / Spécialisation multiple Véhicule Véhicule aquatique Véhicule terrestre Auto Véhicule amphibie Bateau

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

47 Généralisation / Spécialisation
Modèle structurel Généralisation / Spécialisation 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 ».

48 Les contraintes sont héritées.
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.

49 Les contraintes: Exemples de contraintes sur associations
Modèle structurel Les contraintes: Exemples de contraintes sur associations membreDe Chemin Personne * * Comité * {subset} 1 préside * 1..* {ordered} contrainte entre 2 associations contrainte sur extrémité d'association Arête

50 Les contraintes: Exemple de contraintes à différents niveaux
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 { Personne.employeur = Personne.chef.employeur } actif : Real {value  0} passif : Real <dirige chef contrainte sur attribut contrainte sur 2 associations

51 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

52 diagrammes de collaboration diagrammes de séquences
Modèle dynamique diagrammes de collaboration diagrammes de séquences diagrammes états-transitions diagrammes d'activités (non traités)

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

54 Les messages Types Synchronisation Modèle dynamique constructeurs
destructeurs sélecteurs modificateurs itérateurs asynchrone synchrone retour

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

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

57 La ligne de vie Modèle dynamique « create » :C1 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

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

59 Modèle dynamique France Poitou Bretagne LR A H G Popul() Popul()
temps Popul() Popul()

60 Événement Événement et État État d'un objet Modèle dynamique
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

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

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

63 Notation des arcs Modèle dynamique étiquette étiquette
événement(paramètres) [condition] /action

64 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.

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

66 Généralisation Modèle dynamique
- 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 E6 E5

67 Agrégation Modèle dynamique
une classe "agrégat" aura un état défini par l'agrégation des états de ses composants. Agrégation concurrente (relation et) Auto Moteur Portière Roue Arrêt Moteur portière roue Ouverte gonflée Marche point mort crevée Marche arrière Marche avant Fermée

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 Introduction Approche objet Concepts objet et formalisme UML
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

71 Des bienfaits de l ’encapsulation ….
Discussion Des bienfaits de l ’encapsulation …. Données Encapsulation Messages Opérations Proposer un service et réagir aux messages

72 La méta-modélisation Discussion Langage pour spécifier Meta-Class,
tout métamodèle Meta-Class, Meta-Attribut, etc Meta-Meta Modèle Class, Attribut, etc Langage pour spécifier un modèle Meta-Modèle Langage pour spécifier un domaine d’information Parcelle, Surface, etc Modèle Définition spécifique d’un domaine A120, 50, etc Objets utilisateur

73 UML n’est pas une méthode comme Merise
Discussion UML et Merise UML n’est 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

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

75 Outil de dialogue : Outil ouvert Discussion
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)

76 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 2000. 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 2000. Rumbaugh James, Jacobson Ivar, and Booch Grady, The Unified Modeling Language Reference Manual, X, Addison Wesley, Fall 1998

77 Livres UML (2) Conallen Jim, Concevoir des applications Web avec UML, Eyrolles , 2000. Douglass Bruce Powell, Doing Hard Time : Developping Real-Time Systems with UML, Addison Wesley, 1999. 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, 2000. Roques Pascal, UML par la pratique, Eyrolles, 2001. Schmuller Joseph, Teach Yourself UML in 24 Hours, Sams Publishing, 1999 Texel Williams, Uses cases combined with Booch/OMT/UML, Prentice Hall, 1998