I.4 Programmation globale
I.4.2 Terminologie : Programmation détaillée, globale et coopérative
Les trois termes programmation détaillée, programmation globale et programmation coopérative sont tout d’abord présentés. La notion de programmation globale est ensuite affinée et l’on introduit l’architecture, la manufacture, la variation et l’évolution.
I.4.2.1 “Programmation détaillée”
Laprogrammation détaillée regroupe les activités se focalisant sur chaque composant du logiciel pris individuellement. Deux notions sont essentielles : les algorithmes et les structures de données.
La programmation détaillée considère le logiciel à un niveau de granularité fin. Les différentes entités considérées sont les variables, les types, les opérateurs arithmétiques, les instructions, etc. Typiquement les compilateurs et les éditeurs syntaxiques sont des outils de programmation détaillée. En fait, les langages de programmation sont à la base de cette discipline.
I.4.2.2 “Programmation globale”
La signification du terme “Programmation globale” a évolué au cours du temps [Tich92]. Tout d’abord nous présentons son origine, ensuite son évolution et enfin notre définition.
L’origine du terme...
Le volume et la complexité des logiciels sont des facteurs importants qui influent sur la manière de les développer et de les maintenir, non seulement d’un point de vue quantitatif mais également d’un point de vue qualitatif[Shaw86]. Le développement de logiciels de grandes tailles, implique bien sûr des activités de programmation détaillée, mais aussi des activités de natures différentes. Cette constatation est à la base de la distinction entre programmation globale et programmation détaillée, idée introduite en 1976 par DeRemer et Kron dans l’article “Programming-in-the-large vs. Programming-in-the-small”[DereKron76]. L’objectif de DeRemer et de Kron était de montrer que les langages de programmation n’étaient pas aptes à résoudre seuls les problèmes posés par le développement de logiciels de grandes tailles. Ils définirent un Langage de Connexions de Modules(unM.I.L.1) ayant pour but de décrire les interactions entre les composantes du logiciel à un niveau global. La comparaison de ce langage aux langages de programmation explique la présence du mot “programmation” dans le terme programmation globale.
L’évolution du terme...
Par la suite, il est apparu beaucoup plus clairement que la programmation ne représentait qu’une partie des activités en génie logiciel. Le concept de programmation globale, initialement représenté par l’utilisation de M.I.L, s’est progressivement élargi à d’autres activités du cycle de vie. Quoique devenu contestable, le terme programmation globale est néanmoins resté2.
1. “Module Interconnection Language” en anglais. L’acronyme M.I.L. étant largement utilisé, c’est celui-ci que nous utiliserons dans la suite de ce document.
2. Pour contourner ce problème de terminologie le terme “Developement-in-the-large” a été utilisé[LiRama85]. Néanmoins cet usage ne s’est pas répandu. D’ailleurs il est trop restrictif car il exclut la maintenance.
En fait, bien qu’introduit en 1976, ce terme a surtout été en vogue vers le milieu des années 80, période pendant laquelle il a été utilisé par de nombreux auteurs, par exemple[Wegn84] [Mull86] [RamaGP86] [Shaw86] [WattWF87] [Belk88]1.
Ce terme n’en est pas moins flou. En réalité il n’existe pas de consensus sur ce qu’il recouvre exactement. Bien souvent il est uniquement défini par opposition à la programmation détaillée et est donc susceptible de designer de nombreuses notions. Par exemple dans l’article “Programming-in-the-large” [RamaGP86] cette désignation inclue des concepts allant de la réutilisation jusqu’à la mesure, en passant par des systèmes de bases de connaissances. Selon
[Tich92] ce terme recouvre principalement (1) la gestion de configurations, (2) la réutilisation et (3) la modélisation de processus.
Notre définition...
Dans le cadre de cette thèse nous donnons une définition plus restrictive et plus précise. Cette définition sera utilisée tout au long de ce document.
Laprogrammation globale regroupe les activités se focalisant sur les produits logiciels de grande taille en considérant leur architecture, leur manufacture, leur évolution et/ ouvariation.
Les quatre termes “Architecture”, “Manufacture”, “Evolution” et “Variation” permettent de raffiner le domaine de la programmation globale.
• Architecture (oustructuration2). Ici les entités de bases sont les modules, les interfaces, les sous-systèmes, etc. En ce qui concerne les relations d’intérêt citons par exemple la relation de dépendance entre modules ou encore la relation de composition entre systèmes et sous systèmes3.
• Manufacture (ou dérivation4). L’une des caractéristiques du logiciel est qu’il se compose d’objets dont le traitement peut être automatisé. Par exemple le texte source des programmes
1. Dans[CurtKSI87] on trouve même le terme “Programming-in-the-gargantuan”. En 1985 un workshop international s’intitulait “Software Engineering Environment for Programming-in-the-large”[Chea85]. Notons aussi en 1986, la décomposition des actes du workshop[ConrDW86] en deux parties : “Programming-in-the-small” et “Programming-in-the-large”.
2. Le terme “structuration” étant employé à de nombreuses occasions, comme certains auteurs, nous préférerons le terme “architecture”.
3. Depuis quelques années le terme “architecture” est employé dans un contexte plus large que celui utilisé ici. Il intègre désormais les problèmes de communication entre outils et est souvent associé au problème d’intégration (on parle par exemple d’architecture dans le cadre des environnements de génie logiciel). Cette vision n’est pas contradictoire avec la vision plus ancienne (celle utilisée dans cette thèse). La différence réside dans le fait que les communications entre composants étaient essentiellement réalisées par des appels de procédures et des échanges de structure de données alors qu’aujourd’hui il s’agit de techniques réseaux plus diversifiées et complexes. Dans le cadre de la maintenance et de la ré-ingénierie il est suffisant de considérer la définition la plus restrictive.
figure 16 Programmation globale = Architecture∪ Manufacture∪Evolution∪Variation
Architecture Manufacture
Evolution Variation
peut être automatiquement transformé, ou dérivé, en un code objet à l’aide d’un compilateur. On est alors amené à distinguer les objets sources des objets dérivés. La production des premiers nécessite une intervention humaine alors que les seconds peuvent être dérivés automatiquement à partir d’autres objets via l’application d’outils de dérivation. Pour un logiciel, on appellemanufacture la génération des objets dérivés à partir des objets sources. • Evolution. L’évolution des logiciels est un phénomène incontournable et intrinsèquement lié
au temps. Dans le cadre de la programmation globale seuls les résultats de l’évolution sur le produit logiciel sont considérés, pas le processus d’évolution. En fait, l’évolution des logiciels est à la fois un problème de programmation globale et de programmation coopérative (voir la section suivante). Les versions, ou plus exactement les révisions successives, sont des exemples d’entités.
• Variation. Dans cette thèse nous faisons une distinction entre les problèmes d’évolution et les problèmes de variations. Dans le dernier cas on pourrait également parler de problèmes d’adaptation. Pour un logiciel donné, il s’agit de répondre aux variations en termes de besoins des utilisateurs et des plates-formes. Quand une version unique et générale du logiciel n’est pas suffisante, et c’est souvent le cas, il est nécessaire de décrire et de maintenir plusieurs variantes1. Trop souvent ce problème est assimilé aux problèmes d’évolution. Pourtant conceptuellement il s’agit d’une autre dimension où le temps n’intervient pas. Par exemple dès la conception initiale du logiciel il peut être utile de proposer différentes variantes de celui-ci2.
Discussion
Selon notre définition, la programmation globale se focalise sur le produit logiciel et ne prend pas en compte le processus logiciel. Ceci signifie par exemple que les problèmes de coordination et de coopération entre différents développeurs ne sont pas considérés.
Cette définition fait également ressortir le fait que l’on s’intéresse aux produits logiciels de grande taille. Dans ces conditions l’architecture, l’évolution, la variation et la manufacture sont des éléments essentiels et il est indispensable de les contrôler.
Granularité forte et granularité fine...
Il est souvent considéré que la distinction entre programmation globale et programmation détaillée implique un saut de granularité. Alors que la programmation détaillée considère des entités de faible grain (par exemple des variables et des instructions), la programmation globale fait abstraction de nombreux “détails” et considèrent des grains plus forts (des modules, des interfaces, etc.). C’est d’ailleurs cette idée qui a été mise en avant dans la traduction française puisque “globale” est opposée à “détaillée”3.
4. Dans le domaine de la conception assistée par ordinateur et parfois même en génie logiciel, on dit qu’une version est dérivée d’une autre si celle-ci a été obtenue (manuellement) à partir d’une copie de cette dernière. Ici la dérivation est supposée être automatique et n’est pas liée à la notion de version. On préférera donc le terme manufacture, car plus spécifique et donnant lieu à moins de confusion.
1. Les termes “versions”, “variantes”, “variation” sont définis plus loin (cfChapitre II).
2. Même si l’évolution et la variation sont des concepts différents, les techniques proposées sont souvent proches ou même identiques. Par exemple les techniques de versionnement sont généralement communes. Ceci explique l’amalgame souvent fait entre évolution et variation.
I.4.2.3 “Programmation coopérative”
Avec la définition de Tichy, la programmation globale inclut les aspects processus logiciels
[Tich92]. Au contraire dans cette thèse ces aspects sont regroupés sous le terme “Programmation coopérative”.
L’évolution du terme...
C’est dans le début des années 80 que ce raffinement a été introduit dans le projet Gandalf sous le terme “Programming-in-the-many”1. Au cours de cette décennie peu d’auteurs ont repris cette distinction [Mull86]. Par contre au cours des dernières années la croissance de la gestion de processus a provoqué un regain d’intérêt pour celle-ci[Melo93] [Ahme94].
Une définition...
Deux décennies après l’introduction du terme “programmation globale” il n’existe pas de consensus sur ce qu’il recouvre. Le terme “programmation coopérative” est encore plus récent et il n’est donc pas étonnant que les limites du domaine qu’il désigne ne soient pas claires. Auparavant la programmation globale était utilisée pour désigner tout ce qui n’était pas du ressort de la programmation détaillée. Maintenant cette même logique s’applique à la programmation coopérative. Ce terme est introduit dans cette thèse uniquement pour situer la programmation globale et la programmation détaillée dans un contexte général. La définition suivante, même si elle n’indique pas de bornes précises, est néanmoins suffisante :
La programmation coopérative est l’ensemble des activités liées à la multiplicité des agents impliqués dans un projet logiciel[Melo93].
Clairement la présence de différents agents coopérant pour produire un logiciel de grande taille introduit de nouvelles notions. Par exemple la notion de rôle est importante, tout comme la notion d’espace de travail. Le contrôle des activités est également essentiel.
Remarquons aussi que la différence entre la programmation coopérative et la programmation globale n’est pas toujours très nette. Rappelons simplement que la programmation globale se focalise sur le produit logiciel alors que la programmation coopérative prend en compte les aspects processus.
3. Cette idée est également reprise dans différents domaines et les suffixes “-in-the-large” et “-in-the-small” ont été utilisés à d’autres occasions. On trouve par exemple la distinction entre “Reuse-in-the-large” et “Reuse-in-the-small” [Luba86], [Mull86], “Documenting-in-the-small” et “Documenting-in-the-large”[Till93]. Nous avons introduit aussi la distinction entre “Reengineering-in-the-large” et “Reengineering-in-the-small”[Favr94a] que nous traduisons par ingénierie détaillée et ré-ingénierie globale.
1. “Gandalf system development environments are characterized by (1) System version control support that aids in describing and manipulating the interfaces, composition, and dependencies of modules, subsystems, and systems. Such support is related to the notion of Programming-in-the-large. (2) Project management support that helps control the development process so that programmers make changes in an orderly fashion. Since this is essential to the cooperation, communication, and coordination of programmers in a project, we have christened this Programming-in-the-many”[HabeNotk86].
Lafigure 17 présente, dans une vision simplifiée, quelques caractéristiques de chaque domaine.