analyse des besoins (spécifications) -...
TRANSCRIPT
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 2
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 3
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 4
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 Marlet 5
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 Marlet 6
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 »
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 7
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)
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 8
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)
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 9
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)
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 10
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 11
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 12
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 13
Plan type du dossier d'analysePlan type du dossier d'analyse
2) 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 Marlet 14
Plan type du dossier d'analysePlan type du dossier d'analyse
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é
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 15
Plan type du dossier d'analysePlan type du dossier d'analyse
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 16
Plan type du dossier d'analysePlan type du dossier d'analyse
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 17
Plan type du dossier d'analysePlan type du dossier d'analyse
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 18
Qualité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 Marlet 19
Qualités du dossier d'analyse (2)Qualités du dossier d'analyse (2)
● 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é (→)
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 20
Qualité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 Marlet 21
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)
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 22
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 Marlet 23
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 24
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 25
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 ?
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 26
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 27
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 28
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 29
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 30
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é
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 31
Importance du modèle conceptuelImportance du modèle conceptuel
● Impact sur tout les acteurs – utilisateur– développeur (projet complexe)– décideur
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 32
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 33
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)
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 34
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)
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 35
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 36
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, ...
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 37
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 38
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)
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 39
Exemple :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 Marlet 40
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 41
Table de décision : ExempleTable de décision : Exemple« date et heure » de MAC OS X« date et heure » de MAC OS X
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 42
QuestionQuestion
Quelle structure de table– s'il y a plusieurs paramètres de sortie ?
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 43
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 (→)
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 44
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 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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 45
QuestionQuestion
Quelle 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 Marlet 46
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 47
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 48
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 49
QuestionQuestion
Quelle 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 Marlet 50
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 51
Table de décision : ExempleTable de décision : Exemple« date et heure » de MAC OS X« date et heure » de MAC OS X
● 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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 52
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 53
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 ?
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 54
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 55
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 56
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é
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 57
QuestionQuestion
Structures 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 Marlet 58
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 ?
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 59
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 60
Représentations graphiquesReprésentations graphiques
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 »
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 61
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)
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 62
Représentations graphiquesReprésentations graphiques
● Modèle entité-association● Diagramme de flot de données● Diagramme états-transitions● Réseau de Petri● ...
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 63
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é)
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 64
Modèle entité-associationModèle entité-association
● 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, ...
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 65
Modèle entité-associationModèle entité-association
● 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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 66
Modèle entité-associationModèle entité-association
● 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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 67
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 68
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 69
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 70
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)
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 71
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 72
Diagramme de flot de donnéesDiagramme de flot de données
Affinements 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 Marlet 73
Diagramme de flot de donnéesDiagramme de flot de données
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
(↑)
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 74
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 75
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 76
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 77
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 78
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é
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 79
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 80
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 ☺)
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 81
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 82
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 83
Réseau de PetriRé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
•
•
••• •
•
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 84
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 85
Réseau de PetriRé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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 86
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 87
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 88
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 89
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 90
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 91
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, ...
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 92
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)
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 93
Et aussi...Et aussi...
● Critères Communs (CC)– sécurité
● ...
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 94
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 95
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 Marlet 96
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) ]
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 97
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)
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 98
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 99
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, ...
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 100
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 101
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– ...
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 102
Interface 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 Marlet 103
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
– objectifs, nature, intérêt, ...
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 104
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 105
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 106
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)
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 107
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 108
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 !)
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 109
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 110
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)
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 111
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
Génie logiciel – Définition des besoins © 2005-2007 Renaud Marlet 112
À 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