iut de vélizy université de versailles st-quentin en yvelines de l'analyse des besoins à la...
TRANSCRIPT
IUT de Vélizy
Université de Versailles St-Quentin en Yvelines
De l'analyse des besoins à la spécification formelle en B :
un cours en première année d'IUT
Nicole Levy
Journée B
L'enseignement de B et des méthodes formelles
Nantes
Vendredi 29 Novembre 2002
Nicole Levy 2
1. Objectifs
Donner une vision globale du développement d’un logiciel basée sur le cycle en V
Conception Architecturale
Conception Détaillée
Programmation
Test d’Intégration
Tests Unitaires
Test SystèmeSpécification
Test d’acceptationAnalyse des besoins
Nicole Levy 3
1. Objectifs
Cours de Génie Logiciel
en première année d’IUT… et même premier semestre !
Public jeune … et globalement pas très bon
Manque de connaissances en théorie des ensembles et en logique
Nicole Levy 4
2. Approche proposée
Analyse des besoins En dériver des tests d’acceptationEn 7 semaines 1 cours et 1 TD de 2h
Spécification en B Jusqu’à l’implémentation En dériver des tests systèmeEn 7 semaines 1 cours,1 TD de 1h1/4 et 1 TP
de 2h
Nicole Levy 5
Analyse des besoins
Approche inspirée des travaux de J. Souquières et M. Heisel
Introduisant quelques diagrammes UML(mais ils ne connaissent pas encore les langages orientés objets)
Nicole Levy 6
Étapes d’analyse
1ère étape Analyse des interactions
Logiciel Environnement 2ème étape
Définition des propriétés invariantes 3ème étape
Étude de quelques comportements 4ème étape
Définition du comportement
Nicole Levy 7
Étapes d’analyse
Complete
System
Description
Interaction
Analysis
Desired
Behavior
Analysis
Invariant
Properties
AnalysisFact
Hypothesis
Needs
* F1: The vending machine * F2: The vending machine * F3: The vending machine
UML Use Case
UML statecharts
init
R10
R3
waiting
payment
R3/R7/R9
failure
R1
R4/R5/R6/R8
R10
R2/R7/R9
waiting client
UML sequence
diagrams
waiting
ClientcaptorsMACHINE
select
waiting
waiting
payment
available
pay
deliver
payment
=
price
UML sequence
diagrams
waiting
Client captorsMACHINE
select
waiting
waiting
payment
available
pay
deliver
payment
=
price
Nicole Levy 8
Example: un distributeur de boissons
Le distributeur à analyser pourra servir 4 boissons différentes et à des prix différents. Parmi ces boissons, il y a du café pour lequel l’utilisateur pourra indiquer qu’il désire plus de sucre ou au contraire n’en désire pas du tout. L’utilisateur devra dans un premier temps choisir sa boisson puis la payer à l’aide de pièces de 0.2, 0.5 et 1 euro. Si l’argent fourni est suffisant, si le distributeur possède de quoi rendre la monnaie ainsi que (possède) la boisson demandée, alors il rendra la monnaie, préparera la boisson et la délivrera (la boisson). Dans les autres cas, il rendra l’argent à l’utilisateur.
Nicole Levy 9
Lecture du cahier des charges un distributeur de boissons...
Le distributeur à analyser pourra servir 4 boissons différentes et à des prix différents. Parmi ces boissons, il y a du café pour lequel l’utilisateur pourra indiquer qu’il désire plus de sucre ou au contraire n’en désire pas du tout.L’utilisateur devra dans un premier temps choisir sa boisson puis la payer à l’aide de pièces de 0.2, 0.5 et 1 euro. Si l’argent fourni est suffisant, si le distributeur possède de quoi rendre la monnaie ainsi que (possède) la boisson demandée, alors il rendra la monnaie, préparera la boisson et la délivrera (la boisson). Dans les autres cas, il rendra l’argent à l’utilisateur.
Nicole Levy 10
1ère étape: Analyse des Interactions Identifier les acteurs et les actions
Acteurs : ils interagissent avec le système, ils déclenchent les actions
Actions: elles modifient l’état du système :
Associer à chaque acteur : les actions qu'il pourra effectuer au logiciel : les actions qu'il effectuera en retour
Diagrammes Use-Case
Introducem oney
Choose a drink
User Vending M achine
Nicole Levy 11
1ère étape: Analyse des Interactions un distributeur de boissons...
Utilisateur indiquer qu’il désire plus ou pas de sucre,choisir une boisson,payer une boisson
Distributeurposséder de la monnaie, posséder la boisson demandée, rendre de la monnaie,préparer une boisson, délivrer une boisson, rendre l’argent
Rendre la monnaie Délivrer la boisson
Choisir une boissonIndiquer sucrePayer
LOGICIELdistributeur
Utilisateur
Nicole Levy 12
2ème étape: analyse des propriétés invariantes
Comprendre ce qui est attendu du logiciel
Faits : propriétés statiques du domaine d'application comportement implicite du système:
ses états les préconditions sur les transitions physiques les préconditions évidentes les limites physiques
Nicole Levy 13
2ème étape: analyse des propriétés invariantes
Comprendre ce qui est attendu du logiciel
Hypothèses : concernant le comportement attendu de l'environnementpeuvent être remises en causes
Besoins : concernant le comportement attendu du logiciel :
propriétés temporelles propriétés structurelles
Nicole Levy 14
2ème étape: propriétés invariantes un distributeur de boissons...
Faits :1. le distributeur sert un utilisateur et une boisson à la fois 2. le distributeur peut rendre la monnaie 3. le prix des boissons peut être payé à l’aide des pièces acceptées par le distributeur
Nicole Levy 15
2ème étape: propriétés invariantes un distributeur de boissons...
Hypothèses :4. le distributeur n’accepte que les pièces de
0.2, 0.5 et 1 €5. le distributeur sert 6 boissons différentes dont 3 qui sont du café plus ou moins sucré6. le prix de chaque boisson est fixé7. l’utilisateur peut annuler sa commande … mais il faut définir jusqu’à quand
Nicole Levy 16
2ème étape: propriétés invariantes un distributeur de boissons...
Besoins :8. l’utilisateur choisit d’abord sa boisson (une parmi les 6) puis la paye.9. Si le distributeur accepte de servir une boisson
Alors il doit rendre la monnaie correctement10. Si le distributeur n’accepte pas de servir une boisson
Alors il doit rendre tout l’argent donné par l’utilisateur11. le distributeur accepte de servir une boisson ssi l’argent fourni est suffisant et la monnaie est disponible et la boisson est disponible et un gobelet est disponible
Nicole Levy 17
3ème étape: description de certains comportements particuliers
Diagrammes de séquence
Montre les objets de l’environnement et le logiciel et les messages qu’ils s’échangent Les messages sont classés par ordre chronologique. Un scénario représente une vue particulière du logiciel par un des acteurs.Un scénario est une suite d'actions se produisant à partir d'un état donné du système et provoquant éventuellement l'exécution d' opérations.
Nicole Levy 18
3ème étape: certains comportements un distributeur de boissons...
Utilisateur Distributeur
Choisit une boisson attente choixboisson disponiblegobelet disponible
Paye attente argentargent suffisantmonnaie disponibleprépare la boisson
Délivre la boisson
Rend la monnaieattente choix
Nicole Levy 19
4ème étape: Définition du comportementRéaction: comportement précis et complet
attendu du système pour chaque acteur pour chaque action qu'il peut déclencher pour tous les états possibles du système
Expression de chaque réaction selon un format standard:
Ri: Quand un acteur déclenche une action Si le logiciel est dans un état donné et Si une propriété est vérifiée Alors le logiciel change d'état
et exécute une opération et renvoie une réponse
Diagrammes d'états-transitions
Nicole Levy 20
4ème étape: réactions un distributeur de boissons...
1. Quand un utilisateur choisit une boisson (une parmi les 6)Si le distributeur est en attente de choix de boissonEt Si la boisson est disponibleAlors le distributeur attend que l’utilisateur paye
2. Quand un utilisateur choisit une boisson (une parmi les 6)Si le distributeur est en attente de choix de boissonEt Si la boisson n’est pas disponibleAlors le distributeur reste dans l’attente d’un choix de boissonEt envoie en réponse un message « boisson non disponible »
3. Quand un utilisateur choisit une boisson (une parmi les 6)Si le distributeur n’est pas en attente de choix de boissonAlors le distributeur ne change pas d’état : il ne se passe rien
4. Quand un utilisateur paye (on suppose une action unique)Si le distributeur est en attente de paiement Et Si l’argent donné est suffisant Et Si le distributeur a de quoi rendre la monnaieAlors le distributeur rend la monnaie, prépare la boisson et
la délivre et passe à l’état attente d’un choix de boisson
Nicole Levy 21
4ème étape: réactions un distributeur de boissons...
5. Quand un utilisateur paye (action unique )Si le distributeur est en attente de paiement Et Si l’argent donné n’est pas suffisant Ou Si le distributeur n’a pas de quoi rendre la monnaieAlors le distributeur rend l’argent et
passe à l’état attente d’un choix de boisson6. Quand un utilisateur paye
Si le distributeur n’est pas en attente de paiement Alors le distributeur rend l’argent et ne change pas d’état
7. Quand un utilisateur annule Si le distributeur est en attente de paiement Alors le distributeur passe à l’état attente d’un choix de
boisson8. Quand un utilisateur annule
Si le distributeur n’est pas en attente de paiement Alors le distributeur ne change pas d’état
Nicole Levy 22
4ème étape: réactions un distributeur de boissons...
On ajoute un état PANNE et une action de détection de panne :
9. Quand une panne est détectée Si le distributeur est en attente de choix de boisson
ou de paiement Alors le distributeur passe à l’état panneEt envoie en réponse un message « distributeur HS »
10. Quand une panne est détectée Si le distributeur est en déjà en panne Alors le distributeur ne change pas d’état : il ne se passe
rien
Nicole Levy 23
4ème étape: Comportement un distributeur de boissons...
Diagramme d'états-transitions
Att_boisson Att_paiement
Panne
R1
R2/R6/R8
R3
R3/R6/R8/R10
R4/R5
R9 R9
R7
Nicole Levy 24
Génération des tests d’acceptation
Sc Cas Testé
Acteur
État initial
Actions +
propriétés des données
Résultats attendus
Nouvel état
Résultats obtenus
1 Normal
Util Att_choix tqMonnaie et boisson dispo
Choisir boisson
dispo ;Payer tq suffisant (>)
Rendre monnaie ; Servir boisson
Att_choix
Nicole Levy 25
De l’analyse des besoins à la Spécification en B
Formaliser les besoins:
Des Faits, Hypothèses et besoins:La partie statique
Des réactions La partie dynamique
Nicole Levy 26
De l’analyse des besoins à B un distributeur de boissons...
Exemple:Faits :3. le prix des boissons peut être payé à l’aide des pièces acceptées par le distributeur variable pièces_acceptées de type P(NATURAL)
Hypothèses :4. le distributeur n’accepte que les pièces de
0.2, 0.5 et 1 € variable pièces_acceptées ={20,50,100}
Nicole Levy 27
De l’analyse des besoins à B un distributeur de boissons...
DISTRIBUTEUR_BOISSONSETS BOISSON ; ETAT = {att_boisson, att_paiement, panne} ; REPONSE = {boisson_non_disponible, veuillez_payer,
prenez_la_boisson, somme_versee_insuffisante}CONSTANTS cafe_sucre, cafe_non_sucre, cafe_plus_sucre, pas_de_choix, prix_boisson , /*Hyp6 */ piece_acceptees,/*Hyp4 */ boissons_serviesPROPERTIES cafe_sucre : BOISSON & cafe_non_sucre: BOISSON & cafe_plus_sucre: BOISSON & pas_de_choix : BOISSON & prix_boisson : NATURAL & piece_acceptees : POW (NATURAL) & boissons_servies : POW(BOISSON) & card(boissons_servies) = 6 & /*Hyp5 */...
Nicole Levy 28
De l’analyse des besoins à B un distributeur de boissons...
OPERATIONS
rep <-- Choisir_boisson (boi) =
PRE boi : BOISSON & boi /= pas_de_choix &
etat_courant = att_boisson THEN
IF boi : boissons_disponibles THEN /*réact 1*/
utilisateur := boi ||
etat_courant := att_paiement ||
rep := veuillez_payer
ELSE
rep := boisson_non_disponible/*réact 2*/
END
END;/*réact 3*/
Nicole Levy 29
Spécification en B
On ne peut pas tout voir… alors j’ai choisi de montrerComment modéliser:
ensembles, relations, fonctions et suitesComment raffiner:
très rapidement et sur des exemples très simplesPour arriver à la génération de code
Toujours une seule machine
Nicole Levy 30
ConclusionsPublic jeune et globalement pas très bonMais sans a priori et très réceptifUn choc dès leur arrivée:
des maths et la génération automatique de code !
Pour certains c’est très dur… pour d’autre au contraire pas du tout
Mais ils prennent tous des bonnes habitudes…
Nicole Levy 31
ConclusionsCe que j’espère qu’ils acquièrent (en vrac):
Réfléchir au comportement désiré avant de programmerLa notion de type et d’invariantLa notion de préconditionL’idée que savoir programmer n’est pas forcément leur unique objectif La vision d’un système comme un tout qu’il faut décomposerLa notion de raffinementPenser aux tests dès les premières étapes de développement
Nicole Levy 32
ConclusionsTP avec l’Atelier B:Contrôleur de Type: le plus utiliséProuveur: Preuves automatiques uniquement Mais ils doivent savoir lire les Obligations de PreuveL’animateur : inadéquat et manque cruellement
Un regret: pas de version gratuite qu’ils puissent télécharger chez eux
Et puis…. Des petits problèmes tels queSurchage du serveur TP à 2 par machineProblèmes de jetonsLes commentaires disparaissent lors du passage à Latex
Nicole Levy 33
Et après ? ….
En deuxième année:
Le projet tutoré et un suivi dans le module génie logicielL’analyse des besoins et les fiches de test
… pas de spécification B…
Mais UML
Nicole Levy 34
1èreétape: Analyse des Interactions un distributeur de boissons...
Analyse un plus approfondie des interactions
DISTRIBUTEUR
LOGICIELDistributeur
Utilisateur
choisir une boissonindiquer sucre, annuler
monnayeur Rendre la monnaieRendre l’argentDélivrer une boisson
payerpayer
capteur gobelet
capteur boisson
Rendre la monnaieRendre l’argentDélivrer une boisson
manque gobelet
manque boisson
Nicole Levy 35
Exemples d’exercices
Des distributeurs en tous genresUn réseau téléphoniqueL’organisation d’un séminaire…
Nicole Levy 36
Un projet à faire en 3 semaines
L’an dernier:Spécification d’un système distribué Un système de communication dans réseau complexe
Source_données
Cible_données
Nœud source Nœud cible
Agent récepteur
Canal de transmission
Canal-données
Agent émetteur
Figure-2-