IUT de Vélizy Université de Versailles St-Quentin en Yvelines De l'analyse des besoins à la...

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


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


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


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


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


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


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-

IUT de Vélizy Université de Versailles St-Quentin en Yvelines De l'analyse des besoins à la...

Documents

Transcript of IUT de Vélizy Université de Versailles St-Quentin en Yvelines De l'analyse des besoins à la...