Si le langage naturel est créatif, suggestif, associé au cognitif, le langage informatique se conforme impérativement à des règles syntaxiques. Telle est sa « logique ». Quant à la « sémantique » qui désigne en linguistique le sens d’un texte pour le distinguer de sa forme, en informatique, elle est d’abord « formelle » et désigne l’interprétation d’un langage sous forme de règles et de structure mathématiques (typage des données). On ne programmera pas un ordinateur de façon à le doter de la compréhension du « sens » du langage, sans lui fournir une représentation de domaines de connaissances, i.e des « ontologies », significatives et extensibles.
Quelle que soit l’opération de modernisation que l’on souhaite effectuer sur un code existant, il existe une première étape incontournable pour prendre connaissance du code et le stocker dans une forme exploitable pour l’analyse et la transformation automatique : le parsing de code.
En ingénierie logicielle, le parsing est défini comme le processus d’analyse du code source d’un programme de façon à déterminer sa structure grammaticale. Un parser est dès lors un outil logiciel dont l’objectif consiste à traduire dans une forme intermédiaire un langage de programmation, à l’aide d’une description de la grammaire du langage. Inventés à l’origine à l’usage des compilateurs et des interpréteurs des langages de programmation, le champ d’application des parsers s’est vite
étendu aux outils de modernisation de code, dont ils sont une brique essentielle.
Si tous les parsers partagent le même principe d’analyse, il n’en reste pas moins des différences non négligeables entre eux. En effet, pour traiter des volumes imposants (MLOC) et des systèmes complexes, un parser « industriel » est indispensable. Il aura des exigences beaucoup plus fortes que des outils de restitution de graphe d’appels ou de simples compilateurs, qui restituent un fichier au lieu d’une base de données, notamment quant au niveau (la granularité et la complétude) des informations collectées.
Un parser « industriel », vise par définition des opérations industrielles de ré-ingéniérie. Pour être apte à les satisfaire, il doit fournir une représentation abstraite du code qui respecte des principes d’acuité, de stockage de larges volumes dans une base de connaissance interrogeable, de complétude et de granularité des composants collectés, afin d’une part d’autoriser la recherche précise de patrons (« pattern ») et l’identification d’objets, d’autre part, la transformation du code.
Cela n’est pas suffisant, encore faut-il qu’il soit « extensible », c'est-à-dire qu’il ait la capacité de traiter les dialectes de langages inhérents à la grande variété d'environnements existants. Ainsi l’accent en modernisation doit être mis sur les outils à échelle industrielle. Ils se définissent à la fois par un référentiel de gros volumes de code doté d’un système de gestion, afin de pouvoir interroger l’existant avec un langage de règles d’analyse et de condition non satisfaite en ré-ingéniérie »
[] the condition that the grammar of the language is known in advance is not satisfied in the field of reengineering In Current Parsing Techniques in Software Renovation Considered Harmful (.ps), by Mark van den Brand, Alex Sellink, Chris Verhoef.
Il y a des milliers de langages existants, si on prend en compte en plus de la variété des langages, les extensions, les dialectes, les versions, etc. Pour exemple, il n'y a aucune application de COBOL en production qui utilise purement des programmes COBOL de norme ANSI. Comprendre une application en production « COBOL » sous MVS exige de comprendre le COBOL (sous ses nombreuses formes incluant OS/VS COBOL, VS COBOL II, MVS COBOL, etc.) mais aussi le JCL, le CICS, l’embedded SQL, l'IDMS, et les références aux programmes dans d'autres langues telles que l'assembleur, le PL/I, le RPG. C’est là où des technologies de génération de parser, telles que Yacc ou Bison, atteignent leurs limites, car elles partent d’une description de la grammaire du langage, considérée connue et délimitée, et non soumise à de continuels changements.
Afin de s’adapter aux exigences spécifiques des applications en production, la modernisation requiert des outils de parsing incluant des « générateurs de parser » qui puissent étendre continuellement, par apprentissage, la connaissance des grammaires.
Le domaine de la réingéniérie logiciel est extrêmement porteur pour optimiser les projets de modernisation d’une application patrimoniale issue d’un développement spécifique, grâce à des possibilités d’automatisation de transformation vers une cible à partir de l’analyse de l’implémentation de la source existante.
En particulier, les techniques de réingéniérie logicielle permettent :
La migration d'un système d’information vers un nouvel environnement technologique :
• Migration de plate-forme
• Migration de base de données
• Migration de langages
La ré-architecture d’un code existant pour une meilleure maintenabilité et évolutivité, donc améliorer son « degré d’utilisabilité » et son « degré d’évolution »,
La redocumentation et le contrôle qualité à partir de mesures factuelles issues de l’implémentation grâce à des outils de compréhension du code (inventaire, mesure des métriques qualités, navigateurs de code, références croisées et relations entre composants, etc) et le contrôle qualité des codes sources pour réduire les risques d’erreurs en amont du passage en exploitation.
La rétro-modélisation des applications existantes pour créer, par exemple, des modèles de conception UML, qui pourront ensuite servir de cadre à une génération de code vers la cible retenue.
La réingénierie logicielle autorise d’automatiser une bonne partie des opérations évoquées ci-dessus. En particulier, les migrations peuvent atteindre un taux élevé d’automatisation quand la source et la cible retenue partagent le même paradigme architectural (pour exemple conversion d’un langage procédural à un autre).
Dès lors que la cible est à un niveau d’abstraction plus élevé que la source, ou que la transformation implique une connaissance métier pour valider, par exemple, le périmètre d’une règle de gestion, ou l’association d’une donnée métier à une variable, l’automatisation s’avère plus complexe et a ses limites (ex : en cas
de changement de paradigme, type Procédural vers objet, Cobol vers Java, NSDK vers J2EE, …).