Projet Webmaster
Gestion de projets web ntic

Du concept au projet informatique - De la maîtrise d’oeuvre à la maîtrise d’ouvrage

Web-ntic MOE MOA > Powerbuilder > Mémoire Powerbuilder conclusions

Mémoire Powerbuilder conclusions

vendredi 21 mars 2003, par km

4 ème Partie du mémoire : Conclusions et annexes.

C O N C L U S I O N

La démarche

La méthode suivie a consisté à analyser les éléments qui sous tendent l’architecture C/S repartie et à comparer notre outil de développement au regard de ces éléments, pour étudier le mode opératoire vers l’architecture distribuée. Les éléments qui nous ont guidé ont été : l’outil de seconde génération et notre outil de développement PowerBuilder, c’est à dire un modèle d’outil et un outil.

L’outil

Les dix points que nous avons analysés sont focalisés sur l’outil, puisque c’est notre problématique. Néanmoins, en entreprise, si la décision de réécrire ou non l’application doit être prise, cet élément constitué par l’outil peut être pris en considération mais il n’est pas le seul, d’autres problématiques se posent. Je pense que le paradigme du mainframe est différent du paradigme client-serveur, lui-même différent du paradigme Internet, [FAURE97] souligne qu’Internet constitue une nouvelle plate-forme, de même que le client serveur constitue une plate-forme. L’outil propose une évolution vers le client serveur, et c’est notre problématique, et propose une solution avec Internet. Une question peut alors se poser : les compétences client-serveur sont elles suffisantes pour l’architecture Internet ou faut-il des compétences spécifiques. Se pose alors la problématique de la cible à atteindre, le C/S distribué ou Internet, qu’apporte Internet, quels sont les problèmes qu’il résout, quels sont ceux qu’il pose. Peut-on considérer Internet comme étant un paradigme du client-serveur, ou bien est-ce un nouveau paradigme [Faure97], et quelles sont alors les différences et quelles modifications doivent être apportées au niveau du SI (compétences, coûts, architecture technique, comportements humains face à une nouvelle technologie).

Les règles

Cette analyse de l’outil s’est faite en regard de dix règles. La méthode suivie fait l’hypothèse que ces règles aient été correctement choisies. De manière théorique, elles répondent à ce que l’on peut attendre d’un outil de seconde génération. Mais sur le plan de l’application en entreprise, d’une part certaines règles ne sont pas nécessaires (règle n°3 sur le transactionnel lourd). D’autre part il me semble que les solutions adressées par les systèmes ouverts, donc des systèmes nécessitant un choix en termes de fournisseurs, éditeurs et constructeurs, s’appliquent à une entreprise donnée. Pour une autre entreprise la solution ne peut être appliquée telle que, mais demande des adaptations, c’est le cas notamment de la mise en place de solution de Middleware [FAURE97] ou de Corba [FAURE97], qui sont en fait des solutions programmables. Il est alors préférable d’adapter ces règles à l’entreprise, ce qui introduit un biais dans le modèle qui nous a servi de référence.

Dès lors, concernant la comparaison de PowerBuilder avec ces règles, il convient également de regarder le cas spécifique de l’entreprise ; ainsi si les procédures stockées ou les DataWindow constituent une limite pour notre problématique, elles ne le seront pas pour une autre entreprise. Nous nous trouvons en face de règles qui sont génériques et un cas entreprise qui est spécifique. Il parait alors difficile de comparer un cas particulier à un modèle. Cependant je pense que les dix règles constituent un cadre de référence, un modèle général que l’on peut appliquer avec des adaptations pour les spécificités.

Une autre limite que l’on peut retrouver au niveau de la méthode est son aspect statique, le modèle représenté par les dix règles ne prend pas en compte l’aspect évolution. Ainsi dans notre problématique, ce n’est pas tant l’utilisation de PowerBuilder pour une architecture répartie qui nous pose problème (aspect statique), mais plutôt une telle évolution (aspect dynamique) avec des applications qui ont leur historique, qui ont été écrites d’une certaine manière. Cet aspect de prise en compte de l’existant n’est pas abordé dans les dix règles, ni même coté Powersoft, si on regarde les annonces marketing qui sont faites [SYBASE99] [POWERSOFT99].

La méthode

Je pense que la méthode utilisée a permis de mettre en évidence un manque de profondeur de l’outil au niveau des concepts objets, et cette profondeur, cette philosophie objet fait défaut dans la répartition (forte imbrication des traitements et de l’interface graphique dans les DataWindow, rendant difficile le passage de DataWindow à DataStore). La méthode utilisée, si elle peut-être biaisée par différents éléments, permet toutefois de confronter un outil avec un modèle d’outil. Au regard des éléments étudiés, je pense que cette méthode offre une analyse de surface par l’étude du modèle (les dix règles) et une étude de profondeur de l’outil en lui même, permettant une analyse fine depuis un champ d’analyse défini. Ainsi dans notre cas d’entreprise cette approche a permis de confirmer les limites de l’outil, et d’appuyer des éléments essentiels (le référentiel, la fenêtre unique par exemple). Cette méthode peut-être enrichie, et notamment en élargissant le champ d’investigation du modèle (qu’en est il de la conception ? peut-on utiliser une conception procédurale pour un développement orienté objet ?) ; elle constitue néanmoins un cadre de référence exploitable. D’autres méthodes auraient pu être menées :

  • Le point clé de notre problématique étant constitué des éléments de l’outil face à la répartition, nous aurions pu nous interroger sur les éléments qui limitent ou favorisent la répartition, et essayer de généraliser cette approche. Cette approche des éléments génériques de la répartition pourrait être reproduite sur un autre outil. Il aurait été intéressant ainsi de comparer les résultats de l’approche avec un outil purement de seconde génération tel que Forté de Forté Software ou Natstar (ces outils ont été conçus dèsle départ pour une architecture client serveur réparti).
  • L’architecture client-serveur est une cible que l’on veut atteindre dans un premier temps, et que l’on veut ensuite projeter vers l’architecture Internet. Sans remettre en cause l’architecture Internet bien qu’il me semble qu’elle constitue une problématique, nous aurions pu étudier ce que j’appellerai l’outil de troisième génération, c’est à dire un outil permettant d’une part de conserver les apports de l’outil de seconde génération, d’autre part d’implémenter l’architecture Internet. De même qu’il a été fait ici, nous aurions pu comparer ce modèle d’outil avec ce que propose PowerBuilder pour Internet et tirer des enseignements.

Cette méthode, si elle peut-être enrichie, a permis de comparer PowerBuilder avec un modèle d’outil de seconde génération. Si le modèle doit être adapté à l’entreprise, pour prendre en compte les spécificités de son SI, il peut en grande partie servir de référence pour une comparaison, notamment dans ses éléments essentiels. Ainsi, vis à vis de ce modèle, PowerBuilder apparaît en adéquation avec certaines règles, mais constitue une limitation à la répartition vis à vis des règles qui ne sont respectées qu’en partie. Parmi ces éléments nous avons vu les procédures stockées qui sont une limite à la règle de la fenêtre unique (règle n°1), les DataWindows qui imbriquent traitements et présentation et s’opposent à la règle d’orientation service (règle n°2). Il est des éléments positifs tels que le référentiel (règle n°7).

Face à ce décalage entre l’outil de développement et le modèle de ce que l’on pourrait attendre d’un outil de seconde génération, et compte tenu de la spécificité de notre SI, il convient à notre niveau d’être prudent en termes de choix et notamment de cible à atteindre entre le client serveur réparti et l’architecture Internet avec ses composants spécifiques. Ces deux architectures sont distinctes [FAURE97], mais ne semblent pas être différenciées au niveau de PowerBuilder ; cependant, il est un point commun tant au niveau des architectures que des scénarios d’évolution, c’est celui du concept d’objet, objet Powerbuilder au niveau de l’outil ou objet Internet encapsulant un objet Powerbuilder.

Ce point commun semble, au travers de ce que nous avons vu, un point de passage obligé vers la répartition, la maîtrise de ce concept passe par la maîtrise de règles au niveau de l’outil, à défaut de quoi l’évolution vers la répartition semble soit compromise, soit devoir nécessiter des coûts importants en réécriture.

Résumé de la conclusion :

La méthodologie utilisée nous a permis de comparer un outil de développement avec un modèle d’outil en environnement distribué, cette démarche laisse apparaître des biais du à l’aspect générique du second élément opposé à un aspect spécifique d’emploi de PowerBuilder dans un SI qui a des propriétés propres, un historique. Au delà de ces biais, cette méthodologie permet toutefois d’analyser l’outil en profondeur et partant d’une situation donnée, d’envisager des scénarios d’évolution vers la répartition. Ainsi, il apparaît que l’objet, point commun tant des architectures ciblées, que des scénarios est un élément clés de la distribution. Non maîtrisé en tant que concept, il peut compromettre l’atteinte de la cible ou nécessiter des coûts importants.


Dictionnaire client serveur

Bibliographie


[01Info97] "JAVA ET ACTIVE X, DEUX TECHNOLOGIES À LA VOCATION IDENTIQUE " 01 Informatiques, N° 1454 23/05/1997 1997
[Andrieu96] Olivier Andrieu, "Informatique et réseaux : Java mène la danse", 1996
[Baudoin 96] Baudoin, Claude & Hollowell, Glenn. Realizing the Object-Oriented Lifecycle. Upper Saddle River, NJ : Prentice Hall, 1996.
[Bénard95] Philippe Bénard, Alain Dang-Van-Mien, "L’architecture de services" Edition Addison-Wesley, Juillet 1995
[Bouzeghoub97] Mokrane Bouzeghoub, Georges Gardarin, Patrick Valduriez, "Les objets", éditions Eyrolles, Septembre 1997.
[Caussin98] Olivier Caussin, "La programmation orientée objet", 1998
[Dagorn94] François Dagorn , "World-Wide Web", 1994
[Debrauwer94] Laurent Debrauwer, "L’héritage multiple", 1994
[Dickman 95] Dickman, A. "Two-Tier Versus Three-Tier Apps." Informationweek 553, Novembre 1995.
[FAURE97] P. Faure, "Systèmes d’Information modernes : les clés de l’avenir" 1997
[Guerraoui96] R. Guerraoui, M. Aksit, A. Black, L. Cardelli, P. Cointe, "Strategic research directions in Object Oriented Programming", "ACM Computing Surveys", vol. 28, no. 4, , 1996
[Hudson 94] Hudson, D. & Johnson, J., "Client-Server Goes Business Critical. Dennis", MA : The Standish Group International, 1994.
[IEEE 90] Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary : A Compilation of IEEE Standard Computer Glossaries, New-York, NY : 1990.
[Jacquot 96] Thierry Jacquot, "Les objets - Les phases d’analyse et de conception conditionnent les gains de programmation", 01 Informatique N°1404 3/05/96
[Lagoden97] Jean Lagoden , "Pleins feux sur les objets métiers", Logiciels & Systèmes, Septembre 1997
[Larcher 98] Eric Larcher, "Introduction aux technologies Java et Active X", 78 1998
[Lefevre98] Alain Lefevre, "Web client-serveur", CMP, 10/1998
[Lesueur98] B. Lesueur, N. Revault, G. Sunyé, M. Ziane , "Using the MétaGen Modeling and Development Environment in the FIBOF Esprit Project" , "International Workshop on Automating the Object-Oriented Software Development", ECOOP’98, 1998
[Macary97] Jean-François Macary, "Technologies push", Edition Eyrolles, octobre 1997
[Meinadier91] Jean-Pierre Meinadier, "L’interface utilisateur", Edition Dunod, septembre 1991
[Perzinsky97] Boris Perzinsky, "Réutilisation, les composants métiers arrivent" Logiciels & Systèmes, Décembre 1997.
[Poisson98] Marie-Andrée Poisson, "Conception et développement orientés objet (OO)", 1998
[Powerline98]1998
"Economies of Scalability", Topher White, 1999
"Moving Client/Server to the Web" Andrew McKay, 1999
"Generating Components with PowerBuilder" Marc Cajolet, 1999
"Platform Freedom for Your Applications" Susan Gauthier "No Recoding Required " Marlana C. Patton, 1999
[Powersoft]
[Prométhéus96] Institut Prométhéus, "Les outils de développement client-serveur d’entreprise", 1996
[Rugy 98] Alain de Rugy, "Management et gestion de parc informatique" Edition Hermes 1998
[SEI97] Software Engineering Institute, Handbook, CMU/SEI-97-HB-001, Janvier 1997
[Sybase]
[Wallnau97] Kurt Wallnau, Nelson Weiderman, Linda Northrop, "Distributed Object Technology With CORBA and Java : Key Concepts and Implications", TECHNICAL REPORT CMU/SEI-97-TR-004, Juin 1997

Résumé et Introduction du Mémoire sur Powerbuilder
Objet et client serveur
Powerbuilder Outils de seconde génération client serveur
PowerBuilder l’outil client serveur
Mémoire Powerbuilder conclusions






Répondre à cet article et accéder au Forum Mémoire Powerbuilder conclusions

Imprimer Mémoire Powerbuilder conclusions