Les systèmes à base de COTS

CHAPITRE I. INTRODUCTION
I.1 Introduction a la problématique
I.2 Pourquoi les systèmes à base de COTS ?
I.3 Les COTS et les services WEB
I.4 L’approche centrée architecture
I.4.1 Présentation
I.4.2 Les enjeux des travaux sur l’architecture logicielle
I.4.2.1 Processus de conception devenu inefficace
I.4.2.2 Evolution vers un processus centré architecture
I.4.3 La notion de style architectural
I.4.3.1 Langage de Description Architecturale (LDA)
I.5 Problématique
I.6 Organisation du document
CHAPITRE II. ETAT DE L’ART
II.1 Les systèmes à base de COTS
II.1.1 Définition du COTS
II.1.2 Comparaison entre COTS et composant
II.1.3 Classification de COTS.
II.1.4 Modélisation des systèmes à base de COTS
II.1.4.1 UML (Unified Modeling Language)
II.1.4.2 Les Langages de Description Architecturale (LDA)
II.1.5 Technologies et normes pour l’intégration de composant
II.1.5.1 SUN (EJB)
II.1.5.2 Microsoft(COM/DCOM)
II.1.5.3 OMG(CORBA)
II.1.6 Problèmes d’intégration des COTS.
II.1.7 Bilan
II.2 Les services WEB
II.2.1 Pourquoi les services WEB dans notre approche?
II.2.2 Définition d’un service WEB.
II.2.3 Langage de description de service WEB
II.2.3.1 La Grammaire de WSDL
II.2.4 SOAP
II.2.4.1 Définition
II.2.4.2 Grammaire SOAP
II.2.5 UDDI
II.2.5.1 Définition
II.3 Les workflow
II.4 Quelque workflow
II.4.1 WSFL d’IBM
II.4.1.1 Définition
II.4.1.2 Un exemple WSFL
II.4.1.3 Présentation générale de la syntaxe de WSFL
II.4.2 XLANG de Microsoft
II.4.2.1 Définition
II.4.2.2 Les actions XLANG
II.4.2.3 Les actions de contrôle XLANG
II.4.2.4 un exemple XLANG
II.4.3 BPEL4WS de IBM, Microsoft et BEA
II.4.3.1 Définition.
II.4.3.2 Structure de BPEL4WS
II.4.3.3 Traitement d’erreurs
II.4.3.4 Exemple
II.4.4 Autres langages
II.4.4.1 WSCI de SUN
II.4.4.2 WSCL de HP
II.4.4.3 BPML de BPMI
II.4.5 Bilan
II.5 Le serveur Biztalk
II.5.1 Introduction
II.5.2 Le moteur BizTalk Server
II.5.3 Relier les applications.
II.5.3.1 Envoyer et recevoir des Messages: les adaptateurs
II.5.3.2 Traitement des messages : les pipelines
II.5.3.3 Choix des Messages: les Souscriptions (subscriptions)
II.5.4 Définition d’un Processus Métier
II.5.4.1 Orchestration
II.5.4.2 Le moteur des règles de gestion
II.5.5 Bilan
II.6 Les langages de description architecturale
II.6.1 Définition
II.6.1.1 Style
II.6.2 Présentation de quelque ADL
II.6.2.1 UNICON-2
II.6.2.2 AESOP
II.6.2.3 ARMANI
II.6.2.4 π-ADL
II.6.3 Bilan des ADL
II.6.4 Le langage formel π-CALCUL
II.6.4.1 Introduction :
II.6.4.2 Concept de Mobilité
II.6.4.3 Syntaxe
II.6.4.4 Sémantique.
II.6.4.5 Le π-calcul asynchrone
II.6.4.6 Le π-calcul polyadique
II.6.4.7 Le π-calcule d’ordre supérieur
II.6.4.8 Bilan
CHAPITRE III. PROPOSITIONS
III.1 Rappel de la problématique
III.2 Proposition d’une architecture de référence
III.3 Définition des services principaux fournis par UDDI-COTS
III.4 Description des éléments de l’architecture
III.4.1 Service de publication (UDDI)
III.4.2 Service Contrôle de processus (UC)
III.4.3 Service orientation (OR)
III.4.4 Représentation externe du COTS
III.4.5 L’attachement des composants
III.5 Génération de code (π-ADL à XLANG)
III.6 Bilan
III.7 Formalisation d’un exemple avec nos styles architecturaux
III.7.1 Description de l’exemple
III.7.2 Création de l’architecteur du système
III.7.2.1 Projection du système selon la topologie
III.7.2.2 Description du système en π-ADL
III.7.2.3 Raffinement du système
III.7.3 Bilan
CHAPITRE IV. BILAN GENERALE
IV.1 Bilan de travail
IV.2 Conception de système
IV.3 Le raffinement
IV.4 Conclusion
REFERENCES BIBLIOGRAPHIQUES .
ANNEXE A : DESCRIPTION DU STYLE
ANNEXE B : L’UC DE L’EXEMPLE EN XLANG
ANNEXE D : PUBLICATION REALISEE

CHAPITRE I. INTRODUCTION

I.1 Introduction a la problématique
La tendance actuelle pour réaliser des applications de grandes tailles est orientée  vers les systèmes modulaires (modules, objets ou composants), et pour les faire communiquer, on utilise des interfaces et des outils adéquats. En plus, la conception, le développement et la maintenance de ces applications posent des problèmes difficiles à résoudre. Les concepteurs sont confrontés à des contraintes de réutilisation de code existant, d’installation d’applications dans des contextes matériels et/ou logiciels qui peuvent varier avec le temps, des contraintes d’administration, d’évolution des applications, etc. La conception d’applications avec les langages de programmation classiques permet difficilement de respecter ces contraintes. Ces langages sont intéressants pour programmer des logiciels mais sont inadéquats pour décrire la structure et le comportement d’une application. Ainsi, des travaux portant sur les architectures logicielles sont nés les langages de description architecturale (LDA)

I.2 Pourquoi les systèmes à base de COTS2?
Il s’agit de considérer les logiciels de demain comme des assemblages d’outils logiciels déjà existants au sein des entreprises ou disponibles sur le marché plutôt que de nouvelles applications issues de longs et coûteux processus de développement [Verjus-2001] .
L’objectif est d’assembler un ensemble d’outils logiciels pour permettre d’exploiter les fonctionnalités propres à chacun d’eux. Cet assemblage doit être aussi simple que possible à mettre en œuvre et offrir des possibilités d’évolution en fonction des nouveaux besoins exprimés par les utilisateurs.
Au cours de ces dernières années, plusieurs travaux ont porté sur les approches orientées composants, c’est-à-dire création des applications par l’assemblage des composants.
Nous nous intéressons à l’assemblage de composants existants, disponibles (COTS).
Les composants qui entrent dans la construction des systèmes à base de COTS, sont généralement de grandes tailles, développes avec des langages différents, fonctionnent dans des milieux hétérogènes et bien souvent distribués.

I.3 Les COTS et les services WEB
Trois standards sont aujourd’hui utilisés pour développer des systèmes distribuer.
CORBA/IIOP (Common Object Request Broker Architecture / Internet Inter-ORB Protocol), DCOM (Distributed Component Object Model) et RMI (Remote Method Invocation).

Si le lien ne fonctionne pas correctement, veuillez nous contacter (mentionner le lien dans votre message)
Définition d’un style architectural pour la description de systèmes logiciels à base de composants de type COTS, selon une approche « services WEB » (1.2 MO) (Rapport PDF)
Définition d’un style architectural

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *