L'enseignement de B et des méthodes formelles 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

Conception Architecturale 1. Objectifs Donner une vision globale du développement d’un logiciel basée sur le cycle en V Analyse des besoins Conception Architecturale Conception Détaillée Programmation Test d’Intégration Tests Unitaires Test d’acceptation Spécification Test Système Nicole Levy

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

2. Approche proposée Analyse des besoins Spécification en B En dériver des tests d’acceptation En 7 semaines 1 cours et 1 TD de 2h Spécification en B Jusqu’à l’implémentation En dériver des tests système En 7 semaines 1 cours,1 TD de 1h1/4 et 1 TP de 2h Nicole Levy

J. Souquières et M. Heisel 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

É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

Étapes d’analyse Nicole Levy Interaction Analysis Invariant Properties Complete System Description Interaction Analysis Desired Behavior Invariant Properties Fact 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 R2/R7/R9 waiting client UML sequence diagrams Client captors MACHINE select available pay deliver = price Nicole Levy

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

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

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 Nicole Levy

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 Distributeur possé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 boisson Indiquer sucre Payer LOGICIEL distributeur Utilisateur Nicole Levy

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

2ème étape: analyse des propriétés invariantes Comprendre ce qui est attendu du logiciel Hypothèses : concernant le comportement attendu de l'environnement peuvent être remises en causes Besoins : concernant le comportement attendu du logiciel : propriétés temporelles propriétés structurelles Nicole Levy

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

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

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 correctement 10.  Si le distributeur n’accepte pas de servir une boisson Alors il doit rendre tout l’argent donné par l’utilisateur 11.  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

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

3ème étape: certains comportements un distributeur de boissons... Utilisateur Distributeur   Choisit une boisson attente choix boisson disponible gobelet disponible Paye attente argent argent suffisant monnaie disponible prépare la boisson Délivre la boisson Rend la monnaie attente choix Nicole Levy

4ème étape: Définition du comportement Ré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

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 boisson Et Si la boisson est disponible Alors le distributeur attend que l’utilisateur paye 2.      Quand un utilisateur choisit une boisson (une parmi les 6) Et Si la boisson n’est pas disponible Alors le distributeur reste dans l’attente d’un choix de boisson Et 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 boisson Alors 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 monnaie Alors 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

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 monnaie Alors le distributeur rend l’argent et passe à l’état attente d’un choix de boisson 6.      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 Alors le distributeur passe à l’état attente d’un choix de boisson 8.      Quand un utilisateur annule Alors le distributeur ne change pas d’état  Nicole Levy

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 panne Et 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

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 R7 Nicole Levy

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 tq Monnaie et boisson dispo Choisir boisson dispo ; Payer tq suffisant (>) Rendre monnaie ; Servir boisson Att_choix  Acteur État initial Actions + propriétés des données Résultats attendus Nouvel état Résultats obtenus 1 Normal Util Att_choix tq monnaie dispo et 1 Boiss Dispo  Choisir boisson tq dispo ; Payer tq suffisant (>) Rendre monnaie ; Servir boisson Att_choix   2 Paiement exact Payer tq suffisant (=) Servir boisson 3 Boisson non dispo Att_choix tq existe 1 Boiss non Dispo  Choisir boisson tq non dispo ; Message « Boisson non Disponible » 4 Pas de monnaie Att_choix tq monnaie non dispo et 1 Boiss Dispo  Payer tq suffisant (>) Rendre argent 5 Argent insuffisant Att_choix tq 1 Boiss Dispo  Payer tq insuffisant (<) 6 Annulation Annuler Message « annuler » 7 Att_argent 8 Panne Capteur de panne Att_choix ou Att_argent ou Panne Détecter panne Message « HS » Nicole Levy

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

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

De l’analyse des besoins à B un distributeur de boissons... DISTRIBUTEUR_BOISSON SETS 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_servies PROPERTIES 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

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

Spécification en B On ne peut pas tout voir… alors j’ai choisi de montrer Comment modéliser: ensembles, relations, fonctions et suites Comment raffiner: très rapidement et sur des exemples très simples Pour arriver à la génération de code Toujours une seule machine Nicole Levy

Conclusions Public jeune et globalement pas très bon Mais sans a priori et très réceptif Un 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

Conclusions Ce que j’espère qu’ils acquièrent (en vrac): Réfléchir au comportement désiré avant de programmer La notion de type et d’invariant La notion de précondition L’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écomposer La notion de raffinement Penser aux tests dès les premières étapes de développement Nicole Levy

Conclusions TP avec l’Atelier B: Contrôleur de Type: le plus utilisé Prouveur: Preuves automatiques uniquement Mais ils doivent savoir lire les Obligations de Preuve L’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 que Surchage du serveur  TP à 2 par machine Problèmes de jetons Les commentaires disparaissent lors du passage à Latex Nicole Levy

Et après ? …. En deuxième année: Le projet tutoré et un suivi dans le module génie logiciel L’analyse des besoins et les fiches de test … pas de spécification B… Mais UML Nicole Levy

1èreétape: Analyse des Interactions un distributeur de boissons... Analyse un plus approfondie des interactions DISTRIBUTEUR LOGICIEL Distributeur Utilisateur choisir une boisson indiquer sucre, annuler monnayeur Rendre la monnaie Rendre l’argent Délivrer une boisson payer capteur gobelet capteur boisson manque gobelet manque boisson Nicole Levy

Exemples d’exercices Des distributeurs en tous genres Un réseau téléphonique L’organisation d’un séminaire … Nicole Levy

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- Nicole Levy