Ministère de l’enseignement supérieur

Université de la Manouba
Ecole Nationale des Sciences de l’Informatique

Projet de fin d’études

Sujet :

Conception et implementation des modules

fonctionnels pour la Plateforme Mootwin

Réalisé par : Arbi BEN SASSI

Encadré par : M. Allan Denis

Supervisé par : Dr. Yassine Jamoussi

Année universitaire
2010-2011
 Introduction

• Enjeux de la Mobilité :
• Développer des services mobiles avancés
• Utilisable partout et tous le temps
• Fonctionnels en environnement de réseau dégradé

• Défi
• Augmentation des coûts de développement
• Diversité des plate-forme mobile (iPhone, Android, Windows Mobile, etc.)
• Explosion des coûts de maintenance
• Failles de Sécurité
 Introduction

Avantages de la solution Mootwin :

La rapidité (réplication intelligente des données de SI)

Accessibilité : même en cas de réseau dégradé

Temps réel : réduction des échanges de données 🡪 push temps réel

Ergonomie garantie : Application natif 🡪totale harmonie , agréable et conviviale.

 Problèmatique

• Existant : MOS(Mootwin operation serveur )

• Son rôle :
- Gérer la connectivité des différents mobiles à la plateforme
- Capacité à s’intégrer aux SI hétérogènes

• Limites :
* Manque de Traçabilité :
l’impossibilité d’avoir d’information consoludée
(statistique d'utilisation)

* Pas de notion d'utilisateur :

- Permettre de faire la mapping entre les
utilisateurs de l'application mobile et le SI client.

- Le SI ne peut pas demander à la plateforme

Mootwin d'envoyer un message à un ou
plusieurs utilisateurs précis
 Problèmatique
Politique de Mootwin :
* Répondre aux besoins des Clients :
- Afin de gagner encore sur le temps de développement
- Accélérer l'accée au marché

Développer des modules fonctionnels

Objectif :
🡪 L’objectif de ce présent travail consiste à spécifier, concevoir, implémenter et tester des
modules fonctionnels pour la plateforme de Mootwin (gestion des utilisateurs, gestion des
groupes)
 Plan

• Etat de l’art

• Solution

• Réalisation

• Conclusion & perspective

•6
Etat de l’art 🡪 Modèle orienté composant

• Construction d’applications = Composition de plusieurs blocs

• Pour supporter la composition, un composant doit fournir :

• la ou les fonctionnalités proposées,
• La signature (liste et nature des informations attendues en entrée)
• les informations retournées
• Les propriétés configurables.

• Les composants : Structure d’un composant

• Livrés et déployés indépendamment sous forme de codes binaires
• Satisfaire les dépendances de déploiement avant d’être instancié.
• Environnement d’exécution supportant :
- Gestion du cycle de vie
- sécurité
- Contrôle à distance
- la persistance
- les transactions.
Etat de l’art 🡪 Modèle orienté service
L’architecture orientée services :
• Un concept architectural qui s’applique à la structure de l’applications

• Les Plates-formes SOA sont basées sur la programmation orientée composant

• Le fonctionnement de cette architecture repose sur deux principes fondamentaux :

• Forte cohérence interne (même format d'échange)
• Couplages entre composants (échange minime , Utilisation d'interface interopérable)

• Avantage de l’architecture orientée services :

• Réutilisabilité
• Interopérabilité
• réduction des couplages entre les applications

Fonctionnement d’une Architecture

Orientée Services
Etat de l’art 🡪 Framework OSGi
• Le Framework OSGi 🡪 Plate-forme de type SOA

• Son rôle est la gestion dynamique des composants

• Le Framework OSGi fournit aux applications, un environnement d’exécution

standardisée.

• Les composants unitaires de la plate-forme sont appelés des bundles.

Vue en couche de l’environnement OSGi et ses bundles
• Un bundle peut être à la fois un fournisseur et un consommateur de services.

• L’avantage d'OSGi :
🡪 Offre la portabilité de ses bundles sur de multiples plates-formes (Java, JVM)

🡪 La découverte dynamique des bundles :

- Minimiser les efforts de configurations,

- Simplifier l’ajout de nouvelles fonctionnalités

🡪 Versionning
🡪 Simplifier les tâches de maintenances
Composition dynamique d’application au sein d’OSGi

•9
 Solution –> Besoins Fonctionnels
Module UserInformationService :

🡪 Proposer un service qui centralise et stocke tous les utilisateurs ayant déjà démarrés l’application mobile
(informations vitales au fonctionnement de Mootwin Foundation)

🡪 Gérer la correspondance avec le système d’information client (SI)

🡪 Permettre aux différents modules de partager des informations pouvant être exploitées par d’autres
modules de la plateforme Mootwin. (Meta-données)

🡪 UIS doit maintenir le mapping entre customerID et le mootwinID

Module GroupManager :

🡪 Offrir une fonction permettant la gestion de groupes d’utilisateurs dans la plateforme Mootwin
Foundation.

🡪 Les modules UIS et le groupManager doivent exposer une API qui sera fourni aux autres modules et SI
Solutions –> Besoins Non Fonctionnels
🡪 La performance :
- Temps de chargement des données de la base de données
- Temps d’échange des messages entre les modules

🡪 La modularité : les modules fonctionnels répondent aux critères suivant :

- Fonctionnalité
- Interchangeabilité
- Réutilisabilité

🡪 La disponibilité
Solution - Cas d’utilisations
Solution – architecture globale
Solution - Architecture des Modules

Avantages de ce modèle :
* La modularité :
- L'application → Rassemblage de petit entitées
- La Réutilisation de certaines entités
- Souplesse de modifications ( changement au niveau d’un module n’influe pas sur l’ensemble ) .

* La flexibilité :
- Tolérance de changements structurels et les mutations probables des technologies.
Solution → Interaction entre les différents composants
Réalisation → Les composants
Réalisation
Réalisation → Web Service
Réalisation → Interface d’administration de Web Service
Interfaces de gestion du group
Réalisation → Phase de Test
Test unitaire des Bundles avec Junit
Réalisation → Phase de Test
Test des web service à l'aide de SoapUI
Conclusion & Perspective
Merci pour votre attention