marc le bihanassertions et exceptions.1 les apports des assertions, et des exceptions, au cours de...

Marc Le Bihan Assertions et exceptions. 1

Les apports des assertions,et des exceptions,

au cours de la phase de développement

Marc Le Bihan


Plan

I) La conception d’un logiciel.

II) La recherche d’un fonctionnement sûr.

III) La gestion des exceptions.

Conclusion


La conception d’un logiciel


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


Un acteur [de l’entreprise] a des besoins liés à ses situations de travail.Engageant des notions métiers, ils sont résolus ensuivant 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


• 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


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


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.


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


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


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.


La recherche d’un fonctionnement sûr


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


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


Distance entre défaut et panneUn 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]


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…


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


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


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)


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)


La protection des objets métiersAvec 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(…)) ; }


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


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 à montrerque l’objet est dans une situation attendue,et qu’il l’est pour des causes sans équivoque


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.


[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


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

eg

a[a, b, c][a, b, d, e][a, b, d, f, g]chemins possibles


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]…


Les exceptions


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


Les exceptions métiers = cas d’utilisationdans 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


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


Le message d’erreur en sept pointsUne 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).


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


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: I014217UV: NFP120Sujet: DH01


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


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)

? ?


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)


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


• 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


L’exploitation des 5 couches logicielles

Méthodes publiques aux nomshumainement compréhensibles

Méthodes aux noms complexes

API simple et limitée

API étendue

marc le bihanassertions et exceptions.1 les apports des assertions, et des exceptions, au cours de...

Documents