La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Marc Le BihanAssertions et exceptions.1 Les apports des assertions, et des exceptions, au cours de la phase de développement Marc Le Bihan.

Présentations similaires


Présentation au sujet: "Marc Le BihanAssertions et exceptions.1 Les apports des assertions, et des exceptions, au cours de la phase de développement Marc Le Bihan."— Transcription de la présentation:

1 Marc Le BihanAssertions et exceptions.1 Les apports des assertions, et des exceptions, au cours de la phase de développement Marc Le Bihan

2 Assertions et exceptions.2 Plan I)La conception d’un logiciel. II)La recherche d’un fonctionnement sûr. III)La gestion des exceptions. Conclusion

3 Marc Le BihanAssertions et exceptions.3 La conception d’un logiciel

4 Marc Le BihanAssertions et exceptions.4 Dans une entreprise, chacun manipule des notions métiers propres à sa fonction, à son corps de métier. Tout personne (acteur) finit par demander l’assistance d’un de ses: collaborateurs, service/département de son entreprise, sous-traitant. L’aide peut-être obtenue si les problèmes à résoudre sont clairement exposés. Un acteur demande une assistance

5 Marc Le BihanAssertions et exceptions.5 Un acteur [de l’entreprise] a des besoins liés à ses situations de travail. Engageant des notions métiers, ils sont résolus en suivant des règles de gestion connues et approuvées. C’est un service ou une personne qui y répondront. D’eux, pour des éléments donnés, l’acteur attendra: -d’autres éléments en retour, ou que des opérations soient accomplies. -Un rejet de la demande, motivé. -Une notification d’échec éventuel. Une assistance: un contrat de service

6 Marc Le BihanAssertions et exceptions.6 L’utilisateur [l’acteur dans l’entreprise] sait ce qu’il veut obtenir et à partir de quoi (des objets métiers, qui sont son propre quotidien). Nous savons à qui nous allons le demander (un service, qui répondra à un cas d’utilisation). Mais nous ne savons pas comment il s’y prendra pour répondre à notre demande. Cela suffit à une première formalisation du traitement: ses principes de fonctionnement sont suffisamment décrits pour avoir un moyen de validation. Test driven: des tests avant le codage

7 Marc Le BihanAssertions et exceptions.7 Les analystes fonctionnels ont défini des cas d’utilisation aux règles de gestion précises: éléments en entrée. en sortie. situations de rejet (exceptions métier). On ne peut remplacer par des types de base les objets métiers, ni les exceptions métiers par des Exception. L’appelant ne possèdera en retour que: -Le paramètre de retour du service: utile et contraint. -Ou l’exception, sa seule source de diagnostic. Et parfois, de reprise possible. Conserver la précision de la demande

8 Marc Le BihanAssertions et exceptions.8 Les problèmes du typage faible Object fcn(Object arg) throws Exception Cette fonction est imprécise et est source d’instabilité. Object arg : Elle ne sait pas précisément ce qu’elle va recevoir. Object est retourné : Elle ne décrit pas clairement ce qu’elle va renvoyer. Exception peut être levée: Elle n’est pas très consciente de ce qui peut l’arrêter.

9 Marc Le BihanAssertions et exceptions.9 Un service subit l’effet cumulé de toutes les imprécisions du logiciel: L’ordre d’agir vient d’IHMs, de contrôleurs, de modèles qui ont une interprétation de la demande. Fasse que le service ait également la même! Pour la résolution de la tâche réclamée, le service doit se fier à des DAOs et des objets métiers qu’il ne peut qu’escompter justes. [l’hypermarché] Le service subit les imprécisions

10 Marc Le BihanAssertions et exceptions.10 spécification inexistante condition d’échec bien maîtrisée spécification obsolète condition état satisfaisant spécification incomplète spécification incorrecte Condition(s) d’apparition mal connues ??? condition d’échec non traitée Situation inadaptée, instable D’un état à l’autre: de nombreux aléas Une action quelconque entreprise par le logiciel, qui aura pour effet de passer d’un état à un autre, peut nous conduire à un grand nombre de situations

11 Marc Le BihanAssertions et exceptions.11 20, 100, 300, 500 classes… Une application voit sa complexité et son temps de développement croissants quand son nombre d’instructions augmente. 20 classes*: 3 semaines, 1 personne. 100 classes: 4 mois, 2 personnes. 300 classes: 1 an, 3 personnes. 500 classes: 2 ans, 4 personnes. * pour 75 instructions par classe.

12 Marc Le BihanAssertions et exceptions.12 La recherche d’un fonctionnement sûr

13 Marc Le BihanAssertions et exceptions.13 Le Titanic n’a pas coulé parce qu’il a heurté un Iceberg Il a sombré parce qu’il: -Allait à grande vitesse pour battre un record de traversée. -N’avait pas tous ses officiers à leurs postes de surveillance. -N’avait pas assez de charbons ardents pour ses lampes. -Ses rivets, de mauvaise qualité, se sont révélés particulièrement peu robustes. Il s’agit de négligences accumulées. Le Titanic

14 Marc Le BihanAssertions et exceptions.14 Le jour d’une défaillance majeure X, Le service Y ne peut pas retrouver toutes les logs. La procédure de redémarrage échoue après avoir réalisé 85% de son travail. Le module de re-calcul des données fausses dues à X traite mal 10% des cas. Une opération jadis mal implémentée impose depuis toujours une intervention hebdomadaire humaine pour corriger un enregistrement défectueux dans une table, et le retraitement intégral impose aujourd’hui 800 interventions. Vous êtes mort. Un incident fatal

15 Marc Le BihanAssertions et exceptions.15 Distance entre défaut et panne Un logiciel, ne peut éviter de présenter temporairement des anomalies. Mais celles-là ne doivent pas l’affecter au point qu’il soit brutalement mis en péril. Si le défaut et la panne sont: au même niveau dans la pile d’appel (même fonction): résolution du bug rapide. Un niveau d’écart: plus long. Deux niveaux d’écarts: nettement plus long. Trois niveaux d’écarts: Dangereux. [Le nouvel épluche-légumes]

16 Marc Le BihanAssertions et exceptions.16 Quand un programme ne sait pas ce qu’il va faire, mieux vaut qu’il s’arrête. Quand il sait qu’il va faire une ânerie, surtout qu’il ne la fasse pas. Un programme qui s’est stoppé sans agir, doit être corrigé et re-livré. Un programme qui a échoué en abîmant une base de données, doit être corrigé, re-livré. S’ajoute une reprise, toujours incertaine et mal perçue. Un impératif: stopper les programmes incertains, hésitants…

17 Marc Le BihanAssertions et exceptions.17 La prudence s’impose toujours, même dans les cas qui semblent anodins. Si une valeur est retirée d’une énumération tandis que cette valeur circule encore en base, elle sera un jour rencontrée et l’application stoppée. En revanche, une valeur ajoutée à cette même énumération passera inaperçue, alors que son effet est insidieux. [La cantine] Les énumérations d’états interprétables

18 Marc Le BihanAssertions et exceptions.18 Un traitement qui observe des valeurs énumérées, devrait toujours s’alarmer de celles qu’il ne reconnaît pas. switch(etat) { case STOPPE :... break ; case ACTIF :... break ; case SUSPENDU :... break ; default : // Bloquer impérativement les états que l’on ne connaît pas. throw(new RuntimeException("Etat inconnu : " + etat)) ; } Les énumérations d’états interprétables

19 Marc Le BihanAssertions et exceptions.19 Une assertion est une prévention minimale. Elle est au développeur ce que l’équipement de sécurité est à l’alpiniste. L’expérience accroît nos compétences, et on les penserait avec le temps de moins en moins utiles pour soi, mais: -nous construisons des logiciels plus gros (nos capacités de conception, d’implémentation s’accroissent). -Le taux d’erreurs au millier d’instructions a un plancher.. 30 erreurs/1000 instructions pour un développeur débutant.. 10 erreurs pour un développeur de 1 à 5 ans d’expérience.. 5 à 7 pour un développeur très expérimenté.. Tests unitaires et de recette divisent ce taux par deux.. Certaines sociétés disent descendre à 1 ou 2 erreurs/KSL.. NASA, organisations militaires, jusqu’à 0,5 ou 0,3… ? Les bénéfices des assertions (1/2)

20 Marc Le BihanAssertions et exceptions.20 Les erreurs résiduelles peuvent avoir grossièrement cet effet lors de l’exploitation d’un logiciel: 3 à 5 erreurs/1000 instructions = 1 jour de perdu par mois pour des corrections. 5 à 10 erreurs = 3 jours à une semaine perdue par mois. > 10 = logiciel quasi-inutilisable. Une assertion prévient de situations vis-à-vis desquelles développeur et concepteur ont souhaité se prémunir, mais aussi des conséquences logiques d’évènements non immédiatement apparents. Ce qui peut amener à réviser des spécifications ou prendre connaissance de comportement inattendus. Les bénéfices des assertions (2/2)

21 Marc Le BihanAssertions et exceptions.21 La protection des objets métiers Avec les pré-conditions et les invariants. private Object m_o ; // La variable membre qui ne peut être nulle. public Object getXXXX() {check() ; return(m_o);} // Test de l ’ invariant dans le getter. public void setXXXX(Object o) { // Test de la pr é -condition dans le setter. if (o == null) throw (new IllegalArgumentException( … )); m_o = o; } public void check() { // Invariant de l ’ objet. if (m_o == null) throw(new IntegriteObjetMetierException( … )) ; }

22 Marc Le BihanAssertions et exceptions.22 L’invariant d’instance d’un objet, placé dans sa méthode check(), vise à démontrer qu’il est dans une situation admise avant que son contenu ne soit employé. L’invariant contrôle typiquement: -Le contenu des variables membre de type simple (int, String…). -Le contenu de ses autres membres, dont il appelle aussi la méthode check(), s’ils en disposent. -L’invariant de la super-classe de l’objet. L’invariant d’objet: principe

23 Marc Le BihanAssertions et exceptions.23 Soit un objet A composé de membres qui sont des objets ou des types simples. En majuscule: ceux qui ont un invariant. En minuscule: ceux qui n’en ont pas, ou sont des membres de type simple. L’invariant: chaînage arrière L’invariant de A est vérifié si: A :- b, C, d, E. Ce qui implique: C :- f, g, I. E :- o, p. Et par là: I :- H, k, l, M, N. Et: H :- t, u, v. M :- q, r. N :- s. L’invariant d’objet cherche à montrer que l’objet est dans une situation attendue, et qu’il l’est pour des causes sans équivoque

24 Marc Le BihanAssertions et exceptions.24 La validité de A est la conséquence de la validité de ses autres variables membres. L’invariant: chaînage avant Parce que le contenu des variables: t, u, v, q, r, s, o, p était correct, H, M, N et E ont été déclarés corrects. Parce que: H, M, N, k, l étaient corrects I a été déclaré correct. Parce que: I, f, g étaient corrects C a été déclaré correct. Parce que: C, E, b, d étaient corrects A a été déclaré correct. Des causes ont mené à des conséquences uniques.

25 Marc Le BihanAssertions et exceptions.25 [le peintre et le mélange des couleurs] Notre intérêt n’est pas seulement de savoir que nous sommes dans une bonne situation, mais que c’était inévitable au vu des conditions respectées. que nous ne nous sommes pas retrouvés dans une situation admise par le fruit d’un heureux hasard. Un booléen a toujours une chance sur deux « d’être bon »! Sa seule valeur ne compte pas, elle ne garantit rien! Éradiquer le hasard

26 Marc Le BihanAssertions et exceptions.26 Le graphe de commande (1/2) 1 à n opérations en séquence dont on considère l’exécution atomique (pas de condition, pas de levée d’exception) Une condition simple. Attention: (i == 1 && j > 3) sont deux conditions simples j = x + 1; i = obtenirValeur(); if (i == 1 && j > 3) { z = j * 2; j --; } J = x+1; i = obtenirValeur(); i == 1 j > 3 z = j * 2; j --; i != 1 j <= 3 détail forme habituelle b d f c e g a [a, b, c] [a, b, d, e] [a, b, d, f, g] chemins possibles

27 Marc Le BihanAssertions et exceptions.27 Le graphe de commande (2/2) La possible levée d’une exception équivaut à une condition (soit elle est levée, soit elle ne l’est pas). a b c d e f g h La présence d’une boucle incite à tester les cas: - zéro itérations. - une itération. - n itérations. Il pourra être intéressant de tester une fonction qui aurait ce graphe de commande sur ces chemins: [a,b,e,f], [a,b,c,d,g], [a,b,c,d,h,e,f], [a,b,(c,d,h) n>1,e,f]…

28 Marc Le BihanAssertions et exceptions.28 Les exceptions

29 Marc Le BihanAssertions et exceptions.29 Lors d’un incident, la capacité de réaliser un déboggage à chaud (une exécution pas à pas) dans une contexte identique à celui de la panne est rare.. Si le problème est découvert tardivement: Les données utiles ont pu être consommées.. Et elle est typiquement impossible lorsque:. Il n’y a pas de déboggeur disponible,. ou de sources!. Dans des applications réparties. => Très bonne Traçabilité requise. La session de déboggage

30 Marc Le BihanAssertions et exceptions.30 Les exceptions métiers = cas d’utilisation dans la plupart des cas. Elles sont levées à l’issue d’actions interdites (mais prévisibles) de l’utilisateur. Ou par des règles de gestion, qui refusent en le motivant le traitement de tel objet métier par tel service, avec un bien fondé parfaitement établi. Mais ces exceptions métiers peuvent aussi mettre en lumière des spécifications incomplètes, fausses ou inexistantes… Exceptions métiers = cas d’utilisation

31 Marc Le BihanAssertions et exceptions.31 Exceptions checkées, non checkées Les exceptions checkées, non checkées.. Objets métiers (checkées).. DAOs, persistance: (checkées, mais présentées par leur type de base).. Invariants, accès à annuaire, aux services (non checkées).

32 Marc Le BihanAssertions et exceptions.32 Le message d’erreur en sept points Une exception sans message gêne la compréhension. Mal ou non typée, elle rend difficile la reprise, le choix de la réaction à l’événement. Le message qui l’accompagne devrait comporter trois à quatre de ces indications: Situation du composant au moment de l’appel (rare). Motif de l’appel (courant). Paramètres d’entrées associés (courant). Motif de l’échec (toujours). Éléments impliqués dans l’échec (courant). Diagnostic éventuel (rare). Solution de contournement (très rare).

33 Marc Le BihanAssertions et exceptions.33 Un pharmacien pourra refuser de nous donner une boite de médicaments, parce que : -Nous n’avons pas d’ordonnance a lui soumettre. -Nous en avons une, mais elle ne mentionne pas le produit que nous voulons. -L’ordonnance est périmée. -Nous voulons un renouvellement mais il est trop tôt pour cela. -L’ordonnance est illisible. -Nous n’avons pas la somme nécessaire pour régler le médicament. -Le pharmacien n’a plus notre remède en stock. Typage des exceptions: le pharmacien

34 Marc Le BihanAssertions et exceptions.34 Note correctionAutomatique(Casier c, ParametresCorrection pc) throws AuditeurInexistantException, AuditeurNonInscritException, AuditeurSansDevoirException, DevoirEnErreurException, DevoirNonSelectionnableDansModeException, DevoirDejaNoteDefinitivementException DevoirNonNotableException, DevoirNonNoteException, DevoirSansExecutableException, NoteInvalideException, SujetInexistantException, SujetNonAccessibleAuditeurException, SujetNonExamenException, TestAutomatiqueEchoueException, UVInexistanteException, PersistanceException Un cas d’utilisation complexe Auditeur: I UV: NFP120 Sujet: DH01

35 Marc Le BihanAssertions et exceptions.35 Une exception se propage au travers de la pile d’appel. Elle ne devrait être stoppée que si le niveau d’appel sait quoi en faire! Ré-interprétation ou enrichissement possibles, en rapport avec les informations possédées au niveau d’appel considéré. La propagation des exceptions

36 Marc Le BihanAssertions et exceptions.36 Un incident sur un support physique comme un enregistrement inexistant, peut parfois avoir une traduction métier immédiate. Traduire l’exception de persistance en exception métier permet de lever l’ambiguïté d’un EnregistrementInexistantException. Commander(Client c, Article a) throws EnregistrementInexistantException catch(EnregistrementInexistantException e) { throw(new ArticleNonCommandeException(e.getMessage(), e, refArticle)); } La promotion des exceptions (1/2) ??

37 Marc Le BihanAssertions et exceptions.37 Lorsqu’une exception métier survient durant l’exécution d’un service, elle peut avoir une interprétation dans la logique de ce service, et être promue. public CommandesClients prendreCommande(int numeroTable) throws AutreTableProposeeException, RestaurantCompletException { try { … } catch(TropPeuDeGensSurGrandeTableException e) { // Recherche d’une autre table. if (…une meilleure table existe…) throw(new AutreTableProposeeException(e.getMessage(), e, autreTable)); else throw(new RestaurantCompletException(e.getMessage(), e)); } La promotion des exceptions (2/2)

38 Marc Le BihanAssertions et exceptions.38 n nouvelles exceptions métiers (à catcher) apparaissent dans une fonction. Que se passe t-il ? Cas n°1: La re-compilation d’un programme utilisateur de la fonction échoue, il faut les catcher. Par là, justifier d’un comportement vis-à-vis d’elles. Cas n°2: Le programme n’est pas re-compilé, mais en s’exécutant il rencontre cette nouvelle exception. Il échoue sur une UndeclaredThrowableException. Est-ce un mal, est-ce un bien? C’est un bien. Cf. La cantine. [le métro] L’apparition de nouvelles exceptions métier

39 Marc Le BihanAssertions et exceptions.39 L’énumération des chemins possibles dans une fonction. La possibilité de mettre en évidence les causes/conséquences par des assertions. L’emploi d’exceptions d’une manière qui détaille les évènements (des incidents ou non) qui dérogent du chemin classique attendu pour la résolution d’un cas d’utilisation. Conclusion

40 Marc Le BihanAssertions et exceptions.40 L’exploitation des 5 couches logicielles Méthodes publiques aux noms humainement compréhensibles Méthodes aux noms complexes API simple et limitée API étendue


Télécharger ppt "Marc Le BihanAssertions et exceptions.1 Les apports des assertions, et des exceptions, au cours de la phase de développement Marc Le Bihan."

Présentations similaires


Annonces Google