[French Fr Logiciel Software Tutorial Programmation Java C++

Concepts et méthodologie Objet illustrés par Java et C++ Référence OO-100 Guide étudiant Sun Microsystems France S.A. Service Formation 143 bis, avenue de Verdun 92442 ISSY LES MOULINEAUX Cedex Tel 41 33 17 17 Fax 41 33 17 20 Révision D, Fevrier 1999 Document non révisable  1997 Sun Microsystems, Inc.—Printed in the United States of America. 2550 Garcia Avenue, Mountain View, California 94043-1100 U.S.A. Tous droits réservés. Ce produit ou document est protégé par un copyright et distribué avec des licences qui en restreignent l'utilisation, la copie, la distribution, et la décompilation. Aucune partie de ce produit ou de sa documentation associée ne peut être reproduite sous aucune forme, par quelque moyen que ce soit, sans l'autorisation préalable et écrite de Sun et de ses bailleurs de licence, s'il y en a. Des parties de ce produit pourront être dérivées du système UNIX® licencié par Novell, Inc. et du système Berkeley 4.3 BSD licencié par l'Université de Californie. UNIX est une marque enregistrée aux Etats-Unis et dans d'autres pays et licenciée exclusivement par X/Open Company Ltd. Le logiciel détenu par des tiers, et qui comprend la technologie relative aux polices de caractères, est protégé par un copyright et licencié par des fournisseurs de Sun. Sun, Sun Microsystems, le logo Sun, [ATTRIBUTION OF ALL OTHER SUN TRADEMARKS MENTIONED SIGNIFICANTLY THROUGHOUT PRODUCT OR DOCUMENTATION. DO NOT LEAVE THIS TEXT IN YOUR DOCUMENT !] sont des marques déposées ou enregistrées de Sun Microsystems, Inc. aux Etats-Unis et dans d'autres pays. Toutes les marques SPARC, utilisées sous licence, sont des marques déposées ou enregistrées de SPARC International, Inc. aux Etats-Unis et dans d'autres pays. Les produits portant les marques SPARC sont basés sur une architecture développée par Sun Microsystems, Inc. [THIRD PARTY TRADEMARKS THAT REQUIRE ATTRIBUTION APPEAR IN `TMARK.' IF YOU BELIEVE A THIRD PARTY MARK NOT APPEARING IN `TMARK' SHOULD BE ATTRIBUTED, CONSULT YOUR EDITOR OR THE SUN TRADEMARK GROUP FOR GUIDANCE.] Les interfaces d'utilisation graphique OPEN LOOK® et SunTM ont été développées par Sun Microsystems, Inc. pour ses utilisateurs et licenciés. Sun reconnaît les efforts de pionniers de Xerox pour la recherche et le développement du concept des interfaces d'utilisation visuelle ou graphique pour l'industrie de l'informatique. Sun détient une licence non exclusive de Xerox sur l'interface d'utilisation graphique Xerox, cette licence couvrant aussi les licenciés de Sun qui mettent en place l'interface d'utilisation graphique OPEN LOOK et qui en outre se conforment aux licences écrites de Sun. Le système X Window est un produit de X Consortium, Inc. CETTE PUBLICATION EST FOURNIE "EN L'ETAT" SANS GARANTIE D'AUCUNE SORTE, NI EXPRESSE NI IMPLICITE, Y COMPRIS, ET SANS QUE CETTE LISTE NE SOIT LIMITATIVE, DES GARANTIES CONCERNANT LA VALEUR MARCHANDE, L'APTITUDE DES PRODUITS A RÉPONDRE A UNE UTILISATION PARTICULIERE, OU LE FAIT QU'ILS NE SOIENT PAS CONTREFAISANTS DE PRODUITS DE TIERS. Table des matières Vision objet pour le développement..................................................... 1-1 Technologies objet............................................................................ 1-2 Présentation du concept objet ........................................................ 1-4 Identité et classification................................................................... 1-6 Abstraction et Encapsulation ......................................................... 1-8 Passage de messages...................................................................... 1-12 Association et Agrégation............................................................. 1-14 Héritage et polymorphisme.......................................................... 1-20 Méthodes objet .......................................................................................... 2-1 Analyse et conception orientées objet ........................................... 2-2 Caractéristiques des méthodologies.............................................. 2-4 Méthodes orientées traitements..................................................... 2-6 Méthodes orientées Données ....................................................... 2-14 Méthodes orientées Données : Merise ........................................ 2-16 Principales méthodologies objet .................................................. 2-30 Présentation d’OMT ...................................................................... 2-38 OMT : Modélisation Statique ....................................................... 2-40 OMT : Modélisation Dynamique................................................. 2-48 OMT : Modélisation Fonctionnelle.............................................. 2-56 Différentes étapes en analyse objet.............................................. 2-58 Approche objet et méthodes orientées Traitements.................. 2-60 Approche objet et méthodes orientées Données ....................... 2-62 Développement orienté objet ................................................................. 3-1 Passage de l’analyse à la conception ............................................. 3-2 Types abstraits et identité d’objet .................................................. 3-8 Polymorphisme : staticité, dynamicité, virtualité ..................... 3-10 Classes et métaclasses.................................................................... 3-14 Gestion de la mémoire................................................................... 3-16 Langages orientés objet ................................................................. 3-18 Catalogue des langages purs........................................................ 3-20 Catalogue des langages hybrides ................................................ 3-22 Internet et Java................................................................................ 3-26 iii Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 Java : une plate-forme applicative universelle........................... Principes de fonctionnement........................................................ Classe ............................................................................................... Constructeur et destructeur.......................................................... Allocation ........................................................................................ Envoi de message........................................................................... Agrégation ...................................................................................... Héritage ........................................................................................... Polymorphisme .............................................................................. Atelier de Génie Logiciel............................................................... Outils d’Upper CASE orientés objet............................................ Outils du Lower CASE orientés objet ......................................... Présentation de Visual WorkShop C++ ...................................... Présentation d’un AGL ................................................................. Exercices .......................................................................................... 3-30 3-32 3-34 3-38 3-42 3-44 3-46 3-48 3-50 3-56 3-58 3-60 3-62 3-64 3-66 Objets en application ............................................................................... 4-1 Standards de l’objet ......................................................................... 4-2 CORBA .............................................................................................. 4-4 ORB .................................................................................................... 4-6 Services CORBA et facilités communes...................................... 4-10 Orbix d’IONA................................................................................. 4-16 Solutions d’objets distribués avec Java ....................................... 4-18 Architecture de composants objets.............................................. 4-22 Relationnel et objet......................................................................... 4-24 Principes des SGBDO .................................................................... 4-30 Approche langage ou objet persistant ........................................ 4-32 Approche Base de données objet intégrée.................................. 4-34 Modèle objet de l’ODMG.............................................................. 4-36 Langage d’interrogation OQL...................................................... 4-38 Marché des SGBDO ....................................................................... 4-40 Corrections de l’étude de cas .................................................................A-1 Index ............................................................................................................... 1 iv Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 Vision objet pour le développement 1 Objectifs ■ Présenter le concept objet ■ Identité ■ Classification ■ Encapsulation ■ Passage de messages ■ Association et agrégation ■ Héritage ■ Polymorphisme ■ Abstraction Exercice ■ Exercice simple de modélisation objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 1-1 1 Technologies objet GUI (Graphic User Interface) Programmation par objet Outils objet Méthodes objet Bases de données objet Systèmes d’exploitation objet 1-2 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 11 1 Technologies objet Initialement cantonnés aux environnements de développement et aux langages de programmation, l’objet s’est étendu depuis les années 1990, aux méthodologies de conception et aux bases de données. Mais déjà les systèmes d’exploitation et les architectures distribuées sont de nouveaux champs d’investigation de l’objet. Ce cours ne consacre pas beaucoup de place à cette dernière émergence et s’attache d’avantage à dresser un panorama de l’objet dans le domaine de la conception : a. Méthodes, b. Outils de conception/spécification et AGL, c. Langages de programmation, d. Bases de données. On s’attachera dans la limite du possible à fournir des catalogues des différents produits disponibles sur le marché dans ces divers domaines ainsi qu’une comparaison avec ceux qui se rattachent d’avantage à des méthodes/outils traditionnels. Vision objet pour le développement Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 1-3 1 Présentation du concept objet Une personne se présenter Prénom Nom Age lire courir 1-4 Modularisation Communication par messages Encapsulation Héritage Classification Polymorphisme Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 11 1 Présentation du concept objet Ce dessin représente une personne. Une personne peut se présenter en énonçant son prénom, son nom, son âge, etc. Elle peut lire, courir, etc. Nous pouvons retrouver ici les concepts fondamentaux des objets : 1. Modularisation C’est le développement logiciel en petits modules, appelés objets. Les objets regroupent des structures de données et les opérations autorisées sur ces données. 2. Identité et classification On regroupe les objets ayant le même comportement pour les les traiter comme faisant partie de la même classe. 3. Encapsulation C’est la distinction claire entre les interfaces de l’objet, qui décrivent ce que l’objet réalise, et son implémentation définissant comment il le fait et ce qu’il a à faire. 4. Communication par messages Un objet demande à un autre objet un service, indépendamment de "comment" et "où" l’objet distant est implémenté. 5. Héritage On veut pouvoir réutiliser des classes existantes en définissant de nouvelles classes qui héritent des caractéristiques de la première. 6. Polymorphisme Il est possible à divers objets de classes héritées de répondre au même message. Vision objet pour le développement Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 1-5 1 Identité et classification objets (Personne) (Personne) (Personne) Lazare Garcin 30 Classe Personne Prénom Nom Données Age courir lire se présenter 1-6 Services Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 11 1 Identité et classification Identité L’identité signifie que les données sont regroupées en entités discrètes et identifiables appelées objets. Il est possible d’avoir deux objets ayant les mêmes données. Nous pouvons les différencier en utilisant une adresse, un index ou en donnant une valeur unique à une donnée. Par exemple, des jumeaux sont quand même deux personnes différentes. Classification Les objets ayant la même structure de données et les mêmes services sont groupés dans une Classe. Une Classe est une abstraction des informations nécessaires pour une application particulière. Une Classe est la description d’un nombre indéfini d’objets. Nous pouvons donc dire qu’un objet est une instance de sa Classe. Un objet connaît son genre car il contient une référence implicite à sa propre Classe. Vision objet pour le développement Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 1-7 1 Abstraction et Encapsulation Abstraction Classe = Type abstrait de données Personne Prénom Nom Age courir lire se présenter 1-8 Données Services Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 11 1 Abstraction et Encapsulation L’Abstraction et l’Encapsulation ne sont pas des concepts uniquement liés à l’orienté objet mais ils y sont très bien intégrés en particulier grâce à l’Héritage et au Polymorphisme. Abstraction L’Abstraction est une vue générique d’une entité permettant de ne pas être limité par des contraintes d’ordre technique ou matériel. Une classe peut être appelée un type abstrait de données (A.D.T. / Abstract Data Type). La puissance de l’abstraction est renforcée par les effets multiplicateurs apportés par l’héritage et le polymorphisme de l’objet. Vision objet pour le développement Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 1-9 1 Abstraction et Encapsulation Encapsulation Personne Prénom Nom Age Adresse courir se présenter lire voir ■ ■ 1-10 Données privées Données publiques Services privés Services publics Interface publique d’un objet : ■ Accès libre au monde extérieur ■ A pour vocation de contenir l’interface de l’objet (services) ■ Des données peuvent aussi être publiques Interface privée d’un objet : ■ Accès interdit au monde extérieur ■ Contient les données vitales de l’objet ■ Contient les services de gestion des données privées ■ Contient les services d’action sur l’environnement liés à l’état de l’objet Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 11 1 Abstraction et Encapsulation Encapsulation L’objet est indépendant parce qu’il peut gérer lui même ses données internes. Ceci implique que l’objet soit seul à pouvoir accéder à ces données vitales. Nous pouvons donc distinguer deux types de propriétés (données et services) : ■ les propriétés publiques, d’interface ou en libre accès, ■ les propriétés privées, d’accès exclusivement réservé à l’usage de l‘objet. Les propriétés publiques Les services et données publics sont destinés à réaliser l’interface avec l’environnement. C’est par ces services que l’environnement peut véhiculer ses messages à destination de l’objet. Dans notre exemple, nous pouvons dire que les services lire et voir sont publics car ils peuvent être mis en oeuvre par des messages venant directement de l’extérieur. Les propriétés privées Ce sont les parties de l’objet auxquelles l’environnement n’a aucun droit d’accès direct. Dans notre exemple, nous pouvons définir se présenter comme un service privé. Il est possible d’imaginer que le service se présenter ne sera mis en oeuvre que si l’objet a été mis dans l’état pas connaître par le service public voir. De même, un service de gestion de la donnée privée Age pourrait être créé, pour la remettre à jour chaque année. Vision objet pour le développement Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 1-11 1 Passage de messages ■ Les objets inter-agissent par échange de messages ■ Prise en charge par les méthodes de l’interface publique Lire !! implémentation Interface publique ■ 1-12 Message : ■ Objet destinataire ■ Méthode à activer sur cet objet ■ Paramètres Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 11 1 Passage de messages Les objets communiquent entre eux en s’envoyant des messages. Un objet envoie un message à un autre objet lequel peut répondre, changer d’état ou réagir d’une toute autre façon. Les objets peuvent seulement interagir à travers leurs interfaces publiques. On peut citer, comme exemple de passage de messages, un appel téléphonique entre deux personnes, un signal électrique entre le démarreur et le moteur d’une machine etc. Les messages sont pris en charge par les méthodes de l’interface publique de l’objet destinataire. Prenons l’exemple d’une expression arithmétique : num1 + num2. L’objet num1 reçoit le message "+ num2". Le + permet à l’objet num1 d’identifier la méthode (que l’objet devra appliquer à lui-même) alors que num2 est le paramètre de cette méthode. Vision objet pour le développement Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 1-13 1 Association et Agrégation Deux types de relations Collaboration objets stylo, encre, main et papier La main associé l’encre du stylo à l’objet papier Le stylo est composé d’une plume, d’un réservoir etc Exemples d’associations “uses” “Utilise” Une relation est souvent décrite comme un contrat Un objet contracte un service auprès d’un autre. La personne utilise l’ordinateur... La personne ne contient pas l’ordinateur pas plus que l’ordinateur ne contient la personne... 1-14 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 11 1 Association et Agrégation Les objets interagissent à travers des associations ou des agrégations. Une agrégation est une relation de contenant lorsqu’un objet contient un autre objet ; très souvent, l’objet contenu est un composant de l’objet plus général. Une association correspond à la décision de deux objets indépendants de collaborer pour réaliser un but commun. Après l’atteinte du but, ils peuvent continuer à exister indépendamment l’un de l’autre. Association Des objets sont associés lorsque l’un d’entre eux utilise les services et les opérations d’un autre. Le taille-crayon offre un service aux objets crayons. Le crayon utilise le taille-crayon pour réaliser un but précis : avoir une mine pointue. Une relation d’agrégation serait dans ce cas inapplicable : un taillecrayon ne peut pas être un composant du crayon ou vice-versa. Les associations doivent être effectuées à la main. Les objets sont créés simplement avec un potentiel d’association avec les autres. En revanche, pour l’agrégation, la gestion est automatique. Vision objet pour le développement Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 1-15 1 Association et Agrégation Exemples d’agrégations Un crayon est composé d’un objet mine et d’un objet corps en bois. Sans mine, un crayon ne serait pas un crayon. Un nombre flottant 3.1459 Mantisse Exposant Nom Un employé Age Adresse Prénom Association ou agrégation ? "possède" ou "utilise" Dans cette relation, est-ce que le réveil est associé aux aiguilles ou possède les aiguilles ? 1-16 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 11 1 Association et Agrégation Agrégation L’agrégation intervient lorsqu’un objet est contenu à l’intérieur d’un autre. Dans beaucoup de cas, il n’est fondamental pour l’objet d’exister indépendamment d’un autre. Dans ce cas, l’agrégation est la relation la plus adaptée. Cela a peu de sens pour un crayon d’exister sans mine. Mais un crayon sans mine est-il réellement un crayon ? L’agrégation permet d’augmenter le niveau d’abstraction dans le système du fait que les objets (comme la mantisse et l’exposant d’un nombre flottant) sont cachés derrière l’interface publique de la classe contenant (le nombre flottant). Agrégation ou Association? Il n’est pas toujours facile de faire un choix entre agrégation et association. Utilisation de l’agrégation Si on modélise le réveil en utilisant l’agrégation alors il contient toujours les aiguilles et ne peut exister sans ce composant fondamental. Utilisation de l’association Si on modélise le réveil à travers les associations, quels seront les objets en relation ? L’objet boîtier et l’objet aiguilles correspondent à deux objets qui interagissent pour constituer l’objet réveil. Vision objet pour le développement Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 1-17 1 Association et Agrégation Résumé ■ ■ 1-18 Association ■ Implémentation de la relation utilise ■ Création des objets obligatoires ■ Flexible ■ Utilisation fréquente avec des objets composés d’éléments interchangeables ou pré-existants Agrégation ■ Implémentation de la relation possède ■ Les composants sont créés automatiquement ■ Augmentation du niveau d’abstraction dans la phase de conception ■ Non flexible Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 11 1 Notes Vision objet pour le développement Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 1-19 1 Héritage et polymorphisme ■ Exemple de la personne Personne Nom: string Prénom: string Age: integer courir lire se présenter {abstrait} Anglais Allemand se présenter se présenter ■ Autres exemples Superclasse Classes dérivées ... Basket ball Balle Football Méthode taper Tennis Méthode taper 1-20 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 11 1 Héritage et polymorphisme Héritage L’héritage est le partage des données et des services entre des classes ayant une relation hiérarchique. Une Classe peut avoir une définition large et être ensuite affinée par des classes dérivées. Chacune de ces sous-classes hérite de toutes les propriétés (données et services) de la classe lui étant hiérarchiquement supérieure sans avoir à les répéter et ajoute ses propres propriétés. Nous pouvons par exemple affiner la Classe Personne suivant la nationalité ou la langue maternelle tout en gardant les propriétés de base telles que Prénom, Nom et Age. Cette possibilité de factoriser dans une classe, que l’on peut appeler superclasse, des propriétés communes à d’autres classes est un des avantages principaux de l’orienté objet car il permet de réduire la répétition et permet la réutilisation. Polymorphisme Le polymorphisme veut dire que le même service, aussi appelé opération ou méthode, peut avoir un comportement différent suivant la Classe dans laquelle il est utilisé. Par exemple, la Classe Personne possède un service se présenter ; chaque personne peut se présenter mais la façon de le faire variera suivant la langue utilisée. De même, la classe Balle a une méthode taper qui peut différer en fonction du type de balle considéré : balle de Basket Ball, de Football ou de Tennis. Le polymorphisme permet de créer de nouvelles classes utilisant le même service sans avoir à modifier le code existant. Vision objet pour le développement Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 1-21 1 Héritage et polymorphisme Cas de l’héritage multiple ■ Exemple d’héritage multiple Commercial Manager Manager commercial ■ Problème d’ambiguité Personne Nom commercial Manager Nom Nom Manager commercial Nom Nom Quel est mon nom ? 1-22 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 11 1 Héritage et polymorphisme Cas de l’héritage multiple L’héritage multiple est une technique qui consiste à dériver de nouvelles classes à partir de plusieurs classes de base. Cela est très utile lorsqu’on modélise des objets qui nécessitent la combinaison de deux ou plusieurs autres types. Dans l’exemple ci-joint, une nouvelle classe Manager commercial dérive de plus d’une classe de base : de ce fait, il contient les attributs et méthodes de ses deux classes de base ainsi que tout membre additionnels nécessaires. Mais l’héritage multiple introduit un problème lorsque les classes de base dérivent d’une même classe commune. Dans l’exemple ci-joint, l’attribut Nom de la classe Personne apparaît deux fois dans la classe Manager commercial. On peut donc parler d’ambiguïté. La solution à cette ambiguïté est résolue différemment selon les langages orientés objet. Vision objet pour le développement Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 1-23 1 Nouvelle terminologie 1-24 ■ Objet ■ Classe ■ Abstraction ■ Encapsulation ■ Attributs, états, données ■ Comportement, méthodes, opérations ■ Membres privés ■ Membres publiques, interface ■ Modélisation de l’objet ■ Association et Agrégation ■ Héritage ■ Polymorphisme Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 11 1 Exercice 1. Faire la liste des objets présents dans la salle de cours. On précisera en particulier : ■ les états et les opérations, ■ Quels sont les membres publics et privés. 2. Procéder à la classification des objets en favorisant le polymorphisme. 3. Identifier les relations de type agrégation et association. 4. Créer des hiérarchies dans vos classes et : ■ introduire, si possible, l’héritage multiple, ■ identifier dans ce cas les ambiguïtés possibles. Vision objet pour le développement Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 1-25 1 Notes 1-26 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 Méthodes objet 2 Objectifs ■ ■ ■ ■ Faire un rappel sur les méthodes orientées Traitements : ■ Les différentes méthodes ■ Les décompositions fonctionnelles successives ■ La représentation dynamique Faire un rappel sur les méthodes orientées Données : ■ Les principales méthodes ■ Les trois axes de modélisation ■ Le concept Merise Présenter : ■ Les principales méthodologies objet ■ Les trois axes de modélisation objet ■ La technique de modélisation objet Comparer ces méthodes à la modélisation objet Evaluation ■ Proposition d’étude de cas Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-1 2 Analyse et conception orientées objet Rappels Modèle de développement Analyse Conception Codage Test Maintenance Analyse Conception Codage “Object-oriented design defines a notation and process for constructing complex software systems, and offers a rich set of logical and physical models with which we may reason about different aspects of the system...” Grady Booch “Object-oriented modelling and design is a new way of thinking about problems using models organized around real-world concepts.” James Rumbaugh Apport de l’objet 2-2 ■ Même sémantique en Analyse et conception et en codage ■ Modularité et réutilisabilité favorisent tests et maintenance Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Analyse et conception orientées objet Méthodes de développement classiques Un des principaux problèmes en développement classique (5 phases : analyse, conception, codage, test, maintenance) est que chaque étape utilise des notations et descriptions spécifiques. Ces différences radicales font que les modifications sont souvent difficiles du fait des changements de sémantique d’une phase à l’autre. Les méthodes objet sans changer la succession des phases de développement vont permettre, comme nous allons le voir, de réduire le temps de développement et de faciliter les résolutions de problèmes tardifs. Analyse orientée objet ■ Trouver les objets potentiels et les caractériser. ■ Construire un modèle abstrait en conservant une stricte correspondance entre ce modèle et les objets réels. Conception orientée objet ■ Rechercher la structure du système (conception système) puis du logiciel (conception logicielle). Programmation, test et maintenance ■ Implémenter avec un langage supportant objets, classes et messages à la place des traditionnelles fonctions. ■ Réutiliser massivement le code existant. ■ Tester les modules (objets). ■ Maintenir des librairies d’objets modulaires plus facilement compréhensibles par des personnes tierces. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-3 2 Caractéristiques des méthodologies Trois axes de modélisation Fonctionnelle (Flux/Processus) Dynamique (Scénario, Etat/Transition) Statique (objets) 2-4 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Caractéristiques des méthodologies Trois axes de modélisation Modèle Statique Le modèle statique, aussi appelé modèle objet, décrit la structure des objets dans le système tel que leurs identités, leurs données, leurs services et les relations entre les objets. C’est une représentation conceptuelle et graphique des données et des services essentiels pour une application, sous la forme de diagrammes de classes d’objets. On parle de modèle Entité-association évolué. Modèle Dynamique Le modèle dynamique décrit les parties du système où le temps et le séquencement des opérations sont d’importance. Il est représenté graphiquement avec des diagrammes à états. Chaque diagramme représente les états et les événements possibles pour une classe dans le système. Il existe une référence entre le modèle dynamique et les autres modèles. Les actions dans les diagrammes à états correspondent aux fonctions du modèle fonctionnel et les événements dans le scénario deviennent des services dans les classes du modèle statique. Modèle Fonctionnel Le modèle fonctionnel décrit ce que fait le système sans se soucier des contraintes temporelles ou événementielles. Il est représenté graphiquement par des diagrammes de flux de données où l’on décrit les fonctions et leurs entrées/sorties sans décrire leurs mécanismes. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-5 2 Méthodes orientées traitements Les méthodes de décompositions fonctionnelles SA/SD : Structured Analysis/Structured Design SA-RT : Structured Analysis-Real Time SADT : Structured Analysis Design Technique Les axes de Modélisation Fonctionnelle (Flux/Processus) Dynamique (Etat/Transition, Scénario) 2-6 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Méthodes orientées traitements Rappels Historiquement, les méthodes commencent dans les années 1960 avec des approches simples comme les réseaux de Pétri, les méthodes orientées traitements, puis les méthodes orientées Données (EntitéRelation ou Entité-Association). Les méthodes de décompositions fonctionnelles sont certainement les plus utilisées à l’heure actuelle en informatique technique et scientifique. Elles reposent principalement sur les diagrammes de flux de données. Il n’y a pas de standard mais il existe une littérature abondante associée à des auteurs tels que Yourdon, DeMarco, Mellor. Elles travaillent particulièrement l’axe fonctionnel et l’axe dynamique. Alors que la méthode SA/SD se concentre sur l’axe fonctionnel, la méthode SA-RT ajoute réellement l’axe dynamique. SADT réalise la fusion des deux premières méthodes. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-7 2 Méthodes orientées traitements Décompositions fonctionnelles successives Fonctionnelle (Flux/Processus) Dynamique (Scénario,Etat/Transition) Décomposition de l’activité Technico-commerciale tion ven nter Ingénieur Commercial d’i de Système an em D n i Ou form ivi e de Gérer l’activité Technico-Commerciale Su n atio es ns po Ré D at e nt em clie d an D ou no Formation 2-8 Client Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Méthodes orientées traitements Décompositions fonctionnelles successives Dans un premier temps, on définit le domaine d’étude en recherchant les acteurs externes du système générant les entrées et recevant les sorties. Une décomposition du système sera exécutée en utilisant des diagrammes de flux successifs jusqu’à l’obtention de la forme la plus simple que l’on pourra coder facilement. Tout au long de cette décomposition, nous retrouverons les entrées et les sorties définies au départ. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-9 2 Méthodes orientées traitements Décompositions fonctionnelles successives Première décomposition Système Demande d’intervention Prendre rendez-vous Oui ou non Seconde décompositon Système Processus "Prendre rendez-vous" Agenda Demande Vérifier d’intervention Da te OK Mettre à jour 2-10 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 Oui ou Non 22 2 Méthodes orientées traitements Décompositions fonctionnelles successives Dans notre exemple, nous pouvons réaliser une première décomposition en représentant une fonction Prendre rendez-vous ayant une demande d’intervention en entrée et la réponse Oui ou Non en sortie. Il est encore possible de décomposer cette fonction pour définir son fonctionnement. Nous pouvons décomposer la fonction Prendre rendez-vous en sous-fonctions. La sous-fonction Vérifier compare la date de demande d’intervention avec un système de stockage de données appelé Agenda. La flèche en pointillé représente un flux de contrôle qui sera une valeur booléenne déclenchant, si elle est vérifiée, la fonction Mettre à jour. Cette fonction pourra avoir un accès en lecture/écriture sur le système de stockage de données et générer la sortie Oui ou Non. Il est possible dans cette étape de développer ces fonctions simples en les codant à l’aide d’un langage informatique ou de pseudo-code. Certaines méthodes d’analyse structurée proposent une représentation des systèmes de stockage de données sous la forme d’EntitésAssociations. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-11 2 Méthodes orientées traitements Méthodes orientées Traitements : modélisation dynamique Fonctionnelle (Flux/Processus) Dynamique (Scénario, Etat/Transition) Diagramme d’états Agenda fermé Date Agenda ouvert 2-12 Lecture base Mise à jour agenda si date Ok Envoyer message Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Méthodes orientées traitements Méthodes orientées Traitements : modélisation dynamique On peut faciliter la phase de codage en effectuant une représentation dynamique du processus sous la forme d’un diagramme d’états. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-13 2 Méthodes orientées Données Principales méthodes Les méthodes Entités-Associations Chen Bachman SSADM Merise Les trois axes de Modélisation en orienté Données Fonctionnel (Flux/Processus) Dynamique (Opérations) Statique (Donnée) 2-14 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Méthodes orientées Données Principales méthodes Merise est une méthode surtout utilisée en informatique de gestion. Elle est bien implantée en France, son pays d’origine. SSADM peut être considérée comme sa soeur anglo-saxonne. Trois axes de modélisation Modèle Statique Le modèle statique, aussi appelé modèle de données, décrit la structure des données dans le système et leurs associations. C’est une représentation conceptuelle et graphique des données et de leurs liens dans une application sous la forme de diagrammes d’Entités. Modèle Dynamique Le modèle dynamique décrit les parties du système où le temps et les événements sont à prendre en compte. Il est représenté graphiquement sous la forme de modèles organisationnels. Chaque diagramme représente le séquencement des opérations entre les fonctions. Modèle Fonctionnel Le modèle fonctionnel décrit ce que fait le système sans se soucier des contraintes temporelles. Il est représenté graphiquement par des diagrammes de traitement où l’on décrit les fonctions, leurs entrées/sorties et leurs opérations sans aborder leurs mécanismes. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-15 2 Méthodes orientées Données : Merise Le concept Merise Niveaux Données Traitements Modèle Conceptuel de Données (MCD) Modèle Conceptuel de Traitement s (MCT) A B Conceptuel Entité 1 Association Données 1,n 1,1 Entité 2 Données Evènements Synchronisation ET Opérations Résultat C Modèle Logique de Données (MLD) Logique et organisationnel Commercial Assistante Vue réseau Entité 1 Entité 2 Modèle Physique de Données (MPD) Physique et Opérationnel Modèle Organisationnel de Traitements (MOT) Modèle Opérationnel de Traitements (MOpT) Schéma de Base de Donnée Programmes DDL 2-16 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Méthodes orientées Données : Merise La démarche utilisée dans Merise amène à représenter divers aspects du système étudié à des points variables entre le plus concret et le plus abstrait. On parle de modélisation à divers niveaux d’abstraction. Il s’agit de hiérarchiser les préoccupations de conception à un niveau gestion, organisation et technique. Les préoccupations de gestion seront étudiées au niveau conceptuel, les problèmes d’organisation au niveau organisationnel et logique, et les préoccupations techniques au niveau physique. Niveau conceptuel Pour modéliser un système, il convient de l’analyser, dans un premier temps, de façon globale. Il faut se concentrer sur l’activité du système. Les fonctions sont décrites à ce niveau sans tenir compte de la manière dont elles seront réalisées. On représente le "quoi" du système en suivant les règles de gestion. Niveau organisationnel A ce niveau, on définit l’organisation à mettre en place pour atteindre les objectifs du niveau conceptuel. Cela peut être représenté par les questions "qui", "où" et "quand". Ce niveau est encore indépendant des choix techniques. Niveau technique Les moyens techniques, matériel et logiciel, nécessaires à la réalisation du projet sont proposés à ce niveau. En pratique, beaucoup de concepteurs ne travaille que dans les données pas dans les traitements. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-17 2 Méthodes orientées Données : Merise Fonctionnelle (Flux/Processus) Dynamique Statique (Données) Modèle Conceptuel de Données Département Salarié No salarié Nom salarié Prénom salarié Adresse salarié 2-18 No dép. 0,n Travaille - Titre - Grade - Date d’entrée 1,n Nb d’empl. dép. Libellé dép. Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Méthodes orientées Données : Merise Modèle Conceptuel de Données Le Modèle Conceptuel de Données (MCD) représente un ensemble d’Entités associées par des liens et des cardinalités. Une Entité est représentée par un rectangle. Le nom de l’Entité est dans la partie haute, suivi par son identifiant souligné d’un trait puis du nom des données. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-19 2 Méthodes orientées Données : Merise Modèle Logique de Données Salarié No salarié Nom salarié Prénom salarié Adresse salarié Salarié 2-20 0,n Travaille - Titre - Grade - Date d’entrée Travaille Département 1,n No dép. Nb d’empl. dép. Libellé dép. Département Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Méthodes orientées Données : Merise Modèle Logique de Données Le modèle conceptuel permet de traduire le langage naturel et aide à la communication mais il est encore éloigné de la rigueur nécessaire au passage à l’informatique. Le Modèle Logique de Données (MLD) est une représentation du MCD intégrant les choix d’organisation des données (hiérarchique, réseau ou relationnel). Le MLD permet de préfigurer ce que seront les temps d’accès nécessaires et les volumes occupés par la base de données. Le passage du Modèle Conceptuel de Données au Modèle Logique de Données se fait en appliquant des règles d’algorithme très simples basées sur le type de relation et les cardinalités. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-21 2 Méthodes orientées Données : Merise Modèle Physique de Données CREATE TABLE I.T.C. (No_de_salarié ID not null, Nom char(30) not null, Prénom Adresse Grade char(30) , char(120) not null, char(10) , PRIMARY KEY (No_de_salarié)); 2-22 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Méthodes orientées Données : Merise Modèle Physique de Données Le Modèle Physique de Données (MPD) correspond à la création de la table suivant les règles d’organisation interne de la base de données avec laquelle on travaille. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-23 2 Méthodes orientées Données : Merise Fonctionnelle (Flux/Processus) Dynamique Statique (Données) Modèle Conceptuel des Traitements Agenda Demande d’intervention ET Mettre à jour agenda OK No de l’affaire Agenda à jour Pas OK Date refusée Créer dossier Dossier 2-24 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Méthodes orientées Données : Merise Modèle Conceptuel de Traitements Le Modèle Conceptuel de Traitements (MCT) représente les événements, leurs synchronisations, les opérations et les résultats. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-25 2 Méthodes orientées Données : Merise Modèle Organisationnel des Traitements Temps I.T.C. Agenda I.C. Demande d’intervention pf1 Mise à jour agenda Agenda à jour Date refusée No de l’affaire pf3 Création du dossier Modification de la pf2 demande d’intervention Dossier créé Nouvelle demande d’intervention 2-26 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Méthodes orientées Données : Merise Modèle Organisationnel de Traitements Le Modèle Organisationnel de Traitements (MOT) est la description dynamique du système d’information. L’opération est remplacée par la procédure fonctionnelle qui représente l’ensemble des traitements et leurs séquencements. Ce modèle décrit également les postes de travail ce qui permet de définir le flux de informations à l’intérieur de l’entreprise. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-27 2 Méthodes orientées Données : Merise Modèle Opérationnel de Traitements Niveaux Données Traitements MCD C MCT Temps I.T.C. Agenda L et O I.C. Demande d’intervention Mise à jour agenda MLD Agenda à jour Date refusée No de l’affaire Création du dossier Modification de la Dossier créé CREATE TABLE I.T.C. P et O (No_de_salarié ID not null, Nom char(30) not null, Prénom char(30) , Adresse char(120) not null, Grade char(10) MOpT , PRIMARY KEY (No_de_salarié)); 2-28 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Méthodes orientées Données : Merise Modèle Opérationnel de Traitements Le Modèle Opérationnel de Traitements (MOpT) est le développement de l’application dans un langage informatique. Il doit prendre en compte la définition des tables et la représentation dynamique du système. La méthode reste vague sur cette phase et la dichotomie entre les données et les traitements dans les méthodes orientées Données n’en favorise pas le développement. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-29 2 Principales méthodologies objet Historique des méthodes 1986 BOOCH, GOOD 1987 HOOD 1988 Shlaer/Mellor 1989 Coad/Yourdon Objectory, OMT, CRC 1990 1991 SYNTHESIS, MOOD, BOOCH SOMA, OOM, OSA, OSDL 1992 1993 OOJSD, ORCA, FUSION, SYNTROPY, BOOCH ORCA, OBA Principales méthodes 2-30 ■ OOA/OOD (Object Oriented Design) - Coad Yourdon ■ BOOCH - Booch ■ HOOD (Hierarchical Object Oriented Design) ■ OOA/D (Object Oriented Analysis) - Shlaer et Mellor ■ OMT (Object Modeling Technique) - Rumbaugh ■ Objectory - Jacobson Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Principales méthodologies objet C’est dans les années 1980 que Booch introduit une nouvelle approche. Coad-Yourdon, Rumbaugh avec OMT (Object Modeling Technique) ainsi que de nombreuses méthodes européennes apparurent, alors. OOA/OOD (Coad-Yourdon) Méthode très généraliste, plus adaptée à l’analyse qu’à la conception. BOOCH (Grady Booch) La partie conception est plus développée que la partie analyse. Une très bonne recherche au niveau de l’héritage et des classes. HOOD (Hierarchical Object Oriented Design) Méthode plus temps réel avec une lacune au niveau de l’héritage et l’absence de méthode réelle pour l’analyse. Elle a été normalisée par un groupe d’utilisateurs. OOA/D (Shlaer et Mellor) Méthode séparant l’analyse en trois phases, comme la méthode OMT mais elle s’apparente plus à une extension d’une méthode Entité Relation. OMT (Object Modeling Technique de Rumbaugh) Méthode d’analyse et de conception basée sur les trois axes : une modélisation statique des objets, une modélisation dynamique des états et des évènements, et une modélisation fonctionnelle. C’est une méthodologie très complète et bien diffusée. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-31 2 Principales méthodologies objet Principales méthodes ■ UML (Unified Modeling Language - Rumbaugh, Booch et Jacobson) ■ FUSION - Coleman ■ ROOM - Real time Object Oriented Modeling ■ CLASSE-RELATION - Desfray ■ Merise objet Méthodes en cours de stabilisation : beaucoup d’évolutions sont encore en cours. 2-32 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Principales méthodologies objet Principales méthodes UML (Unified Modeling Language) Langage support de modélisation objet : les concepts sont issus des travaux communs de Booch, Rumbaugh et Jacobson. Le langage a la vocation d’être utilisé (formalisme) dans le cadre d’autres méthodologies. FUSION Née dans les laboratoires d’HP, cette méthode permet de couvrir les phases d’analyse, de conception et d’implémentation. FUSION guide l’utilisateur tout au long du processus de développement. ROOM Cette méthode est préconisée pour les applications Temps Réel, privilégiant les aspects structures et dynamiques. Trois graphes d’héritage complémentaires sont proposés : un pour la structure, un pour le comportement et un dernier pour les données. Cette approche est très proche de LDS 92, langage de conception utilisé dans les TELECOMS. CLASSE-RELATION Méthode d’origine française utilisée par l’outil Objecteering de Softeam, elle propose trois types de modèles : le modèle objet (notion de schéma), le modèle opératoire (service offert par les classes) et le modèle dynamique. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-33 2 Principales méthodologies objet Quelques notations FUSION Employé S&M Employé Classe OMT Employé Salaire : réel *Matricule Salaire Attributs Salaire Augmenter(N) Opérations Donner Prime (Montant) Héritage Agrégation Association 2-34 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Principales méthodologies objet Quelques notations Les notations des différentes méthodes sont proches, mais certains différences existent comme : ■ En Fusion, les opérations apparaissent dans un autre schéma que le modèle objet : ce sont les graphes d’interaction. ■ En Fusion, la représentation de l’agrégation utilise des blocs imbriqués. ■ Certains symboles de BOOCH sont utilisés en OMT avec une signification différente. Dans la suite du chapitre, nous utiliserons le formalisme d’OMT. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-35 2 Principales méthodologies objet Positionnement des méthodologies orientées objet BOOCH HOOD Axes Statique oui Dynamique oui oui Fonctionnelle OOA/ OOD OMT oui oui oui oui oui oui oui FUSION ROOM Classe Relation Axes Statique oui Dynamique oui Fonctionnelle oui 2-36 OOAD /S &M oui oui oui oui oui Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Principales méthodologies objet Positionnement des méthodologies orientées objet En application du modèle objet, certaines méthodes se voient complétées pour se spécialiser dans tel ou tel domaine. Les cases blanches du tableau ne veulent pas forcement dire qu’un axe n’est pas pris en compte dans telle méthode mais plutôt que cet axe ne ressort pas comme un point fort de la méthode. OMT semble être la méthodologie objet la plus diffusée et la plus utilisée, en particulier en France. Ceci est certainement dû en partie à la globalité de la méthode et à l’existence de plusieurs outils du Génie Logiciel la supportant. Alors qu’OMT est plutôt orientée analyse, Booch offre des éléments intéressants en phase de conception. UML intègre ces deux points forts pour donner toute la puissance d’une méthode objet. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-37 2 Présentation d’OMT La méthode OMT Statique Analyse Fonctionnelle Dynamique Scenario Flux d’événement Etat/transition Statique Conception Réalisation Contexte Flux de données Fonctionnelle Dynamique Classe Données Services 2-38 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Présentation d’OMT La technique de modélisation objet OMT (Object Modeling Technique) intervient sur les trois axes dynamique, statique et fonctionnel mais également sur trois niveaux analyse, conception et au niveau de la classe informatique que l’on peut aussi appeler le niveau physique. La méthode OMT consiste en un affinage successif par niveau en ajoutant des considérations systèmes, techniques et physiques liées à l’environnement et aux langages informatiques utilisés pour la mise en oeuvre de l’application ; le résultat final consiste en des classes définies avec leurs données typées et le développement des services associés. Pour modéliser les classes et les objets, OMT utilise un symbolisme qui lui est propre. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-39 2 OMT : Modélisation Statique classe objets (Personne) Marie Durant 31 Personne Prénom Nom (Personne) Jean Martin 28 Age courir lire se présenter (Personne) Lazare Garcin 30 Société Nom Adresse 2-40 Données Travaille pour Salaire Titre Services . Personne Prénom Nom Age courir lire se présenter Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 OMT : Modélisation Statique objets Nous pouvons définir un objet comme étant une abstraction d’une chose existante, fournissant une base pratique pour le développement d’une application informatique. Il n’existe pas une seule façon de représenter un problème en objets puisque la décomposition dépend de notre jugement et de la nature du monde que l’on cherche à décrire. Chaque objet possède une identité propre lui permettant de le distinguer des autres. Cela veut dire que les objets peuvent être différenciés uniquement parce qu’ils existent. Un objet dépend d’une classe et nous pouvons dire qu’un objet est une instance de classe. Le but de la modélisation objet est la description des objets. Un objet en OMT est représenté par un rectangle aux coins arrondis. Le nom de la classe est écrit entre parenthèses et en caractère gras en haut du rectangle. Classes Une classe est la description d’un groupe d’objets qui ont la même structure de donnée, des services communs, des liens communs avec d’autres objets et une sémantique commune. La classe permet un niveau d’abstraction supérieur qui donne sa puissance et sa capacité de généralisation à la modélisation. La classe en OMT est représentée par un rectangle divisé horizontalement en trois parties : le nom de la classe est écrit en gras dans la partie haute du rectangle, les noms des données sont écrits dans la partie centrale et les services dans la troisième. Diagramme de classes Pour représenter le cas général dans la modélisation d’un système, les classes sont reliées entre elles par des liens et associations sous la forme d’un diagramme de classes. Il existe différents types de liens pour représenter les différents concepts. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-41 2 OMT : Modélisation Statique conduit Personne role 1 Voiture Association simple binaire role 2 Développement Langage Association ternaire Programmeur Les cardinalités Personne Personne . Personne Personne Personne 2-42 1+ 1-5,8 Voiture Exactement une (une) Voiture Zéro ou plus (plusieurs) Voiture Zéro ou un (optionel) Voiture Un ou plus Voiture Spécifié numériquement Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 OMT : Modélisation Statique Associations en OMT En OMT, une association est représentée par une ligne entre classes et un lien par une ligne entre objets. Le nom de l’association est écrit en italique mais il peut ne pas être précisé dans le cas d’une association unique ayant une signification évidente entre deux classes. Il est préférable, dans la mesure du possible, de disposer les classes de la gauche vers la droite pour faciliter la lecture. Types d’associations Les associations peuvent être binaires, ternaires ou d’ordre supérieur. Dans la majorité des cas, nous avons des associations binaires ou qualifiées ; les associations d’ordre supérieur sont à éviter à cause de leur complexité. Cardinalité La cardinalité permet de spécifier le nombre possible d’instanciations d’une classe pour l’objet qui lui est associée. Dans un diagramme de classes, la cardinalité est indiquée par l’ajout de symboles spécifiques à la fin des lignes représentant les associations. Une ligne simple signifie une association une à une, une boule noire signifie plusieurs (zéro ou plus), une boule blanche traduit l’optionnel (zéro ou une). Il est également possible d’indiquer le nombre exact ou de donner une fourchette de valeurs. Il n’est pas nécessaire de ce soucier outre mesure de la cardinalité au début de la modélisation, le plus important étant, dans un premier temps, la définition des objets, des classes et des associations. Il faudra par la suite s’y intéresser car : ■ une sous-estimation peut réduire la flexibilité de votre application, ■ une sur-estimation peut alourdir l’application en forçant des recherches supplémentaires. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-43 2 OMT : Modélisation Statique Personne employé employeur Société Association lien donnée Travail Titre Salaire Paragraphe Phrase Agrégation Personne Nom Prénom Age se présenter {abstrait} Anglais Allemand se présenter 2-44 Héritage ... se présenter Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 OMT : Modélisation Statique Association lien donnée Un lien relie deux ou plusieurs objets. Une association décrit un groupe de liens qui ont une structure et une sémantique commune. Un lien données (link attribute) est une propriété des liens dans une association. Une association avec des cardinalités plusieurs à plusieurs (points noirs des deux cotés) entraîne le plus souvent des liens données. Il est parfois utile de modéliser une association sous la forme d’une classe où chaque lien sera une instance de cette classe. Pour des associations avec des cardinalités une à une ou une à plusieurs, il est possible d’inclure les données du lien donnée dans la classe opposant la cardinalité 1. Il n’est pas conseillé d’inclure les données des liens données dans les classes au niveau de la modélisation car ceci réduit la souplesse du modèle qui sera à refaire si l’on décide de modifier les cardinalités. Dans notre exemple, la relation entre la classe Personne et la classe Société est Travail et ce lien peut contenir le Titre et le Salaire. Agrégation Nous pouvons définir la relation d’agrégation comme étant le rattachement d’une classe composant à une classe composite. L’agrégation se dessine comme une association avec un petit losange à la fin de la relation du côté de la classe groupe. Dans notre exemple, nous présentons un paragraphe qui est composé de phrases. Héritage L’héritage est une abstraction qui permet le partage de propriétés communes entre classes tout en préservant leurs différences. C’est un des concepts fondamentaux de l’orienté objet. L’héritage permet l’organisation des classes en structure hiérarchique et facilite la réutilisation de code dans les phases de développement. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-45 2 OMT : Modélisation Statique Conseils pratiques 2-46 ■ Consulter les experts du domaine à modéliser ■ Comprendre le problème avant de se jeter dans la construction des classes et des relations ■ Garder le modèle aussi simple que possible ■ Porter une grande attention dans le choix des noms ■ Décomposer en associations binaires autant que possible ■ Ne pas trop se soucier des cardinalités au début de la modélisation ■ Essayer d’éviter trop de niveaux d’héritage ■ Faire attention aux associations de cardinalité 1 à 1 pouvant causer des problèmes au niveau d’une base de données ■ Avoir recours aux cycles auteur-lecteur tout au long du processus de modélisation ■ Documenter son modèle : dictionnaire de données. Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Notes Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-47 2 OMT : Modélisation Dynamique Exemple d’une voiture automatique Personne conduit Démarreur Voiture Transmission Frein Accélérateur Diagramme de classes ■ 2-48 Scénario ■ Le conducteur tourne la clé de contact ■ Le démarreur vérifie si la transmission est à N ■ La transmission renvoie OK ■ La voiture démarre ■ Le conducteur met le levier de vitesse sur D ■ Le conducteur appuie sur l’accélérateur ■ L’accélérateur indique à la transmission qu’il accélère ■ Le conducteur appuie sur le frein ■ Le frein indique à la transmission qu’il freine Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 OMT : Modélisation Dynamique Evènement Un modèle objet décrit les objets, leurs données et leurs liens possibles dans un système. La valeur des données et des liens d’un objet à un moment donné est appelée son état. Les objets s’appellent les uns les autres et modifient leurs états respectifs. Un message d’un objet à un autre s’appelle un événement. Scénario Un événement est quelque chose qui arrive à un certain moment. C’est une façon de transmettre de l’information d’un objet à un autre. Une suite d’événements qui se produisent pendant une exécution réelle ou imaginaire d’un système peut être contenue dans un scénario. Exemple ■ Etude du fonctionnement de la transmission d’une voiture automatique. ■ Il y a trois vitesses, ■ La voiture automatique ne peut démarrer que si le levier de vitesse est au point mort (sur la position N), ■ Au freinage, la boite repasse en première. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-49 2 OMT : Modélisation Dynamique Personne ■ Objectif : décrire les diagrammes états/transitions les plus importants ■ Moyen : utiliser les différents diagrammes de modélisation OMT de type traces d’événements et flux d’événements ■ Diagramme de traces d’événements Démarreur Transmission Accélérateur Frein Tourne la clé de contact Vérifie si N OK Démarré Passe sur D Appuie sur l’accélérateur Vitesse moteur Marche avant Appuie sur le frein Stop 2-50 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 OMT : Modélisation Dynamique Objectifs et moyens de la modélisation dynamique Le but de la modélisation dynamique est de décrire aussi fidèlement que possible les différents états des objets du modèle ainsi que les événements entraînant les transitions d’états. OMT propose différents outils de construction permettant de mettre en évidence les états et événements impliqués dans la dynamique du système. Diagramme de traces d’événements L’étape suivant l’écriture du scénario est l’identification des objets émetteurs et récepteurs de chaque événement. La séquence des événements échangés entre les objets identifiés peut être représentée sous la forme d’un diagramme appelé diagramme de traces d’événements (event trace diagram). En examinant une colonne particulière dans le diagramme de traces, nous pouvons voir les événements qui affectent un objet en particulier ; ce seront uniquement ces événements qui apparaîtront dans le diagramme d’état de cet objet. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-51 2 OMT : Modélisation Dynamique ■ Diagramme de flux d’événements Démarreur OK Pas OK Contact Coupe contact Démarre Ne démarre pas Frein Appuie frein Freine Passe sur D Passe sur N Personne Vérifie que N Transmission Passe sur P Passe sur R Appuie accélérateur Accélère Accélérateur 2-52 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 OMT : Modélisation Dynamique Diagramme de flux d’événements Nous aurons un diagramme de trace d’événements pour chaque scénario. Pour récapituler tous les événements entre toutes les classes, sans tenir compte de leurs ordres d’arrivée, nous pouvons construire un diagramme de flux d’événements (event flow diagram). Un diagramme de flux d’événement peut être assimilé à une version dynamique d’un diagramme d’objets. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-53 2 OMT : Modélisation Dynamique ■ Diagramme d’états/transitions Transmission levier sur R Neutre levier sur D levier sur N Marche arrière levier sur N Marche avant [Tour moteur>x] Stop Première Seconde [Tour moteur<x] 2-54 [Tour moteur>y] Troisième [Tour moteur<Y] Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 OMT : Modélisation Dynamique Diagramme d’états/transitions Un état est une abstraction de la valeur des données et des liens d’un objet. Un jeu de valeurs (suivant certaines règles) qui influent sur le comportement de l’objet donnera un état. Par exemple, on saura si l’objet transmission est dans l’état Neutre en vérifiant si certaines de ses données ont telles ou telles valeurs. Le diagramme d’états décrit les événements et les états. A la réception d’un événement, un objet qui est dans un état particulier passe dans un autre état. On appelle ce passage une transition. Les événements deviennent des services dans le modèle objet et les actions correspondent à des fonctions dans le modèle fonctionnel. Notre exemple représente le diagramme d’états de la transmission. La transmission peut être au point mort (Neutre), en marche arrière ou en marche avant. En marche avant, la transmission peut être en première, seconde ou troisième. Ces trois états sont des sous-états de l’état marche avant. Les transitions du super-état (marche avant dans notre cas) sont héritées par chacun des trois sous-états. L’événement stop qui pointe sur le super-état marche avant allant vers l’état première, indique que dans le cas d’un événement arrêt, survenant n’importe quand en marche avant, on se retrouve dans l’état première. Les informations entre crochets signifient que ce sont des conditions ; quand la condition est atteinte, il y a changement d’état. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-55 2 OMT : Modélisation Fonctionnelle ■ Diagramme de flux de données vitesse moteur choix R choix N Personne choix D marche avant Accélérateur Gérer transmission stop marche arrière point mort 2-56 Frein Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 OMT : Modélisation Fonctionnelle Diagramme de flux de données Le modèle fonctionnel spécifie le résultat d’une opération sans prendre en compte comment ou quand cette opération a été traitée. Le modèle fonctionnel est représenté graphiquement sous la forme de multiples diagrammes de flux de données (DFD : Data Flow Diagram). Un DFD fait apparaître : ■ ■ les valeurs des entrées d’une opération venant : ■ d’objets externes, ■ d’autres opérations, ■ de systèmes de gestion de données. et les valeurs de sorties. Le modèle fonctionnel montre ce qui doit être fait par le système. Les processus définis sont les services des objets. Le modèle objet nous présente les objets avec leurs données et les services (ou opérations) que l’objet peut effectuer. Le modèle fonctionnel met en évidence les fonctions ou processus qui sont mis en oeuvre en tant que services pour certains objets alors que le modèle dynamique nous informe de l’ordre dans lequel les services sont exécutés. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-57 2 Différentes étapes en analyse objet Différentes étapes d’analyse 1. Modélisation Statique Les classes, les objets, les attributs, les associations 2. Modélisation Dynamique Scénario, diagrammes de traces événements et d’états 3. Modélisation Fonctionnelle Diagramme de flux de données 4. Affinage des modèles Ajout des services, jeux de scénarios, suppression d’attributs et d’associations inutiles Tous ces modèles sont optionnels et seront plus ou moins détaillés selon le problème à modéliser. Processus ■ 2-58 Enrichir le modèle statique (objet) à l’aide des informations fournies par les modèles dynamique et fonctionnel Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Différentes étapes en analyse objet Le but de l’analyse est la reformulation et la compréhension du problème et de son domaine d’application pour permettre une conception juste et rapide. Il existe trois axes de modélisation et différentes étapes dans chacun de ces axes. Il est possible de suivre ces axes et ces étapes dans un certain ordre : 1. 2. 3. 4. Modélisation Statique (si nécessaire) ■ reformuler le problème, ■ identifier les classes d’objets et leurs attributs, ■ identifier les associations entre les objets. Modélisation Dynamique (si nécessaire) ■ préparer un scénario, ■ représenter un diagramme de traces d’événements, ■ construire un diagramme d’états. Modélisation Fonctionnelle (si nécessaire) ■ identifier les entrées/sorties, ■ construire un diagramme de flux de données. Affinage des modèles (si nécessaire) ■ ajouter les services déduits des modèles fonctionnel et dynamique au modèle objet, ■ vérifier la consistance des classes, des associations et des services, ■ créer et jouer des scénarios sur les trois modèles pour les tester. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-59 2 Approche objet et méthodes orientées Traitements Planification Analyse des besoins Analyse Conception Codage Conception système pour certaines méthodes Traitement Intégration et tests Validation du système Maintenance Planification Analyse des besoins Analyse Conception OBJET Codage Intégration et tests Validation du système Maintenance 2-60 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Approche objet et méthodes orientées Traitements Points communs avec les méthodologies Structurées Les méthodologies d’Analyse/Conception structurées sont basées sur la notion de flux de données. Elles commencent avec une représentation unique du système à construire puis divisent les fonctions complexes jusqu’à l’obtention de petits processus faciles à coder. Les méthodologies objet utilisent également les modèles dynamiques et fonctionnels. La différence majeure réside dans le fait que les méthodologies structurées mettent l’accent sur le modèle fonctionnel alors que les méthodologies objet accordent plus d’importance au modèle de Classes d’objets. Approche ascendante modulaire en orienté objet L’approche descendante par décomposition fonctionnelle limite la réalisation dans la mesure où un module n’apparaît que s’il est initialement prévu dans la fonction plus générale. L’approche objet grâce à l’héritage est intrinsèquement ascendante dans la mesure où on part des principaux objets et c’est seulement après que l’on construit les objets plus complexes (librairies d’objets etc...) Approche d’analyse proche du codage Les méthodes orientées objet réduisent par ailleurs la distance qui peut exister entre le monde réel et le modèle du système (codage et représentation interne). En effet, les langages de programmation et les bases de données orientées objet implémentent directement le modèle issu de l’analyse. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-61 2 Approche objet et méthodes orientées Données Planification Analyse des besoins Analyse Conception Codage MERISE Intégration et tests Validation du système Maintenance Planification Analyse des besoins Analyse Conception Codage OBJET Intégration et tests Validation du système Maintenance 2-62 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Approche objet et méthodes orientées Données Symbolisme emprunté aux méthodes Entités Associations Les méthodologies objet sont des formes avancées des méthodologies Entité-Associations. Elles utilisent un symbolisme similaire en y ajoutant les concepts orientés objet tels que l’héritage, le polymorphisme ou l’abstraction. La modélisation objet englobant les données et les services est également plus facile à comprendre et à lire. Dichotomie entre données et traitements L’approche Entité-Association réalise une nette dichotomie entre données et traitements : entre les modèles de données et de traitement il n’y pas beaucoup de points communs. Ceci complique considérablement le cycle de développement particulièrement dans les phases d’intégration et de validation. Par exemple, en Merise, on s’exprime en terme d’attribut, d’entité, d’association pour les données alors que l’on parle d´événements ou de synchronisation pour les traitements. L’approche objet donne lui un cadre homogène pour l’analyse simultanée des données et de leurs comportements. Points forts de l’analyse objet Dans un cycle de développement, l’approche objet présente les avantages suivants : 1. réduire la distance entre le modèle conceptuel issue de l’analyse et les besoins des utilisateurs, 2. permettre facilement les méthodes de type RAD (Bottom-Up), 3. regrouper l’analyse des données et des traitements en renforçant les liens entre les aspects statique et dynamique, 4. simplifier les transformations entre l’analyse et l’implémentation, ce qui a l’avantage de réduire les distorsions finales entre les besoins et le système d’information. Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-63 2 Notes 2-64 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 22 2 Exercices Etude de cas d’une station service Enoncé Un système automatisé a pour mission de contrôler la fourniture de carburant par les différentes pompes de la station, de gérer les paiements et de surveiller le niveau des réservoirs. Pour qu'un client puisse utiliser une pompe en self-service, le gérant doit avoir mis la pompe en service. Quand une pompe est mise en service, l'affichage est remis à 0, le moteur de la pompe démarre, l'embrayage étant désactivé. Lorsque la gâchette du pistolet est enclenchée, l'embrayage de la pompe est activé afin de délivrer le carburant ; dès qu'elle est relâchée, l'embrayage est libéré, interrompant la fourniture. Quand le pistolet est replacé sur la pompe, la fourniture est terminée; la pompe est alors désactivée ; de nouvelles pressions sur la gâchette sont inopérantes. Après un certain temps, le moteur de la pompe est arrêté, à moins qu'un nouveau client arrive. Pour pouvoir être à nouveau utilisée, une pompe doit être autorisée par le gérant. Cette autorisation peut intervenir quand le client précédent a payé sa fourniture. Un système de mesure émet une impulsion chaque fois qu'1/100 de litre de carburant est fourni. L'afficheur de la pompe indique le prix du litre, la quantité fournie et le montant correspondant. Il y a 2 types de pompes : ■ la pompe ordinaire permet au client d'acheter la quantité qu'il souhaite, Méthodes objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 2-65 2 Exercices ■ la pompe à pré-sélection permet au client de choisir un montant ; la fourniture s'arrête automatiquement lorsque la limite choisie est atteinte (en conception, on ne traitera que la pompe ordinaire). Toute fourniture donne lieu à une transaction ; celle-ci est affichée jusqu'à ce que le client paie. Le paiement peut se faire en liquide, par carte de crédit ou par chèque. Un client peut demander un reçu. Si un client part sans payer, l'opérateur doit enregistrer le numéro minéralogique du véhicule. A la fin de la journée, toutes les transactions sont archivées. Durant la journée, les transactions sont gardées dans un enregistrement journalier. Si le niveau d'essence d'un réservoir est inférieur à 4% de sa capacité, toutes les pompes reliées à ce réservoir passent hors service. Cette information est détectée lors de la mise en route de la pompe. L'ensemble des transactions est accessible et visualisé par l'utilisateur du système de gestion. Elaboration du modèle objet avec l'outil ObjectPartner Traduire l'énoncé précédent sous forme d'un modèle objet et y appliquer les opérations permettant d'exécuter le scénario de livraison d'essence : 2-66 ■ Lancer l'éditeur de modèle objet par la commande oedit, ■ Identifier les classes du modèle objet, ■ Identifier les opérations de toutes ces classes afin de répondre aux exigences des besoins exprimés ci dessus, ■ Lancer le vérificateur par la commande check du menu Tools. Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 Développement orienté objet 3 Objectifs ■ Passage de l’analyse à la conception ■ Présentation de la programmation orientée objet ■ Présentation des langages orientés objet ■ Présentation du langage C++ ■ Présentation de Java ■ Présentation du CASE ■ Liste des principaux outils orientés objet ■ Présentation d’un AGL orienté objet Evaluation ■ Génération de code C++ avec un Atelier de Génie Logiciel Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-1 3 Passage de l’analyse à la conception Système Sous-système Analyse/Conception . Modélisations : objet Dynamique Fonctionnelle . Conception système . Conception logicielle Programmation 3-2 Base de données Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Passage de l’analyse à la conception Rappel sur l’analyse orientée objet Dans la phase d’analyse, on s’intéresse seulement au système du point de vue de ses missions, sans se soucier de la solution technique qui sera retenue. On se focalise sur les objets du domaine étudié : ■ Formulation du problème, ■ Modélisation des objets : identification des objets, des classes, des associations, des attributs, organisation de l’héritage et regroupement en modules, ■ Modélisation dynamique : description des scénarios et diagrammes d’état, ■ Modélisation fonctionnelle : diagramme des flots de données. Conception système Le but est de rechercher une solution informatique et de produire une architecture du système. Les étapes sont : ■ Décomposer le système en sous-systèmes, ■ Identifier les problèmes de concurrence, ■ Allouer les sous-systèmes aux composants matériel et logiciel, ■ Décider comment allouer et gérer les stockages, ■ Décider de l’implémentation du contrôle, ■ Définir le cadre de la conception détaillée. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-3 3 Passage de l’analyse à la conception Conception du logiciel ■ Combiner les trois modèles ■ Concevoir l’implémentation des opérations ■ Optimiser le modèle objet ■ Implémenter les automates ■ Généraliser ■ Implémenter les relations ■ Faire un choix de conception Implémentation ■ Choix d’un langage en principe orienté objet comme C++ ou Smalltalk ■ Persistance des objets dans l’application : ■ 3-4 Si oui, utilisation d’un SGBD Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Passage de l’analyse à la conception Conception du logiciel Le but est de produire une implémentation informatique du système indépendante de tout langage, d’accroître le niveau de détail, d’implémenter les opérations définies lors de l’analyse au moyen d’opérations plus élémentaires, d’introduire de nouvelles classes plus techniques. Les principales tâches en matière de conception du logiciel sont récapitulées dans le tableau ci-contre. Implémentation Le choix d’un langage orienté objet n’est pas une obligation après une analyse objet bien que cela soit assez naturel. Le passage de la conception à l’implémentation passe par les étapes suivantes : ■ définition des classes, ■ création des objets, ■ appel des opérations, ■ héritage, ■ implémentation des associations. L’autre problème est la persistance car les données ne survivent pas à l’exécution du programme, sauf lorsque le programmeur donne des instructions explicites pour les sauvegarder dans des fichiers. Dans les bases de données, la persistance est en revanche systématique. Nous verrons qu’il existe plusieurs façons d’aborder le problème de la persistance des objets. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-5 3 Caractéristiques des langages orientés objet ■ 3-6 Langage de programmation orienté objet ■ Types abstraits de données (A.D.T/Abstract data type) ■ Aptitude à la gestion des héritages ■ Aptitude au polymorphisme Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Caractéristiques des langages orientés objet Les langages orientés objet sont nombreux et pas toujours concurrentiels. Dans la plupart des cas, ils appartiennent à l’une des deux familles que l’on va considérer plus loin, et donc répondent à un besoin spécifique. Cependant, chacun de ces langages intègre les éléments suivants : 1. aptitude à fournir des types abstraits de données (ADT), 2. aptitude à l’héritage simple et multiple, 3. aptitude à gérer le polymorphisme (par dynamicité ou virtualité). Les langages ne répondant pas à ces spécifications ne peuvent pas être considérés comme des langages objet. Nous allons voir par la suite un nombre important de ces langages. Il s’agit simplement de fournir un panorama des langages objet, et non une liste exhaustive. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-7 3 Types abstraits et identité d’objet ■ ■ ■ 3-8 Type abstrait : ■ Données ■ Méthodes ■ Encapsulation. Typage : ■ Statique : contrôle à la compilation ■ Dynamique : type connu seulement à l’exécution. Identité d’objet : ■ Le tout objet dans les langages purs avec la notion d’identifiant ■ Simple pointeur dans les langages hybrides pour les instanciations de classes Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Types abstraits et identité d’objet Méthodes et encapsulation La principale caractéristique des langages objet est de supporter des types abstraits de données (à l’aide des classes). Les services qui caractérisent un type abstrait sont appelées fonctions ou méthodes. Les types abstraits cachent données et méthodes par des opérations dont l’utilisateur ne perçoit que l’interface appelée aussi signature. Le type abstrait doit implémenter par ailleurs, l’encapsulation qui permet de cacher les données privées du type abstrait, ne laissant visible à l’utilisateur que les interfaces. Typage des données d’un objet Dans les langages objet, le typage est soit statique, soit dynamique, soit les deux. Un typage statique signifie que le type de la variable est déterminé à la compilation : c’est le cas par exemple, de C++ et de Eiffel. Un typage dynamique signifie que le langage ne fait une identification de type qu‘à l’exécution : on trouve dans cette catégorie Smalltalk et Objective C. Le typage statique présente l’avantage d’un contrôle des types rigoureux. Le langage Java a l’avantage de posséder à la fois les caractéristiques des typages dynamique et statique. Identité d’objet L’identifiant au niveau objet est un pointeur en mémoire qui permet de l’identifier d’une façon unique : c’est un simple pointeur dans les langages hybrides directement manipulable par l’utilisateur alors qu’il est généré automatiquement dans les langages purs. Pour les langages purs, on parle de tout objet ce qui signifie que toute donnée est un objet et possède donc un identifiant. L’implémentation des types simples dans les langages purs est cependant simplifiée pour éviter l’overhead à l’exécution. Les langages purs sont destinés à des applications très spécifiques (systèmes experts, I.A, représentation des connaissances). Malgré l’overhead généré lors de l’exécution, ils sont conceptuellement très puissants. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-9 3 Polymorphisme : staticité, dynamicité, virtualité ■ Polymorphisme et liens Méthode 1 Méthode 2 Message Switch ? Méthode 3 Méthode 4 ■ 3-10 Dynamicité des liens ■ Extrême souplesse d’utilisation ■ Moins rapide à l’exécution ■ Explicite (Eiffel et C++) ou implicite (Java, Smalltalk) Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Polymorphisme : staticité, dynamicité, virtualité Polymorphisme par les liens Comme nous l’avons vu, le polymorphisme est la possibilité, lorsque l’on envoie un message à un objet, de générer cet envoi non pas à l’objet tel qu’il est vu, mais tel qu’il existe. Dans la mesure où ceci revient à effectuer un appel de fonction (à un niveau ou à un autre), on en arrive à parler des liens. Les liens sont le relais qui est effectué entre l’appelant ou l’appelé. Dans les langages "conventionnels", les liens sont dits statiques. Dans les langages objet, ils sont dynamiques ou statiques avec virtualité. Liens statiques Les liens statiques sont des liens créés lors de la compilation. Dès qu’un appel à une fonction est généré, il lui est substitué le saut permettant le lancement du code auquel il est associé. Liens dynamiques Les liens dynamiques permettent d’effectuer le choix de l’appel au moment de l’exécution. Ils sont l’apanage des langages "purs" et présentent l’avantage de gérer le polymorphisme de façon transparente et simple. Malheureusement, ce principe des liens dynamiques possède un gros défaut : la lenteur du code qu’il génère. En effet, le choix de cet appel sera généré après un nombre parfois conséquent d’examens des champs de l’objet concerné et la mise en oeuvre d’un raisonnement parfois complexe (surtout dans le cas des champs à attributs complexes). L’overhead peut alors devenir très important. Parmi les langages objet utilisant le principe des liens dynamiques on peut citer : Java, Objective C, Smalltalk, Simula, CLOS et C++/Eiffel (si explicitement spécifié - voir fonctions virtuelles). Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-11 3 Polymorphisme : staticité, dynamicité, virtualité ■ Liens statiques et virtualité Père Meth_Norm Meth_Virt Fils Petit-fils Meth_Virt Meth_Virt Meth_Virt Meth_Norm 3-12 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Polymorphisme : staticité, dynamicité, virtualité Virtualité et liens statiques : polymorphisme La virtualité est un moyen utilisé en plus des liens statiques pour permettre la gestion du polymorphisme en liaison statique. Ceci est réalisé par un jeu de pointeurs et d’offset (transparents à l’utilisateur) qui sont implantés lors de la compilation. Lors d’un envoi de message, il suffit alors de se référer à une table pour se rediriger sur le code à lancer. L’overhead impliqué par cette méthode est très faible (une simple indirection en C++) et permet d’accéder au polymorphisme. Le code fourni peut alors être très rapide (dépendant du langage). De plus cette virtualité peut être gérée de deux manières : a. Implicitement : Cette méthode de gestion implique la virtualité au sein même du langage. Elle est implicite et donc transparente à l’utilisateur. C’est le cas de SmallTalk, Objective C et Java. b. Explicitement : Cette méthode n’implique pas le traitement de tout message en tant que sujet à virtualité.Parmi les langages objet utilisant cette méthode, on peut citer : C++, Eiffel, Object Pascal. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-13 3 Classes et métaclasses Classes ■ ■ Spécification d’objets identiques en terme de : ■ Structures de données ■ Comportement Disponible avec tout langage objet Métaclasses 3-14 ■ Constructeur de classes ■ Polymorphisme sur les méthodes de classes ■ Disponible avec certains langages : Smalltalk et Objective C dans une certaine mesure ■ Pas disponibles avec Java et C++ Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Classes et métaclasses Classes Les classes sont le moyen de prototyper les objets. Elles servent à définir le fonctionnement interne de l’objet mais aussi les interfaces de mise en oeuvre de ces objets. Métaclasses Les métaclasses sont un moyen de redéfinir par la création d’un nouveau modèle, les classes de base du langage avec lequel on travaille. Dans les langages "purs", où tout est assimilé à un objet, cela revient à pouvoir redéfinir le fonctionnement même du langage. Parmi les langages disposant des métaclasses, on peut citer Smalltalk. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-15 3 Gestion de la mémoire ■ Garbage collector ■ Permet une gestion transparente de l’allocation mémoire ■ Peut être désactivé lors de phases critiques en temps d’exécution Exemple : langage Smalltalk, Clos, Spoke, Simula, Java ■ Destruction manuelle avec la notion de destructeur Exemple : langage C++, Objective C 3-16 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Gestion de la mémoire Création des objets en mémoire La création des objets exige l’allocation d’une zone mémoire. Dans beaucoup de langages orientés objet, les objets sont créés après l’activation d’une méthode appelée parfois constructeur (Java et C++). Destruction des objets en mémoire Certains langages disposent d’un outil qui, s’il n’est pas lié à la notion d’objet, mérite cependant d’être mentionné. Il s’agit du Garbage collector ou Ramasse miettes. Cet outil permet, en standard dans tout code produit, d’effectuer un nettoyage automatique de la mémoire. Dès qu’un objet n’est plus utilisé, la mémoire qui le contenait est automatiquement libérée. La destruction manuelle s’effectue parfois par appel d’un destructeur (langage C++) qui est une fonction exécutée lors de la destruction de l’objet. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-17 3 Langages orientés objet Historique des langages Algol Lisp Flavors Simula Clos Allegro CL Modula Object Pascal Ada C Smalltalk Loops Pascal self Eiffel Distributed Smalltalk Objective-C C++ Java 3-18 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Langages orientés objet Simula, créé en 1967, est le premier langage orienté objet. Simula-1 était un langage interprété mais il a été remplacé ultérieurement par Simula-67. Cette version est souvent appelée simplement Simula. Smalltalk fut ensuite le nouveau langage majeur orienté objet. Nous reviendrons ultérieurement sur ce langage. C++ développé par Bjarne Stroustrup chez AT&T dans les années 1980 est une extension du langage C intégrant des concepts objets. Nous reviendrons sur ce langage. Objective C développé par Stepstone a connu son heure de gloire avec les stations NeXT et son système NeXTStep. En 1995, Sun a proposé un nouveau langage Java en liaison avec l’Internet. Langage orienté objet à part entière, il est disponible sur d’autres plates-formes et connaît un succès important. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-19 3 Catalogue des langages purs Les langages purs Tout objet Liens dynamiques Métaclasses Attributs complexes Métaclasses Kee Art Kool Smeci Crl Attributs simples Métaclasses Smalltalk Clos Domaines de prédilection Représentation des connaissances 3-20 Prototypage Génération d’applications Simulation Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Catalogue des langages purs Smalltalk Smalltalk est un langage pur objet semi-compilé, c’est à dire qu’un code intermédiaire est généré, puis interprété. Smalltalk reste le langage objet de référence ayant une très forte dynamicité. Les principales différences avec C++ sont : 1. il n’y a pas de contrôle de type à la compilation. 2. les objets échangent des messages d’une façon explicite. 3. réels, entiers, chaînes de caractères sont des objets dont l’identifiant contient la valeur. 4. L’environnement de développement fait partie de Smalltalk qui intégre un éditeur graphique de classes et un debugger. Le tout objet Il n’y a pas en Smalltalk de différence entre classe, objet et membre de données ou attribut. Le tout objet présente l’avantage de considérer une classe comme élément d’une classe supérieure appelée métaclasse. De plus, la hiérarchie des classes comporte une racine unique Object de qui toute classe hérite. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-21 3 Catalogue des langages hybrides Les langages hybrides Type objet et type simple Pas de métaclasse utilisateur C++ Eiffel Simula Objective C Java Domaines de prédilection Génie logiciel industriel Applications à fort taux de maintenabilité Client/Serveur 3-22 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Catalogue des langages hybrides Langage Simula Simula est un langage compilé ancien dont la syntaxe est hérité d’Algol. Les principales caractéristiques de Simula sont : 1. héritage simple et encapsulation, 2. mécanisme de fonctions virtuelles, 3. gestion automatique de la mémoire, 4. typage statique. Objective C Ce langage est une extension de C qui est fortement inspiré de Smalltalk 80. Il a été utilisé pour écrire le système NeXT. Les principales caractéristiques de Objective C sont : 1. pas de métaclasses comme en Smalltalk, 2. typage dynamique, 3. héritage simple. Langage Eiffel Conçu pour les applications scientifiques et la gestion, ce langage compilé intègre, comme Smalltalk et C++, les exceptions. Les principales caractéristiques d’Eiffel sont : 1. héritage simple, multiple et virtualité, 2. notion de packages, 3. gestion automatique de la mémoire. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-23 3 Langage C++ ■ C++ est un sur-ensemble de C ■ Les compilateurs C++ sont aujourd’hui des compilateurs natifs NATIF PREPROCESSEUR Source C++ cfront AT&T Compilateur C++ Compilateur C Fichier objet (.o) Editeur de liens Exécutable 3-24 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Langage C++ Introduction C++ est un sur-ensemble de C. Il rajoute un ensemble de fonctionnalités nouvelles pour C, et ce à deux niveaux : Niveau non orienté objet C++ autorise un nombre d’actions importantes que n’autorise pas C. Ceci donne à C++ une grande souplesse d’emploi. Par exemple, en C++, on peut associer à un même nom de fonction des codes différents. Le choix du code à lancer est effectué en fonction des arguments passés. Ceci provient de l’une des fonctionnalités les plus importantes introduites par C++ : la surcharge et le contrôle de type exercé sur tout appel à une fonction. Niveau orienté objet C++ permet de mettre en oeuvre tout ce que nous venons de voir dans le module précédent. La notion d’héritage est mise en oeuvre au travers des types abstraits de données que sont les classes (A.D.T : Abstract Data Type). Les compilateurs C++ étaient souvent des pré-processeurs de compilateurs C. Aujourd’hui, il sont natifs, effectuant directement toutes les phases de compilation, réduisant ainsi significativement le temps de compilation. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-25 3 Internet et Java Première génération ■ Basée sur HTML et un ensemble de protocoles déterminés: FTP, HTTP ■ Interactivité limitée ■ Charge serveur et réseau importantes ■ Evolutivité faible Seconde génération 3-26 ■ Bénéficie de l’acquis et ajoute la possibilité de télécharger des applications, les applets : ■ Richesse d’un langage de programmation objet dynamique, ■ Interactivité et évolutivité maximales, ■ Exploitation des ressources du poste client Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Internet et Java Première génération La première génération d’applications Internet est essentiellement basée sur HTML et les protocoles tels que FTP, HTTP, SMTP, etc... et offre souvent la seule possibilité de charger des pages HTML associées à des liens hypertextes. L’interactivité et la richesse de ces applications peuvent être améliorées en utilisant des passerelles vers d’autres applications comme les CGI, mais on retrouve alors toutes les difficultés inhérentes au déploiement d’applications traditionnelles (pas de portabilité, développement parfois complexe). De plus, l’ensemble des protocoles disponibles est limité à ceux qui sont offerts par les navigateurs, ce qui en limite l’évolutivité. Seconde génération Java apporte la capacité de télécharger de véritables applications associées à des pages HTML, et cela quelque soit la plate-forme cliente. La Machine Virtuelle Java offre non seulement l’interprétation du langage, mais également la possibilité de télé-chargement dynamique de classes. ceci permet d’étendre aisément les possibilités des applications Internet ou Intranet. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-27 3 Modèle Client/Serveur Java Applet Application Java téléchargée avec une page HTML Serveur (1) demande de page (URL) contenant une référence d’applet (2) retour page demandée + bytecode applet Client (3) exécution du code Java 3-28 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Modèle Client/Serveur Java Applet Une applet est une application écrite en langage Java qui est téléchargée et exécutée par le client. Une applet est liée à une page HTML par un tag particulier (<applet>). Elle est chargée sous sa forme compilée (le bytecode) par le poste client lorsque ce dernier charge la page HTML hôte pour la première fois. Elle est alors exécutée par la Machine Virtuelle Java, après avoir subi plusieurs vérifications destinées à s’assurer de son authenticité et de son caractère “amical”. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-29 3 Java : une plate-forme applicative universelle Machine Virtuelle ■ Abstraction des ressources matérielles et logicielles Application Java Utilise Abstraction Java Machine Virtuelle Système natif 2 Système natif 1 OS OS Fenêtrage Fenêtrage 3-30 ■ UNIX ■ Windows ■ MacOS Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Java : une plate-forme applicative universelle Machine Virtuelle Les besoins liés à l’usage d’Internet ont introduit la nécessité de créer une abstraction de tout système d’exploitation afin de rendre l’applet indépendante de l’architecture de la machine cliente sur laquelle elle s’exécute. La Machine Virtuelle est une abstraction de l’ensemble des fonctionnalités d’un système d’exploitation complexe : ■ système d’exploitation, ■ système de fenêtrage graphique, ■ exécution d’application, ■ gestion des ressources fichiers, imprimantes, réseaux, ■ multi-threading Il existe une implémentation de la Machine Virtuelle Java pour les plates-formes les plus courantes : ■ UNIX: Solaris, AIX, HP-UX, Linux, etc, ■ Windows : NT 4.0, 3.1, 95 ■ MacOS Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-31 3 Principes de fonctionnement Compilation Code source Compilateur Code compilé Bytecode Exécution Code compilé Bytecode Module de Vérification chargement local ou réseau Module d’Exécution Module de Chargement 3-32 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Principes de fonctionnement Compilation La phase de compilation permet de traduire le code source Java en un code binaire virtuel exécutable par la machine virtuelle de façon plus efficace. Il permet également d’optimiser les transferts réseau. Exécution L’exécution se déroule en trois phases: ■ Chargement du code compilé nécessaire à l’exécution, de façon dynamique. ■ Vérification de l’intégrité du code chargé. Le bon déroulement de cette phase est un préalable à la phase d’exécution. ■ Exécution du code par un interpréteur ou un compilateur à la volée, capable de traduire le bytecode Java en code binaire spécifique à la plate-forme d’exécution. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-33 3 Classe C++ class Cercle { private: int x; int y; float rayon; public: Cercle (int, int, float); void dessine (); }; Cercle::Cercle (int cx, int cy, float r) { x = cx; y = cy; rayon = r; } void Cercle::dessine() { cout << "Cercle"; } 3-34 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Classe C++ La définition d’une classe en C++ s’effectue en utilisant le mot clef class. Il faut ici souligner une notion très importante : les droits d’accès. On considère trois types de zone d’accès au sein d’une classe : ■ La zone privée (mot clef : private) Cette zone est interdite d’accès à l’environnement extérieur. Seules les méthodes de l’objet ont un droit de regard sur les données membres de l’objet. ■ La zone protégée (mot clef : protected) Cette zone n’est accessible qu’aux membres de l’objet et aux instances dérivées de la classe pour laquelle elle est définie (vu plus loin). ■ La zone publique (mot clef : public) Cette zone est libre d’accès à tous. Elle sert généralement à définir l’interface entre l’environnement et l’objet instancié de cette classe. Par défaut, une classe est privée. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-35 3 Classe Java class Cercle { Attributs private int x; private int y; private float rayon; public Cercle (int cx, int cy, float r) { x = cx; y = cy; rayon = r; } public void dessine () { System.out.println ("Cercle"); } } Méthodes 3-36 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Classe Java La définition d’une classe en Java s’effectue en utilisant le mot clef class. Comme en C++, on considère trois types de zone d’accès au sein d’une classe : ■ La zone privée (mot clef : private) Cette zone est interdite d’accès à l’environnement extérieur. Seules les méthodes de l’objet ont un droit de regard sur les données membres de l’objet. ■ La zone protégée (mot clef : protected) Cette zone n’est accessible qu’aux membres de l’objet et aux instances dérivées de la classe pour laquelle elle est définie (vu plus loin). ■ La zone publique (mot clef : public) Cette zone est libre d’accès à tous. Elle sert généralement à définir l’interface entre l’environnement et l’objet instancié de cette classe. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-37 3 Constructeur et destructeur C++ class Cercle { private: int x; int y; float rayon; public: Cercle (int, int, float); ~Cercle (); void dessine (); }; Cercle::Cercle (int cx, int cy, float r) { x = cx; y = cy; rayon = r; } Cercle::~Cercle () { cout << "Cercle détruit"; } 3-38 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Constructeur et destructeur C++ Il y a deux méthodes particulières au sein d’une classe : Le constructeur : Il porte toujours le nom de la classe. C’est une méthode qui est appelée lors de l’instanciation de l’objet. Cette méthode est facultative mais peut être surchargée. Le destructeur : Il porte toujours le nom de la classe précédé d’un ~. Il est facultatif, mais s’il existe, il doit être unique (pas de surcharge). D’autre part, un destructeur ne peut pas prendre d’arguments. Utilité des constructeurs et destructeurs Le constructeur sert pour l’initialisation de l’objet. La phase d’instanciation peut se décomposer en trois sous-phases : ■ Allocation : phase d’allocation de la mémoire nécessaire à l’objet, ■ Initialisation : phase d’initialisation des classes de base, des constantes et des références, ■ Assignation : exécution du code de la méthode constructeur (initialisations particulières ou dynamiques). Le destructeur sert pour la destruction de l’objet. Vous ne devez pas l’appeler explicitement ; c’est automatiquement fait par le système dès que l’on arrive en fin de vie de l’objet. On se sert généralement des destructeurs pour libérer la mémoire dynamiquement allouée par l’objet. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-39 3 Constructeur et destructeur Java Pas de type de retour Porte le nom de la classe public Cercle (int cx, int cy, float r) { x = cx; y = cy; initialise les attributs rayon = r; de l’objet construit } public void finalize () { System.out.println ("Cercle détruit"); } 3-40 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Constructeur et destructeur Java ■ Le constructeur est appelé au moment de la création de l’objet (l’instanciation). Sa finalité est d’initialiser cet objet en fonction de paramètres fournis par l’utilisateur. ■ Une classe peut comporter plusieurs constructeurs, qui seront différenciés par leurs paramètres. ■ Le constructeur ne possède pas de type de retour. ■ Chaque classe possède un constructeur par défaut, qui ne prend aucun paramètre. ■ Il n’y a pas de destructeur. La libération est prise en charge par le ramasse-miettes de Java. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-41 3 Allocation C++ ■ Automatique Cercle c (0, 0, 2.0); ■ Dynamique explicite Cercle *c; c = new Cercle (0, 0, 2.0); Java ■ Dynamique explicite seulement Cercle c; int x = 100; int y = 100; (1) déclaration c = new Cercle (x, y, 10.0); ... // utilisation de c (2) allocation dynamique (3) libération par le ramasse-miettes 3-42 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Allocation C++ C++ offre deux manières d’instancier un objet : ■ automatique : dans ce cas, la destruction de l’objet s’effectue lorsque son bloc de définition n’existe plus. ■ dynamique : la destruction doit être prise en charge explicitement par le programmeur. ■ (1) Une référence sur l’objet doit d’abord être déclarée. ■ (2) L’allocation de l’objet est réalisée par l’intermédiaire de new() auquel on passe les paramètres requis par le constructeur. Java Cercle c; X new c Y RAYON ... ■ (3) Il n’y a pas de libération explicite à faire. Celle-ci est effectuée par le ramasse-miettes dès que l’objet est hors de portée. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-43 3 Envoi de message C++ Cercle c (0, 0, 2.0); c.dessiner (); // ou Cercle *c = new Cercle (0, 0, 2.0); c->dessiner (); Java Cercle c = new Cercle (0, 0, 100.0); Envoi de message c.dessiner (); = invocation d’une méthode sur un objet particulier Parallèle avec l’accès aux attributs en C++ et Java Si x et y étaient des attributs publics de Cercle // allocation d’un Cercle c.x = 100; c.y = 20; 3-44 Fournir des méthodes est préférable Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Envoi de message Comme nous l’avons vu, les fonctions sont pour les langages orientés objet le moyen de véhiculer les messages à destination des objets. Elles sont alors des méthodes publiques que l’on peut appeler de l’extérieur. Les langages C++ et Java ne possèdent pas de différence sémantique dans ce domaine. L’accès aux attributs s’effectue de la même manière avec les deux langages. Il est préférable de fournir des méthodes d’accès aux attributs afin de respecter les principes d’encapsulation et de ne pas rendre le code utilisateur trop dépendant des types des attributs. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-45 3 Agrégation C++ : supportée par le langage class Cercle { private: float rayon; Point origine; public: Cercle (int cx, int cy, float r) : origine (cx, cy), rayon (r) { } Java : doit être prise en charge explicitement class Cercle { private float rayon; private Point origine; public Cercle (int cx, int cy, float r) { rayon = r; origine = new Point (cx, cy); } } 3-46 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Agrégation C++ Le langage offre la possibilité de définir des agrégations dont la construction peut être totalement contrôlée au niveau de l’agrégat. Dans l’exemple ci-contre, la définition de la classe Point est : class Point { public: int x; int y; Point (int Java Avec java, il est indispensable de prendre en charge la construction explicite de chaque composant de l’agrégation. Dans l’exemple ci-contre, la définition de la classe Point est : class Point { public int x; public int y; Point (int px, int py) { x = px; y = py; } Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-47 3 Héritage Figure Point origine; hérite de Cercle float rayon; C++ class Cercle : public Figure { private : ....... } Java class Cercle extends Figure { private ...... } 3-48 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Héritage En C++ et Java, les héritages s’effectuent au travers des classes. En fait on effectue la dérivation de classes de base pour obtenir des classes plus évoluées. Par exemple, toutes les instances de Figure seront alors vues comme si la classe Figure avait repris dans sa définition la définition de Cercle. C++ C++ supporte également la notion d’héritage multiple. Java Java ne supporte pas l’héritage multiple d’implémentations. Par contre, il est possible de définir un héritage multiple d’interfaces. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-49 3 Polymorphisme Java Définition ■ Un seul nom, plusieurs implémentations public class Cercle extends Figure { ... public void dessiner () { // dessin d’un cercle } } public class Rectangle extends Figure { ... public void dessiner () { // dessin d’un rectangle } } Utilisation ■ Totalement transparente public class Fenetre { // gestion d’une liste de figures public void dessiner () { // boucle de dessin de chaque Figure // par appel de dessiner() 3-50 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Polymorphisme Java ■ Les classes Cercle et Rectangle sont des Figure qui implémentent la méthode dessiner(). ■ Le comportement de chaque méthode dessiner() dépend de sa classe de définition. ■ La Fenêtre est capable de représenter graphiquement toute Figure, grâce à sa méthode dessiner(). ■ Pour cela, elle gère une liste d’objets de type Figure grâce à des méthodes de type ajouter() et enlever(), que l’on va pouvoir utiliser au niveau de Figure. ■ Il est possible d’enrichir ce mécanisme à l’aide des interfaces, classes et méthodes abstraites. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-51 3 Polymorphisme C++ Définition ■ Un seul nom, plusieurs implémentations class Cercle : public Figure { public: virtual void dessiner () { // dessin d’un Cercle } }; class Rectangle : public Figure { public: virtual void dessiner () { // dessin d’un Rectangle } }; Utilisation ■ Totalement transparente class Fenetre { // gestion d’une liste de figures void dessiner () { // boucle de dessin de chaque Figure // par appel de dessiner() } } 3-52 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Polymorphisme C++ ■ Les classes Cercle et Rectangle sont des Figure qui implémentent la méthode dessiner(). ■ Le comportement de chaque méthode dessiner() dépend de sa classe de définition. Il est indispensable d’indiquer explicitement par l’emploi du mot-clé virtual que l’on désire utiliser le polymorphisme. ■ La Fenêtre est capable de représenter graphiquement toute Figure, grâce à sa méthode dessiner (). ■ Pour cela, elle gère une liste d’objets de type Figure grâce à des méthodes de type ajouter() et enlever(), que l’on va pouvoir utiliser au niveau de Figure. ■ Il est possible d’enrichir ce mécanisme à l’aide des méthodes virtuelles pures. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-53 3 Définition du CASE Computer Aided Software Engineering UPPER CASE AGL (Analyse/Conception) ATELIER Traitements Données objets DE LOWER CASE GENIE L3G Code source RAD OBJET LOGICIEL Test Qualité L4G 3-54 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Définition du CASE Les outils CASE (Computer Aided Software Engineering) ou outils de Génie Logiciel (OGL) sont des logiciels d’aide au développement d’applications. Ils agissent sur une ou deux phases du cycle de développement aussi appelé le cycle de vie du logiciel. Phases hautes (Upper Case) On retrouve dans les phases hautes toutes les méthodes et les outils d’analyse/conception et de modélisation. Ce sont des outils permettant de concevoir des systèmes d’information et de spécifier des applications. De plus en plus, ces outils proposent de la génération automatique de code et agissent donc sur les phases basses du cycle de vie du logiciel. Ils peuvent également générer des schémas de Bases de Données (DDL : Data Definition Language). Phases basses (Lower Case) Les outils du Lower Case sont des outils à faible composante méthodologique tels que des générateurs d’interfaces graphiques (IHM), des L4G (générateurs de code de 4ème génération plus ou moins objet), les L3G (langages tels que C, Fortran, Cobol, utilitaires de développement, outils de debugging, de test, de qualité, les gestionnaires de configuration) et les nouveaux ateliers de développement d’applications objet. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-55 3 Atelier de Génie Logiciel Définition Gestion Analyse Conception Gestion Développement Qualité Test de Configuration d’objets Référentiel Un Atelier de Génie Logiciel (AGL) est un ensemble d’outils de Génie Logiciel (OGLs) articulés autour d’un référentiel permettant l’automatisation de l’ensemble des phases du développement. 3-56 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Atelier de génie logiciel Définition Dans le monde du CASE, il existe un nombre important d’outils couvrant une ou plusieurs phase du cycle de vie du logiciel. Le problème majeur est le manque de communication entre ces outils. Par exemple, il est intéressant de pouvoir utiliser un document de conception venant d’un Upper Case comme point d’entrée du L4G. Pour cela, je dois sauvegarder le schéma de ma base ou la définition de mes objets dans une base de données, propriétaire ou non, appelée référentiel. Un Atelier de Génie Logiciel peut donc être défini comme un ensemble d’outils de Génie Logiciel articulés autour d’un référentiel permettant, l’automatisation de l’ensemble des phases du cycle de vie, grâce à un mode de communication commun et la mise en oeuvre de règles de gestion à l’aide de techniques. On ne peut pas parler d’AGL sans évoquer les structures d’accueil aussi appelée bus logiciel. Une structure d’accueil est composée du référentiel, permettant aux différents outils de partager leurs données, et d’une couche intégration qui leurs permet de communiquer. Si la couche intégration est propriétaire, l’AGL ne permet pas l’intégration d’outils venant d’autres éditeurs et connaît toutes les limitations inhérentes à un système propriétaire (coût, choix, évolution) mais garantit, en général, un environnement bien "rodé" avec un bon niveau de sécurité. Pour des raisons de contrôle de coûts et de pérennité des investissements, les développeurs préfèrent des solutions basées sur des standards. Il y a quelques standards émergeant à l’heure actuelle tels que : ■ PCTE (Portable Common Tool Environment) de l’ECMA (European Computer Manufacturers Association) basé sur UNIX, ■ les systèmes ouverts et CORBA (Common Object Request Broker Architecture) de l’OMG (Object Management Group) pour décrire les mécanismes d’échanges entre objets distribués, ■ Tooltalk de Sun intégré aux spécifications du COSE. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-57 3 Outils d’Upper CASE orientés objet Exemples d’outils 3-58 Outils Editeur Méthodologies StP IDE OMT,Booch ObjecTeam Cadre OMT,S&M Rose Rational Booch, OMT, UML ObjectPartner VERILOG OMT Paradigm Protosoft OMT, Booch, Fusion Objecteering Softeam CLASSE-RELATION ObjectBench SES Shlaer Mellor ObjecTime ObjectTime ROOM Select/omt Select OMT Westmount Westmount OMT JavaPlan Sun-Lighthouse OMT Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Outils d’Upper CASE orientés objet Upper case L’offre de certaines de ces sociétés dépassent d’ailleurs largement le cadre de l’Upper Case puisque ce sont de véritables Ateliers de Génie Logiciel. StP d’IDE Software through Pictures est une gamme complète de produits de développement dans le domaine du lower CASE (génération de SQL pour les principales bases de données avec Stp/IM, outil de test StP/T) et de l’analyse/spécification objet (StP/OMT et StP/Booch). Les outils de l’upper CASE sont interfacés avec des environnements de développement comme le produit ObjectWorks ou Sun WorkShop. ObjectTeam de CADRE En plus de l’outil d’analyse/Conception proposé par cet éditeur, on trouve aussi dans ObjectTeam un module ObjectTeam/Sim de simulation de comportement du modèle OOA en amont de l’implémentation permettant de vérifier le comportement dynamique des applications. Rose de Rational Rose de Rational propose des outils d’analyse/Conception basés sur les méthodes Booch/OMT/UML et de génération de Code C++, Java et Smalltalk. Des outils de documentation (SoDA) et de génération de SQL/DDL pour des bases relationnelles comme Oracle complètent l’offre de Rational. JavaPlan JavaPlan est un outil d’analyse/conception et de génération de code (Java et Objective C) basé sur OMT. Il propose des fonctionnalités de reverse engineering pour C++, Java et Objective C. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-59 3 Outils du Lower CASE orientés objet Exemples d’outils 3-60 Outils Editeur Langages ObjectCenter CenterLine C++ Eiffel ISE Eiffel VisualWorks ParcPlace C++, Smalltalk,Java Borland C++ Borland C++ JBuilder Borland Java Visual C++ Microsoft C++ Visual Studio Microsoft C++, Java Galaxy Visix C++ Vibe Visix Java Visual WorkShop C++ Sun C++ Java WorkShop Sun Java JavaStudio Sun Java Visual Cafe Symantec Java Visual Age IBM Smalltalk, Java, C++ Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Outils du Lower CASE orientés objet Lower CASE On trouve dans cette catégorie : ■ Les environnements de développement autour des langages objet L’objectif de ces outils est de favoriser l’utilisation des langages. Les principales fonctions sont : éditeur, browser de classes, gestionnaire de projets, compilateurs objet, gestionnaires de librairies, debugger. ■ Les L4G Les bases de données orientées objet offrent aussi des outils de création et d’édition du schéma (graphe de classes) appelé concepteur de classes. ■ Les générateurs d’interface graphique (IHM) L’objectif est de permettre aux développeurs d’applications de développer des GUI sans avoir à connaître l’interface de programmation de base. Il peut disposer pour cela de librairie de classes graphiques. Environnements de développement Les environnements de développement sont des plates-formes complètes pour la mise au point itérative des applications. Les solutions C++ sont des références tant dans le domaine UNIX avec Visual WorkShop C++ ou ObjectCenter que sous Windows avec Visual C++ ou Borland C++. De nombreux environnements Java offrent une palette complète d’outils couvrant tous les besoins du développement. En général, ils sont disponibles sur les principales plates-formes du marché : UNIX, Windows NT et Windows 95 (Visual Age et Sun Java WorkShop) ou seulement sous Windows/Windows NT (Visual Cafe, JBuilder). Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-61 3 Présentation de Visual WorkShop C++ WorkShop pour lancer les outils Visual C++ pour construire des IHM Browsing pour naviguer et faire des recherches dans le code Building pour construire Debugging pour trouver facilement les erreurs Compilateur C++ et C 3-62 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Présentation de Sun Visual WorkShop C++ Les outils de Sun Visual WorkShop C++ sont les suivants : ■ Workshop Browsing examine les fonctions et les définitions de variables ainsi que leurs utilisations, les arbres d’appels de fonctions et les hiérarchies de classe C++. ■ Building traduit les règles du make et supervise les différentes phases de construction. ■ Debugging offre : ■ le contrôle d’erreurs à l’exécution, ■ le Fix and Continue qui permet la prise en charge de modifications de source sous contrôle de Debugging, ■ la définition de points d’arrêt, ■ des interfaces graphiques pour la visualisation des données et de la pile du processus. ■ Performance Analyzer affiche les temps user, system ainsi que la charge en Entrées/Sorties et en défauts de page système sous Solaris. ■ Visual C++ : WorkShop Visual de Sun est un outil interactif (produit X-Designer) permettant de construire des interfaces homme-machine utilisant les widgets de la librairie standard OSF/MOTIF. L’outil permet de construire une hiérarchie de widgets. On peut générer du code C, C++ ou UIL (en entrée également) ainsi que les fichiers makefile (si nécessaire). Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-63 3 Présentation d’un AGL ObjectPartner de VERILOG ■ ■ ■ Outils proposés : ■ OMT ProjectOrgamizer : gestion du projet OMT ■ OMT ObjectEditor : diagrammes de classes et d’instances ■ OMT FunctionEditor : diagrammes de flots de données ■ OMT BehaviorEditor : diagrammes d’état et event Traces (modèle dynamique) ■ OpenInterface : interfaces de programmation et utilitaire de documentation ■ C++ ProjectOrganizer : Reverse C++ pour le Reverse Engineering de Code C++ etc... Génération standards : ■ C++ ■ SQL Ouverture ■ 3-64 Langage LDS GEODE de VERILOG Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 33 3 Présentation d’un AGL ObjectPartner de VERILOG Outils ObjectPartner peut être utilisé pendant toutes les phases de la méthode OMT, de l’analyse au codage. Les trois éditeurs graphiques sont : ■ ObjectPartner ObjectEditor qui supporte les diagrammes de classe et d’instances, ■ ObjectPartner FunctionEditor qui supporte les diagrammes de flots de données. ■ ObjectPartner BehaviorEditor qui supporte les modèles dynamiques (diagrammes d’états et event Traces). Chaque éditeur peut importer un modèle existant. Toutes les informations du modèle peuvent être réutilisées dans les différents points de vue. Par exemple, une classe pourra être réutilisée dans la définition d’un processus. La traçabilité est supportée entre l’analyse et la conception. Un mécanisme de marquage permet de connaître les classes spécifiques d’une phase. Du Code à la conception ObjectPartner Reverse C++ permet de reprendre du code source C ou C++ pour générer un modèle objet. Génération de code La génération ne supporte que les parties déclaratives. Grâce à un mécanisme d’annotation, les parties rajoutées peuvent être prises en compte lors d’une régénération. La traduction automatique peut également être personnalisée. Développement orienté objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 3-65 3 Exercices Etude de cas d’une station service Implémentation en C++ 3-66 ■ Lancer le générateur de code par la commande C++ Generator du menu Tools, ■ Editer les différents fichiers générés afin de compléter le code. Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 Objets en application 4 Objectifs ■ Présenter ■ Les standards de l’objet ■ Les environnement objet ■ CORBA ■ Neo de SunSoft ■ ORBIX ■ l’approche Internet avec Java et ACTIVE X ■ l’utilisation d’une base de données relationnelle avec JDBC ■ l’appel de méthodes distantes avec RMI ■ les principes de réalisation d’un applicatif Java aux normes CORBA ■ le relationnel étendu ■ les systèmes de gestion de bases de données objet persistants ■ les systèmes de gestion de bases de données objet intégrés ■ les principales bases de données orientées objet Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 4-1 4 Standards de l’objet COSE X/Open Management information objet ODMG OSF Modèles intégration d’outils CASE OMG X consortium Open distributed processing Trois axes de l’OMG : Applications distribuées Applications intégrées ou services Environnements hétérogènes 4-2 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 44 4 Standards de l’objet L’objectif des standardisations est de faire communiquer les applications et d’obtenir une certaine transparence par rapport aux plates-formes matérielles et logicielles choisies par les utilisateurs. De nombreux organismes existent qui sont en général complémentaires. Un organisme essentiel est l’OMG, l’Object Management Group qui a été créé en 1989 à l’initiative d’un certain nombre de grandes sociétés américaines. La même année un accord de coopération était conclu entre l’OMG et le consortium X/Open de standardisation des systèmes ouverts pour la promotion de leurs travaux. L’OMG est une association internationale, sans but lucratif regroupant aujourd’hui plus de 750 membres assurant la promotion de spécifications de technologies d’objets distribués. Le but de l’OMG est de créer des standards pour réaliser l’interopérabilité entre les applications orientées objet en milieu hétérogène. L’OMG a proposé un modèle de standardisation des communications inter-objets. Ce projet a donné lieu en 1992, à l’architecture distribuée CORBA 1.1 qui a évolué plus tard vers CORBA 2. Ces spécifications concernent la communication entre objets, les services nécessaires et tendent à assurer l’interopérabilité entre les applications sur différentes machines en environnement distribué. La persistance est aussi étudiée par un groupe, appelé ODMG, qui réunit les principaux éditeurs de bases de données orientées objet et qui s’intéresse en particulier, à la standardisation du langage d’interrogation de la base. Objets en application Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 4-3 4 CORBA Common Object Request Broker Architecture Applications objets Facilités communes Object Request Broker COSS-1 COSS-2 COSS-3 etc... Services CORBA 4-4 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 44 4 CORBA Architecture L’architecture CORBA 1 (Common Object Request Broker Architecture) résulte d’une fusion des propositions HP, Sun, NCR, ODI réalisée suite à un appel d’offre de l’OMG. Une spécification CORBA 2 du produit est sortie en 1994 proposée par Sun et IONA. CORBA propose une approche idéale qui consiste à développer une interface indépendante de tout langage permettant de solliciter des opérations sur des objets sans connaître leur localisation. Il s’agit d’une généralisation des architectures Client/Serveur aux objets. Les objets Clients communiquent avec les objets Serveurs et les utilitaires communs par un échangeur de messages (ORB : Object Request Broker). On trouve quatre composants en CORBA : ■ Object request broker (ORB) – composant de communication, ■ Applications objet – applications utilisateurs, ■ Facilités communes ou Common facilities (CFS) – Services de haut niveau pour les applications objets, ■ Services CORBA – Services pour l’accès à l’ORB : en effet, CORBA est complété par le COSS (Common Object Service Submission) correspondant à un certain nombre de services. Les services proposés par le COSS sont, entre autres : ■ la notification d’événements inter-objets, ■ la gestion du cycle de vie des objets, ■ le service de noms (localisation), ■ la persistance des objets. Objets en application Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 4-5 4 ORB Object Request Broker ■ Un ORB est un "RPC objet" ■ CORBA spécifie deux approches d’ORB ■ Statique : - Utilisation d’un langage de définition IDL (Interface Definition Language) : - Description de l’interface de l’objet - Edition de liens avec l’application Inconvénient : recompilation en cas de modification ■ Dynamique : interface dynamique depuis un langage compilé - Fiche IDL stockée dans l’IR (Interface Repository : référentiel d’interfaces) - Interrogation IR avec API spécifique - Appel des méthodes avec DII (Dynamic Invocation Interface) Avantage : possibilité d’utiliser en exécution des objets inconnus lors de la phase de compilation Les deux API sont fournies par les éditeurs de logiciels qui proposent aujourd’hui CORBA. 4-6 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 44 4 ORB Interfaces d’ORB Les spécifications CORBA concernant l’ORB (Object Request Broker) comprennent deux interfaces différentes : ■ une interface statique décrite en langage de définition d’interface IDL (Interface Definition Language), ■ une interface d’appels dynamiques DII (Dynamic Invocation Interface) avec un référentiel d’interfaces. Langage de définition d’interfaces L’interface statique nécessite la connaissance à la compilation du type des objets avec lesquels on va interagir à l’exécution. Pour cette raison, on parle d’approche statique. IDL est un langage de spécification indépendant du langage de programmation. Un compilateur IDL transforme ensuite les spécifications en langage structuré ; on peut alors faire l’édition de liens avec des modules écrits en C, C++, Java, Ada95 et SmallTalk. Interface d’invocation dynamique L’interface d’appel dynamique propose, à contrario, une interface de programmation qui peut être appelée depuis tout programme conforme à CORBA. La construction est alors dynamique à l’exécution, ce qui peut donner plus de souplesse dans certaines applications : en effet, la connaissance par le développeur des objets Serveurs peut être insuffisante en phase de développement. Une "base de données" d’interface (IR : Interface Repository) permet d’enregistrer les fiches IDL. Une interface de programmation spécifique (DII : Dynamic Invocation Interface) permet à l’application Cliente de découvrir et invoquer les services implémentés par les objets serveurs. Objets en application Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 4-7 4 ORB Fonctionnement Implémentation Client Interface Repository DII objet Stub Interface Skeleton IDL ORB Serveur Adaptateur Code objet repository ORB Exemple d’interface IDL pour un objet addition interface CompteBancaire { void deposer (in long value); void retirer (in long value); attribute readonly long solde; } 4-8 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 44 4 ORB Fonctionnement ■ Client – Pour faire une requête, le client peut utiliser l’interface DII, utiliser un stub statique ou interagir directement avec l’ORB. ■ Stubs IDL et Skeleton – Les stubs client IDL et les skeletons serveurs sont générés par le compilateur IDL. L’interface DII permet au client de rechercher les méthodes de l’objet Serveur à l’exécution du programme client. ■ Interface Repository (IR) – Maintient la description de toutes les classes enregistrées ainsi que la signature (nom et paramètres) des méthodes qui leurs sont associées. En fait, l’IR est une base de données de référence des classes disponibles sur un réseau à un instant donné. L’accès à ce service se fait à travers une API. ■ Adaptateur d’objet ou Basic Object Adapter (BOA) – Contrôle les instanciations d’objets sur le serveur. En réponse aux requêtes sur le réseau, ce composant instancie le serveur objet puis assure l’échange de messages entre les stubs clients et les skeletons serveurs. Toutes les instanciations d’objets sont identifiés par un Object IDentifier (OID). ■ Code Repository – Maintient le registre des classes qu’un serveur peut supporter et les OIDs de serveurs objets actifs. Ce composant gère les données associées à l’audit, la sécurité (administration de objets), etc. Objets en application Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 4-9 4 Services CORBA et facilités communes Extraits des principaux services 4-10 ■ Object lifecycle – Administration des objets ■ Object persistence – Stockage des objets ■ Object events – Notifications des événements aux objets ■ Object naming – Service de noms ■ Object transactions – Transactionnel ■ ............. Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 44 4 Services CORBA et facilités communes Alors que l’ORB fournit le mécanisme de base pour l’acheminement des requêtes entre objets, les services CORBA (COSS) offrent des fonctions fondamentales pour les objets distribués. La cible des utilités communes (CFS) est de fournir des interfaces systèmes ou frameworks pour les utilisateurs finaux. Les services CORBA sont des interfaces et services de plus bas niveau que les CFS. Objets en application Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 4-11 4 Solutions d’objets distribués ■ Réalisations CORBA sous UNIX ■ NEO (Network Environment Object) de Sun ■ DSOM (Distributed System Object Model) d’IBM ■ Orbix de IONA ■ VisiBroker de Visigenic ■ IIOP (Internet Inter Orb Protocol) implémenté par NEO, VisiBroker et Orbix ■ Autres approche objets ■ Microsoft : OLE (Object Linking and Embedding) OLE n'est pas conforme aux standards de l'industrie à savoir OMG/CORBA. 4-12 ■ COM (Common Object Model) et DCOM (Distributed COM) ■ ActiveX ■ Java RMI Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 44 4 Solutions d’objets distribués Sun Sun propose son implémentation de CORBA 2 NEO sur Solaris qui propose un compilateur IDL générant du code en Java et en C++. IBM et HP DSOM est un produit clairement concurrent de Solaris NEO et il est conforme à CORBA 2. Membre de OMG, HP propose une approche DCE étendu (OODCE), une implémentation d’ORB non conforme a CORBA. Orbix Orbix créé par IONA Technologies, est aujourd’hui disponible sur une large gamme de systèmes d’exploitation comme VMS, MAC, Windows NT, Solaris, HP-UX, etc. Orbix fournit par ailleurs une interface pour l’intégration des systèmes d’objets distribués comme OLE. OLE de Microsoft OLE permet de lier des documents ou des applications, mais pas des objets distribués mais ne répond pas aux spécifications CORBA. DCOM est en revanche une technologie d’objets distribués (non CORBA). ActiveX de Microsoft Active X est une architecture de définition de composants logiciels distribués non conforme à CORBA. Le modèle de distribution est identique à celui des applets Java sans toutefois bénéficier de l’universalité inhérente à la plate-forme Java. Objets en application Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 4-13 4 NEO de Sun ■ ■ 1988 : Projet Spring ■ 1991 : Première spécification CORBA de l’OMG ■ 1995 : version Prelude de NEO (CORBA 1.2) ■ 1996 : Version Crescendo de NEO Conforme à IIOP (Internet Inter Orb Protocol) avec nombreux services CORBA 2 disponibles Architecture du produit NEO Applications objets spécifiques Applications objets Tiers Framework Développement objet DOMF (CORBA) + Services COSS Solaris 2.x 4-14 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 44 4 NEO de Sun Caractéristiques NEO est la solution CORBA 2 de Sun. Par ailleurs, WorkShop NEO propose en plus des outils classiques WorkShop (compilateur, debugger, browser, etc) le compilateur IDL ainsi qu’un générateur d’objets distribués, Networked Object Builder, et les Frameworks de développement de NEO. Par ailleurs, il implémente avec IIOP l’interopérabilité défini par CORBA 2. NEO est complètement conforme aux standards de l’OMG : ■ CORBA à travers le Distributed Object Management Facility (DOMF), ■ COSS (niveau 1), ainsi que des fonctionnalités additives en cours d’implémentation. Autres composantes de NEO ■ Persistent Storage Manager (PSM), ■ Object Development Framework (ODF). Objets en application Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 4-15 4 Orbix d’IONA ■ Disponible sur un grand nombre de systèmes d’exploitation : SunOS, Solaris, IRIX, HP-UX,AIX, OS/2, SCO, Digital Unix, Windows NT, Windows 3.1 et 95, VMS, VxWorks, MacOS ■ Dialogue avec OLE/COM de Microsoft ■ Conforme à IIOP (Internet Inter Orb Protocol) ■ Architecture Objets serveurs Service de Noms Repository Compilateur IDL Interface IDL Orbix DII BOA Runtime Orbix Système de communication Orbix Système d’exploitation UNIX, Windows, Propriétaire 4-16 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 44 4 Orbix d’IONA Présentation Le système de communication Orbix comprend un certain nombre de classes abstraites implémentées par défaut au dessus de TCP/IP et utilisant le codage XDR (eXternal Data Representation). Le runtime Orbix comprend la partie client DII et la partie serveur appelée BOA (Basic Object Adaptor). ainsi que l’API statique. Le service de noms permet de centraliser auprès d’un serveur principal de localisation de serveurs objet. Lorsqu’un client veut utiliser un service objet particulier, il doit demander à Orbix de le mettre en communication avec le service correspondant. Une façon de faire est de fournir une référence complète de l’objet (contenant entre autres le nom de la machine sur laquelle le serveur objet est localisé). Une forme plus générale consiste à solliciter un service sans préciser la machine de localisation. Dans ce cas Orbix fait une recherche sur le réseau des machines offrant le service désigné. La localisation est transparente pour l’objet client. Le compilateur IDL (compatible avec celui de Solaris NEO de Sun) génère du C++ et Java (OrbixWEB) Orbix offre, par ailleurs, de nombreuses passerelles vers d’autres architectures Client/Serveur : moniteurs transactionnels (TUXEDO), DCOM. Par ailleurs, il implémente avec IIOP l’interopérabilité défini par CORBA 2. Objets en application Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 4-17 4 Solutions d’objets distribués avec Java Java RMI (Remote Method Invocation) ■ Invocation de méthodes distantes en Java ■ Identification des objets et transport d’informations sur le réseau ■ Gestion de la sécurité spécifique ■ Solution propriétaire Java CORBA et Java 4-18 ■ Générateurs IDL - Java ■ Permet la mise en place de solutions hétérogènes Java - C - C++ - Smalltalk ■ Prise en compte du protocole IIOP ■ Soumis à l’OMG pour approbation Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 44 4 Solutions d’objets distribués avec Java Remote Method Invocation RMI offre à deux Machines Virtuelles Java le moyen d’utiliser leurs services respectifs, que ce soit sur une même machine ou sur deux machines connectées en réseau local ou à grande échelle. RMI comporte des services de nommage et d’identification d’objets et s’appuie sur le sérialisation d’objets pour gérer le transport des paramètres sur le réseau. Le type d’architecture distribuée ainsi défini est purement propriétaire Java, mais un rapprochement vers les protocoles IIOP (Internet InterORB Protocol) devrait s’opérer rapidement. CORBA Un compilateur Java-IDL permet de générer du code Java à partir de descriptions de services écrites en langage IDL. Cela permet de bâtir des solutions hétérogènes dans lesquelles peuvent s’intégrer des clients et des serveurs écrits en C, C++, Smalltalk et Java. Une proposition de normalisation du "mapping" IDL - Java a été soumise à l’Object Management Group (OMG). Objets en application Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 4-19 4 Solutions d’objets distribués avec Java Exemple Java et CORBA Interface IDL module HelloApp { interface hello { string sayHello(); }; }; Mise en place ■ ■ 4-20 Serveur ■ Instanciation de l’ORB ■ Instanciation de l’implémentation de l’interface ■ Démarrage du service de nommage ■ Enregistrement du premier objet Client ■ Instanciation de l’ORB ■ Accès au service de nommage ■ Accès à l’objet serveur et invocation distante Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 44 4 Solutions d’objets distribués avec Java Exemple Java et CORBA Interface IDL Toutes les fonctionnalités du langage IDL normalisé par l’OMG sont disponibles. Mise en place ■ Serveur Le serveur est une application Java autonome qui initialise l’ORB et son service de nommage et d’identification d’objets. Il crée également les premiers objets dont les services pourront être utilisés de manière distante. C’est l’invocation de ces services par les objets clients qui pourra éventuellement créer de nouveaux objets utilisables à travers le réseau. ■ Client Le client peut être une applet ou une application autonome Java. Il doit créer une représentation locale d’un objet distant afin de pouvoir invoquer ses services. Pour cela, il utilise le nom attribué à l’objet par le serveur. Objets en application Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 4-21 4 Architecture de composants objets Solutions JavaBeans 4-22 ■ Réutilisabilité ■ Modularité ■ Interopérabilité ■ Développement rapide (RAD) Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 44 4 Architecture de composants objets Solutions JavaBeans JavaBeans est un modèle d’architecture de composants logiciels Java qui permet de constituer une application par simple assemblage de composants. Cette technique permet de constituer des bibliothèques d’objets de haut niveau ou objets métiers et permet de répondre de façon globale aux besoins récurrents liés au développement d’application : ■ réutilisabilité accrue par l’emploi de composants aux interfaces normalisées, ■ modularité liée à la possibilité de remplacer aisément un composant par un autre, ■ interopérabilité grâce à la possibilité d’utiliser un composant JavaBeans au sein de toute application le permettant, ■ développement rapide grâce au mécanisme d’assemblage de composants coopérants. Objets en application Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 4-23 4 Relationnel et objet Accès aux Bases de Données Relationnelles avec Java JDBC: Java DataBase Connectivity 4-24 ■ Accès à toute base de données relationnelle ou objet conforme à SQL-92 ■ Vision universelle du SGBD ■ Indépendance totale vis-à-vis des fournisseurs de SGBD Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 44 4 Relationnel et objet Accès aux Bases de Données Relationnelles JDBC : Java DataBase Connectivity Les bases de données sont au coeur de très nombreuses applications. Leur utilisation par une application souffrait jusqu’alors de la diversité des API mises à disposition par les différents fournisseurs. JDBC offre une API unique d’accès à toute base de données conforme au standard SQL2, qu’elle soit relationnelle ou objet. Une application Java est capable d’accéder de façon générique à une base de données, quel que soit son fournisseur. Objets en application Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 4-25 4 Relationnel et objet JDBC Application Java Une Machine Virtuelle JDBC (java.sql) Driver JDBC fournisseur 1 S.G.B.D. fournisseur 1 Base de données 4-26 Driver JDBC fournisseur 2 S.G.B.D. fournisseur 2 Base de données Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 44 4 Relationnel et objet JDBC Principes Il offre les moyens d’accès universels à la base de données et notamment la capacité de charger et répertorier les différents drivers d’accès aux SGBD. Un driver est particulier au SGBD dont il gère l’accès et est réalisé par une tierce partie qui peut être le fournisseur du SGBD ou tout autre éditeur de logiciels. JDBC n’offre aucun driver et spécifie uniquement l’architecture que ces drivers doivent respecter. L’implémentation des drivers est totalement libre. Objets en application Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 4-27 4 Relationnel et objet Limites du relationnel ■ Besoin de représenter des données imbriquées ■ Dichotomie entre : ■ Langage de manipulation (SQL) ■ Langage de programmation (Cobol, C, Pascal) Nouvelles approches ■ ■ 4-28 Systèmes de Gestion de Bases de Données Relationnelles Etendus (SGBDRE) : ■ Modèle V3 de CODD, ■ POSTGRES ■ UniSQL ■ Oracle V8 ■ SQL SERVER de Microsoft Nouveaux modèles de données (SGBDO) Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 44 4 Relationnel et objet Limites du relationnel A l’origine le modèle relationnel conçu pour les applications de gestion se limitait aux entiers, aux réels, aux flottants. L’émergence des technologies objet (Java, CORBA, C++) a induit une distorsion entre le modèle de données des applications et celui des bases de données (persistance). Pour résoudre ce problème, deux tendances sont apparues : les systèmes s’appuyant sur le relationnel ou systèmes de gestion de bases de données relationnels étendus (SGBDRE) et les autres fondés sur de nouveaux modèles purement objet. SGBDRE Les SGBDRE visent à étendre le modèle relationnel en lui ajoutant de nouveaux outils de modélisation tels que les types abstraits de données et des règles mais aussi en améliorant les langages de manipulation de données. Le niveau V3 de SQL ou SQL3 prévoit une approche évolutionnaire avec entre autres : ■ polymorphisme de types : union récursive et hiérarchie ■ objets persistants avec trois niveaux d’encapsulation : public, privé et protégé ■ procédures cataloguées avec plusieurs instructions SQL. Objets en application Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 4-29 4 Principes des SGBDO Historique ■ 1984 : Principes ■ 1986-87 : Premiers prototypes avec VBase, Gemstone, Iris, Orion, O2 ■ 1988-89 : Premiers produits VBase et GemStone ■ 1989-90 : La deuxième génération d’éditeurs. Caractéristiques 4-30 ■ Identité objet : tout objet a une identité indépendante de sa valeur ■ objets complexes : objets atomiques et constructeurs d’objets complexes ■ Encapsulation : objet = données + programmes ■ Typage : classe = objets de même structure et de même comportement ■ Héritage ■ Redéfinition et lien dynamique ■ Complétude ■ Extensibilité. Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 44 4 Principes des SGBDO Un SGBDO est d’abord un SGBD et fournit donc les fonctions de base pour gérer une base de données, c’est-à-dire : l’intégrité des données, leur persistance, leur indépendance physique, la possibilité de requêtes et la gestion des transactions. Un SGBDO propose en plus, la notion d’objet (données + comportement), d’héritage et de polymorphisme (facultatifs). Le schéma de base de données objet comprend la définition des classes et des associations inter-classes. L’utilisation des bases de données objet fait partie intégrante de la technologie objet et leur utilisation est en synergie avec les méthodes d’analyse/conception et les langages de programmation. En dehors de l’approche relationnel étendu qui prévoit une extension du modèle relationnel et du langage de manipulation SQL, on trouve deux approches : une approche langage aussi appelée systèmes objets persistants et une autre appelée systèmes bases de données intégrés. Objets en application Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 4-31 4 Approche langage ou objet persistant Principes Espace des objets du programme SGBDO Ecrire A Lire Objets temporaires Objets persistants Méthodes de persistance ■ Persistance manuelle, par héritage ou par référence ■ Exemples : ■ ■ 4-32 Langage OPAL de GEMSTONE : extensions de Smalltalk Langage DML d’ObjectStore : extensions de C++ Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 44 4 Approche langage ou objet persistant Principes Un langage objet tel que C++ ou Smalltalk est étendu pour permettre la définition et la manipulation d’objets persistants. C’est l’approche retenue par des systèmes ObjectStore avec C++ et GemStone avec Smalltalk. En fait, on utilise C++ ou Smalltalk à la place de SQL. Le développeur adopte alors une approche plus continue en utilisant le "paradigme objet" pour les objets temporaires et les objets persistants : il importe les définitions des classes depuis le schéma de la base pour manipuler tous les objets utiles dans son espace de travail. La lecture et l’écriture d’objet persistant est transparente. Par rapport à une approche de type relationnel avec SQL, la frontière est moins rigide grâce à la compatibilité des types temporaires et persistants (c’est à dire appartenant à la base) : en effet, on utilise le même modèle objet pour la base de données et le langage. Persistances manuelle, par héritage et par référence Pour créer dans l’espace du programme un objet persistant, il existe plusieurs méthodes : ■ Méthode manuelle : On donne la possibilité au programmeur de créer un objet persistant à partir d’un objet temporaire déjà existant. ■ Méthode par héritage : Cette technique permet de définir la persistance d’un objet par appartenance à une classe héritant d’une classe persistante. ■ Méthode par référence : Cette technique permet de définir la persistance d’un objet par création explicite d’une racine ou par attachement à un objet persistant. Objets en application Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 4-33 4 Approche Base de données objet intégrée Compte bancaire Client Nom Prénom Adresse Téléphone Profession Numéro de Client est titulaire Numéro de compte Solde Courant Seuil Découvert Revenu Mensuel a signature Catégorie Retrait Dépôt Etat Fermeture Opposition Changer Information Interdire Client Fermeture Mouvements Compte Courant Date Montant Origine 4-34 Compte Epargne Date Ouverture Intérêt Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 44 4 Approche Base de données objet intégrée Principes Un SGBDO intégré est indépendant de tout langage de programmation. Il offre une interface multi-langages (base de données O2) ou un langage de manipulation compatible avec SQL. Dans ce dernier cas, la compatibilité ascendante ne signifie pas relationnel étendu car le SGBD et son modèle voit simplement le concept de relation comme un cas particulier. En fait un système de BDO intégré préserve les avantages d’un langage déclaratif comme SQL. Le modèle proposé est en général d’un plus haut niveau sémantique qu’un modèle à objet persistant. Le modèle : ■ intégre le concept d’héritage, ■ supporte directement les relations, ■ prend en compte l’agrégation et la récursivité. Exemple Les relations ci-contre sont construites directement dans la base de données objet : héritage, relations, agrégation, récursivité. On remarque que les jointures des SGBD relationnels sont directement disponibles en orienté objet. Objets en application Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 4-35 4 Modèle objet de l’ODMG Object Database Management Group ■ Tout objet ■ Propriétés de l’objet : Attributs ■ Associations ■ Opérations (décrivant le comportement) ■ Notion de classe (implémentation d’un type) ■ Types ■ 4-36 ■ ■ Organisés en hiérarchie avec racine unique ■ Création de nouveaux types ■ Extensions Chaque objet est identifié par son OID Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 44 4 Modèle objet de l’ODMG Objectif L’ODMG est un groupe indépendant regroupant un ensemble d’éditeurs de bases de données (Object Design, Unidata O2 Technology, Objectivity, Ontos, Versant), ayant pour objectif de développer un standard pour les SGBD orientés objet. Ces travaux sont soumis à l’OMG en vue de leurs standardisations. Modèle de l’ODMG Le modèle de l’ODMG ne supporte pas de valeur et tout est objet (on retrouve une approche proche de celle de Smalltalk). Le modèle est plus général que le modèle relationnel et même que le relationnel étendu. Il supporte la notion de classe et les concepts d’attributs et d’associations sont aussi intégrés. Les attributs peuvent être multi-valués par des objets structurés et les associations 1:1, 1:N ou M:N. La notion de classe est vue comme l’implémentation d’un type. Les types sont organisés en une hiérarchie d’héritage représentant les liens types. L’héritage multiple est possible et il existe une racine unique. On peut créer de nouveaux types, en faire l’extension (retrouver tous les objets d’un type donné). Le modèle de l’ODMG supporte les opérations qui décrivent le comportement de l’objet et qui sont définies au niveau des types. Chaque objet est repérable par son Object-id (OID) qui ne peut pas changer pendant toute sa durée de vie. Objets en application Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 4-37 4 Langage d’interrogation OQL Object Query Language ■ SQL étendu objet compatible SQL2 ■ Envois de méthodes ■ Constructions de valeurs complexes ■ Standard ODMG ■ Caractéristiques : ■ ■ Requête sur les objets complexes ■ Utilisation des opérations dans les listes de projection et dans les clauses where ■ Possibilité de créer un objet résultat d’une requête Deux modes de fonctionnement : ■ interactif select tuple (auto : voiture->title, consommation: voiture.consommation) from voiture in Mercedes.voitures where voiture.consommation > 3 and exists c in voiture.caractéristiques.transmission : c.nom == "Automatique" ; ■ 4-38 intégration à C++, C, etc Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 44 4 Langage d’interrogation OQL OQL est le langage d’interrogation de bases de données objet que propose l’OMG. OQL est un langage déclaratif où une requête peut être vue comme une fonction select qui s’applique à une ou à plusieurs extensions de types et retourne une extension de types. Pour créer explicitement des objets en résultat, un constructeur de type doit être utilisé explicitement (dans l’exemple construction de l’objet tuple). Les jointures, agrégats et tris sont supportés et peuvent être appliqués aussi aux méthodes. En conclusion, il est possible d’écrire des expressions très complexes qui peuvent être imbriquées aussi bien au niveau du select, du from que du where. Objets en application Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 4-39 4 Marché des SGBDO Principales bases Produit Editeur Langage Ontos Ontos/BIM C,C++ Versant Versant C++ ObjectStore Object Design C, C++ Gemstone Servio C, C++, Smalltalk P.O.E.T. Poet Software C++ O2 UniData C, C++,O2C Orion Itasca C, C++, Lisp, Ada Matisse Intellitic C,ADA, C++, Cobol Objectivity /DB Objectivity C, C++ Jasmine Computer Associates JAD Illustra Sybase 4-40 Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 44 4 Marché des SGBDO Marché La liste des bases de données jointe ne concerne pas les systèmes relationnels étendus. Nous retrouvons les deux grandes familles avec les systèmes de type langage de programmation persistant et les autres dits bases de données intégrés. ■ GemStone (langage Smalltalk, persistance par héritage) , ■ ObjectStore (C++, persistance par référence), ■ Ontos (C++, OSQL, persistance par héritage), ■ Versant (C++, persistance par héritage) ■ P.O.E.T. (C++, persistance manuelle), ■ O2, ■ Orion. Par exemple, le système O2 est un SGBDO intégré, doté d’un environnement de développement graphique puissant. L’approche est multi-langage et son langage de requête O2SQL lui donne une forte compatibilité avec le standard de l’ODMG. Des travaux visant à l’intégration de OGLs et ODL à Java sont en cours au niveau de l’ODMG. Objets en application Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService 4-41 4 Résumé ■ Standard d’objets distribués (NEO, Orbix, VisiBroker) et interopérabilité (IIIOP) ■ Architecture de composants logiciels : ActiveX et JavaBeans ■ Interfaçage SGBDR et objet : JDBC ■ Persistance : ■ 4-42 ■ Approche évolutionnaire des SGBDRE ■ Approche révolutionnaire des SGBDO Marché : ■ Offre abondante et succès des méthodes et langages objet (effet Java) ■ Maturité des outils CASE ■ Perspective d’évolution des systèmes de gestion de base de données Concepts et méthodologie Objet illustrés par Java et C++ Révision D Copyright février 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 Corrections de l’étude de cas A A-1 Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 Fichier Fourniture.C #include "Fourniture.h" Fourniture::Fourniture(tProduit pdt) { GenInit(); Cout = 0; Volume = 0; Produit = pdt; } void Fourniture::Init(int tps) { Volume = (float)tps; Cout = this->afficheur->PrixLitre * (int)Volume; } void Fourniture::GenInit() { afficheur = 0; } void Fourniture::set_afficheur (class afficheur& a_afficheur) { p_connect_afficheur(a_afficheur); a_afficheur.p_connect_Fourniture(*this); } void Fourniture::unset_afficheur() { if (afficheur) afficheur->p_disconnect_Fourniture(*this); p_disconnect_afficheur(*afficheur); } void Fourniture::p_connect_afficheur (class afficheur& a_afficheur) { unset_afficheur(); afficheur = &a_afficheur; } void Fourniture::p_disconnect_afficheur(class afficheur& a_afficheur) A-2 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 { assert(&a_afficheur == afficheur); afficheur = 0; } Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-3 Fichier Fourniture.h #ifndef _FOURNITURE_H_ #define _FOURNITURE_H_ #include <assert.h> #include "afficheur.h" #ifndef TPRODUIT #define TPRODUIT typedef enum { essence, super } tProduit; #endif class Fourniture { public: int Cout; float Volume; tProduit Produit; Fourniture(tProduit pdt); void Init(int tps); private: void GenInit(); public: class afficheur* afficheur; void set_afficheur (class afficheur& a_afficheur); void unset_afficheur (); public: void p_connect_afficheur (class afficheur& a_afficheur); void p_disconnect_afficheur (class afficheur& a_afficheur); }; #endif A-4 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 Fichier Terminal.C #include "Terminal.h" #include "transaction.h" #include <iostream.h> void Terminal::AutoriserPompe() { this->pompe->Status = this->pompe->TestPompe(); cout << "Etat de la pompe : " << this->pompe->Status << endl; } void Terminal::SaisiePaiement(class transaction &transac) { char rep; rep =' '; cout << "volume :" << transac.volume << endl; cout << "cout :" << transac.cout << endl; if (transac.produit == essence) cout << "produit : essence " << endl; else cout << "produit : super " << endl; cout << "numero pompe :" << transac.NumeroPompe << endl; cout << "numero vehicule :" << transac.NumeroVehicule << endl; cout << "mode de paiemant :" << transac.Remarque << endl; cout << endl; while (rep != 'p') { cout << "veuillez payez svp appuyez sur p "<< endl; cin >> rep; } ValidationTransaction(); } void Terminal::ValidationTransaction() { cout << "Transaction valide" << endl; } Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-5 void Terminal::GenInit() { pompe = 0; gerant = 0; transaction = 0; } Terminal::Terminal() { GenInit(); } void Terminal::set_transaction (class transaction& a_transaction) { p_connect_transaction(a_transaction); a_transaction.p_connect_Terminal(*this); } void Terminal::unset_transaction() { if (transaction) transaction->p_disconnect_Terminal(*this); p_disconnect_transaction(*transaction); } voidTerminal::p_connect_transaction(classtransaction&a_transaction) { unset_transaction(); transaction = &a_transaction; } void Terminal::p_disconnect_transaction(class transaction& a_transaction) { assert(&a_transaction == transaction); transaction = 0; } void Terminal::set_gerant (class gerant& a_gerant) { p_connect_gerant(a_gerant); a_gerant.p_connect_Terminal(*this); } void Terminal::unset_gerant() { if (gerant) gerant->p_disconnect_Terminal(*this); p_disconnect_gerant(*gerant); } A-6 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 void Terminal::p_connect_gerant (class gerant& a_gerant) { unset_gerant(); gerant = &a_gerant; } void Terminal::p_disconnect_gerant(class gerant& a_gerant) { assert(&a_gerant == gerant); gerant = 0; } void Terminal::set_pompe (class pompe& a_pompe) { p_connect_pompe(a_pompe); a_pompe.p_connect_Terminal(*this); } void Terminal::unset_pompe () { if (pompe) pompe->p_disconnect_Terminal(*this); p_disconnect_pompe(*pompe); } void Terminal::p_connect_pompe (class pompe& a_pompe) { unset_pompe(); pompe = &a_pompe; } void Terminal::p_disconnect_pompe (class pompe& a_pompe) { assert(&a_pompe == pompe); pompe = 0; } Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-7 Fichier Terminal.h #ifndef _TERMINAL_H_ #define _TERMINAL_H_ #include "transaction.h" #include "gerant.h" #include <assert.h> #include "pompe.h" class Terminal { public: void AutoriserPompe(); void SaisiePaiement(class transaction &transac); void ValidationTransaction(); Terminal(); private: void GenInit(); public: class transaction* transaction; void set_transaction (class transaction& a_transaction); void unset_transaction (); public: void p_connect_transaction (class transaction& a_transaction); void p_disconnect_transaction (class transaction& a_transaction); public: class gerant* gerant; void set_gerant (class gerant& a_gerant); void unset_gerant (); public: void p_connect_gerant (class gerant& a_gerant); void p_disconnect_gerant (class gerant& a_gerant); public: class pompe* pompe; void set_pompe (class pompe& a_pompe); void unset_pompe (); public: void p_connect_pompe (class pompe& a_pompe); void p_disconnect_pompe (class pompe& a_pompe); }; #endif A-8 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 Fichier Timer.C #include "Timer.h" #include <iostream.h> #include <time.h> void Timer::Armer() { cout << "timer arme" << endl; time(&HeureDep); } int Timer::Arreter() { cout << "timer desarme" << endl; time(&HeureArr); return (int)(HeureArr - HeureDep); } Timer::Timer() { GenInit(); } Timer::~Timer() { } void Timer::GenInit() { pompe = 0; } Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-9 void Timer::set_pompe (class pompe& a_pompe) { p_connect_pompe(a_pompe); a_pompe.p_connect_Timer(*this); } void Timer::unset_pompe () { if (pompe) pompe->p_disconnect_Timer(*this); p_disconnect_pompe(*pompe); } void Timer::p_connect_pompe (class pompe& a_pompe) { unset_pompe(); pompe = &a_pompe; } void Timer::p_disconnect_pompe (class pompe& a_pompe) { assert(&a_pompe == pompe); pompe = 0; } A-10 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 Fichier Timer.h #ifndef _TIMER_H_ #define _TIMER_H_ #include <assert.h> #include "pompe.h" #ifndef TYPTPS #define TYPTPS typedef long TypTps; #endif class Timer { public: TypTps HeureDep; TypTps HeureArr; void Armer(); int Arreter(); Timer(); ~Timer(); private: void GenInit(); public: class pompe* pompe; void set_pompe (class pompe& a_pompe); void unset_pompe (); public: void p_connect_pompe (class pompe& a_pompe); void p_disconnect_pompe (class pompe& a_pompe); }; #endif Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-11 Fichier afficheur.C #include "afficheur.h" #include "Fourniture.h" #include <iostream.h> void afficheur::Raz() { if (this->Fourniture->Produit == essence) PrixLitre = 5; else PrixLitre = 7; Afficher(); } Fourniture &afficheur::Lecture() { return * this->Fourniture; } void afficheur::Afficher() { cout << endl; cout << "cout :" << this->Fourniture->Cout << endl; cout << "volume :" << this->Fourniture->Volume << endl; if (this->Fourniture->Produit == essence) cout << "produit : essence" << endl; else cout << "produit : super" << endl; } void afficheur::GenInit() { pompe = 0; Fourniture = 0; } A-12 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 afficheur::afficheur() { GenInit(); } void afficheur::set_Fourniture (class Fourniture& a_Fourniture) { p_connect_Fourniture(a_Fourniture); a_Fourniture.p_connect_afficheur(*this); } void afficheur::unset_Fourniture () { if (Fourniture) Fourniture->p_disconnect_afficheur(*this); p_disconnect_Fourniture(*Fourniture); } void afficheur::p_connect_Fourniture (class Fourniture& a_Fourniture) { unset_Fourniture(); Fourniture = &a_Fourniture; } voidafficheur::p_disconnect_Fourniture(classFourniture&a_Fourniture) { assert(&a_Fourniture == Fourniture); Fourniture = 0; } void afficheur::set_pompe (class pompe& a_pompe) { p_connect_pompe(a_pompe); a_pompe.p_connect_ptraff(*this); } void afficheur::unset_pompe() { if (pompe) pompe->p_disconnect_ptraff(*this); p_disconnect_pompe(*pompe); } void afficheur::p_connect_pompe (class pompe& a_pompe) { unset_pompe(); pompe = &a_pompe; } void afficheur::p_disconnect_pompe(class pompe& a_pompe) { assert(&a_pompe == pompe); pompe = 0; Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-13 } A-14 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 Fichier afficheur.h #ifndef _AFFICHEUR_H_ #define _AFFICHEUR_H_ #include "Fourniture.h" #include <assert.h> #include "pompe.h" class afficheur { public: int PrixLitre; void Raz(); class Fourniture &Lecture(); void Afficher(); afficheur(); private: void GenInit(); public: class Fourniture* Fourniture; void set_Fourniture (class Fourniture& a_Fourniture); void unset_Fourniture (); public: void p_connect_Fourniture (class Fourniture& a_Fourniture); void p_disconnect_Fourniture (class Fourniture& a_Fourniture); public: class pompe* pompe; void set_pompe (class pompe& a_pompe); void unset_pompe (); public: void p_connect_pompe (class pompe& a_pompe); void p_disconnect_pompe (class pompe& a_pompe); }; #endif Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-15 Fichier Client.C #include "client.h" #include <string.h> client::client(char* NV) { GenInit(); NumeroVehicule = new char[strlen(NV)+1]; strcpy(NumeroVehicule,NV); } client::~client() { delete NumeroVehicule; } void client::GenInit() { pompe = 0; pistolet = 0; } void client::set_pistolet (class pistolet& a_pistolet) { p_connect_pistolet(a_pistolet); a_pistolet.p_connect_client(*this); } void client::unset_pistolet () { if (pistolet) pistolet->p_disconnect_client(*this); p_disconnect_pistolet(*pistolet); } void client::p_connect_pistolet (class pistolet& a_pistolet) { unset_pistolet(); pistolet = &a_pistolet; A-16 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 } void client::p_disconnect_pistolet (class pistolet& a_pistolet) { assert(&a_pistolet == pistolet); pistolet = 0; } void client::set_pompe (class pompe& a_pompe) { p_connect_pompe(a_pompe); a_pompe.p_connect_client(*this); } void client::unset_pompe () { if (pompe) pompe->p_disconnect_client(*this); p_disconnect_pompe(*pompe); } void client::p_connect_pompe (class pompe& a_pompe) { unset_pompe(); pompe = &a_pompe; } void client::p_disconnect_pompe (class pompe& a_pompe) { assert(&a_pompe == pompe); pompe = 0; } Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-17 Fichier Client.h #ifndef _CLIENT_H_ #define _CLIENT_H_ #include "pistolet.h" #include <assert.h> #include "pompe.h" class client { public: char * NumeroVehicule; client(char* NV); ~client(); private: void GenInit(); public: class pistolet* pistolet; void set_pistolet (class pistolet& a_pistolet); void unset_pistolet (); public: void p_connect_pistolet (class pistolet& a_pistolet); void p_disconnect_pistolet (class pistolet& a_pistolet); public: class pompe* pompe; void set_pompe (class pompe& a_pompe); void unset_pompe (); public: void p_connect_pompe (class pompe& a_pompe); void p_disconnect_pompe (class pompe& a_pompe); }; #endif A-18 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 Fichier embrayage.C #include "embrayage.h" #include <iostream.h> int embrayage::Liberer() { cout << "embrayage libere" <<endl; return 0; } int embrayage::Engager() { cout << "embrayage engage" <<endl; return 1; } void embrayage::GenInit() { pompe = 0; pistolet = 0; } embrayage::embrayage() { GenInit(); } void embrayage::set_pistolet (class pistolet& a_pistolet) { p_connect_pistolet(a_pistolet); a_pistolet.p_connect_embrayage(*this); } void embrayage::unset_pistolet() { if (pistolet) pistolet->p_disconnect_embrayage(*this); Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-19 p_disconnect_pistolet(*pistolet); } void embrayage::p_connect_pistolet (class pistolet& a_pistolet) { unset_pistolet(); pistolet = &a_pistolet; } void embrayage::p_disconnect_pistolet(class pistolet& a_pistolet) { assert(&a_pistolet == pistolet); pistolet = 0; } void embrayage::set_pompe (class pompe& a_pompe) { p_connect_pompe(a_pompe); a_pompe.p_connect_ptremb(*this); } void embrayage::unset_pompe() { if (pompe) pompe->p_disconnect_ptremb(*this); p_disconnect_pompe(*pompe); } void embrayage::p_connect_pompe (class pompe& a_pompe) { unset_pompe(); pompe = &a_pompe; } void embrayage::p_disconnect_pompe(class pompe& a_pompe) { assert(&a_pompe == pompe); pompe = 0; } A-20 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 Fichier embrayage.h #ifndef _EMBRAYAGE_H_ #define _EMBRAYAGE_H_ #include "pistolet.h" #include <assert.h> #include "pompe.h" class embrayage { public: int Liberer(); int Engager(); embrayage(); private: void GenInit(); public: class pistolet* pistolet; void set_pistolet (class pistolet& a_pistolet); void unset_pistolet (); public: void p_connect_pistolet (class pistolet& a_pistolet); void p_disconnect_pistolet (class pistolet& a_pistolet); public: class pompe* pompe; void set_pompe (class pompe& a_pompe); void unset_pompe (); public: void p_connect_pompe (class pompe& a_pompe); void p_disconnect_pompe (class pompe& a_pompe); }; #endif Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-21 Fichier gerant.C #include "gerant.h" void gerant::GenInit() { Terminal = 0; } gerant::gerant() { GenInit(); } void gerant::set_Terminal (class Terminal& a_Terminal) { p_connect_Terminal(a_Terminal); a_Terminal.p_connect_gerant(*this); } void gerant::unset_Terminal () { if (Terminal) Terminal->p_disconnect_gerant(*this); p_disconnect_Terminal(*Terminal); } void gerant::p_connect_Terminal (class Terminal& a_Terminal) { unset_Terminal(); Terminal = &a_Terminal; } void gerant::p_disconnect_Terminal (class Terminal& a_Terminal) { assert(&a_Terminal == Terminal); Terminal = 0; } A-22 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 Fichier gerant.h #ifndef _GERANT_H_ #define _GERANT_H_ #include <assert.h> #include "Terminal.h" class gerant { public: gerant(); private: void GenInit(); public: class Terminal* Terminal; void set_Terminal (class Terminal& a_Terminal); void unset_Terminal (); public: void p_connect_Terminal (class Terminal& a_Terminal); void p_disconnect_Terminal (class Terminal& a_Terminal); }; #endif Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-23 Fichier moteur.c #include "moteur.h" #include <iostream.h> int moteur::Demarrer() { etat = 1; cout << "moteur demarre" << endl; return 1; } int moteur::Arreter() { etat = 0; cout << "moteur arrete" << endl; return 0; } moteur::moteur() { GenInit(); etat = 0; } void moteur::GenInit() { pompe = 0; } void moteur::set_pompe (class pompe& a_pompe) { p_connect_pompe(a_pompe); a_pompe.p_connect_ptrmot(*this); A-24 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 } void moteur::unset_pompe() { if (pompe) pompe->p_disconnect_ptrmot(*this); p_disconnect_pompe(*pompe); } void moteur::p_connect_pompe (class pompe& a_pompe) { unset_pompe(); pompe = &a_pompe; } void moteur::p_disconnect_pompe(class pompe& a_pompe) { assert(&a_pompe == pompe); pompe = 0; } Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-25 Fichier moteur.h #ifndef _MOTEUR_H_ #define _MOTEUR_H_ #include <assert.h> #include "pompe.h" class moteur { public: int etat; int Demarrer(); int Arreter(); moteur(); private: void GenInit(); public: class pompe* pompe; void set_pompe (class pompe& a_pompe); void unset_pompe (); public: void p_connect_pompe (class pompe& a_pompe); void p_disconnect_pompe (class pompe& a_pompe); }; #endif A-26 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 Fichier pistolet.C #include "pistolet.h" #include <iostream.h> int pistolet::AppuiGachette(tProduit typess) { cout << "la gachette est appuye" << endl; this->pompe->Timer->Armer(); this->embrayage->Engager(); return 1; } int pistolet::RelacherGachette() { int tps; cout << "la gachette est relache" << endl; tps = this->pompe->Timer->Arreter(); this->embrayage->Liberer(); this->pompe->ptraff->Fourniture->Init(tps); return 0; } int pistolet::Autoriser() { if (etat == 0) { etat = 1; return 1; } else return 0; } int pistolet::Interdire() { Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-27 if (etat == 1) { etat = 0; return 1; } else return 0; } pistolet::pistolet() { GenInit(); etat = 0; } void pistolet::GenInit() { embrayage = 0; pompe = 0; client = 0; } void pistolet::set_client (class client& a_client) { p_connect_client(a_client); a_client.p_connect_pistolet(*this); } void pistolet::unset_client() { if (client) client->p_disconnect_pistolet(*this); p_disconnect_client(*client); } void pistolet::p_connect_client (class client& a_client) { unset_client(); client = &a_client; } void pistolet::p_disconnect_client(class client& a_client) { assert(&a_client == client); client = 0; } A-28 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 void pistolet::set_pompe (class pompe& a_pompe) { p_connect_pompe(a_pompe); a_pompe.p_connect_ptrpis(*this); } void pistolet::unset_pompe() { if (pompe) pompe->p_disconnect_ptrpis(*this); p_disconnect_pompe(*pompe); } void pistolet::p_connect_pompe (class pompe& a_pompe) { unset_pompe(); pompe = &a_pompe; } void pistolet::p_disconnect_pompe(class pompe& a_pompe) { assert(&a_pompe == pompe); pompe = 0; } void pistolet::set_embrayage (class embrayage& a_embrayage) { p_connect_embrayage(a_embrayage); a_embrayage.p_connect_pistolet(*this); } void pistolet::unset_embrayage () { if (embrayage) embrayage->p_disconnect_pistolet(*this); p_disconnect_embrayage(*embrayage); } void pistolet::p_connect_embrayage (class embrayage& a_embrayage) { unset_embrayage(); embrayage = &a_embrayage; } void pistolet::p_disconnect_embrayage (class embrayage& a_embrayage) { assert(&a_embrayage == embrayage); embrayage = 0; } Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-29 Fichier pistolet.h #ifndef _PISTOLET_H_ #define _PISTOLET_H_ #include "client.h" #include "pompe.h" #include <assert.h> #include "embrayage.h" #ifndef TPRODUIT #define TPRODUIT typedef enum { essence, super } tProduit; #endif class pistolet { public: int etat; int AppuiGachette(tProduit typess); int RelacherGachette(); int Autoriser(); int Interdire(); pistolet(); private: void GenInit(); public: class client* client; void set_client (class client& a_client); void unset_client (); public: void p_connect_client (class client& a_client); void p_disconnect_client (class client& a_client); public: class pompe* pompe; void set_pompe (class pompe& a_pompe); void unset_pompe (); public: void p_connect_pompe (class pompe& a_pompe); void p_disconnect_pompe (class pompe& a_pompe); public: class embrayage* embrayage; void set_embrayage (class embrayage& a_embrayage); void unset_embrayage (); public: void p_connect_embrayage (class embrayage& a_embrayage); A-30 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 void p_disconnect_embrayage (class embrayage& a_embrayage); }; #endif Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-31 Fichier pompe.C #include "Fourniture.h" #include "pompe.h" #include <iostream.h> pompe::pompe(int num, int valetat) { GenInit(); Numero = num; Status = valetat; ptrpis = new pistolet; ptrmot = new moteur; ptraff = new afficheur; ptremb = new embrayage; ptrpis->p_connect_pompe(*this); ptrmot->p_connect_pompe(*this); ptraff->p_connect_pompe(*this); ptremb->p_connect_pompe(*this); } int pompe::DecrocherPistolet() { if (this->ptrpis->Autoriser()) { cout << "Le pistolet est decroche" << endl; return 1; } else return 0; } int pompe::RaccrocherPistolet() { if (this->ptrpis->Interdire()) { this->ptrmot->Arreter(); cout << "Le pistolet est raccroche" << endl; this->ptraff->Afficher(); A-32 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 EnvoiFourniture(this->ptraff->Lecture()); return 1; } else return 0; } int pompe::TestPompe() { if (this->reservoir->TestNiveau()) { if (this->ptrmot->Demarrer()) { this->ptraff->Raz(); return 1; } else return 0; } else return 0; } int pompe::EnvoiFourniture(class Fourniture &Carburant) { char * reponse; reponse = "carte bancaire"; this->reservoir->RemiseANiveau((int)Carburant.Volume); cout << endl; cout << "mode de paiement :"; cin >> reponse; cout << endl; this->transaction->Initialiser(Carburant,Numero,this->client>NumeroVehicule, reponse); return 1; } pompe::~pompe() { delete ptrpis; delete ptrmot; Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-33 delete ptremb; delete ptraff; } void pompe::GenInit() { ptraff = 0; Terminal = 0; reservoir = 0; client = 0; ptremb = 0; ptrmot = 0; ptrpis = 0; transaction = 0; Timer = 0; } void pompe::set_Timer (class Timer& a_Timer) { p_connect_Timer(a_Timer); a_Timer.p_connect_pompe(*this); } void pompe::unset_Timer() { if (Timer) Timer->p_disconnect_pompe(*this); p_disconnect_Timer(*Timer); } void pompe::p_connect_Timer (class Timer& a_Timer) { unset_Timer(); Timer = &a_Timer; } void pompe::p_disconnect_Timer(class Timer& a_Timer) { assert(&a_Timer == Timer); Timer = 0; } void pompe::set_transaction (class transaction& a_transaction) { p_connect_transaction(a_transaction); a_transaction.p_connect_pompe(*this); } void pompe::unset_transaction () { A-34 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 if (transaction) transaction->p_disconnect_pompe(*this); p_disconnect_transaction(*transaction); } void pompe::p_connect_transaction (class transaction& a_transaction) { unset_transaction(); transaction = &a_transaction; } voidpompe::p_disconnect_transaction(classtransaction&a_transaction) { assert(&a_transaction == transaction); transaction = 0; } void pompe::set_ptrpis (class pistolet& a_ptrpis) { p_connect_ptrpis(a_ptrpis); a_ptrpis.p_connect_pompe(*this); } void pompe::unset_ptrpis () { if (ptrpis) ptrpis->p_disconnect_pompe(*this); p_disconnect_ptrpis(*ptrpis); } void pompe::p_connect_ptrpis (class pistolet& a_ptrpis) { unset_ptrpis(); ptrpis = &a_ptrpis; } void pompe::p_disconnect_ptrpis (class pistolet& a_ptrpis) { assert(&a_ptrpis == ptrpis); ptrpis = 0; } void pompe::set_ptrmot (class moteur& a_ptrmot) { p_connect_ptrmot(a_ptrmot); a_ptrmot.p_connect_pompe(*this); } void pompe::unset_ptrmot () { if (ptrmot) ptrmot->p_disconnect_pompe(*this); p_disconnect_ptrmot(*ptrmot); } void pompe::p_connect_ptrmot (class moteur& a_ptrmot) { unset_ptrmot(); Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-35 ptrmot = &a_ptrmot; } void pompe::p_disconnect_ptrmot (class moteur& a_ptrmot) { assert(&a_ptrmot == ptrmot); ptrmot = 0; } void pompe::set_ptremb (class embrayage& a_ptremb) { p_connect_ptremb(a_ptremb); a_ptremb.p_connect_pompe(*this); } void pompe::unset_ptremb () { if (ptremb) ptremb->p_disconnect_pompe(*this); p_disconnect_ptremb(*ptremb); } void pompe::p_connect_ptremb (class embrayage& a_ptremb) { unset_ptremb(); ptremb = &a_ptremb; } void pompe::p_disconnect_ptremb (class embrayage& a_ptremb) { assert(&a_ptremb == ptremb); ptremb = 0; } void pompe::set_client (class client& a_client) { p_connect_client(a_client); a_client.p_connect_pompe(*this); } void pompe::unset_client() { if (client) client->p_disconnect_pompe(*this); p_disconnect_client(*client); } void pompe::p_connect_client (class client& a_client) { unset_client(); client = &a_client; } void pompe::p_disconnect_client(class client& a_client) { assert(&a_client == client); client = 0; A-36 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 } void pompe::set_reservoir (class reservoir& a_reservoir) { p_connect_reservoir(a_reservoir); a_reservoir.p_connect_pompe(*this); } void pompe::unset_reservoir() { if (reservoir) reservoir->p_disconnect_pompe(*this); p_disconnect_reservoir(*reservoir); } void pompe::p_connect_reservoir (class reservoir& a_reservoir) { unset_reservoir(); reservoir = &a_reservoir; } void pompe::p_disconnect_reservoir(class reservoir& a_reservoir) { assert(&a_reservoir == reservoir); reservoir = 0; } void pompe::set_Terminal (class Terminal& a_Terminal) { p_connect_Terminal(a_Terminal); a_Terminal.p_connect_pompe(*this); } void pompe::unset_Terminal() { if (Terminal) Terminal->p_disconnect_pompe(*this); p_disconnect_Terminal(*Terminal); } void pompe::p_connect_Terminal (class Terminal& a_Terminal) { unset_Terminal(); Terminal = &a_Terminal; } void pompe::p_disconnect_Terminal(class Terminal& a_Terminal) { assert(&a_Terminal == Terminal); Terminal = 0; } void pompe::set_ptraff (class afficheur& a_ptraff) { p_connect_ptraff(a_ptraff); a_ptraff.p_connect_pompe(*this); } Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-37 void pompe::unset_ptraff () { if (ptraff) ptraff->p_disconnect_pompe(*this); p_disconnect_ptraff(*ptraff); } void pompe::p_connect_ptraff (class afficheur& a_ptraff) { unset_ptraff(); ptraff = &a_ptraff; } void pompe::p_disconnect_ptraff (class afficheur& a_ptraff) { assert(&a_ptraff == ptraff); ptraff = 0; } A-38 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 Fichier pompe.h #ifndef _POMPE_H_ #define _POMPE_H_ #include "Timer.h" #include "transaction.h" #include "pistolet.h" #include "moteur.h" #include "embrayage.h" #include "client.h" #include "reservoir.h" #include "Terminal.h" #include <assert.h> #include "afficheur.h" class pompe { public: int Numero; int Status; pompe(int num, int valetat); int DecrocherPistolet(); int RaccrocherPistolet(); int TestPompe(); int EnvoiFourniture(class Fourniture &Carburant); ~pompe(); private: void GenInit(); public: class Timer* Timer; void set_Timer (class Timer& a_Timer); void unset_Timer (); public: void p_connect_Timer (class Timer& a_Timer); void p_disconnect_Timer (class Timer& a_Timer); public: class transaction* transaction; void set_transaction (class transaction& a_transaction); void unset_transaction (); public: void p_connect_transaction (class transaction& a_transaction); void p_disconnect_transaction (class transaction& a_transaction); public: class pistolet* ptrpis; void set_ptrpis (class pistolet& a_ptrpis); Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-39 void unset_ptrpis (); public: void p_connect_ptrpis (class pistolet& a_ptrpis); void p_disconnect_ptrpis (class pistolet& a_ptrpis); public: class moteur* ptrmot; void set_ptrmot (class moteur& a_ptrmot); void unset_ptrmot (); public: void p_connect_ptrmot (class moteur& a_ptrmot); void p_disconnect_ptrmot (class moteur& a_ptrmot); public: class embrayage* ptremb; void set_ptremb (class embrayage& a_ptremb); void unset_ptremb (); public: void p_connect_ptremb (class embrayage& a_ptremb); void p_disconnect_ptremb (class embrayage& a_ptremb); public: class client* client; void set_client (class client& a_client); void unset_client (); public: void p_connect_client (class client& a_client); void p_disconnect_client (class client& a_client); public: class reservoir* reservoir; void set_reservoir (class reservoir& a_reservoir); void unset_reservoir (); public: void p_connect_reservoir (class reservoir& a_reservoir); void p_disconnect_reservoir (class reservoir& a_reservoir); public: class Terminal* Terminal; void set_Terminal (class Terminal& a_Terminal); void unset_Terminal (); public: void p_connect_Terminal (class Terminal& a_Terminal); void p_disconnect_Terminal (class Terminal& a_Terminal); public: class afficheur* ptraff; void set_ptraff (class afficheur& a_ptraff); void unset_ptraff (); public: void p_connect_ptraff (class afficheur& a_ptraff); void p_disconnect_ptraff (class afficheur& a_ptraff); A-40 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 }; #endif Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-41 Fichier reservoir.C #include "reservoir.h" #include <iostream.h> reservoir::reservoir(int id, int qte) { GenInit(); numero = id; capacite = qte; } int reservoir::TestNiveau() { if (capacite <= 100) return 0; else return 1; } void reservoir::RemiseANiveau(int qte) { capacite = capacite - qte; cout << endl; cout << "qte reservoir : " << capacite << endl; } void reservoir::GenInit() { pompe = 0; } void reservoir::set_pompe (class pompe& a_pompe) { p_connect_pompe(a_pompe); a_pompe.p_connect_reservoir(*this); } A-42 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 void reservoir::unset_pompe () { if (pompe) pompe->p_disconnect_reservoir(*this); p_disconnect_pompe(*pompe); } void reservoir::p_connect_pompe (class pompe& a_pompe) { unset_pompe(); pompe = &a_pompe; } void reservoir::p_disconnect_pompe (class pompe& a_pompe) { assert(&a_pompe == pompe); pompe = 0; } Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-43 Fichier reservoir.h #ifndef _RESERVOIR_H_ #define _RESERVOIR_H_ #include <assert.h> #include "pompe.h" class reservoir { public: int numero; int capacite; reservoir(int id, int qte); int TestNiveau(); void RemiseANiveau(int qte); private: void GenInit(); public: class pompe* pompe; void set_pompe (class pompe& a_pompe); void unset_pompe (); public: void p_connect_pompe (class pompe& a_pompe); void p_disconnect_pompe (class pompe& a_pompe); }; #endif A-44 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 Fichier scenario.c //scenario.C #include #include #include #include #include #include #include #include #include #include #include #include #include "afficheur.h" "client.h" "embrayage.h" "Fourniture.h" "gerant.h" "moteur.h" "pistolet.h" "pompe.h" "reservoir.h" "Terminal.h" "Timer.h" "transaction.h" <iostream.h> int main(void) { char reponse; char choixess; int rep; tProduit chxpdt; //construction des instances pompe PompeA(1,0); Terminal TerminalG; gerant Jacques; client Pierre("666MM69"); transaction transac1; Timer horloge; //construction des associations PompeA.ptrpis->set_embrayage( * PompeA.ptremb); PompeA.set_Timer(horloge); PompeA.set_transaction(transac1); Jacques.set_Terminal(TerminalG); TerminalG.set_pompe(PompeA); TerminalG.set_transaction(transac1); Pierre.set_pompe(PompeA); Pierre.set_pistolet( * PompeA.ptrpis); Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-45 //debut scenario reponse = 'x'; while(reponse != 'e' && reponse != 's') { cout << "quel type de carburant voulez vous? essence (e) ou super (s) ? : "; cin >> reponse; cout << endl; } choixess = reponse; if (choixess=='e') { chxpdt = essence; reservoir Reserv(1,1000); PompeA.set_reservoir(Reserv); } else { chxpdt=super; reservoir Reserv(2,1000); PompeA.set_reservoir(Reserv); } Fourniture livraison(chxpdt); PompeA.ptraff->set_Fourniture(livraison); Jacques.Terminal->AutoriserPompe(); while(reponse != 'd') { cout << endl; cout << "pour decrocher le pistolet, appuyez sur d :"; cin >> reponse; cout << endl; } Pierre.pompe->DecrocherPistolet(); while(reponse != 'a') { cout << endl; cout << "pour appuyer sur la gachette, appuyez sur a :"; A-46 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 cin >> reponse; cout << endl; } if (choixess == 'e') rep = Pierre.pistolet->AppuiGachette(essence); else rep = Pierre.pistolet->AppuiGachette(super); while(reponse != 'l') { cout << endl; cout << "pour relacher la gachette, appuyez sur l :"; cin >> reponse; cout << endl; } Pierre.pistolet->RelacherGachette(); while(reponse != 'r') { cout << endl; cout << "pour raccrocher le pistolet appuyez sur r :"; cin >> reponse; cout << endl; } Pierre.pompe->RaccrocherPistolet(); } Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-47 Fichier transaction.C #include "transaction.h" #include "Fourniture.h" #include <string.h> void transaction::Initialiser(class Fourniture &carb, int numppe, char* numveh, char* rque) { cout = carb.Cout; volume = carb.Volume; produit = carb.Produit; NumeroPompe = numppe; NumeroVehicule = new char(strlen(numveh)+1); strcpy(NumeroVehicule , numveh); Remarque = new char(strlen(rque)+1); strcpy(Remarque , rque); this->Terminal->SaisiePaiement(*this); } void transaction::GenInit() { Terminal = 0; pompe = 0; } transaction::transaction() { GenInit(); } void transaction::set_pompe (class pompe& a_pompe) { p_connect_pompe(a_pompe); a_pompe.p_connect_transaction(*this); } void transaction::unset_pompe() { A-48 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 if (pompe) pompe->p_disconnect_transaction(*this); p_disconnect_pompe(*pompe); } void transaction::p_connect_pompe (class pompe& a_pompe) { unset_pompe(); pompe = &a_pompe; } void transaction::p_disconnect_pompe(class pompe& a_pompe) { assert(&a_pompe == pompe); pompe = 0; } void transaction::set_Terminal (class Terminal& a_Terminal) { p_connect_Terminal(a_Terminal); a_Terminal.p_connect_transaction(*this); } void transaction::unset_Terminal () { if (Terminal) Terminal->p_disconnect_transaction(*this); p_disconnect_Terminal(*Terminal); } void transaction::p_connect_Terminal (class Terminal& a_Terminal) { unset_Terminal(); Terminal = &a_Terminal; } void transaction::p_disconnect_Terminal (class Terminal& a_Terminal) { assert(&a_Terminal == Terminal); Terminal = 0; } Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-49 Fichier transaction.h #ifndef _TRANSACTION_H_ #define _TRANSACTION_H_ #include "pompe.h" #include <assert.h> #include "Terminal.h" #ifndef TPRODUIT #define TPRODUIT typedef enum { essence, super } tProduit; #endif class transaction { public: int cout; float volume; tProduit produit; int NumeroPompe; char * NumeroVehicule; char * Remarque; void Initialiser(class Fourniture &carb, int numppe, char* numveh, char* rque); transaction(); private: void GenInit(); public: class pompe* pompe; void set_pompe (class pompe& a_pompe); void unset_pompe (); public: void p_connect_pompe (class pompe& a_pompe); void p_disconnect_pompe (class pompe& a_pompe); public: class Terminal* Terminal; void set_Terminal (class Terminal& a_Terminal); void unset_Terminal (); public: void p_connect_Terminal (class Terminal& a_Terminal); void p_disconnect_Terminal (class Terminal& a_Terminal); }; #endif A-50 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 Fichier de compilation CC afficheur.C client.C embrayage.C Fourniture.C gerant.C moteur.C pistolet.C pompe.C reservoir.C scenario.C Terminal.C Timer.C transaction.C -o exo Corrections de l’étude de cas Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 A-51 A-52 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 Index A Abstract Data Type 3-25 Abstraction 1-9 ActiveX 4-13 ADT 3-7 AGL 3-57 Agrégation 1-15, 2-45 Analyzer 3-63 Applet 3-29 association 1-15, 2-43 Association lien donnée 2-45 B Base de données Objet intégrée 4-35 BOOCH 2-31 Borland C++ 3-60, 3-61 bytecode 3-33 C C++ 3-13, 3-25 cardinalité 2-43 CASE 3-55 CLASSE-RELATION 2-32, 2-33 Classification 1-4, 1-7 CLOS 3-11 Coad-Yourdon 2-31 COM 4-12 Common Object Model 4-12 Common Object Service Submission 4-5 Common Request Broker Architecture 4-5 Communication par messages 1-4 constructeur 3-39 CORBA 3-57, 4-5, 4-18, 4-19 CORBA 1.1 4-3 CORBA 2.0 4-3 COSS 4-5, 4-11 cycle de vie du logiciel 3-55 D Data Flow Diagram 2-57 DCE 4-13 DCOM 4-13 DDL 3-55 Debugger 3-63 destructeur 3-16, 3-17, 3-39 DFD 2-57 Diagramme d’états 2-55 Diagramme de classes 2-41 Diagramme de flux d’événements 2-53 Diagramme de flux de données 2-57 Diagramme de traces d’événements 2-51 diagrammes de flux successifs 2-9 DII 4-7 Distributed System Object Model 4-12 DML 4-32 DSOM 4-12, 4-13 Index-1 Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 Dynamic Invocation Interface 4-7 dynamicité 3-7 E ECMA 3-57 Eiffel 3-13, 3-23, 3-60 Encapsulation 1-4, 1-11 Environnements de développement 3-61 F fonctions virtuelles 3-11 FTP 3-27 FUSION 2-32, 2-33 JavaBeans 4-22, 4-23 JavaPlan 3-58, 3-59 JavaStudio 3-60 JDBC 4-24 K KEE 3-11 L L4G 3-61 librairie de classes graphiques 3-61 Liens dynamiques 3-11 liens statiques 3-11 M G Garbage collector 3-17 GemStone 4-33, 4-41 H héritages 3-49 Hierarchical Object Oriented Design 2-31 HOOD 2-31 HTTP 3-27 I Identité 1-7 Identité d’objet 3-8, 3-9 IDL 4-6, 4-7, 4-9, 4-18 IHM 3-55, 3-61 IIOP 4-12, 4-14, 4-15, 4-16, 4-17 Interface Definition Language 4-7 Interface Repository 4-6, 4-9 Internet 4-28 IR 4-6 J Java 3-11, 3-13, 3-59 Java DataBase Connectivity 4-24 Java RMI 4-18 Java WorkShop 3-60 Index-2 MakeTool 3-63 MCD 2-19 MCT 2-25 Merise 2-15 Merise objet 2-32 méthodes de décompositions fonctionnelles 2-7 Méthodes et encapsulation 3-9 Méthodes orientées Traitements 2-7, 2-8, 2-9, 2-10, 2-11, 2-12, 2-13 MLD 2-21 Modèle Conceptuel de Traitements 2-25 Modèle Dynamique 2-5, 2-15 Modèle Fonctionnel 2-5, 2-15 Modèle Opérationnel de Traitements 2-29 Modèle Organisationnel de Traitements 2-27 Modèle Physique de Données 2-23 Modèle Statique 2-5, 2-15 Modèle V3 du CODD 4-28 Modélisation Dynamique 2-48 Modélisation Fonctionnelle 2-56 Modélisation statique 2-40 Modularisation 1-4 MOpT 2-29 MOT 2-27 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 MPD 2-23 N NEO 4-12, 4-13 Network Environment Object 4-12 Networked Object Builder 4-15 new 3-43 O O2 4-35, 4-41 O2SQL 4-41 Object Adapter 4-9 Object Database Management Group 4-36 Object IDentifier 4-9 Object Modeling Technique 2-31, 2-39 Object Pascal 3-13 Object Request Broker 4-5, 4-7 ObjectBench 3-58 ObjectCenter 3-60, 3-61 Objecteam 3-58 Objecteering 3-58 ObjecTime 3-58 Objective C 3-11, 3-23, 3-59 ObjectPartner 3-58, 3-65 ObjectPartner BehaviorEditor 3-65 ObjectPartner FunctionEditor 3-65 ObjectPartner ObjectEditor 3-65 ObjectStore 4-33, 4-41 ObjectWorks 3-60 objets persistants 4-33 objets temporaires 4-33 ODMG 4-3, 4-37 OGL 3-55 OLE 4-12, 4-13 OMG 3-57, 4-3, 4-37 OMT 2-31, 2-33, 2-39 Ontos 4-41 OOA/D 2-31 OOA/OOD 2-31 OODCE 4-13 OPAL 4-32 opérations 3-9 OQL 4-38, 4-39 Oracle V8 4-28 ORB 4-5, 4-7, 4-20 Orbix 4-12, 4-13, 4-17 OrbixWEB 4-17 Orion 4-41 P P.O.E.T. 4-41 Paradigm 3-58 PCTE 3-57 Persistance 3-4 Polymorphisme 1-4, 1-21, 3-6, 3-11 POSTGRES 4-28 private 3-35, 3-37 propriétés privées 1-11 propriétés publiques 1-11 protected 3-35, 3-37 public 3-35, 3-37 R RAD 4-22 ramasse-miettes 3-41 référentiel 3-57 Remote Method Invocation 4-18 ROOM 2-32, 2-33 Rose 3-60 Rumbaugh 2-31 S Select/omt 3-58 SGBD 3-4, 4-24 SGBDRE 4-28, 4-29 Shlaer et Mellor 2-31 signature 3-9 Simula 3-11, 3-23 skeletons 4-9 Smalltalk 3-11, 3-21, 4-37 SMTP 3-27 SourceBrowser 3-63 SQL 4-24 SQL SERVER de Microsoft 4-28 SQL2 4-25 SQL3 4-29 SSADM 2-15 Index-3 Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999 StP 3-58 stubs 4-9 Systèmes de Gestion de Bases de Données Relationnelles Etendus 4-28 T Typage des données d’un objet 3-9 typage dynamique 3-9 typage statique 3-9 Types abstraits 3-6 U UML 2-32 Unified Modeling Language 2-32 UniSQL 4-28 upper case 3-59 V Versant 4-41 Virtualité 3-13 virtualité 3-7 Visual Age 3-60 Visual C++ 3-60, 3-61 Visual Cafe 3-60 Visual Studio 3-60 W Westmount 3-58 WorkShop 3-61 WorkShop C++ 3-60 WorkShop NEO 4-15 X X/Open 4-3 X-Designer 3-63 Index-4 Concepts et méthodologie Objet illustrés par Java et C++ Copyright February 2, 1999 Sun Microsystems, Inc. Tous droits réservés. SunService Fevrier 1999

[French Fr Logiciel Software Tutorial Programmation Java C++

Related documents

Products

Support

[French Fr Logiciel Software Tutorial Programmation Java C++

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib