EXERCICE NO

Cours IFT 3051 Projet d'informatique
Identification de micro-architectures similaires aux motifs de design présenté à MM. Yann-Gaël Guéhéneuc & Houari Sahraoui Département d'informatique et de recherche opérationnelle Laboratoire de Génie Logiciel [pic] par Duc-Loc Huynh Janice Ka-Yee Ng UNIVERSITÉ DE MONTRÉAL Lundi 20 septembre 2004 TABLE DES MATIÈRES CONTEXTE 4
OBJECTIFS 4
ENVIRONNEMENT DE TRAVAIL 6
MÉTHODOLOGIE 7 . Background 7
. Méthodologie no 1 - Début du projet 8
Description 8
Programmes analysés 8
Commentaire 9
. Méthodologie no 2 -Milieu du projet 12
Description 12
Programmes analysés 12
Commentaire 12
. Méthodologie no 3 - Phase finale du projet 15
Description 15
Programme analysé 15
Commentaire 15 RÉSULTATS 17
ÉVOLUTION ET COMMENTAIRE PERSONNELLE 18 Janice Ka-Yee Ng 18
Duc-Loc Huynh 20 ANNEXES 22
BIBLIOGRAPHIE 27
CONTEXTE Les langages de programmation ont constamment évolué depuis qu'ils
existent. De nos jours, on distingue différents styles de programmation,
allant de impératif (Perl), fonctionnel, orienté-objet (Eiffel, C++, Java,
...) , logique, à concurrent. Les langages de programmation orientés-objet
connaît un essor grandissant depuis les années 80. De plus en plus, les
concepteurs bâtissent des programmes complexes où un grand nombre de
composants interagissent entre eux en suivant la tendance POO. Dans cette suite d'idées, peut-on réutiliser un ensemble de classes
collaborantes pour accélérer le processus de développement de logiciels,
pour faciliter la maintenance de programmes complexes, pour promouvoir un
bon style de programmation, bref, pour augmenter la qualité d'un programme?
C'est ainsi que, dans le but de formuler des solutions générales pour des
problèmes qui surviennent de manière récurrente dans la conception des
logiciels, la notion de design pattern est naît. Une préoccupation de ce
concept réside en la conception de logiciels orientés-objet réutilisables.
Les design patterns encouragent la réutilisation de solutions proposées
pour des problèmes rencontrés auparavant par des développeurs ! Christopher Alexander, docteur gradué en architecture, auteur du livre « A
Pattern Language », a vu les méthodes et techniques décrites pour être
appliquées initialement dans le monde de la construction, migrées vers le
domaine de l'informatique par rapport à la programmation orientée-objet.
Dans le but idéaliste de permettre à tous les citoyens de construire sa
propre maison, il a proposé une définition au mot « pattern » de la manière
suivante : « Each pattern describes a problem which occurs over and over again in
our environment, and then describes the core of the solution to that
problem, in such way that you can use this solution a million times
over, without ever doing it the same way twice. [...] Each pattern is
a three part rule, which express a relation between a context, a
problem, and a solution. » Christopher Alexander, [Alexander, 1977] Par la suite, cette notion de patrons de conception a été poussé pour être
appliquée explicitement dans le domaine de l'informatique. En
l'occurrence, Gamma et al ont proposé une collection de patrons de
conception à laquelle nous nous référons dorénavant dans le projet. Mais dans quelle mesure peut-on affirmer que l'utilisation de patrons de
conception a permis effectivement d'améliorer la qualité d'un programme ?
Le calcul de métriques directes telles que la complexité cyclomatique sur
les programmes, et l'utilisation de modèles prédictifs de qualité
permettant d'interpréter les résultats des métriques directes, nous
permettront de mesurer indirectement la qualité des programmes.
OBJECTIFS Le travail dont il est question dans ce projet consiste à retracer des
patrons de conception que les auteurs de programmes auraient appliqués,
consciemment ou inconsciemment, durant la conception du logiciel. Le choix
des programmes à analyser se restreint évidemment à des logiciels écrits
avec un langage orienté-objet, plus précisément en Java, puisque nous
voulons déterminer l'impact des patrons de conception sur les programmes à
objets. Quant aux patrons de conception à identifier, nous nous référons
aux vingt-trois (23) motifs que nous ont proposés Gamma et al [i]. Bien
entendu, il existe dans la littérature de patterns une multitude d'autres
patrons présentés par d'autres auteurs, mais étant donné un compromis
nécessaire entre le degré de difficulté du travail à réaliser et le temps
alloué pour le projet, il est amplement suffisant d'examiner seulement la
vocabulaire de Gamma et al. Nous compilons l'ensemble de résultats dans un fichier XML. Chaque motif
identifié est présenté sous forme d'une micro-architecture, qui possède une
nomenclature définie par le responsable de projet au début du travail.
Voici une illustration d'une micro- architecture similaire à l'application
du design pattern « Abstract Factory » :


com.taursys.html.test.HTMLComponentFactory
Test


com.taursys.xml.ComponentFactory<
/abstractFactory>


com.taursys.html.HTMLComponentFactory


com.taursys.xml.Component


com.taursys.xml.DispatchingContainer
com.taursys.xml.DocumentElement
[...]



ComponentFactory may be extended as specialized XML documents are
needed. Therefore, it is possible
to create our own extension of CompenentFactory as to generate
Components for specialized XML document,
just like " HTMLComponentFactory is used to automate the creation of
Components based on the HTML Document
and its Elements. "

Figure 1. Représentation d'une micro-architecture identifiée dans le
programme
MapperXML similaire au patron Abstract Factory.
Outre que de fournir des données aux futurs étudiants qui étendront ce
sujet vers un niveau plus haut dans l'analyse de l'impact des patrons de
conception sur les programmes à objets par le calcul de métriques directes
sur les programmes analysés, l'intérêt principal de notre travail est de
pouvoir proposer une méthodologie d'identification de patron de conception
dans un programme donné. Ainsi donc, nous avons développé diverses
techniques durant notre chasse aux patrons, l'une plus fiable que l'autre,
que nous allons tenter d'exposer dans les quelques pages qui suivent. Nous
essayons de proposer une méthodologie pouvant contribuer, d'une manière ou
d'une autre, à automatiser l'identification de patrons de conception dans
les logiciels. En résumé, voici les objectifs qui entourent ce projet : - - Proposer des recettes afin d'identifier les patrons de conception;
- Analyser l'impact des patrons de conception appliqués sur les programmes
à objet par le calcul de métrique et les modèles de qualité (réalisable
par une autre équipe d'étudiants);
- Automatiser l'identification de patrons de conception (contribution en
partie seulement, puisque notre niveau de connaissance n'est pas
suffisamment avancé dans ce projet pour proposer une solution à
l'automatisation, si celle-ci est possible).
ENVIRONNEMENT DE TRAVAIL
Le travail que nous avons effectué est essentiellement réalisé à travers
l'environnement de développement pour Java, fourni par la plate-forme
Eclipse. De plus, l'emploi de l'outil Visio offert par Microsoft s'est
avéré utile au cours de notre projet.
MÉTHODOLOGIE
Dans les quelques pages qui suivent, nous allons tenter d'exposer les trois
méthodologies que nous avons développées au cours de ce projet, afin de
pouvoir proposer des recettes simplifiant le processus d'identification de
patrons de conception dans des logiciels complexes. De plus, les
descriptions sont agrémentées de nos critiques. On remarquera qu'il existe
un progrès, une évolution constante, dans la description d'une méthodologie
par rapport à la précédente, au fur et à mesure que nous devenons plus à
l'aise avec cette tâche difficile que représente le retraçage de patrons de
conception.
Background Nous sommes tous deux étudiants au baccalauréat en informatique,
orientation génie logiciel. Ainsi, nous avons déjà assimilé certaines
notions des patrons de conception présentées dans les cours de base, soient
IFT22