Analyse des Besoins (Spécifications) - IMAGINEimagine.enpc.fr/~marletr/LaBRI/teaching/GenLog/slides/GenLog... · Génie logiciel – Définition des ... Position dans le cycle de

Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 1

Génie LogicielGénie Logiciel

Analyse des BesoinsAnalyse des Besoins

(Spécifications)(Spécifications)

Renaud Marlet

LaBRI / INRIAhttp://www.labri.fr/~marlet

(d'après A.-M. Hugues)

màj 17/04/2007


Analyse des besoins :Analyse des besoins :Position dans le cycle de viePosition dans le cycle de vie

● Contexte :– problème posé par le client : cahier des charges

● Phase d'analyse des besoins :– formulation d'une réponse à ce problème (proposition)

→ dossier d'analyse

● Phase suivante : planification

● Terminologie alternative :– définition du produit, spécification


Objectifs de ce coursObjectifs de ce cours

● Donner des éléments structurants– points clés du dossier d'analyse– techniques et outils standards de spécification

● Inté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


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



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


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'environnement

Attention :– seules sont décrites les fonctions visibles de l'usager– pas l'architecture modulaire du produit

→ « boîte noire »


Contenu du dossier d'analyse (2)Contenu du dossier d'analyse (2)

● spécifications fonctionnelles● spécifications non-fonctionnelles● premiè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)


Cycle de vie :Cycle de vie :modèle en V (rappel)modèle en V (rappel)

Spécifications

Conception globale

Conception détaillée

Programmation

Qualification

Tests d'intégration

Testsunitaires

(Expressiondes besoins)

(Validationdes besoins)


Importance du dossier d'analyseImportance du dossier d'analyse

● Erreur 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)


Dossier d'analyse : fait par qui ?Dossier d'analyse : fait par qui ?

● Généralement réalisé par– des membres de l'unité de développement

● Parfois réalisé par le client– attente d'un produit précis

● Parfois donné par une norme– protocole, format d'échange, ...

☛ exercice : citez des exemples


Dossier 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 exploitation

● Pour 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


Plan 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



2) Concepts et terminologie– glossaire de l'application

☛ Peut être en annexe, ou bien un document autonome utilisé et partagé dans tout le projet



3) Description fonctionnelle externe

3.1) Pour chaque « fonction » :(☛ fonctionnalité abstraite, pas une routine de programme !)● entrées (multi-canales)● traitement● sorties (multi-canales) : effets● détails éventuels :

– conditions d'arrêt– exceptions, points de reprise, traitement des anomalies– si traitement trop complexe à décrire : algorithme suggéré



3) Description fonctionnelle externe (suite)

...

3.2) Organisation logique des données● types de données● domaines de variation

3.3) Interface homme-machine● fenêtres et écrans● états (représentés ou non) et transitions



4) Description interne

4.1) Interaction avec l'environnement● composants logiciels nécessaires aux fonctions en 3.1

(ex. base de données existante)

4.2) Contraintes● contraintes de réalisation (ex. encombrement mémoire)● contraintes de qualité (ex. précision du calcul)● performances● critères de vérification des contraintes● priorités



5) 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 recette

● constitution des lots● tests de recette● dates issues de la planification


Qualités du dossier d'analyse (1)Qualités du dossier d'analyse (1)

● Précis– formulation non ambiguë

● Cohérent– pas de contradictions



● Complet– pas d'oublis

● couverture de tous les besoins (→ cahier des charges)● description exhaustive des fonctionnalités

● Argumenté– liaison claire (références) avec

● des besoins exprimés dans le cahier des charges● (des objectifs exprimés dans la spécification d'objectifs)

☛ critère de traçabilité (→)



● 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?


Forme du dossier d'analyseForme du dossier d'analyse

● Séparation des concepts

= 1 concept par paragraphe

● Numérotation des paragraphes et/ou sections

→ facilité de référence

→ traçabilité (dans les phases ultérieures)




→ Techniques et outils de spécification

– modèles, représentations, ...● Interface utilisateur




Modèle conceptuelModèle conceptuel

● Donne une image « mentale » du produit (!)● Recense les fonctionnalités attendues

● Point de départ à :– l'analyse des besoins– l'interface utilisateur

☛ ExtrêmeExtrême importance


Modèle conceptuelModèle conceptuel

● Élaboré à partir des interviews d'utilisateurs● Dé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


Exercice :Exercice :Définir un modèle conceptuelDéfinir un modèle conceptuel

● Messagerie 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épertoire

● Quels sont les objets et les relations (notamment de possession) entre objets ?


Objets et relations dans une Objets et relations dans une messagerie textuelle téléphoniquemessagerie textuelle téléphonique

● Objets– boîte de réception– message (2 types : reçu, en cours de rédaction)– répertoire– contact

● Relations– 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


Modèle conceptuel de la messagerieModèle conceptuel de la messagerieExercice : remplir le tableauExercice : remplir le tableau

Grand type defonction du

produitObjet (et attributs) Liste des opérations

Exemple decontrainteséventuelles

gestion de laboîte de réception

gestion d'unmessage reçu

création d'unnouveaumessage

gestion durépertoire

gestion d'uncontact


Exemple de modèle conceptuelExemple de modèle conceptuelde la messageriede la messagerie

Grand type defonction du

produitObjet (et attributs) Liste des opérations

Exemples decontrainteséventuelles

gestion de laboîte de réception

boîte de réception(liste de messages

reçus)

consulter la liste,sélectionner un msg

nombre maximumde messages

gestion d'unmessage reçu

message reçu (suitede caractères non

modifiable)

lire, faire suivre,répondre, supprimer

création d'unnouveaumessage

message en cours(suite de caractères) éditer, envoyer, annuler taille maximum

d'un message

gestion durépertoire

répertoire(liste de contacts)

consulter la liste,ajouter un contact,

sélectionner un contact

nombre maximumde contacts

gestion d'uncontact

contact(nom, numéro) modifier, supprimer taille maximum du

nom, du numéro


Choix dans le modèle conceptuelChoix dans le modèle conceptuel

● Ajout 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


Importance du modèle conceptuelImportance du modèle conceptuel

● Il structure– identification de concepts, objets, attributs, opérations

et de leur articulation● Il fonde l'intuition

– image mentale : analogie avec des concepts, objets, attributs et opérations connus

– apprentissage réduit● Il facilite l'interaction

– efficacité, productivité


Importance du modèle conceptuelImportance du modèle conceptuel

● Impact sur tout les acteurs – utilisateur– développeur (projet complexe)– décideur


Différents types deDifférents types demodèles conceptuelsmodèles conceptuels

● Modèle de simulation– lien avec un existant concret

● Modèle structurel– abstraction

→ On va en donner des exemples


Modè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 contenant● des cellules (caractères ou blancs) [regroupées en lignes]

● un curseur (là où le prochain caractère s'imprime)

– actions● surimpression d'un caractère où se trouve le curseur

→ écrire, effacer (blancs), copier des caractères [sur une ligne]

(d'après P. Baudelaire)


Modè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 logique● insérer, détruire, remplacer, déplacer, copier

● pas de limitation à des opérations sur une seule ligne

● spécification et enregistrement de règles de formatage

→ changer le style sans changer le contenu

(d'après P. Baudelaire)


Comparaison des différents types Comparaison des différents types de modèles conceptuelsde modèles conceptuels

● Modèle de simulation– avantage : intuition facile– inconvénient : peut être limitatif

● Modèle structurel– avantage : plus général, plus puissant– inconvénient : peut demander un plus grand travail

de conceptualisation


Dictionnaire de donnéesDictionnaire de données

● Souvent amorcé par le modèle conceptuel● Constitué 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éveloppement

● variables, fonctions, classes, ...


Modèle conceptuel etModèle conceptuel etbesoins de spécificationbesoins de spécification

● Descriptions 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


Table de décisionTable de décision

● Définition des valeurs de sorties en fonctions des valeurs d'entrée et de leurs combinaisons

● Adapté aux systèmes dont les sorties ne dépendent que des entrées (et pas de l'état courant)


Exemple :Exemple :« date et heure » de MAC OS X« date et heure » de MAC OS X


Table de décision : ExempleTable de décision : Exemple« date et heure » de MAC OS X« date et heure » de MAC OS X

Affichage 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, optionnel

Afficher le jour de la semaine Affichage :numérique

Affichage :analogique

Afficher dans : barre desmenus

optionnel non

Afficher dans : fenêtre oui non



Affichage 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, optionnel

Afficher l'heure avec les secondes Affichage :numérique

Affichage :analogique

Afficher dans : barre des menus optionnel non

Afficher dans : fenêtre non optionnel


QuestionQuestion

Quelle structure de table– s'il y a plusieurs paramètres de sortie ?


Réponses possiblesRéponses possibles

Quelle 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 (→)



Affichage 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, optionnel

Afficher le jouret/ou les secondes

Affichage : numérique Affichage : analogique

Afficher dans : barre des menus

jour optionnelsecondes optionnelles

jour absentsecondes absentes

Afficher dans : fenêtre

jour présentsecondes absentes

jour absentsecondes optionnelles


QuestionQuestion

Quelle structure de table– s'il y a plus de deux paramètres d'entrée ?


Réponse possibleRéponse possible

Quelle 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


Table 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 lignes

A B C (A ∧ B) ∨ C

V V V V

V V F V

V F V V

V F F F

F V V V

F V F F

F F V V

F F F F


Table 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éhension

N.B. pas de titre pour les lignes

A B C A ∧ B (A ∧ B) ∨ C

V V V V V

V V F V V

V F V F V

V F F F F

F V V F V

F V F F F

F F V F V

F F F F F


QuestionQuestion

Quelle structure de table– s'il y a plusieurs paramètres d'entrée

et plusieurs paramètres de sortie ?


Réponse possibleRéponse possible

Quelle 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



● Deux paramètres d'entrée :– « afficher dans », « affichage »

● Deux paramètres de sortie :– jour de la semaine, heure avec les secondes

Afficher dans Affichage Jour de lasemaine Secondes

barre des menus numérique optionnel optionnel

barre des menus analogique non non

fenêtre numérique oui non

fenêtre analogique non optionnel


Capacité de représentation d'une Capacité de représentation d'une table de décisiontable de décision

● Exprimer une fonction

= sorties définies en fonction des entrées

● Exprimer une relation

= quelles combinaisons d'entrées et de sorties sont acceptables

– peu courant● non-déterminisme● confusions / oublis possibles


Table 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ées

● Limites : 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 ?


Table 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


Table de transitionTable de transition

● Automate modélisant la dynamique du système

● Adapté 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


Table de transition : ExempleTable de transition : Exempleautorisation d'accès par loginautorisation d'accès par login

● 2 états :– logué, délogué

● 4 opérations :– se loguer, se déloguer, lire, écrire

État Opérations autorisées État résultant

délogué se loguer logué

logué lire, écrire logué

logué se déloguer délogué


QuestionQuestion

Structures de table :– Quels cas sont bien traités ?– Quels cas ne sont pas bien traités ?


Tables (de décision, de transition) etTables (de décision, de transition) etbesoins de spécificationbesoins de spécification

● Bien adaptées tant que le problème est petit● Ne 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 ?


Représentations graphiquesReprésentations graphiques

● Pouvoir d'expression :– représentation des données et des traitements

● Caractéristiques :– plus synthétiques que les tables– sans nécessairement perte de précision



Pas 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 »


Intérêt desIntérêt desreprésentations graphiquesreprésentations graphiques

● Renforcement 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)



● Modèle entité-association● Diagramme de flot de données● Diagramme états-transitions● Réseau de Petri● ...


Modèle entité-associationModèle entité-association

● Date 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é)



● Une entité est– un objet que l'on sait distinguer d'un autre– ex. : livre dans une bibliothèque

● Chaque 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, ...



● Les 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 entreprise

● Une 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



● Une 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 banque● La cardinalité d'une relation est

– le nombre de liens (minimum, maximum) pour un ensemble d'entités


Modèle entité-association :Modèle entité-association :Notations graphiquesNotations graphiques

● Entités représentées par des rectangles● Attributs attachés aux entités : liste d'attributs● Identifiant de l'entité : item souligné dans la liste● Relations : ovales● Cardinalités : (x,y) c.-à-d. entre x et y

adhérent cassetteemprunterest empruntée

(0,1)emprunte

(0,n)

N°exemplairedate d'achatnb empruntsétat


Modèle entité-associationModèle entité-associationExemple : vidéothèqueExemple : vidéothèque

date

adhérent cassette

film

prix

emprunterest empruntée

(0,1)emprunte

(0,n)

fournisseur

reproduire

carte

posséder est possédée (1,1)

possède (1,1)

réserver

réserve(0,n)

numéronomcautionnb films

numéro

ref fournisseurnom fournisseuradresse fournisseurtéléphone fournisseurresponsable commercial

reproduit (1,1)

est reproduit par (0,n)

code filmtitreréalisateuracteursgenrerésumé

fournir

est fourni (1,n)

fournit(1,n)

est réservé (0,n)

N°exemplairedate d'achatnb empruntsétat


Modèle entité-association etModèle entité-association etbesoins de spécificationbesoins de spécification

● Relations ↔ états statiques possibles

● Ne rend pas compte de la dynamique– des traitements– du flux d'information

→ Diagrammes de flot de données


Diagramme de flot de donnéesDiagramme de flot de données

● Modélise– les gisements d'information– le transit des données– les traitements

● Exprime– 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)


Diagramme de flot de donnéesDiagramme de flot de donnéesExemple : gestion des empruntsExemple : gestion des emprunts

demanded'emprunt

cartevérificationcassette

vérificationclient

enregistrementemprunt

stock decassettes

comptesclients

N°cassette

cassette

carte modifiée

référence film

infos film

N°carte

N°client

refus

refus



Affinements successifs :– zoom sur une boîte– numérotation arborescente (ex. : A.D.3)– veiller à la cohérence des entrées et sorties



Conseils :– 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

(↑)


Diagrammes de flot de données etDiagrammes de flot de données etbesoins de spécificationbesoins de spécification

● Ne 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


Diagramme états-transitionsDiagramme états-transitions

Graphe :– nœud = état– arête = transition, étiquetée par

● les événements qui provoquent la transition● ou les événements provoqués par la transition

Représentation ordinaire des automates finis


Diagramme états-transitions :Diagramme états-transitions :Ex. Cassette dans une vidéothèqueEx. Cassette dans une vidéothèque

Cassette commandée

Cassette disponible

Cassette empruntée

Cassette perdue

Livraison de la cassette etenregistrement de l'entrée de la cassette

Emprunt de la cassette etenregistrement de l'emprunt

Demande d'emprunt etréponse N° de cassette

Retour cassette etenregistrement du retour

Temps d'emprunt dépassé etenregistrement de la perte de la cassette

Demande d'empruntet réponse de refus


Diagrammes états-transitionsDiagrammes états-transitions

● Rendent compte de :– la dynamique des traitements– l'enchaînement des traitements dans le temps

● Exemples d'application– comportement d'un objet réactif– enchaînements d'écrans avec IHM complexes


Comparaison : Table de transition etComparaison : Table de transition etDiagramme états-transitions Diagramme états-transitions

délogué

logué

se loguer se déloguer

lire, écrire

État Opérations autorisées État résultant

délogué se loguer logué

logué lire, écrire logué

logué se déloguer délogué


Non-déterminisme (1)Non-déterminisme (1)

● Plusieurs transitions avec la même étiquette, partant d'un même état

● Transition : sans événement attaché

Ex. transitions de l'état 1 à l'état 2 = {acd, a, b, f, aef}

1

2

a

c

d

b e

a

f


Non-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 ☺)


Diagramme états-transitions etDiagramme états-transitions etbesoins de spécificationbesoins de spécification

● Ne permettent pas d'exprimer la « concurrence » (= parallélisme)

→ Réseaux de Petri


Réseau de PetriRéseau de Petri

● Graphe biparti– sommets répartis en 2 groupes

– chaque arête a une extrémitédans un groupe et une extrémitédans l'autre groupe

● Sommets (nœuds)– place → état

● marques (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



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

•

•

••• •

•


Réseau de Petri : ExempleRéseau de Petri : ExempleDélivrance d'une cassetteDélivrance d'une cassette

• P1

P3P2

P7P6P5P4

P8

T1

T2 T3 T4 T5

T6

P1 : 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



● Ordonnancement des activités● Modélisation

– systèmes parallèles à événements discrets– concurrence, coopération– ex. exclusion mutuelle, producteur/consommateur

● Extensions– marques colorées, arcs inhibiteurs, limites de taille,

transitions sources, transitions puits, ...● Variante (dual) : Grafcet


Méthodes semi-formellesMéthodes semi-formelles

● Répandues dans l'industrie● Nombreux outils qui les implémentent● Inconvénient : manque (parfois) de rigueur

mathématique

→ Méthodes formelles


Méthodes d'analyse formelles :Méthodes d'analyse formelles :CaractéristiquesCaractéristiques

● Spécifications formelles = objets mathématiques

→ modélisations analysables par les mathématiques

● Nécessité d'une analyse profonde du problème

→ meilleure maîtrise

● Preuves formelles (mathématiques)

→ certaines propriétés garanties (sûreté, sécurité, ...)

ex. correction : programme conforme à sa spécification


Méthodes d'analyse formelles :Méthodes d'analyse formelles :Capacités automatiquesCapacités automatiques

● Aide 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 tests

● Animation d'une spécification

~ génération de prototype


Méthodes d'analyse formelles :Méthodes d'analyse formelles :Problèmes objectifsProblèmes objectifs

● Certains problèmes difficilement spécifiables– interface homme-machine, système temps-réel, ...

● Manque de formation– ingénieurs logiciel ≠ mathématiciens, logiciens

● Efforts plus sur les notations que sur les outils– preuves faisables mais difficiles à réaliser en pratique


Méthodes d'analyse formelles :Méthodes d'analyse formelles :CroyancesCroyances

● Croyances (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


Méthodes d'analyse formelles :Méthodes d'analyse formelles :Quelques formalismesQuelques formalismes

● Spé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, ...


Méthodes d'analyse formelles :Méthodes d'analyse formelles :La situation aujourd'huiLa situation aujourd'hui

● Peu répandues– utilisées pour des systèmes critiques (sécurité)

● Mais représentent l'avenir de la spécification– mais avenir lointain

● Besoin d'outils– plus simples (moins d'expertise nécessaire)– plus puissants (moins de choses à expliciter)


Et aussi...Et aussi...

● Critères Communs (CC)– sécurité

● ...


Récapitulatif desRécapitulatif desTechniques et outils de spécificationTechniques et outils de spécification● Modèle conceptuel● Représentations tabulaires :

– table de décision– table de transition

● Représentations graphiques semi-formelles :

– modèle entité-association– diagramme de flot de données– diagramme états-transitions– réseau de Petri, ...

● Méthodes formelles





→ Interface utilisateur




Interface utilisateurInterface utilisateur

● Souvent 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) ]


Spécification deSpécification del'interface utilisateur l'interface utilisateur

● Tôt dans le cycle de vie– spécifications fonctionnelles

● Nombreuses discussions avec l'utilisateur/client– maquette pour valider l'interface

(~ seul moyen efficace d'une discussion profitable)


Interface utilisateur : MéthodologieInterface utilisateur : Méthodologie

● Partir du modèle conceptuel des données et traitements

● Définir un modèle conceptuel du dialogue– représentation de l'information– interactions

☛ Choix crucial d'un bon modèle conceptuel


Interface utilisateur : Ergonomie (1)Interface utilisateur : Ergonomie (1)

● Convivialité– facilité d'utilisation– mesure : ex. nombre de jours d'apprentissage

● Efficacité– productivité des utilisateurs (→ mesure)

– caractériser les types d'utilisateurs ciblés● compétence● but du travail● performances attendues, ...


Interface 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'autre

● Standardisation– marché, influence du système d'exploitation/fenêtrage– normes de l'entreprise– conventions liées au domaine


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


Interface utilisateur : Outils (2)Interface utilisateur : Outils (2)

● Utilisation de bibliothèques standards– X Athena Widget– Motif– Tk– Swing– GTK, GTK+– OpenGL– ...





● Interface utilisateur– méthodologie, ergonomie, ...

→ Maquettage et prototypage

– objectifs, nature, intérêt, ...


Maquettage et prototypageMaquettage et prototypage

● Quand :– après le premier jet des spécifications fonctionnelles

● Objectifs :– montrer au client à quoi ressemblera le produit– valider les besoins et les spécifications


MaquetteMaquette

● Système incomplet dont l'aspect extérieur est +/- le même que le produit à réaliser

● Destiné à tester l'ergonomie du produit● Instaure un dialogue développeur-utilisateur● Ne permet pas le test de performance● Souvent jetable


PrototypePrototype

● Esquisser 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)


PrototypePrototype

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


PrototypePrototype

Ignorer 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 !)


PrototypePrototype

Choix d'un langage de prototypage adapté– impératif : perl, shell, java, ...– fonctionnel : ML, lisp, scheme, ...– déclaratif : prolog, ...– spécifique à un domaine

● ex. programmation réactive : ESTEREL, SIGNAL, LUSTRE● ex. modélisation de processus : SIMULA, QNAP2


Prototyper n'est pas spécifierPrototyper n'est pas spécifier

Un 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)


Du prototype à l'implémentationDu prototype à l'implémentation

Ré-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'utilisateur

Mais– réutilisation possible de certains composants du

prototype– réimplémentation plus rapide grâce à une bonne

connaissance du problème


À retenirÀ retenir

● Qualités du dossier d'analyse– précis, cohérent, complet, argumenté, traçable, flexible

● Extrême importance du modèle conceptuel– image mentale : concepts, objets, attributs, opérations

● Représentations graphiques semi-formelles– synthétiques, normalisées, non ambiguës– des diagrammes différents pour des usages différents

● Ne pas oublier :– aspects non fonctionnels

Documents

Analyse des Besoins (Spécifications) - IMAGINEimagine.enpc.fr/~marletr/LaBRI/teaching/GenLog/slides/GenLog... · Génie logiciel – Définition des ... Position dans le cycle de