La méthode a consisté à produire un document de synthèse répondant, avec plusieurs niveaux de lecture, à une problématique relative à l’architecture distribuée.
Connaissance du client serveur, architecture, 1 à n tiers
4 ème Partie du mémoire : Conclusions et annexes.
3 ème partie du mèmoire : PowerBuilder et les scénarios possibles.
2 ème Partie du mémoire : l’outil de seconde génération
1 ère partie du memoire : L’Etat de l’art, l’objet et le client-serveur distribué.
Résumé et Introduction du Mémoire : Powerbuilder et l’architecture distribuée
Vous êtes actuellement dans WEB-NTIC > Powerbuilder Thème spécifique au L4G Powerbuilder au travers d’un mémoire de DESS. Mise en ligne: vendredi 21 mars 2003, par km Mémoire Powerbuilder conclusionsC O N C L U S I O NLa 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 :
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. Bibliographie[01Info97] "JAVA ET ACTIVE X, DEUX TECHNOLOGIES À LA VOCATION IDENTIQUE " 01 Informatiques, N° 1454 23/05/1997 Résumé et Introduction du Mémoire sur Powerbuilder Répondre à cet article et Acceder au Forum Mémoire Powerbuilder conclusions
|
Plan Web Ntic | Espace rédacteurs | Résumé | XML
Copyright © 2008 Web-ntic MOE MOA - Tous droits réservés. Responsable éditorial : km |