analyse et conception d une application n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
ANALYSE ET CONCEPTION D'UNE APPLICATION PowerPoint Presentation
Download Presentation
ANALYSE ET CONCEPTION D'UNE APPLICATION

Loading in 2 Seconds...

play fullscreen
1 / 27

ANALYSE ET CONCEPTION D'UNE APPLICATION - PowerPoint PPT Presentation


  • 131 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'ANALYSE ET CONCEPTION D'UNE APPLICATION' - agrata


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
analyse et conception d une application
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...

slide2

Préambule, quelques éléments importants :

Méthode inspirée de GradyBooch

Fusion entre Booch, OMT de Rumbaugh et OOSE de Jacobson

UnifiedModelingLanguage

Normalisée par l ’Object Management Group.

UnifiedMethod

Ateliers de Génie Logiciel : Visual Paradigm , Rational Rose C++, Rational UnifiedProcess

, TogetherC++/Java, Objecteering, Platinum, ...

premier sujet systeme d administration de formations
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 ?

slide4

Description succincte : ce que le UC apporte en terme de fonctionnalités.

  • Intervenantsdans 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 effetsqui 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énariosdé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.
slide5

Scénariosdécrivant les cas "alternatifs" , avec la condition de déclenchement .

  • Scénariosdé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).
  • Contraintespré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 .
  • Importancede 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…).
slide6

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 :

slide7

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, [Email], [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

slide8

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.

slide9

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.
slide10

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, …).
slide12

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 :

slide13

Traduction d’un scénario

Chaque use-case estexplicité 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."

slide15

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.

slide16

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 ResponsabilityAssignment Software Patterns.

D’autres patterns fondamentaux de la famille sont :

Créateur, Forte Cohésion, Faible Couplage, Contrôleur.

slide17

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é.
slide19

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.

slide20

Package « Modèle de l ’organisation »

Chaque package logique sera détaillé en fonction des éléments qu’il contiendra, par un ou des diagrammes de classes.

Package « Interface »

slide22

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.
slide24

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.

slide26

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
slide27

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.