Proposition d un système patron pour la conception de sites web

Transcription

1 Proposition d un système patron pour la conception de sites web E. Cocquebert, D. Trentesaux, and C. Tahon LAMIH - Université de Valenciennes, le Mont Houy, Valenciennes cedex 9, France Résumé Les sites web ayant pris une place prépondérante en termes d images, de diffusion d information et d outils de travail, leurs conceptions sont progressivement passées d un mode artisanal à un développement basé sur des méthodes et sur la réutilisation de travaux existants. En nous basant sur un état de l art qui montre les avantages et inconvénients des travaux actuels sur les réutilisations logicielles et conceptuelles, nous définissons les spécifications d un système patron dont l objectif est de guider l utilisateur le long d un processus de conception (réutilisation conceptuelle), avec une aide évoluée au choix de composants logiciels (réutilisation logicielle). Nous présentons ensuite les patrons métiers et le processus de ce système patron. Après avoir présenté notre cadre applicatif qui est la conception du nouveau site web du LAMIH, une dernière partie nous permet de conclure et de présenter les perspectives de notre travail. L Mots clés réutilisation, composants, patrons I. INTRODUCTION ES sites web ayant pris une place prépondérante en terme d images, de diffusion d information et d outils de travail, leur conception à fait l objet de soins de plus en plus importants. Cela a entraîné un coût de plus en plus élevé pour pouvoir produire un site toujours à jour, disposant de plus en plus d informations, utilisant les dernières technologies interactives de présentation d informations, etc. Afin de diminuer le temps de mise en œuvre, donc le coût du développement, la conception des sites web est progressivement passée d un développement artisanal «from scratch» à un développement basé sur la réutilisation de travaux existants. Au cours de notre expérience de conception de 10 sites web et du développement de 4 modules spécifiques pour ces sites web 1, durant laquelle notre souci constant était la réutilisation de travaux logiciels existants, nous avons remarqué des freins et des manques pour mettre en œuvre cette démarche de réutilisation : problèmes pour identifier rapidement les travaux existants, lacunes dans les méthodes pour les réutiliser, lacunes dans la définition d un cadre de développement. Ceci nous a conduits à vouloir proposer un cadre pour la conception de sites web, intégrant la réutilisation de travaux logiciels existants. La partie II de cet article détaille l état de l art autour des deux types de réutilisation qui nous concerne : la réutilisation logicielle et la réutilisation conceptuelle. Cet état de l art nous permet de définir dans la partir III les spécifications de notre proposition d un système patron pour la conception de sites web. Le cœur de ce système patron est présenté dans la partie IV. La partie V présente le cadre applicatif de ce système patron : la conception du nouveau site web du LAMIH. La partie VI conclut cette publication en synthétisant les points importants. II. ETAT DE L ART SUR LA REUTILISATION De nombreuses réflexions ont été menées pour donner le moyen de réutiliser des travaux existants lors du développement d un nouveau système. Ils ont conduit à la définition de différents types d entités et de différents types de réutilisation. Parmi les différents points de vue de classification de ces entités que nous avons recensé dans la littérature [5, 10, 19], nous reprenons celui qui différencie les entités par rapport aux étapes du cycle de développement, et nous nous focalisons sur la réutilisation logicielle à l étape d implémentation et la réutilisation conceptuelle à l étape de conception. L étape d implémentation ayant été la première à être concernée par la réutilisation, nous présentons d abord la réutilisation logicielle. A. Réutilisation logicielle Les différentes entités logicielles que l on peut réutiliser sont les fonctions/sous-programmes/classes, les composants et les frameworks. Les Fonctions/sous-programmes/classes C est le type le plus ancien de réutilisation. Ces entités se présentent sous la forme d un ensemble de fichiers regroupés sous la forme de bibliothèques d un même domaine (mathématiques, graphisme, etc.), d un même langage (classes en C, C++, Java, ADA ) [5], dédié à un langage (PEAR 2, PECL 3 ), d un même environnement (Enterprise Java Beans,.NET Platform, Framework San Fransisco) [7] d un même IDE [19], pour le développement de système à base de connaissances (bibliothèques de PSM ou «Problem Solving Methods»), etc. La réutilisation de ces fonctions/sous-programme/classes se traduit par une inclusion des fichiers de définition de ces entités («headers»). Même si ces bibliothèques peuvent offrir une recherche par mots-clés, l identification d une fonction/sous-programme/classe dans une librairie est fortement dépendante de l expérience de l utilisateur. 1 Cf

2 Les composants Ils se présentent comme un ensemble cohérent de classes et sont dédiés à la réalisation d une fonction précise. S ils se présentent sous une forme binaire (composants «boîtes noires»), ils sont reconnus sous le nom de COTS «Commercial Off-The-Shelf», puis «Component-Off-The- Shelf» [2]), et ils sont inclus tel que dans le nouveau système pour être utilisés via leurs interfaces [3]. Si les codes sources sont disponibles (composants «boîtes blanches»), ils peuvent être utilisés après amélioration. Dans les deux cas, ils peuvent être regroupés dans des bibliothèques, avec des fonctions de recherche par mots-clés ou par type de fonction, ou en utilisant un processus automatique [26]. En intégrant un composant dans un nouveau système, un avantage est la mise en œuvre déjà mature de la fonction correspondante et le bénéfice de ne pas refaire ce qui existe déjà ; un inconvénient est l absence d aide à l identification autre que par une recherche par mots-clés ou par type de fonction. En effet, il n existe pas à notre connaissance de recueil de retours d expériences sur les fonctionnalités, les évolutions, le dynamisme de la communauté utilisateurs, etc. Ainsi, l avantage d intégrer au sein d un nouveau système une solution déjà mature sous la forme d un composant, peut être compromis par le temps nécessaire pour choisir celui-ci parmi un ensemble de composants candidats, que l on doit tester soi-même du fait de l absence d aide au choix. Les frameworks. Ils permettent la conception d une application à part entière. Ils se présentent sous la forme d un ensemble de classes organisées selon une architecture préétablie, mais proposant également des mises en œuvre de fonctionnalités courantes. Un avantage est de bénéficier implicitement d une réflexion qui a conduit à une architecture de système, à l organisation des classes dans cette architecture, et à la définition d une démarche pour leur réutilisation efficace. Un inconvénient est la difficulté d y intégrer un développement déjà existant s il ne respecte pas les principes de développement imposés par le framework. On les utilise: - par spécialisation via le mécanisme d héritage ou par leurs interfaces s ils sont définis, - en les intégrant dans un autre système tel que ou suite à une configuration et/ou une adaptation, - pour développer des familles génériques d applications. Dans ce dernier cas d utilisation, des frameworks ont été utilisés pour concevoir des logiciel de gestion de contenus (Content Management System - CMS) dédiés à une famille particulière de sites web : les sites portails. Un avantage d un CMS est de proposer dès le départ des fonctions que l on retrouve généralement dans les sites web portails (pages dynamiques, forums de discussion, enquêtes en ligne, profil d utilisateurs, etc.), que l on peut configurer selon le contexte d utilisation ; un inconvénient est que le développement d une fonctionnalité absente est contraint (et parfois freiné) par les choix de développement du CMS, et que l on ne peut intégrer que des composants qui les respectent. Ainsi, baser le développement d un nouveau système sur le choix d un framework ou d un CMS (dans le cas d un site web portail) impose de respecter des choix de développement et d architecture, mais également de ne pas changer d outil en cours de développement sous peine d avoir ensuite des difficultés pour réutiliser le travail déjà fait. Synthèse La réutilisation logicielle définit des entités de complexité croissante : - Les fonctions/sous-programmes/classes. Elles sont réutilisées implicitement dès que l on utilise un langage de développement, ou explicitement si l on utilise des fonctions spécifiques. - Les composants. Ils évitent de perdre du temps à refaire ce qui existe déjà, mais l absence d une aide évoluée au choix peut en annuler le bénéfice d utilisation. - Les frameworks (et les CMS). Ils offrent dès le démarrage un cadre de développement, mais il est impératif (i) de le respecter (et de le garder) si on veut les utiliser efficacement, (ii) de choisir un outil pérenne si on ne veut pas investir inutilement du temps. La partie suivante présente les différents moyens qui ont été définis pour réutiliser des travaux existants au niveau conceptuel. B. Réutilisation conceptuelle Après avoir présenté l entité conceptuelle qui est la plus utilisée, nous présentons les différents moyens qui ont été définis pour l utiliser. Entité conceptuelle L entité majoritairement utilisée à ce niveau est appelée «patron». Les patrons proposent des solutions génériques et éprouvées pour résoudre des problèmes récurrents d un domaine donné [23]. De nombreux travaux ont définis différents types de patrons, mais leur classification est habituellement reliée à leur portée, c est-à-dire à une étape du cycle de conception [1, 10, 14, 20, 21]. On distingue entre autres les patrons d analyse [10] ; les patrons de conception détaillée [23], globale [24] ou liée à des architectures particulières [27] ; les patrons processus [4, 7, 10, 18] ; les patrons d implantation, aussi appelés idiomes [28]. Un avantage de ces patrons est qu ils généralisent une expérience propre à une activité particulière ; un inconvénient est qu ils sont définis par des rubriques textuelles non formalisables. Supports à l utilisation Selon les buts, les objectifs et l expérience des utilisateurs, les nombreux travaux de recherche du domaine ont défini différents supports pour utiliser ces patrons afin de concevoir un nouveau système. Un premier support consiste à regrouper les patrons au sein d un catalogue. On peut citer le catalogue pour la conception logicielle pure [11], les architectures de systèmes [24], d analyse [25], etc. Un avantage est de

3 disposer d un ensemble de patrons d un même type, un inconvénient est de ne pas fournir d aide au choix autre que les rubriques textuelles des patrons. Ce dernier point impose d avoir une expérience confirmée pour pouvoir identifier et utiliser efficacement un patron à partir d un catalogue. Une réponse à cet inconvénient est de définir des patrons pour un métier précis. Comme ils généralisent une connaissance métier, ils respectent la notion initiale des patrons ; cette connaissance étant celle d un métier, ils sont plus facilement applicables. On peut citer par exemple les propositions [22] et [29] pour l encapsulation de composants logiciels, [15] et [16] pour la conception d applications collaboratives, [6] et [9] pour la conception d interfaces utilisateurs, [8] pour la conception de systèmes de télécommunications, etc. Un avantage de ces catalogues métiers est de regrouper des patrons qui sont plus facilement identifiables et applicables pour un besoin donné ; un inconvénient est que leur utilisation n est pas encadrée par une démarche. La définition de cette démarche est l objectif des langages patrons. «Collection structurée de patrons construits l un sur l autre pour transformer les besoins et les contraintes dans une architecture» [23], ils expliquent quand et comment appliquer des patrons par des règles et des lignes de conduite [4]. D un point de vue général, ils décrivent des familles de système. Un avantage de leur utilisation est d être guidé dans la séquence d utilisation ; un inconvénient est de ne pas avoir de lien direct avec l implémentation des solutions préconisées par les patrons utilisés. Ce lien entre l aspect conceptuel des patrons et l implémentation est apporté par les systèmes patrons. Ils définissent une architecture cadre de l utilisation d un ensemble de patrons, et des lignes de conduite pour leur implémentation, leur combinaison et leur utilisation pratique dans le développement de logiciels [4]. Ils sont définis par [4, 6, 7, 10, 12, 13, 16, 21]: - un catalogue de patrons métiers, facilitant le développement d applications d un domaine donné, - une organisation relative des patrons et un ou plusieurs processus qui orientent et guident l utilisateur dans le choix et la séquence d utilisation des patrons métiers (le langage patron), - des solutions qui implémentent les solutions préconisées par les patrons, - un patron architecture qui établit une architecture logicielle générique d une application du domaine. Utilisant un catalogue métier, ces systèmes sont reliés à un domaine d application (par exemple, pour la conception d applications collaboratives [12] et pour la conception d interfaces utilisateur [13]). Leur avantage est d orienter l utilisateur vers tel ou tel patron métier du catalogue en fonction de l étape ou il se trouve dans le processus de conception, et d y associer une implémentation. L inconvénient est qu il y a toujours une opération de codage à la fin de l utilisation d un patron. Synthèse La réutilisation conceptuelle formalise l expérience sous la forme d entités appelées patrons. Selon les buts, les objectifs et l expérience des utilisateurs, différents supports à l utilisation de ces patrons ont été définis : - Les catalogues. Ils regroupent des patrons d un même domaine, mais ils nécessitent une solide expérience pour identifier un patron par rapport à un besoin et l utiliser efficacement. - Les catalogues métiers. Ils sont plus facilement applicables, mais sans guide d utilisation. - Les langages patrons. Ils apportent cet encadrement pour l utilisation, mais ils ne font pas de lien vers l implémentation. - Les systèmes patrons. Ils font le lien entre les patrons et l implémentation, mais toujours sous la forme de codage. En se basant sur cet état de l art, la partie suivante présente les spécifications de notre proposition. III. SPÉCIFICATIONS L objectif est de proposer un cadre pour la conception de sites web, permettant la réutilisation de travaux logiciels existants, et intégrant une aide évoluée à leur choix. Notre analyse de l état de l art sur la réutilisation logicielle préconise de choisir l utilisation des composants en tant que travaux logiciels existants : dédiés à une fonction de service, leur intégration est circonscrite à un ensemble utile de fonctions, contrairement à l intégration d une bibliothèque de fonctions ; d un fonctionnement autonome, leur choix est moins risqué que celui d un CMS ou d un framework, car leur remise en cause n a pas d influence sur l architecture générale du système. Parmi les deux types de composants existants (composants «boîtes blanches» et composants «boîtes noires»), c est le premier que l on retrouve généralement dans le domaine de la conception de sites web sous la forme de composants «open source». Nous focalisons donc notre proposition sur la réutilisation de composants «boîtes blanches». Comme il n existe pas d aide à l identification de composants autre que sous la forme d une recherche par mots-clés ou par fonction, il est nécessaire de développer ce point. Cela passe par la définition d un ensemble de critères caractéristiques de ces composants (exigences logicielles, matérielles, retours d expérience, etc.) afin d aider à choisir un composant pour un besoin donné. Notre analyse de l état de l art sur la réutilisation conceptuelle préconise de proposer sous la forme d un système patron notre cadre pour la conception de sites web : «patron» pour formaliser une démarche conceptuelle de conception de sites web, «système» pour relier l aspect conceptuel à l aspect implémentation. L état de l art nous indique que la définition d un système patron nécessite de formaliser : - sous la forme de patrons métiers, les différentes étapes de conception de sites web, - sous la forme d un langage patron, le processus de succession des différents patrons métiers, - sous la forme d un patron architecture, une architecture logicielle générique d un site web. Afin d intégrer à ce système une aide évoluée au choix de composants, nous proposons : - que les patrons métiers préconisent tel ou tel type de composants (et non pas telle ou telle forme

4 d implémentation), et donne une liste de composants potentiels - que des informations sur ces composants potentiels soient disponibles sous la forme de «fiches composants» au sein d un catalogue, et aident l utilisateur à faire un choix en donnant des informations sur les fonctionnalités, les exigences logicielles, des retours d expérience, etc. Dans le cadre de cette publication, nous nous focalisons sur les patrons métiers et sur le langage patron. IV. PROPOSITION D UN SYSTEME PATRON POUR LA CONCEPTION DE SITES WEB Les sites web qui nous intéressent sont les sites de diffusion d informations (portails, sites de conférence), et les sites de travail collaboratifs (avec wiki, système de gestion de contenus). A. Patrons métiers Nos patrons métiers ont pour but de guider l utilisateur dans chacune des étapes de conception d un nouveau site web. Patron «Besoin» De nombreux travaux relatifs aux méthodologies de développement informatique en général [17] ou dédiées à la conception de sites web [30] ont montré que le besoin d une application doit être identifié avant sa mise en œuvre. De manière traditionnelle, ces besoins sont identifiés à l aide d entretiens avec les utilisateurs cibles, et leur analyse permet de définir : - les groupes éventuels d items, - le nom des items de menus, - la liste des fonctions à mettre en œuvre et à associer aux items. La structure d un menu formant une arborescence, l implémentation de ce patron est basée sur celle du patron «composite» [11] (cf. Figure 1), qui permet de traiter de la même manière les racines et les feuilles de chaque branche de l arborescence, sans limitation de profondeur. Figure 1: diagramme de classes du patron "composite" Patron «Dialogue» L interface utilisateur d une application peut présenter des informations de différentes natures : - informations générales telles que logos ou menu. Présentes sur toutes les pages de l application, leur affichage est toujours valide, et elles complètent la charte graphique pour former la signature de l application. - informations à durée de vie limitée telles que mises à jour ou rappels d événements à venir. Généralement, ces informations sont uniquement présentes sur la page d accueil afin que le visiteur en ait connaissance immédiatement. - informations spécifiques à une page interne de l application, qui ne sont donc présentes que sur cette page. Ces différents types d informations peuvent être répartis selon des zones de différentes natures : - «navigation» : affiche l arborescence du menu qui permet d accéder aux différentes fonctions de services définies à l aide du patron «besoin». Son affichage peut être différent selon le type d affichage du menu choisi : complet, hiérarchique, déroulant, etc. - «liens rapides» : affiche et donne un lien vers des informations à durée de vie limitée : mises à jour récentes, documents spécifiques, etc. Cette zone peut être attachée à un groupe d items ou à un item. - «annonces» : affiche et donne également un lien vers des informations à durée de vie limitée telles que les événements à venir qui sont datés. Cette zone peut également être attachée à un groupe d items ou à un item. - «statique» : elle contient des informations stables et communes à toutes les pages. C est donc la même instance sur toutes les pages de l application. - «contenu» : associée à une page interne, elle affiche des informations qui lui sont spécifiques. Elle peut contenir d autres zones. Concernant les zones de navigation, de liens rapides, d annonces et de contenu, elles sont définies sous la forme de zones dans un fichier modèle, auxquelles sont associés des labels («zone_contenu», «zone_liens_item1», «zone_annonces_item1», etc.) qui sont remplacés par un contenu lors de l appel du fichier. La zone statique peut être implémentée de deux manières : - en utilisant la notion de modèle que l on peut trouver dans des éditeurs HTML tels que Dreamweaver, dans lequel on définit ce qui est figé. L avantage est que pour chaque page basée sur ce modèle, une modification dans le modèle est automatiquement répercutée dans toutes les pages qui y sont attachées, - en définissant ce qui est figé dans un fichier externe, et en incluant ce fichier dans chaque page à l endroit qui est nécessaire. L avantage est de ne pas toucher aux pages dans lesquelles le fichier externe est inclus et de ne pas dépendre de l implémentation de la notion de «modèle» par un logiciel. Patron «données» Ce patron a pour objectif de caractériser les différents types de données associées à un item, et la manière avec laquelle elles seront affichées. Quand les données sont dynamiques, les types distingués sont les suivants : - données principales : elles forment l ensemble minimal à afficher pour différencier des informations de même type (exemple : pour une liste de

5 conférences, les données principales sont les acronymes) - données secondaires : elles sont affichées à partir d une sélection d une donnée principale et lui sont complémentaires (pour l exemple de la liste des conférences : affichage de données secondaires telles que le nom complet, le lieu, les dates, le site web, etc. à partir de la sélection d un acronyme) - données internes : elles ne sont pas affichées mais sont utiles à la gestion de l affichage des deux types précédents (exemple : date d insertion, date de modification, date au format TIMESTAMP, etc.) L affichage de données dynamiques se fait sous la forme d un tableau de valeurs sur plusieurs colonnes, d un tableau sur deux colonnes «nom->valeurs», d un tableau de valeurs triées par mois, etc. Il est réalisé en utilisant une librairie (cf. patron «module»), ou par un développement spécifique (cf. les bonnes pratiques sur des catalogues en ligne de patrons 5, 6 ). Patron «Module» Son objectif est d aider à choisir un composant ou une librairie 4 afin de le(la) réutiliser pour concrétiser les interfaces utilisateur (définies via le patron «dialogue»), associées aux fonctions de service (identifiées via le patron «besoin»), et utilisant les données de l application (identifiées via le patron «données»). Le diagramme de classe est composé d une classe unique «module» (cf. Figure 2) dans laquelle : - l attribut «url_details» renvoie sur une des sources externe : catalogue de patrons d interface utilisateur de M. van Welie 5 ou de J. Tidwell 6 ; catalogues de composants «opensourcecms 7», «cmsmatrix 8», etc. qui permettent une identification à partir de critères fonctionnels ; catalogue de briques logicielles PHP 9, qui considère également des informations non fonctionnelles - les autres propriétés sont initialisées à partir de ces sources externes si les valeurs sont disponibles. Figure 2 : classes du patron "module" B. Langage patron Il définit la séquence d utilisation des différents patrons métiers qui viennent d être présentés. De manière analogue à [10], il est formalisé par le Tableau 1. 4 En simplifiant, une librairie est un composant sans interface utilisateur Etape Contenu de l étape Patrons utilisés 1 Définir l arborescence du menu du «Besoin» système final et les fonctions de service de chacun des items. Dans le cas ou les fonctions de service sont remplis par des composants (par exemple : forums), aller à l étape 6 pour identifier les composants candidats. 2 Implémenter l arborescence du menu et «Besoin» son affichage 3 Choisir un item de l arborescence et «Dialogue» définir le contenu de son interface utilisateur. 4 Organiser les différentes zones dans la «Dialogue» page d accueil et dans les pages internes du site web, et définir les modèles de pages. 5 Caractériser les données associées à un item. Si l affichage est implémenté par une librairie, aller à l étape 6 pour identifier les librairies candidates ; s il est implémenté par un développement spécifique, aller à l étape 7 dès lors «Données», catalogues externes de patrons d interfaces 5, 6 qu il est réalisé. 6 Dans le cas ou la fonction de service «Module» est remplie par un composant ou une librairie, choisir un module à l aide de 7, 8, 9 catalogues externes. 7 Intégrer au sein d une page associé à l item la librairie ou le développement spécifique à l aide d un code d assemblage («glue code») 8 Reprendre le processus à l étape 3 pour un autre item de l arborescence. Tableau 1: Langage patron V. APPLICATION Ayant formalisé cette démarche de réutilisation dans un cadre basé sur un état de l art, notre objectif est de l utiliser pour concevoir le futur site web du LAMIH : - définition de pages publiques sur les objectifs de recherche en général et par équipes, la composition des équipes, les publications, les projets de recherche, les événements à venir, etc. - définition de pages privées sur les différents documents de fonctionnements administratifs, les logiciels et équipements disponibles, les liens internet d intérêt commun, etc. - définition d un espace de gestion de données concernant les publications, les événements à venir, les logiciels et équipements disponibles, etc. - définition d accès à des outils de travail collaboratif tels que «wiki», dépôt de documents, listes de diffusion d informations, etc. Cet exemple pratique permettra d affiner et de renforcer la définition de notre système patron. VI. CONCLUSION ET PERSPECTIVES A partir de notre expérience de conception de sites web qui nous a montré des freins et des manques dans les méthodes existantes pour supporter la réutilisation de 9

6 travaux logiciels existants, notre objectif est de proposer un cadre de développement de sites web pour améliorer cette réutilisation. En nous basant sur un état de l art des travaux existants sur les réutilisations logicielles et conceptuelles, nous spécifions ce cadre sous la forme d un système patron. Les composants en sont un ensemble de patrons métier reliés à une bibliothèque documentée de composants, un processus qui guide l utilisateur le long du processus de conception du site web, et une architecture logicielle générique d applications «site web». Dans le cadre de cet article, nous nous sommes focalisés sur le processus de conception des sites web et sur les patrons métiers de notre système patron. Nous avons enfin présenté notre cas d application qui est la conception du nouveau site web du LAMIH. Les perspectives de nos travaux sont : - d un point de vue recherche, de formaliser notre catalogue de composant à l aide de QSOS 10, qui est une méthode conçue pour qualifier, sélectionner et comparer les logiciels open source ; et de relier nos patrons à ce catalogue de composants - d un point de vue applicatif, de confronter régulièrement la définition de notre système patron à son utilisation pour concevoir le nouveau site du LAMIH, de continuer la mise en place de notre catalogue de composants potentiels 9, et de compléter nos patrons par un framework de classe génériques. VII. BIBLIOGRAPHIE [1] G. Antoniol, G. Casazzab, M. Di Pentaa, R. Fiutemc: Objectoriented design patterns recovery. Journal of Systems and Software, Volume 59, Issue 2, 15 November 2001, Pages [2] Sous la direction de J. Arlat : «Composants logiciels et sûreté de fonctionnement». Hermès, [3] O. Barais : «Construire et Maîtriser l'evolution d'une Architecture Logicielle à base de Composants». Thèse de doctorat, USTL, [4] I. Borne : «Patterns pour le développement logiciel - Langage et systèmes de patterns». Journées patterns, Grenoble 3 et 4 avril [5] Sous la direction de C. Cauvet : «Ingénierie des systèmes d informations». Hermès, [6] J. Coldewey, I. Krüger : Form-Based User Interface - The Architectural Patterns. A Pattern Language. EuroPLoP 1997, Irsee, Germany. [7] E. Todd, E. Kemp, C. Phillips : What makes a good User Interface pattern language?. 5th Australasian User Interface Conference (AUIC 2004), Dunedin. [8] E. Körner : Patterns for constructing CSCW applications in TINA. Computer Communications Volume 21, Issue 15, 1 October 1998, Pages [9] I. Fliege, A. Geraldy, R. Gotzhein, T. Kuhn, C. Webe : Developing safety-critical real-time systems with SDL design patterns and components. Computer Networks Volume 49, Issue 5, 5 December 2005, Pages [10] A. Front : «Développement de systèmes d'information a l'aide de patrons : Développement de systèmes d'information à l'aide de patrons». Thèse de doctorat, Université Joseph Fourier, [11] E. Gamma, R. Helm, R. Johnson, J. Vlissides : Design pattern, Elements of Reusable Object-Oriented Software. Addison Wesley, [12] L. A. Guerrero, D. A. Fuller : A pattern system for the development of collaborative applications. Information and Software Technology, Volume 43, Issue 7, 1 June 2001, Pages [13] Å. Granlund, D. Lafrenière, D. A. Carr : «A Pattern-Supported Approach to the User Interface Design Process. Proceedings of HCI International th International Conference on Human- Computer Interaction, August 5-10, 2001, New Orleans, USA. [14] S. Lepreux : Approche de développement centrée décideur et à l aide de patrons de Systèmes Interactifs d Aide à la Décision». Thèse de doctorat, Université de Valenciennes, [15] G. Licea, J. Favela : An extensible platform for the development of synchronous groupware. Information and Software Technology, Volume 42, Issue 6, 15 April 2000, Pages [16] S. Lukosch, T. Schümmer : Groupware development support with technology patterns. International Journal of Human-Computer Studies, Volume 64, Issue 7, July 2006, Pages [17] P. Meinadier : «Ingénierie et intégration des systèmes». Hermes, 1998 [18] M. Morisio, C. B. Seaman, V. R. Basili, A. T. Parra, S. E. Kraft, S. E. Condone : COTS-based software development: Processes and open issues. Journal of Systems and Software Volume 61, Issue 3, 1 April 2002, Pages [19] Sous la direction de C. Oussalah «Génie objet». Hermes, [20] D. Rieu : Ingénierie des Systèmes d Information». HDR, INPG, [21] M. Saidane : Formalisation de familles d Architecture logicielles coopératives : démarches, modèles et outils. Thèse de doctorat, Université Joseph Fourier, [22] Z.-W. Honga, J.-M. Lina, H. C. Jiaub, G.-M. Fanga, C. W. Chiouc : Encapsulating windows-based software applications into reusable components with design patterns. Information and Software Technology, Volume 48, Issue 7, July 2006, Pages [23] C. Alexander : A Pattern Language. New York:Oxford University Press, [24] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal : Pattern-Oriented Software Architecture, Wiley [25] M. Fowler : Analysis Patterns - Reusable Object Models, Addison-Wesley, [26] D. Spinellis, K. Raptis : «Component Mining: A Process and its Pattern Language Information and Software Technology, 42(9): , June [27] J-M. Jezequel, S. Lorcy, N. Plouzeau : «Un patron pour la gestion de la qualité de service d'applications réparties «, Numéro spécial de la revue L OBJET : Patrons Orientés Objet, Hermès, [28] J.O. Coplien : Advanced C++ Programming Styles and Idioms. Addison-Wesley, [29] D. Parsons, A. Rashid, A. Telea, A. Speck : An Architectural Pattern for Designing Component-Based Application Frameworks. Software Practice & Experience, Volume 36, Issue 2 (February 2006), Pages: [30] M. Villanova-Oliver : «Adaptabilité dans les systèmes d information sur le web : Modélisation et mise en oeuvre de l accès progressif». Thèse de doctorat, INPG,