Soutenance NOUMEA NetwOrk Unified Marketplace Enterprise Application

1. Soutenance NOUMEANetwOrk Unified Marketplace EnterpriseApplication Groupe Orphée Laurent Bocquet, Nicolas Demange, Thomas Ferry, Pierre Gallice, Antoine Tallon Vendredi 22 Juillet 2005

2. Analyse • Définition • Ensemble des travaux comprenant l'étude détaillée d'un problème, la conception d'une méthode permettant d'obtenir le résultat désiré et la définition précise du traitement correspondant par ordinateur – GDT • L’analyse se concentre sur • La compréhension du problème • Les exigences fonctionnelles • La structure du système • L’analyse est une ébauche idéalisée d’une solution Cas d’utilisation Exigences fonctionnelles Classe d’analyse Entités du système Interactions entre les entités Diagrammes de séquence Business Plan

3. Analyse : cas d’utilisation (1/3) • But • Transformer l’expression des besoin en exigences fonctionnelles • Illustrer le fonctionnement global de l’application finale • Démarche • Analyse du cahier des charges fonctionnel • Identification des acteurs • Administrateur • Client • Courtier • Responsable de comptes client/ Responsable d’agence • Pour chacun des acteurs, identification des fonctionnalités idoines • Documentation • Formalisation UML • Description, séquences d’interactions, exigences spéciales, pré et post conditions Business Plan

4. Analyse : cas d’utilisation (2/3) • Réalisation (1/2) • Administrateur • Créer un compte utilisateur • Changer les mots de passe • Client • Gérer son compte • Approvisionner • Répartir les fonds entre portefeuilles • Gérer ses portefeuilles • Créer et catégoriser • Liquider • Responsable d’agence • Définir les modèles et catégories de portefeuille • Attribuer les portefeuilles aux courtiers • Visualiser les cours, les statistiques Business Plan

5. Analyse : cas d’utilisation (3/3) • Réalisation (2/2) • Courtier • Gestion de portefeuille • Choisir un modèle de portefeuille • Ajouter des cotations • Passer un ordre • Visualisations • Portefeuilles client • Statistiques Business Plan

6. Analyse : classes d’analyse (1/2) • But • Identification des objets du domaine et leur responsabilité et/ou comportement • Avoir un premier aperçu du modèle objet du système à partir des exigences fonctionnelles • Démarche • Reprise de chaque cas d’utilisation et extraction des entités nécessaires • Identification des rôles via les stéréotypes : • Boundary : interface avec un acteur • Entity : donnée et actions • Control : intermédiaire de contrôle Business Plan

7. Analyse : classes d’analyse (2/2) • Réalisation • Boundary Gestion de compte Gestion de portefeuille Gestion de modèle Gestion de catégorie Gestion de courtiers Gestion de transactions Connexion/déconnexion • Control Contrôleur de compte Contrôleur de portefeuille Contrôleur d’agence Contrôleur de courtage Contrôleur de transaction Contrôleur d’authentification • Entity Compte client Utilisateur et ses déclinaisons Portefeuille Catégorie et modèle Cotation Transaction B C E Business Plan

8. Analyse : diagramme de séquence (1/2) • But • Diagramme modélisant les interactions entre les classes d’analyse • Vision dynamique • Démarche • Pour chaque séquence d’interactions des cas d’utilisation • Reprise des classes d’analyse actrices dans l’interaction • Allocation des comportements et des responsabilités aux classes d’analyses • Formalisation des interactions dans des diagrammes de séquence Business Plan

9. Analyse : diagramme de séquence (2/2) • Réalisation • Affinage des classes d’analyse • Identification des méthodes nécessaires aux interactions • Structures conditionnelles d’interaction • Mise en exergue du concept Modèle-Vue-Contrôleur  Classes du système Business Plan

10. Inscription dans le cycle de développement • Prochaine phase • Codage Business Plan

11. Conclusion Business Plan

12. Questions ?