Les compagnies font face à d'énormes coûts pour maintenir leurs applications informatiques. Au fil des ans, le code de ces applications a accumulé des connaissances corporatives importantes (règles d'affaires et décisions de conception). Mais, après plusieurs années d'opération et d'évolution de ce code, ces connaissances deviennent difficiles à récupérer. Les développeurs doivent donc consacrer beaucoup de leur temps à l'analyser: une activité connue sous le nom de « compréhension du logiciel ». Comme il a été estimé que cette activité accapare entre 50 % et 90 % du travail d'un développeur, simplifier le processus de compréhension du logiciel peut avoir un impact significatif dans la réduction des coûts de développement et de maintenance. L'une des solutions au problème de compréhension du logiciel est la rétro-ingénierie. Celle-ci est le processus d'analyse du code source d'une application pour (1) identifier les composantes de l'application et les relations entre ces composantes et (2) créer une représentation de haut niveau de l'application. Plusieurs approches ont été proposées pour la rétro-ingénierie ; cependant, la représentation abstraite du code source extraite par la plupart de ces approches combine la logique d'affaires de l'application et son architecture (ou son infrastructure). Dans ce mémoire, nous présentons une nouvelle approche qui permet d'analyser le code source d'une application orientée objet afin d'en extraire un modèle abstrait ne décrivant que les règles d'affaires de cette application. Ce modèle prend la forme d'un diagramme de classes UML, présentant les classes d'affaires de cette application ainsi que les relations entre ces classes. Cette approche a été validée sur plusieurs systèmes (écrits en Java) de différentes tailles. L'approche donne de bons résultats pour les systèmes possédant une bonne architecture et un bon style de programmation. Dans le cas contraire, les résultats sont moins convaincants.

For many years software engineering has primarily focused on the development of new systems and neglected maintenance and reengineering of legacy applications. Maintenance typically represents 70% of the cost during the life cycle of a system. In order to allow an efficient and safe maintenance of a legacy system, we need to reverse engineer it in order to reconstruct its missing or out-of-date documentation. In data-oriented applications the reverse engineering complexity can be broken down by considering that the database can be reverse engineered independently of the procedural components. Database reverse engineering can be defined as the process of recovering the database's schema(s) of an application from database declaration text and program source code that use the data in order to understand their exact structure and meaning. A database reverse engineering methodology is broken down into three processes: project preparation, data structure extraction that recovers the database's logical schema and data structure conceptualization that interprets the logical schema in conceptual terms. In order to validate our methodology and program understanding techniques, we have developed tools to support them. Those tools have proved absolutely necessary to perform database reverse engineering of medium to larger applications in reasonable time and at reasonable cost. To cut down on the cost of large projects, we have stressed the need for automation to reduce the manual work of the analyst. Our experience with real size projects has taught us that the management aspects of a project are essential success factors. The management of a project comprises different aspects such as database reverse engineering explanation, cost evaluation and database reverse engineering result evaluation.

Les antipatrons sont de “mauvaises” solutions à des problèmes récurrents de conception logicielle. Leur apparition est soit due à de mauvais choix lors de la phase de conception soit à des altérations et des changements continus durant l’implantation des programmes. Dans la littérature, il est généralement admis que les antipatrons rendent la compréhension des programmes plus difficile. Cependant, peu d’études empiriques ont été menées pour vérifier l’impact des antipatrons sur la compréhension. Dans le cadre de ce travail de maîtrise, nous avons conçu et mené trois expériences, avec 24 sujets chacune, dans le but de recueillir des données sur la performance des sujets lors de tâches de compréhension et d’évaluer l’impact de l’existence de deux antipatrons, Blob et Spaghetti Code, et de leurs combinaisons sur la compréhension des programmes. Nous avons mesuré les performances des sujets en terme : (1) du TLX (NASA task load index) pour l’éffort ; (2) du temps consacré à l’exécution des tâches ; et, (3) de leurs pourcentages de réponses correctes. Les données recueillies montrent que la présence d’un antipatron ne diminue pas sensiblement la performance des sujets alors que la combinaison de deux antipatrons les entrave de façon significative. Nous concluons que les développeurs peuvent faire face à un seul antipatron, alors que la combinaison de plusieurs antipatrons devrait être évitée, éventuellement par le biais de détection et de réusinage. / Antipatterns are “poor” solutions to recurring design problems which are conjectured in the literature to make object-oriented systems harder to maintain. However, little quantitative evidence exists to support this conjecture. We performed an empirical study to investigate whether the occurrence of antipatterns does indeed affect the understandability of systems by developers during comprehension and maintenance tasks. We designed and conducted three experiments, each with 24 subjects, to collect data on the performance of these subjects on basic tasks related to program comprehension and assess the impact of two antipatterns and their combinations: Blob and Spaghetti Code. We measured the subjects’ performance with: (1) TLX (NASA task load index) for their effort; (2) the time that they spent performing their tasks; and, (3) their percentages of correct answers. The collected data shows that the occurrence of one antipattern does not significantly decrease developers’ performance while the combination of two antipatterns impedes developers significantly. We conclude that developers can cope with one antipattern but that combinations thereof should be avoided possibly through detection and refactorings.

No description available.