Évolution des paradigmes de développement des systèmes d’information

Dès l‟apparition des premiers ordinateurs, les instructions d‟un programme devaient être écrites en langage machine (langage binaire) ou assembleur afin d‟être exécutées par un ordinateur. Cette tâche était très fastidieuse car en plus de la description algorithmique d‟un problème donné, le programmeur devrait avoir des connaissances minutieuses de la structure matérielle de l‟ordinateur afin de pouvoir l‟implémenter. Ceci a tout de suite fait naître un besoin de créer des langages intermédiaires, facilement compréhensibles et manipulables par les programmeurs. Ainsi, les programmes pourront être écrits dans ces langages et ensuite traduits ou compilés en langage machine pour exécution. De nos jours, dans le contexte du Génie logiciel, les techniques et les langages utilisés dans le processus de développement logiciel ont considérablement évolués. Cette évolution est dictée par le besoin de concevoir et de maintenir des logiciels toujours plus complexes. De nombreux langages ou paradigmes de développement se sont succédé dans le but de s‟abstraire de plus en plus de la structure matérielle de bas niveau afin de faciliter le développement logiciel. On peut dire qu‟ils nous ont affranchi des processeurs et même des systèmes d‟exploitation. Chaque paradigme introduit des concepts, identifie une classe de problèmes et fournit des techniques permettant de les traiter. Nous résumons ci-dessous quelques uns des plus représentatifs.

3.2.1 Le paradigme procédural

Avant les années 80, on a assisté au paradigme procédural dont l‟objectif était la séparation entre la représentation des données et leurs traitements. Ainsi, le concept de structure de

données a été introduit pour représenter les données et les concepts de procédures et fonctions

pour designer le traitement associé aux données. Ces concepts ont ensuite été implantés dans différents langages de programmation comme Pascal, Fortran, C, etc. Ce paradigme a très vite connu ses limites face aux applications de grande taille. En effet, l‟interopérabilité entre les procédures/fonctions se fait par les variables globales qui sont accessibles par différentes procédures/fonctions. Ceci a engendré des effets de bord : si on oublie de mettre à jour certaines données partagées, si l‟ordre chronologique des assignations par les différentes parties du logiciel est incorrect, ou si une zone de mémoire a été désallouée au mauvais moment, le programme se retrouve dans un état imprévu. Lors de la maintenance, la modification d‟une procédure/fonction peut avoir des conséquences inattendues sur le résultat

61

d‟autres procédures/fonctions liées par des variables globales. Ainsi, la maintenance des systèmes développés avec le paradigme procédural est difficile et coûteuse et la réutilisation du code se trouve souvent compromise. La nécessité d‟avoir un paradigme un peu plus modulaire a donc donné place au paradigme orienté objet.

3.2.2 Le paradigme orienté objet

Vers les années 1980, le paradigme orienté objet a vu le jour pour pallier aux limites du paradigme procédural en introduisant le concept de classe et d’objet. Ce paradigme offre une meilleure protection des données car elles sont encapsulées dans un objet ainsi que leurs traitements. Ceci favorise également une meilleure réutilisation et extension grâce aux mécanismes d‟héritage et de polymorphisme. Le paradigme orienté objet est implanté dans les langages comme C++, Java, etc. La modularité apportée par ce paradigme a nécessité également la conception de nouvelles méthodes de modélisation qui a conduit vers la définition et la standardisation d‟un langage de modélisation objet unifié appelé UML. Cependant, malgré son essor, le paradigme orienté objet n‟a pas réussi à surmonter toutes les difficultés liées au développement des applications distribuées et reparties compte tenu de sa faible granularité qui pose un problème de réutilisation des objets ou des classes. On va donc assister à une extension du paradigme orienté objet d‟un point de vue architecture logicielle qui va conduire à un paradigme orienté composant.

3.2.3 Le paradigme orienté composant

Vers les années 1990 apparaît le paradigme orienté composant qui offre une granularité et un niveau d‟abstraction élevé changeant ainsi la manière de développer les applications. Les applications sont désormais construites par assemblage de composants distribués et réutilisables, un composant étant une entité logicielle fait pour la composition (Barbier, 2005). L‟objectif est d‟industrialiser la réalisation des systèmes informatiques comme c‟est le cas dans d‟autres secteurs tel que l‟automobile, le bâtiment, etc. Ainsi, l‟approche orientée composant va présenter une vision plus macroscopique que l'approche objet par l‟utilisation des intergiciels (middleware) comme EJB (Enterprise JavaBeans), CORBA (Common Object

Request Broker Architecture), etc. Ces intergiciels définissent des abstractions pour les

développeurs des applications réparties qui masquent les aspects d‟implantation tels que le nommage, les transactions, la localisation, la sécurité et les communications sur réseaux hétérogènes. On assiste ainsi à une meilleure séparation des préoccupations. La conception

62

propose désormais de décomposer les applications en des aspects fonctionnels, traitant la logique métier de l‟application et en des aspects non fonctionnels, traitant les détails techniques d‟implémentation, délégués aux intergiciels. Cette séparation permet de réduire la complexité de conception, de réalisation et de maintenance des logiciels et d‟en améliorer la compréhension, la réutilisation et l‟évolution. Cependant, il existe une prolifération des intergiciels offrant divers services et sans cesse en évolution pour supporter de nouveaux services plus sophistiqués. Les entreprises sont ainsi tributaires des plateformes d‟exécutions qui sont sans cesse en évolution. En plus, l‟intégration de nouvelles fonctionnalités les oblige souvent de faire migrer leurs systèmes sur de nouvelles plateformes d‟intergiciels et ceci à des coûts rédhibitoires. Une application étant dépendante de l‟intergiciel sur lequel elle est bâtie, l‟hétérogénéité inéluctable entre les différents intergiciels et le manque de standardisation rendent l‟interopérabilité entre applications utilisant des intergiciels différents très complexe. Afin de surmonter ce problème, il faut penser un nouveau paradigme basé sur une modélisation de haut niveau, centré sur la logique métier et indépendante des choix technologiques. Ce qui permet de garantir une pérennité des modèles conceptuels métier et la conception des applications portables tant au niveau des langages de programmation que des systèmes d‟exploitation et aussi des intergiciels. Les entreprises peuvent ainsi gagner en productivité et en compétitivité, capitaliser les efforts consentis à tous les niveaux et tirer profit des avantages qu‟offre la diversité des plates-formes. La continuité nous conduit vers l‟IDM que nous avons mentionné plus haut dont l‟intérêt a été fortement amplifié, lorsque l'OMG a rendu publique son initiative MDA qui vise à la définition d'un cadre normatif pour l'IDM.