Plateforme de passages d'ordres boursiers

1. Plateforme de passages d'ordres boursiers Etienne Charpentier Jean-Michael Legait Michèle Reynier Judicaël Ribault

2. Plan • Cahier des charges • Architecture • Patterns for e-business • Architecture logique • Solution applicative • Architecture physique • Prototype

3. Cahier des charges Contexte et contraintes

4. ContexteRéseau de la banque

5. ContexteClients visés • Clients individuels • Clients traditionnels Employés d'agence • Internautes • Gros clients : cabinet de placement • Courtiers • Agents à la corbeille

6. Contraintes fonctionnellesDiagramme de cas d'utilisations

7. Contraintes non fonctionnellesVolumétrie du système • 10 courtiers et chaque courtier a 10 fois moins de clients que la banque • 400 agences et 3 employés par agence • 20 Gros clients et 10 employés par Gros client • Chaque agent à la corbeille suit 5 valeurs

8. Contraintes non fonctionnellesQualité de service • Gros client/agent à la corbeille Délai d'exécution < 400ms • Agents à la corbeille Débit minimal = 2Mo/s • Taux de disponibilité 99,99% soit 52min et 33s d'indisponibilité par an

9. Architecture Patterns for e-business

10. Patterns for e-businessDéfinition • Mis à disposition par IBM • Manière simple de traduire les besoins de l'entreprise en solutions techniques • Solutions déduites de milliers de projets e-business

11. Patterns for e-businessBusiness Patterns • Definition: • Décrivent les interactions utilisateurs/entreprises/données • Nos besoins : • Passer un ordre de bourse Self-Service (User-to-Business) • Consulter le cours de la bourse Information aggregation (User-to-Data)

12. Patterns for e-businessIntegration Patterns • Definition : • Intégration de plusieurs modèles métier • Acces Integration • Application Integration

13. Patterns for e-businessComposite Patterns • Definition : Combine les différents patterns utilisés pour n'en faire qu'un. • e-Marketplace

14. Architecture Architecture logique

15. Architecture logique globale

16. Architecture logiqueLes clients dans le système Les clients qui vont intéragir avec le systèmes : • Les employés d’agence • Les gros clients • L’agent à la corbeille   • Le courtier

17. Architecture Solution applicative

18. Solution applicativeServeur d'application • Choix de la plateforme logicielle : • PHP • Complexité de développement • La persistance n'est pas gérée automatiquement • Pas de système transactionnel • .Net et C# • Manque de maturité (Version finale : Janvier 2002) • Lié aux environnements Windows • Serveur Microsoft moins fiable qu'un serveur Unix • J2EE et EJB sur serveur Unix • Maturité (fin 1999) • Richesse de l'API Java • Indépendance de plate-forme • Performance de Java améliorée • Tolérance aux pannes

19. Solution applicativeClients lourds Les types de client disposant des services applicatifs d'un client lourd sont: • Gros clients • Agents à la corbeille

20. Solution applicativeBases de données Les données stockées en base sont : • Les comptes de bourses • L'historique des passages d'ordres • La file de requêtes à traiter

21. Architecture Architecture physique

22. Architecture physiqueAgences régionales

23. Architecture physiqueSites centraux

24. Prototype