ANALYSE ET CONCEPTION D'UNE APPLICATION

Présentation au sujet: "ANALYSE ET CONCEPTION D'UNE APPLICATION"— Transcription de la présentation:

1 ANALYSE ET CONCEPTION D'UNE APPLICATION
Avant de produire, il faut concevoir, donc utiliser une ou des méthodes ad-hoc, adaptée(s) à la nature de l’application, des concepts et des outils. La méthode sera formalisée par une notation. La méthode peut inclure en outre des techniques de prototypage, des techniques de mesures et évaluation, des moyens de modéliser, de tester, etc...

2 Préambule, quelques éléments importants :
Méthode inspirée de Grady Booch Fusion entre Booch, OMT de Rumbaugh et OOSE de Jacobson Unified Modeling Language Normalisée par l ’Object Management Group. Unified Method Ateliers de Génie Logiciel : Visual Paradigm , Rational Rose C++, Rational Unified Process , Together C++/Java, Objecteering, Platinum, ...

3 PREMIER SUJET : SYSTEME D’ADMINISTRATION DE FORMATIONS
Le premier contact permet de définir les éléments de base à travers les diagrammes de use-case. Chaque cas sera explicité et commenté. On définit donc des fonctionnalités (ce que le système fera et éventuellement ce qu’il ne doit pas faire) QUI FAIT QUOI ?

4 Description succincte : ce que le UC apporte en terme de fonctionnalités.
Intervenants dans l'élaboration du UC : analystes, utilisateurs, spécialistes du domaine, clients. Date de création et dates de mises à jour, avec l'énoncé des modifications. Quels sont les utilisateurs (acteurs) susceptibles d'enclencher le UC. Quels sont les effets qui en résultent (mise à jour d'une base, envoi d'un document, écriture dans un fichier, …). Fréquence d'utilisation. Quelles sont les pré-conditions pour pouvoir enclencher ce UC (réalisation d’un autre UC, existence d’une base de données, etc.). Technique de déploiement : enclenché via le web, via un terminal, en intranet, en C/S. Scénarios décrivant le déroulement des opérations, pour le cas normal : une description en langage clair des interactions entre les éléments intervenants pour mener le UC à bien. On y identifie le ou les acteurs, ainsi que les autres UC éventuellement enclenchés.

5 Scénarios décrivant les cas "alternatifs" , avec la condition de déclenchement .
Scénarios décrivant les cas d'exception (panne réseau, serveur arrêté, …) avec la condition de déclenchement. Définition des tests qui serviront à valider la réalisation du UC, appelés parfois "Test cases" : complets et détaillés ! ! ! Informations nécessaires avant d'enclencher le UC (qui seront demandées). Contraintes préalables (techniques, personnelles, temps d'exécution maximum, etc.) Estimation des risques : niveau de connaissance du domaine du problème traité par le UC, niveau de compétence de l'équipe de designers, niveau de compétence de l'équipe de programmeurs . Importance de ce UC pour les utilisateurs/clients. Ce point et le point qui précède serviront à classer les UC, pour un ordre "chronologique" Le dictionnaire des abstractions et des actions associées aux scénarios (des noms et des verbes…).

6 Exemple: Description : le UC permet à l'administratif d'inscrire un candidat à la prochaine session d'une formation On doit pouvoir trouver ses informations s'il est déjà client, sinon on les demande. Si la prochaine session est complète, on peut l'inscrire dans une liste d'attente. Intervenants : Analyste : T. Bastianelli Client : Inpres Formation, Jimmy Piette Date de création : 6 juin 2001 Mises à jour : 2 juillet 2001, description simple Acteurs : enclenché par un Administratif Effets : la liste des inscrits a été complétée pour la session choisie le client a été ajouté dans la liste des clients s’il est nouveau client Fréquence d'utilisation : apériodique Technique de déploiement : accessible via un PC dans le bureau des administratifs Scénario normal : On présente la liste des formations. Après choix on affiche la date de la prochaine session. Si pas de session, message. Si le candidat est d'accord, on demande son nom et on cherche s'il est déjà client. Si oui, on récupère ses coordonnées, sinon on les encode. Scénario alternatif : Si la prochaine session est complète, on peut l'inscrire dans une liste d'attente. Celle-ci sera utilisée pour créer la liste des inscrits de la prochaine session créée. Scénario d'exception : …

7 Tests : on testera avec un nouveau client, un client existant, une formation sans session, une session non complète et une session complète. Informations nécessaires : les coordonnées du client (nom, prénom, date de naissance, no national, adresse, tél, [ ], [coordonnées employeur] Contraintes : un minimum d'interactions et d'encodage de la part de l'utilisateur. Risques : connaissance du domaine : bonne compétence designer : moyenne compétence programmeurs : bonne Importance du UC : grande Dictionnaire abstractions: ListeFormations, Formation, Sessions, ListeClients, Inscription, ListeAttente, FicheInscriptionSession Dictionnaire opérations : consulterFormations, consulterSession, inscrireClient, rechercheClient, inscrireListeAttente

8 Exigences pour un bon modèle
Non Ambigu – Chaque phrase n’a qu’une seule interprétation. Les termes choisis sont clairs et précis. Complet – Tous les besoins significatifs sont inclus. Rien n’a été laissé de côté pour définition ultérieure. Vérifiable – Toutes les fonctionnalités faisant partie des spécifications du projet ont un test associé qui déterminera si elles ont été correctement livrées. Cohérent – les terminologies contradictoires, les actions requises contradictoires et les combinaisons impossibles sont absentes. Modifiable – Absence de redondance; l’index et les contenus sont corrects. Traçable – Chaque condition référencée est identifiée de manière unique. Correct – Chaque condition énoncée représente une partie du système à construire.

9 Être testé en un seul "Test Case"
On retiendra qu'un UC doit généralement : Fournir un seul service simple ("benefit") à l'utilisateur, qui doit pouvoir l'utiliser en une seule "session" de travail et éventuellement quitter l'application. Être décrit en une trentaine de mots maximum, avec peu de "et" et de "ou". Être testé en un seul "Test Case" L'Acteur doit "gagner" des informations significatives ou changer le système de façon perceptible.

10 Chaque type d'utilisateur ou Acteur fera aussi l'objet d'une description, par exemple selon un canevas proposé ci-dessous : Localisation : endroit où les utilisateurs se trouvent. Caractéristiques : nombre, compétences et motivation à l'égard du système. Technologie utilisée : portable, station, Windows, browser, … Privilèges par rapport au système (administration des utilisateurs, accès données confidentielles, …).

11

12 Modélisation de l ’existant, analyse des règles de métier
Nous pouvons utiliser le même type de diagramme pour modéliser une situation qui existe, avant de modéliser la solution future. On pourrait tout aussi bien modéliser un système non automatisé, de type “ papier-crayon ”, qu’un système informatique déjà opérationnel dans l’entreprise. On dispose donc des mêmes moyens que les méthodes d’analyse classiques pour les différentes étapes d ’un projet. Le diagramme de use-cases pourrait être, en utilisant des stéréotypes :

13 Traduction d’un scénario
Chaque use-case est explicité par un ou des scénarios, matérialisés par un (ou des) diagrammes de collaboration. Il définit les éléments qui interviennent pour mener à bien le cas d’utilisation et les services nécessaires pour y arriver (les messages échangés). Il faut se souvenir que nous réalisons un modèle “ logiciel ”, c’est-à-dire un modèle des éléments logiciels qui seront intégrés dans l’application pour rendre les services prévus (ceci pour le distinguer du modèle du domaine). On dialogue essentiellement avec le client, il doit comprendre les diagrammes. Le scénario normal du UC "Inscription à une session " repris de la documentation du UC : " On présente la liste des formations. Après choix d'une formation on affiche la date de la prochaine session. Si pas de session, message. Si le candidat est d'accord, on demande son nom et on cherche s'il est déjà client. Si oui, on récupère ses coordonnées, sinon on les encode. «  On peut ajouter le cas alternatif correspondant à une session déjà complète : "Si la prochaine session est complète, on peut l'inscrire dans une liste d'attente. Celle-ci sera utilisée pour créer la liste des inscrits de la prochaine session créée."

14 Traduction d’un scénario

15 Responsabilités et patterns
Le problème : Il s’agit, au début de la séquence, de récupérer les dates associées à une session, pour une formation choisie. La question est donc : quel est l’objet qui connaît cette information et se chargera de fournir ce service (getDatesSession) ? Solution : Isoler la notion de session et en faire un élément “ géré ”, ou “ caché ” par la formation : une session n’a de sens que rattachée à une formation. C’est donc la formation qui connaît la session qui lui est associée et donc peut obtenir les dates. Nul besoin, d’ailleurs, pour récupérer les dates, d’avoir directement accès à l’objet session, ni même de connaître son existence. La formation est responsable de ce savoir, et de la fonction associée. Nous avons donc affecté la responsabilité à l’objet :Formation (donc à la classe Formation), selon une méthode qui passe par la mise en œuvre d’une question classique : “ qui est l’expert en information pour le problème à résoudre ? ” Cette approche, qui doit aider à la construction des diagrammes de séquence, et donc de notre modèle objet, est basée sur l’utilisation de patterns.

16 Responsabilités et patterns
Un pattern décrit un problème et une manière d’arriver à une solution pour ce problème. C’est un couple problème/solution identifié, applicable à d’autres contextes. Le pattern utilisé ci-dessus est le pattern “ Expert en Information ”. Il permet, dans un modèle objet, d’identifier l’objet le plus susceptible de fournir une information déterminée (comme une date de session,…). Ce pattern fait partie de la famille des patterns GRASP, pour General Responsability Assignment Software Patterns. D’autres patterns fondamentaux de la famille sont : Créateur, Forte Cohésion, Faible Couplage, Contrôleur.

17 Le modèle dynamique génère le modèle statique
Toutes les classes créées seront immédiatement "rangées" dans la vue logique de notre dossier, dans des packages ad-hoc. Nous avons donc créé des packages "Interfaces utilisateurs" et "Modèle Business". Chaque classe sera complétée par les opérations nécessaires, correspondant aux messages reçus. Nous procédons donc bien à la construction de notre modèle en définissant les interfaces des classes  Le principe d’inversion des dépendances sera respecté.

18 Un diagramme d’activités...

19 Le modèle logique statique
On peut déjà opérer une répartition des éléments en différents packages logiques, dans la mesure où les diagrammes de séquence ont permis d’introduire des classes, selon les besoins.

20 Chaque package logique sera détaillé en fonction des éléments qu’il contiendra, par un ou des diagrammes de classes. Package « Modèle de l ’organisation » Package « Interface »

21 On détaille les attributs et les relations entre les classes.

22 Le diagramme de séquence n’a pas fait apparaître un élément important : qui se chargera de créer les différents objets ? Par exemple, qui créera la session associée à une Formation ? Le pattern Créateur nous aidera à résoudre le problème… Dans [LARMAN], on trouve les “ conseils ” suivants. On affectera la création d’une instance d’une classe A à une instance d’une classe B si : La classe B agrège des objets de A La classe B contient des objets de A La classe B enregistre des instances de A B utilise étroitement A B a les données d’initialisation pour créer A (B est un Expert pour la création de A) (source [LARMAN]) On peut donc déduire que Formation est une bonne candidate pour créer la Session, d’autant qu’elle devra garder une référence sur celle-ci.

23 Entre notre classe d’interface utilisateur et les classes métier...

24 Entre notre classe d’interface utilisateur et les classes métier...
Nous utilisons le pattern “ Faible Couplage ” qui dit qu’il faut minimiser les dépendances et ainsi réduire l’impact des changements.

25

26 Synthèse relative aux patterns
Comment se présente un pattern ? Un pattern doit être identifié par : Un nom Le problème résolu La solution apportée Un exemple éventuel Les contre-indications Les patterns associés

27 Synthèse relative aux patterns
Exemple : Expert en Information Problème : à quelle classe affecter une responsabilité déterminée (une fonction à exécuter ou un service à fournir à remplir) ? Solution : on affectera la responsabilité à la classe qui connaît l’information nécessaire pour fournir le service. Exemple dans notre contexte de problème : la Formation connaît la ou les sessions qui lui sont associées. Chaque Session connaît les dates qui lui sont affectées. En respectant le pattern de Faible Couplage et celui d’Expert, nous avons attribué à la Formation la responsabilité de fournir les dates d’une Session. La Formation utilisera d’ailleurs une fonction de la Session pour y arriver. Mais pour le reste du logiciel, la responsabilité est bien attribuée à la classe Formation. Patterns associés : Faible Couplage et Forte Cohésion.