ARCHITECTURE A BASE DE COMPOSANTS

Architecture à Base de Composants

Les systèmes informatiques actuels sont à la fois efficaces, fiables et complexes du fait qu‟ils se basent sur les architectures puissantes et extensibles. Ces architectures ont évolué depuis l‟apparition des premières architectures que sont les mainframes ou encore les architectures un-tiers. Depuis, la notion d‟architecture est devenu essentielle pour le développement des futures applications. Bien que les applications sur Mainframes aient connu un succès remarquable, la tendance vers une nouvelle architecture s‟est concrétisée par l‟évènement du modèle Client/serveur. Ce type d‟architecture est très répandu du fait qu‟il s‟est bien adapté aux applications sur des réseaux informatiques. On est arrivé à une époque ou les besoins exigent que de nouvelles architectures logicielles prennent place pour améliorer les systèmes Client/serveur classiques Donc le défi s‟est inscrit sur le développement des architectures distribuées.

Ce qui a favorisé l‟émergence de ces architectures c‟est l‟apparition de nouvelles approche de développement telles que l‟orienté objet, le paradigme des composants ou encore l‟approche par aspect. La vision est devenue donc différente vis-à-vis de la conception des nouveaux systèmes logiciels du fait qu‟on s‟est orienté vers le développement de systèmes à base de composants. Les bénéfices attendus de l‟utilisation des composants sont a priori clairs : il s‟agit essentiellement de réduire les coûts de production des logiciels, mais aussi d‟en réduire les coûts de maintenance et d‟en favoriser la réutilisation Actuellement, trois technologies se partagent le marché industriel à savoir CORBA, Dot Net et J2EE pour fournir une infrastructure et une architecture permettant le développement de ces systèmes à base de composants.

CORBA CORBA (Common Object Request Broker Architecture) est une architecture proposée et maintenue par l‟OMG (Object Management Group) pour permettre l‟intégration d‟une grande variété de systèmes hétérogènes distribués orientés objet. CORBA est conçue pour supporter des applications distribuées orientées objet et développées selon le modèle client-serveur. On dit aussi que CORBA est un bus réparti (à ne pas confondre évidemment avec la notion de bus physique utilisée dans les réseaux de transmission). CORBA a été conçue pour développer des applications de la façon la plus simple possible, même si développer des applications distribuées n‟est pas toujours facile. Transparence, portabilité et interopérabilité sont les principes de base de la spécification de CORBA. Quand le client fait une requête, il ne voit qu‟un appel local, tous les mécanismes impliqués dans l‟appel sont transparents au client. Un des avantages les plus importants de la spécification CORBA est de faciliter le développement des applications distribuées en évitant au développeur des difficultés concernant les mécanismes de communication, la location des applications, les clients et serveurs, le protocole de communication à utiliser ou le format de message à utiliser.

Le développement d’un EJB

Concrètement un EJB est un groupe de deux interfaces accompagné d‟au moins une classe dans un module contenant un descripteur de déploiement. La gestion des transactions, la persistance des données et la sécurité sont directement prises en charge par les EJB. Les EJB communiquent entre eux en utilisant le JNDI (Java Naming Directory Interface). La création d’un bean nécessite la création d’au minimum deux interfaces et une classe pour respecter les spécifications de Sun : la classe du bean, l’interface remote et l’interface home. L’interface remote permet de définir l’ensemble des services fournis par le bean. Cette interface étend l’interface EJBObject. Dans la version 2.0 des EJB, l’API propose une interface supplémentaire, EJBLocalObject, pour définir les services fournis par le bean qui peuvent être appelés en local par d’autres beans. Ceci permet d’éviter de mettre en oeuvre toute une mécanique longue et coûteuse en ressources pour appeler des beans s’exécutant dans le même conteneur. L’interface home permet de définir l’ensemble des services qui vont assurer la gestion du cycle de vie du bean. Cette interface étend l’interface EJBHome. La classe du bean contient l’implémentation des traitements du bean. Cette classe implémente les méthodes déclarées dans les interfaces home et remote. Les méthodes définissant celles de l’interface home sont obligatoirement préfixées par « EJB ». L’accès aux fonctionnalités du bean se fait obligatoirement par les méthodes définies dans les interfaces home et remote.

Présentation d’UML

UML (Unified Modeling Language) est un langage formel et normalisé en termes de modélisation objet. Son indépendance par rapport aux langages de programmation, aux domaines de l‟application et aux processus, son caractère polyvalent et sa souplesse ont fait lui un langage universel. En plus UML est essentiellement un support de communication, qui facilite la représentation et la compréhension de solution objet. Sa notation graphique permet d‟exprimer visuellement une solution objet, ce qui facilite la comparaison et l‟évaluation des solutions. L‟aspect de sa notation, limite l‟ambigüité et les incompréhensions. UML fournit un moyen astucieux permettant de représenter diverses projections d’une même, représentation grâce aux vues. Une vue est constituée d’un ou plusieurs diagrammes. On distingue deux types de vues: La vue statiques, permettant de représenter le système physiquement : Diagrammes de classes, diagrammes d’objets, diagrammes de cas d‟utilisation, diagrammes de composants, diagrammes de déploiement. La vue dynamiques, montrant le fonctionnement du système : Diagrammes de collaboration, diagrammes de séquence, diagrammes d’états-transitions, diagrammes d’activités.

Conclusion Générale

L’objectif de notre projet est la réalisation d‟une application médicale qui aide à la gestion et l’informatisation des patients dans une clinique, et à encourager les gens à utiliser la technologie dans leur travail pour le faciliter et le rendre moins compliqués et plus sécurisé. Le développement de notre application web dans le domaine médicale nous a permis de découvrir un nombre d‟outils d’informatique, ainsi que l’importance de la sécurité des données. Tous d‟abord nous avons commencé par la conception, en utilisant le formalisme UML puisque notre application devra rester ouverte pour les améliorations futures. Pour les données, nous avons eu recours à la base de données Heidi SQL pour sa capacité de stockage adéquate au projet développé ainsi que pour son aptitude à stocker les images sous bonne qualité.

Nous avons acqui de nouvelles connaissances en EJB et de découvrir des nouveaux design patterns, notamment MVC qui permet une séparation et une distribution des tâches entre développeurs, et rend l’application plus flexible. Aussi le pattern Façade qui cache la conception et la complexité de code source et le rend plus lisible. Ceci nous permis d‟avoir une bonne expérience et une amélioration de nos connaissances concernant le domaine de la programmation Orienté Objet. Enfin nous pensons que ce système peut être amélioré pour le rendre aussi convenable dans l’avenir.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport gratuit propose le téléchargement des modèles gratuits de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

LISTE DES FIGURES
INTRODUCTION GENERALE
Introduction générale
1.ARCHITECTURE A BASE DE COMPOSANTS
1.1 Introduction
1.2 CORBA
1.2.1 Définition
1.2.2 Développement CORBA
1.2.3 Déroulement de requête sous CORBA
1.3 Dot Net
1.3.1 Définition
1.3.2 Les langages de programmation
1.3.3 Architecture
1.3.4 Le déploiement d‟applications .NET
1.4 J2EE
1.4.1 Définition J2EE
1.4.2 Organisation d‟une architecture J2EE
1.4.3 Composants de l‟architecture J2EE
1.4.4 Les Services de l‟architecture J2EE
1.4.5 Outils de développement
1.4.6 Le Runtime
1.5 Conclusion
2.ENTREPRISE JAVA BEANS (EJB)
2.1 Introduction
2.2 La présentation des EJB
2.3 Interfaces EJB
2.4 Les différents types d’EJB
2.5 Les différents rôles d‟EJB
2.6 Caractéristiques des EJB
2.7 Le développement d’un EJB
2.8 Fournisseur de serveur/conteneur d’EJB
2.9 Les outils de développement
2.10 Le déploiement des EJB
2.11 Processus de Développement, de Déploiement et d‟Exécution
2.12 Conclusion :
3.CONCEPTION DU SYSTEME
3.1 Introduction
3.2 la méthodologie de conception
3.2.1 Présentation d‟UML
3.2.2 Processus Unifié
3.2.3 StarUml
3.3 Les diagrammes du système
3.3.1 Diagrammes de cas d‟utilisation :
3.3.2 Diagramme de séquence
3.3.3 Diagramme de classes
3.3.4 Le modèle relationnel
3.4 Conclusion
4.REALISATION DU SYSTEME
4.1 Introduction
4.2 Architecture technique
4.3 Architecture MVC :
4.4 Choix des outils et langages de développement
4.5 Développement de l‟application
4.5.1 Principales interfaces graphiques :
CONCLUSION GENERALE
Conclusion Générale
LISTE DES FIGURES
ABSTRACT