Installation et compilation des Enterprise Library(EntLib)

Rôle du candidat et nomination

En juillet 2006, ayant une licence en informatique de gestion et environ 3 ans d’expérience dans le domaine de l’analyse et de développement de logiciel et des services Web, j’ai été recruté en tant qu’analyste programmeur au sein d’Omega Financial Solutions.
J’ai gagné une partie de mon expérience au sein d’Internet Facilites Group qui est une entreprise internationale située au Liban et qui développe des solutions pour le secteur privé ainsi que public. J’ai travaillé la première année en tant que développeur au sein d’une équipe sur un projet de gestion des fraudes pour le ministère de l’économie et du commerce. Cette application qui consistait à contrôler les sociétés du marché Libanais, a nécessité un an de travail et a été réalisée sous .Net Framework et Microsoft SQL Server 2000.
Au bout d’un an de développement, je commençais à faire de l’analyse en parallèle au développement d’applications multimédia dédiées aux écoles et aux centres éducatifs en général.
D’autres parts, les différentes tâches que j’ai accomplies au sein de la société Omega Financial Solutionsse résument par ce qui suit :
• Faire de l’analyse et de développement de modules sous Delphi en relation avec la communication TCP/IP.
• Former les développeurs sur le modèle multicouches et l’environnement .NET.
• Voyager et communiquer avec les consultants en France et présenter les nouveaux prototypes qui seront intégrés dans OmegaPM.
• Intervention technique auprès des clients et la documentation des scénarios de déploiement pour chaque composant mis en place.
Tout ce travail m’a permis de gagner la confiance de la société pour que je sois désigné analyste programmeur dans l’équipe de recherche et développement responsable de la migration du Logiciel.

Etat de l’art

Les Application distribuées

Définition

Une application distribuée est une application dont tous les éléments qui la composent (classes, persistance, logique métier) sont distants géographiquement etcommuniquent entre eux via des réseaux locaux d’entreprise ou par Internet en utilisant le protocole IP. Les composants des applications distribuées sont réutilisables et servent souvent à plus d’une application simultanément. Cependant, l’utilisateur final n’a pas conscience de la nature distribuée de l’applicatif car il utilise plusieurs interfaces dont le but souvent est de fédérer tous les éléments distants pour atteindre l’objectif de l’application tout en masquant tous les mécanismes d’accès.

Technologies pour applications

Le principe même des applications distribuées n’est pas nouveau. Beaucoup de technologies et de protocoles, souvent incompatibles entre eux ont été mis en œuvre pour permettre aux composants d’une application distribuée, de communiquer entre eux. Parmi ces technologies, on peut citer :
• COM (Component Object Model) : Technologie de communication inter application propre à l’environnement Windows. Cette technologie ne permet pas de construire à proprement parler des applications distribuées mais sert d’interface pour faire communiquer des applications sur une même machine. (Les différents logiciels de la suite bureautique Microsoft Office par exemple).
• DCOM (Distributed Component Object Model) : version Distribuée de COM.
• .Net Remoting : Technologie de communication inter application incluse dans le Framework .Net 2.0, basée sur un modèle client/serveur permettant la communication et la transmission d’objets entre les applications.
• RMI : équivalent Java du .Net Remoting.
• Services Web : technologie permettant de faire communiquer des composants entre eux, indépendamment de la plateforme sur laquelle ils sont hébergés, en utilisant un protocole de communication et un format de fichier unique et standardisé basé sur du XML.
Contrairement aux technologies évoquées précédemment, grâce à la nature standardisée des échanges, il devient tout à fait possible de faire communiquer des modules hébergés sous Windows avec d’autres hébergés sous Linux ou Unix. C’est cette interopérabilité associée à une relative facilité de mise en œuvre, qui fait que les services web sont aujourd’hui une des technologies les plus utilisées, pour construire des applications distribuées.

La naissance de l’Architecture Orientée Service [SOA]

Pour comprendre l’avènement et en quoi consiste le SOA, il est nécessaire de bien identifier que le but de la programmation structurée, est d’écrire du code qui soit robuste et réutilisable. Au tout début, il n’existait que les langages purement procéduraux, la seule façon d’écrire du code réutilisable était d’écrire des fonctions et des procédures dans un fichier séparé du corps du programme, et de faire appel à ce fichier chaque fois que c’est nécessaire. Ensuite, est apparue la Programmation Orientée Objet (POO). Elle était innovante dans le sens ou le concept même d’ « objet » permet l’encapsulation et donc de masquer la complexité des opérations. Les objets peuvent s’envoyer des messages, grâce aux appels de méthodes exposées par l’objet avec lequel ils souhaitent communiquer sans pour autant savoir comment le dit objet implémente le traitement qu’on lui demande d’exécuter. Malgré le fait que des technologies comme DCOM, RMI ou .Net Remoting permettent de transporter les objets et donc de dépasser les frontières de la machine grâce au réseau, on s’est souvent heurté à des problèmes de compatibilité entre plateformes, d’où le besoin d’une standardisation et la mise en commun des protocoles (SOAP, XML, …). De là est née la notion d’architecture orientée services (SOA). .Net Remoting et les services web sont les deux méthodes les plus communes pour écrire des applications .Net distribuées, sauf que chacune présente des avantages et des inconvénients et le choix de l’une ou de l’autre repose sur le besoin et le type d’investissement décidé.

Web services et standards ouverts

Les services web sont des composants applicatifs capables de communiquer entre eux à travers plusieurs réseaux par le biais de « standards ouverts » non propriétaires basés sur le XML. Les services web permettent à différents types d’applications de communiquer et d’opérer entres eux sans se soucier des plateformes et des langages de programmation utilisés.
Lors du déroulement d’un processus distribué, des ordinateurs s’envoient des messages entre eux pour récupérer des données ou invoquer des procédures.
Traditionnellement, ces messages passaient par des solutions middleware propriétaires ou faites maison. Dans un système d’information hétérogène actuel comprenant différents systèmes d’exploitations et des applications programmées avec différents langages, il est souvent nécessaire pour les managers IT d’acheter ou développer une différente interface pour chaque paire de systèmes connectés – une situation coûteuse et complexe.
Un nombre de tentatives ont été faites pour résoudre le problème mais elles ont échoué à cause d’un manque d’adoption par les acteurs de l’industrie et la suprématie des standards propriétaires. Avec l’arrivée d’Internet et des capacités de description universelle du XML, les services web ont apparus.
Le fait que les acteurs de l’industrie se soient mis d’accord sur l’adoption de la technologie émergeante que représentent les services web a eu pour conséquence une révolution dans le monde de l’informatique.

Standardisation et interopérabilité

Pour que les systèmes puissent librement évoluer tout en restant compatible (dans un cadre interopérable), ils doivent s’affranchir d’une marque ou d’un vendeur particulier. Ils doivent obéir à une norme clairement établie et comprise.
Les systèmes restent interopérables, tant qu’ils respectent les normes régissant leurs contenus et leurs interfaces.La standardisation a permis de s’entendre sur les :
• Formats de données: X(HT)ML, SVG, SMIL, …
• Protocoles de communication: HTTP, SOAP

Les standards des services Web

L’un des avantages lié à l’utilisation des web services lors de déploiement d’environnements distribués est l’universalité de leurs interfaces.
Un web service dépend de trois standards basés pour bien fonctionner:
Web Services Description Langage (WSDL) qui est le document qui décrit exactement ce que le web service fait et comment le solliciter.
Universal Discovery, Description, and Integration (UDDI)
Les services web sont basés sur une architecture logicielle de requêtes et réponses.
Un « client » d`un service web sollicite un service web avec une requête SOAP. En retour, le service web effectue l’opération demandée et répond à son tour avec un message SOAP.
Chaque service web a un client et un fournisseur. Grâce à leur nature, les services web peuvent avoir plusieurs clients se connectant à leurs interfaces sans se soucier de la plateforme et des langages de programmation.
Tant que le client envoi un message au format standard SOAP, il n’y a aucune différence au niveau du service web concernant les détails du client.
Pour se décrire au monde extérieur, chaque service web a un document (WSDL) qui fournit au client potentiel du service une explication concernant le fonctionnement et l’accès du service.
Le WSDL décrit comment créer une requête SOAP qui appellera le service web spécifique. Si un développeur veut créer un programme qui fait appel a un web service, il lui faudra juste le WSDL de celui ci.
L’Universal Discovery Description and Integration (UDDI) est un annuaire des services web disponibles dans un réseau particulier. Un client potentiel de service web peut consulter l’UDDI pour la disponibilité.

Atouts et faiblesses des SOA

Au-delà de la théorie et du mode de fonctionnement, quels sont donc les avantages que l’on peut identifier autour des SOA? Premièrement, leur mise en place nécessite une réflexion basée sur les notions d’objet. Chaque “service” doit s’apparenter à une fonctionnalité, dont le rôle et le périmètre de couverture doivent être clairement identifiés. La nécessité d’un effort conséquent en termes de modélisation se traduit inévitablement par une implémentation de meilleure qualité. Il en découle des facilités en termes de maintenance, de solidité applicative et de distribution. [W3]
Mais au-delà de ces aspects propres à l’objet et non spécifiques à l’orientation services, ce sont bien entendu les caractéristiques mises en avant par les services web qui ressurgissent. Ainsi, la capacité d’exécuter un traitement, sans avoir connaissance du langage ayant servi à son implémentation, est un atout indéniable. Tout comme la possibilité d’y accéder sans connaître à l’avance sa localisation.
À l’inverse, la nécessité d’effectuer un effort conséquent en termes de conception représente à ce jour l’un des principaux freins à la banalisation des SOA. De même que le besoin de réalisation d’une couche d’interface supplémentaire, pour laquelle les équipes de développement ne sont généralement pas habitués.
Comme on vient de le constater, les SOA seront d’autant plus utiles dans les contextes d’applications d’entreprise – voire de systèmes d’informations dans leur globalité, pour lesquels l’investissement consenti en conception et en interfaçage sera rentabilisé dans la phase d’évolution et de maintenance. Pour des projets départementaux ou locaux, cette approche présente moins d’intérêt, si ce n’est bien sûr pour accéder à des modules existants reposant sur les SOA.
Dans ce qui suit nous allons aborder le découplage entre les architectures car l’architecture orientée service vient pour compléter l’abstraction des couches, et par suite le principe de découpage en couches est une nécessité pour rendre une application flexible.

Les plus et les moins

Comme n’importe quelle technologie, WPF a des avantages comme des inconvénients, même ces derniers sont malgré tout très restreints, comme on va pouvoir le voir.

Les avantages de WPF

Utilisation du GPU

Un des principaux changements avec WPF c’est l’utilisation du GPU. Bref rappel de base, le GPU est en fait le processeur graphique présent sur la carte graphique d’un ordinateur.
Le fait que WPF utilise le GPU change énormément de choses. En effet cela permet de déléguer une partie du travail habituellement délégué au microprocesseur (CPU), au processeur graphique qui va se charger de la manipulation de données graphiques.

Séparation code / design

Souvent, lorsqu’un développeur travaille une application en collaboration avec des designers et d’autres développeurs, un problème majeur va se poser. En effet pour customiser votre application, votre designer devra avoir des compétences en développement, il va devoir connaître les objets de votre application et les fonctionnalités des WinForms.
C’est là que WPF permet de justement séparer en couches votre application,il va se charger de séparer le code designer du code behind(classe d’arrière plan).C’est à dire que le designer va pouvoir travailler sur le design de l’application,via un langage commun basé sur du XML qui est le XAML qu’on verra plus loin ( section 4.5 de ce chapitre). Quant au développeur de son côté via le code behindil va pouvoir travailler sur la couche métier. Cela va permettre une meilleure productivité et un support de l’application plus facile par la suite.

Plus puissant que les WinForms

Même si au premier abord, WPF peut choquer par la séparation code / design et aux contrôles également sensiblement différents, WPF offre plus de possibilités comme on a pu le voir et plus de « puissance ».
C’est‐à‐dire que par exemple grâce à WPF et Expression Blend on va pouvoir mettre en place des animations pour notre application, de façon vraiment très simple et très rapide. Cela augmente d’une part la productivité du développeur, celle du designer et pour finir l’ergonomie de l’application pour l’utilisateur final.

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.com propose le téléchargement des modèles complet 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
Table des figures 
Table des tableaux
Présentation de l’entreprise 
Introduction 
Première Partie 
Environnement et Etat de l’art 
Chapitre I
Environnement de travail
I.1 – Structure de l’entreprise
I.2 – Fonctionnalités principales d’Omega PM
I.3 – Organigramme de l’entreprise et processus d`intégration continue
I.4 – Rôle du candidat et nomination
I.5 – Définition du problème et Étude des besoins
Chapitre II 
Etat de l’art
II.1 Les Application distribuées
II.2 Le découplage dans les architectures
II.3-Introduction au design Patterns
II.4 Introduction à WPF
Chapitre III 
Justification du choix du logiciel
III.1– Architecture et Composants du système
III .1.2 Les Blocs d’application Enterprise Library
III .1.2.1 Introduction aux blocs d`application
III .1.2.2 Le noyau des blocs d’applications
III .1.2.3 Dépendances entre les blocs d’application
III .1.2.6 Le bloc d’accès aux données
III .1.2.7 Le bloc de gestion des exceptions
III .1.2.8 Le bloc de mise en cache
III .1.2.9 Le bloc de piste d’audit(Logging)
III .1.2.10 Le bloc de sécurité
III .1.2.11 Le bloc de Validation des données
III .1.2.12 Outils divers
Deuxième Partie 
Phases de la migration vers l’architecture orientée service
Chapitre IV 
Compilation en .Net
IV.1 Phase de recherche
IV.1.1.2 Normes de codage et de nomenclatures
IV.2 Phase d’analyse du code
IV.3 Installation du CodeGear et gestion des composants
Chapitre V 
Conception des composants de l’application
V.1 Installation et compilation des Enterprise Library(EntLib)
V.2 Conception des tiers de données
V.3 Conception des tiers de gestion
V.4 Conception et développement de la politique de sécurité
V.5 Conception des composants d’audit
V.6 Conception des composants de gestion des exceptions
V.7 Conception des composants de validation des données
Chapitre VI
VI.1 Composants communs et types d’écrans
VI.1.1 Composants visuels communs
VI.1.2 Type d’écrans
Chapitre VII 
Assistant de conception de l’interface utilisateur
VII.1 Phases de Conception de l’assistant
VII.2 Etape de développement de l’assistant
VII.3 Le Processus de test des couches
VII.3.1 Pré requis
VII.3.2 Le plan de tests
Conclusion 
Bibliographie 
1- Ouvrage de référence
2- Articles
3- Les sites Internets
Glossaire
Annexe A
1) Aperçu global sur l’interface de développement Delphi
2) Bibliothèque de composants VCL
Annexe B
2 L’EDI de Delphi
3)La bibliothèque d’objets de Delphi
Annexe C
1) Description des différents fichiers d’un projet Delphi
Annexe D
Classe
1)Générateur de code SQL
a)Exemple de génération de la requête insert
b)Exemple de génération de la requête update
Annexe E
Annexe F
1) Table des matières du plan de Test
Annexe G
Annexe F
a)Exemple de syntaxe du protocole FIX

Rapport PFE, mémoire et thèse PDFTélécharger le rapport complet

Télécharger aussi :

Laisser un commentaire

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