Chapitre 4 - Tension de Coût Minimal 53
6.3. Niveaux d’abstraction
La création d’un logiciel passe par trois grandes phases: l’analyse, la conception et l’implémentation (cf. figure 6.2). Le cycle de développement n’est pas séquentiel et il est courant, voire obligatoire, de revenir
Bruno Bachelet CHAPITRE6 - LARÉUTILISABILITÉLOGICIELLE
sur des étapes antérieures. Ces trois phases représentent différents niveaux d’abstraction. Le premier est très abstrait et consiste en une étude avant même la conception du logiciel. La seconde consiste en l’élaboration de la structure du logiciel, a priori indépendamment de l’environnement informatique sur lequel il sera développé. La dernière phase est la création même du logiciel dans un ou plusieurs langages informatiques. Depuis le début de ce chapitre, nous avons parlé principalement de réutilisabilité au niveau de l’implémentation, mais ce concept existe tout naturellement aux autres niveaux. Nous proposons donc d’en discuter ici, en se posant la question de savoir à quel niveau il est le plus judicieux d’exploiter la réutilisabilité.
Analyse 1 réutilise Analyse 2
réutilise
réutilise
Conception 1 Conception 2
Implémentation 2 Implémentation 1
Figure 6.2: Les phases de développement d’un logiciel.
La figure 6.2 explique comment, en dehors de toute méthode favorisant la réutilisabilité, des logiciels d’un même domaine d’application sont élaborés. D’un premier besoin démarre la création du premier logiciel suivant les trois phases (Analyse 1, Conception 1 et Implémentation 1). Lorsque le besoin d’un nouveau logiciel apparaît, comme aucune stratégie particulière de développement n’a été mise en place, les trois phases sont à nouveau lancées (Analyse 2, Conception 2 et Implémentation 2). Ces dernières réutilisent le peu qu’elles peuvent du premier développement. Mais voyons maintenant comment améliorer la part de réutilisation.
6.3.1. Analyse
L’analyse est l’étape préliminaire à la conception de tout logiciel. Elle consiste principalement à analyser un système et à recenser les besoins des futurs utilisateurs. Le système étudié est celui dans lequel le logiciel doit s’insérer. Par exemple, un logiciel de gestion assistée par ordinateur sera intégré dans les systèmes de production et comptable d’une entreprise; pour une base de données ou un modèle de simulation, le système analysé est celui qu’ils devront représenter. Cette étude est appelée l’analyse de système.
réutilise réutilise ex pé rienc e expé rienc e Implémentation 2 Implémentation 1 Conception 1 Conception 2 Analyse de domaine réutilise réutilise
Figure 6.3: Les phases de développement d’un logiciel, avec analyse de domaine.
CHAPITRE6 - LARÉUTILISABILITÉLOGICIELLE Bruno Bachelet
Une approche plus abstraite peut être menée, elle consiste à étudier plusieurs systèmes d’un même domaine, dans l’espoir de fournir une analyse commune et de conduire à un environnement logiciel unique. Cette étude est appelée analyse de domaine. Cependant, il est très difficile de concevoir un seul environnement infor-matique qui réponde aux besoins de tous les systèmes. En revanche, il est possible d’identifier des éléments communs qui permettront de mener des analyses communes (cf. [Leac97], [Cohe98]). Ces résultats pourront alors être réutilisées lors de l’analyse d’un système précis du domaine (cf. figure 6.3). Comme le précise [Camp00], l’analyse de domaine peut s’effectuer progressivement en concevant des logiciels pour plusieurs systèmes d’un même domaine. Un retour d’expérience permet alors d’étoffer l’analyse du domaine.
6.3.2. Conception
La conception est l’étape où la structure du logiciel est élaborée. A ce niveau l’étude est menée indépendam-ment du ou des langages de programmation qui seront employés pour le logiciel. Cependant, il faut tout de même décider d’une approche de modélisation, e.g. faut-il employer le paradigme objet, un modèle entité-association... A ce niveau tout le logiciel est élaboré, dans un ou plusieurs formalismes.
réutilise ex pé rienc e expé rienc e réutilise réutilise Conception 2 Conception 1 Implémentation 2 Implémentation 1 Analyse de domaine Patrons de conception
Figure 6.4: Les phases de développement d’un logiciel, avec patrons de conception.
Lors de ces phases de conception, certains problèmes de modélisation sont récurrents. Des solutions génériques peuvent alors être apportées. Afin d’en permettre une réutilisation, la notion de patron de conception (design
pattern) a été introduite (cf. [Schm96]). Un patron de conception est un élément réutilisable de conception
qui est indépendant du domaine d’application (et bien entendu de tout langage de programmation). Il propose une solution générique à un type précis de problème. Il s’agit donc d’un outil qui permet de mémoriser et de formaliser l’expérience d’experts. Bien qu’il soit indépendant du langage de programmation, un patron de conception n’en est pas moins dépendant de l’approche choisie pour la modélisation. Par exemple, les patrons désormais célèbres fournis dans [Gamm95] proposent des solutions de conception pour l’approche orientée objet. Comme dans la phase d’analyse, un retour d’expérience des différentes conceptions permet d’alimenter les collections de patrons (cf. figure 6.4).
6.3.3. Implémentation
La phase d’implémentation est l’étape qui consiste à programmer proprement dit le logiciel. Notre discussion sur la réutilisabilité a porté principalement sur ce niveau d’abstraction jusqu’à cette dernière section. La
Bruno Bachelet CHAPITRE6 - LARÉUTILISABILITÉLOGICIELLE
ure 6.5 résume l’intérêt d’une bibliothèque de composants dans la phase d’implémentation du logiciel. Comme pour les deux phases précédentes, le retour d’expérience de chaque implémentation permet de fournir la biblio-thèque logicielle en nouveaux composants.
Au travers des derniers paragraphes on pourrait penser que plus la réutilisabilité est abstraite, plus sa portée est grande puisqu’elle est indépendante de l’approche et du langage de programmation. Par conséquent, la réutilisabilité logicielle (i.e. au niveau implémentation) n’aurait que peu d’intérêt.
réutilise ex pé rienc e expé rienc e réutilise réutilise Conception 2 Conception 1 Implémentation 2 Implémentation 1 Analyse de domaine Patrons de conception Conception bibliothèque expé rienc e Bibliothèque logicielle ex pé rienc e réutilise
Figure 6.5: Les phases de développement d’un logiciel, avec bibliothèque logicielle.
Cependant, comme l’explique [Stro96], la réutilisabilité ne peut pas être totalement indépendante du langage de programmation, il y a trop de différences dans les concepts de chacun pour concevoir un bon composant réutilisable à un niveau trop abstrait. A vouloir exprimer quelque chose avec les seules notions communes à plusieurs langages, on en perd une puissance d’expression. L’idéal, c’est de combiner la réutilisabilité aux différentes phases d’élaboration du logiciel, c’est ce que l’on appelle un cadriciel.
6.3.4. Cadriciel
Plusieurs définitions du terme cadriciel (framework) peuvent être énoncées (e.g. [John88], [Matt96]). Nous retenons celle de [Camp00] qui s’intègre le mieux à notre discussion: un cadriciel est une collection d’éléments de conception (e.g. les patrons de conception) et d’implémentation (e.g. les composants logiciels) en coopéra-tion et réutilisables qui permettent de créer des applicacoopéra-tions ou des parties d’applicacoopéra-tions dans un domaine spécifique.
L’idée est de fournir, à partir d’une analyse de domaine, des éléments réutilisables, aussi bien au niveau de la conception que de l’implémentation (cf. figure 6.6). Associés à une assistance informatisée, cela permet à un expert d’un domaine de concevoir un logiciel pour ses besoins sans connaître tous les concepts liés au génie logiciel et en particulier à l’approche orientée objet si elle a été retenue pour la conception. La liste des cadriciels célèbres à l’heure actuelle est longue. Nous n’en citerons que deux types représentatifs: les interfaces graphiques, qui proposent au niveau conceptuel les fenêtres, les boutons... et qui offrent aussi les composants
CHAPITRE6 - LARÉUTILISABILITÉLOGICIELLE Bruno Bachelet
logiciels pour les implémenter; les gestionnaires de bases de données (e.g. Microsoft Access), ils permettent de manipuler à un niveau d’abstraction élevé des bases de données, et fournissent les composants logiciels associés. Cadriciel réutilise expé rienc e ex pé rienc e Implémentation 2 Implémentation 1 Analyse de domaine Bibliothèque logicielle
Patrons de conception réutilise
ex p ér ie n ce
Figure 6.6: Les phases de développement d’un logiciel, avec cadriciel.
6.3.5. Conclusion
Cette discussion a porté sur l’élaboration de logiciels au sens large. Quand est-il de la recherche opérationnelle et de notre objectif de créer une bibliothèque de composants réutilisables ? En recherche opérationnelle, le processus de développement d’un logiciel est très similaire à celui d’un logiciel au sens classique du génie logiciel. La différence réside dans l’analyse de domaine où les méthodes employées sont radicalement dif-férentes. Pour la recherche opérationnelle, la modélisation des systèmes même est très synthétique, la majeure partie de l’analyse consiste alors à élaborer des méthodes de résolution pour la problématique étudiée. En génie logiciel de manière générale, ou en simulation, la plus importante partie du travail consiste à modéliser les sys-tèmes pour lesquels on aboutit souvent à de larges modèles, comparés à ceux que l’on rencontre en recherche opérationnelle. La résolution des problèmes modélisés est alors plus secondaire et peut concerner d’autres disciplines.
La phase de conception est en revanche très similaire, il s’agit de traduire en termes plus informatiques les résultats de l’analyse de domaine pour établir une structure encore abstraite du logiciel. Cela signifie concevoir logiciellement les structures de données et les algorithmes nécessaires aux méthodes de résolution pour la recherche opérationnelle, et modéliser avec des concepts informatiques les modèles des systèmes pour le génie logiciel ou la simulation. En résumé, la recherche opérationnelle travaille plutôt sur les algorithmes alors que le génie logiciel et la simulation se concentrent sur les données et leurs interactions, même si, en fonction des domaines d’application, les deux approches sont plus ou moins mélangées.
Il est intéressant de noter qu’au niveau de l’analyse de domaine, la recherche opérationnelle est très performante en termes de réutilisabilité. Il existe énormément d’articles qui proposent des méthodes pour résoudre un grand nombre de problèmes. En revanche, en génie logiciel ou en simulation, les articles et les études apportent plutôt des réponses générales sur la manière de modéliser un système, mais semble-t-il un peu moins sur une manière de modéliser les systèmes d’un domaine particulier. A l’inverse au niveau de la conception et
Bruno Bachelet CHAPITRE6 - LARÉUTILISABILITÉLOGICIELLE
de l’implémentation, il est beaucoup plus rare de trouver soit des patrons de conception, soit des composants logiciels pour des problèmes de recherche opérationnelle, alors qu’ils prolifèrent pour le génie logiciel ou même la simulation.
Notre objectif dans ce document sera de présenter quelques patrons de conception et de discuter des problèmes liés à l’implémentation. En aucun cas nous présentons un cadriciel complet pour les problèmes d’optimisation dans les graphes. Néanmoins notre objectif à plus long terme est justement de le fournir et de concevoir l’assistance informatique associée pour disposer d’un environnement de développement d’outils de recherche opérationnelle relativement complet, et suffisamment simple d’utilisation par rapport à tous les concepts de génie logiciel et en particulier l’approche orientée objet (présentée au chapitre suivant).