Définition

Nous définissons un framewok comme un ensemble de classes destinées à être utilisées pour développer des applications pour un domaine et un système informatique donné. On entend par domaine, le type d’application : gestion, logiciel de simulation, jeux, etc..
Dans la suite de notre propos, nous allons uniquement discuter des frameworks qui couvrent les applications de gestion en GUI (Graphical User Interface, interface graphique de type Windows) . Pour ce type d’application, dès lors que le projet est important, l’utilisation d’un framework est indissociable d’une programmation de qualité.
En effet, en application de gestion la cinématique d'une application peut être décomposée en une série de cinématiques de base que l’on rencontre régulièrement. En conséquence, un framework doit contenir un ensemble de classes qui possèdent toutes les primitives nécessaires pour permettre aux descendants de ces classes d’adopter la cinématique souhaitée en redéfinissant et, le cas échéant, en enrichissant ces primitives. Autrement dit, tout ce qui est du ressort de la cinématique de base des applications de gestion doit avoir été factorisé dans les classes du framework et notamment la gestion :
1. des erreurs de tous types (applicatives, base de onnées, etc.)  ;
2. des transactions avec la base de données ;
3. différentes formes de présentations des données (liste, détail) ;
4. de la cinématique du contrôle des règles de gestion ;
5. de la cinématique de consultation et mise à jour des données (opérations élementaires)
6. de la cinématique concernant l’ouverture des fenêtres et le passage de paramètre

Le développement d’un framework

ll ne faut pas sous-estimé la complexité de mise en œuvre des différents points précédents au niveau d’un framework, d’autant qu’il est impératif que celui-ci permette de redéfinir l’ensemble de cette gestion au niveau de chaque classe. Cela n’est envisageable que si le framework a été conçu en utilisant les concepts objets. Si tel n’est pas le cas,  le framework impose soit de retenir la cinématique qu’il a lui même décidé d’adopter, soit de réécrire complétement cette cinématique. En prenant le concept de la classe ouverte et fermée, un framework qui n’a pas mis en œuvre les concepts de la programmation orientée objet peut être considéré comme fermé, alors qu’un framework qui les a implémentées est à la fois fermé (directement utlisable) et ouvert (on peut le modifier en s’appuyant sur l’existant). Un framewok fermé aura beaucoup de difficultés à évoluer en intégrant les nouvelles avancées technologiques. Le plus souvent, il se contentera d’ajouter des nouveaux services bien moins contraignants à implémenter (comme le font les PFC) que le recours à l’héritage, mais bien plus complexe à apréhender et à maintenir.
L’élaboration d’un framework pour les applications de gestion en GUI est difficle et complexe, il demande de la part du concepteur à la fois une très bonne connaissance de ce type d’application mais également une très bonne connaissance des techniques de la programmation orientées en GUI. Même si ces qualités sont réunies, il faut compter plusieurs années durant lesquelles, confronté à de nouveaux problèmes soulevés par de nouvelles applications de gestion, le framework devra évoluer constamment, pour parvenir à être réellement l’outil productif et maintenable que l’on avait imaginé.
La construction d’un framewok constitue un projet à part entière qui diffère totalement d’un projet de gestion. En effet, il s’agit ici de construire un véritable outil destiné à être utilisé pour les futurs développements. Or, l’élaboration d’un logiciel outil obéit à une logique de dévelopement qui n’est pas comparable avec une application de gestion. Il s’agit d’un véritable projet industriel avec des difficultés multiples comme :
- l’abstracton très forte du développement ;
- La validation de l’efficacité du framework. On développe pour cela une application type de gestion avec le framework mais cela n’est jamais suffisant pour être certain que ce dernier conviendra également à d’autres applications à la problématique parfois très différentes ;
- La définition du périmètre de son utilisation. Qu’elles applications cibles ?
Dans la pratique, on rencontre quatre types de frameworks :

1. Les frameworks professionnel qui ont été développés comme un projet industriel avec de grand moyens financiers par les grands éditeurs du monde de l’informatique

2. Les frameworks que nous qualifierons de « semi-professionnels » car il ne bénificient pas des moyens financiers du précédent type, sont le fruit de l’expérience de développement de projet de la part de sociétés de services qui ont capitalisé leur savoir-faire sur un framework. La genèse de ce type de framework est une réalisation au forfait d’un projet important qui justifiait la création d’une infrastructure de développement. Cette infrastructure sera ensuite utilisée et améliorée pour d’autres projets, jusqu'à devenir un framework suffisament abouti pour être commercialisé. Cependant une fois commercialisé, le framework, paradoxalement, n’est plus en situation d’évoluer de manière optimale. En effet, lorque le framework était uniquement destiné à répondre aux besoins de développement d’un projet, il était toujours possible dans le cadre du projet de le modifier de manière significative, les coûts de ces modifications étaient intégrées dans le coût global du projet. Dès lors que le framework est commercialisé, on ne peut plus le modifier en profondeur en fonction d’un unique projet, car la nouvelle version est censée être distribuée dans tous les sites qui ont un contrat de maintenance avec la société qui le commercialise. Une modification en profondeur générerait des coûts en cascades financièrement impossibles à assumer. Le framework évolura donc à minima, générant une source de profits au début de sa commercialisation lorsqu’il sera technologiquement « up to date ». Cette source se tarira forcément lorsque le framework, vieillissant, n’aura pas sufisament évolué.

3. Les framewoks d’entreprise sont des framewok non commerciaux qui ont été développés pour les besons d’une société qui les utilise pour ses projets. La génése de ces framework est sensiblement indentique à celle du précédent type de framewok, un projet au départ puis l’utilisation et l’amélioration pour d’autres projets. Si le framework est partagé par l’ensemble des projets de l’entreprise, le risque est qu’il ne puisse pas évoluer correctement pour les mêmes raisons que le précédent type de framework : une modification en progondeur impliquerait une mise à jour coûteuse de tous les projets qui l’utilisent. En revanche, si chaque projet coupe le lien avec le framework, la nouvelle version du framework ne sera pas utilisée pour les anciens projets et le framework pourra  évoluer de manière optimale. L’inconvénient est qu’il existe plusieurs versions du framework au sein de la société.

4. Les frameworks personnels sont des frameworks qui ont été développés par une ou plusieurs personnes et ne sont pas commercialisés avec une licence d’utilisation, comme peuvent l’être les frameworks semi-professionnel, mais dont les droits d’utilisation peuvent être acquis auprès des concepteurs pour une utilisation au sein d’une entreprise. Une fois acquis les droits, l’entreprise considère le framework comme le sien mais elle ne peut elle-même le commercialiser, et le fait évoluer en framework d’entreprise. L’avantage pour la société, c’est la souplesse de la formule, pas de contrat de maintenance, pas de migration à venir, mais en contrepartie cela demande un effort d’investissement important de la part du personnel qui sera amené à utiliser le framework afin d’en assimiler la logique. C’est en effet le personnel qui en assurera l’évolution. Les frameworks personnels n’ont pas les contraintes des frameworks semi-professionnel et peuvent donc évoluer en fonction du temps que veulent bien leur consacrer leurs auteurs.

Il est posssible d’imaginer le framewok idéal. Il servirait d’infrastructure à de nombreux projets et il serait possible de le faire évoluer sans que cette évolution implique un impact important sur les applications qui l’utilisent. Autrement dit, un framewok qui soit à la fois partagé et puisse évoluer sans que cette évolution ne génère un coût concernant le partage. On retrouve la notion d’ouverture/fermeture, le framework est fermé pour les applications qui l’utilisent et ouvert pour les futures évolutions. Un tel framework est, dans l’état actuel des techniques informatiques utilisées dans la gestion en GUI, peu envisageable. La migration d’application, en l’occurrence le passage d’une application vers une nouvelle version de framework, a encore de beaux jours devant elle.

Framework et PowerBuilder

En PowerBuilder, les "Powers Tools"  qui pouvait rentrer dans la catégorie framework de type 1 (professionnel) a été abandonné. Il existe encor la possibilité d'utiliser les PFC, mais outre leur complexite, ces classes ont été conçues avec la version 6.5 de PB et n'ont pas évoluées en harmonie avec les versions ultérieures. De plus, les PFC ont été conçues sous forme de services et non de programmation objets avec tous les inconvéninets de ce type de programmation.


Dans la catégorie 2, il reste la "PowerLib" mais qui a très mal veilli, illustrant les problèmes que nous avons soulevé pour ce type de framework une fois commercialisé.

La catégorie 3 n'a pas vocation à être commerciliasée.

En catégorie 4, à ma connaissance, il n'existe plus que le mien qui continue d'évoluer constamment (actuellement il est compatible uniquement PB 10.5) et qui a fait l'objet de deux ouvrages dont le dernier est sorti aux Editions ENI en 2004 sous le titre : "PowerBuilder : Technique avancées de développement".

Dernière modification par Dadone (12-03-2007 21:26:35)