Une approche à base de composants pour la modélisation des procédés logiciels

Transcription

1 Une approche à base de composants pour la modélisation des procédés logiciels Ma. Lizbeth GALLARDO DEA préparé dans l équipe ADELE, au laboratoire LSR Soutenance à Grenoble, Le 20 Septembre Responsable du stage : Noureddine BELKHATIR, Maître de Conférences UPMF Grenoble Responsable de formation DEA : Marie-France BRUANDET, Professeur à l UJF

2 Remerciements. Je tiens à remercier tout particulièrement : Jacky Estublier, responsable de l équipe ADELE, Directeur CNRS, pour m avoir accueilli dans son équipe. Noureddine Belkhatir, Maître de Conférences UPMF pour son encadrement, ses nombreux conseils et son soutien. L ensemble des personnes de l équipe ADELE de laboratoire Logiciel Systèmes et Réseaux. Manuel Aguilar, mon époux, par son amour si précieux et son soutien inconditionnel. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

3 Table des Matières 1. INTRODUCTION Problématique Contexte Contenu du document... 6 CHAPITRE 2. ETAT DE L ART Définitions de procédé et de support automatisé Communautés de procédés : procédé d affaires et procédé logiciel Les Environnements centrés procédés Définition L architecture Techniques d interopérabilité Définition de Composant Définition d Interopérabilité Interopérabilité par échange de donnés Interopérabilité sémantique : Vocabulaire commun Le schéma conceptuel procédé Interopérabilité par les données : Langage de traduction commun Interopérabilité par le contrôle WAPI4 (Workflow Application Programming Interface/Interchange 4) SWAP Jflow Wf - XML Le Modèle «Mission» : utilisation du protocole Wf-XML OZ Process wall APEL Approche par composant pour la modélisation des procédés Endeavors Pynode SPMS. Software Process Management System OPC. Open Process Components Framework SYNTHESE CHAPITRE 3. NOTRE APPROCHE Introduction Concepts Modèle Composant procédé Modélisation basée composants L exécution basée composants procédés Le vocabulaire commun Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

4 3.2.6 Le schéma conceptuel procédé Framework orienté objet L état procédé Classement hiérarchique Architecture de l Environnement Centré Procédé Modèle pour des Composants procédés Les cas d utilisation Scénarios principaux identifiés au travers des cas d utilisation Créer un composant procédé : Exécuter un composant procédé Contrôler l exécution d un composant procédé Abonner un observateur global externe Diagramme de transition d états Diagramme de classes Le patron Fabrication L Observateur global Le patron de façade Le ComposantMétaData Fonctionnement de la machine d'exécution : exemple...36 CHAPITRE 4 PROTOTYPAGE Modèle par composants procédés Dépendances L observateur global CHAPITRE 5. CONCLUSION ET PERSPECTIVES BIBLIOGRAPHIE Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

5 Table des illustrations Figure 1 : Procédé d'affaire: Traitement de dossiers de gestion de prêts bancaires...3 Figure 2 : Procédé logiciel: Cycle de vie du logiciel...4 Figure 3 : Architecture de référence pour les PSEE [Sch99]...5 Figure 4 : Schéma conceptuel...8 Figure 5 : PCIS LCPS Model [Der94]...9 Figure 6 : Modèle par langage canonique...10 Figure 7 : Interopérabilité par control (WAPI 4) [WfMC2-1]...11 Figure 8 : Modèle de procédés chaînés...12 Figure 9 : Modèle de procédés imbriqués...12 Figure 10 : Modèle de procédé parallèle...12 Figure 11 : Modèle de ressource logique...14 Figure 12 : Modèle pour une mission...16 Figure 13 : Hiérarchie de classes pour l'entité "procédé"...20 Figure 14 : Conception d'un procédé par composants...22 Figure 15 : Schéma conceptuel...24 Figure 16 : Les cas d'utilisation...26 Figure 17 : Diagramme de séquences : création d un composant procédé...27 Figure 18 : Diagramme de séquence : Exécution d un composant procédé...27 Figure 19 : Diagramme de séquence : Contrôle de l'exécution...28 Figure 20 : Diagramme de séquence : Abonnement un observateur...29 Figure 21 : Diagramme de transition d'états pour un composant procédé...29 Figure 22 : Diagramme de classes : Framework pour des composants procédés...30 Figure 23 : Diagramme de classes : Patron fabrication...31 Figure 24 : Diagramme de classes: L'observateur global...31 Figure 25 : Diagramme de classes: Méta données produits par un composant procédé...27 Figure 26 : Le schéma pour test...33 Figure 27 : Arbres illustrant la création et exécution des sous composants test...33 Figure 29 : Diagramme de séquences pour exécution de Test...34 Figure 30: Diagramme de séquence : interopérabilité entre des composants procédés...35 Figure 31 : Diagramme de transition d'état pour le composant test...35 Figure 32 : Fenêtre pour créer un modèle par composants...36 Figure 33 : Fenêtre pour remplir les dépendances entre composants...37 Figure 34 : Fenêtre pour observer cours de l'exécution des composants...38 Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

6 Chapitre 1. Introduction. Dans les années 1990 une équipe d ingénieurs a mis en avant le fait que les outils logiciels pouvaient être utilisés pour automatiser les procédures de travail impliquant la circulation de documents papier [SW92]. La gestion de flux de travaux est une technique de modélisation de procédés logiciels, qui est née de cette idée. Ainsi commence l étude des procédés dirigée principalement vers le développement de techniques et de mécanismes facilitant la modélisation et le support de procédés. Par procédé on désigne l ensemble des activités faisant intervenir de nombreux agents humains et outils ayant un but commun, la création et la maintenance d un produit ou la réalisation de services en respectant un ensemble de caractéristiques bien définies. Un modèle est la description abstraite des pratiques réelles concernant le déroulement des projets au sein d un groupe de travail ou d'une organisation. Plusieurs formalismes de représentation ont été proposés pour la modélisation de procédés. Les systèmes supportant l exécution de ces formalismes sont appelés environnements centrés procédés. 1.1 Problématique. Actuellement les procédés mis en œuvre dans notre société sont de plus en plus complexes et difficiles à gérer; la raison principale est l'évolution rapide des activités sociales et économiques durant les dernières décennies, en plus de la diffusion de la technologie de l information dans beaucoup de domaines» [Avr96]. En conséquence, la conception, l exécution et la maintenance des modèles pour ces procédés sont de plus en plus complexes. Nous nous interessons plus particulièrement aux procédés logiciels et à leur modélisation pour faire face à la complexité des procédés, la communauté génie logiciel propose leur construction en faisant coopérer plusieurs équipes (peut-être géographiquement distribuées). En considérant que chaque équipe peut avoir ses propres environnements de développement (formalismes de représentation, moteur procédé, bases de données etc.), les modèles fournis par ces équipes seront hétérogènes. Et malheureusement, les formalismes de représentation actuels liés à l infrastructure qui les supporte ne facilitent ni l interopérabilité, ni la réutilisation de modèles procédés exécutables. Comme nous le présentons dans l état de l art, les travaux cherchant à résoudre le problème de l interopérabilité sont nombreux. Une approche intéressante et récente consiste à appliquer la technologie des composants et objets au développement de procédés. Parmi ces travaux on trouve APEL et OZ, qui proposent une architecture par composants et Pynode, Endeavors et OPC, qui proposent une approche par composant au niveau modélisation. Les avantages attendus par l approche composant pour le support de procédés sont : Obtention d environnements de développement de logiciels coopératifs et ouverts Interopérabilité entre des composants hétérogènes (fédération de composants) Dépendances entre procédés délimitées, mieux reconnues et gérées Réutilisation des composants procédés Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

7 1.2 Contexte Notre domaine de recherche s inscrit dans une approche par composant pour le support automatisé aux procédés logiciels. Nous proposons un framework orienté objet permettant construire, exécuter et faire évoluer des modèles de procédés logiciels. Le contexte de ce travail est caractérisé par les aspects suivants : Approfondissement du concept de composant procédé logiciel. Etude des différentes techniques d interopérabilité. Les buts de notre travail sont : La proposition d un framework orienté objet pour le support de procédés qui permette : D'augmenter le potentiel de réutilisation des modèles de procédés fonctionnels, D'assurer l'interopérabilité entre des composants hétérogènes. L intégration dynamique de composants. La présentation des concepts et de la terminologie qui caractérisent la technologie de procédés. Le développement d un prototype pour valider nos idées, en utilisant des technologies actuelles telles que Java, XML, protocoles de communication comme CORBA, etc. 1.3 Contenu du document. Nous allons présenter dans le chapitre 2 l état de l art qui comprend plusieurs techniques d interopérabilité identifiées dans le domaine de procédés. Dans le chapitre 3, nous présenterons les concepts et la terminologie utilisés dans notre approche, ensuite le framework pour un composant procédé. Dans le chapitre 4, nous présenterons le prototype comprenant les interfaces de dialogue pour la création et gestion d un modèle par composants. Le chapitre 5 présentera les conclusions ainsi que les perspectives de ce travail. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

8 Chapitre 2. Etat de l Art 2.1 Définitions de procédé et de support automatisé. Par procédé on entend l ensemble des activités faisant intervenir des équipes de personnes (souvent nombreuses), des outils et des techniques pour assurer le développement et la maintenance de produits ou de services. Le support automatisé aux procédés correspond à l application de la technologie informatique pour assister et automatiser le travail d une organisation. 2.2 Communautés de procédés : procédé d affaires et procédé logiciel. On distingue deux communautés dans l étude de procédés : La communauté de procédé logiciel (Software process) et celle des procédés d affaires (Workflow). Les deux partagent le même objet d étude : le procédé ainsi que de l intérêt d accroître la connaissance autour de celui-ci mais ils diffèrent dans l approche initiale du problème. Dans les années 1990, une équipe d ingénieurs a mis en avant que les outils logiciels peuvent être utilisés pour automatiser les procédures de travail impliquant la circulation de documents papier [SW92]. La gestion des flux de travaux (workflow management système) est la technologie logicielle inspirée de cette idée. Elle permet de modéliser les procédures de travail et d en assurer la mise en œuvre. L approche adoptée par la communauté de procédés d affaire est pragmatique. Les recherches effectuées dans le domaine visent dès le départ l application pratique de cette nouvelle technologie dans des situations de travail réelles. On assiste alors aux développement de systèmes dédiés à la gestion des documents dans des organisations caractérisées par des procédés d affaires de type traitements de dossier. Pour illustrer cette approche, considérons par exemple le dossier de gestion de prêts dans une banque. La figure suivante montre l ensemble des activités nécessaires pour son traitement. Figure 1 : Procédé d'affaire: Traitement de dossiers de gestion de prêts bancaires Quand à la démarche adoptée par la communauté procédé logiciel, elle est plus orientée vers l étude de modèles pour les procédés que dans la production de systèmes directement exploitables. Les aspects technologiques étudiés se focalisent sur l élaboration d environnements destinés à supporter les modèles développés. Un exemple est le modèle en cascades [JCJ+93] de cycles de vie du Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

9 logiciel, la figure 2 illustre un procédé suivi pour le développement d un logiciel. Les flèches arrondis indiquent le flux d exécution des différents activités dans le développement du logiciel. Par exemple quand l activité Analyser le problème soit fini, l activité Concevoir la solution logiciel sera initiée. Si dans le développement de cet activité on trouve des erreurs, l activité analyser le problème sera appelé pour réaliser les corrections pertinents au modèle. Les flèches droits indiquent que tous les produits fournis par les activités seront validés, dans l activité Valider les modèles et l implémentation. Figure 2 : Procédé logiciel: Cycle de vie du logiciel Les principales différences entre les deux types de procédés peuvent être résumées de la manière suivante : Les procédés d affaires (Workflow) Travail sur l automatisation de procédés d affaires Ils sont stables. (la définition du procédé ne change pas fréquemment). Environnement industriels (WFMS) (Workflow Management Systems) Les procédés logiciel Travail sur l automatisation de procédés logiciels Sont relativement instables. (développement d activités peut être changé ou raffiné quand le procédé est en train de s exécuter) Produits universitaires (PSEE). (Process S/W Engineering Environment) Malgré les différences décrites auparavant, les orientations suivies par chacune des deux communautés ont permis de faire avancer en parallèle et de façon complémentaire les recherches sur les procédés. Peu à peu, les 2 courants se sont rapprochés, chacun intégrant les avancées de l autre dans son approche du problème. 2.3 Les Environnements centrés procédés Définition Un Environnement Centré procédé ( PSEE - Process Software Engineering Environment) est un système permettant de décrire explicitement et avec suffisamment de détails la manière de produire un logiciel. Cette description, appelée modèle du procédé, est exprimée dans un formalisme approprié appelé langage de modélisation de procédés [Ami99]. Pour le groupe de travail PROMOTER 2, un environnement de développement peut être qualifié de centré procédé si son architecture est basée sur un moteur de processus qui, par interprétation ou exécution du modèle de procédé, contrôlela Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

10 démarche de production en cours. L environnement peut en outre comporter des outils dédiés au suivi, à l analyse et à l évolution des modèles de procédés [Der94]. On peut trouver dans la littérature plusieurs études comparant les différentes PSEE développés en tant que prototypes de recherche, industriels ou systèmes commercialisés [Lon94], [CJ99]. Il ressort de ces travaux que la plupart de ces systèmes offrent les moyens de mener à bien l ensemble des activités relevants de l ingénierie du procédé. Toutes les étapes depuis la définition jusqu au support automatisé et à l évolution du procédé forment le cycle de vie du procédé, communément appelé Méta Procédé [Avr96] L architecture L identification des différents services de base que doit fournir un PSEE permet d élaborer un modèle de référence pour l architecture générale de ce type de systèmes [Sch99]. La figure 3 illustre les services : gestion des dialogues, des procédés, des espaces de travail et des bases de données. Ils sont organisés dans une architecture comportant quatre couches abstraites. Figure 3 : Architecture de référence pour les PSEE [Sch99] Tout PSEE doit permettre la gestion des dialogues afin d informer les utilisateurs sur le procédé et de leur permettre, sur la base des informations fournies, d effectuer leurs tâches. Le service de gestion des dialogues concerne directement l interface proposée à l utilisateur, qui doit par ailleurs correspondre directement au rôle de celui-ci. Via les informations gérées par ce service, l environnement répond en adéquation avec les besoins inhérents au rôle de l utilisateur. La gestion des processus est le service rendu par un PSEE qui fait référence à l exécution d un modèle de procédés donné. C est à ce niveau qu est gérée la coordination des activités concurrentes des divers acteurs impliqués. Par ailleurs, ce service «calcule» l espace de travail à fournir à l utilisateur, en fonction de l état du procédé en cours. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

11 Un espace de travail doit être consacré à chaque utilisateur en fonction de son rôle. Un service dédié à la gestion de ces espaces de travail permet de maintenir, pour chacun et à un instant donné, les éléments logiciels nécessaires et suffisants pour procéder à la réalisation de la tâche. La gestion de base d objets est un quatrième service inhérent aux PSEE. L objectif est ici d assurer l accès aux objets logiciels et à leurs relations qui sont stockés de façon persistante. Un gestionnaire de données est un des éléments clé des PSEE : il est responsable de la cohérence et de la disponibilité des informations nécessaires aux autres composants de l environnement (i.e. la résolution des conflits d accès notamment). La gestion des communications suppose que des interfaces de communication soient créées pour les composants et que des protocoles de communication soient établis pour définir les modalités d utilisation des services disponibles. L intégration de ce service au sein de l architecture présente l intérêt non négligeable de rendre l environnement adaptable, flexible et extensible. 2.4 Techniques d interopérabilité La tendance actuelle dans les systèmes supportant des procédés est d offrir un environnement coopératif dans lequel le support se fait à travers un ensemble de composants. Chaque composant prend en charge la gestion d un aspect particulier du procédé. Les récents travaux de recherche [BK95] [GLK97] dont les nôtres [ABC94] [ABC96] [Ami99] proposent une approche par composant pour le support de procédés. Les avantages attendus sont: L obtention des environnements coopératifs et ouverts L Interopérabilité entre composants hétérogènes Les Dépendances entre procédés sont délimitées et par conséquent mieux reconnues et gérées La réutilisation des composants procédés Notre étude est centrée sur le développement d un modèle de procédé à base de composants avec deux aspects importants à expliciter : Le concept de composants et l interopérabilité entre composants Définition de Composant «Un composant est un fragment de logiciel assez petit pour qu on puisse le créer et le maintenir, et assez grand pour qu on puisse l installer et en assurer le support. De plus, il est doté d interfaces standard pour pouvoir intéropérer». [OHE99] Un composant procédé est constitué d un groupe significatif d activités. Le composant procédé contient tous les rôles et produits qui sont liées à ces procédés et activités [LD97] Définition d Interopérabilité Deux ou plusieurs ressources sont interopérables si elles peuvent interagir pour exécuter ensemble une tâche [NWM93]. L interopérabilité implique la distribution d informations, la communication et la compréhension mutuelle entre les différents domaines d exécution. L hétérogénéité des composants rend complexe l interopérabilité. Cette hétérogénéité peut être due à la diversité des solutions proposées pour couvrir les différents aspects du procédé. En effet, pour chaque aspect dans le procédé, on peut envisager des solutions conceptuelles et technologiques différentes. Ceci concerne les concepts utilisés, les formalismes proposés et les plates formes d exécution, etc. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

12 On peut distinguer trois niveaux d'hétérogénéité : sémantique syntaxique des plate formes d'exécution. L'hétérogénéité sémantique est due à la diversité des concepts utilisés par les composants. Chaque composant peut offrir des concepts différents pour gérer l aspect du procédé auquel il est dédié. L'hétérogénéité syntaxique. Les composants peuvent offrir un formalisme différent pour décrire l aspect de procédé qui leur correspond. Le choix d un formalisme par rapport à un autre peut avoir un impact considérable sur l amélioration de la compréhension des modèles et de la capture du domaine du problème. L hétérogénéité des plates formes d exécution. En considérant que l exécution du procédé est répartie sur un ensemble de composants autonomes, chaque composant peut faire appel à des plates formes matérielles différentes. Le problème consiste ici à trouver les mécanismes appropriés qui permettent aux composants d interagir, d échanger des données et du contrôle. Les travaux qui proposent des solutions aux problèmes d hétérogénéité sont nombreux. Dans notre état de l art nous avons classifiés en trois groupes les techniques d interopérabilité trouvées dans plusieurs propositions du domaine de procédés et correspondant à une évolution dans le temps. 1. Interopérabilité par échange de données : Vocabulaire commun (sémantique) Schéma conceptuel procédé. Langage (syntaxe) 2. Interopérabilité par le contrôle (plates formes d exécution) 3. Interopérabilité par composants Nous proposons à présent d aborder chacune des techniques d interopérabilité, en remarquant les concepts apportés par les groupes de recherche Interopérabilité par échange de donnés Interopérabilité sémantique : Vocabulaire commun. Les environnements coopératifs impliquent que de multiples participants travaillent ensemble pour réaliser un but commun.. Pour atteindre ce but, ils ont besoin d échanger des idées et des résultats. Cependant, lorsque les participants interagissent, il apparaît un problème de vocabulaire, à cause des différentes définitions qu ils utilisent pour décrire le même concept. Le problème du vocabulaire commun a été abordé par différents domaines de l informatique tels que les bases données [BFL94] ou les systèmes collaboratifs [Che94] [WfMC98. Une des solutions proposées consiste à proposer des normes définissant les concepts relatifs à un domaine particulier (ontologies). Dans le domaine de procédés, des efforts importants ont été mis en œuvre afin de clarifier les concepts et la terminologie. Les contributions en rapport avec ce sujet viennent principalement de la communauté procédés logiciels [CFF94] [Lon93]. Nous allons définir les éléments basiques qui interviennent dans le procédé. Bien que nous ayons trouvé différentes définitions pour les éléments du procédé, nous avons essayé de donner une définition qui fasse l objet d un large consensus. Nous montrerons dans ce qui suit la façon d abstraire de tels éléments dans un schéma d objets. Tout composant doit adhérer à ce schéma. Il représente les éléments et les relations qui les lient. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

13 Procédé : tous les éléments impliquées dans le développement et la maintenance d un produit ou service, i.e. artefacts, support de production (outils), activités, agents [CFF94]. Artefact : produit créé ou modifié pendant un procédé [Lon93]. Il correspond à des objets tels que des documents ou des codes ayant une structure bien identifiée. Agent : celui qui exécute le procédé. Cela peut être un humain ou un outil logiciel [CFF94]. Un agent est caractérisé par les propriétés de son rôle. Rôle : décrit un ensemble de responsabilités, droits et compétences d un agent dans le contexte des activités où il intervient. Activité : c'est une unité élémentaire du procédé. Elle correspond à l ensemble des actions effectuées par les rôles dans le but de créer, de consommer, de transformer des produits ou de réaliser un service Le schéma conceptuel procédé. Une proposition pour le développement d une théorie unifiée dans la modélisation des procédés, est le «schéma conceptuel commun». Un schéma conceptuel commun offre une information importante sur l ensemble des entités participant au procédé et sur les relations existant entre les entités. Armitage et Kellner [AK94] ont proposé «un schéma conceptuel qui représente une vue unique et intégrée de l information nécessaire dans les modèles et définitions d un procédé». Le schéma conceptuel est suffisamment général et abstrait, ce qui permet de l utiliser avec une large variété de langages de définition ou de modélisation de procédés. L objectif visé est d obtenir : Unebasepourlareprésentationetlatransformationd unprocédédansdifférentsformalismes. L assistance au développement, à la révision et à l amélioration du modèle de procédé. La constitution d une base de modèles de procédés réutilisables. Le schéma est constitué de trois entités de bases : activité, artefact et agent et des relations qui les lient. La figure 4 montre le schéma conceptuel. Figure 4 : Schéma conceptuel Nous pouvons interpréter le schéma de la manière suivante : Un agent exécute une activité produisant un artefact. Par ailleurs, un artefact est issu d un autre artefact ; un agent est géré par un autre agent ; et une activité vérifiant le travail d une autre activité. Un procédé est de nature dynamique. Par conséquent, le comportement dans le temps est un aspect critique du procédé. Les principales entités et relations peuvent être envisagées comme une photo Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

14 instantanée. La figure 4 montre que le comportement est un aspect fourni par tous les entités et les relations. Exemples de comportements : Quand (sous quelles circonstances) Une activité peut commencer? Uneactivitépeutêtreconsidéréecommeterminée? Un artefact est produit (output)? Un artefact est acquis (input)? Un agent peut commencer à travailler dans une activité? L information du comportement peut être représentée par plusieurs approches de modélisation et de définition de procédés, comme : les diagrammes à transition d état, les déclencheurs ou les règles événements conditions - actions, les pré / post-condition. Un autre approche de schéma conceptuel commun est le modèle proposé dans le cadre du projet PCIS LCPS (Portable Common Interface Set Life Cycle Process Support). Ce modèle identifie les entités basiques du procédé et les relations entre elles. Voir figure 5. Figure 5 : PCIS LCPS Model [Der94] Le PCIS LCPS est centré sur les relations entre les activités (Activity) et les produits (Product). Une activité produit ou consomme des produits. L activité emploie des outils (Tools) pour assister ou mettre en œuvre l activité. Toute activité est exécutée par un agent via son Rôle (Role), lequel identifie le responsable de l activité. Finalement, chaque activité a un but (Direction) associé, lequel représente les objectifs de l activité Interopérabilité par les données : Langage de traduction commun. Nous avons dit précédemment que le schéma conceptuel servait de base pour la représentation d un procédé dans différents langages de modélisation. Dans un environnement coopératif chaque composant peut offrir un langage de modélisation différent pour décrire l aspect du procédé qui lui correspond. Le but de l interopérabilité syntaxique est de minimiser les conversions de données entre deux composants souhaitant échanger des définitions de procédés. L approche par modèle canonique a été dégagée des différents travaux d interopérabilité syntaxique. Cette approche préconise une représentation canonique et considère un convertisseur du formalisme du composant vers le formalisme canonique et vice versa. Généralement, les critères de choix d un tel langage dépendent de la nature du domaine et de l objectif à atteindre [Ami99]. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

15 Figure 6 : Modèle par langage canonique Des exemples de langages basés sur le modèle canonique sont PIF et WPDL. PIF (Process Interchange Format) Le PIF a commencé à se développer en octobre de 1993 par un groupe de travail comprenant des représentants de plusieurs universités et de sociétés de développement. L objectif principal est d offrir des formats et des schémas standards pour permettre l échange automatique de représentations de procédés entre des systèmes hétérogènes [LGJ+98]. PIF est basé sur un modèle objet. Il inclut un noyau de type objet (classe) prédéfini représentant les activités, les acteurs et les ressources. PIF permet à des groupes de travail de définir des extensions locales au modèle à savoir, de nouvelles classes ou nouveaux attributs. WPDL (Workflow Process Langage) Le WPDL a été défini par la coalition du workflow (WfMC). Il s agit d un langage standard qui supporte la transmission des définitions de procédés entre différents systèmes workflow [WfMC98]. Le langage est basé sur un méta modèle (modèle d objets). L objectif est de rendre possible l échange de modèles et de documentation entre des systèmes hétérogènes provenant de vendeurs différents Interopérabilité par le contrôle. L interopérabilité au niveau exécution, peut être défini comme la capacité pour un serveur d exécution de communiquer avec un autre afin d'exécuter ensemble un procédé. Rappelons que dans le contexte des composants, l exécution d un procédé est répartie entre un ensemble de composants autonomes et chaque composant peut faire appel à d autres pour interagir. Un mécanisme qui permet l interopérabilité est dit d'intégration par le contrôle. L objectif de l intégration par le contrôle est de permettre à des systèmes hétérogènes de communiquer entre eux et de faire varier leurs comportements en fonction des informations recueillies à travers ces communications [Was90]. Deux types de contrôles peuvent être distingués [Boy94] : la notification de l information et la demande de services. La notification d information permet à un système d émettre une information (souvent sous forme de messages ou d événements) vers d autres systèmes. Les notifications se font généralement au traversd unsystèmedemessagerieoudemiddlewaretelquecorba. La demande de services permet à un système de faire appel à un service (généralement un service est une méthode) offert par un autre système. Ce type d interaction se fait souvent à Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

16 travers des interfaces qui contiennent l ensemble des services que le composant veut rendre visibles. Les travaux réalisés au niveau d interopérabilité d exécution sont nombreux, nous allons en décrire quelques-uns. Nous présentons d abord la spécification de WAPI 4 fournie par la WfMC, notre intention est d'identifier les besoins qui conduisent à supporter l interopérabilité d exécution. Après nous présenterons trois protocoles de communication proposés par différents groups de recherche afin de supporter l interopérabilité entre les serveurs d exécution : SWAP, Jflow et Wf - XML WAPI4 (Workflow Application Programming Interface/Interchange 4) WAPI4 est la spécification abstraite défiant les fonctionnalités nécessaires pour supporter l interopérabilité entre les différents moteurs de procédés. Figure 7 : Interopérabilité par control (WAPI 4) [WfMC2-1] Le but est de définir un standard permettant de passer des items de travail (instances des procédés ou des activités) d un système workflow à un autre système différent. Deux ou plusieurs moteurs workflow peuvent communiquer pour réaliser : la sélection, l instantiation et l exécution d une définition de procédé connu, et (optionnellement) retourner les résultats sur l exécution de la définition du procédé. On peut distinguer deux modèles de communication : Communication synchrone : Où une requête demande une réponse «immédiate», elle nécessite une connexion directe via le protocole TCP/IP. Communication asynchrone : Où la réponse peut arriver quelques temps après la requête (de l ordre de quelques jours, semaines ou mois). La communication peut être réalisée en utilisant des mécanismes de type «stocker transférer» tel que la messagerie électronique. Les types de messages pour effectuer l interopérabilité. Un message est la représentation abstraite de l information qui doit être passée d un moteur d exécution à l autre, afin que ce dernier puisse réaliser les opérations décrites dans le message. Un message contient : des opérations et leurs paramètres respectifs ; et l information additionnelle pour que ces opérations puissent être exécutées. Il y a trois classes de messages : requête, réponse et notification. Un message «requête» est utilisé quand un moteur d exécution A a besoin de déclencher une activité ou un sous procédé dans un moteur B. A tout message de requête correspond un message «réponse» qui retourne le résultat de succès ou d échec de la demande. Le message notification permet au moteur B d informer sur les événements significatifs qui arrivent pendant l exécution du sous procédé. Tout message «notification» aura un message de réponse informant que le moteur A a reçu la notification. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

17 Les modèles d interopérabilité par contrôle supportés sont : Procédés chaînés. Ce modèle considère qu un procédé qui est exécuté dans le moteur de procédé A, déclenche la création et l exécution d'un sous procédé dans le moteur B. Pendant l exécution du sous procédé, le moteur A peut finir ou continuer l exécution de son propre procédé. Figure 8 : Modèle de procédés chaînés Sous procédés imbriqué. Ce modèle considère qu un procédé en cours d exécution dans un moteur d exécution A provoque la création et l exécution d un sous procédé dans un moteur B. Ainsi, le premier moteur attend la terminaison du deuxième moteur avant de continuer sa propre exécution. Figure 9 : Modèle de procédés imbriqués Parallèle synchronisé. Ce modèle considère que deux moteurs d exécution sont en train de dérouler chacun des procédés différents, et que chaque définition de procédé possède un rendezvous spécifié. Une fois que tout les deux ont atteint leur point rendez-vous, il y a des échanges entre les moteurs avant de continuer l exécution de leurs procédés respectifs. Figure 10 : Modèle de procédé parallèle Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

18 Pour cette spécification abstraite d interopérabilité par contrôle nous avons trouvé trois protocoles de communication proposés : SWAP lequel travaille sur HTTP, jflow travaillant sur CORBA et une proposition récente : Wf-XML généralisation de SWAP et Jflow, car il reste indépendant du protocole de communication SWAP En 1998 le protocole SWAP (Simple Workflow Acces Protocole) à été introduit par Netscape, HP et Sun comme une solution simple destinée à supporter l interopérabilité entre serveurs d exécution workflow. La spécification d interopérabilité définit un standard de communication basé sur le protocole HTTP, et utilise XML pour la structure d échange de données. Les buts du SWAP sont d intégrer des fournisseurs procédés ; de fournir des services asynchrones, à travers Internet ou de réseaux Intranet ; et de subvenir aux besoins de leurs interactions. Le protocole SWAP offre un chemin pour commencer une instance d un service générique asynchrone. Il offre aussi, des mécanismes pour contrôler et diriger l instance; et un autre mécanisme pour notifier quand elle est terminée. Par exemple une demande asynchrone est faite pour l exécution d un service. Des demandes additionnelles (synchrones ou bien asynchrones) peuvent être faites durant l exécution du service pour contrôler l avancement Jflow En 1998 l OMG (Object Management Group) a défini un protocole d interopérabilité workflow nommé jflow en utilisant le protocole CORBA. Le standard CORBA établit la façon dont les objets distribués peuvent participer à un workflow au moyen d invocations par un ORB (Object Request Broker). JFlow support l interaction des procédés workflow pendant l exécution, en utilisant des mécanismes de contrôle, de monitoring et de distribution des procédés. Le but de l OMG est de créer un framework architectural pour des applications distribuées basées sur des spécifications supportant des objets distribués. Le but inclut la réutilisation, la portabilité et l interopérabilité de composants logiciels dans des environnements hétérogènes [OMG98]. Pour atteindre ce but, l OMG adopte des spécifications de protocoles et d interfaces, basés sur la technologie objet commercialement disponible. Wf-XML est un protocole plus général que SWAP et jflow. Il reste indépendant des protocoles de communication HTTP et CORBA Wf - XML Wf-XML est la spécification d un langage XML (extensible Markup Langage) désigné pour modéliser le transfert de données demandé par la spécification d interopérabilité WfMC. Ce langage sera utilisé comme base pour les implémentations des fonctionnalités de l interface 4 de WfMC. Wf-XML supporte deux types d interopérabilité : workflow simple chaîne et workflows imbriqués. Le standard d interopérabilité [WfMC2-2] permet l interaction entre fournisseurs et demandeurs de services workflow (lesquels peuvent ou non être des services d exécution workflow). Il définit des opérations permettant à des fournisseurs de retourner des rapports sur l état d un procédé éloigné. Wf-XML définit le format de la requête qu un demandeur de services A envoie au fournisseur de service B pour contrôler et surveiller l exécution d un procédé. Le fournisseur répond à chaque requête avec une réponse assortie. Alors, le fournisseur B renseignera A sur les changements d état d un procédé, qui résultent des événements dans le domaine de B [WfMC2-1]. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

19 Les caractéristiques de la spécification Wf-XML: 1. Le corps du protocole est structuré et «bien formé». Il est constitué de structures de messages contenant des données et des entêtes. 2. L utilisation de messages synchrones et asynchrones. 3. L indépendance du mécanisme de transport. La spécification Wf-XML définit le contenu des données nécessaires pour la communication effective entre deux moteurs d exécution. La méthode de transport dépend de la solution du fournisseur. Quelques exemples de méthodes de transport : HTTP, , CORBA, IIOP, COM/DCOM ou des systèmes de queue de messages. 4. Contrat d interopérabilité. Typiquement le contrat d interopérabilité s adresse au sujet de connectivité, sécurité et le format de données qui sont associés à un procédé workflow spécifique. Dans le Wf-XML, le contrat définit clairement les besoins de chaque vendeur. 5. Facilite l extensibilité grâce à l utilisation du XML, et grâce à l utilisation d un contexte de donnés dynamique. Le concept d interopérabilité entre systèmes workflow peut être étendu pour couvrir des interactions entre d autres types de systèmes et services dits «services génériques» et peuvent représenter des ressources identifiables avec qui arrivent des interactions. L interopérabilité est menée à bien par des fonctions individuelles dites «opérations». Chaque opération peut être passée comme un ensemble de paramètres en utilisant un message «requête» ; de la même façon, ses résultats peuvent être retournées comme un ensemble de paramètres en utilisant un message «réponse». Les opérations sont classifiées dans trois groupes, afin de les identifier en accord à leur contexte, à savoir : le ProcessDefinition, le ProcessInstance et l'observer. Les groupes d opérations et leurs relations sont illustrées par la figure suivante. Figure 11 : Modèle de ressource logique Le processdefinition est le groupe fondamental des opérations nécessaires pour l interaction de ressources. Il représente la description de fonctions plus basiques, et il est la ressource par laquelle des instances d un service seront crées. Le groupe ProcessInstance représente l exécution réelle d un procédé défini. Chaque instance de procédé aura son propre identificateur séparé de l identificateur de sa définition. Le groupe Observer fournit les moyens par lesquels l instance d un procédé peut communiquer son terminaison. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

20 Wf XML a spécifié les opérations suivantes : Process Process Observer Description Definition Instance CreateProcessInstance X Crée une nouvelle instance d un procédé particulier laquelle sera contrôlée par le fournisseur de service. GetProcessInstanceData X Obtient les valeurs de toues les propriétés définies pour une instance du procédé. ChangeProcessInstanceState X Change l état de l instance du procédé. ProcessInstanceSetChanged X Renseigne sur les changements d état closed.completed et closed.abnormalcompleted Le Modèle «Mission» : utilisation du protocole Wf-XML. Nous allons présenter le modèle mission comme un exemple de la démarche du protocole Wf-XML. La «mission» a par but atteindre l interopérabilité entre les différents composants procédés, en utilisant le modèle client - serveur et le protocole Wf-XML [WfMC2-1], sur HTTP. Description. La mission commence quand un serveur reçoit une requête Wf-XML avec les paramètres nécessaires dans la démarche d une opération, tel que «CréerComposant» ; et elle finit quand le client reçoit une réponse avec les résultats de l opération demandé. On peut distinguer deux types de requêtes : synchrone et asynchrone. La requête synchrone. La réponse à une requête est presque immédiate, quelques secondes ou minutes. La requête asynchrone. La réponse à une requête est plus tardive que précédemment, quelques heures, jours ou mois. Il y a trois types d'opérations qui définissent la nature de la requête. Une mission doit avoir au minimum un des types d opération suivants: Enregistrer : pour réaliser des requêtes impliquant des actions et pour retourner des résultats. Rapporter : pour demander la progression et le résultat d une requête finie. Cette opération est utile quand un client invoque une mission incluant des centaines de requêtes. Contrôler : pour annuler, arrêter ou reprendre l exécution d une requête. Les opérations de nature synchrones sont constituées en deux phases : La phase de «requête» et la phase de «réponse». Dans la figure les messages No. 10 et No. 11. Les opérations de nature asynchrones sont constituées en quatre phases : la «requête» tel que le message No. 6, la phase de «Reconnaissance» sortante tel que le message No. 7, la phase de «Réponse» tel que le message No. 8, et «Reconnaissance» entrante tel que le message No. 9. On peut distinguer deux types de directions : Sortant et entrant. Quand le client A fait une requête au serveur B, la direction «sortant» indique que le message est envoyé du client A au serveur B ; pendant que la direction «entrant» indique que le message est envoie du serveur B au client A Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

21 Figure 12 : Modèle pour une mission 1. Le gestionnaire de requêtes A ressemble toutes les requêtes Wf-XML. Il fait un script de commandes avec les requêtes nombres. 2. Le gestionnaire de requêtes A fournit un identificateur à la mission «IdMission» 3. Le gestionnaire de requêtes A envoie le script au gestionnaire de requêtes B, à travers d un message Enregistrer.requête. Ce message contient : L'«IdMission», une étiquette contenant l URL du gestionnaire de requêtes A, et une étiquette <Asynchrone> indiquant que l opération est asynchrone. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

22 4. Le gestionnaire de requêtes B retourne un message de «Enregistres.reconnaissance» avec l'«idmission». 5. Le gestionnaire de requêtes B exécute chacune des requêtes trouvées dans le script. 6. Quand le gestionnaire de requêtes A veut connaître la progression et le résultat de toute requête finie, il envoie un message Rapporter.requête. Ce message contient : Le «IdMission» passé dans le pas 3, et une étiquette <Asynchrone> indiquant que l opération sera menée à bien de façon asynchrone. 7. Le gestionnaire de requêtes B retourne un message de «Rapporter.reconnaissance» avec l'«idmission». 8. Le gestionnaire de requêtes B retourne le message réponse de l'opération Rapporter «Rapporter.réponse», avec la progression et le résultat. 9. Le gestionnaire de requêtes A retourne un message de «Rapporter.reconnaissance» avec l'«idmission». 10. Quand le gestionnaire de requêtes A veut déclencher une action sur l exécution du composant procédé, il envoie un message Control.requête. Ce message contient : L'«IdMission» et une étiquette <Synchrone> indiquant que l opération sera menée à bien de façon synchrone. 11. Le gestionnaire de requêtes B envoi un message réponse de l'opération Contrôle «Control.réponse». 12. Lorsque que toutes les requêtes dans le script sont finies, un message réponse de l'opération enregistrer «Enregistrer.réponse» est envoyé vers le gestionnaire de requêtes A. Le message peut inclure des exceptions sur les requêtes qui ont présenté des pannes pendant leur exécution. 13. Le gestionnaire de requêtes A retourne un message de «reconnaissances» par le résultat OZ OZ [BK95] est un système développé dans le but de permettre l interopérabilité entre des environnements homogènes (les PSEE s pris en compte par l environnement sont identiques), autonomes et géographiquement distribués. L approche utilisée consiste à répartir l exécution du modèle de procédé sur des sites différents en fonction de la disponibilité des ressources nécessaires à son exécution. Oz utilise la métaphore «alliance internationale» pour gérer la communication entre PSEE s décentralisés. La Métaphore implique deux concepts : traités et sommets. Les sites PSEE s sont interconnectés, pour établir des traités. Un traité est un sous procédé partagé par plusieurs PSEE s. La réalisation d une tâche multi-site définie dans un traité est un sommet. Seulement les tâches spécifiées dans le traité peuvent accéder aux données des sites en accord avec les restrictions définies dans le traité. Les sommets permettent l exécution d activités multi-sites globales et partagées Process wall Process Wall [Hei92] est un moteur de procédé basé sur un serveur d états. Il a été développé par l Université du Colarado. Il permet le stockage des états d un procédé et offre des opérations manipulant la structure des états. Une caractéristique importante du Process Wall est la séparation du formalisme décrivant le code de procédé du formalisme décrivant l état du procédé. Cette séparation permet l interopérabilité entre différents formalismes de code (langages de procédés) car ils adhérent à la structure d un état commun. L architecture du serveur d état est de type client serveur. Les clients hétérogènes, manipulent le serveur d état du procédé central. La communication entre le client et le serveur est bidirectionnelle et utilise RPC (Remote Procedure Call). Un client manipule une instance de procédé partagé et reçoit les notifications des mises à jour de l instance. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

23 APEL. APEL [EAD98] est un environnement centré procédé pour la modélisation et l exécution de procédés. Il est basé sur une architecture dénommé «fédération de composants». L idée consiste à partager le modèle global d un procédé dans un nombre d aspects (activités d un procédé) indépendants; chacun des aspects seront réalisés par un composant spécifique. Tous les composants dans cet environnement sont des Process (Sensitive) Support Systems 1 (PSS) hétérogènes à niveau représentation ; cependant ils partagent les mêmes concepts de procédés fondamentaux. Bien qu eux sont hétérogènes APEL essaye de les faire interopérer, pour mener à bien le procédé global. L interopérabilité est supporté au niveau de la modélisation et au niveau de l abstraction (interopérabilité sémantique) ; elle est de plus renforcée en utilisant les moteurs procédés distribués et hétérogènesauniveaudel exécution. APEL utilise le paradigme d interopérabilité dit «ultra libéral». Ici, les composants réagissent par notification d événements. Les principales caractéristiques: Les composants sont libres de choisir les événements auxquels ils souscrivent. Les composants sont libres de décider comment réagir quand un événement arrive. Il n y a pas de contrôle sur les actions qu un composant peut effectuer dans un serveur de procédé Approche par composant pour la modélisation des procédés Nous nous sommes intéressés plus particulièrement aux approches de modélisation de procédés à base de composants. Ainsi, le contrôle et l intégration des données sont mis en œuvre à partir d un modèle basé composants. Alors, le procédé est vu comme un ensemble de composants inter opérants. Les dépendances de données sont réduites en encapsulant les composants derrière des interfaces bien définies. Cela permet d éliminer le besoin de traduction entre langages de procédés. Les systèmes suivants illustrent une telle approche : Endeavors, Pynode, SPMS et OPC Endeavors. Le système Endeavors [BT96] est un système distribué destiné à assister les procédés. Le système est basé sur la combinaison d une approche homogène au niveau de la modélisation et d une approche hétérogène à l exécution. Un procédé peut être décrit à travers un ensemble de modèles (composants) en utilisant le même formalisme et les mêmes concepts. Chaque modèle est interprété par un ensemble de «handlers». L implémentation en Java de ces «handlers» permet de les porter sur des plate-formes hétérogènes. Bien qu Endeavors supporte l interopérabilité au niveau exécution, l interopérabilité au niveau sémantique et syntaxique n a pas été abordé Pynode La principale motivation de Pynode [ABC94], est de développer un environnement interactif et intégré, supportant des procédés. L idée consiste à éliminer les aspects monolithiques des formalismes de procédés, et ainsi fournir des possibilités de réutilisation et d intégration de représentations de procédés hétérogènes. 1 Un PSS est un système dans lequel un procédé peut être modelé. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

24 Pynode propose la construction de composants procédés aboutissant à la production d artefacts procédés. Un composant procédé est essentiellement un fragment de modèle de procédé écrit dans un langage de modélisation de procédé. Les composants sont dynamiquement combinés pour construire un modèle de procédé à travers des interfaces et des ports de connexions. Les types de ports de l interface de connexion donnent des relations d entrée, de sortie et de synchronisation pour permettre à des composants d interagir dynamiquement. Les types de ports de l interface d échange permettent aux composants d échanger des informations (lecture/écriture) de manière asynchrone durant l exécution. L exécution de procédés est supportée via les vues d exécution. Une vue d exécution définit une collection de composants et de relations de composition. La composition dynamique de composants via les vues d exécution avec l exécution des composants définit l exécution de procédés SPMS. Software Process Management System. Dans SPMS [KTL+92] les composants sont des collections nommées de fragments de procédés organisés en réseau. Un composant procédé représente un fragment de procédé à un niveau donné de granularité et complexité, et qui a été élaboré avec suffisamment de détails nécessaires à son exécution. Les modèles de procédés sont construits à partir d une hiérarchie de et un réseau de flots d informations entre les composants. Les auteurs décrivent les objectifs d une approche à base de composants sans décrire la machinerie de support. Aucune définition rigoureuse du composant procédé n est fournie ni une description sur la manière d implémenter les composants. En général le terme composant est utilisé pour décrire des fragments de procédés réutilisables. Cependant ce système a été présenté en 1992 avant le boom courant sur le développement de logiciel à base de composants OPC. Open Process Components Framework. L OPC [GLK97] propose un environnement pour la production de procédés à base de composants. Dans cette approche, les modèles de procédés sont construits comme un ensemble de composants qui interagissent à travers des interfaces bien définies. Il propose aussi une infrastructure, pour l interopérabilité et la réutilisation de composants procédés hétérogènes, construit selon trois niveaux d abstraction. 1. Le niveau méta modèle qui identifie les entités fondamentales du procédé et leurs relations. 2. La Machine d états finis. Représentation du comportement des entités du procédé 3. Un framework orienté objet lié au formalisme de représentation du procédé et à son domaine d application. La figure illustre un exemple sur l hiérarchie de classes, séparés en trois niveaux, pour le entité procédé. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

25 Figure 13 : Hiérarchie de classes pour l'entité "procédé" Le niveau de base dit «framework» qui capture les abstractions de base des entités du procédé. Les classes et les interfaces de la couche framework servent comme contrat minimum que tout composant doit supporter. Le niveau de représentation capture les abstraction des formalismes spécifiques. Elle encapsule la sémantique d un langage de modélisation du procédé donné. Le niveau domaine incorpore aux classes les comportements de domaine spécifique à partir desquelles les composants d exécution sont dérivés. Ici est possible de contrôler les interactions entre les composants de type particulier. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

26 2.5 SYNTHESE Dans ce chapitre nous avons présenté différentes techniques d interopérabilité décrits dans le domaine des procédés. Ces techniques ont évolués dans le temps. La première est l interopérabilité par échange de données, qui est caractérisée par : L'unification des concepts et des terminologies relatives au domaine des procédés. La proposition d un modèle générique contenant les éléments et leurs relations afin de rester indépendant au formalisme de représentation du procédé. La création d un formalisme canonique pour l échange automatique de représentations de procédés entre des systèmes hétérogènes. La deuxième technique est l interopérabilité par le contrôle, dont le but est la communication entre des moteurs de procédés hétérogènes 2, afin qu ils exécutent ensemble un procédé. Plusieurs protocoles d interopérabilité ont été proposés, le plus récent, étant Wf-XML qui est indépendant du mécanisme de transport (HTTP et CORBA). La troisième technique est l interopérabilité par composant, dont les principales caractéristiques sont: Le contrôle et l intégration de données sont mis en œuvre à partir d un modèle à base de composants. Les dépendances de données sont réduites en capsulant les composants par des interfaces bien définies. Ceci permet d éliminant la traduction entre les différents formalismes de représentation. Les bénéfices attendus par cette dernière approche sont : La réutilisation de modèles de procédés (composants) autonomes et fonctionnels. L'interopérabilité entre composants hétérogènes. L'évolution dynamique du modèle par composant. Nous allons proposer dans le chapitre suivant un framework qui couvre les aspects décrits ci-dessus. Ce framework pourra être étendu afin de répondre à des besoins particuliers pour certaines applications. 2 Chaque moteur procédé exécute un formalisme particulier Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

27 CHAPITRE 3. Notre Approche. 3.1 Introduction. Dans le domaine de la modélisation des procédés, l approche par composants vise à construire de nouveaux procédés de façon coopérative, dans un environnement distribué et hétérogène. Pour qu un système puisse supporter de tels besoins, il doit compter sur une architecture physique appropriée. Comme Les composants sont hétérogènes, on doit implémenter des mécanismes supportant les niveaux d interopérabilité décrits dans l état de l art. La figure 14 illustre le scénario pour la construction et l'exécution du procédé «conception d un logiciel». Figure 14 : Conception d'un procédé par composants Nous allons appliquer la philosophie des objets distribués et des composants pour le développement des procédés. Au cours de ce chapitre, nous présenterons les concepts de base de notre proposition. Après, nous menerons à bien le développement d un framework orienté objet pour des composants procédés ; il constituera le moteur d un environnement centré procédé permettant la modélisation de procédés par composants. Finalement, nous proposerons un modèle d interopérabilité par contrôle des composants procédés. 3.2 Concepts Modèle. Un modèle est la représentation abstraite d un procédé dans un formalisme donné, qui permet de comprendre et de simuler. Ce modèle est en suite spécialisé pour obtenir une instance pouvant être exécutée par un environnement centré procédé Composant procédé. Un composant procédé est l instance d un procédé, dérivée d un modèle stocké dans une base de données. Le composant encapsule sa représentation et fournit une interface simple pour établir la communication avec l extérieur. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

28 Si on approfondit le concept du procédé, un composant correspond à une activité ou à un sous procédé qui contribue à la réalisation d un but spécifique dans le procédé. Il vise à générer ou à modifier un ensemble de produits Modélisation basée composants. Le but de la modélisation basée composant est la construction de modèles plus complexes, à travers la réutilisation de modèles consistants et fonctionnels. Chacun d eux constitue un composant procédé. Voici les points à considérer pour la modélisation par composants : Construire une base d information sur les composants réutilisables Déterminer la fonction de chaque composant dans le nouveau modèle procédé Composition dynamique des composants hétérogènes L exécution basée composants procédés. Notre vision concernant le support de procédés est un environnement où deux ou plusieurs composants hétérogènes exécutent et coopèrent de façon distribuée. Cet environnement doit être capable de rendre l hétérogénéité et la distribution des composants transparentes. Ainsi, par exemple, le rôle charge de la modélisation, voit les composant comme des boîtes noires, qu il utilise pour créer un nouveau modèle Le vocabulaire commun. La terminologie utilisée dans notre approche est inspirée de [CFF+92]. Ce vocabulaire commun sera exprimé à travers d un schéma conceptuel dans le prochain point. Composant procédé : Il correspond à une activité ou à un sous procédé qui contribue à la réalisation d un but dans le procédé. Il vise à générer ou à modifier un ensemble de produits. Produit, le résultat d un procédé : Il correspond à des objets tels que des documents, codes ou services. Agent : C est un performeur d un procédé, cela peut être un humain ou un outil logiciel. Un agent est caractérisé par les propriétés de son rôle. Rôle : Décrit l ensemble de responsabilités, droits et compétences d un agent dans le contexte des activités où il intervient Le schéma conceptuel procédé. Un schéma conceptuel procédé rassemble toute l information des entités qui appartiennent au procédé, dès que des relations existent entre elles. Le schéma conceptuel pour notre environnement procédés est illustré par la figure suivante. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

29 EntitéProcédé Agent agentid : String can_perform Role roleid : String rolename : enumerate assigned_to name : String 1..* 1..* Role( ) ~Role( ) AffectRole( ) 1..* ProcessComponet sieexécution : String nomprocédé : String datecreation : Date durée : Date sujet : String description : String PropriétésComposant( ) TerminerComposant( ) Suspendre( ) RéprendreComposant( ) AnnulerComposant( ) AttacherObservateur( ) DétacherObservateur( ) ListEvénements( ) Notifier( ) 1..* 1..* has_input has_output 1..* 1..* Produit produitid : String produitname : String version : String TransferProduit( ) has_sub Figure 15 : Schéma conceptuel Framework orienté objet Un framework est un ensemble de classes qui coopèrent et permettent des conceptions réutilisables. Il apporte de nombreuses fonctionnalités et des relations entre classes d objets, ainsi qu une infrastructure au développeur. On spécialise un framework afin qu il répond aux caractéristiques d une application, par création de sous classes spécifiques à partir des classes abstraites du framework [GHJ99] L état procédé. L état procédé correspond au comportement des entités d un procédé. Le changement d état est déclenché par des événements produits quand des méthodes sont exécutées. Par exemple, l exécution de la méthode ChangeEtatProcédé(Suspendre) produit l événement : ( :Composant Procédé, suspendu) et en suite, il produit un changement d état de l entité ComposantProcédé Classement hiérarchique Nous proposons un classement hiérarchique. Il consiste à structurer la base de composants réutilisables par domaine d application. Par exemple : Analyse Dessin Implémentation Test Chaque domaine d application peut être raffiné en sous-domaines. Par exemple on peut raffiner Implémentation en : Les structures de données Les composant graphiques Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

30 Pour entrer un composant dans la base, on détermine à quel domaine il correspond, puis à quel sousdomaine, et ainsi de suite jusqu'à arriver à l emplacement qui lui convient Architecture de l Environnement Centré Procédé. L architecture correspond à un ensemble des outils nécessaires pour l exécution d un procédé. Notre architecture, est une extension de l architecture PSEE traité dans l état de l art. De telle sorte qu elle supporte l hétérogénéité et la distribution des composants. L architecture est donc formée par : L Interface permettant à l utilisateur de regarder le développement d un procédé. L information fournie par celle-ci, doit répondre en adéquation avec les besoins inhérents au rôle de l utilisateur. Les moteurs d exécution, chacun étant spécifique à un formalisme donné, regroupent les différents modules de la définition d un procédé et les exécutent. La base d objets contient la définition des procédés stockés de façon persistante. Il y aura un gestionnaire de la base d objets responsable de la cohérence et de la disponibilité des informations nécessaire aux autres composants de l environnement. Le serveur des communications, suppose que des interfaces de communication soient créées pour les composants et que des protocoles de communication soient établis pour définir les modalités d utilisation des services disponibles. Mécanismes d interaction. Evénement. Un événement est une action instantanée et non persistante, qui apparaît pendant l exécution d une instance d un certain procédé. Un événement est levé pour indiquer l état actuel de l instance du procédé. Service d événements. Au temps d exécution, le serveur d événements capture des événements provenant de l exécution des composants ; et en suite, il fait la notification à des composants abonnés à tels événements. 3.3 Modèle pour des Composants procédés. Le modèle que nous proposons pour des composants procédés, est représenté par la notation UML[Mul97]. La démarche adoptée consiste à considérer un modèle de procédé, représenté dans un formalisme quelconque, comme un composant réutilisable, qui fournit une interface simple à des concepteur de procédés. Dans ce qui suit, nous allons décrire les diagrammes de modélisation, en commençant par les cas d utilisation, puis les diagrammes de séquence, le diagramme d état et finalement le diagramme de classes Les cas d utilisation. A travers la présentation des cas d utilisation nous mettons en évidence les rôles qu implique l introduction d un composant procédé dans la modélisation d un procédé. Nous identifions trois rôles principaux : celui chargé de la définition d un composant procédé, celui chargé de l exécution et celui chargé de l observation. Le premier cas d utilisation correspond au rôle chargé de la définition des composants procédés au sein de la modélisation d un procédé. Il va définir chaque composant procédé, dont les fonctionnalités et les propriétés sont similaires à un autre, en appliquant les changements à une définition existant (dans une base de données) de composant. Le chargé de la définition va spécifier la composition des composants, i.e. comment des composant doivent interagir avec des autres composant procédés. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

31 Le deuxième cas d utilisation correspond au rôle chargé de l exécution du composant procédé. Une fois que le procédé est déclenché, chaque composant sera exécuté dans l ordre et sous les conditions définies par celui chargé de la définition. Le dernier cas d utilisation est relatif au rôle de celui chargé de l observation. Les besoins de ce type d acteur sont de visualiser l information concernant les composants qui l intéressent, en train de s exécuter (combien de temps il dispose pour le mener à bien, si le procédé a fini, dans quel état se trouve-t-il, etc.). Pour eux la distribution des composants est transparente. Ils les observent et les contrôlent comme si les composants étaient dans son propre site. Les manipulations de base définis pour les composants procédés peuvent être résumés de la manière suivante : 1. Définition d un composant procédé selon le méta modèle. 2. Définir un composant procédé, dont les fonctionnalités et les propriétés sont similaires à un autre, en appliquant les changements à une définition existante de composant procédé. 3. Spécifier la composition. Comment les composants procédés interagissent avec d autres composants procédés. 4. Instancier un composant procédé en spécifiant les liaisons nécessaires pour lui permettre d être exécuté. 5. Exécuter un composant procédé. La figure suivante illustre les différents cas d utilisation décrits auparavant. Charge de la définition Créer composant procédé utilise Exécuter composant procédé Regarder course de l'exécution Charge de l'observation Charge de l'exécution Contrôler l'exécution Figure 16 : Les cas d'utilisation Scénarios principaux identifiés au travers des cas d utilisation Créer un composant procédé : 1. Le rôle chargé de la définition demande la liste de composants procédés à la base de données. 2. La base de données affiche la liste des composants (à travers une interface de dialogue) disponibles dans la bibliothèque de composants procédés. 3. Le rôle chargé de la définition d un procédé sélectionne les composants procédés à partir de fabriques (factory s) composants concrets. 4. L objet FactoryComposant crée un composant procédé concret. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

32 5. La factory est responsable de la création du diagramme de transition d état du composant en utilisant le FactoryDiagrammeEtat. 6. Le FactoryDiagrammeEtat crée le DiagrammeEtatComposant. : Charge de la définition : BaseDonnées :Factory Composant : Composant Procédé :Factory DiagrammeEtat : DiagrammeEtat Composant 1: Démande liste de 2: Liste de composants 3. Création des composants 4. CréerComposant ( ) 5. appelle 6. créé Figure 17 Diagramme de séquences : création d un composant procédé Les objets FactoryComposant deviennent les fabriques de composants procédés. Ils correspondent à des modèles des composants procédés enregistrés dans une base de données. Chaque modèle a un formalisme de représentation dépendant de l'environnement centré procédé sur lequel il a été créé Exécuter un composant procédé 1. Le rôle chargé de l exécution demande l instanciation et l exécution du composant procédé 2. Avec l instanciation commence proprement l exécution du composant procédé. 3. Un observateur global est déclenché pour observer le développement de l exécution pour ce composant. :Chargede l'exécution : Composant Procédé : Observateur Global 1: Instancier et exécuter 2: Exécution 3: déclencher Figure 18 Diagramme de séquence : Exécution d un composant procédé Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

33 Contrôler l exécution d un composant procédé 1. Le rôle chargé de l exécution active l observateur global correspondant, avec la méthode PropriétésObservateur(). 2. L observateur global affiche les propriétés du composant et des sous composants fils, enregistrés jusqu'à présent. 3. Le rôle chargé de l exécution demande le changement d état du composant procédé au travers de l observateur global. 4. L observateur global exécute par exemple, la méthode Suspendre(). 5. Quand la méthode s exécute, il se produit un changement d état. 6. Le composant procédé notifie le changement d état à son propre observateurs global et à ceux observateurs externes intéresses par tel événement. 7. La méthode MisAJour actualise les propriétés enregistrées par l'observateur global. 8. L observateur global affiche les propriétés plus récentes du composant procédé. : Charge de l'exécution : Observateur Global : Composant Procédé 1. PropriétésObservateur ( ) 2. propriétés 3. ChangeEtatProcédé(susprendre) 4. susprendre ( ) 5. change d'état 6. Notifier ( ) 8. PropriétésObservateur ( ) 7.MisAJour ( ) Figure 19 Diagramme de séquence : Contrôle de l'exécution Abonner un observateur global externe. 1. L observateur global externe demande à être abonné à des événements via la méthode AttacheObservateur() 2. Le composant procédé retourne la liste d événements. 3. L observateur sélectionne le ou les événements auxquels il veut s abonner. 4. Validation de l attachement pour éviter par exemple d'abonner plusieurs fois un observateur au même événement ou bien d'abonner un observateur sans permission. 5. Si l attachement est validé, le message de confirmation est envoyé. 6. En même temps le composant procédé fait l attachement de l'observateur. 7. Dans l'autre cas le composant envoie un message d erreur. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

34 : Observateur Global : Composant Procédé 1. AttacheObservateur ( ) 2. liste d'événements 3. Selection d'événements 4. validation if attachement valid 5. Message de confirmation 6: attachement else 7. Message d'erreur Figure 20 Diagramme de séquence : Abonnement un observateur Diagramme de transition d états. Les états qui peuvent arriver au composant procédé sont : Figure 21 : Diagramme de transition d'états pour un composant procédé Bien que le composant procédé a été mis en exécution, le rôle chargé de l exécution pourra abandonner le composant procédé Le composant procédé passe de l état prêt à l état exécution avec l arrivée de l événement «débutprocédé» Si l exécution est menée à bien sans erreurs, alors le composant sera terminé normalement. Si pendant l exécution, des erreurs interviennent, le rôle chargé de l exécution peut prendre une des deux décisions suivantes, dépendant du type d erreur. Suspendre le procédé pour corriger le problème et après reprendre l exécution. Mais si ce n'est pas possible de le corriger, alors le rôle chargé de l exécution pourra abandonner le procédé. Il peut opter pour l'abandon du procédé. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

35 3.3.4 Diagramme de classes Dans la suite, nous décrivons le framework orienté objet permettant la définition des composants procédés selon le méta modèle ; la création des composants procédés dont les fonctionnalités et propriétés sont similaires à un autre, en appliquant les changements à la définition d un composant procédé existant ; finalement l instanciation d un composant procédé en spécifiant les liaisons que lui permet d être exécuté. Agent agentid : String name : String 1..* a_par_rôle 1..* Rôle roleid : String rolename : Enumerate Role( ) ~Role( ) AffectRole( ) assigné_à ObservateurGlobal idobservateurglobal : String siteexécution : URL InfoProcédé : Elément PropriétésObservateur( ) MiseAJour( ) ProcédéTerminé( ) ChangeEtatProcédé( ) selec_facteur_concret assigné_à lié_à abonne sous 1..* 1..* FactoryComposant NomFacteur : String CréerComposant( ) crée ComposantProcédé siteexecution : URL nomprocédé : String datecreation : Date durée : Période sujet : String description : String appelle appelle stocke PropriétésComposant( ) TerminerComposant( ) SusprendreComposant( ) <exécuter RéprendreComposant( ) AnnulerComposant( ) AttacheObservateur( ) DetacheObservateur( ) ListEvénements( ) Ajouter( ) Modifier( ) Suprimer( ) Notifie( ) a_diagrammeetat FactoryDiagrammeEtat nometat : String description : String crée DaigrammeEtatComposant Etat : String description BaseDonnés idbasedonné MoteurProcédé idmoteurprocédé : String nommoteurprocédé : String Attribut nomattribut : String type : String < a_attribut produit ComposantMetaData nomcomposant : String a_shema capture a_method Schéma nomshema : String Evénement nomevénement AffectEtat( ) <déclenche Méthode nomméthode : String name : type = initval Figure 22 Diagramme de classes : Framework pour des composants procédés On peut identifier trois patrons basiques dans ce modèle: fabrication ( factory ), observateur (observer) et façade (façade) dans le sens de Gamma [GHJ99]. Dans ce qui suit nous allons analyser ces patrons et les classes principales qui constituent notre framework Le patron Fabrication. Nous proposons un framework conçu pour la modélisation susceptible d intégrer différents composants procédés. Les classes basiques dans notre modèle de fabrication sont : FactoryComposant et ComposantProcede. Ce sont deux classes abstraites, par conséquent, nous devons en dériver des sous classes pour réaliser l implémentation spécifique d'un composant procédé. Par exemple, considérons le composant procédé représenté dans le formalisme APEL. Alors modèleapel devient la classe concrète de FactoryComposant et test la classe concrète de ComposantProcédé. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

36 appelle FactoryComposant NomFacteur : String crée CréerComposant( ) ComposantProcédé siteexecution : URL nomprocédé : String datecreation : Date durée : Période sujet : String description : String PropriétésComposant( ) TerminerComposant( ) SusprendreComposant( ) RéprendreComposant( ) AnnulerComposant( ) AttacheObservateur( ) DetacheObservateur( ) ListEvénements( ) Notifie( ) a_sous modèleapel CréerProcédéInstance( ) ListeInstances( ) Test Figure 23 Diagramme de classes : Patron fabrication L interprétationpourlediagrammedeclassesdelafigure23: ComposantProcede : définit l interface des objets créés par le FactoryComposant. FactoryComposant : déclare la fabrication, celle-ci renvoie un objet de type Composant Procede. Le test implémente l interface ComposantProcede. ModelApel surcharge la fabrication pour renvoyer un objet de type test L Observateur global Agent agentid : String name : Strng 1..* à_par_rôle 1..* Rôle roleid : String rolename : Enumerate Role( ) ~Role( ) AffectRole( ) assigné_à ObservateurGlobal idobservateurglobal : String siteexécution : URL InfoProcédé : Elément PropriétésObservateur( ) MiseAJour( ) ProcédéTerminé( ) ChangeEtatProcédé( ) lié_à abbonne ComposantProcédé siteexecution : URL nomprocédé : String datecreation : Date durée : Période sujet : String description : String PropriétésComposant( ) TerminerComposant( ) SusprendreComposant( ) RéprendreComposant( ) AnnulerComposant( ) AttacheObservateur( ) DetacheObservateur( ) ListEvénements( ) Notifie( ) sous Figure 24 Diagramme de classes: L'observateur global La classe observateur global, illustré par la figure 24, a deux types de relations : La relation lié_à définit une relation d un observateur global avec un composant procédé. Ici la tâche de l observateur est d'enregistrer l information plus importante sur le composant procédé auquel il appartient et l information sur les possibles sous composants fils, tel que : nom du composant, son état, la durée, le rôle responsable de l'exécution du composant, etc. L observateur a le contrôle sur le composant et sur ses sous composants fils ; en lui peut par exemple, modifier l état du ou des composants procédés. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

37 La relation abonné définit une interdépendance de façon telle que, quand le composant procédé change d état, tous ceux observateurs globales externes qui en dépendent soient notifiés, et automatiquement mis à jour. L observateur global externe n aura pas la permission de modifier l état du composant procédé en question Le patron de façade. La classe ComposantProcédé joue le rôle de façade : elle doit offrir à l utilisateur une interface unique et simple vers les services du composant procédé. Elle connaît les classes pour une requête. Mais les classes du sous système ne connaissent pas la façade, c est à dire qu elles n ont pas de référence à celle-ci. Les observateurs communiquent avec le composant procédé en envoyant des requêtes à la façade, qui répercute celles-ci aux objets appropriés du sous-système Le ComposantMétaData. Le composant procédé produit des méta données constituées par les classes : attribut, méthode et événements. On peut ainsi manipuler l information et des opérations des composants procédés. Il suivi un schéma conceptuel bien établi. La figure 25 illustre le diagramme de classes correspondant. a_sous ComposantProcédé siteexecution : URL nomprocédé : String datecreation : Date durée : Période sujet : String description : String PropriétésComposant( ) TerminerComposant( ) SusprendreComposant( ) RéprendreComposant( ) AnnulerComposant( ) AttacheObservateur( ) DetacheObservateur( ) ListEvénements( ) Notifie( ) produit Attribut nomattribut : String type : String < a_attribut ComposantMetaData nomcomposant : String a_schema 1..* capture a_method Schéma nomshema : String Evénement nomevénement AffectEtat( ) <déclenche Méthode nomméthode : String name : type = initval Figure 25 : Diagramme de classes: Méta données produits par un composant procédé Fonctionnement de la machine d'exécution : exemple. Remarquons, que la création et l exécution d un modèle par composants est assez dynamique, surtout car elle peut impliquer l exécution parallèle de plusieurs composants, chaque composant à son tour peut déclencher l exécution de d'autres sous composants parallèles, enchaînes ou imbriqués (modèles étudiés dans l état de l art). Analysons un exemple pratique: Le procédé test dans le développement d un système logiciel. Les sous-composants du test sont : test d intégration et test unitaire. Chacun d eux reçoit comme entrée un plan de test, ils fournissent un documents contenant le rapport du test. Par chaque composant il existe un rôle gestionnaire responsable de exécution, pour chaque composant procédé. La figure 26 illustre le schéma pour le test avec des éléments décrits au dessus : Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

38 Figure 26 : Le schéma pour test Le composant «test unitaire» est le niveau de test plus bas réalisé pour les classes, les blocs et les paquets de service. Le but composant «test d intégration» est de tester si différentes unités développées fonctionnent correctement ensemble. Chaque composant décris au dessus est composé, à son tour, de sous-composants test dans son domaine d application. Pour simplifier notre exemple, nous considérons le cas où l exécution du test se trouve dans le niveau plus bas, i.e. dans les composants d unité. La création de composants procédés est mené à bien par des fabriques «factory»illustrés par l arbre à gauche de la figure 27. En cours d exécution, une factory en appele une autre pour demander la création d un composant procédé. La phase d exécution est illustré par l arbre à droite, ici le composant test lance l exécution des sous composants test unitaire, il à son tour lance l exécution en parallèle des sous composants test d unité. Le composant test d intégration est mis en exécution, une fois que les test d unité ont fini leur exécution. Figure 27 : Arbres illustrant la création et exécution des sous composants test Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

39 Regardons le comportement de la machine d exécution pour le composant test au travers des diagrammes de séquence suivants : Le composant test demande la liste de composants procédés à la base de données. Après il appelle l outil qui va créer le composant sélectionné. Cet outil va créer l environnement nécessaire pour mener à bien l exécution du composant procédé TestUnitaire, à savoir : le diagramme d états, les variables, etc. En suite un événement est diffusé signalant l existence du nouveau composant TestUnitaire. Test lance l exécution de ce composant, et un autre événement est diffusé signalant le début de l exécution de TestUnitaire. Quand il termine son exécution, l evénément terminé est diffusé via le gestionnaire d événements. Test : Composant Procédé : BaseDonnées TestUnitaire : ComposantProcédé : Environnement de test : Gestionnaire Evénements Démande liste composants nom de l'outil nom de l'outil créer lancer exécution Evénement "création composant" Evénément "début exécution" fin d'exécution Evénement "terminé" Figure 29 Diagramme de séquences pour exécution de Test La figure 29 illustre l intéropérabilité entre des composants basé sur des événements. Le composant test s abonne a des événements fin de l exécution du TestUnitaire et TestIntegration. Le composant testunitaire est en train de s exécuter. Quand le TestUnitaire termine son exécution, un événement «terminé» est diffusé par le gestionnaire d événements, et en suit il renseigne le composant test sur le changement d état. Après, le composant procédé lance l exécution du composant TestIntégration. Cette action déclenche l événement «débutprocédé». La fin de l exécution du composant TestIntégration finalisera le composant Test. Ce composant notifiera aux observateurs abonnés à l événement «terminé Test» afin de que ceux ci déclenchent des actions propres à son exécution. Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

40 Test : Composant Procédé TestUnitaire : Composant Procédé TestIntegration : ComposantProcédé : Gestionnaire Evénements abonnement événement fin d'exécution test unitaire abonnement événement fin d'exécution test fin d'exécution événement "TestUnitaire Terminé" test unitaire a été Terminé lancer exécution événement "débutprocédé" test d'intégration en "exécution" Findel'exécution événement "TestIntégration Terminé" test d'intégration a ététerminé Fin de l'exécution événement " Test Terminé" Figure 30 Diagramme de séquence : interopérabilité entre des composants procédés Le diagramme d état de notre exemple est illustré par la figure ci dessous. Remarquons que tous ces sous composant auront le même comportement, la récursivité est indiquée par la flèche «créer sous composant test». Figure 31 : Diagramme de transition d'état pour le composant test Lizbeth Gallardo DEA Systèmes d Information 20 Septembre

41 Chapitre 4 Prototypage Dans cette section nous allons présenter le prototype permettant la mise en œuvre du modèle de composants procédé. Nous présentons les interfaces de dialogue pour la création d un modèle par composants, et pour la gestion de l exécution de chacun des composants procédés. 4.1 Modèle par composants procédés. Cette fenêtre permet de réaliser la modélisation d'un procédé par sélection de composants procédés. Description. Dans champ «Créer modèle» on doit entrer le nom du modèle à développer. La liste composants disponibles affiche tous les composant procédés disponibles dans la base de données. La liste composants inclus affiche des composants sélectionnés par l utilisateur. Les boutons : Dépendances, Stocker, Exécuter y annuler. Fonctionnalité. On sélectionne les composants à partir de la liste des Composants disponibles. Pour ajouter un composant à la liste de Composants inclus, on appuie sur le bouton «>>». L action inverse «<<»,retire le composant sélectionné de la liste de composants inclus. Les dépendances pour chaque composant sélectionné pourront être remplies en appuyant sur le bouton Dépendances Le bouton Stocker sauvegarde le modèle par composants Le bouton Annuler ferme la fenêtre sans sauvegarder le modèle par composants. Le bouton Exécuter démarre l exécution du modèle par composants. Figure 32 : Fenêtre pour créer un modèle par composants Lizbeth Gallardo DEA Systèmes d Information 20 Septembre