Spécification et transformation de langages de points de vue des systèmes répartis ouverts

Dimension: px
Commencer à balayer dès la page:

Download "Spécification et transformation de langages de points de vue des systèmes répartis ouverts"

Transcription

1 UNIVERSITE MOHAMMED V AGDAL FACULTE DES SCIENCES Service des affaires estudiantines RABAT N d ordre : 2479 Discipline : Informatique Spécialité : Systèmes répartis et réseaux THÈSE DE DOCTORAT Présentée par Youssef BALOUKI Titre de thèse : Spécification et transformation de langages de points de vue des systèmes répartis ouverts Soutenue le 10 février 2010 devant le jury composé de : Président : S. EL HAJJI Professeur (PES) à la Faculté des Sciences Rabat Examinateurs : M. ERRADI Professeur (PES) à l Ecole Nationale Supérieure d Informatique et d analyse des Systèmes Rabat E.M. SOUIDI Professeur (PES) à la Faculté des Sciences Rabat N. ZAHID Professeur (PES) à la Faculté des Sciences Rabat M. BOUHDADI Professeurs (PH) à la Faculté des Sciences Rabat Faculté des Sciences, 4 Avenue Ibn Battouta B.P RP, Rabat-Maroc. Tel : (0) /35/38, Fax : (0) ,

2 à ma fille Lina

3 REMERCIEMENT Les travaux présentés dans cette thèse ont été effectués au sein de l unité de formation et de recherche Mathématiques, Informatique et Applications à la faculté des sciences de Rabat. Je tiens à remercier très vivement Monsieur Mohammed BOUHDADI, Professeur Habilité à la faculté des sciences de Rabat, pour son soutien, sa disponibilité, sa patience, la collaboration étroite dans laquelle nous avons travaillé et son aide qui m ont permis de mener à bien cette thèse. Merci également pour ses relectures minutieuses de ce mémoire. J exprime ma profonde gratitude à Saîd ELHAJJI, professeur à l Université de Rabat, pour l honneur qu il me fait de présider mon jury de thèse. Qu il trouve ici l expression de ma profonde gratitude. Je souhaite remercier M.ERRADI, professeur à l école nationale supérieure d informatique et d analyse des systèmes Rabat, et M.SOUIDI, professeur à l Université de Rabat, pour avoir accepté la lourde charge d être Rapporteur et pour leurs précieuses remarques qui m ont permis d améliorer ce manuscrit. Je tiens à remercier N.ZAHID, professeur à l Université de Rabat, pour l intérêt qu il a tout porté à ce travail. Merci infiniment à tous les membres du Département de Mathématiques et Informatique à la faculté des sciences de Rabat. Mes remerciements vont naturellement à l ensemble des gens que j ai côtoyé durant ces cinq années et qui m ont aidé ou tout simplement rendu le déroulement de cette thèse agréable. En particulier je voudrais remercier mes parents pour leur amour et leur soutien dans les moments difficiles. Je tiens à remercier très chaleureusement ma femme, Bouchra Farah, qui m a beaucoup aidé tout au long de ces cinq années. Je remercie mes frères pour leur amitié et leurs encouragements. Enfin, je tiens à remercier tous ceux qui m ont soutenu, et plus particulièrement ma famille et mes amis. i

4 RESUME Dans un système réparti ouvert, les applications sont capables d'interagir même lorsqu'elles ont été développées dans des environnements différents. Cette capacité ne peut être obtenue que si ces environnements sont conformes à un même modèle conceptuel. Ces besoins constituent le point de départ du travail de la normalisation du modèle de référence pour le traitement réparti ouvert RM-ODP. Cependant, RM-ODP n est pas une méthode, mais bien un ensemble de concepts de spécification et de modélisation. Ses langages de point de vue possèdent une sémantique informelle qui n est décrite qu en langage naturel. Ceci peut provoquer des problèmes d'interprétation et d'ambiguïté. C'est en partant du constat du manque de formalisme des langages ODP et du manque de convivialité des méthodes formelles, que nous avons travaillé autour de l'intégration de ces deux types de méthodes. Afin de contribuer à résoudre cette problématique, nous nous intéressons à la sémantique formelle du modèle de référence ODP pour la rendre plus précise. Nous avons adopté l approche méta-modélisation basé UML/OCL et l approche dénotationnelle pour la spécification précise de la sémantique des langages de point de vue ODP en particulier du langage d entreprise et de traitement. Nous proposons le méta-modèle de la syntaxe abstraite qui se compose des diagrammes de classe et des contraintes OCL, le méta-modèle des instances des modèles en UML/OCL et la relation entre les modèles et leurs instances. Nous avons définit une sémantique formelle pour un sous ensemble de concepts de comportement ODP dans le langage d'entreprise (temps, comportement, action, rôle et processus) en utilisant UML couplé avec le langage de contraintes OCL. Puis, nous avons proposé une méthodologie de modélisation de comportement du langage d'entreprise ODP par la création d un profil UML spécifique. Ce profil sera transformé au langage BPEL. Cette transformation, orientée MDA, va être assurée par l utilisation de l outil Rational rose. Mots clés : RM-ODP, Langages de point de vue, Sémantique dénotationnelle, Comportement, UML/OCL, BPEL ii

5 TABLES DES MATIERES Remerciement... i Résumé... ii Tables des matières... iii Liste des figures... vi Liste des tableaux... vi Liste des abréviations... vii Glossaire... vii Introduction générale... 1 I. Pourquoi un modèle de référence pour le traitement réparti ouvert?... 1 II. Méthodologie de conception pour les systèmes répartis... 4 III. Thème de recherche... 5 IV. Description des travaux réalisés... 6 V. Plan de mémoire... 8 Chapitre I : État de l art I.1. Introduction I.2. Le modèle RM-ODP I.2.1. Présentation générale de RM-ODP I.2.2. Le modèle objet I.2.3. Le modèle architectural I Les points de vue I Point de vue Entreprise I Point de vue Information I Point de vue Traitement I Point de vue Ingénierie I Point de vue Technique I Les langages de points de vue I Le langage d entreprise I Le langage d information I Le langage de traitement I Le langage d ingénierie I Les fonctions ODP I Les transparence ODP I.3. La sémantique formelle I.3.1. La syntaxe I La syntaxe concrète I La syntaxe abstraite I.3.2. Les principales méthodes de description de la sémantique I Sémantique opérationnelle I Sémantique axiomatique(ou predicate transformer) I.3.3. Sémantique dénotationnelle I la composition I Sémantique statique et dynamique iii

6 I L approche dénotationnelle I Syntaxe abstraite I L algèbre sémantique I La relation entre la syntaxe et la sémantique I Exemple : Application sur un langage de spécification QML I La syntaxe abstraite de QML I Algèbre sémantique de QML I Fonctions sémantiques pour QML I.3.4. La cohérence des définitions sémantiques I.4. Méta-modélisation et transformation de modèles I.4.1. Techniques de méta-modélisation I Modèles et méta-modèles I Le besoin de méta-modélisation I Une architecture de méta-modélisation à quatre niveaux I Le MOF : Un langage de définition de méta-modèles I.4.2. Transformation des modèles I.4.3. Les standards pour la manipulation des modèles I Le MOF I Les langages UML et OCL I Les profils UML I Le format d échange normalisé : XMI I.5. Conclusion Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL II.1. Introduction II.2. Travaux connexes II.3. Stratégie de formalisation II.3.1. La convenance du méta-modèle II.3.2. L utilisation du standard II.3.3. La précision de la sémantique de base II.4. RM-ODP II.4.1. Le modèle objet ODP II.4.2. Utilisation des langages de point de vue II.4.3. Le langage d'entreprise RM-ODP II.4.4. Le langage de point de vue traitement RM-ODP II.5. Sémantique dénotationnelle pour le langage de point de vue entreprise II.5.1. Domaine Syntaxique II.5.2. Domaine sémantique II.5.3. La fonction de signification II.6. Sémantique dénotationnelle pour le langage de point de vue traitement II.6.1. Domaine Syntaxique II.6.2. Domaine sémantique II.6.3. La fonction de signification II.7. Conclusion Chapitre III : Une sémantique dénotationnelle pour un sous-ensemble de concepts de comportement du langage d entreprise III.1. Introduction iv

7 III.2. Concepts de modélisation de base du comportement ODP III.3. Meta-modélisation du temps et des contraintes comportementales III.3.1. Temps III.3.2. contraintes Comportementales III Contraintes de séquencement III Contraintes de la concurrence III Contraintes de non-déterminisme III.4. Les politiques de comportement dans le Langage Entreprise RM-ODP III.4.1. Obligation III.4.2. Permission III.4.3. Interdiction III.5. Conclusion Chapitre IV : Utilisation de BPEL pour les concepts comportementaux du langage d entreprise ODP IV.1. Introduction IV.2. Langage d exécution des processus métiers IV.2.1. Introduction au BPM : Business Process Management IV.2.2. Langage BPEL IV.3. La fonction de courtage IV.4. Spécification de la fonction de courtage du point de vue entreprise IV.5. Profil UML pour des processus automatisés de comportement IV.6. Transformation au BPEL IV.6.1. D'UML à BPEL IV.6.2. Exécution du processus de comportement IV.6.3. Démarche de transformation d UML au BPEL IV.6.4. Implémentation du processus de comportement IV La construction et l exportation du modèle IV Génération du BPEL et WSDL IV.7. Conclusion Conclusion générale et perspectives Bibliographie Annexes Annexes A : Grammaire du langage OCL v

8 LISTE DES FIGURES Figure 1 : Modèle architectural de RM-ODP Figure 2 : La spécification au point de vue Ingénierie Figure 3 : Les objets du point de vue Ingénierie Figure 4: La relation entre les points de vue ODP Figure 5 : Types de liaisons Figure 6 : Système de translation d un langage de programmation Figure 7 : Interpréteur Figure 8 : Domaines syntaxiques du langage QML Figure 9 : Domaines sémantiques du langage QML Figure 10 : Fonctions de valuation pour les domaines syntaxiques de QML Figure 11 : Relation entre les diverses sémantiques Figure 12 : L architecture à quatre niveaux Figure 13 : Le MOF version Figure 14 : Transformation de méta-modèle Figure 15 : Le processus de formalisation Figure 16 : RM-ODP Foundation Object Model Figure 17 : Méta-modèle de la syntaxe abstraite du langage d entreprise Figure 18 : Méta-modèle des domaines sémantiques du langage d entreprise Figure 19 : Méta-modèle de la syntaxe abstraite du langage de traitement Figure 20 : Méta-modèle des domaines sémantiques du langage du traitement Figure 21 : Relation entre domaines syntaxique et sémantique des différentes méthodes formelles Figure 22 : Concepts de base de modélisation de comportement Figure 23 : (a) les contraintes déterministes séquentielles (b) les contraintes non déterministes séquentielles Figure 24 : Diagramme RM-ODP - Contraintes de la concurrence Figure 25 : Diagramme RM-ODP - Exemple de contraintes de non-déterminisme Figure 26 : Un méta-modèle pour des concepts de comportement et de politique Figure 27 : Collaboration entre différents acteurs Figure 28 : Méta-modèle du langage BPEL Figure 29 : La fonction de Trading dans ODP Figure 30 : Une classe UML modélise le processus du comportement BPEL Figure 31 : Un diagramme d'activité du processus de comportement Figure 32 : Développement d un processus Figure 33 : Modélisation et Exportation avec XDE Figure 34 : Transformation du fichier XMI Figure 35 : Déploiement du processus Figure 36 : Déploiement des services LISTE DES TABLEAUX Tableau 1 : Mapping entre concepts de comportement et constructions UML Tableau 2 : Mapping entre constructions UML et concepts BPEL vi

9 LISTE DES ABREVIATIONS API BPEL4WS CCM CIM CORBA CWM DCOM DTD EAI EDOC EJB IDM IDL MDA MOF OCL OMG ODP PDM PIM PSM QoS QVT SDL SPEM UML XMI XML Application Program Interface (Business Process Execution Language for Web Services) : le langage de composition de services CORBA Component Model Computation Independent Model Common Object Request Broker Architecture Common Warehouse Metamodel Distributed Component Object Model Document Type Definition Enterprise Application Integration Enterprise Distributed Object Computing Entreprise Java Bean Ingénierie Dirigée par les Modèles Interface Definition Language Model Driven Architecture (Architecture basée sur les modèles ou Architecture dirigée par les modèles) Meta-Object Facility Object Constraint Language Object Management Group Open Distributed Processing Plateform Description Model Platform Independent Model Platform Specifique Model Quality of Service Query View Transformation Specification and Description Language Software Process Engineering Metamodel Unified Modeling Language XML Metadata Interchange extensible Markup Language GLOSSAIRE Architecture Composant Framework Middleware Plate-forme Système L architecture d un système est la spécification de ses différentes parties avec leurs interconnexions qui le constituent. Module logiciel autonome qui assure un service. Ce module peut être installé sur différentes plates-formes. En vue de son utilisation ou de sa réutilisation, il exporte différents attributs ou méthodes sous forme d'interfaces Infrastructure logicielle qui facilite la conception des applications par l'utilisation de bibliothèques de classes ou de générateurs de programmes Permet la communication entre des clients et des serveurs ayant des structures et une implémentation différentes. Il permet l'échange d informations dans tous les cas et pour toutes les architectures. Enfin, le middleware doit fournir un moyen aux clients de trouver leurs serveurs, aux serveurs de trouver leurs clients et en général de trouver n'importe quel objet atteignable Ensemble ou sous-ensemble de systèmes et de technologies qui fournissent un ensemble cohérent de fonctionnalités au travers d interfaces Pris au sens large, il peut s agir d un programme, d un ensemble d applications logicielles, vii

10 INTRODUCTION GENERALE L évolution conjuguée de la technologie des télécommunications et de la structure des organisations conduit à l émergence d applications réparties de grande complexité. Ces applications sont ouvertes pour supporter l'intégration permanente de services sophistiqués et interagir dans de multiples environnements, eux-mêmes évolutifs en permanence. Leur construction, leur déploiement, leur fonctionnement, leur maintenance posent des problèmes difficiles pour lesquels les solutions actuelles sont jugées insuffisantes par les utilisateurs et coûteuses par les opérateurs de services. L environnement d exécution d une application répartie est constitué des systèmes interconnectés généralement hétérogènes. L hétérogénéité technique se caractérise par des machines d architectures différentes, des systèmes d exploitation distincts ou encore des réseaux de nature diverse. L hétérogénéité organisationnelle apparaît lorsque l environnement d exécution relève de domaines d organisation multiples, avec des objectifs, des politiques d usage et de gestion et des contraintes différentes. L interconnexion des systèmes soulève en plus, les problèmes plus classiques de la concurrence, de l asynchronisme, ou de l absence d état global. Maîtriser cette complexité est nécessaire pour supporter des applications constituées de composants, développées par différents acteurs, interagissant et répartis sur des sites distants. L assemblage de tels composants, dont les interactions réalisent les fonctionnalités attendues, donne naissance à des systèmes fortement hétérogènes. L intégration provient de la nécessité de conserver et faire évoluer les applications existantes pour des raisons économiques évidentes et également pour offrir une certaine continuité vis-à-vis des utilisateurs. Cependant, les composants de ces applications ne sont pas toujours homogènes ni propriétaires. Leur réutilisation ou leur coopération pour offrir de nouvelles fonctionnalités reposent sur la capacité d interactions cohérentes de tous leurs composants. L'interaction entre ces composants applicatifs constitue un des aspects du traitement réparti. Plus précisément, Le traitement réparti correspond aux différents aspects du traitement de l'information dans lequel des composants déterminés peuvent être localisés dans des lieux différents et au cours duquel les communications entre composants peuvent subir des délais ou des pannes. 1

11 Introduction générale Lorsque ces composants ont une capacité d'ouverture, on peut alors parler de traitement réparti ouvert. Dans un système réparti ouvert idéal, les applications sont capables d'interagir même lorsqu'elles ont été développées dans des environnements différents (par exemple, ils sont écrits au moyen de langages différents ou développés par des organisations distinctes). Cette capacité ne peut être obtenue que si ces environnements sont conformes à un même modèle conceptuel. Ces besoins constituent le point de départ du travail de la normalisation du modèle de référence pour le traitement réparti ouvert RM-ODP. Les objectifs de RM-ODP sont la répartition, l'inter- fonctionnement et la portabilité. Il fournit un cadre de description des architectures selon plusieurs niveaux d abstraction. Cependant, il ne vise pas à fournir une méthodologie concrète de conception ou de développement. En fait, il n'est qu'un fil banalisant l'ingénierie de systèmes répartis en environnements hétérogènes. C'est une norme qui guide le développement d'autres normes qui permettront à long terme de développer de tels systèmes. I. Pourquoi un modèle de référence pour le traitement réparti ouvert? Parallèlement aux efforts d industriels au sein de l OMG (Object Management Group), le monde de la recherche de son côté, est sollicité pour fournir de nouvelles théories et de nouveaux paradigmes liés à cette évolution. En effet, l effort de normalisation est fourni, au sein de l ISO et de l ITU/T sur le modèle de référence pour le traitement réparti ouvert, pour suivre l évolution et le développement des systèmes répartis. En fait, l ISO et l ITU-T ont d abord activement étudié le problème d interconnexion de systèmes hétérogènes et ont produit le modèle OSI. Ce modèle est structuré en sept couches. Cependant avec la prolifération de nombreux standards applicatifs au niveau de la couche application, il a été constaté que les six premières couches ne fournissent qu un support de communication, et par conséquent un modèle de référence plus général était nécessaire pour traiter tous les aspects relatifs à la répartition d applications : interfaces normalisées entre les composants d applications, plate-forme de répartition et conception de ces applications. En outre, l ensemble des caractéristiques d un système réparti ne couvre pas que des aspects techniques mais recouvre également des aspects organisationnels, puisqu un système peut être réparti en plusieurs organisations. Différentes autorités participent alors à sa réalisation sans control central, d où l hétérogénéité technique s ajoute à l hétérogénéité d entreprise qui s exprime en termes de domaines et d objectifs distincts, de politique d usage et de gestion de contrainte. Dans ce contexte l objectif de la normalisation ODP est de développer une architecture de 1

12 Introduction générale référence pour les systèmes répartis ouverts. Cette architecture serait générique, c'est-à-dire, définie indépendamment de tout domaine d application. Elle prendrait en compte l interfonctionnement, la répartition, la portabilité, la modularité, la sécurité, la transparence et le contrôle de la qualité de service. L ISO a défini la norme RM-ODP. De ce fait, en contraste avec le modèle OSI, le modèle RM-ODP n est pas restreint aux aspects de communication entre systèmes hétérogènes mais traite les problèmes d interaction et d interfonctionnement d applications. RM-ODP permet d assurer l interfonctionnement et la portabilité des applications de façon transparente aux applications elles mêmes. Le modèle identifie en fait les fonctionnalités de la plate-forme de traitement réparti (l environnement d exécution support d ODP) requises pour les interactions de composants d applications ; ces interactions étant ouvertes et transparentes à la répartition. Le principe étant qu un jour, il sera possible d automatiser ce processus de traitement distribué. La construction du modèle RM-ODP est basée sur le principe de la séparation de points de vue. Ce modèle définit une architecture permettant de définir un système selon cinq points de vue qui sont : 1) Le point de vue entreprise (enterprise viewpoint) décrit un système ODP en spécifiant les besoins d un domaine donné. Il porte essentiellement sur l'objectif et la portée du système ainsi que sur les politiques qui lui sont applicables. Elle comprend les objets d'entreprise et les actions de ces objets. 2) Le point de vue information (information viewpoint) spécifie l information gérée et manipulée ainsi que les traitements effectués sur cette information. 3) Le point de vue traitement (computational viewpoint) exprime une décomposition fonctionnelle d un système en termes d objets interagissant via leurs interfaces et ce, en faisant abstraction de la répartition. 4) Le point de vue ingénierie (engineering viewpoint) décrit l infrastructure requise pour mettre en œuvre une spécification de traitement. Il est axé sur les mécanismes et les fonctions qui prennent en charge l interaction répartie des objets du système. 5) Le point de vue technologie (technology viewpoint) est axé sur les choix technologiques de réalisation et d implantation du système. 2

13 Introduction générale Afin de représenter un système ODP selon un point de vue donné, il est nécessaire de définir un ensemble structuré de concepts qui permettent d exprimer la partie de spécification relative à ce point de vue. Cet ensemble forme un langage de point de vue. Les termes de chaque langage et les règles de structuration de ces termes sont définis en utilisant les concepts du modèle objet. Le langage d entreprise : définit les objectifs, le domaine d application et les politiques d un système ODP. Le système ODP et l environnement dans lequel il opère sont représentés par un ou plusieurs objets d entreprise regroupés en une communauté d entreprise liés par un contrat et par les rôles joués par ces objets. Le langage d information : définit la sémantique de l information et la sémantique de traitement de l information dans un système ODP. Celui-ci est exprimé en termes d une configuration d objets d information. Les relations entre les objets d information sont modélisées comme des objets d information ou comme parties des objets d information. Le langage de traitement : est un modèle de programmation réparti abstrait, basé objet pour décrire la structure et l exécution d application répartie dans un environnement ODP. Il constitue une spécialisation du modèle objet en considérant l objet de traitement comme unité de répartition. Une application répartie est alors structurée en un ensemble d objets interagissant à travers leurs interfaces. Le langage de traitement définit un modèle d interaction, des interfaces de traitement et un modèle de liaison. Le langage d ingénierie : permet d'exprimer une spécification d'ingénierie qui définit les fonctions et les mécanismes requis pour prendre en charge l'exécution et l'interaction répartie entre les objets d'un système ODP. Le langage de technologie : décrit la réalisation du système ODP en termes de configuration d'objets techniques qui en représentent les composants matériels et logiciels. Le point de vue technologie fournit ainsi un lien entre l'ensemble des spécifications de points de vue et la réalisation effective en donnant la liste des normes utilisées pour fournir les opérations de base que requièrent les autres spécifications de points de vue. De plus, le modèle contient un ensemble de fonctions s appelant les fonctions ODP. Elles sont au nombre de 24, organisées en 4 catégories qui participent à la simplification de la description du modèle d architecture : 3

14 Introduction générale 1) les fonctions de gestion système qui incluent la gestion des nœuds, d objets, de grappes et de capsules ; 2) les fonctions de référentiel qui incluent les fonctions de stockage, de gestion de base d informations, de conteneurs de types et de courtage ; 3) les fonctions de coordination qui incluent la fonction de notification d événement, de sauvegarde et de reprise, de désactivation, et réactivation, de groupage, de duplication, de migration, de ramasse miettes pour les références d interfaces d ingénierie et de transaction ; 4) les fonctions de sécurité qui incluent les fonctions de contrôle d accès, d audit, d authentification, d intégrité, de confidentialité, de non répudiation et de gestion de clé. II. Méthodologie de conception pour les systèmes répartis Le développement des applications ouvertes dans un environnement réparti (CORBA, OMA) a atteint aujourd'hui un premier niveau de maturité industrielle qui reste cependant limité : l'apparition de chaînes de développement logiciel permettant la fabrique de lignes de produit, à l'instar d'autres industries, n'est pas encore à l'ordre du jour. Cependant des disciplines émergentes y concourent comme l'ingénierie des modèles, confirmée entre autres par l'omg (Object Management Group) et son initiative MDA (Model Driven Architecture). L'Architecture Dirigée par les Modèles est un thème en pleine expansion aussi bien dans le monde académique que dans le monde industriel. Elle apporte un changement important dans la conception des applications, la pérennité des savoir-faire, des gains de productivité et bénéficie des avantages des plates formes existantes. C est une approche qui préconise de construire des applications réparties interopérables via les modèles. L idée est d automatiser la transformation des modèles métier d une application pour en arriver à une solution technique sur une plate-forme de notre choix. Ainsi, en cas de changement d architecture technique, il suffirait de regénérer un autre code du même modèle métier. Pour cela, MDA envisage de construire une chaîne automatisée de production de logiciels. Celle-ci doit être suffisamment outillée pour supporter tout le cycle de vie des applications à réaliser et garantir l industrialisation de leur fabrication. Elle devrait être modulable et générique. De nombreuses techniques manipulant les modèles permettent la mise en œuvre de cette approche (méta-modélisation, transformation de modèles, ). Toutefois, il n existe pas de 4

15 Introduction générale consensus sur une méthodologie pour les appliquer. Parmi celles les plus répandues, la méthodologie ODAC (Open Distributed Applications Construction), orientée MDA, dont l objectif est d assurer une industrialisation de la production logicielle. Généralement ces méthodes permettent le développement de système avec la notation UML selon une sémantique ODP. Cependant, cette sémantique est ambigüe, et pour l essentiel informelle. III. Thème de recherche RM-ODP définit une architecture permettant de construire des systèmes répartis et ouverts. Il est cependant très difficile à appréhender non pas à cause de sa longueur et de ses détails mais parce qu il est très abstrait. Il constitue une méta-norme donc non applicable directement. En effet il n a défini ni quand ni comment produire les spécifications des différents points de vue. Il faut utiliser une méthode de génie logiciel adéquate qui servira d outils permettant de structurer le développement de systèmes ODP. Cela consiste entre autres à situer (à correspondre) les points de vue ODP avec le processus de développement de la méthode. Un objectif majeur est de construire correctement les systèmes ODP, c'est-à-dire que les systèmes ODP doivent être par construction correctes malgré leur complexité. Les différentes spécifications de point de vue correctes et conformes entre elles (techniques de raffinement). Il faut alors que la méthode de génie logiciel utilisée aboutira à des spécifications qu on peut prouver qu elles sont correctes et qu elles sont conformes entre elles. Cependant, RM-ODP n a défini ni de relations de conformité entre les différentes spécifications, ni les moyens de validation et de vérification. Il a néanmoins, défini les concepts de modélisation et de formalisation en utilisant des langages formels standards. Or les langages préconisés ont été conçus pour l ingénierie des protocoles et la conception de systèmes matériels. Il est donc nécessaire de disposer d un formalisme conforme à ODP. Ce formalisme doit être intégré à la méthode de génie logiciel conforme à ODP. Ce que nous avons constaté comme insuffisance ou ce qui manque pour le développement des systèmes ODP ne constitue guère des oublis dans RM-ODP. En fait ce modèle fournit un cadre architectural et une base minimale pour coordonner et guider le développement de nouveaux standards pour le traitement réparti ouvert. Selon le modèle, le traitement réparti correspond aux différents aspects du traitement de l information. RM-ODP est indépendant de tout domaine d application et de toute technologie particulière. Il définit le traitement réparti 5

16 Introduction générale ouvert en se basant sur lui-même. Un traitement réparti ouvert est un traitement conçu conformément aux standards ODP, qui sont RM-ODP et les standards qui lui sont conformes de façons directes ou indirectes. Ces standards incluent : - les standards pour les composants de systèmes ODP ; - les standards pour la composition des systèmes ODP ; - les standards pour la modélisation et la spécification des systèmes ODP ; - les standards pour les langages de programmation ; - les standards pour les tests de systèmes de système ODP ; - la fonction de conteneur de type ; - les références d interfaces ; - le raffinement du langage d entreprise ; - la qualité de service. L objectif de notre thème de recherche est d apporter une solution qui répond à certaines insuffisances précitées. Un deuxième objectif, qui est aussi important, est la transformation de modèles orientée MDA. Nous avons proposé un méta-modèle de la sémantique du langage de point de vue entreprise et un autre pour le langage de traitement fondée sur la description en UML et OCL de sémantiques dénotationnelles. Aussi, avons-nous défini avec précision les concepts de base du comportement dans le langage d entreprise. Puis, nous avons définit un profil UML pour ces concepts de comportement. Ce profil a été mappé avec les concepts du langage BPEL. IV. Description des travaux réalisés Pour aborder ce thème, nous avons eu à étudier les méthodes de génie logiciel, et les techniques de spécification formelle actuelles. Nous en avons déduit que les orientations actuelles sont d'une part l'unification et l'intégration, aussi bien des méthodes de génie logiciel, que des techniques de spécification et de description formelle; d'autre part, leur intégration ensemble. Ces orientations rappellent les tendances du traitement réparti. Le langage UML constitue un modèle de référence pour les langages de modélisation objet. Ses propriétés de généricité et d'extensibilité entre autres, laissent à penser qu UML est 6

17 Introduction générale adéquat pour la modélisation de systèmes ODP. Quant à la spécification formelle de systèmes ODP, les langages préconisés par RM-ODP (Z, SDL, LOTOS, ESTEREL) ne permettent pas de décrire tous les concepts du traitement réparti ouvert. Vu la complexité de problèmes à résoudre, nous avons choisi de traiter un certain nombre de problèmes représentatifs liés aux points de vue ODP. Chaque point de vue présente un nombre de problèmes en plus des problèmes communs. Nous avons choisi l approche de méta modélisation de la syntaxe dans la définition d UML. Nous supposons que cette syntaxe est indépendante du contexte [1,2]. Nous avons traité plusieurs problèmes : - L utilisation du langage OCL dans le processus de développement de systèmes ODP (plus particulièrement le point de vue entreprise et traitement) ; - La sémantique formelle des langages de point de vue (le point de vue entreprise et traitement) ; - La définition précise des concepts de base du comportement de point de vue entreprise ; - La transformation de modèles (le point de vue entreprise). Nous avons traité dans un premier point l utilisation d OCL dans l ingénierie des systèmes ODP. En effet, l intégration et l unification aussi bien des méthodes de génie logiciel que des méthodes formelles laissent penser que le langage OCL peut être utilisé dans l ingénierie des systèmes ODP plus particulièrement pour la spécification formelle de la sémantique ODP. En deuxième lieu, nous avons définit la spécification formelle des langages de point de vue en utilisant l approche dénotationnelle. Nous avons séparé entre la syntaxe et la sémantique. D abord, nous avons supposé que la syntaxe est indépendante du contexte et nous avons traité le problème de la syntaxe contextuelle pour les différents concepts de structure des langages d entreprise et de traitement. En troisième lieu, nous avons défini avec précision les concepts de base du comportement de point de vue entreprise d ODP en ajoutant des contraintes de séquencement, de nondéterminisme et de la concurrence utilisant le langage OCL et en définissant des politiques sous forme de contraintes OCL sur le comportement du système ODP. 7

18 Introduction générale En dernier lieu, la spécification du comportement établie a été transformée en spécification opérationnelle dans un environnement d exécution cible en utilisant le langage BPEL. La transformation utilisée est de type transformation méta-modèle. V. Plan de mémoire Dans le premier chapitre constituant l état de l art des travaux relatifs à notre sujet, nous présentons seulement les concepts et principes nécessaires à la compréhension de notre propos et nous donnons des pointeurs vers les sources permettant au lecteur d approfondir ses connaissances sur le sujet. Dans un premier temps, nous exposons le modèle de référence pour le traitement réparti ouvert RM-ODP. Nous introduisons ensuite la sémantique formelle mettant l accent essentiellement sur l approche dénotationnelle. Enfin, nous donnons un résumé sur les récentes avancées qui ont eu lieu dans le domaine de méta-modélisation et de transformation de modèles. Dans le chapitre 2, nous traitons la nécessité de la notation formelle des langages de point de vue ODP. Ces langages sont des langages abstraits dans la mesure où ils définissent les concepts qui devraient être employés, mais pas comment devraient-ils être représentés. Une définition formelle des langages de point de vue ODP permet de tester la conformité des spécifications de différents points de vue, d'analyser et vérifier formellement les spécifications produites, et de dériver des implémentations possibles à partir des spécifications de système. Nous avons adopté l approche dénotationnelle pour la spécification précise de la sémantique d un sous ensemble de concepts de structure dans les deux points de vue entreprise et traitement. Nous proposons le méta-modèle de la syntaxe abstraite qui se compose des diagrammes de classe et des contraintes OCL, le méta-modèle de la sémantique en UML/OCL et nous définissons la fonction sens entre les modèles et leurs instances en utilisant OCL. Le chapitre 3 propose de définir une sémantique formelle pour un sous ensemble de concepts de comportement ODP cités dans la partie fondements RM-ODP[1,2,3,4] en particulier dans le langage d'entreprise en utilisant le langage de modélisation unifié UML, couplé avec le langage de contraintes OCL. Nous commençons par une analyse des concepts comportementaux RM-DOP centrés sur la représentation et la spécification de comportement, de temps, d action, de rôle et de processus, nous donnons par la suite des définitions précises pour les contraintes de séquencement, de non-déterminisme et de la concurrence et nous 8

19 Introduction générale terminons par la définition des politiques qui peuvent être utilisées pour identifier la spécification des contraintes sur le comportement du système ODP. Dans le chapitre 4, nous allons décrire la méthodologie de modélisation de comportement du langage d'entreprise ODP par la création d un profil UML. Nous allons présenter le profil UML spécifique au comportement. Ce profil sera transformé au langage BPEL en faisant un mapping entre les concepts du comportement du langage d'entreprise et les concepts du langage BPEL, cette transformation, orientée MDA, va être assurée par l utilisation de l outil Rational rose. Finalement, Nous concluons ce travail en récapitulant les résultats obtenus et en évoquant différentes possibilités de continuation et d extension de travail déjà réalisé. 9

20 CHAPITRE I : ÉTAT DE L ART I.1. Introduction La croissance rapide des applications réparties a fait naître le besoin d'un cadre pour coordonner la normalisation du traitement réparti ouvert (ODP, open distributed processing). Le modèle de référence ODP fournit ce cadre et il établit une architecture qui permet la prise en compte de la répartition, de l'interfonctionnement et de la portabilité. Le modèle de référence pour le traitement réparti ouvert (RM-ODP, reference model of open distributed processing) repose sur des concepts précis issus des développements récents dans le domaine des traitements répartis et s'appuie, dans la mesure du possible, sur l'utilisation des techniques de descriptions formelles pour la spécification de l'architecture. Les méthodes formelles existent depuis plusieurs décennies et ont pour finalité la description de systèmes logiciels de façon plus mathématique. L utilité des descriptions formelles est de faciliter la compréhension des langages, la conception et la spécification d un système, la vérification et la validation des spécifications. En contrepartie, leur difficulté d apprentissage et d utilisation leur a souvent été reprochée. La sémantique a une importance décisive sur la spécification d un système. La théorie des sémantiques doit contribuer à une spécification et vérification de systèmes de manière systématique. Les sémantiques formelles peuvent être classées selon trois catégories complémentaires: Opérationnelles, Axiomatiques, Algébriques ou Dénotationnelles. Chacune d'elles s'apprête mieux à un certain type de tâches. La méta-modélisation est une technique de définition des concepts à utiliser pour modéliser des systèmes. Elle apporte donc la flexibilité nécessaire à la fourniture de moyens adaptés aux besoins d un processus logiciel, pour concevoir des applications. 10

Méthode B pour la Spécification et la vérification formelle des systèmes répartis ouverts

Méthode B pour la Spécification et la vérification formelle des systèmes répartis ouverts UNIVERSITE MOHAMMED V AGDAL FACULTE DES SCIENCES Service des affaires estudiantines RABAT N d ordre : 2577 THÈSE DE DOCTORAT Discipline : Informatique Spécialité : Systèmes répartis ouverts Hafid BELHAJ

Plus en détail

La démarche MDA. Auteur : Projet ACCORD (Assemblage de composants par contrats en environnement ouvert et réparti)*

La démarche MDA. Auteur : Projet ACCORD (Assemblage de composants par contrats en environnement ouvert et réparti)* La démarche MDA Auteur : Projet ACCORD (Assemblage de composants par contrats en environnement ouvert et réparti)* Référence : Livrable 1.1-5 Date : Mai 2002 * : Les partenaires du projet ACCORD sont CNAM,

Plus en détail

basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML

basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML http://olivier-augereau.com Sommaire Introduction I) Les bases II) Les diagrammes

Plus en détail

Chapitre I : le langage UML et le processus unifié

Chapitre I : le langage UML et le processus unifié I. Introduction Les méthodes d analyse orientées objet sont initialement issues des milieux industriels. La préoccupation dominante de leurs auteurs est le génie logiciel, c est-àdire les principes et

Plus en détail

MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE»

MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE» MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE» Du cours Modélisation Semi -Formelle de Système d Information Du Professeur Jean-Pierre GIRAUDIN Décembre. 2002 1 Table de matière Partie 1...2 1.1

Plus en détail

Ingénierie des Modèles. Méta-modélisation

Ingénierie des Modèles. Méta-modélisation Ingénierie des Modèles Méta-modélisation Eric Cariou Master Technologies de l'internet 2 ème année Université de Pau et des Pays de l'adour UFR Sciences Pau Département Informatique Eric.Cariou@univ-pau.fr

Plus en détail

IFT2255 : Génie logiciel

IFT2255 : Génie logiciel IFT2255 : Génie logiciel Chapitre 6 - Analyse orientée objets Section 1. Introduction à UML Julie Vachon et Houari Sahraoui 6.1. Introduction à UML 1. Vers une approche orientée objet 2. Introduction ti

Plus en détail

Université de Bangui. Modélisons en UML

Université de Bangui. Modélisons en UML Université de Bangui CRM Modélisons en UML Ce cours a été possible grâce à l initiative d Apollinaire MOLAYE qui m a contacté pour vous faire bénéficier de mes connaissances en nouvelles technologies et

Plus en détail

Conception, architecture et urbanisation des systèmes d information

Conception, architecture et urbanisation des systèmes d information Conception, architecture et urbanisation des systèmes d information S. Servigne Maître de Conférences, LIRIS, INSA-Lyon, F-69621 Villeurbanne Cedex e-mail: sylvie.servigne@insa-lyon.fr 1. Introduction

Plus en détail

MDA (Model Driven Architecture) principes et états de l art.

MDA (Model Driven Architecture) principes et états de l art. CONSERVATOIRE NATIONAL DES ARTS ET MÉTIERS CENTRE D ENSEIGNEMENT DE LYON Examen probatoire du diplôme d ingénieur C.N.A.M. en INFORMATIQUE option ingénierie et intégration informatique : système de conduite

Plus en détail

Architecture d'entreprise : Guide Pratique de l'architecture Logique

Architecture d'entreprise : Guide Pratique de l'architecture Logique Guides Pratiques Objecteering Architecture d'entreprise : Guide Pratique de l'architecture Logique Auteur : Version : 1.0 Copyright : Softeam Equipe Conseil Softeam Supervisée par Philippe Desfray Softeam

Plus en détail

Programme scientifique Majeure ARCHITECTURE DES SYSTEMES D INFORMATION. Mentions Ingénierie des Systèmes d Information Business Intelligence

Programme scientifique Majeure ARCHITECTURE DES SYSTEMES D INFORMATION. Mentions Ingénierie des Systèmes d Information Business Intelligence É C O L E D I N G É N I E U R D E S T E C H N O L O G I E S D E L I N F O R M A T I O N E T D E L A C O M M U N I C A T I O N Programme scientifique Majeure ARCHITECTURE DES SYSTEMES D INFORMATION Mentions

Plus en détail

Objectif : Passer de l analyse métier et fonctionnelle à la définition des applications qui

Objectif : Passer de l analyse métier et fonctionnelle à la définition des applications qui Formation PARTIE 1 : ARCHITECTURE APPLICATIVE DUREE : 5 h Objectif : Passer de l analyse métier et fonctionnelle à la définition des applications qui automatisent les fonctions Définir une architecture

Plus en détail

Description de la formation

Description de la formation Description de la formation Modalités Ce parcours de formation est un parcours en alternance, d une durée de 2ans, à raison d une semaine de formation par mois, soit 770 heures et de trois semaines de

Plus en détail

CORBA. (Common Request Broker Architecture)

CORBA. (Common Request Broker Architecture) CORBA (Common Request Broker Architecture) Projet MIAGe Toulouse Groupe 2 1 CORBA, introduction (1/4) Les systèmes répartis permettent de créer des applications basées sur des composants auto-gérables,

Plus en détail

D une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information.

D une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information. PACBASE «Interrogez le passé, il répondra présent.». Le Module e-business Les entreprises doivent aujourd hui relever un triple défi. D une part, elles ne peuvent faire table rase de la richesse contenue

Plus en détail

Analyse,, Conception des Systèmes Informatiques

Analyse,, Conception des Systèmes Informatiques Analyse,, Conception des Systèmes Informatiques Méthode Analyse Conception Introduction à UML Génie logiciel Définition «Ensemble de méthodes, techniques et outils pour la production et la maintenance

Plus en détail

Les nouvelles architectures des SI : Etat de l Art

Les nouvelles architectures des SI : Etat de l Art Les nouvelles architectures des SI : Etat de l Art Objectif Mesurer concrètement les apports des nouvelles applications SI. Être capable d'évaluer l'accroissement de la complexité des applications. Prendre

Plus en détail

Oracle Fusion Middleware Concepts Guide 11g Release 1 (11.1.1) Figure 1-1 Architecture Middleware

Oracle Fusion Middleware Concepts Guide 11g Release 1 (11.1.1) Figure 1-1 Architecture Middleware 1 Introduction Ce chapitre décrit Oracle Fusion Middleware. Il comprend : o Qu'est-ce que Middleware o Les fonction de Middleware o L'architecture de conception Middleware o L'architecture orientée services

Plus en détail

L approche Model-Driven Architecture, crédible pour développer un progiciel de

L approche Model-Driven Architecture, crédible pour développer un progiciel de ÉCOLE DOCTORALE SYSTÈMES L approche Model-Driven Architecture, crédible pour développer un progiciel de gestion intégré Mémoire de DEA Systèmes Industriels Tuteur : Paul Gaborit Xavier Moghrabi Année universitaire

Plus en détail

En vue de l obtention du. Discipline : Informatique. Présentée et soutenue par Mohamed HADJ KACEM. Le Jeudi 13 Novembre 2008

En vue de l obtention du. Discipline : Informatique. Présentée et soutenue par Mohamed HADJ KACEM. Le Jeudi 13 Novembre 2008 THÈSE En vue de l obtention du DOCTORAT DE L UNIVERSITÉ DE TOULOUSE ET DE L UNIVERSITÉ DE SFAX Délivré par l Université Toulouse III - Paul Sabatier et la Faculté des Sciences Économiques et de Gestion

Plus en détail

Extensions à la formation. Laurent Pérochon, 28-30 avril 2008, RMT Modelia, modélisation conceptuelle, formation UML, INRA Castanet Tolosan

Extensions à la formation. Laurent Pérochon, 28-30 avril 2008, RMT Modelia, modélisation conceptuelle, formation UML, INRA Castanet Tolosan Extensions à la formation Diagramme de timing FinEpreuve SautBarrière CourseAvantBarrière SautMur {>2 et 10 et 2 et 10 et

Plus en détail

Le génie logiciel. maintenance de logiciels.

Le génie logiciel. maintenance de logiciels. Le génie logiciel Définition de l IEEE (IEEE 1990): L application d une approche systématique, disciplinée et quantifiable pour le développement, l opération et la maintenance de logiciels. Introduction

Plus en détail

Méthodologies de développement de logiciels de gestion

Méthodologies de développement de logiciels de gestion Méthodologies de développement de logiciels de gestion Chapitre 5 Traits caractéristiques des deux approches de méthodologie Présentation réalisée par P.-A. Sunier Professeur à la HE-Arc de Neuchâtel http://lgl.isnetne.ch

Plus en détail

Démarches d urbanisation : réorganiser le Système d Information en structurant ses fonctions dans des blocs fonctionnels communicants.

Démarches d urbanisation : réorganiser le Système d Information en structurant ses fonctions dans des blocs fonctionnels communicants. Plan du chapitre Master Informatique et Systèmes Urbanisation des Systèmes d Information Architecture d Entreprise 04 Architecture du SI : identifier et décrire les services, structurer le SI 1 2 3 4 5

Plus en détail

Visual Paradigm Contraintes inter-associations

Visual Paradigm Contraintes inter-associations Visual Paradigm Contraintes inter-associations Travail de Bachelor d'informaticien de gestion Partie C Présentation de Visual Paradigm 1 Présentation de Visual Paradigm For UML L objet du travail de Bachelor

Plus en détail

Conception des systèmes répartis

Conception des systèmes répartis Conception des systèmes répartis Principes et concepts Gérard Padiou Département Informatique et Mathématiques appliquées ENSEEIHT Octobre 2012 Gérard Padiou Conception des systèmes répartis 1 / 37 plan

Plus en détail

openarchitectureware & transformation de modèle Yannick Lizzi Architecte Logiciel itemis France Mail: lizzi@itemis.de

openarchitectureware & transformation de modèle Yannick Lizzi Architecte Logiciel itemis France Mail: lizzi@itemis.de openarchitectureware & transformation de modèle Yannick Lizzi Architecte Logiciel itemis France Mail: lizzi@itemis.de itemis France 2009 All rights reserved 1 Itemis en quelques mots Spécialisé dans l

Plus en détail

Démarches d urbanisation : réorganiser le Système d Information en structurant ses fonctions dans des blocs fonctionnels communicants.

Démarches d urbanisation : réorganiser le Système d Information en structurant ses fonctions dans des blocs fonctionnels communicants. Plan du chapitre Master Informatique et Systèmes Urbanisation des Systèmes d Information Architecture d Entreprise 04 Architecture du SI : identifier et décrire les services, structurer le SI 1 2 3 4 5

Plus en détail

Workflow et Service Oriented Architecture (SOA)

Workflow et Service Oriented Architecture (SOA) White Paper Workflow et Service Oriented Architecture (SOA) Présentation Cet article offre une approche pragmatique de la SOA et du workflow à travers des problématiques d'entreprises, une méthodologie

Plus en détail

Nom de l application

Nom de l application Ministère de l Enseignement Supérieur et de la Recherche Scientifique Direction Générale des Etudes Technologiques Institut Supérieur des Etudes Technologiques de Gafsa Département Technologies de l Informatique

Plus en détail

Université de Lausanne

Université de Lausanne Université de Lausanne Records management et archivage électronique : cadre normatif Page 2 Ce qui se conçoit bien s énonce clairement Nicolas Boileau Page 3 Table des matières Qu est- ce que le «records

Plus en détail

Information utiles. cinzia.digiusto@gmail.com. webpage : Google+ : http://www.ibisc.univ-evry.fr/ digiusto/

Information utiles. cinzia.digiusto@gmail.com. webpage : Google+ : http://www.ibisc.univ-evry.fr/ digiusto/ Systèmes de gestion de bases de données Introduction Université d Evry Val d Essonne, IBISC utiles email : cinzia.digiusto@gmail.com webpage : http://www.ibisc.univ-evry.fr/ digiusto/ Google+ : https://plus.google.com/u/0/b/103572780965897723237/

Plus en détail

Urbanisation des Systèmes d Information Architecture d Entreprise. 04 Architecture du SI : identifier et décrire les services, structurer le SI

Urbanisation des Systèmes d Information Architecture d Entreprise. 04 Architecture du SI : identifier et décrire les services, structurer le SI Plan du chapitre Master Informatique et Systèmes Urbanisation des Systèmes d Information Architecture d Entreprise 04 Architecture du SI : identifier et décrire les services, structurer le SI 1 2 3 1.1

Plus en détail

Plan. Exemple: Application bancaire. Introduction. OCL Object Constraint Language Le langage de contraintes d'uml

Plan. Exemple: Application bancaire. Introduction. OCL Object Constraint Language Le langage de contraintes d'uml OCL Object Constraint Language Le langage de contraintes d'uml Plan 1. Introduction 2. Les principaux concepts d'ocl Object Constraint Language 1 Object Constraint Language 2 Exemple: une application bancaire

Plus en détail

Chapitre 1 : Introduction aux bases de données

Chapitre 1 : Introduction aux bases de données Chapitre 1 : Introduction aux bases de données Les Bases de Données occupent aujourd'hui une place de plus en plus importante dans les systèmes informatiques. Les Systèmes de Gestion de Bases de Données

Plus en détail

ISO/CEI 19770-1. Technologies de l information Gestion des actifs logiciels. Partie 1: Procédés et évaluation progressive de la conformité

ISO/CEI 19770-1. Technologies de l information Gestion des actifs logiciels. Partie 1: Procédés et évaluation progressive de la conformité NORME INTERNATIONALE ISO/CEI 19770-1 Deuxième édition 2012-06-15 Technologies de l information Gestion des actifs logiciels Partie 1: Procédés et évaluation progressive de la conformité Information technology

Plus en détail

THESE. DOCTORAT EN SCIENCES APPLIQUEES Spécialité : Informatique

THESE. DOCTORAT EN SCIENCES APPLIQUEES Spécialité : Informatique mi Université Mohamed V- Souissi Rabat Ecole Nationale Supérieure d Informatique et d Analyse des Systèmes Numéro d ordre : ---- UFR : Systèmes d Information Métiers, Multimédia et Mobiles (SI3M) -ENSIAS-

Plus en détail

Rational Unified Process

Rational Unified Process Rational Unified Process For Christiane DAVOINE-GUHUR Société GICAB - Vannes Christiane.Davoine@CA-GICAB.fr Table des Matières 1 INTRODUCTION... 1 2 LES COMPOSANTS ET LES GRANDS PRINCIPES DU PROCESSUS...

Plus en détail

CATALOGUE FORMATION. Product Lifecycle Management. Juin 2013

CATALOGUE FORMATION. Product Lifecycle Management. Juin 2013 CATALOGUE FORMATION Product Lifecycle Management Juin 2013 s de formation ENOVIA V6 ENOVIA V6 Plateforme Collaborative 5 ENOVIA V6 Installation et Administration 9 ENOVIA V6 Implémentation et Développement

Plus en détail

URBANISME DES SYSTÈMES D INFORMATION

URBANISME DES SYSTÈMES D INFORMATION FAYCAL AYECH GL2. INSAT 2010/2011 INTRODUCTION AUX SYSTÈMES D INFORMATIONS URBANISME DES SYSTÈMES D INFORMATION De l Urbanisme à L Urbanisation des SI Urbanisme : Mise en œuvre des politiques urbaines

Plus en détail

SECTION 5 BANQUE DE PROJETS

SECTION 5 BANQUE DE PROJETS SECTION 5 BANQUE DE PROJETS INF 4018 BANQUE DE PROJETS - 1 - Banque de projets PROJET 2.1 : APPLICATION LOGICIELLE... 3 PROJET 2.2 : SITE WEB SÉMANTIQUE AVEC XML... 5 PROJET 2.3 : E-LEARNING ET FORMATION

Plus en détail

Christian Soutou UML 2. pour les. bases de données. Avec 20 exercices corrigés. Groupe Eyrolles, 2007, ISBN : 978-2-212-12091-2

Christian Soutou UML 2. pour les. bases de données. Avec 20 exercices corrigés. Groupe Eyrolles, 2007, ISBN : 978-2-212-12091-2 Christian Soutou UML 2 pour les bases de données Avec 20 exercices corrigés Groupe Eyrolles, 2007, ISBN : 978-2-212-12091-2 Chapitre 4 Outils du marché : de la théorie à la pratique Non mais t as déjà

Plus en détail

Cycle de vie du logiciel. Unified Modeling Language UML. UML: définition. Développement Logiciel. Salima Hassas. Unified Modeling Language

Cycle de vie du logiciel. Unified Modeling Language UML. UML: définition. Développement Logiciel. Salima Hassas. Unified Modeling Language Unified Modeling Language UML Salima Hassas Version Cycle de vie du logiciel Client Besoins Déploiement Analyse Test Conception Cours sur la base des transparents de : Gioavanna Di Marzo Serugendo et Frédéric

Plus en détail

Sujet de thèse CIFRE RESULIS / LGI2P

Sujet de thèse CIFRE RESULIS / LGI2P Ecole des Mines d Alès Laboratoire de Génie Informatique et d Ingénierie de Production LGI2P Nîmes Sujet de thèse CIFRE RESULIS / LGI2P Titre Domaine De l ingénierie des besoins à l ingénierie des exigences

Plus en détail

Patrons de Conception (Design Patterns)

Patrons de Conception (Design Patterns) Patrons de Conception (Design Patterns) Introduction 1 Motivation Il est difficile de développer des logiciels efficaces, robustes, extensibles et réutilisables Il est essentiel de comprendre les techniques

Plus en détail

Prise en compte des ressources dans les composants logiciels parallèles

Prise en compte des ressources dans les composants logiciels parallèles Prise en compte des ressources dans les composants logiciels parallèles Aperçus de l action RASC et du projet Concerto F. Guidec Frederic.Guidec@univ-ubs.fr Action RASC Plan de cet exposé Contexte Motivations

Plus en détail

Mineure Architectures Orientées Services SOA Business Process Modeling (BPM) Mineure SOA. Business Process Modeling (BPM)

Mineure Architectures Orientées Services SOA Business Process Modeling (BPM) Mineure SOA. Business Process Modeling (BPM) Mineure SOA Business Process Modeling (BPM) Idir AIT SADOUNE idir.aitsadoune@supelec.fr Idir AIT SADOUNE - Plan 1 Notion de processus? 2 Modélisation des processus? 3 Langages

Plus en détail

Business Process Execution Language

Business Process Execution Language Business Process Execution Language Rapport du projet de systèmes distribués d information Markus Lindström 6 mai 2009 Motivation personnelle Le sujet que j ai retenu et présenté dans le cadre du cours

Plus en détail

NFP111 Systèmes et Applications Réparties

NFP111 Systèmes et Applications Réparties NFP111 Systèmes et Applications Réparties 1 de 34 NFP111 Systèmes et Applications Réparties Cours 7 - CORBA/Partie 1 Claude Duvallet Université du Havre UFR Sciences et Techniques 25 rue Philippe Lebon

Plus en détail

Chapitre 5 Vision Informatique Logique Architectures Applicative et Logicielle

Chapitre 5 Vision Informatique Logique Architectures Applicative et Logicielle Chapitre 5 Vision Informatique Logique Architectures Applicative et Logicielle NFE107 Chapitre 5 Vision Informatique Logique Architectures Applicative et Logicielle 5.1 Introduction Positionnement de la

Plus en détail

Business Process Modeling (BPM)

Business Process Modeling (BPM) Business Process Modeling (BPM) Mineure SOA Cécile Hardebolle cecile.hardebolle@supelec.fr Programme 8 nov. 15 nov. Introduction. Enjeux, rôle de l'architecte SI Partie n 1 du cas d'étude Architecture

Plus en détail

PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN

PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN 1. DÉVELOPPEMENT D'APPLICATION (CONCEPTEUR ANALYSTE) 1.1 ARCHITECTURE MATÉRIELLE DU SYSTÈME INFORMATIQUE 1.1.1 Architecture d'un ordinateur Processeur,

Plus en détail

Software Engineering and Middleware A Roadmap

Software Engineering and Middleware A Roadmap Software Engineering and Middleware A Roadmap Ecrit par: Dr. Wolfgang Emmerich Présenté par : Mustapha Boushaba Cours : IFT6251 Wolfgang Emmerich Enseignant à University College London: Distributed Systems

Plus en détail

INF 1250 INTRODUCTION AUX BASES DE DONNÉES. Guide d étude

INF 1250 INTRODUCTION AUX BASES DE DONNÉES. Guide d étude INF 1250 INTRODUCTION AUX BASES DE DONNÉES Guide d étude Sous la direction de Olga Mariño Télé-université Montréal (Québec) 2011 INF 1250 Introduction aux bases de données 2 INTRODUCTION Le Guide d étude

Plus en détail

Annuaires LDAP et méta-annuaires

Annuaires LDAP et méta-annuaires Annuaires LDAP et méta-annuaires Laurent Mynard Yphise 6 rue Beaubourg - 75004 PARIS yphise@yphise.com - http://yphise.fr T 01 44 59 93 00 F 01 44 59 93 09 LDAP020314-1 Agenda A propos d Yphise Les annuaires

Plus en détail

Développement d un interpréteur OCL pour une machine virtuelle UML.

Développement d un interpréteur OCL pour une machine virtuelle UML. ObjeXion Software Prototyping made easy SA au capital de 500 000 F Siret 421 565 565 00015 APE 722Z Téléphone : 03 89 35 70 75 Télécopie : 03 89 35 70 76 L embarcadère 5, rue Gutemberg 68 800 Vieux-Thann,

Plus en détail

Fiche méthodologique Rédiger un cahier des charges

Fiche méthodologique Rédiger un cahier des charges Fiche méthodologique Rédiger un cahier des charges Plan de la fiche : 1 : Présentation de la fiche 2 : Introduction : les grands principes 3 : Contenu, 1 : positionnement et objectifs du projet 4 : Contenu,

Plus en détail

OASIS www.oasis-open.org/committees/xacml/docs/docs.shtml Date de publication

OASIS www.oasis-open.org/committees/xacml/docs/docs.shtml Date de publication Statut du Committee Working Draft document Titre XACML Language Proposal, version 0.8 (XACML : XML Access Control Markup Language) Langage de balisage du contrôle d'accès Mot clé Attestation et sécurité

Plus en détail

CC30 Certificat de compétence Conception, développement et animation de sites Web

CC30 Certificat de compétence Conception, développement et animation de sites Web CC30 Certificat de compétence Conception, développement et animation de sites Web UE RSX050 Bases de l informatique Séance 2 UERSX050 Bases de l informatique séance 2-30/10/2009 1 Table des matières Séance

Plus en détail

Proposition de sujet de thèse CIFRE EUROCOPTER / LGI2P

Proposition de sujet de thèse CIFRE EUROCOPTER / LGI2P EUROCOPTER SAS Groupe EADS Marignane Ecole des Mines d Alès Laboratoire de Génie Informatique et d Ingénierie de Production LGI2P Nîmes Proposition de sujet de thèse CIFRE EUROCOPTER / LGI2P Titre Domaine

Plus en détail

INDUSTRIALISATION ET RATIONALISATION

INDUSTRIALISATION ET RATIONALISATION INDUSTRIALISATION ET RATIONALISATION A. LA PROBLEMATIQUE La mission de toute production informatique est de délivrer le service attendu par les utilisateurs. Ce service se compose de résultats de traitements

Plus en détail

Projet 2. Gestion des services enseignants CENTRE D ENSEIGNEMENT ET DE RECHERCHE EN INFORMATIQUE. G r o u p e :

Projet 2. Gestion des services enseignants CENTRE D ENSEIGNEMENT ET DE RECHERCHE EN INFORMATIQUE. G r o u p e : CENTRE D ENSEIGNEMENT ET DE RECHERCHE EN INFORMATIQUE Projet 2 Gestion des services enseignants G r o u p e : B E L G H I T Y a s m i n e S A N C H E Z - D U B R O N T Y u r i f e r M O N T A Z E R S i

Plus en détail

Messagerie asynchrone et Services Web

Messagerie asynchrone et Services Web Article Messagerie asynchrone et Services Web 1 / 10 Messagerie asynchrone et Services Web SOAP, WSDL SONT DES STANDARDS EMERGEANT DES SERVICES WEB, LES IMPLEMENTATIONS DE CEUX-CI SONT ENCORE EN COURS

Plus en détail

Projet Active Object

Projet Active Object Projet Active Object TAO Livrable de conception et validation Romain GAIDIER Enseignant : M. Noël PLOUZEAU, ISTIC / IRISA Pierre-François LEFRANC Master 2 Informatique parcours MIAGE Méthodes Informatiques

Plus en détail

Classeur de suivi de l auditeur. Architecture et Ingénierie des Systèmes et des Logiciels

Classeur de suivi de l auditeur. Architecture et Ingénierie des Systèmes et des Logiciels Classeur de suivi de l auditeur Architecture et Ingénierie des Systèmes et des Logiciels 04/12/2012 2 Sommaire Introduction... 4 Objectifs... 4 Méthodologie... 4 Coordonnées... 5 Curriculum vitae de l

Plus en détail

Management des processus opérationnels

Management des processus opérationnels Ecole Nationale Supérieure de Management Master Management des organisations Management des processus opérationnels Dr TOUMI Djamila Cours n 2: la modélisation des processus opérationnels INTRODUCTION

Plus en détail

1 JBoss Entreprise Middleware

1 JBoss Entreprise Middleware 1 JBoss Entreprise Middleware Les produits de la gamme JBoss Entreprise Middleware forment une suite de logiciels open source permettant de construire, déployer, intégrer, gérer et présenter des applications

Plus en détail

Les Architectures Orientées Services (SOA)

Les Architectures Orientées Services (SOA) Les Architectures Orientées Services (SOA) Ulrich Duvent Guillaume Ansel Université du Littoral Côte d Opale 50, Rue Ferdinand Buisson BP 699 62228 Calais Cedex Téléphone (33) 03.21.46.36.92 Télécopie

Plus en détail

La technologie BPM. Qu'est-ce que la technologie BPM? AVRIL 2006

La technologie BPM. Qu'est-ce que la technologie BPM? AVRIL 2006 La technologie BPM Devant la quête incessante de productivité et le manque de vision globale entre les différents processus aboutissant à la mise sur le marché d'un nouveau produit, les entreprises font

Plus en détail

Le 09 et 10 Décembre 09

Le 09 et 10 Décembre 09 Séminaire de 2 jours Le 09 et 10 Décembre 09 Mettez les évolutions technologiques au service de vos objectifs métier 2 OXIA a pour mission de concevoir et mettre en œuvre les meilleures solutions technologiques

Plus en détail

NORME INTERNATIONALE

NORME INTERNATIONALE NORME INTERNATIONALE ISO/CEl 1700 Première édition 1997-06-l 5 Technologies de l information - Interconnexion de systèmes ouverts (OSI) - Protocole de couche réseau ((Fast Byte» Information technology

Plus en détail

Chapitre 9 : Informatique décisionnelle

Chapitre 9 : Informatique décisionnelle Chapitre 9 : Informatique décisionnelle Sommaire Introduction... 3 Définition... 3 Les domaines d application de l informatique décisionnelle... 4 Architecture d un système décisionnel... 5 L outil Oracle

Plus en détail

Architecture à base de composants pour le déploiement adaptatif des applications multicomposants

Architecture à base de composants pour le déploiement adaptatif des applications multicomposants Architecture à base de composants pour le déploiement adaptatif des applications multicomposants Dhouha Ayed, Chantal Taconet, et Guy Bernard GET / INT, CNRS Samovar 5157 9 rue Charles Fourier 91011 Évry,

Plus en détail

Le Guide Pratique des Processus Métiers

Le Guide Pratique des Processus Métiers Guides Pratiques Objecteering Le Guide Pratique des Processus Métiers Auteur : Version : 1.0 Copyright : Softeam Equipe Conseil Softeam Supervisée par Philippe Desfray Softeam 21 avenue Victor Hugo 75016

Plus en détail

- Couches - Éléments - Domaines - ArchiMate et les techniques du BABOK

- Couches - Éléments - Domaines - ArchiMate et les techniques du BABOK ArchiMate et l architecture d entreprise Par Julien Allaire Ordre du jour Présentation du langage ArchiMate - Couches - Éléments - Domaines - ArchiMate et les techniques du BABOK Présentation du modèle

Plus en détail

4. Utilisation d un SGBD : le langage SQL. 5. Normalisation

4. Utilisation d un SGBD : le langage SQL. 5. Normalisation Base de données S. Lèbre slebre@unistra.fr Université de Strasbourg, département d informatique. Présentation du module Contenu général Notion de bases de données Fondements / Conception Utilisation :

Plus en détail

et les Systèmes Multidimensionnels

et les Systèmes Multidimensionnels Le Data Warehouse et les Systèmes Multidimensionnels 1 1. Définition d un Datawarehouse (DW) Le Datawarehouse est une collection de données orientées sujet, intégrées, non volatiles et historisées, organisées

Plus en détail

Architecture N-Tier. Ces données peuvent être saisies interactivement via l interface ou lues depuis un disque. Application

Architecture N-Tier. Ces données peuvent être saisies interactivement via l interface ou lues depuis un disque. Application Architecture Multi-Tier Traditionnellement une application informatique est un programme exécutable sur une machine qui représente la logique de traitement des données manipulées par l application. Ces

Plus en détail

Générer du code à partir d une description de haut niveau

Générer du code à partir d une description de haut niveau Cedric Dumoulin Générer du code à partir d une description de haut niveau Ce projet vise à fournir un environnement de développement permettant de modéliser des UI Android à un haut niveau d abstraction,

Plus en détail

Etat de l art sur le développement logiciel dirigé par les modèles.

Etat de l art sur le développement logiciel dirigé par les modèles. Etat de l art sur le développement logiciel dirigé par les modèles. Samba Diaw* Rédouane Lbath* Bernard Coulette* * Université de Toulouse Laboratoire IRIT Université de Toulouse 2-Le Mirail 5, allées

Plus en détail

Introduction aux intergiciels

Introduction aux intergiciels Introduction aux intergiciels M. Belguidoum Université Mentouri de Constantine Master2 Académique M. Belguidoum (UMC) Introduction aux intergiciels 1 / 39 Plan 1 Historique 2 Pourquoi l'intergiciel? 3

Plus en détail

Fiche de l'awt Intégration des applications

Fiche de l'awt Intégration des applications Fiche de l'awt Intégration des applications Aujourd'hui, plus de 40 % des budgets de développement en informatique sont liés à l'intégration de données dans les systèmes d'information. Il s'agit donc d'une

Plus en détail

WHITE PAPER Une revue de solution par Talend & Infosense

WHITE PAPER Une revue de solution par Talend & Infosense WHITE PAPER Une revue de solution par Talend & Infosense Master Data Management pour les données de référence dans le domaine de la santé Table des matières CAS D ETUDE : COLLABORATION SOCIALE ET ADMINISTRATION

Plus en détail

Le Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer

Le Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer Le Processus RUP Database Administrator Project Leader H. Kadima Performance Engineer Release Engineer Analyst Designer / Developer Tester Table des matières 1. De l artisanat à l industrialisation de

Plus en détail

Modernisation et gestion de portefeuilles d applications bancaires

Modernisation et gestion de portefeuilles d applications bancaires Modernisation et gestion de portefeuilles d applications bancaires Principaux défis et facteurs de réussite Dans le cadre de leurs plans stratégiques à long terme, les banques cherchent à tirer profit

Plus en détail

Service de réplication des données HP pour la gamme de disques Continuous Access P9000 XP

Service de réplication des données HP pour la gamme de disques Continuous Access P9000 XP Service de réplication des données HP pour la gamme de disques Continuous Access P9000 XP Services HP Care Pack Données techniques Le service de réplication des données HP pour Continuous Access offre

Plus en détail

Université Mohamed Khider Biskra. Faculté des sciences exactes et des sciences de la nature et de la vie. Département d Informatique.

Université Mohamed Khider Biskra. Faculté des sciences exactes et des sciences de la nature et de la vie. Département d Informatique. République Algérienne Démocratique et Populaire Ministère de l Enseignement Supérieur et de la Recherche Scientifique Université Mohamed Khider Biskra Faculté des sciences exactes et des sciences de la

Plus en détail

NOVA BPM. «Première solution BPM intégr. Pierre Vignéras Bull R&D

NOVA BPM. «Première solution BPM intégr. Pierre Vignéras Bull R&D NOVA BPM «Première solution BPM intégr grée» Pierre Vignéras Bull R&D Définitions Business Process Pratiques existantes qui permettent aux personnes et systèmes de travailler ensemble Business Process

Plus en détail

Résumé CONCEPTEUR, INTEGRATEUR, OPERATEUR DE SYSTEMES CRITIQUES

Résumé CONCEPTEUR, INTEGRATEUR, OPERATEUR DE SYSTEMES CRITIQUES Aristote ----- Cloud Interopérabilité Retour d'expérience L A F O R C E D E L I N N O V A T I O N Résumé Les systèmes d'information logistique (SIL) sont des outils qui amènent des gains de productivité

Plus en détail

Urbanisme du Système d Information et EAI

Urbanisme du Système d Information et EAI Urbanisme du Système d Information et EAI 1 Sommaire Les besoins des entreprises Élément de solution : l urbanisme EAI : des outils au service de l urbanisme 2 Les besoins des entreprises 3 Le constat

Plus en détail

RTDS G3. Emmanuel Gaudin emmanuel.gaudin@pragmadev.com

RTDS G3. Emmanuel Gaudin emmanuel.gaudin@pragmadev.com RTDS G3 Emmanuel Gaudin emmanuel.gaudin@pragmadev.com PragmaDev Dédiée au développement d un AGL pour le développement des applications temps réel et embarquées. Réseau de partenaires: Formations, Service,

Plus en détail

Gérez efficacement vos flux d entreprises.

Gérez efficacement vos flux d entreprises. Gérez efficacement vos flux d entreprises. g geai* répond au besoin de gestion des flux de données inter et intra-entreprises. Vous maîtrisez vos flux autour d une application centralisée. *EAI : Enterprise

Plus en détail

Génie logiciel (Un aperçu)

Génie logiciel (Un aperçu) (Un aperçu) (sommerville 2010) Laurent Pérochon INRA URH 63122 St Genès Champanelle Laurent.perochon@clermont.inra.fr Ensemble d activités conduisant à la production d un logiciel Sur un échantillon de

Plus en détail

2. Activités et Modèles de développement en Génie Logiciel

2. Activités et Modèles de développement en Génie Logiciel 2. Activités et Modèles de développement en Génie Logiciel Bernard ESPINASSE Professeur à l'université d'aix-marseille Plan Les Activités du GL Analyse des besoins Spécification globale Conceptions architecturale

Plus en détail

Cours en ligne Développement Java pour le web

Cours en ligne Développement Java pour le web Cours en ligne Développement Java pour le web We TrainFrance info@wetrainfrance Programme général du cours Développement Java pour le web Module 1 - Programmation J2ee A) Bases de programmation Java Unité

Plus en détail

Langage HTML (2 partie) <HyperText Markup Language> <tv>lt La Salle Avignon BTS IRIS</tv>

Langage HTML (2 partie) <HyperText Markup Language> <tv>lt La Salle Avignon BTS IRIS</tv> Langage HTML (2 partie) «Je n'ai fait que prendre le principe d - hypertexte et le relier au principe du TCP et du DNS et alors boum! ce fut le World Wide Web!» Tim Berners-Lee

Plus en détail

L Orchestration de Services Web avec Orchestra. Goulven Le Jeune Orchestra Project Manager

L Orchestration de Services Web avec Orchestra. Goulven Le Jeune Orchestra Project Manager L Orchestration de Services Web avec Orchestra Goulven Le Jeune Orchestra Project Manager D1 Bull, Architecte d un Monde Ouvert : contributeur et acteur majeur de l'open Source Applications métiers Infrastructures

Plus en détail

Services OSI. if G.Beuchot. Services Application Services Présentation - Session Services Transport - Réseaux - Liaison de Données - Physique

Services OSI. if G.Beuchot. Services Application Services Présentation - Session Services Transport - Réseaux - Liaison de Données - Physique Services OSI Services Application Services Présentation - Session Services Transport - Réseaux - Liaison de Données - Physique 59 SERVICES "APPLICATION" Architecture spécifique : ALS (Application Layer

Plus en détail