[PDF] Analyse des Besoins (Spécifications)

View - Download Analyse des Besoins (Spécifications)

Previous PDF

Next PDF

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet1

Génie LogicielGénie LogicielAnalyse des BesoinsAnalyse des Besoins(Spécifications)(Spécifications)Renaud MarletLaBRI / INRIAhttp://www.labri.fr/~marlet(d'après A.-M. Hugues)màj 17/04/2007

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet2

Analyse des besoins :Analyse des besoins :Position dans le cycle de viePosition dans le cycle de vieContexte :-problème posé par le client : cahier des chargesPhase d'analyse des besoins :

-formulation d'une réponse à ce problème (proposition)→ dossier d'analysePhase suivante : planificationTerminologie alternative :-définition du produit, spécification

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet3

Objectifs de ce coursObjectifs de ce coursDonner des éléments structurants-points clés du dossier d'analyse-techniques et outils standards de spécificationIntérêt-pour celui qui va écrire des spécifications-pour celui qui va lire des spécifications-techniques réutilisables dans d'autres contextes

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet4

Plan du coursPlan du coursDossier d'analyse-contenu, importance, qualité, ...Techniques et outils de spécification-modèles, représentations, ...Interface utilisateur-méthodologie, ergonomie, ...Maquettage et prototypage-nature, intérêt, ...

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet5

Plan du coursPlan du cours→ Dossier d'analyse-contenu, importance, qualité, ...Techniques et outils de spécification-modèles, représentations, ...Interface utilisateur-méthodologie, ergonomie, ...Maquettage et prototypage-nature, intérêt, ...

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet6

Contenu du dossier d'analyse (1)Contenu du dossier d'analyse (1)Description des fonctions du produit-complète et détaillée-y compris dans sa relation avec l'environnementAttention :-seules sont décrites les fonctions visibles de l'usager-pas l'architecture modulaire du produit→ " boîte noire »

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet7

Contenu du dossier d'analyse (2)Contenu du dossier d'analyse (2)spécifications fonctionnellesspécifications non-fonctionnellespremière version du glossaire(et dans le cas d'un cycle de vie en V :+ tests de validation et de qualification+ première version du manuel utilisateur)

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet8

Cycle de vie :Cycle de vie :modèle en V (rappel)modèle en V (rappel)SpécificationsConception globaleConception détailléeProgrammationQualificationTests d'intégrationTestsunitaires(Expressiondes besoins)(Validationdes besoins)

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet9

Importance du dossier d'analyseImportance du dossier d'analyseErreur dans la spécification→ coût important si découvert trop tardÀ la base du contrat-protection du client (engagement du fournisseur)-protection du fournisseur (attente client bien définie)

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet10Dossier d'analyse : fait par qui ?Dossier d'analyse : fait par qui ?Généralement réalisé par-des membres de l'unité de développementParfois réalisé par le client-attente d'un produit précisParfois donné par une norme-protocole, format d'échange, ...☛ exercice : citez des exemples

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet11Dossier d'analyse : fait pour qui ?Dossier d'analyse : fait pour qui ?Pour le client :-description précise de ce qui sera réalisé→ permet d'anticiper la mise en exploitationPour les développeurs :-référence précise et non ambiguë→ ce qu'il s'agit de réaliser→ ce qu'il s'agit de tester

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet12Plan type du dossier d'analysePlan type du dossier d'analyse☛ plan indicatif !(ne pas nécessairement le suivre à la lettre)1) Introduction-objectifs-fonctionnalités attendues-environnement-faisabilité et justifications-ressources nécessaires-éléments de coût et échéancier

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet13Plan type du dossier d'analysePlan type du dossier d'analyse2) Concepts et terminologie-glossaire de l'application☛ Peut être en annexe, ou bien un document autonome utilisé et partagé dans tout le projet

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet14Plan type du dossier d'analysePlan type du dossier d'analyse3) Description fonctionnelle externe3.1) Pour chaque " fonction » :(☛ fonctionnalité abstraite, pas une routine de programme !)entrées (multi-canales)traitementsorties (multi-canales) : effetsdétails éventuels :-conditions d'arrêt-exceptions, points de reprise, traitement des anomalies-si traitement trop complexe à décrire : algorithme suggéré

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet15Plan type du dossier d'analysePlan type du dossier d'analyse3) Description fonctionnelle externe (suite)...3.2) Organisation logique des donnéestypes de donnéesdomaines de variation3.3) Interface homme-machinefenêtres et écransétats (représentés ou non) et transitions

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet16Plan type du dossier d'analysePlan type du dossier d'analyse4) Description interne 4.1) Interaction avec l'environnementcomposants logiciels nécessaires aux fonctions en 3.1 (ex. base de données existante)4.2) Contraintescontraintes de réalisation (ex. encombrement mémoire)contraintes de qualité (ex. précision du calcul)performancescritères de vérification des contraintespriorités

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet17Plan type du dossier d'analysePlan type du dossier d'analyse5) Questions ouvertes et réponses apportées par les développeurs-précisions, faisabilité (éléments de prototypage)-...6) Éléments de livraison-cahier provisoire de recetteconstitution des lotstests de recettedates issues de la planification

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet18Qualités du dossier d'analyse (1)Qualités du dossier d'analyse (1)Précis-formulation non ambiguëCohérent-pas de contradictions

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet19Qualités du dossier d'analyse (2)Qualités du dossier d'analyse (2)Complet-pas d'oubliscouverture de tous les besoins (→ cahier des charges)description exhaustive des fonctionnalitésArgumenté-liaison claire (références) avecdes besoins exprimés dans le cahier des charges(des objectifs exprimés dans la spécification d'objectifs)☛ critère de traçabilité (→)

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet20Qualités du dossier d'analyse (3)Qualités du dossier d'analyse (3)Traçable-pouvoir suivre le devenir des fonctionnalités dans les phases ultérieures (implémentation, test)Maintenable / flexible-comment prendre en compte les évolutions futures?

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet21Forme du dossier d'analyseForme du dossier d'analyseSéparation des concepts= 1 concept par paragrapheNumérotation des paragraphes et/ou sections→ facilité de référence→ traçabilité (dans les phases ultérieures)

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet22Plan du coursPlan du coursDossier d'analyse-contenu, importance, qualité, ...→ Techniques et outils de spécification-modèles, représentations, ...Interface utilisateur-méthodologie, ergonomie, ...Maquettage et prototypage-nature, intérêt, ...

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet23Modèle conceptuelModèle conceptuelDonne une image " mentale » du produit (!)Recense les fonctionnalités attenduesPoint de départ à :-l'analyse des besoins-l'interface utilisateur☛ ExtrêmeExtrême importance

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet24Modèle conceptuelModèle conceptuelÉlaboré à partir des interviews d'utilisateursDéfinit, pour chaque grande fonction du produit :-les objets (ou entités) que le produit crée/manipule-les attributs de ces objets-les opérations à réaliser sur ces objets

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet25Exercice :Exercice :Définir un modèle conceptuelDéfinir un modèle conceptuelMessagerie téléphonique du type SMS / texto :-consulter les messages dans la boîte de réception-supprimer un message-envoyer un message-faire suivre ou répondre à un message-consulter les contacts dans le répertoire-ajouter et supprimer des contacts dans le répertoireQuels sont les objets et les relations (notamment de possession) entre objets ?

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet26Objets et relations dans une Objets et relations dans une messagerie textuelle téléphoniquemessagerie textuelle téléphoniqueObjets-boîte de réception-message (2 types : reçu, en cours de rédaction)-répertoire-contactRelations-la boîte de réception contient une liste de messages-un message provient de / est destiné à un numéro-un contact a un nom et un numéro

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet27Modèle conceptuel de la messagerieModèle conceptuel de la messagerieExercice : remplir le tableauExercice : remplir le tableauGrand type de

fonction du produit

Objet (et attributs)Liste des opérations

Exemple de

contraintes

éventuelles

gestion de la boîte de réception gestion d'un message reçu création d'un nouveau message gestion du répertoire gestion d'un contact

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet28Exemple de modèle conceptuelExemple de modèle conceptuelde la messageriede la messagerieGrand type de

fonction du produit

Objet (et attributs)Liste des opérations

Exemples de

contraintes

éventuelles

gestion de la boîte de réception boîte de réception (liste de messages reçus) consulter la liste, sélectionner un msg nombre maximum de messages gestion d'un message reçu message reçu (suite de caractères non modifiable) lire, faire suivre, répondre, supprimer création d'un nouveau message message en cours (suite de caractères)éditer, envoyer, annulertaille maximum d'un message gestion du répertoire répertoire (liste de contacts) consulter la liste, ajouter un contact, sélectionner un contact nombre maximum de contacts gestion d'un contact contact (nom, numéro)modifier, supprimertaille maximum du nom, du numéro

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet29Choix dans le modèle conceptuelChoix dans le modèle conceptuelAjout et de suppression de message-opération sur un message sur la boîte de réception ?Ajout et suppression de contact-opération sur un contact ou sur le répertoire ?Plus généralement, il y a un choix quand une opération-relie deux objets-en particulier : un contenant avec un contenu

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet30Importance du modèle conceptuelImportance du modèle conceptuelIl structure-identification de concepts, objets, attributs, opérations et de leur articulationIl fonde l'intuition-image mentale : analogie avec des concepts, objets, attributs et opérations connus -apprentissage réduitIl facilite l'interaction-efficacité, productivité

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet31Importance du modèle conceptuelImportance du modèle conceptuelImpact sur tout les acteurs -utilisateur-développeur (projet complexe)-décideur

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet32Différents types deDifférents types demodèles conceptuelsmodèles conceptuelsModèle de simulation-lien avec un existant concretModèle structurel-abstraction→ On va en donner des exemples

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet33Modèle conceptuel de simulationModèle conceptuel de simulationExemple : traitement de texteExemple : traitement de texte☛ Recréer une technologie connue→ Machine à écrire, papier-page = zone rectangulaire contenantdes cellules (caractères ou blancs) [regroupées en lignes]un curseur (là où le prochain caractère s'imprime)-actionssurimpression d'un caractère où se trouve le curseur→ écrire, effacer (blancs), copier des caractères [sur une ligne](d'après P. Baudelaire)

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet34Modèle conceptuel structurelModèle conceptuel structurelExemple : traitement de texteExemple : traitement de texte☛ Manipulation et représentation d'entités abstraites→ Document = chaîne de caractères arbitrairement longue, organisée hiérarchiquement en sections, paragraphes, mots...-manipulations à travers cette structure logiqueinsérer, détruire, remplacer, déplacer, copierpas de limitation à des opérations sur une seule lignespécification et enregistrement de règles de formatage→ changer le style sans changer le contenu(d'après P. Baudelaire)

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet35Comparaison des différents types Comparaison des différents types de modèles conceptuelsde modèles conceptuelsModèle de simulation-avantage : intuition facile-inconvénient : peut être limitatifModèle structurel-avantage : plus général, plus puissant-inconvénient : peut demander un plus grand travail de conceptualisation

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet36Dictionnaire de donnéesDictionnaire de donnéesSouvent amorcé par le modèle conceptuelConstitué au fur et à mesure de l'analyse→ Nom de tous les objets utilisés(+ attributs, opérations, ...)-classement alphabétique (+ synonymes ou alias)-lien avec de futures entités issues du développementvariables, fonctions, classes, ...

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet37Modèle conceptuel etModèle conceptuel etbesoins de spécificationbesoins de spécificationDescriptions avec des mots-concepts, objets, attributs, opérations...Besoin de structuration-pour la précision-pour la complétude (comment être systématique?)-pour la lisibilité→ Représentations tabulaires

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet38Table de décisionTable de décisionDéfinition des valeurs de sorties en fonctions des valeurs d'entrée et de leurs combinaisonsAdapté aux systèmes dont les sorties ne dépendent que des entrées (et pas de l'état courant)

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet39Exemple :Exemple :" date et heure » de MAC OS X" date et heure » de MAC OS X

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet40Table de décision : ExempleTable de décision : Exemple" date et heure » de MAC OS X" date et heure » de MAC OS XAffichage du jour de la semaine (lundi, mardi, ...) :-Paramètres d'entrée :" Afficher dans » : [barre des menus] ou [fenêtre]" Affichage » : [numérique] ou [analogique]-Paramètre de sortie :" Afficher le jour de la semaine » : oui, non, optionnelAfficher le jour de la semaineAffichage :

numérique

Affichage :

analogique

Afficher dans : barre des

menus optionnelnon

Afficher dans : fenêtreouinon

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet41Table de décision : ExempleTable de décision : Exemple" date et heure » de MAC OS X" date et heure » de MAC OS XAffichage de l'heure avec les secondes-Paramètres d'entrée :" Afficher dans » : [barre des menus] ou [fenêtre]" Affichage » : [numérique] ou [analogique]-Paramètre de sortie :" Afficher l'heure avec les secondes » : oui, non, optionnelAfficher l'heure avec les secondesAffichage :

numérique

Affichage :

analogique

Afficher dans : barre des menusoptionnelnon

Afficher dans : fenêtrenonoptionnel

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet42QuestionQuestionQuelle structure de table-s'il y a plusieurs paramètres de sortie ?

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet43Réponses possiblesRéponses possiblesQuelle structure de table-s'il y a plusieurs paramètres de sortie ?

→ Autant de tables que de paramètres de sortie (↑) → Liste des sorties dans chaque case (→)

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet44Table de décision : ExempleTable de décision : Exemple" date et heure » de MAC OS X" date et heure » de MAC OS XAffichage du jour de la semaine et des secondes :-Paramètres de sortie :" Afficher le jour de la semaine » : oui, non, optionnel" Afficher l'heure avec les secondes » : oui, non, optionnelAfficher le jour

et/ou les secondesAffichage : numériqueAffichage : analogique

Afficher dans :

barre des menus jour optionnel secondes optionnelles jour absent secondes absentes

Afficher dans :

fenêtre jour présent secondes absentes jour absent secondes optionnelles

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet45QuestionQuestionQuelle structure de table-s'il y a plus de deux paramètres d'entrée ?

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet46Réponse possibleRéponse possibleQuelle structure de table-s'il y a plus de deux paramètres d'entrée ?

→ Combinatoire-autant de colonnes que de paramètres d'entrée-et toutes les combinaisons possibles

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet47Table de décision : Exemple (1)Table de décision : Exemple (1)3 paramètres d'entrée (booléens)1 paramètre de sortie (booléen)N.B. pas de titre pour les lignesABC(A ∧ B) ∨ C

VVVV VVFV VFVV VFFF FVVV FVFF FFVV FFFF

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet48Table de décision : Exemple (2)Table de décision : Exemple (2)3 paramètres d'entrée (booléens), 1 de sortie (booléen)résultats intermédiaires pour la compréhensionN.B. pas de titre pour les lignesABCA ∧ B(A ∧ B) ∨ C

VVVVV VVFVV VFVFV VFFFF FVVFV FVFFF FFVFV FFFFF

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet49QuestionQuestionQuelle structure de table-s'il y a plusieurs paramètres d'entrée

et plusieurs paramètres de sortie ?

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet50Réponse possibleRéponse possibleQuelle structure de table-s'il y a plusieurs paramètres d'entrée

et plusieurs paramètres de sortie ?

→ Combinatoire-autant de colonnes que de paramètres d'entréeet de paramètres de sortie-et toutes les combinaisons possibles

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet51Table de décision : ExempleTable de décision : Exemple" date et heure » de MAC OS X" date et heure » de MAC OS XDeux paramètres d'entrée :-" afficher dans », " affichage »Deux paramètres de sortie :-jour de la semaine, heure avec les secondesAfficher dansAffichageJour de la

semaineSecondes barre des menusnumériqueoptionneloptionnel barre des menusanalogiquenonnon fenêtrenumériqueouinon fenêtreanalogiquenonoptionnel

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet52Capacité de représentation d'une Capacité de représentation d'une table de décisiontable de décisionExprimer une fonction= sorties définies en fonction des entréesExprimer une relation= quelles combinaisons d'entrées et de sorties sont acceptables-peu courantnon-déterminismeconfusions / oublis possibles

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet53Table de décision etTable de décision etbesoins de spécification (1)besoins de spécification (1)Table de décision :-sorties en fonction (ou en relation avec) des entréesLimites : besoin de modéliser-l'état du système-des relations entrées-sorties dépendant de l'état-des relations entrées-sorties modifiant l'état→ Comment faire ?

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet54Table de décision etTable de décision etbesoins de spécification (2)besoins de spécification (2)Besoin de modéliser-l'état du système→ traiter l'état comme un paramètre ordinaire-des relations entrées-sorties dépendant de l'état→ état comme paramètre d'entrée supplémentaire-des relations entrées-sorties modifiant l'état→ état comme paramètre de sortie supplémentaire→ Table de transition

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet55Table de transitionTable de transitionAutomate modélisant la dynamique du systèmeAdapté aux systèmes dont les sorties sont déterminées-non seulement par les entrées-mais aussi par l'état/historique des entrées antérieures

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet56Table de transition : ExempleTable de transition : Exempleautorisation d'accès par loginautorisation d'accès par login2 états :-logué, délogué4 opérations :-se loguer, se déloguer, lire, écrire ÉtatOpérations autoriséesÉtat résultant

déloguése loguerlogué loguélire, écrirelogué loguése déloguerdélogué

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet57QuestionQuestionStructures de table :-Quels cas sont bien traités ?-Quels cas ne sont pas bien traités ?

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet58Tables (de décision, de transition) etTables (de décision, de transition) etbesoins de spécificationbesoins de spécificationBien adaptées tant que le problème est petitNe passent pas à l'échelle (s'il y a un grand nombre de paramètres d'entrée, de sortie ou d'états)-croissance exponentielle-mauvaise lisibilité-risque d'erreurs (oublis, incohérences, ...)☛ Comment faire ?

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet59Représentations graphiquesReprésentations graphiquesPouvoir d'expression :-représentation des données et des traitementsCaractéristiques :-plus synthétiques que les tables-sans nécessairement perte de précision

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet60Représentations graphiquesReprésentations graphiquesPas un dessin arbitraire !-en fait, " langage » normalisé-sémantique non ambiguë (ou peu ambiguë, si accompagnées de textes en langue naturelle)☛ Représentations " semi-formelles »

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet61Intérêt desIntérêt desreprésentations graphiquesreprésentations graphiquesRenforcement de la précision et de la lisibilitéRéduction du risque d'oubli (→ systématique)Passage à l'échelle(éventuellement en rajoutant de la modularité)Plus intuitives bien que plus formelles→ favorisent la communication entre le développeur et l'utilisateur (le client)

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet62Représentations graphiquesReprésentations graphiquesModèle entité-associationDiagramme de flot de donnéesDiagramme états-transitionsRéseau de Petri...

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet63Modèle entité-associationModèle entité-associationDate de 1976 (P. Chen) mais toujours très utiliséReprésentation des données d'un système et des relations les liant(Utilisé notamment pour la conception de bases de données relationnelles, mais avec des contraintes supplémentaires, ex. non circularité)

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet64Modèle entité-associationModèle entité-associationUne entité est

-un objet que l'on sait distinguer d'un autre-ex. : livre dans une bibliothèqueChaque entité a des attributs (ou propriétés)-ex. : titre, nom, numéro, ...Chaque attribut prend ses valeurs sur-un domaine de valeurs autorisées-ex. : chaîne de caractères, entier de 1 à 31, ...

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet65Modèle entité-associationModèle entité-associationLes entités peuvent être regroupées en des ensembles d'entités ayant-les mêmes attributs avec des valeurs différentes-ex. : livres d'une bibliothèque, clients d'une entrepriseUne clé ou un identifiant-permet de distinguer une entité (ou un ensemble d'entités) d'un(e) autre-ex. : titre d'un livre, ou numéro de référence si plusieurs exemplaires du même livre

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet66Modèle entité-associationModèle entité-associationUne relation entre différentes entités ou ensemble d'entités est-un lien d'association entre eux (possession, dépendance, ...)-ex. : un livre possède un auteur, un client d'une banque possède un ou des comptes en banqueLa cardinalité d'une relation est-le nombre de liens (minimum, maximum) pour un ensemble d'entités

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet67Modèle entité-association :Modèle entité-association :Notations graphiquesNotations graphiquesEntités représentées par des rectanglesAttributs attachés aux entités : liste d'attributsIdentifiant de l'entité : item souligné dans la listeRelations : ovalesCardinalités : (x,y) c.-à-d. entre x et y

adhérentcassetteemprunterest empruntée(0,1)emprunte(0,n)N°exemplairedate d'achatnb empruntsétat

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet68Modèle entité-associationModèle entité-associationExemple : vidéothèqueExemple : vidéothèquedateadhérentcassettefilmprixemprunterest empruntée(0,1)emprunte(0,n)fournisseurreproduirecarteposséder est possédée (1,1) possède (1,1)réserver réserve(0,n)numéronomcautionnb filmsnuméroref fournisseurnom fournisseuradresse fournisseurtéléphone fournisseurresponsable commercial reproduit (1,1) est reproduit par (0,n)code filmtitreréalisateuracteursgenrerésuméfournirest fourni (1,n) fournit(1,n) est réservé (0,n) N°exemplairedate d'achatnb empruntsétat

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet69Modèle entité-association etModèle entité-association etbesoins de spécificationbesoins de spécificationRelations ↔ états statiques possiblesNe rend pas compte de la dynamique-des traitements-du flux d'information→ Diagrammes de flot de données

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet70Diagramme de flot de donnéesDiagramme de flot de donnéesModélise-les gisements d'information-le transit des données-les traitementsExprime-comment chaque processus (traitement) transforme ses entrées en sorties (flot entrant et sortant)(aussi appelé " diagramme de contexte »= idem avec agents extérieurs intervenant sur le produit)

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet71Diagramme de flot de donnéesDiagramme de flot de donnéesExemple : gestion des empruntsExemple : gestion des empruntsdemanded'empruntcartevérificationcassettevérificationclientenregistrementempruntstock decassettescomptesclientsN°cassettecassettecarte modifiéeréférence filminfos filmN°carteN°clientrefusrefus

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet72Diagramme de flot de donnéesDiagramme de flot de donnéesAffinements successifs :-zoom sur une boîte-numérotation arborescente (ex. : A.D.3)-veiller à la cohérence des entrées et sorties

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet73Diagramme de flot de donnéesDiagramme de flot de donnéesConseils :-Entre 2 et 6 activités par diagramme (sinon découper)-Flot globalement de gauche à droite, de bas en haut-Éviter les croisements de flèches(↑)

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet74Diagrammes de flot de données etDiagrammes de flot de données etbesoins de spécificationbesoins de spécificationNe conviennent pas pour le flot de contrôle☛ ce ne sont pas des organigrammes !Ne rendent pas compte de-la dynamique des traitements-l'enchaînement des traitements dans le temps→ Diagrammes états-transitions

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet75Diagramme états-transitionsDiagramme états-transitionsGraphe :-noeud = état-arête = transition, étiquetée parles événements qui provoquent la transitionou les événements provoqués par la transitionReprésentation ordinaire des automates finis

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet76Diagramme états-transitions :Diagramme états-transitions :Ex. Cassette dans une vidéothèqueEx. Cassette dans une vidéothèqueCassette commandéeCassette disponibleCassette empruntéeCassette perdueLivraison de la cassette etenregistrement de l'entrée de la cassetteEmprunt de la cassette etenregistrement de l'empruntDemande d'emprunt etréponse N° de cassetteRetour cassette etenregistrement du retourTemps d'emprunt dépassé etenregistrement de la perte de la cassetteDemande d'empruntet réponse de refus

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet77Diagrammes états-transitionsDiagrammes états-transitionsRendent compte de :-la dynamique des traitements-l'enchaînement des traitements dans le tempsExemples d'application-comportement d'un objet réactif-enchaînements d'écrans avec IHM complexes

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet78Comparaison : Table de transition etComparaison : Table de transition etDiagramme états-transitions Diagramme états-transitions déloguéloguése loguerse déloguerlire, écrireÉtatOpérations autoriséesÉtat résultant

déloguése loguerlogué loguélire, écrirelogué loguése déloguerdélogué 1 2a c d b ea

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet80Non-déterminisme (2)Non-déterminisme (2)Automate déterministe-plus lisible (une seule transition à suivre)-moins compact si le problème comporte de l'indéterminisme (peut être exponentiellementplus grand)Automate non déterministe-moins lisible (suivre des transitions en parallèle)-plus compact (donc plus lisible ☺)

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet81Diagramme états-transitions etDiagramme états-transitions etbesoins de spécificationbesoins de spécificationNe permettent pas d'exprimer la " concurrence » (= parallélisme)→ Réseaux de Petri

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet82Réseau de PetriRéseau de PetriGraphe biparti-sommets répartis en 2 groupes-chaque arête a une extrémitédans un groupe et une extrémitédans l'autre groupeSommets (noeuds)-place → étatmarques (jetons) dans certainesplaces, à un instant donné-transition → changement d'état•••place entrée(pré-condition)place entrée(pré-condition)place sortie(post-condition)transition

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet83Réseau de PetriRéseau de PetriDéclenchement d'une transition :-présence de jetons dans toutes les places entrée-décrémentation du nb de marques des places entrée-incrémentation du nb de marques des places sortie-non-déterministe, atomique•

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet84Réseau de Petri : ExempleRéseau de Petri : ExempleDélivrance d'une cassetteDélivrance d'une cassette•P1P3P2P7P6P5P4P8T1T2T3T4T5T6P1 : emprunt demandéP2 : vérification de la cassetteP3 : vérification de l'adhérentP4 : emprunt refuséP5 : emprunt possibleP6 : emprunt possibleP7 : emprunt refuséP8 : emprunt autoriséT1 : préparation de la vérification (action)T2 : cassette empruntée (condition)T3 : cassette disponible (condition)T4 : adhérent en règle (condition)T5 : adhérent pas en règle (condition)T6 : autoriser l'emprunt (action)emprunt autorisé si cassette disponible et adhérent en règle

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet85Réseau de PetriRéseau de PetriOrdonnancement des activitésModélisation-systèmes parallèles à événements discrets-concurrence, coopération-ex. exclusion mutuelle, producteur/consommateurExtensions-marques colorées, arcs inhibiteurs, limites de taille, transitions sources, transitions puits, ...Variante (dual) : Grafcet

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet86Méthodes semi-formellesMéthodes semi-formellesRépandues dans l'industrieNombreux outils qui les implémententInconvénient : manque (parfois) de rigueur mathématique→ Méthodes formelles

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet87Méthodes d'analyse formelles :Méthodes d'analyse formelles :CaractéristiquesCaractéristiquesSpécifications formelles = objets mathématiques→ modélisations analysables par les mathématiquesNécessité d'une analyse profonde du problème→ meilleure maîtrisePreuves formelles (mathématiques)→ certaines propriétés garanties (sûreté, sécurité, ...)ex. correction : programme conforme à sa spécification

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet88Méthodes d'analyse formelles :Méthodes d'analyse formelles :Capacités automatiquesCapacités automatiquesAide au développement-debug de spécification (vérification de cohérence)-génération (semi-)automatique de code-génération (semi-)automatique de testsAnimation d'une spécification~ génération de prototype

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet89Méthodes d'analyse formelles :Méthodes d'analyse formelles :Problèmes objectifsProblèmes objectifsCertains problèmes difficilement spécifiables-interface homme-machine, système temps-réel, ...Manque de formation-ingénieurs logiciel ≠ mathématiciens, logiciensEfforts plus sur les notations que sur les outils-preuves faisables mais difficiles à réaliser en pratique

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet90

Méthodes d'analyse formelles :Méthodes d'analyse formelles :CroyancesCroyancesCroyances (conservatrices) du management-rentabilité pas prouvée-en fait : souvent plus cher mais de meilleure qualitéCroyance (frileuse) des développeurs :-peu de problèmes spécifiables formellement-en fait : gros systèmes déjà spécifiés (gestion de fichiers Unix, JavaCard, systèmes de transport, ...)Croyance (naïve) des chercheurs :-problèmes de développement résolus dès qu'on adopte des méthodes formelles

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet91

Méthodes d'analyse formelles :Méthodes d'analyse formelles :Quelques formalismesQuelques formalismesSpécifications opérationnelles(= enchaînement des actions)-automates, systèmes de transition, logique de Hoare-langages : VDM, Z, B, ...Spécifications axiomatiques(= propriétés que doivent satisfaire les implémentations)-spécifications algébriques : OBJ, Larch, ...

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet92

Méthodes d'analyse formelles :Méthodes d'analyse formelles :La situation aujourd'huiLa situation aujourd'huiPeu répandues-utilisées pour des systèmes critiques (sécurité)Mais représentent l'avenir de la spécification-mais avenir lointainBesoin d'outils-plus simples (moins d'expertise nécessaire)-plus puissants (moins de choses à expliciter)

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet93 Et aussi...Et aussi...Critères Communs (CC)-sécurité... Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet94

Récapitulatif desRécapitulatif desTechniques et outils de spécificationTechniques et outils de spécificationModèle conceptuelReprésentations tabulaires :-table de décision-table de transitionReprésentations graphiques semi-formelles :-modèle entité-association-diagramme de flot de données-diagramme états-transitions-réseau de Petri, ...Méthodes formelles

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet95

Plan du coursPlan du coursDossier d'analyse-contenu, importance, qualité, ...Techniques et outils de spécification-modèles, représentations, ...→ Interface utilisateur-méthodologie, ergonomie, ...Maquettage et prototypage-nature, intérêt, ...

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet96

Interface utilisateurInterface utilisateurSouvent objet de concurrence entre applications(peu de différences " sous le capot »)Reflet des fonctionnalités du produit[ Terminologie :-français : interface homme-machine (IHM), interface graphique-anglais : graphical user interface (GUI) ]

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet97

Spécification deSpécification del'interface utilisateur l'interface utilisateur Tôt dans le cycle de vie-spécifications fonctionnellesNombreuses discussions avec l'utilisateur/client-maquette pour valider l'interface(~ seul moyen efficace d'une discussion profitable)

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet98

Interface utilisateur : MéthodologieInterface utilisateur : MéthodologiePartir du modèle conceptuel des données et traitementsDéfinir un modèle conceptuel du dialogue-représentation de l'information-interactions☛ Choix crucial d'un bon modèle conceptuel

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet99

Interface utilisateur : Ergonomie (1)Interface utilisateur : Ergonomie (1)Convivialité-facilité d'utilisation-mesure : ex. nombre de jours d'apprentissageEfficacité-productivité des utilisateurs (→ mesure)-caractériser les types d'utilisateurs cibléscompétencebut du travailperformances attendues, ...

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet100Interface utilisateur : Ergonomie (2)Interface utilisateur : Ergonomie (2)Lisibilité-mise en avant des données pertinentes/prioritaires-regroupement des données similaires-alignement visuel des données-sens/ordre de lecture " ordinaire »-stabilité d'un écran à l'autreStandardisation-marché, influence du système d'exploitation/fenêtrage-normes de l'entreprise-conventions liées au domaine

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet101Interface utilisateur : Outils (1)Interface utilisateur : Outils (1)Utilisation de " briques de base » standards-fenêtres, boîtes de dialogue, onglets-menus : fixes, déroulants, pop-up-boutons, jauges-choix : cases à cocher, boutons radio, vidéo inverse-raccourcis clavier-aides visuelles : icônes, couleurs-effets visuels : images, animations-...

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet102Interface utilisateur : Outils (2)Interface utilisateur : Outils (2)Utilisation de bibliothèques standards-X Athena Widget-Motif-Tk-Swing-GTK, GTK+-OpenGL-...

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet103Plan du coursPlan du coursDossier d'analyse-contenu, importance, qualité, ...Techniques et outils de spécification-modèles, représentations, ...Interface utilisateur-méthodologie, ergonomie, ...→ Maquettage et prototypage-objectifs, nature, intérêt, ...

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet104Maquettage et prototypageMaquettage et prototypageQuand :-après le premier jet des spécifications fonctionnellesObjectifs :-montrer au client à quoi ressemblera le produit-valider les besoins et les spécifications

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet105MaquetteMaquetteSystème incomplet dont l'aspect extérieur est +/- le même que le produit à réaliserDestiné à tester l'ergonomie du produitInstaure un dialogue développeur-utilisateurNe permet pas le test de performanceSouvent jetable

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet106PrototypePrototypeEsquisser ce que sera le produit final-les fonctionnalités-sans contraintes (fiabilité, ...)Valider les besoins utilisateur-réalisables ?Valider les spécifications-complètes, réalistes, non contradictoires ?Souvent jetable (sinon = prototype évolutif)

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet107PrototypePrototypeIntérêt-évaluer rapidement la faisabilité, mais aussi :-mettre en évidence les incompréhensions développeur-utilisateur-identifier les services difficiles à utiliser-découvrir les contradictions-détecter les oublis de spécification-servir de base à l'écriture de spécifications complètes

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet108PrototypePrototypeIgnorer les critères non-fonctionnels :-temps de réponse, contraintes mémoire-traitements d'erreur-standards-fiabilité, robustesse-...(sauf si la faisabilité en dépend !)

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet109PrototypePrototypeChoix d'un langage de prototypage adapté-impératif : perl, shell, java, ...-fonctionnel : ML, lisp, scheme, ...-déclaratif : prolog, ...-spécifique à un domaineex. programmation réactive : ESTEREL, SIGNAL, LUSTREex. modélisation de processus : SIMULA, QNAP2

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet110Prototyper n'est pas spécifierPrototyper n'est pas spécifierUn prototype ne remplace pas des spécifications-il ignore les critères non fonctionnels-il ne peut être une base fiable du contrat (à la différence du dossier d'analyse)

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet111Du prototype à l'implémentationDu prototype à l'implémentationRé-implémentation toujours recommandable-difficulté à intégrer des contraintes non fonctionnelles-dégradation de la structure après prises en compte successives des demandes de l'utilisateurMais-réutilisation possible de certains composants du prototype-réimplémentation plus rapide grâce à une bonne connaissance du problème

Génie logiciel - Définition des besoins © 2005-2007 Renaud Marlet112À retenirÀ retenirQualités du dossier d'analyse-précis, cohérent, complet, argumenté, traçable, flexibleExtrême importance du modèle conceptuel-image mentale : concepts, objets, attributs, opérationsReprésentations graphiques semi-formelles-synthétiques, normalisées, non ambiguës-des diagrammes différents pour des usages différentsNe pas oublier :-aspects non fonctionnels

quotesdbs_dbs29.pdfusesText_35

[PDF] Manuel de qualification et de classification des entreprises

[PDF] Le 'Ministre » »

[PDF] Dossier de validation d 'études - Université de La Rochelle

[PDF] Pro Expérience Client SEPHORA - Ema Sup

[PDF] dossier professionnel de vente - Forum manucure

[PDF] Liste des pièces justificatives pour l 'instruction de la demande - 3F

[PDF] SCHEMA DE LA PROCEDURE D 'ENREGISTREMENT AU RNCP

[PDF] LA REALISATION DU DOSSIER DOCUMENTAIRE

[PDF] Sommaire - Decitre

[PDF] Dossier eleve E22 - Hôtellerie-Restauration

[PDF] Dossier eleve E22 - Hôtellerie-Restauration

[PDF] Dossier eleve E22 - Hôtellerie-Restauration

[PDF] Dossier eleve E22 - Hôtellerie-Restauration

[PDF] Dossier eleve E22 - Hôtellerie-Restauration

[PDF] epreuve e3 - Académie de Nancy-Metz