Framework Orienté objet

80 %
20 %
Information about Framework Orienté objet
Technology

Published on November 23, 2009

Author: effrem

Source: slideshare.net

Description

Ce document présente une revue du concept de framework orienté objet, ainsi que de ses applications.

S Y L VA I N D E S B U R E AU X SÉBASTIEN JOBIN JIMMY PERRON PAT R IC K P E L L E T I E R G E ST IO N D E P ROJ ET S O RI EN T E S OB J ET S LES FRAMEWORKS

TA BL E D ES MATI ÈR ES Introduction..............................................................................................................5 1 Frameworks orientés-objets et leur développement..............................................6 1.1 Frameworks orientés-objets.....................................................................................7 1.1.1 Qu’est-ce qu’un framework ? .............................................................................................7 1.1.2 Pourquoi utiliser des frameworks ? ..................................................................................11 1.2 le développement des frameworks.........................................................................17 1.2.1 L’organisation du projet.....................................................................................................19 1.2.2 La préparation du développement d’un framework...........................................................23 1.3 La phase d’analyse..................................................................................................26 1.3.1 Les exigences pour le framework......................................................................................27 1.3.2 L’analyse............................................................................................................................29 1.4 La phase de design..................................................................................................32 1.4.1 Le design d’architecture.....................................................................................................35 1.4.2 Le design détaillé...............................................................................................................37 1.5 L’implantation.........................................................................................................38 1.6 Vérification et Validation.......................................................................................42 1.6.1 Test des unités....................................................................................................................45 1.6.2 Test d’Intégration...............................................................................................................46 1.6.3 Test du modèle...................................................................................................................46 1.6.4 Spécificité des frameworks................................................................................................47 1.7 La maintenance.......................................................................................................51 2 Expérience d’application des Frameworks.........................................................53 2.1 Réutilisabilité...........................................................................................................54 2.1.1 Réutilisabilité lors du développement d’un nouveau framework......................................54 2.2 Documentation........................................................................................................60 2.2.2 Les approches CookBook..................................................................................................63 2.2.3 Les approches par Pattern..................................................................................................65 2.2.4 L’approche « Langage de description de frameworks »....................................................67 2.2.5 Conclusion sur la documentation.......................................................................................69 2.3 Exemple...................................................................................................................70 2.4 Conclusion...............................................................................................................80 3 Framework JAFIMA pour les systèmes agent....................................................81 3.1 Le framework d’agent en couche...........................................................................83 3.1.1 La couche senseur..............................................................................................................85 3.1.2 La couche des croyances....................................................................................................87 3.1.3 La couche de raisonnement................................................................................................89 3.1.4 La couche d’action.............................................................................................................90 3.1.5 La couche de collaboration................................................................................................97 3.1.6 La couche de mobilité......................................................................................................105 3.1.7 Le Sous-framework de configuration et d’intégration d’agent........................................107

3.2 Conclusion sur le framework pour les systèmes agent.......................................109 Conclusion............................................................................................................111 2

TABLE DES FIGURES Figure 1- 1 : La différence de contrôle entre un framework et une librairie [Landin, Niklasson 95]..............................................................................................9 Figure 1- 2 : Frameworks vs Applications OO traditionnelles : la réutilisation en tête............................................................................................................................12 Figure 1- 3 : Le processus de développement d'un framework.............................18 Figure 1- 4 : Développement de logiciel traditionnel.............................................20 Figure 1- 5 : Plan de développement du Framework.............................................27 Figure 1- 6 : processus de développement des exigences.......................................28 Figure 1- 7 : Les exigences et la phase d'analyse avec leurs produits..................30 Figure 1- 8 : Plan de développement du Framework.............................................33 Figure 1- 9 : la phase design et ses sous-processus................................................34 Figure 1- 10 : le design pattern « stratégie » appliqué dans le framework pour les jeux de dés................................................................................................................35 Figure 1- 11 : Utilisation d’un inline explicite.......................................................41 Figure 1- 12 : La différence entre un case et le polymorphisme...........................48 Figure 2- 13 : Cycle de réutilisation d’un framework............................................56 Figure 2- 14 : Description du problème du premier motif de Hotdraw.................65 Figure 2- 15 : Partie d’un motif du framework HotDraw [Joh, 1992]..................66 Figure 2- 16 : Interface d’un template FDL...........................................................68 Figure 2- 17: Introduction générale du framework...............................................71 Figure 2- 18 : Présentation des concepts du module..............................................72 Figure 2- 19 : Présentation techniques du module................................................74 Figure 2- 20 : Description d’une classe du framework..........................................74 Figure 2- 21 : Présentation des tutoriels.................................................................75 Figure 2- 22 : découpage des diagrammes.............................................................76 Figure 2- 23 : Architecture des classes d’affichage..............................................77 Figure 2- 24 : diagramme d’objets de JTGame......................................................78 Figure 3- 25 : Modèle architectural en couche d’agent.........................................84 Figure 3- 26 : Diagramme de classes de la couche senseur.................................86 3

Figure 3- 27 : Diagramme de séquence montrant l’acquisition d’une croyance par un senseur.........................................................................................................87 Figure 3- 28 : Diagramme de classes de la couche des croyances........................88 Figure 3- 29 : Diagramme de séquence pour la mise à jour d’une croyance primitive...................................................................................................................89 Figure 3- 30 : Diagramme de séquence pour la mise à jour d’une croyance composée..................................................................................................................89 Figure 3- 31 : Diagramme de classes de la couche de raisonnement....................90 Figure 3- 32 : Utilisation du pattern « Command » dans la couche d’action.......91 Figure 3- 33 : Le pattern « Abstract Factory » qui instancie les « ConcretePlans » ..................................................................................................................................92 Figure 3- 34 : Utilisation du pattern « Decorator » dans la couche d’action.......93 Figure 3- 35 : Le pattern « Future » et le pattern « Observer » dans la couche d’action....................................................................................................................95 Figure 3- 36 : L’utilisation du pattern « Active Object » dans la couche d’action ..................................................................................................................................96 Figure 3- 37 : Diagramme de séquence pour l’exécution d’un plan.....................97 Figure 3- 38 : Le pattern « Synchronized Singleton »...........................................99 Figure 3- 39 : Le pattern « Decorator » dans la couche de collaboration..........100 Figure 3- 40 : Design de l’interface de collaboration..........................................102 Figure 3- 41 : Design de l’interface de représentation de la collaboration.........103 Figure 3- 42 : Réception de message dans la couche de collaboration...............103 Figure 3- 43 : Diagramme de séquence montrant l’assignation d’un message entrant à un « CollabThread »..............................................................................104 Figure 3- 44 : Diagramme de séquence montrant comment un message sortant est stocké dans un « MesgHolder » et passé à un autre agent.............................105 Figure 3- 45 : Architecture de la couche de mobilité...........................................106 Figure 3- 46 : La création des différentes couche de l’agent par le pattern « Agent Builder »......................................................................................................107 Figure 3- 47 : Design du pattern « Layer Linker »..............................................108 4

INTRODUCTION 5

1 FRAMEWORKS ORIENTÉS-OBJETS ET LEUR DÉVELOPPEMENT 6

1.1 FRAMEWORKS ORIENTÉS-OBJETS Toutes les personnes qui s’intéressent de près ou de loin à la programmation Orientée Objets ont déjà entendu parler d’un concept qui lui est souvent associé : la réutilisation. Les frameworks ont vu le jour dans un but de maximisation de la réutilisation. Nous allons donc ici nous intéresser à ce qu’est un framework, puis à la façon de développer des frameworks. 1.1.1 QU’EST-CE QU’UN FRAMEWORK ? Pour mieux comprendre ce que peut être un framework, regardons comment les spécialistes les définissent : ainsi, d’après Johnson, un framework est défini comme suit : “A framework is a set of classes that embodies an abstract design for solutions to a family of related problems.” [Johnson, Foote 91] et “A framework is a set of objects that collaborate to carry out a set of responsibilities for an application subsystem domain.”. [Johnson, Russo 91] Nous pourrions traduire ceci de cette façon : « Un framework est un ensemble de classes qui englobe un design abstrait en guise de solutions à une famille de problèmes similaires. » et « Un framework est un ensemble d’objets qui collaborent pour distribuer un ensemble de responsabilités d'un domaine de sous-système d'application ». On peut donc dire qu’un framework orienté objet est une architecture définie pour permettre au maximum la réutilisation de code dans un domaine donné, ou encore pour un pôle d’applications données. C’est à dire que chaque framework sera construit 7

pour un certain domaine de travail ou encore pour une certaine utilisation plus ou moins spécifique. De plus, un framework est composé de classes concrètes et abstraites. Les frameworks sont créés afin de répondre à des besoins spécifiques, et ce en englobant des classes utiles à ces applications. On pourrait donc objecter que les définitions que l’on vient de donner ainsi que les explications adjacentes correspondent exactement à l’idée que l’on se fait des librairies… Il est spécifié dans [Johnson, Foote 91] que les frameworks permettent aussi de réutiliser les implémentations (comme les librairies en fait), mais que ceci est moins important que la réutilisation des interfaces internes d’un système ainsi que la façon dont ses fonctions sont divisées entre ses composants. Et les frameworks permettent tout ceci. Lors d’utilisation de librairies, le développeur fait appel aux classes existantes de ces dernières, alors que pour les frameworks, ce sont les classes internes aux frameworks qui appellent des classes que le développeur doit personnaliser en fonction de son application, ce qui revient à dire que, contrairement aux librairies, le framework va appeler des classes spécialisées : 8

Figure 1- 1 : La différence de contrôle entre un framework et une librairie [Landin, Niklasson 95] Pour de plus amples comparaisons entre les frameworks et d’autres concepts tels que les patrons OO (« Object-Oriented Design Patterns »), les patrons de langage (« Language Patterns »), etc., nous vous renvoyons à [Mattsson 96]. Il est aussi précisé que les liaisons dynamiques permettent aux frameworks de traiter un objet sans regarder son implémentation. En fait, pour préciser comment mieux comprendre ce qui a été dit précédemment, nous pourrions dire qu’un développeur dérive une nouvelle classe à partir de la classe abstraite fournie par le framework. En ce faisant, il spécialise le code pour son application tout en suivant le patron fourni par la super classe abstraite contenue dans le framework. On dit parfois qu’un framework fournit une base guidée par l’architecture (aussi appelée boite blanche ou focalisée sur l’héritage) avec une couche supplémentaire guidée par les données (ou boite noire, ou focalisée sur la composition). Cela signifie que le développeur utilise les fonctionnalités fournies avec le framework en créant une instance d’une classe du framework et en appelant ses fonctions membres (on a à faire ici à de la focalisation sur la composition), et qu’il étend et modifie les fonctionnalités en dérivant de nouvelles classes des classes existantes, ou encore en redéfinissant des fonctions membres (ce qui est ici de la focalisation sur l’héritage). 9

A noter que lorsque l’on désirera développer des applications à partir de frameworks, il y aura des librairies de sous-classes à choisir, et la personnalisation se fera alors de manière incrémentale par composition (c’est à dire que l’on ajoutera au fur et à mesure des librairies au choix que l’on personnalisera). Par contre, si les applications sont développées uniquement par composition, il n’y aura pas besoin de coder et/ou de tester notre application (on ne fait que récupérer des composants déjà testés et codés), et on gagnera ainsi énormément de temps. M. Taligent a classé les frameworks aussi bien par leur structure interne que par leur domaine d’application [Taligent 94a]. Voici ci-après les différentes catégories qu’il a dégagées : • Les frameworks de support (« support frameworks ») : Ils fournissent des services au niveau système, comme par exemple l’accès aux fichiers, le support de calcul distribué, ou encore les pilotes matériels. Les développeurs d’application utilisent habituellement les frameworks de support directement, ou utilisent des modifications apportées par des constructeurs de matériel. Toutefois, même les frameworks de support peuvent être personnalisés, comme par exemple lorsque l’on développe un nouveau système de fichier, ou un nouveau pilote de matériel. • Les frameworks d’application (« Application frameworks ») : Ils englobent une expertise applicable à une large variété de programmes. Les frameworks commerciaux d’applications de type « interface graphique usagers » (GUI) actuels, qui supportent les fonctions standards requises par toutes les applications GUI, sont un type de framework d’application. • Les frameworks de domaine (« Domain frameworks ») : 10

Ils englobent l’expertise dans un domaine particulier, comme par exemple les frameworks multimédia, … Maintenant que nous avons défini les frameworks et passé en revue les différents types de frameworks cités dans la littérature, on peut se demander pourquoi utiliser des frameworks… 1.1.2 POURQUOI UTILISER DES FRAMEWORKS ? Nous avons succinctement abordé précédemment la raison d’être des frameworks, et ceci en rappelant la notion de réutilisation souvent recherchée en programmation, et plus particulièrement depuis l’avènement de la programmation Orientée Objets. Nous allons préciser un peu plus les raisons qui peuvent pousser à utiliser des frameworks. Pour ce faire, nous allons citer les divers avantages que peut avoir de la programmation à base de frameworks, mais nous donnerons aussi les désavantages liés à un tel choix. Tout d’abord, précisons que l’utilisation de frameworks bien conçus, bien documentés, permet la réutilisation à la fois de l’analyse, du design et du code. Un framework rend la réutilisation de l’analyse possible en décrivant les objets importants, les relations entre objets et de quelle façon des problèmes de grande taille peuvent être scindés en des problèmes de taille restreinte. Le design est quant à lui réutilisé dans la mesure où le design du framework lui-même contient des algorithmes abstraits et définit les interfaces, aussi bien que les contraintes qu’une application se doit de satisfaire. Le code est réutilisé puisqu’une classe concrète implantée par l’utilisateur peut hériter d’une super classe. [Johnson, Russo 91] [Mattsson 96] présente, en introduisant le développement des frameworks, la figure ci-dessous qui permet de mettre en relief la réutilisation permise par les frameworks, contrairement aux applications OO traditionnelles. On constate ici qu’en développant 11

des frameworks, on n’effectue qu’une seule fois les phases de développement de ceux- ci. En effet, on ne fait qu’une fois l’analyse du domaine et la conception du framework, puis on peut ensuite utiliser celui-ci dans de nombreuses applications. Si l’on avait opté pour une application OO traditionnelle, on devrait refaire les phases d’analyse du domaine et de conception du framework autant de fois qu’il y a d’applications… Autant dire que lors de l’utilisation de framework, on sauve énormément de temps puisque toute l’analyse est déjà faite… Figure 1- 2 : Frameworks vs Applications OO traditionnelles : la réutilisation en tête Nous venons donc ici d’évoquer un des avantages des frameworks, mais ce n’est pas le seul... Nous allons donc voir ci-après les avantages principaux, mais aussi les inconvénients, des frameworks. 1.1.2.1 Avantages Les avantages des frameworks sont nombreux et variés. Nous allons ici passer en revue ceux que [Landin, Niklasson 95] dégagent de leurs recherches. 12

• Le temps réduit avant la mise en marché : Lorsque l’on écrit des applications avec des frameworks comme base, seul le code qui diffère des applications précédentes doit être écrit. Il est donc nécessaire d’écrire moins de code, ce qui mène à un temps de développement amoindri et donc un temps réduit avant la mise en marché, comme évoqué en introduction de ce chapitre lors de la présentation de la Figure 1-2. • La maintenance : La maintenance de systèmes est très chère. Entre 60 et 85% du coût total du cycle de vie d’un gros système est passé sur la maintenance, et il y a donc de grosses possibilités d’économies en réduisant le besoin de maintenance [Meyers 88]. Quand on doit tenir à jour des applications se basant sur un même framework, seul le framework lui-même et le code qui diffère de entre chaque application (les spécialisations de méthode des classes du framework par exemple) qui doivent être mis à jour. Cela signifie en outre que les changements ne sont à faire qu’en un seul endroit, ce qui augmente la cohérence de l’application. Comparé à la maintenance de plusieurs systèmes différents, les économies réalisées avec l’utilisation de frameworks est non négligeable. • Les tests : Lorsque l’on réutilise un framework, on réutilise aussi les tests. Le framework que l’on utilise a déjà été testé et il n’y a donc pas besoin de refaire ces tests. Les seuls tests qui doivent être effectués sont les tests des nouveaux modules et les tests des interactions entre ces nouveaux modules et le framework, ainsi que les tests du système. Ainsi, il y a moins 13

de tests et de déboggage à effectuer. Bien sûr cela sous-entend que le framework est correct et que les tests du système vérifient que le framework est utilisé correctement. • Le niveau de confiance : Un framework pourrait, comme n’importe quel autre programme, contenir des erreurs et/ou bogues, mais comme le framework est réutilisé, il tend à se stabiliser et les nouvelles erreurs et nouveaux bogues seront alors moins fréquents. On pourrait comparer ce phénomène avec les logiciels « open source » qui voient des failles corrigées par nombre de gens et qui sont sans cesse mis à jour et maintenus. Ils gagnent à être reconnus au bout d’un certain temps lorsque très peu d’erreurs sont trouvées car la participation de tous a permis de stabiliser le produit. Ainsi, le fait de réutiliser des frameworks stables offre une plus grande confiance envers le système développé que d’écrire tout le code depuis rien. • Les standards : Un framework bien conçu d’après les standards de la compagnie permet une meilleure pratique. Quand on développe des applications depuis un framework, le framework impose des contraintes sur le code de l’application développée. Cela conduit à se conformer aux standards de la compagnie aussi bien qu’à acquérir une meilleure pratique de programmation. En fait, on pourrait résumer cela en disant qu’une compagnie peut imposer de bonnes pratiques de programmation pour ses employés (utiliser des noms de fonctions évocateurs, …) mais que ces derniers ne sont pas obligés de les suivre étant donné qu’ils rédigent leur code seul. Cependant, avec la présence d’un framework, le codeur est obligé de respecter la manière dont le framework a été conçu, étant donné 14

que ce dernier est la abs du développement et qu’il n’est pas question de le modifier. Ainsi, les bonnes pratiques de programmation se trouvent être suivies de manière involontaire. • Les frameworks englobent de l’expertise : La conception de bons logiciels dans un domaine particulier nécessite une connaissance de ce domaine, qui est acquise généralement seulement par expérience. Puisque les frameworks contiennent cette expertise, les problèmes sont résolus une seule fois et les règles de fonctionnement et de conception sont ensuite utilisables par tous. Cela permet en outre à une société de construire des programmes depuis des bases dont on sait qu’elles ont fonctionné par le passé. Les frameworks permettent aussi aux développeurs de se concentrer sur les solutions spécifiques à leur application et de se reposer sur le framework qui leur apporte des services consistants. Cela libère aussi les développeurs qui ne sont pas nécessairement experts du domaine, en ce sens qu’ils n’auront pas à étudier en profondeur les détails du domaine, qui sont inclus dans le framework et déjà développés. Tout ceci est possible car c’est le framework qui a le contrôle de l’application (cf. Figure 1-1). Ce dernier procure le flot de contrôle pendant que le code du programmeur de l’application attend d’être appelé par le dit framework. Cela revient à dire que le développeur n’a pas à se soucier des détails du framework et qu’il n’aura qu’à se concentrer sur le domaine du problème. [Taligent 94b] • La consistance reconnue et la compatibilité : Les applications développées à partir d’un même framework ont une plus grande capacité à travailler ensemble. Elles sont aussi mieux intégrées du 15

point de vue de l’utilisateur, en ce sens qu’elles ont la même interface, ou alors une interface similaire. [Taligent 94b] 1.1.2.2 Les inconvénients En fait d’inconvénients, il est plus à même de parler de difficultés. Les composants et autres architectures ne deviennent pas réutilisables d’eux même. Ils doivent être conçus avec la réutilisation en tête, ou bien avoir été re-conçus dans un but de réutilisation. Ce temps supplémentaire de travail doit être vu comme un investissement sur le long terme. [Johnson, Foote 91] [Taligent 94a] Il est aussi plus difficile de concevoir un framework qu’une bibliothèque de composants, mais le profit potentiel lié à la réutilisation d’un framework est bien plus important que celui lié à la réutilisation d’un composant d’une bibliothèque de composants. La conception d’un framework est plus difficile car l’architecture est à concevoir, mais aussi les communications entre les composants internes du framework [Johnson, Foote 91] [Taligent 94a]. Lorsque l’on conçoit un composant d’une librairie de composants, nous n’avons pas à prendre de telles décisions. Afin de permettre le succès du développement du framework, il doit être soutenu par les processus et organisation de votre équipe. Il faut que tout le monde se rende compte que les bénéfices liés aux frameworks et à la réutilisation se font avec le temps, avec de multiples utilisations du framework. [Johnson, Foote 91] [Taligent 94a] Ainsi, si l’on a vu qu’il y a de nombreux avantages à utiliser les frameworks, nous avons aussi vu qu’il n’est pas forcément si simple de concevoir puis réaliser ces dits frameworks. Intéressons-nous désormais au développement des frameworks. 16

1.2 LE DÉVELOPPEMENT DES FRAMEWORKS Pendant le développement d’un framework, les développeurs doivent essayer de réunir dans le framework le plus grand nombre possible de comportements communs entre les diverses applications. Nous allons présenter ici un processus permettant la construction d’un framework adéquat. Nous avons eu un aperçu des phases de développement d’un framework en Figure 1-2 lors de la comparaison entre la réutilisation d’un framework et celle d’une application OO traditionnelle. En fait, le processus que nous allons expliquer est plus précis que cela : 17

Analyse du domaine Exigences et phase d’analyse Design du framework Implémentation du Framework test Analyse de l’application Design de l’application Implémentation de l’application Figure 1- 3 : Le processus de développement d'un framework Ce processus est tiré de [Landin, Niklasson 95] et ne doit pas être considéré comme le seul processus efficace. Il existe d’autre processus, comme le développement basé sur l’expérience, l’utilisation de « Design Patterns », … Pour de plus amples renseignements sur ces autres processus, nous vous renvoyons à [Mattsson 96]. Remarquons cependant que le processus que nous allons étudier ici est considéré par [Mattsson 96] comme le processus général de développement des frameworks, en ce sens qu’il réunit toutes les caractéristiques communes des processus existants, lesquels diffèrent de ce dernier de quelques détails. 18

Nous allons expliquer plus en détails chacune des phases de ce processus dans la suite de ce chapitre. 1.2.1 L’ORGANISATION DU PROJET Avant de considérer plus en détail le processus de développement d’un framework, il faut savoir qu’il existe des étapes importantes pour la bonne réalisation d’un projet qui n’apparaissent pas dans le processus en lui-même. L’organisation du projet en fait partie. Nous allons au cours de ce chapitre donner une brève introduction sur les questions organisationnelles liées au développement de frameworks. Nous allons dans un premier temps regarder comment un produit de développement de framework devrait être traité en fonction des contraintes temporelles. Nous poursuivrons avec les difficultés liées à la répartition du travail entre divers groupes de travail fonctionnant en parallèle. Nous verrons ensuite quelques-unes des difficultés liées à l’adaptation des organisations au développement pour et avec la réutilisation. 1.2.1.1 Un investissement stratégique La responsabilité du développement d’un framework ne devrait pas se faire comme une organisation ordinaire de projets. La réutilisation d’un framework dépend de façon très importante d’interfaces bien définies et d’une bonne architecture, étant donné que des changements plus tardifs de ces interfaces et/ou architecture affecteraient toutes les applications dépendantes de ce framework. De ce fait, le développement d’un framework ne devrait pas être une partie critique d’un projet car l’équipe responsable de ce développement ne devrait en aucun cas faire des concessions sur le framework, ce qui conduirait à de mauvaises architectures et des interfaces mal définies. On conçoit bien là qu’il est nécessaire de faire des frameworks complets et bien définis si 19

l’on ne veut pas qu’ils aient été conçus pour rien, et que pour ce faire il faut donner à l’équipe responsable de sa réalisation les conditions nécessaires à cette réussite. Le développement d’un framework devrait être vu comme un investissement stratégique plus que comme un investissement opérationnel. Un framework bien développé sera un plus pour la compagnie, car quand il sera réutilisé diminuera les efforts de développement et fera gagner du temps pour les autres projets. La création d’un département ou d’une équipe responsable des développements stratégiques pourrait ainsi être un plus pour la société… 1.2.1.2 L’organisation du travail Figure 1- 4 : Développement de logiciel traditionnel Dans le développement de logiciel traditionnel, le travail est fait, dans la mesure du possible, par de petites équipes de développement travaillant en parallèle, avec des interfaces bien définies (cf. Figure 1-4). Chaque petite équipe travaille sur une partie bien définie du système et chaque interface du sous-système avec les autres parties a été définie au préalable, lors de phases d’étude précédentes. Un architecte Système garde à jour l’image globale du système. Une équipe de développement de framework ne devrait pas être plus grande qu’une équipe de développement de logiciels traditionnels. En effet, quand la taille d’une équipe de développement de logiciel augmente, les communications augmentent et il 20

est nécessaire de fournir plus d’efforts pour garder tout le monde informé. Il est aussi plus difficile de garder une image de la progression globale de l’équipe. Une équipe appropriée pour le développement de frameworks ne devrait pas excéder huit personnes. Il peut être judicieux de faire varier le nombre de membres de l’équipe en fonction de la phase de développement dans laquelle on se trouve. Il est par exemple important que l’équipe s’occupant de l’analyse du domaine incluse un ou deux experts du domaine. Dans la suite du processus de développement, la présence d’experts du domaine n’est plus utile mais le besoin d’experts du système augmente. Ceci devrait se ressentir dans la composition de l’équipe de développement. Le développement de frameworks introduit de nouveaux aspects lors de la division du travail. L’idée principale d’un framework est de réunir les généralités d’un domaine ou un ensemble d’applications d’un domaine. Trouver des généralités nécessite une bonne vue d’ensemble du domaine mais aussi du système. Cet aspect rend le partage du travail moins facile à effectuer. Il y aura donc un compromis à faire entre un délai plus court, quand on divise le travail tôt, et un framework avec une bonne architecture stable, quand on ne travaille pas en parallèle. Le travail devrait donc être séparé entre diverses équipes le plus tard possible dans le cycle de développement. Ainsi, la structure du framework et les interfaces publiques des classes du framework devraient être stabilisées avant de diviser le travail (conformément à ce que nous avons déjà dit à ce sujet), mais il n’est pas nécessaire d’avoir défini en détails les objets et les classes. 1.2.1.3 Les équipes de développement « pour » et « avec » la réutilisation On peut dire qu’il y a deux façons d’organiser l’équipe lors de la réutilisation de frameworks. La première est de laisser les mêmes personnes créer et réutiliser le 21

framework. La seconde est d’avoir des équipes de développement et de réutilisation différentes. Si on a l’intention de vendre le framework en dehors de la compagnie, le choix de l’organisation de réutilisation est limité… Cependant, [Landin, Niklasson 95] pensent que la plupart des compagnies vont réutiliser leurs frameworks de façon interne et que le choix de l’organisation de réutilisation dépendra alors beaucoup de la politique de la compagnie. Le framework doit être considéré comme un produit même s’il est destiné à un usage interne. Il doit donc être bien documenté et le support du framework doit être planifié. Si les développeurs du framework sont les utilisateurs, ils connaîtront le fonctionnement de ce dernier ainsi que ses problèmes et limitations. De plus, ils auront moins de problème qu’un autre pour comprendre les intentions induites par l’architecture et les solutions. L’hésitation classique lors de la nécessité d’utiliser quelque chose développé par d’autres disparaît aussi, et le feedback nécessaire de la part de l’utilisateur pour le développeur est inévitablement présent… Les équipes de développement devraient, dans la mesure du possible, être constituées d’ingénieurs expérimentés, mais ceci n’est pas si simple étant donné d’éventuelles limites dans le nombre de personnel et d’un point de vue économique. Si l’on a des équipes différentes pour le développement et la réutilisation des frameworks, la connaissance des développeurs expérimentés ayant travaillé sur le développement sera transmise aux développeurs moins expérimentés qui réutiliseront ces frameworks. C’est là le principal argument en faveur de la séparation des équipes de développement et de réutilisation des frameworks. Nous avons donc vu ici qu’il y avait quelques différences entre le développement de logiciels traditionnels et le développement de frameworks qui pouvaient avoir un 22

impact sur l’organisation du projet. Lors du développement de frameworks, il est nécessaire de prêter attention à quelle fonctionnalité est générale et quelle autre fonctionnalité est spécifique, car ceci aura un impact sur l’organisation du travail. Maintenant que nous savons ce qu’il faut prendre en compte pour un projet de développement de framework, voyons comment on prépare un tel développement. 1.2.2 LA PRÉPARATION DU DÉVELOPPEMENT D’UN FRAMEWORK On va regarder ici quelles sont les activités effectuées avant de démarrer le processus de développement d’un framework, et ce qu’il est nécessaire de connaître avant de pouvoir démarrer ce processus. L’équipe de développement doit posséder de vastes connaissances du domaine que le framework doit englober. C’est pour cela qu’il est nécessaire d’effectuer une sorte d’analyse du domaine avant une quelconque initialisation du processus de développement. L’analyse du domaine sera une sorte de paramètre d’entrée du processus de développement du framework. Cependant, le processus de développement pourrait aussi retourner un feedback à l’analyse de domaine afin de l’affiner. D’après [Karlsson 95], une analyse de domaine est l’identification des classes et objets qui sont communs à toutes les applications d’un certain domaine. Une modélisation du domaine ne devrait prendre en compte que les artéfacts clé du domaine et ne pas traiter les détails. Un modèle du domaine est un bon outil lorsque l’on commence le développement d’une vue logique du domaine. Il devrait décrire les concepts que les personnes utilisent au sein du domaine, et faire du domaine d’analyse un instrument de communication entre les gens qui prennent part au développement du système, et ce en offrant une terminologie commune. Le modèle du domaine ne 23

devrait pas décrire le domaine du point de vue des développeurs, car cela pourrait gêner la communication et risquerait de donner trop d’importance à des détails trop tôt dans le processus de développement. Une analyse de domaine offre aussi un bon support quand on utilise une spécification à base de use cases. [Jacobson et al.92] De l’analyse de domaine devraient naître au moins deux documents : la portée du domaine et un modèle statique qui contienne les objets et classes importants du domaine. Il est important de réaliser un document de portée du domaine car il est impossible pour un framework de couvrir « le monde entier », en ce sens que le framework ne couvrira peut être pas tous les aspects du domaine considéré, et que dans certaines applications certains des aspects non couverts peuvent être importants. Ainsi, en précisant la portée du domaine, on sait ce que notre framework ne couvre pas. La portée du domaine a beaucoup d’importance dans les activités de découverte des besoins du processus de développement. Elle permet de se rendre compte facilement si un besoin fait partie du domaine et est donc valide, ou ne fait pas partie du domaine et est alors invalide. Elle servira aussi en tant qu’outil dans la réutilisation d’un framework, et ce lorsque l’on décidera s’il est judicieux ou non d’utiliser celui-ci dans une application donnée. Mais il est parfois difficile, lors de la rédaction de la portée du domaine, de choisir ce qui doit être dans le domaine et ce qui ne doit pas l’être. Il est plus aisé de développer un framework pour un domaine restreint que pour un vaste domaine. Il faut consacrer suffisamment de temps pour cette activité qui est des plus importantes. Le modèle statique devrait quant à lui contenir les plus importants objets et classes du domaine. Ce peut être des objets du monde réel et/ou des objets liés au monde de l’application. Ces objets et classes devraient porter des noms qui soient explicites pour 24

les utilisateurs puisque ce modèle sera un instrument de communication entre les développeurs et les utilisateurs de la future application. L’analyse du domaine produit donc les paramètres d’entrée du processus de développement de framework, en l’occurrence la portée du domaine et le modèle statique du domaine. La portée du domaine est un bon outil au moment de valider les besoins lors du processus de développement de framework. Elle est aussi utile lorsque l’on cherche à savoir quel framework pourrait être utile pour l’application que l’on souhaite développer. Le modèle statique contient tous les renseignements pratiques utiles pour permettre le développement. 25

1.3 LA PHASE D’ANALYSE Cette phase est découpée en fait en deux parties : Les exigences du framework et l’analyse elle-même. Voyons d’abord où l’on se situe dans le développement du framework : 26

Figure 1- 5 : Plan de développement du Framework Analyse du domaine Exigences et phase d’analyse Design du framework Implémentation du Framework test Analyse de l’application Design de l’application Implémentation de l’application Intéressons nous d’abord à trouver les exigences pour le framework. 1.3.1 LES EXIGENCES POUR LE FRAMEWORK Le but de cette phase est de trouver toutes les exigences sur le système que l’on est en train de développer. Les inconsistances entre les exigences, les exigences qui sont contradictoires ou ambiguës doivent être trouvées et résolues dans cette phase. Le 27

processus de développement de découverte d’exigence peut se décomposer comme ceci : Figure 1- 6 : processus de développement des exigences Extraction Validation Spécification Les trois sous activités sont décomposées suivant [Loucopolos, Karakostas, 95] : • L’extraction des exigences est le fait de découvrir tout le savoir nécessaire qui est utilisé dans la production des spécifications des exigences. • La spécification des exigences est le processus qui reçoit en entrée les délivrables de l’extraction pour créer un modèle formel des exigences. • La validation des exigences est le processus qui tente de certifier que le modèle d’exigence formel est en accord avec les besoins des utilisateurs. Pour le choix des personnes, il faut la plus grande diversité possible afin que tous les utilisateurs, développeurs du framework soient représentés afin de prendre en compte leurs exigences pour le produit final (les développeurs pour le framework, les utilisateurs pour l’application qui en découle). La phase de découverte des exigences est très importante parce que si on ne trouve pas toutes ces exigences, ou si on ne trouve pas les bons, cela implique que l’on devra faire des changements plus tard dans le développement. Et le coût de ces changements est très élevé du fait qu’une grande partie du code et du design doit être réécrite. C’est 28

pourquoi une grand partie des efforts doit être mis en place lors de la phase d’analyse afin d’avoir une correcte, complète et consistante spécification d’exigences. Afin de rendre cette phase plus compréhensible pour les utilisateurs finaux des différents produits du framework, il est recommandé de créer des diagrammes use case spécifique à chacune des futures applications (connues lors de la création du framework) ainsi qu’un diagramme use case général que nous nommerons use case abstrait. Cela permettra aussi de trouver les différentes généralisations. 1.3.2 L’ANALYSE 29

Modèle d’exigences : Spécification d’exigences Modèle Use Case Exigences Analyse Modèle d’analyse : Modèle d’objet statique Modèle de flots de données Permet de trouver Design Figure 1- 7 : Les exigences et la phase d'analyse avec leurs produits Le but de l’analyse est de décrire un modèle du système qui est en accord avec les exigences trouvées. La phase d’analyse devrait se concentrer uniquement sur le problème et être faite sans aucune considération à-propos de l’environnement d’implantation. A ceci deux raisons, tout d’abord l’analyse restera ainsi correcte même si l’environnement change. De plus, si on si on pense aux détails d’implantation, il y a un risque que les développeurs se concentrent sur les problèmes d’implantation, ce qui entraînera que le système suppose résoudre le problème sera en dehors de ses exigences. En sortie de la phase d’analyse, on aura comme délivrables le modèle d’objet statique ainsi qu’éventuellement le modèle de flots de données par exemple. Le modèle d’analyse lorsque l’on crée un framework doit posséder la faculté de concentre 30

l’attention des développeurs sur ce qui est similaire dans les applications développées et sur ce qui ne l’est pas. La phase d’analyse a les étapes suivantes [Taligent, 94] : • Décrire la situation et le problème. • Examiner les solutions existantes. • Identifier les abstractions clés. • Identifier les abstractions de haut niveau. • Identifier avec quelles parties du problème le framework traitera. • Demander ce que veulent les clients et raffiner l’approche. Lors du raffinement, il faut trouver des classes qui viennent du modèle du domaine et qui n’ont pas besoin d’êtres enlevées. Toutes les nouvelles classes nécessaires devraient, quand c’est possible, être mises dans les hauts niveaux de l’abstraction. En effet, introduire des hauts niveaux d’abstraction conduit à accroître la généralisation du système. Lors de la phase d’analyse, il faut trouver des classes abstraites qui permettront de trouver les frameworks dans le système. 31

1.4 LA PHASE DE DESIGN Après avoir fait la phase d’analyse, la phase suivante lors du développement orienté objet est la phase de design. Nous allons voir dans cette section ce qui différencie la phase de design d’un framework par rapport a une phase de design classique 32

Figure 1- 8 : Plan de développement du Framework Un design de framework est un design de logiciel qui, lorsque c’est implanté, Analyse du domaine Exigences et phase d’analyse Design du framework Implémentation du Framework test Analyse de l’application Design de l’application Implémentation de l’application procure les fonctionnalités générales et abstraites identifiées lors de la phase d’analyse. Il y a deux sous processus au design du framework, le design d’architecture et le design détaillé. Lors du design d’architecture, les objets ainsi que leurs collaborations seront changés, afin de coller avec l’environnement de d’implantation. Durant la phase de design détaillé, les objets trouvés lors de la phase de design d’architecture sont traduits dans le langage cible et si nécessaire, sont raffinés. Cela donne le schéma suivant : 33

Design d’architecture Identification des objets Distribution des responsabilités Définition des collaborations Design détaillé Examiner et Raffiner la hiérarchie d’héritage et les collaborations prototyper Implémentation Figure 1- 9 : la phase design et ses sous-processus La chose principale à faire lors du design d’un framework est de construire une base pour une implantation générique, afin qu’elle puisse marcher pour un nombre important d’applications similaires. Lors de la phase du design, de nombreuses abstractions vont être identifiées, c’est pourquoi le design doit être facile à changer. Il faut donc d’abord identifier les abstractions. Comme de toute façon la plupart des concepts communs doivent être trouvés lors de la phase d’analyse, les abstractions trouvées lors de cette phase seront de niveau moindre. Autrement, cela veut dire qu’il faut retourner dans la phase d’analyse. Comme les abstractions sont trouvées par des méthodes de bas vers le haut (exemples concrets), il faut donc qu’il y ait un design pour trouver ces abstractions [Johnson, 95]. Afin de ne pas refaire plusieurs fois le 34

même design, il est bon d’identifier les solutions de design génériques. Une bonne manière de traiter ce solutions générique est d’utiliser des « design patterns », dont les solutions qu’ils proposent sont bien prouvées, afin de faciliter la communication entre les différents teams de design et rendre le framework plus facile à comprendre. Figure 1- 10 : le design pattern « stratégie » appliqué dans le framework pour les jeux de dés Evidemment, si un design pattern existe pour une partie du design, il est important de s’y conformer. 1.4.1 LE DESIGN D’ARCHITECTURE Comme on l’a vu précédemment, cette phase compte trois sous-phases que l’on va détailler. Mais d’abord, que fait-on lors de cette phase ? On identifie les objets dont on a besoin pour implanter le système, ainsi que leur collaboration. On peut aussi diviser le système en sous-systèmes pendant cette phase s’il est trop gros. 35

La première phase est de raffiner le modèle d’objet qui vient de la phase d’analyse. Il faut ajouter des objets afin d’adapter le système à l’environnement de développement (par exemple pour l’utilisation des API graphiques). Afin de rendre plus compréhensible le système pour l’utilisateur final du framework, il faut essayer de garder pour les objets les mêmes noms que lors de la phase d’analyse pour ne pas perdre inutilement l’utilisateur. Enfin, si une classe a plus de 25 méthodes, cela veut dire qu’il va falloir la restructurer. Une fois cela fait, il faut assigner les responsabilités du systèmes à des objets spécifiques. Pendant l'identification des opérations un objet est responsable de l'exécution et de quelle connaissance il maintiendra. Une façon commune d'exprimer des responsabilités semblables doit être employée, puisque cela peut aider pour identifier des abstractions. Si on nomme les responsabilités de manière générale, les abstractions viendront plus facilement. Parfois on n’arrive pas à trouver où exactement mettre les responsabilités, il faut donc la distribuer. Le premier souci en distribuant les responsabilités doit être de créer des méthodes qui exécutent des opérations logiques sur les instances de la classe. Le fait de distribuer l’intelligence du système permet aussi de trouver des abstractions. Définir autant de classes abstraites aussi possible impliquent la mise en place d'autant de comportements communs que possible. Puis, il faut analyser les collaborations entre les classes. Un objet collabore avec un autre objet si il invoque au moins une méthode de l’autre objet afin de satisfaire ses responsabilités [Karl,95]. Afin de faciliter l’extension du framework, il est préférable de définir des collaborations entres des classes abstraites plutôt qu’entres des classes concrètes. Enfin, pendant tout cela, il est important de raffiner la hiérarchie de classe ainsi que les collaborations. Les hiérarchies de classe doivent être assez profondes et étroites. Des hiérarchies de classes peu profondes et larges indiquent que les abstractions doivent toujours être trouvées dans la hiérarchie. Il est aussi important de préserver les 36

abstractions identifiées lors de la phase d’analyse car ce sont les abstractions fondamentales si l’analyse a été bien faite. 1.4.2 LE DESIGN DÉTAILLÉ Ici, toutes les classes avec leurs attributs et leurs méthodes sont identifiées en utilisant le langage d’implantation [Kar, 95]. On va donc ici trouver les méthodes des classes. Les méthodes doivent avoir peu de paramètres (moins de cinq) afin que l’utilisateur final comprenne facilement. De même, une méthode ne doit faire qu’un tache afin encore une fois de faciliter la compréhension de l’utilisateur final. Si une méthode fait plusieurs taches, il est peut être bon de la diviser entre plusieurs classe, pour que chaque partie soit unique dans les classes. 37

1.5 L’IMPLANTATION Analyse du domaine Exigences et phase d’analyse Design du framework Implémentation du Framework test Analyse de l’application Design de l’application Implémentation de l’application D’après Johnson : « A Framework is a generalisation of the implementation of several applications » soit, un framework est la généralisation de l’implantation de plusieurs applications [Johnson, 95]. Il faut d’abord définir une stratégie. Généralement, on fait une implantation du haut vers le bas, id est avec le développement des objets de haut niveaux d’abord. De plus, comme tous les objets de 38

bas niveaux ne sont pas présent lorsque l’on doit tester le framework, il faut trouver une manière de les remplacer. Soit on mets des stubs, soit on simule les appels de ces objets [Karl, 95] et [Som, 92]. Il faut remarquer que l’implantation est en lien très étroit avec les design détaillé (puisque si on trouve une inconsistance en développant, on reviens de facto dans le design, au moins implicitement) et avec le phase de test puisque généralement les test de classes se font juste après l’avoir implanté [Karl, 95]. L’input de la phase d’implantation est comme avec une application classique une description détaillée des classes, de leurs interfaces. L’output est l’ensemble des classes crées, prêtes à être testée. On le fait en deux étapes : • Mise en oeuvre de l'interface externe de la classe. L'interface, définie pendant la conception détaillée, est achevée pour inclure la définition interne de la classe, c'est-à-dire des attributs protégés et privés et des méthodes. • Mise en oeuvre des méthodes, commençant avec un corps de méthode vide avec type de retour correct. Le comportement interne est identifié en examinant les modèles dynamiques, c'est-à-dire les diagrammes d'interaction et les graphiques de transition d'état. Les diagrammes d'interaction peuvent aussi contenir le pseudo code, sur lequel la mise en oeuvre peut être basée. Le comportement entier des méthodes est mis en oeuvre dans cette étape. Voici quelque guides pour implanter un bon framework, partie la plus importante de la création. Tout d’abord, intéressons-nous aux relations entres les classes. Il faut que la structure de relations soit la plus simple possible parce que c’est la partie la plus ardue à comprendre. Si il y a des héritages multiples, il faut absolument commenter longuement ces héritages afin que l’utilisateur du framework en comprenne l’utilité. Un bon framework est un framework simple à comprendre, avec du code propre. Pour les 39

mêmes raisons, il vaut mieux éviter de faire des appels à des méthodes définies plus bas dans la hiérarchie de classe mais plutôt les mettre dans l’interface de la super classe. L’utilisation de classes friend doit être aussi évitée car cela passe outre l’encapsulation et donc cela peut générer des erreurs. Il vaut mieux mettre en friend seulement les méthodes de classes qui en ont besoin. Enfin les concepts d’héritage privés (qui n’est pas un concept orienté-objets mais un concept de C++) ainsi que le fait d’utiliser des héritages restrictifs ne doit pas être mis en œuvre dans un framework pour des raisons de compréhensions de l’usager final. Il faut plutôt restructure la hiérarchie d’héritage à ce moment là. Maintenant que nous avons vus les relations, intéressons nous aux classes et aux méthodes. Tout d’abord, voyons des conseils qui peuvent être vus pour tout application à créer mais qui sont très importants lors de la création de framework, afin d’éviter que l’utilisateur final ne comprenne pas ce qui est fait ou qu’il puisse faire de fausse manipulations. Ainsi toutes les classes abstraites ne doivent pas pouvoir être instanciées (par exemple en C++, il faut déclarer au moins une méthode virtual afin que la classe ne puisse être instanciée, ou alors si le constructeur est protégé), ceci afin que l’utilisateur ne le fasse par mégarde. De même toutes les méthodes qui devront être surchargée doivent être définies comme virtual. De même, il serait bon d’avoir un mécanisme qui empêche de surcharger des méthodes qui ne doivent pas l’être (mais ce n’est pas possible en C++ par exemple), afin de ne pas passer outre l’esprit du framework. Il est bon aussi de déclarer le plus possible les membres des méthodes en const, afin que la méthode ne change pas l’état de l’objet. Ceci était pour empêcher l’utilisateur de mal utiliser le framework. De même, il est important de spécifier tous les attributs de l’objet comme privés, afin de ne montrer que l’interface de l’objet et non comment on l’implante en pratique. Maintenant, il faut qu’il comprenne comment marche le framework, et pour cela, les méthodes ne devraient pas dépasser 20 lignes de codes, ou alors il faut les redessiner. Il est intéressant aussi d’enlever tous ce qui vérifie explicitement le type de l’objet afin d’utiliser au maximum les bénéfices du polymorphisme, concept très important lors de la création d’un framework, parce qu’il permet d’étendre facilement celui-ci en rajoutant simplement de 40

nouvelles sous-classes. Il est préférable d’utiliser un inline explicite qu’implicite, ceci afin de rendre l’interface la plus lisible possible, et donc de la rendre plus facilement compréhensible : class Kitty: public Money_Container { public: void Deposit(int const nAmount){ nSum = nSum+nAmount; } // Implicit inline } // File: file.h (header file) class Kitty: public Money_Container { public: void Deposit(int const nAmount); } // File: file.cc (source file): inline void Kitty::Deposit(int const nAmount){ nSum = nSum+nAmount; } //Explicit inline Figure 1- 11 : Utilisation d’un inline explicite Après les classes et les méthodes, finissons par les constructeurs et les destructeurs. Afin d’avoir le contrôle de son implantation, le concepteur doit explicitement créer les constructeurs et destructeurs de sa classe, ainsi que les opérateurs copie et assignement. De plus, si ces deux derniers opérateurs ne sont pas obligatoires, il vaut mieux les cacher dans le la partie privée de la spécification de la classe, afin que l’utilisateur ne puisse les utili

Add a comment

Related presentations

Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...

In this presentation we will describe our experience developing with a highly dyna...

Presentation to the LITA Forum 7th November 2014 Albuquerque, NM

Un recorrido por los cambios que nos generará el wearabletech en el futuro

Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...

Microsoft finally joins the smartwatch and fitness tracker game by introducing the...

Related pages

Introduction to the C# Language and the .NET Framework

C# est un langage orienté objet de type sécurisé et élégant qui permet aux développeurs de générer diverses applications sécurisées et fiables ...
Read more

SimplOOO download | SourceForge.net

SimplOOO download. SimplOOO 2016-09-04 23:44:03 free download. SimplOOO Framework bureautique orienté objet, et composants
Read more

Framework — Wikipédia

framework d'infrastructure ... objet, un framework est typiquement composé de classes mères qui seront dérivées et étendues par héritage en fonction ...
Read more

Programmation orientée objet (C# et Visual Basic)

Tous les langages managés dans le .NET Framework, tels que Visual Basic et C#, fournissent une prise en charge totale de la programmation ...
Read more

Programmation orientée aspect — Wikipédia

... œuvre aussi bien avec un langage orienté objet comme Python qu ... ou objet par exemple). Cela dit, une ... Framework 100 % Java conçu par ...
Read more

Développeur web orienté objet

Développeur web orienté objet /> PHP Objet / MySql / Javascript / Ajax JQuery / Symfony2 / Zend Framework > News. ... JQuery et Framework "maison".
Read more

Simple MVC, framework Oriente Objet pour PHP5

Simple MVC est un framework Oriente Objet pour PHP5. Le Framework est le resultat d’une simpleexpérimentationet une serie d’essais pour implementer ...
Read more

Conception d’un framework orienté objet pour le ...

JS-EABA2007 5ème Journées Scientifiques de Borj el Amri 23-24 mai 2007 Conception d’un framework orienté objet pour le développement des ...
Read more

GitHub - ludovicroland/rolandl-php-framework: Rolandl PHP ...

rolandl-php-framework - Rolandl PHP Framework is a light php framework base on the OpenClassrooms course "Programmez en orienté objet en PHP" en strongly ...
Read more