La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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 lapplication,

Présentations similaires


Présentation au sujet: "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 lapplication,"— 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 lapplication, 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 A teliers de G énie L ogiciel : Visual Paradigm, Rational Rose C++, Rational Unified Process, Together C++/Java, Objecteering, Platinum,...

3 PREMIER SUJET : SYSTEME DADMINISTRATION 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 quil 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 dun autre UC, existence dune 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 sil 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 na quune seule interprétation. Les termes choisis sont clairs et précis. Complet – Tous les besoins significatifs sont inclus. Rien na é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; lindex 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 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, quun système informatique déjà opérationnel dans lentreprise. On dispose donc des mêmes moyens que les méthodes danalyse classiques pour les différentes étapes d un projet. Le diagramme de use-cases pourrait être, en utilisant des stéréotypes :

13 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 dutilisation et les services nécessaires pour y arriver (les messages échangés). Il faut se souvenir que nous réalisons un modèle logiciel, cest-à-dire un modèle des éléments logiciels qui seront intégrés dans lapplication 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." Traduction dun scénario

14

15 Responsabilités et patterns Le problème : Il sagit, 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 lobjet qui connaît cette information et se chargera de fournir ce service (getDatesSession) ? Solution :I soler la notion de session et en faire un élément géré, ou caché par la formation : une session na de sens que rattachée à une formation. Cest donc la formation qui connaît la session qui lui est associée et donc peut obtenir les dates. Nul besoin, dailleurs, pour récupérer les dates, davoir directement accès à lobjet 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é à lobjet :Formation (donc à la classe Formation), selon une méthode qui passe par la mise en œuvre dune question classique : qui est lexpert 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 lutilisation de patterns.

16 Responsabilités et patterns Un pattern décrit un problème et une manière darriver à une solution pour ce problème. Cest un couple problème/solution identifié, applicable à dautres contextes. Le pattern utilisé ci-dessus est le pattern Expert en Information. Il permet, dans un modèle objet, didentifier lobjet 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. Dautres 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 dinversion des dépendances sera respecté.

18 Un diagramme dactivités...

19 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 dintroduire des classes, selon les besoins. Le modèle logique statique

20 Chaque package logique sera détaillé en fonction des éléments quil 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 na 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 dune instance dune classe A à une instance dune 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 dinitialisation 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, dautant quelle devra garder une référence sur celle-ci.

23 Entre notre classe dinterface utilisateur et les classes métier...

24 Nous utilisons le pattern Faible Couplage qui dit quil faut minimiser les dépendances et ainsi réduire limpact 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 linformation 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 dExpert, nous avons attribué à la Formation la responsabilité de fournir les dates dune Session. La Formation utilisera dailleurs 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.


Télécharger ppt "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 lapplication,"

Présentations similaires


Annonces Google