De l'analyse des besoins à la spécification formelle en B : un cours en première année d'IUT

1. 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

2. 1. Objectifs Test d’acceptation Spécification Test Système Conception Architecturale Test d’Intégration Conception Détaillée Tests Unitaires Programmation • Donner une vision globale du développement d’un logiciel basée sur le cycle en V Analyse 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’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

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 Interaction UML Use Case Analysis Invariant Needs Properties Hypothesis Analysis Fact UML sequence * F1: The vending machine UML sequence * F2: The vending machine diagrams * F3: The vending machine diagrams MACHINE captors Client MACHINE captors Client waiting Desired waiting select available select available payment Behavior payment waiting Analysis waiting pay payment pay payment = deliver = price deliver waiting price waiting UML statecharts Complete R2/R7/R9 System init waiting client Description R1 R10 R4/R5/ R6/R8 waiting failure payment R10 R3 R3/R7/R9 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 chargesun 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 choisirsa 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èdede quoi rendre la monnaie ainsi que (possède) la boisson demandée, alors il rendrala monnaie, préparerala 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 Nicole Levy

11. 1ère étape: Analyse des Interactions un distributeur de boissons... Choisir une boisson Indiquer sucre Payer Utilisateur LOGICIEL distributeur Rendre la monnaie Délivrer la boisson • 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 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'environnement • peuvent ê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 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

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 comportementsun distributeur de boissons... • UtilisateurDistributeur • 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

19. 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

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 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) • Si le distributeur est en attente de choix de boisson • 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

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 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 • Si le distributeur est en attente de paiement • Alors le distributeur passe à l’état attente d’un choix de boisson • 8.      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 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

23. 4ème étape: Comportementun distributeur de boissons... R1 R7 Att_boisson Att_paiement R4/R5 R3 R2/R6/R8 R9 R9 Panne R3/R6/R8/R10 • Diagramme d'états-transitions Nicole Levy

24. Génération des tests d’acceptation 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 à Bun 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 à Bun 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

28. De l’analyse des besoins à Bun 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 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

30. 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

31. 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

32. 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

33. 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

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

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

36. Un projet à faire en 3 semaines Source_données Cible_données Agent émetteur Agent récepteur Canal-données Canal de transmission Figure-2- Nœud source Nœud cible • L’an dernier: • Spécification d’un système distribué • Un système de communication dans réseau complexe Nicole Levy