Ingénierie des systèmes d'information produit : une approche méthodologique centrée réutilisation de patrons Corine CAUVET1 - Dominique RIEU2 - Bernard ESPINASSE1 – Jean-Pierre GIRAUDIN2 - Michel TOLLENAERE3 1 - DIAM-IUSPIM, Université d'Aix-Marseille, Domaine universitaire de Saint Jérôme, 13397 Marseille Cedex 20 FRANCE - E-mail: [email protected] 2 - LSR-IMAG, BP72, 38402 Saint Martin d'Heres Cedex FRANCE E-mail: [email protected] 3 - GILCO-ENSGI, 46 avenue Félix Viallet, F-38031 Grenoble, Cedex FRANCE E-mail: [email protected]

Résumé : Dans les organisations industrielles, les systèmes d'information produit (SIP) supportent la gestion des données techniques des produits et de leurs processus de conception/production. Le contexte économique actuel fait que ces SIP sont stratégiques pour ces organisations qui font actuellement face à de nombreuses difficultés dans leur développement. L'objet de cette recherche est de définir un cadre méthodologique adapté à l'ingénierie de tels systèmes et permettant de s'affranchir de ces difficultés. Dans cet article, après avoir identifié ces difficultés et montré la nécessité de la réutilisation pour un développement "en écart" de ces systèmes, nous distinguons différentes formes de réutilisation déjà introduites dans le génie logiciel, en mettant plus particulièrement l'accent sur la réutilisation de patrons (ou « patterns »). Le cadre méthodologique proposé est principalement basé sur la réutilisation de patrons tout au long du processus de développement du SIP. Ces patrons sont utilisés pour définir des problèmes récurrents de développement de ces systèmes et permettre la réutilisation de solutions associées. Le papier illustre l’approche par la définition et la spécification d'un patron métier adapté à un problème de conception mécanique. Mots-clés : Patron de conception, Patron métier, Système d'Information Produit (SIP), Système de Gestion de Données Techniques, Réutilisation.

Abstract : In industrial organisations, the product information systems (PIS) support the technical data management of products and their process of design/production. The current economic context makes these PIS strategic for these organisations. Currently, these organisations have many difficulties in the development of these systems. The object of this research is to define a methodological framework adapted to PIS engineering and allowing to reduce these difficulties. In this article, firstly, we identify these difficulties and we augue the necessity of a reuse approach for a development "in gap" of these systems. Then, we distinguish different forms of reuse already introduced in software engineering, by emphasising more particularly design patterns reuse. The proposed methodological framework is mainly based on the reuse of patterns during the entire development process of PIS. These patterns are used to define recurrent development problems of these systems and to allow the reuse of associated solutions already defined. This paper illustrates this approach with the definition and the specification of a pattern adapted to a mechanical design problem. Key Words : Design Patterns, Product Information Systems (PIS), Technical Data Management Systems, Reuse.

Catégorie : Chercheur, Application industrielle

Page 1

1. Introduction La mondialisation de l'économie des années 90 nécessite de réduire massivement les délais de mise sur le marché de nouveaux produits tout en améliorant leur qualité. Pour cela, l’organisation industrielle devient de plus en plus complexe, conduisant les entreprises à adopter de nouvelles pratiques comme par exemple l'ingénierie simultanée, voire même de nouvelles structures comme l'entreprise étendue ou l'entreprise virtuelle [VER 94, TER 92]. Dans ce contexte, les systèmes d'information produit (SIP), permettant tout d'abord une gestion performante de la base documentaire accompagnant le développement des produits, et ensuite une rationalisation de l'ensemble des tâches du processus de développement et de leurs répartitions entre les différents acteurs, deviennent un enjeu stratégique pour les entreprises industrielles. La réactivité de ces dernières aux modifications inhérentes au processus de développement des produits nécessite un pilotage de la circulation de la documentation technique, une gestion rigoureuse de son évolution et s'accompagne d'une exigence de traçabilité liée à la maîtrise de la qualité, autant de fonctions que doivent assurer les SIP. De nombreux travaux de recherche et notamment plusieurs projets européens s'intéressent déjà au partage et à l'intégration de données techniques dans l'entreprise industrielle. Ainsi, associé à l'initiative AIT [AIT 97] (Advanced Information Technology Design and Manufacturing), citons tout d'abord le projet RISESTEP [RIS 97] qui s'intéresse à l'implantation et la validation de bases de données partagées STEP pour l'ingénierie simultanée, et ensuite le projet PISA [PIS 94] dont l'objectif est de développer une plate-forme pour le partage d'informations comprenant une méthodologie et des outils pour la modélisation d'informations, l'intégration et la validation de modèles. Citons enfin le projet OPAL (Integrated Information and Process Management in Manufacturing Engineering) [OPA 97] dont l’objectif est de fournir des concepts pour l’intégration de haut niveau des processus et de l’information dans le domaine de l’ingénierie et de la production. Ces projets s'intéressent plus particulièrement aux problèmes de l'intégration et du partage de données techniques, problèmes très sensibles dans le développement de SIP. Cependant, ils n'abordent pas dans sa globalité, l'ingénierie même des SIP, à savoir les aspects méthodologiques liés à leur conception et à leur réalisation. Le développement de tels systèmes étant stratégique pour l'entreprise industrielle, les enjeux associés à ces aspects méthodologiques sont en conséquence aussi stratégiques et c'est sur eux que porte notre recherche. Cette recherche consiste à définir un cadre méthodologique pour le développement des Systèmes d'Information Produit (SIP), elle associe des laboratoires universitaires d'informatique (DIAM-IUSPIM, LSR-IMAG), de génie industriel (GILCO-ENSGI), de sociologie (CRISTOCNRS) et deux entreprises industrielles, SCHNEIDER Electric et PCO Technologies. L'objet même d’un SIP est de gérer les informations relatives aux produits ou aux familles de produits tout au long de leur cycle de vie (depuis la conception jusqu’à la production). Le contexte de concurrence économique actuel tend à réduire de plus en plus ce cycle de vie, ainsi une entreprise industrielle est conduite à développer le plus rapidement possible de nombreux SIP qui restent opérationnels uniquement pendant la durée de vie du ou des produits concernés. En conséquence, une ingénierie adaptée aux SIP doit permettre un développement en "écart" de tels systèmes, c'est à dire permettre de concevoir et réaliser de nouveaux SIP à partir de SIP déjà conçus et réalisés, autorisant ainsi la réutilisation d’éléments de spécification et de composants logiciels existants. L'approche méthodologique que nous proposons dans ce papier est centrée sur la réutilisation de patrons (ou "patterns") et s'inspire de divers travaux déjà réalisés dans le domaine du génie logiciel.

Page 2

Dans cet article, nous développons tout d'abord la problématique de l'ingénierie des SIP, liée à la spécificité même de ces systèmes et nous précisons les principaux problèmes méthodologiques du développement des SIP auxquels sont actuellement confrontées les entreprises industrielles. Ensuite, après avoir montré la nécessité de la réutilisation en ingénierie des SIP, nous distinguons différentes formes de réutilisation déjà introduites dans le génie logiciel, en développant plus particulièrement la réutilisation de patrons. Puis nous développons l'approche méthodologique que nous avons adoptée et qui est basée sur la réutilisation de patrons tout au long du cycle de vie du SIP (de l'expression des besoins à l'implantation et la maintenance évolutive). Nous présentons la démarche que nous avons retenue pour identifier et spécifier des patrons métiers. Enfin, nous concluons sur les travaux en cours et les perspectives de notre recherche.

2. Problématique de l'ingénierie des SIP 2.1 Spécificités des SIP Le SIP occupe une place centrale dans l'entreprise industrielle moderne. En effet, il supporte toute la gestion de l'information technique, de la base documentaire qui accompagne le développement des produits, de l'ensemble des tâches du processus de développement et de leurs répartitions entre les différents acteurs, etc. Il se présente comme un système sociotechnique, caractérisé par des aspects organisationnels et informatiques. Il s'articule autour de quatre composants majeurs : • les informations relatives aux produits concernés par le SIP et qui en constituent le noyau. Ces produits sont à définir, à caractériser et à suivre, en particulier à faire évoluer, d'une manière générale mais aussi d'une manière spécifique en fonction de leur utilisation dans un processus Etude-Conception-Fabrication-Vente-Après/Vente. Ces produits ne sont pas indépendants les uns des autres et leurs liens sont variés : liens de structuration, de dépendance, de famille... ; •

les documents qui constituent la partie externe du SIP, ce sont des documents techniques adaptés aux rôles des différents acteurs (plans, fiches d'instruction, documents de maintenance...) ;

•

les fichiers d'échanges avec les autres systèmes ; il s’agit par exemple des outils de calcul, des systèmes de simulation...qui sont des éléments essentiels d'ouverture de ce type de système ;

•

les procédures («workflow ») qui codifient les activités [SCH 97a, 97b, 97c] et les rôles des différents partenaires (concepteur, fournisseur, vendeur...), les règles d'organisation, d'échanges, de décision, de droits d'accès, etc. C’est de la prise en compte et de l’expression de la participation de chacun à la résolution du problème, de leurs différentes contraintes (organisation interne, ressources disponibles aussi bien humaine que matérielle...), et des coopérations entre eux qu’émerge une solution.

Face aux besoins des entreprises industrielles de développer des SIP, une offre progicielle s'est développée en proposant des systèmes de gestion de données techniques (SGDT)[RAN 95]. Les SGDT sont de plus en plus utilisés par les entreprises industrielles de grande taille (Schneider, Boeing, ..) pour implanter des SIP. La plupart de ces SGDT, par exemple le produit Metaphase [SDR 96], sont en fait de grosses boîtes à outils permettant de définir et d’exploiter les composants précédents.

Page 3

2.2 Problèmes méthodologiques liés au développement des SIP Comme la plupart des systèmes d'information, le cycle de développement d'un SIP est constitué des étapes chronologiques de l'expression des besoins, de la conception, de la réalisation et de la maintenance. Dans le développement de SIP et tout au long de ce cycle de développement, les entreprises industrielles rencontrent actuellement des difficultés techniques, méthodologiques, organisationnelles et humaines que nous allons brièvement évoquer : •

L'expression des besoins : c'est une étape importante devant conduire à l'élaboration d'un dossier contractuel entre partenaires informaticien (maître d’oeuvre) et utilisateur (maître d’ouvrage). Ce dossier, pouvant donner lieu à ré-actualisation, précise les contraintes et les objectifs du système d'information cible. Cette première étape est rendue délicate par le manque de modèles "formels" et compréhensibles par le maître d’ouvrage ainsi que de démarches adaptées pour élaborer des spécifications parlantes et non ambiguës des besoins.

•

La conception : en s'appuyant sur l'expression des besoins, elle définit les spécifications du SIP. Ces spécifications seront prises en charge par des responsables d’application chargés de leur implantation. Actuellement cette spécification est faite sans réelle continuité. Le chef de projet SIP établit généralement deux dossiers distincts : l'un destiné au client, l'autre pour l'équipe d'informaticiens. La cohérence entre l'attendu et le délivrable restant purement intentionnelle.

•

La réalisation : elle passe de plus en plus par l'utilisation de SGDT, plates-formes d'outils adaptées à la caractérisation d’articles, de nomenclatures, de documents, de procédures, etc. dont la mise en oeuvre est extrêmement complexe et rend difficile la prise en compte des spécifications précédentes. Ce problème n'apparaît pas uniquement lors de la spécification et l'implantation d’un SIP mais aussi lors de son évolution dans l'entreprise en fonction d'évolutions conceptuelles (par exemple les objectifs), organisationnelles (par exemple de nouveaux flux d'information, l'évolution des procédures qualité) ou techniques (introduction d'un logiciel ad-hoc, changement de version du progiciel SGDT, etc.) ayant un impact sur le SIP.

•

La maintenance évolutive : l'objet d'un SIP est de supporter une organisation du travail impliquant des ressources humaines et matérielles. Les besoins de l'organisation évoluent constamment et nécessitent une maintenance évolutive des SIP qui la supportent, conduisant à la définition de nouvelles fonctionnalités pouvant engendrer des changements organisationnels et une maintenance évolutive des parties logicielles du système. L'implantation comme l'évolution des SIP dans l'organisation ne sont actuellement pas abordées de façon méthodique, ce qui conduit à engendrer des coûts et des dysfonctionnements très importants.

A ces difficultés relatives à chacune des étapes du cycle de développement des SIP, il ne faut pas perdre de vue que de tels systèmes ont pour finalité de supporter le cycle de vie du produit, c'est à dire l'accompagner, au sein de l'organisation industrielle, lors de sa conception, sa fabrication, sa production ... Une entreprise industrielle est ainsi amenée à développer constamment de nouveaux SIP pour un nouveau produit ou une nouvelle famille de produits. Le cycle de vie des produits industriels a tendance à être de plus en plus court. En conséquence, celui des SIP les supportant l’est aussi. Un problème majeur et bien connu dans le développement des SIP est le déplacement de la cible à atteindre au cours du temps de développement, ce qui conduit à livrer des systèmes obsolètes avant même leur mise en production.

Page 4

3. Une approche méthodologique centrée sur la réutilisation de patrons 3.1 La nécessité de la réutilisation pour le développement des SIP Les problèmes que nous avons précédemment évoqués, et plus particulièrement la nécessité de réduire au maximum la durÈe des différentes étapes du cycle de vie des SIP, nous conduisent à proposer une nouvelle approche méthodologique. Cette approche, pour être adaptée à la spécificité de ces systèmes doit être différente de celles préconisées par les méthodes traditionnelles. En effet, les méthodes systémiques comme les méthodes orientées objet ne sont pas adaptées à la conception de SIP. Tout d'abord aucune d'elles ne couvre complètement la complexité du SIP, par exemple elles ne fournissent pas de modèles adaptés à la représentation de processus, de versions de produit... ; ensuite les modèles qu'elles proposent sont trop génériques pour être, d'une part accessibles aux utilisateurs chargés de leur validation et d'autre part, facilement adaptés à un domaine particulier, ici les SIP. Par ailleurs, ces méthodes ne favorisent pas la capitalisation et la réutilisation de concepts. Un façon efficace de réduire considérablement le temps des différentes étapes de développement des SIP est de permettre des spécifications "en écart" tant d’un point de vue de la capitalisation et de la réutilisation des concepts déjà rencontrés que de la prise en compte des ressources logicielles (composants ou systèmes) disponibles. Ainsi la réutilisation, déjà efficace en génie logiciel, est-t-elle centrale dans notre approche méthodologique de développement des SIP, au niveau de la spécification et de la réalisation de SIP, mais aussi de leur maintenance évolutive. Nous nous plaçons délibérément dans une approche de capitalisation et de réutilisation des acquis en terme de modèles de produits et de processus et ceci, à chacune des étapes du cycle de développement du SIP : •

au niveau de l'expression des besoins il s'agit de réutiliser des expressions partielles des besoins provenant soit de SIP standards associés à des produits types et à des processus de fabrication aussi standards qui pourraient être fournies par les éditeurs de SGDT, soit de SIP déjà développés dans l'organisation industrielle ;

•

au niveau de la conception et de la maintenance évolutive, la réutilisation de spécifications déjà proposées par le SGDT, ou issues d'autres SIP déjà conçus devrait permettre une importante réduction des délais ;

•

au niveau de la réalisation, la réutilisation des composants logiciels standards proposés par ces SGDT (qui sont, rappelons-le principalement des boites à outils), permet d'accélérer l'étape d'implantation du SIP. Cependant, ces composants logiciels sont peu ou mal documentés et le chef de projet SIP doit parfaitement les maîtriser afin d'élaborer des spécifications détaillées en indiquant ce qu’il faut récupérer et comment. Ces spécifications ne peuvent être que réalisées en écart par rapport à l’existant.

Pour appréhender cette capitalisation et cette réutilisation des acquis dans ce cadre méthodologique de l'ingénierie des SIP, il nous est apparu incontournable d'étudier les différentes techniques de réutilisation déjà développées dans le domaine de l'ingénierie du logiciel (orientée objet) et plus particulièrement celle associée à la réutilisation de patrons que nous avons retenue pour les SIP.

Page 5

3.2 Différentes formes de réutilisation en ingénierie du logiciel La réutilisation peut être définie de façon générale comme une nouvelle approche de développement selon laquelle il est possible de construire un système à partir de composants existants. Elle est aujourd'hui largement utilisée dans le domaine de l’ingénierie du logiciel et différentes formes de composants logiciels réutilisables ont déjà été proposées. On peut distinguer trois grandes approches : les bibliothèques de composants (ou « toolkits »), les canevas (ou "frameworks") et les patrons (ou "patterns") : •

L’approche bibliothèque [ POU 95] est la plus ancienne et la plus rudimentaire. Elle offre des ensembles de composants logiciels pour lesquels la recherche, la composition et l’adaptation restent à la charge du développeur. La granularité de ces composants est directement liée aux constructeurs d’un langage de programmation (la classe, la procédure, la fonction....) et leur niveau d’abstraction est peu élevé puisque ces composants ne fournissent ni le contexte dans lequel on peut les utiliser ni les adaptations que l’on peut leur apporter.

•

Les canevas (ou « frameworks ») [WIL 90, FUK 93] sont le plus souvent dédiés à un domaine d’application, ils proposent des architectures-types globales pour un domaine. Des canevas ont été proposés pour la conception d’interfaces graphiques [WIL 90, WEI 88] et le développement des systèmes d’exploitation [MAD 89]. Ils ont un réel avantage par rapport aux bibliothèques : ils dispensent le développeur de choisir les classes, de fournir les interconnexions, de découvrir quelles méthodes sont disponibles, de trouver celles qui doivent être appelées et dans quel ordre. Les canevas cachent toute cette complexité en offrant un niveau d’abstraction plus élevé. Cependant dans certaines situations, ils peuvent devenir trop rigides compte tenu de leur taille.

•

Les patrons ont été introduits par Alexander [ALE 77] dans le domaine de l’architecture. Cette approche connaît aujourd’hui un réel succès à travers les modèles de conception (« design patterns ») de E. Gamma [GAM 94]. Les modèles de conception sont des descriptions d’objets et de classes communicants qui sont personnalisés pour résoudre un problème général de conception, dans un contexte particulier. Cette forme de composant présente plusieurs avantages sur les approches précédentes. D’abord, la granularité d’un patron fournit une unité de raisonnement très modulaire, en effet, chaque patron existe pour répondre à un problème type. Par ailleurs, l’intégration dans un même patron d’un problème type et d’une solution constitue une aide à la recherche et à l’intégration de composants. Bien sûr des problèmes restent à résoudre quant à la composition de patrons et à leur organisation pour permettre une réutilisation efficace.

La réutilisation de patrons nous semble la forme de réutilisation la plus adaptée à l'ingénierie des SIP. En effet, elle peut être utilisée dans toutes les étapes du cycle de développement d’un SIP (expression des besoins, conception, implantation). Les patrons utilisés dans l’étape d’expression des besoins fournissent des solutions à des problèmes de domaine alors que ceux utilisés par exemple au moment de l’implantation fournissent des solutions à des problèmes techniques dans le contexte de SGDT particuliers. Dans la section suivante nous développons la réutilisation de patrons et montrons ses avantages pour le domaine de la conception de SIP.

Page 6

3.3 Réutilisation par les patrons Le concept de patron a été proposé initialement dans le domaine de l’architecture [ALE 77, ALE 79] puis plus récemment utilisé dans le domaine du génie logiciel [GAM 94] [BUC 96] [COP 96] [FOW 97]. Alexander assimile un patron à un savoir faire formalisé : « Chaque patron décrit à la fois un problème qui se produit très fréquemment dans votre environnement et l’architecture de la solution à ce problème de telle façon que vous puissiez utiliser cette solution des millions de fois sans jamais l’adapter deux fois de la même manière ». Des patrons ont été présentés par K. Beck et W. Cunninghan [BEC 87] comme une adaptation du langage de patrons d’Alexander à la conception et à la programmation orientée objet. Dans le cadre de l’ingénierie des systèmes d’information, P. Coad [COA 92] propose de faciliter l'analyse d'un système en identifiant les besoins selon sept patrons pré-établis. R. Johnson, [JOH 93], propose une décomposition des applications en macro-structures (‘frameworks’) qui s'appuient sur des micro-structures (‘design patterns’) réutilisables et composées de classes d'objets pré-développées. L'équipe de C. Rolland [ROL 93] [CAU 96] prolonge ces approches dans deux directions en proposant une intégration plus forte des aspects dynamiques et en introduisant une réutilisation de connaissances sur les domaines d'application. Des catalogues de patrons sont aujourd’hui proposés [WHI 94, VLI 96] et diffusés. Le catalogue proposé dans [GAM 94] comporte vingt trois patrons pour la conception orientée objet des logiciels, il est à ce jour le plus représentatif et le plus formalisé. Pour E. Gamma [GAM 94], les quatre rubriques fondamentales pour documenter un patron sont : le nom du patron, la description du problème à résoudre, la solution tant statique que dynamique et les avantages de l’application du patron. La forme générale d’un patron est donnée dans la figure ci-dessous : Nom : le nom du patron ; Intention : le problème à résoudre ; Synonymes : les patrons similaires dans d’autres langages de patrons ; Motivation : un scénario d’application du patron, les problèmes particuliers ; Application : les situations dans lesquelles ce patron peut être utilisé ; Structure : une représentation graphique du patron utilisant la notation OMT ; Participants : décrit les classes et/ou les objets participants au patron et leurs responsabilités ; Collaborations : décrit comment les participants collaborent pour accomplir leur responsabilité ; Avantages : présente les apports du patron ; Implantation : les astuces et les conseils d'implantation ; Echantillon de code : fragments de code illustrant l’implantation du patron en C++ ou en Smalltalk ; Utilisations : des exemples d’utilisations réelles de ce patron ; Patrons Apparentés : d’autres patrons utilisés avec (ou par) celui-ci.

Figure 1 : Formalisme de description de patrons dans [GAM 94] Pour illustrer la notion de patron, nous présentons partiellement le patron de conception nommé ‘Composite’ dans [GAM 94]. Un patron similaire nommé ‘Compound Part-Part’ a été aussi proposé par P. Coad [COA 95].

Page 7

Nom : ‘Composite’ Intention : gérer une composition récursive d’objets. Motivation : Les éditeurs graphiques autorisent l’élaboration de figures composites à partir de figures simples et prédéfinies et ceci de manière récursive. Une solution consiste à définir une classe pour gérer les figures complexes et une classe pour gérer les figures élémentaires (texte, cercle, etc.). Dans ce cas, les objets simples sont traités différemment des objets composites ce qui alourdit les applications. F ig u re c o lo re r () tra c e r () a jo u te r(fig ) su p p rim e r(fig ) accéder

u n -C lie n t

uneF ig u r e

u n e F ig u r e C o m p o sé e

uneF ig u r e *

u n e F ig u r e S im p le

1 : c o lo r e r ( ) 1 ,n La solution proposée par le patron 2 : c o lo r e r ( ) 3 :c o lo r e r ( ) ‘Composite’ consiste à définir une classe abstraite (notée Figure) qui représente à la 4 : tra c e r () 5 : tra c e r () fois les objets composites et les objets C e rc le simples (ou feuilles). La classe Figure c o lo re r () F ig u re C o m p o sée c o lo re r () détient des opérations primitives telles que tra c e r () tra c e r () T ex te a jo u te r(fig ) tracer ou colorer mais aussi les opérations c o lo re r () su p p rim e r(fig ) tra c e r () accéder de gestion des composants (accéder, d ia g ra m m e s d ’in tera ctio n s m o d è le o b je t s ta tiq u e supprimer, ajouter un composant). Les sous-classes (Cercle, Texte, etc.) implantent les primitives graphiques telles que colorer ou tracer pour colorer et tracer un cercle, un texte, etc. La classe FigureComposée réalise elle aussi les opérations colorer et tracer par des appels récursifs aux opérations de ses composants : pour colorier une figure composée, il faut colorier toutes les figures (simples ou composées) qui la composent.

Structure et Participants: Composant

• Composant : définit l’interface commune des objets feuille et composite.

Client

Opérationspécifique () Ajouter(Composant) Supprimer(Composant) Accéder()

1,n

composants

• Feuille : définit le comportement des objets feuilles. • Composite : définit le comportement des objets composites et implante les opérations de gestion des composants. • Client : manipule les objets feuilles composites à travers l’interface Composant.

et

Feuille Opérationspécifique ()

pour tout c de composants c.Operationspécifique

Composite Opérationspécifique () Ajouter(Composant) Supprimer(Composant) Accéder()

Conséquences : • définit des hiérarchies de classes d’objets simples et d’objets composites ; • simplifie l’usage de ces objets pour le client qui peut les manipuler uniformément ; • facilite l’ajout des nouveaux composants.

3.4 Réutilisation de patrons pour le développement de SIP La réutilisation de patrons peut être mise en œuvre dans toutes les étapes du cycle de développement des SIP. Cette approche s’avère possible et intéressante pour les raisons suivantes : • La diversité des intervenants. Dans l’entreprise industrielle, l’information technique est destinée à une multitude d'acteurs dont les métiers, les connaissances et les rôles sont bien différenciés : chef de projet, responsable du bureau d'étude, responsable de l'industrialisation, projeteur, dessinateur, préparateur code numérique, ingénieur de calculs, Page 8

etc. Une approche à base de patrons permet de capitaliser sous une forme personnalisée, l'ensemble des problèmes et des solutions relatives à chaque métier. •

La maturité du domaine de la conception des SIP. Une approche à base de patrons peut être développée uniquement pour des disciplines mâtures. Il s’agit de disciplines pour lesquelles il existe d’une part, un consensus établi par une communauté d’acteurs autour d’un ensemble fini de problèmes et d’autre part, une variété de solutions connues pour résoudre ces problèmes. Le domaine de l’ingénierie des SIP répond à ce besoin. En effet, il existe déjà des cadres de référence terminologiques et des guides de procédures standard. Cependant une grande partie de cette connaissance reste dispersée à travers les praticiens de ce domaine et un effort d’acquisition et de représentation de celle-ci serait très utile pour développer rapidement de nombreux SIP.

• La documentation de l’architecture des SIP. La plupart des constructeurs de SGDT, offrent des bibliothèques de composants logiciels qui facilitent l’implantation d’un SIP. Ces bibliothèques sont peu ou mal utilisées, non parce que les artefacts qu'elles implantent sont trop éloignés des objets à implanter mais parce qu'elles sont peu ou mal documentées. Par ailleurs, la plupart de ces bibliothèques sont organisées en fonction des solutions qu'elles offrent et non des problèmes qu'elles résolvent. Il en résulte des logiciels produits difficiles à comprendre et à faire évoluer. En développant un SIP à partir de patrons, on documente de manière systématique le SIP, d’une part, et on facilite l’identification de nouveaux patrons, d’autre part. • L’homogénéité des composants réutilisables. La notion de patron peut être vue comme un concept générique (indépendant d’un domaine, indépendant d’un langage) que l’on peut utiliser pour décrire de manière homogène et modulaire des formes de composants très variées. La notion de patron peut être utilisée, par exemple pour décrire à la fois des problèmes (et les solution associées) de conception logicielle et des problèmes (et les solutions associées) de métier. Dans ces deux exemples, seule la nature du problème est différente. Il semble possible de proposer un cadre méthodologique pour la conception de SIP dans lequel le concept de patron peut être utilisé aux différents niveaux du développement (patrons métier, patrons de conception logicielle, patrons de dérivation ....).

4. Vers un cadre méthodologique pour les SIP basé sur les patrons 4.1 Patrons métiers, patrons processus Le cadre méthodologique que nous proposons repose sur un ensemble cohérent de modèles de différents niveaux d'abstraction pouvant être élaborés par réutilisation de patrons. Chaque niveau proposé doit permettre la résolution d’une problématique (problème de nature conceptuelle, organisationnelle, technique, etc.) particulière du développement de SIP. Comme pour la conception de systèmes d'information de gestion [NAN 96] [ESP 97], la conception de SIP peut être appréhendée selon au moins deux grands niveaux de préoccupation, d'une part un niveau organisationnel conduisant à spécifier le système d'information organisationnel (SIO) et auquel seront associés des patrons dit "métiers" et d'autre part, un niveau technique (informatique) concernant à spécifier la partie de ce SIO qui

Page 9

donnera lieu à informatisation, c'est le système d'information informatisé (SII) et qui conduira à spécifier et réutiliser des patrons dit "logiciels". • Au niveau organisationnel, les patrons métiers sont très importants, notamment dans les étapes d'expression des besoins et de définition de spécification fonctionnelle. Ils doivent pouvoir prendre en compte un ensemble de besoins informationnels associés d'une part aux différents processus industriels de conception, fabrication, production, qualité, etc. et d'autre part à différents métiers et donc acteurs humains qui ont à coopérer dans la réalisation de ces processus. Notons que ces acteurs peuvent être internes à l'organisation industrielle considérée mais aussi externes, comme dans le cas de la sous-traitance voire d'une entreprise étendue ou virtuelle. Dans la définition du niveau organisationnel, deux formes de modélisation sont essentielles : la modélisation des produits et la modélisation des processus [HAR 97]. Concernant la modélisation des produits, il s’agit d’utiliser et d’adapter les solutions de modélisation relevant de l’ingénierie des systèmes d’information. Des adaptations sont nécessaires pour prendre en compte le cycle de vie des produits à travers les différents processus de conception, fabrication,... et l’évolution des produits à travers des changements (notion de versions de produits). Concernant la modélisation des processus nous nous inspirerons tout d'abord des travaux relevant du génie industriel et plus particulièrement de la modélisation et l'intégration d'entreprise [LAD 95] [VER 96], ainsi que des nouvelles techniques d’organisation de type BPR (Business Process Reengineering) [JAC95] mais aussi de travaux réalisés dans le domaine de l’ingénierie des processus en systèmes d’information [ROL96]. Ce domaine propose des modèles de processus permettant la représentation de processus de « workflow »), mais aussi des modèles de processus plus riches intégrant notamment la notion de décision [ROL 93] [ROS 91] [JAR 92]. Un modèle de processus orienté décision est utile pour représenter des processus industriels qui par nature résultent de décisions prises par des acteurs. La nature coopérative de ces processus industriels devra aussi être prise en compte dans le modèle de processus proposé. • Au niveau technique, la définition des patrons logiciels est fortement liée aux SGDT qui sont à la base du développement des SIP. La généricité d'une modélisation à partir de patrons logiciels provient de son indépendance vis à vis d’un SGDT. Cette modélisation est l’expression d’une solution technique qui prend en compte deux problèmes essentiels, celui de l’implantation des modèles de produits et de processus et celui de la communication du SIP avec d’autres systèmes. Concernant l’implantation des modèles de produit et de processus, les SGDT utilisent des modèles de bases de données (relationnelles ou objet) et des modèles de « workflows ». Dans les deux cas, les modèles proposés dans les outils sont largement utilisés et peuvent donc être intégrés dans le cadre méthodologique proposé. Concernant la modélisation des échanges entre le SIP et d’autres systèmes, l’approche format-syntaxe telle celle proposée dans Step/Express [ARB 94].peut être utilisée. Bien qu’un certain nombre de travaux aient été déjà réalisés dans le domaine de l’intégration sémantique, l’intégration format-syntaxe nous semble dans le cas des SIP suffisante. La définition et la spécification de patrons logiciels associés aux SIP, s’appuient sur les fonctionalités proposées par la plupart des SGDT [RIE 97] et les catalogues de patrons de conception déjà disponibles en génie logiciel [GAM 94] (cf. chapitre 3). En ce qui concerne les patrons "métiers", intervenant principalement en expression des besoins et dans la définition de spécifications fonctionnelles du SIP, il s'agit de les identifier à partir de l'activité du domaine. Dans cette section nous nous intéressons à l'identification de patrons métiers ainsi qu'à leur spécification en nous inspirant de celle des patrons logiciels de Gamma. Page 10

4.2 Identification et spécification de patrons métiers Les patrons métiers fournissent les descriptions des produits et des processus qui devront être gérés par le futur SIP. Ces descriptions expriment en grande partie la sémantique du domaine. On distingue deux types de patrons métiers: les patrons Produits fournissant des modèles de structuration de produits avec leurs documentations et les patrons Processus fournissant des modèles de description de processus incluant les rôles des acteurs. Actuellement nous nous intéressons essentiellement à l’étude des patrons Produits. Pour illustrer la particularité de cette classe de patrons, nous considérons à nouveau le patron ‘Composite’ développé au paragraphe précédent. Il s'agit typiquement d'un patron réutilisable dans la plupart des domaines d'application. Cependant, en fonction des sémantiques de composition utilisées dans un domaine particulier, ce patron peut être particularisé. En effet, de nombreux travaux [OUS 97] ont montré qu'il n'existe pas une sémantique unique de composition d'objets. Un composant peut ou non dépendre existentiellement et fonctionnellement de son composite. Des propriétés du composite (resp. du composant) peuvent ou non être diffusées vers ses composants (resp. son composite). Un composant est ou non partageable par plusieurs composites, etc. Les SIP sont une source inépuisable de telles sémantiques. D’autant plus qu'un produit peut être décrit selon différents points de vue [TOL 95] : le point de vue structurel, le point de vue fonctionnel, le point de vue géométrique, le point de vue hydraulique, etc. Chaque point de vue peut être modélisé par une structure de composition: une fonction est composée de sousfonctions, un composant structurel contient des éléments structurels, etc. Cependant les sémantiques de la structure de composition varient d'un point de vue à l'autre. Parfois même un même point de vue peut utiliser plusieurs structures de composition avec des sémantiques différentes. De plus, des liens inter-représentation doivent être exprimés pour maintenir la cohérence entre les différents points de vue, c’est par exemple le cas entre les éléments structurels composant un produit et les fonctions qu’il doit assurer. L’identification et la spécification de patrons métiers doit nécessairement s’appuyer sur une analyse de domaine permettant d’établir un cadre de référence terminologique pour le domaine.

4.3 Un exemple de patron métier pour le domaine des SIP en conception mécanique Cette section présente le patron métier ’Structure et Fonction’ relevant d’un problème de conception mécanique. On définit d’abord, à travers un exemple, le contexte d’utilisation de ce patron, puis le patron est spécifié de manière détaillée. 4.3.1 Contexte d’utilisation du patron. En conception mécanique, le responsable d'un bureau d'étude manipule conjointement la représentation fonctionnelle et la représentation structurelle des produits. La Figure 2 présente sous forme de graphes les décompositions fonctionnelle et structurelle d’un compresseur [TOL 95]. Le graphe fonctionnel est un arbre d’éléments fonctionnels dont les feuilles sont des liaisons mécaniques à réaliser. Le graphe structurel est un graphe sans cycle dont les feuilles sont des pièces. Outre les liens de composition, sont également spécifiés les liens

Page 11

fonction / structure : une fonction peut nécessiter plusieurs éléments structurels pour être assurée, un élément structurel peut contribuer à assurer plusieurs fonctions.

Compresseur structurel

Compresseur

Composant mécanique

Vilebrequin

Comprimer Air

Variation volume chambre

Etancher chambre

Motoriser arbre entrée

Piston

Bâti

Pivot vilebrequin / bâti D

Transformer rotation / translation

Pivot vilebrequin / bielle C

Pivot glissant piston / bielle B

Accoupler moteur / arbre

Pivot glissant piston / bâti A

décomposition structurelle

Distribuer Air

Bielle

Moteur

décomposition fonctionnelle

fonction

élément structurel

lien de composition lien fonction/ structure

Figure 2 : Modélisation au plus haut niveau d’un compresseur Focalisons nous à présent sur la fonction mécanique « Transformer rotation / translation » qui permet le déplacement du piston (Figure 3). Les éléments technologiques (par exemple Elt-Vil D4) matérialisant chacune des liaisons (par exemple Pivot vilebrequin / bâti D) sont reliés par des liens de composition aux pièces (par exemple Vilebrequin 4) de la décomposition structurelle et par des liens fonction/structure aux liaisons à réaliser. Par exemple « Ele-Vil C4 » est un maneton constitutif du vilebrequin tandis que l’élément « Ele-Bie C6 » est un alésage de la bielle. Ils constituent les éléments mâle et femelle de la réalisation de la liaison « Pivot vilebrequin / bielle C ».

Page 12

Compresseur structurel

Composant mécanique

Vilebrequin 4

Transformer rotation / translation

Elt-Vil D4

Piston 7

Bâti 2

Elt-Bie C6 Elt-Car D2

Pivot vilebrequin / bielle C

Elt-Vil C4 Elt-Pis A7 Elt-Car A2

Pivot glissant piston / bâti A

décomposition structurelle

Pivot vilebrequin / bâti D

Bielle 6

Elt-Bie B6

Pivot glissant piston / bielle B

Elt-Pis B7

décomposition fonctionnelle

fonction

lien de composition

élément structurel

lien fonction/ structure

Figure 3 : Modélisation de la réalisation des liaisons La modélisation précédente permet de construire le graphe de contact associé aux composants mécaniques du compresseur (cf. Figure 4). pivot vilebrequin / bielle B

Elt-Bie C6

Elt-Vil C4 Bielle 6

Vilebrequin 4

Elt-Bie B6

pivot glissant piston / bielle B

Elt-Vil D4 Elt-Pis B7

pivot vilebrequin / bâti D

Piston 7

Elt-Car D2

Elt-Pis A7 Bâti 2 Elt-Car A2

pivot glissant piston / bâti A

Figure 4 : Graphe de contact des composants mécaniques du compresseur Cette modélisation permet la prise en compte explicite des éléments fonctionnels et structurels mis en jeu. La décomposition des fonctions en sous-fonctions s’arrête par la mise en évidence des liaisons à réaliser. La décomposition structurelle s’arrête sur des éléments technologiques constitutifs des pièces et réalisant les liaisons. Nous appelons « pièce-usinée » un élément structurel terminal associant une pièce disponible dans une nomenclature de pièces et des éléments technologiques réalisant les liaisons dans lesquelles intervient la pièce et conformes à la nomenclature d’éléments technologiques (Figure 5).

Page 13

Elt-Pis B7 Piston 7

élément technologique - participant à la réalisation d’une liaison - conforme à un élément technologique existant dans une nomenclature d’éléments technologiques

pièce existante dans une nomenclature de pièces

Elt-Pis A7

Figure 5 : Un exemple de pièce usinée Cette approche est applicable dans un bureau d’étude quelque soit le mécanisme à concevoir. Le responsable d’un bureau d’étude décompose fonctionnellement et structurellement son produit de manière à identifier et caractériser les pièces à usiner. 4.3.2 Spécification du patron métier. Nous fournissons dans cette partie la spécification du patron ‘structure et fonction’ associé au contexte de conception mécanique précédent. Pour spécifier ce patron SIP, nous avons retenu le formalisme de E. Gamma [GAM 94] auquel nous avons ajouté les caractéristiques Domaine et Destination indiquant respectivement le domaine d'application du patron et les acteurs du SIP concernés par ce patron. Nous utilisons pour cette spécification le formalisme UML [UML 97] [MUL 97]. Nom : ‘Structure et Fonction’ Classification : Produit Domaine : Conception mécanique Destination : Bureau d’étude Intention : Le patron ‘Structure et Fonction’ permet au responsable du bureau d’étude d’utiliser et de représenter les décompositions fonctionnelle et structurelle d'un produit mécanique de manière, d'une part, à traiter des composants individuels (pièces et liaisons) ou des compositions d’objets (structures et fonctions) uniformément et d'autre part, à autoriser l'expression des réalisations des liaisons par des éléments technologiques entrant dans la constitution des pièces. Motivation : Le SIP doit permettre d’élaborer les représentations fonctionnelles et structurelles de mécanismes. A chaque niveau de décomposition il utilise des objets simples et prédéfinis mais aussi des objets composites déjà élaborés. Le niveau terminal de décomposition est atteint lorsque chaque liaison (élément fonctionnel de bas niveau) est réalisée. Application : Utiliser le patron ‘Structure et Fonction’ pour modéliser les représentations structurelle et fonctionnelle d’un produit et les liens entre elles de manière à identifier les pièces du mécanisme et les éléments technologiques dont elles devront être dotées. Ce patron est également utilisable si seule la décomposition structurelle est pertinente. La décomposition fonctionnelle peut être inutile pour des produits non innovants. Structure et Participants: La structure de ce patron est construite à partir de spécialisations des patrons ‘Composite’ (décrit dans la partie 3) et du patron ‘Nomenclature’ non présenté ici. La Figure 6 présente la structure du patron.

Page 14

gestion de la structure

1,1

Mécanisme graphe-contact () usiner (piece-usinee, elt-tech) ajouter-s (composant, composé) supprimer-s (composant, compose) accéder-s ()

1,1

gestion de la fonction

gestion des liens fonction / structure (contrôlés par les fonctions)

Structure

ajouter-f(composant, compose) supprimer-f (composant, compose) accéder-f () réalise-par (fonct, struct) elt-technique-mâle (liaison, elt-tech) elt-technique-femelle (liaison, elt-tech)

graphe-contact () usiner (elt-tech) 1,n ajouter (compose) supprimer (compose) accéder ()

réaliser-par

1,n

Fonction ajouter (compose) supprimer (compose) accéder () réaliser-par (struct) elt-technique-mâle (elt-tech) elt-technique-femelle (elt-tech)

Figure 6 : Classes Abstraites définissant les interfaces des mécanismes, des éléments structurels et des éléments fonctionnels Un mécanisme est lié à la racine fonctionnelle et structurelle de ses graphes de décomposition. Les classes composant la structure du patron sont : • Mécanisme : classe modélisant des types de produits. Elle définit l’interface commune des produits en particulier les méthodes permettant de manipuler fonctionnellement et structurellement un produit, d’usiner les pièces (feuilles du graphe de décomposition structurelle), de réaliser les liaisons (feuilles de la décomposition fonctionnelle). Elle détient également des opérations plus spécifiques telle que graphe-contact () qui réalise l’affichage du graphe de contact (Figure 4). • Structure : classe modélisant les éléments structurels. Elle définit l’interface commune des éléments structurels en particulier les méthodes permettant de manipuler structurellement un produit, d’usiner les pièces et d’afficher le graphe-contact. • Fonction : classe modélisant les fonctions. Elle définit l’interface commune des éléments fonctionnels en particulier les méthodes permettant de manipuler fonctionnellement un produit et de matérialiser ses liaisons (par des éléments techniques mâle et femelle). Le lien réaliser-par lie une fonction aux éléments structurels participant à sa réalisation. La mise à jour de ce lien est guidé par la fonction (méthode réaliser-par). De même les fonctions élémentaires (les liaisons) sont liées aux éléments techniques mâle et femelle les matérialisant (méthodes elt-technique-mâle et elt-technique-femelle). Ceci permet une adaptation rapide du patron pour les bureaux d’étude ne s’intéressant qu’à une décomposition structurelle.

La structure du patron ‘Structure et Fonction’ met en évidence, à un second niveau, les modélisations de la décomposition structurelle (Figure 7) et de la décomposition fonctionnelle (Figure 8).

Page 15

a) Décomposition structurelle La solution présentée sur la Figure 7 correspond à la combinaison d’une spécialisation du patron ‘Composite’ et du patron ‘Nomenclature’. Sur la Figure 7 les parties grisées font référence au patron ‘Nomenclature’. Mécanisme graphe-contact () usiner (piece-usinee, elt-tech) ajouter-s(composant,composé) supprimer-s (composant compose) accéder-s()

1,1

N-ElémentTechnique code-N

0,n Structure

1,n

graphe-contact () 1,1 usiner (elt-tech) ajouter (compose) supprimer (compose) accéder()

0,n N-Alésage diam-min diam_max

{disjoint, incomplet}

Alésage {disjoint, complet}

1,1 1,n

Maneton

diamètre

voir Nomenclature

Pièce-Usinée

Structure-Composée graphe-contact () usiner (elt-tech) ajouter(struct) supprimer (struct) accéder

graphe-contact () usiner (elt-tech) choix-piece (piece)

N-Maneton

ElémentTechnique

N-Pièce 1,1

codeP

1,n {disjoint, incomplet}

Bielle

Vilebrequin

Piston

Figure 7: Graphe des classes modélisant la décomposition structurelle Outre la classe Structure, la décomposition structurelle met en jeu les classes suivantes : • Structure-Composée : classe des éléments structurels composites. Elle implante les méthodes de gestion du graphe structurel (ajout, suppression d’un composant, accès aux composants). Les méthodes graphe-contact et usiner réalisent un appel récursif des méthodes de même nom aux composants. • Pièce-Usinée : classe des éléments structurels feuilles. Une pièce usinée est liée à des éléments techniques (exemple Elt-Vil D4) et à une pièce (exemple Vilebrequin 4). • N-Pièce : racine de la nomenclature des pièces mécaniques traitée par le patron ‘Nomenclature’. • Elément-Technique : racine des classes d’éléments techniques utilisés dans les pièces usinées. Chaque instance correspond à une réalisation d’un élément technique (d’un type d’alésage par exemple). Un alésage particulier aura par exemple une valeur de propriété diamètre qui devra être conforme au type d’alésage correspondant (diam_min < diametre < diam_max). • N-Elément-Technique : racine de la nomenclature des éléments techniques (patron ‘Nomenclature’).

b) Décomposition fonctionnelle La solution représentée sur la Figure 8 fait référence à l’unique patron ‘composite’.

Page 16

Mécanisme graphe-contact () usiner (piece-usinee, elt-tech) ajouter-s(composant,composé) supprimer-s (composant, compose) accéder-s()

Fonction ajouter(fonct) supprimer (fonct) 1,1 accéder () elt-technique-mâle (elt-tech) elt-technique-femelle (elt-tech) réaliser-par (struct)

ajouter-f(composant, compose) supprimer-f (composant, compose) accéder-f () elt-technique-mâle (liaison, elt-tech) elt-technique-femelle (liaison, elt-tech) réaliser-par (fonct, struct) 1,1 1,1

Pièce-Usinée usiner (elt-tech) graphe-contact () choix-piece (piece) 1,1

Liaison réaliser-par (pièce-usinée) elt-technique-mâle (elt-tech) elt-technique-femelle (elt-tech) ajouter(fonct) supprimer (fonct accéder ()

1,n

Fonction-Composée réaliser-par(struct) ajouter(fonct) supprimer (fonct) accéder ()

élément-femelle 1,1 Elémentélément-mâle Technique 1,1

0,n

Figure 8 : Graphe des classes modélisant la décomposition fonctionnelle Outre la classe Fonction, la décomposition fonctionnelle met en jeu les classes suivantes: • Fonction-Composee : classe des fonctions composites. Elle implante les méthodes de gestion de l’arbre fonctionnel (ajout, suppression d’un composant, accès aux composants). • Liaison : classe des éléments fonctionnels feuilles. Une liaison (par exemple Pivot vilebrequin / bâti D) est liée aux éléments techniques constitutifs des pièces usinées (méthodes elt-technique-mâle et elt-techniquefemelle). Une liaison est réalisée par une pièce-usinée (méthode réaliser-par redéfinie ; le paramètre d’entrée est une pièce usinée). Collaboration : Les collaborations dans les graphes de composition sont régies par le patron ‘Composite’. Certaines collaborations sont inter-graphes. C’est par exemple le cas d’une demande de graphe de contact. Le mécanisme transmet la demande à la racine de sa représentation structurelle qui si elle est composite la transmet à ses éléments jusqu’à atteindre les pièces usinées. Chaque pièce usinée transmet l’ordre d’affichage à : • sa pièce, • ses éléments techniques, • sa liaison (lien réalier-par). Pour simplifier, ces méthodes d’affichage élémentaires ne sont pas mentionnées dans les modèles. Conséquences : • définit les représentations structurelles et fonctionnelles des mécanismes. Ces représentations sont destinées au responsable du bureau d’étude, • gère les liens entre elles (lien réaliser-par, liens gérant les éléments mâle et femelle des liaisons), • permet au responsable du bureau d’étude de manipuler ses objets uniformément, • facilite l’ajout des nouveaux composants.

Page 17

Patrons apparentés : • Deux utilisations du patron ‘Composite’, • Deux utilisations du patron ‘Nomenclature’, • Possibilité de combiner ce patron avec le patron ‘Etat’ de E. Gamma pour modéliser l’évolution du produit ou de ses représentations, • Dans le cas d’évolutions multiples (graphes d’états concurrents), utiliser le patron ‘Rôle’ [RAN 97].

5. Conclusion La réutilisation, déjà efficace en génie logiciel, pourrait l’être également au niveau de la spécification et de la réalisation de SIP. Pour mettre en œuvre cette réutilisation, nous nous sommes placés dans une approche de capitalisation et de réutilisation des acquis en terme de modèles de produits et de processus. Nous avons proposé un cadre méthodologique basé sur la réutilisation de patrons. Des patrons doivent être définis pour couvrir la totalité du cycle de développement d’un SIP. Les travaux présentés dans ce papier concernent les patrons métiers mis en œuvre principalement dans les étapes d’expression des besoins et de spécification fonctionnelle. Leur identification nécessite une analyse de domaine en collaboration avec les experts de cette discipline. Cette analyse de domaine est en cours en collaboration avec nos partenaires industriels, Schneider Electric et PCO Tehnologies. Elle s’appuie sur une étude déjà réalisée qui établit, sur la base d’expériences, un cadre de référence terminologique. Cette analyse devrait aboutir à un véritable catalogue de patrons pour le domaine de l’ingénierie des SIP. Le développement de SIP basé sur le concept de patron remet en cause toute démarche traditionnelle de développement. L’utilisation de patrons devrait par exemple conduire le concepteur de SIP à exprimer des problèmes (par opposition à une démarche traditionnelle où le concepteur doit fournir des solutions) ; les solutions étant fournies par les patrons. Dans ce contexte il devient nécessaire de proposer une nouvelle démarche de développement de SIP intégrant de manière systématique la réutilisation de patrons. Une telle démarche doit s’appuyer sur une représentation informatique des patrons et sur des mécanismes pour en assurer la recherche, la sélection et l’adaptation.

6. Remerciements Les auteurs tiennent à remercier Stéphane Guignard de la Société PCO Technologies et Paola Conforti de la Société Schneider Electric pour leur collaboration.

Références [ALE 77]

C. ALEXANDER, S. ISHIKAWA, M. SILVERSTEIN, and al.. A Pattern Language, Oxford University Press, New York, NY, 1977.

[ALE 79]

C. ALEXANDER. The Timeless Way of Building, Oxford University Press, New York, NY, 1979.

[APP 97]

B. APPLETON. Patterns and Software , Essential Concept and Terminology, http://www.enteract.com/~bradapp/docs/patterns-intro.html. Page 18

[ARB 94]

S. ARBOUY, A. BEZOS & al. STEP : Concepts fondamentaux. AFNOR 1994.

[AIT 97]

E.J. WAITE. AIT - Advanced Information Technology for Design and Manufacture, Proc. ICEIMT’97 International Conference on Entreprise Integration and Modeling Technology, Eds. K. Kosanke, J.G. Nell, 1997.

[BEC 87]

K. BECK, W. CUNNIMGHAN. Using Pattern Languages for Objet-Oriented Programs, OOPSLA-87, 1987.

[BUC 96]

F. BUCHMANN, R. MEUNIER, & al. Pattern-Oriented Architecture. A System of Patterns, WILEY & Sons, 1996.

[CAU 96]

C. CAUVET, F. SEMMAK,.Semantic units and connectons: towards domain knowledge reuse, Proc. of the IFIPW.G.8 Conference Domain Knowledge for Interactive system Design, Geneve, Switzerland, 1996.

[COA 92]

P. COAD. Object-Oriented Patterns, Communication of ACM, Vol 35 n° 9, Sep. 92.

[COA 95]

P. COAD, D. NORTH, M. MAYFIELD. Object Models Strategies Patterns & Applications, Yourdon Press Computing Series, 1995.

[COP 96]

J. O. COPLIEN. Software Design Pattrens : Common Questions and Answers, http://st-www.cs.uiuc.edu/users/patterns/.

[ESP 97]

B. ESPINASSE, D. NANCI. Merise et l’approche orientée objet : du couplage avec OMT à une troisième génération, Revue Ingénierie des systèmes d’information, Hermes, Vol 5, N° 4, Octobre 1997.

[FOW 97]

M. FOWLER. Analysis Patterns, Reusable object models, Addison-Wesley, 1997.

[FUK 93]

A. FUKANAGA, W. PREE, T. KIMURA. Functions as data objects in a data flow based visual language, ACM Computer Science Conference, Indianapolis, 1993.

[GAM 94]

E. GAMMA, R. HELM, R. JOHNSON, J. VLISSIDES. Design Patterns : Elements of Object Oriented Software Architecture, Addison-Wesley, 1994.

[HAR 97]

Y. HARANI. Une approche multi-modèles pour la capitalisation des connaissances dans le domaine de la conception, thèse de doctorat de l’INPG Grenoble, 1997.

[JAC 95]

I. JACOBSON, M. ERICSSON, A. JACOBSON, The object advantage : Business Process Reegineering with object technology, Addison Wesley, 1995.

[JAR 92]

M. JARKE, J. MYLOPOULOS, J.W. SCHMIDT, Y. VASSILIOU, DAIDA An environnement for evolving information systems, ACM TOIS, vol 10, n°1, 1992.

[JOH 93]

R. JOHNSON. How to design frameworks, Tutorial Notes, OOPSLA'93, 1993.

[LAD 95]

P. LADET, F. VERNADAT. The dimensions of Integrated Manufacturing Systems Engineering. Integrated Manufacturing Systems Engineering, Ed. P. Ladet, F. Vernadat, Chapman & Hall, 1995.

[MAD 89]

P.W. MADANY, R.H. CAMPBELL, V.F. RUSSO, D.E. LEYE NS. A Class Hierarchy for building Stream-oriented file systems, In Proc. Of the ECOOP’89 Conference, Nottingham, UK, 1989.

[MUL 97]

P.A. MULLER, Modélisation Objet avec UML, éditions Eyrolles, 1997.

Page 19

Software

[NAN 96]

D.NANCI, B.ESPINASSE et al., Ingénierie des systèmes d'information : Merise deuxième génération, Sybex, 1996.

[OPA 97]

OPAL, Integrated Information and Process Management in Manufacturing Engineering, Esprit 4 Project, 1997.

[OUS 97]

M. OUSSALAH, J.P. GIRAUDIN, F. BOUNAAS, D. RIEU, & al. Ingénierie des objets : Concepts, techniques et méthode,s. InterEditions, Mai 1997

[PIS 94]

PISA, Platform for Information-Sharing by CIME Applications, Esprit 3 Project, 1992-1994.

[POU 95]

J.S. POULIN. Populating Software Repositories : Incentives and Domain Specific Software, Journal of Systems Software, 30, pp 187-199, 1995.

[RAN 97]

H. RANDRIAMPARANY. Les Patrons Orientés Objets : définition et utilisation, DEA Systèmes d'Information MATIS, Grenoble, Juin 97.

[RAN 95]

J.M. RANDOING. Les SGDT, Editions Hermes, 1995.

[RIE 97]

D. RIEU, M. TOLLENAERE et al. Patrons d’Objets pour les SGDT, 2ème congrès international Franco-Québécois : le génie industriel dans un monde sans frontières , 3-5 Septembre 1997.

[RIS 97]

RISESTEP, Enterprise Wide Standard Access to Step Distributed Databases, Esprit 4 Project, 1996-1998.

[ROL 93]

C. ROLLAND. Modeling the Requirements Engineering Process, Proc. FinoJapanese Seminar on Conceptual Modeling, 1993.

[ROL 96]

C. ROLLAND. L’ingénierie des processus de développement de systèmes : un cadre de référence. Revue Ingénierie des Systèmes d’Information, Hermes,vol 4, n°6, 1996.

[ROS 91]

T. ROSE, M. JARKE, M. GOCEK, C. MALTZAHN, H. NISSEN. A DecisionBased Configuration Process Environment, Software Engineering Journal, No 6,5, 1991.

[SCH 95]

H. ALBRECHT SCHMID. Creating the architecture of a manufacturing framework by design patterns, OOPSLA 1995.

[SCH 97a]

T. SCHAEL. Théorie et pratique du Workflow, Des processus métier renouvelés, Springer-Verlag, 1997.

[SCH 97b]

T. SCHAEL. Cooperative Process and Workflow Management for Enterprise Integration, Proc. of ICEIMT’97, International Conference on Entreprise Integration and Modeling Technology, Eds. K. Kosanke, J.G. Nell, Spriger Verlag 1997.

[SCH 97c]

A.-W. SCHEER, R. BOROWSKY, S. KLABUNDE, A. TRAUT. Flexible Industrial Applications Through Model-Based Workflows, Proc. of ICEIMT’97, International Conference on Entreprise Integration and Modeling Technology, Eds. K. Kosanke, J.G. Nell, Springer Verlag1997.

[SDR 96]

SDRC, Metaphase, http://www.sdrc.com/nav/software-services/metaphase/

[TER 92]

G. DE TERSSAC, P. DUBOIS. Les nouvelles rationnalisations de la production, Cépadués-Editions,1992.

[TOL 95]

M. TOLLENAERE. Modélisation objet pour la CFAO : modèle de conception, projet Shood, Rapport de fin de contrat 1995, Région Rhône-Alpes, Pôle Productique. Page 20

[UML 97]

Unified Modeling Language, Version 1.0, January 97 , Rational Software Corporation. Http ://www.rational.com.

[VER 94]

F. VERNADAT. Future R&D Directions for CIM Deployment,, European Workshop on Integrated Manufacturing Systems Engineering, Grenoble, France, dec 12-14, 1994, pp. 3-6.

[VER 96]

F. VERNADAT. Enterprise Modelling and Integration : Principles and Applications,. Chapman & Hall Ed, 1996.

[VLI 96]

J. M. VLISSIDES, J. O. COPLIEN, AND N. L. KERTH. Pattern Languages of Program Design 2, Addison-Wesley. 1996.

[WEI 88]

A. WEINAND, E. GAMMA, R. MARTY. ET++ An Object-oriented Application Framework in C++, In OOPSLA’88, Special Issue of SIGPLAN Notices, 23(11), 1988.

[WHI94]

B.G. WHITENACK. RAPPel : a Requirement Analysis Process Pattern http://www.bellLanguage for Object Oriented development, labs.com/user/cope/Patterns/Process/RAPPeL/rappel.html

[WIL 90]

D.A. WILSON, L.S. ROSENSTEIN, D. SHAFER. Programming with MacApp, Reading, Massachusetts, Addison-Wesley.

___

Page 21