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

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 LanguageNormalisé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, ...

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 ?

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.

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

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. BastianelliClient : Inpres Formation, Jimmy Piette

Date de création : 6 juin 2001Mises à jour : 2 juillet 2001, description simpleActeurs : enclenché par un AdministratifEffets : 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ériodiqueTechnique de déploiement : accessible via un PC dans le bureau des administratifsScé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 : …

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 : moyennecompétence programmeurs : bonne

Importance du UC : grandeDictionnaire abstractions: ListeFormations, Formation, Sessions, ListeClients, Inscription, ListeAttente, FicheInscriptionSessionDictionnaire opérations : consulterFormations, consulterSession, inscrireClient, rechercheClient, inscrireListeAttente

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.

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.

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

Modélisation de l ’existant, analyse des règles de métierNous 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 :

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

Traduction d’un scénario

Traduction d’un scénario

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.

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.

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

Un diagramme d’activités...

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.

Le modèle logique statique

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 »

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

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.

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

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.

Catégorie ExempleA est un élément physique de B Tiroir caisse - Registre des ventes

Aile – AvionA est une élément logique de B LigneArticles – Vente

Etape – Itinéraire completA est physiquement contenu dans B Registre des ventes – Magasin

Article – RayonnagePassager – Avion

A est logiquement contenu dans B Description d’article – CatalogueVol – Horaire des vols

A décrit B Description d’articles – ArticleDescription de vol - Vol

A fait l’objet d’une transaction ou d’un rapport B LigneArticle – VenteTâche de maintenance – Journal de maintenance

A est connu/consigné/enregistré/saisi dans B Vente – Registre des ventesRéservation – Manifeste de vol

A est membre de B Caissier – MagasinPilote – Compagnie

A est une sous-unité organisationnelle de B Rayon – MagasinMaintenance – Compagnie

A utilise ou gère B Caissier – registre des ventesPilote – Avion

A communique avec B Client – CaissierAgent de réservation – Passager

A est lié à une transaction B Client – PaiementPassager – Billet

A est une transaction liée à une transaction B Paiement – VenteRéservation – Annulation

A est voisin de B Article A – Article BVille A – Ville B

A appartient à B Caisse enregistreuse – MagasinAvion – Compagnie

A est un événement lié à B Vente – Client, Vente – MagasinDépart – Vol

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

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.