Abstraction procédurale B. Liskov, Program Development in Java, chap. 3 Procedural Abstraction

Plan Saisir le concept d’abstraction Des avantages de l’abstraction De l’usage des spécifications De la spécification et de l’implémentation des procédures Vers la norme de spécification de l’IEEE

Procédure et abstraction Les procédures combinent les méthodes d’abstraction par Paramétrisation Spécification Afin d’abstraire une simple action ou une tâche

Qu’est-ce qu’une procédure ? Une transformation des arguments en entrée (0 à n) en arguments en sortie (0 à n) Avec modifications possibles aux arguments en entrée

Des avantages de l’abstraction Projection de n à 1 S’abstraire des détails non pertinents Les réalisations sont les mêmes dans les aspects pertinents peuvent varier pour les détails non pertinents

Abstraction par paramétrisation S’abstraire de l’identité des données utilisées Paramètres formels Remplacer par les valeurs réelles Eléments non pertinents L’identité des données qui seront utilisées Eléments pertinents Présence, nombre et type des paramètres La paramétrisation généralise les abstractions Les rend utiles dans plusieurs contextes Avantage Diminue la taille du code qui doit être écrit, modifié et maintenu

Abstraction par spécification Accent est mis sur le comportement auquel l’usager peut s’attendre Abstraction des détails de l’implémentation de ce comportement Élément pertinent ce qui est réalisé Élément non pertinent comment c’est réalisé Avantage Permet de changer l’implémentation sans affecter la signification des programmes qui utilisent cette abstraction Algorithmes différents Langages de programmation différents Par exemple, optimiser certaines parties en langage machine

Propriétés de l’abstraction par spécification Propriétés par rapport à la structure des programmes Localité L’implémentation d’une abstraction peut être lu ou écrite sans devoir examiner les implémentations des autres abstractions Un programmeur n’a besoin de ne comprendre que le comportement de l’abstraction et non les détails de son implémentation Les différentes abstractions qui forment un programme peuvent être écrites par des programmeurs travaillant indépendemment

Propriétés de l’abstraction par spécification Propriétés par rapport à la structure des programmes Modifiabilité Permet de contrôler les modifications et la maintenance Si l’implémentation d’une abstraction change, mais pas sa spécification Alors le reste du programme ne sera pas affecté par cette modification Par exemple, contraindre les opérations dépendantes de la machine à quelques abstractions pour réduire la difficulté et les efforts liés au « transport » sur une autre machine Conduit à une méthode raisonnable et compréhensible pour la mise au point de la performance Il est notoire que les programmeurs sont particulièrement mauvais pour anticiper où les calculs d’un système complexe seront importants Il est très difficile d’identifier les goulots d’étranglement http://www.quest.com/jprobe/index.asp The freeware version is available for Windows and Linux

Des spécifications Si on veut exploiter les propriétés des abstractions (localité et modifiabilité) il est essentiel de donner aux abstractions des définitions précises Les abstractions sont définies par des spécifications Formelles Elles ont une signification précise Informelles Plus faciles à écrire et à lire Moins précises Les spécifications précisent les aspects communs des implémentations qui réalisent une abstraction Un langage de spécification n’est pas un langage de programmation

La spécification d’abstractions procédurales En-tête Information syntaxique Spécification des effets Information sémantique

L’en-tête Information syntaxique Nom de la procédure Nombre, ordre, nom(s) et type(s) des paramètres Type du résultat Liste des exceptions lancées Exemples void removeDupls(Vector v) float sqrt (float x)

La spécification des effets Information sémantique Ce que fait la procédure 3 parties Clause requires Clause modifies Clause effects // REQUIRES: cette clause énumère toute contrainte liée à l’usage de la procédure // MODIFIES: cette clause identifie tout paramètre d’entrée modifié //EFFECTS: cette clause définit le comportement de la procédure Return_type proc_name (…)

Entrées d’une procédure Pour la plupart des procédures Exactement les paramètres énumérés dans l’en-tête de la procédure Certaines procédures ont des entrées implicites fichier à lire System.out

La clause REQUIRES Explicite les contraintes sous laquelle l’abstraction est définie Nécessaire si la procédure est partielle Si son comportement n’est pas défini pour certaines entrées exemple, factorielle Peut être omise si la procédure est totale Si son comportement est défini pour toutes les entrées dont le type est acceptable Dans ce cas, les seules contraintes sont celles spécifiées sur le nombre, le type et l’ordre des paramètres d’appel

La clause MODIFIES Énumère le nom de toute entrée qui est modifiée par la procédure Correspond aux effets de bord Peut être omise s’il n’y a pas d’effets de bord

La clause EFFECTS Décrit les effets de la procédure pour toutes les entrées acceptables Suppose que la clause REQUIRES est satisfaite Définir quelles sorties seront produites Définir quelles modifications sont faites aux entrées dans la liste de la clause MODIFIES

La spécification des classes En Java, procédures == méthodes static Il faut donc connaître la classe où elles sont définies La spécification doit mentionner Le nom de la classe Une brève description de son rôle. visibility class_name { // OVERVIEW : this class defines the // purpose of the class as a whole visibility static proc_name_1 {…} visibility static proc_name_2 {…} }

totale partielle totale /** * OVERVIEW : this class provides a number of standalone procedures * that are useful for manipulating arrays of ints * */ public class Arrays { * EFFECTS : if x is in a, returns an index where x is stored; * otherwise, returns -1 public static int search(int[] a, int x) {…} * REQUIRES: a is sorted in ascending order public static int searchSorted (int[] a, int x) {…} * MODIFIES: a * EFFECTS : Rearranges the elements of a into ascending order * e.g. if a = [3, 1, 6, 1] before the call, * on return a = [1, 1, 3, 6] public static void sort ( int[] a){} } totale partielle totale

Remarques La spécification de searchSorted ne spécifie par ce qui se passe si l’argument ne respecte pas la clause REQUIRES Moralité : éviter le plus possible les clauses REQUIRES Notation alternative /** * MODIFIES: a * EFFECTS : Rearranges the elements of a into ascending order * e.g. if a = [3, 1, 6, 1], * a_post = [1, 1, 3, 6] */ public static void sort ( int[] a){}

Exemple /** * * REQUIRES: * MODIFIES: * EFFECTS : returns a new array containing the element of “a” * in the order they appear in “a” * except that any element of “a” that are greater than “n” * are replaced by “n” */ public static int[] boundArray ( int[] a, int n) Est-ce boundArray peut rendre le même vecteur si aucun de ses éléments n’est supérieur à n ? Exclu par la spécification Cette précision est importante à cause des problèmes de partage éventuel de référence

Exemple avec entrées implicites /** * * REQUIRES: System.in contains a line of text * MODIFIES: System.in and System.out * EFFECTS : Reads a line of text from System.in, * advances the cursor in System.in to the end of the line, * and writes the line on System.out */ public static void copyLine(){} Rem.: la spécification décrit les effets sur les entrées implicites

De l’implémentation des procédures L’implémentation doit produire le comportement spécifié par sa spécification En particulier, ne doit modifier que les entrées de la clause MODIFIES

Qu’est-ce qu’une implémentation acceptable? /** * REQUIRES: “a” is sorted in ascending order * EFFECTS : if “x” is in “a”, returns an index where “x” is stored; * otherwise, returns -1 */ public static int searchSorted(int[] a, int x) { if (a == null) return -1; for (int i = 0; i < a.length; i++) if (a[i] == x) return i; else if (a[i] > x) return -1; } Test if (a==null) return -1; Consistant avec la spécification Cependant, il vaut mieux traiter ce cas à part et déclencher une exception

Le design d’abstractions procédurales Les procédures servent à réduire le code appelant à clarifier la structure d’un programme On peut parfois introduire trop de procédures… Propriétés souhaitables des spécifications et de leur implémentation minimalement contraignantes générales simples

De la minimalité Une spécification est « plus minimale » qu’une autre si elle possède moins de contraintes.

Procédures sous-déterminées Certains détails de ce que fait une procédure peuvent être non-définis Pour certaines entrées, il peut exister plusieurs sorties acceptables En général, les implémentations sont déterministes, mais ils peuvent être non-déterministes Usage de primitives non-déterministes, données globales, variables statiques Exemples Dans search et searchSorted On ne spécifie pas quel indice doit être rendu si l’élément recherché se trouve plusieurs fois dans le vecteur Résultat: des implémentations différentes peuvent rendre des résultats différents

De la généralité des procédures Une procédure est plus générale si elle peut traiter une plus grande classe d’entrée Obtenue en utilisant des paramètres Par exemple, l’objet recherché Généraliser une procédure n’est intéressant que si cela augmente son utilité Éliminer les hypothèses liées à la taille, etc. La généralisation est discutée au chapitre 8 du livre de Liskov

De la simplicité des procédures Une procédure devrait avoir un rôle bien défini facile à expliquer indépendant du contexte d’utilisation Un indice de simplicité le nom devrait être facile à trouver

Quand définir une procédure partielle? Procédures partielles Peuvent être plus efficaces que les procédures totales Par ex. l’implémentation de searchSorted pourra être optimisée Pas aussi sécuritaires que les procédures totales Car l’usager doit s’assurer que les contraintes de la clause REQUIRES sont satisfaites Par ex. le comportement de searchSorted n’est pas défini si le vecteur n’est pas trié

Remarques sur l’usage des procédures partielles Conclusion : Il faut choisir entre l’efficacité et un comportement sécuritaire à l’exécution n’utiliser les procédures partielles que lorsque le contexte d’utilisation est bien limité et qu’un bénéfice substantiel peut en être retiré, par exemple la performance Lorsque c’est possible, l’implémentation devrait vérifier les contraintes de la clause REQUIRES et lancer une exception le cas échéant Par exemple, si dans une librairie – contexte général – privilégier la sécurité Lorsque les contraintes ne sont pas respectées Rendre une valeur ou un objet correspondant à un code d’erreur, e.g. -1, null… Afficher un message d’erreur Lancer une exception (l’approche à privilégier) Le chapitre 9 de Liskov traite de la manière d’écrire de bonnes spécifications