Analyse des Besoins (Spécifications)

Transcription

Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet
1
Génie Logiciel
(d'après A.-M. Hugues)
Analyse des Besoins
(Spécifications)
Renaud Marlet
LaBRI / INRIA
http://www.labri.fr/~marlet
màj 17/04/2007
Analyse des besoins :
Position 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
2
Objectifs 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
3
4
Plan du cours
●
Dossier d'analyse
–
●
Techniques et outils de spécification
–
●
modèles, représentations, ...
Interface utilisateur
–
●
contenu, importance, qualité, ...
méthodologie, ergonomie, ...
Maquettage et prototypage
–
nature, intérêt, ...
5
Plan du cours
→ Dossier d'analyse
–
●
–
●
–
●
–
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 »
6
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)
7
8
Cycle de vie :
modèle en V (rappel)
(Expression
des besoins)
(Validation
des besoins)
Spécifications
Qualification
Conception
globale
Tests
d'intégration
Conception
détaillée
Programmation
Tests
unitaires
Importance 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)
9
Dossier d'analyse : fait par qui ?
●
Généralement réalisé par
–
●
Parfois réalisé par le client
–
●
des membres de l'unité de développement
attente d'un produit précis
Parfois donné par une norme
–
protocole, format d'échange, ...
☛ exercice : citez des exemples
10
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
11
Plan 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
12
2) Concepts et terminologie
–
glossaire de l'application
☛ Peut être en annexe, ou bien un document
autonome utilisé et partagé dans tout le projet
13
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é
14
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
15
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
16
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
17
Qualités du dossier d'analyse (1)
●
Précis
–
●
formulation non ambiguë
Cohérent
–
pas de contradictions
18
●
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é (→)
19
●
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?
20
Forme 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)
21
22
Plan du cours
●
Dossier d'analyse
–
→ Techniques et outils de spécification
–
●
–
●
–
Modè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ême importance
23
Modè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
24
Exercice :
Dé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 ?
25
Objets et relations dans une
messagerie 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
26
Modèle conceptuel de la messagerie
Exercice : remplir le tableau
Grand type de
fonction du
produit
gestion de la
gestion d'un
message reçu
création d'un
nouveau
message
gestion du
répertoire
gestion d'un
contact
Objet (et attributs)
Liste des opérations
Exemple de
contraintes
éventuelles
27
Exemple de modèle conceptuel
de la messagerie
Grand type de
fonction du
produit
Objet (et attributs)
Liste des opérations
Exemples de
contraintes
éventuelles
gestion de la
(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, annuler
taille 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, supprimer
taille maximum du
nom, du numéro
28
Choix 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
29
Importance 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é
30
Importance du modèle conceptuel
●
Impact sur tout les acteurs
–
utilisateur
–
développeur (projet complexe)
–
décideur
31
Différents types de
modèles conceptuels
●
Modèle de simulation
–
●
lien avec un existant concret
Modèle structurel
–
abstraction
→ On va en donner des exemples
32
Modèle conceptuel de simulation
Exemple : traitement de texte
33
(d'après P. Baudelaire)
☛ 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]
Modèle conceptuel structurel
Exemple : traitement de texte
34
(d'après P. Baudelaire)
☛ 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
Comparaison des différents types
de 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
35
36
Dictionnaire 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 et
besoins 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
37
Table 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)
38
Exemple :
« date et heure » de MAC OS X
39
Table de décision : Exemple
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
Afficher dans : barre des
menus
Afficher dans : fenêtre
Affichage :
numérique
Affichage :
analogique
optionnel
non
oui
non
40
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
Afficher dans : barre des menus
Afficher dans : fenêtre
Affichage :
numérique
Affichage :
analogique
optionnel
non
non
optionnel
41
42
Question
Quelle structure de table
–
s'il y a plusieurs paramètres de sortie ?
43
Réponses possibles
–
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 jour
et/ou les secondes
Afficher dans :
barre des menus
Afficher dans :
fenêtre
Affichage : numérique
Affichage : analogique
jour optionnel
secondes optionnelles
jour absent
secondes absentes
jour présent
secondes absentes
jour absent
secondes optionnelles
44
45
Question
–
s'il y a plus de deux paramètres d'entrée ?
Réponse possible
–
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
46
47
Table de décision : Exemple (1)
●
3 paramètres d'entrée (booléens)
●
1 paramètre de sortie (booléen)
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
N.B. pas de titre pour les lignes
48
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
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
N.B. pas de titre pour les lignes
49
Question
–
s'il y a plusieurs paramètres d'entrée
et plusieurs paramètres de sortie ?
Réponse possible
–
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ée
et de paramètres de sortie
–
et toutes les combinaisons possibles
50
●
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 la
semaine
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
51
Capacité de représentation d'une
table 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
52
Table de décision et
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 ?
53
Table de décision et
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
54
55
Table 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 : Exemple
autorisation 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é
56
57
Question
Structures de table :
–
Quels cas sont bien traités ?
–
Quels cas ne sont pas bien traités ?
Tables (de décision, de transition) et
●
●
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 ?
58
Repré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
59
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 »
60
Intérêt des
repré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)
61
●
Modèle entité-association
●
Diagramme de flot de données
●
Diagramme états-transitions
●
Réseau de Petri
●
...
62
●
●
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é)
63
●
●
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, ...
64
65
●
●
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
66
Modèle entité-association :
Notations 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
emprunte
(0,n)
adhérent
emprunter
est empruntée
(0,1)
cassette
N°exemplaire
date d'achat
nb emprunts
état
67
68
Exemple : vidéothèque
N°exemplaire
date d'achat
nb emprunts
état
date
emprunte
(0,n)
adhérent
numéro
nom
caution
nb films
possède
(1,1)
emprunter
cassette
réserve
(0,n)
posséder
reproduit
(1,1)
réserver
est possédée
(1,1)
carte
est empruntée
(0,1)
reproduire
est réservé
(0,n)
est reproduit par
(0,n)
fournisseur
numéro
ref fournisseur
nom fournisseur
adresse fournisseur
téléphone fournisseur
responsable commercial
fournit
(1,n)
film
est fourni
(1,n)
fournir
prix
code film
titre
réalisateur
acteurs
genre
résumé
Modèle entité-association et
●
Relations ↔ états statiques possibles
●
Ne rend pas compte de la dynamique
–
des traitements
–
du flux d'information
→ Diagrammes de flot de données
69
●
●
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)
70
Exemple : gestion des emprunts
refus
carte
infos film
demande
d'emprunt
N°carte
vérification
client
référence film
stock de
cassettes
N°client
refus
comptes
clients
vérification
cassette
N°cassette
enregistrement
emprunt
carte modifiée
cassette
71
Affinements successifs :
–
zoom sur une boîte
–
numérotation arborescente (ex. : A.D.3)
–
veiller à la cohérence des entrées et sorties
72
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
(↑)
73
Diagrammes de flot de données et
●
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
74
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
75
Diagramme états-transitions :
Ex. Cassette dans une vidéothèque
76
Cassette commandée
Livraison de la cassette et
enregistrement de l'entrée de la cassette
Demande d'emprunt et
réponse N° de cassette
Cassette disponible
Emprunt de la cassette et
enregistrement de l'emprunt
Demande d'emprunt
et réponse de refus
Cassette empruntée
Retour cassette et
enregistrement du retour
Temps d'emprunt dépassé et
enregistrement de la perte de la cassette
Cassette perdue
Diagrammes é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
77
Comparaison : Table de transition et
État
Opérations autorisées
État résultant
délogué
se loguer
logué
logué
lire, écrire
logué
logué
se déloguer
délogué
délogué
se loguer
lire, écrire
logué
se déloguer
78
79
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}
a
c
b

d
a
1
2

f
e
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 exponentiellement
plus grand)
Automate non déterministe
–
moins lisible (suivre des transitions en parallèle)
–
plus compact (donc plus lisible ☺)
80
Diagramme états-transitions et
●
Ne permettent pas d'exprimer la « concurrence »
(= parallélisme)
→ Réseaux de Petri
81
82
Ré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
●
–
place entrée
(pré-condition)
marques (jetons) dans certaines
places, à un instant donné
transition → changement d'état
•
••
place entrée
(pré-condition)
transition
place sortie
(post-condition)
83
Réseau de Petri
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 : Exemple
Délivrance d'une cassette
•
P1
P1 : emprunt demandé
P2 : vérification de la cassette
P3 : vérification de l'adhérent
P4 : emprunt refusé
P5 : emprunt possible
P6 : emprunt possible
P7 : emprunt refusé
P8 : emprunt autorisé
T1
P2
T2
P4
P3
T3
T4
P5
P6
T6
T5
P7
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)
P8
emprunt autorisé si cassette disponible et adhérent en règle
84
Réseau de Petri
●
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
85
Mé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
86
Méthodes d'analyse formelles :
Caracté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
87
Capacité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
88
Problèmes objectifs
●
Certains problèmes difficilement spécifiables
–
●
Manque de formation
–
●
interface homme-machine, système temps-réel, ...
ingénieurs logiciel ≠ mathématiciens, logiciens
Efforts plus sur les notations que sur les outils
–
preuves faisables mais difficiles à réaliser en pratique
89
Croyances
●
●
●
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
90
Quelques 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, ...
91
La situation aujourd'hui
●
Peu répandues
–
●
Mais représentent l'avenir de la spécification
–
●
utilisées pour des systèmes critiques (sécurité)
mais avenir lointain
Besoin d'outils
–
plus simples (moins d'expertise nécessaire)
–
plus puissants (moins de choses à expliciter)
92
93
Et aussi...
●
Critères Communs (CC)
–
●
...
sécurité
Récapitulatif des
●
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
94
95
Plan du cours
●
Dossier d'analyse
–
●
–
→ Interface 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) ]
96
Spécification de
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)
97
Interface 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
98
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, ...
99
100
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)
●
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
–
...
101
Interface utilisateur : Outils (2)
●
Utilisation de bibliothèques standards
–
X Athena Widget
–
Motif
–
Tk
–
Swing
–
GTK, GTK+
–
OpenGL
–
...
102
103
Plan du cours
●
Dossier d'analyse
–
●
–
●
–
→ Maquettage et prototypage
–
objectifs, nature, intérêt, ...
●
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
104
105
Maquette
●
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
106
Prototype
●
●
Esquisser ce que sera le produit final
–
les fonctionnalités
–
sans contraintes (fiabilité, ...)
Valider les besoins utilisateur
–
●
Valider les spécifications
–
●
réalisables ?
complètes, réalistes, non contradictoires ?
Souvent jetable (sinon = prototype évolutif)
107
Prototype
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
108
Prototype
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 !)
109
Prototype
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é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)
110
Du 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
111
112
À retenir
●
Qualités du dossier d'analyse
–
●
Extrême importance du modèle conceptuel
–
●
●
précis, cohérent, complet, argumenté, traçable, flexible
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

Analyse des Besoins (Spécifications)

Transcription

Documents pareils

Soirée Comm Animale

Définition des Besoins

Monsieur Claude RENAUD

Antoine Chance « Fou » Lana Del Rey « Ultraviolence » Sia « 1000

CONCERT : RENAUD - le 2 décembre 2016

Institut Supérieur Aquitain du Bâtiment et des Travaux Publics

toupie-tenonneuse sicm-chambon

Programme-RENAUD