METHODOLOGIE DE CONCEPTION ET DE REALISATION "Nous nous intéressons dans ce chapite aux moyens d'augmenter Ia abiité dds sysiémes, In abil d'un objet dant cine par la probabilite pour cue ext objet remplisse pendant un temps donné des fonctions spécifees dans certaines conditions exploitation. Nous avons deja etudié au chapitre 5 comment on pouvait améliorer cette fabilité en ineluant dans les systimes des disposiifs de protection destin 8 déterter les erreurs en cous de fone- ‘ionnement et & limiter leurs conséquences. Nous allons examiner & présent exrtaines méthodes de conception, de réalisation et de mise au point qui tendent a accroitre la probabilité de bon foactionnement des systimes produits Par ces méthodes. 7.1 INTRODUCTION AThhcure actuelle, la mise au point des programmes (Cest-i-dire la recherche et la correction des erreurs) tend & consommer la majeure partic da temps et de Pénergic des programmeurs. Au-dela d’un certain degre de complenité, ‘on peut dire qu'un programme ne sort jamais de sa phase de mise au point, Cest-Adire qui y subsiste toujours des erreurs. Nous nous intéressons aux moyens d'améliorer ceite situation, en ayant surtout en vue Je cas des gros Programmes, oi le probléme se pose avec le plus d’scuité. Nous ne tenterons as ici de fixer des seuils de taille, de durée de réalisation, de complexité, de 280 Systimesd'exploitation des ordinateurs nombre de programmeurs, ausdessus desquels un programme peut étr qualifié ‘de« gros», nous contentant de mentionner que tous ces facteurs interviennent (On peut distinguer schématiquement trois tapes dans le traitement d'un probleme sur ordinateur 1) Grablissement d'un modéle par formalisation d'un probleme concret, 2) description ¢'un algorithme de traitement dans un langage non ambigu, ui peut oa non étre desting a V'nterprétation par une machine ; tous les renseignements nécessaires 4 la construction de cet algorithme sont contenus dans le modéle étabi & la premiére étape, 3) construction d'un programme exécutable, dont Uinterprétation met en uvre Valgorithme sur une machine donnée. Nous considérons ici la dernigre de oes étapes. Pour que le programme résolve effoctivement le probléme pose, il doit satisfuire & un certain nombre de proprigtés qui dédinissent son comportement dans des circonstances déser- mines. On appelle spécifications Fensemble de ces proprités. Elles doivent caractériser Je comportement du programme de fagon compte et, de préie= rence, simple et non redondante. Le probléme de Tétablissement des spse- fications ne nous interesse pas ici; remarquons simplement que le passage du rmodéle & Valgorithme et de Malgorithme au programme peuvent introdaire es distorsions dues aux limitations introduites par Je langage ou par son implantation. Exomple. Les proprités des opérations arithmétiques sur des nombres repré sentés dans des mots de longueur fine ar sont pas identiques& cells des opézations sues; asi, sia = 6 est imexprét comme [eB |< 2", aborsa= bet b= nentrainen paenécerairement 2 = ¢. Un programme cst dit valide sl répond a ses spécifications Pour eure utilsable, on demande en outre & un programme de poscéder certaine: pro- prigts qui influent sur son mode de réalisation — respect de contraintes économiques : minimisation dune fonction de coil a définr par le concepieur, encomlsrement, date limite d'achéverent, ete, — possibilité de compréhension et de modification. Cette demitre propriété est particuliérement importante, L'expérience monire en effet que les specifications des programmes évoluent, que des erreurs sont découvertes pendant leur utilisation. Au cours de son existence, tout programme doit étre adapté aux modifications de ses conditions d'ut lisation. Une condition pour qu'un programme soit aistment modifiable est que Téeventualité d'une modification soit explicitement préwue dans sa consiruction. Cela peut étre réalisé de deur fagons —en sestreignant les possbilités de modification a un choix dans tun ensemble fix une fois pour toutes (assemblage conditionnel), — en convevant Ie programme de maniére a faciliter le remplacement ou Traddition de parties de programmes (modularité)Methodologie de conception et de réalistlon 281 Une autre condition pour qu'un programme soit modifiable est quill en cxistz une description permettant de comprendre sa structure et son fone tionnement, a un niveau de détail suffisent. Cetic description est souvent donnée sous forme de comunentaires mais elle nest pas nécessairement dis- tinete du texte du programme lui-méme. Compte tent des contraintes ci-dessus, on cherche done & réaliser des programmes valides. Le probleme de la vslidite peut étre aborde sous deux aspects ~ dant donné un programme existant, établir sa validilé vis-vis c’un ensemble donné de specifications, — étant donné un ensemble ce spevifications, construire un programme qui les verti. Pour établir Ia validité d'un programme existant, on pourrait imaginer de {aire exécuter le programme dans les conditions définies par ses spécifcations, et de verifier que les résultats obtenus sont ceux spécifés. Dans la pratique, une telle démarche est impossible, car Je nombre de cas & exeminer serait ‘wis grand : ainsi, la vérifeation d'une procédure de racine carrée devrait comprendre l'essai de tous les nombres réels aon négatifs reprécentables ! Suwvant ls formule de Dijkstra, ls tests peuvent servir & détecter Ia présence erreurs, non & prouver leur absence. La validté d'un programme ne peut done en géntral se deduite du seul examen de son comportement, elle doit dre démontrés & partir des propriétés de la structure du programme. L'état ‘actuel des connaissances est encore loin de permettre une telle démarche; ‘nous doanons en 7.2 quelqucs indications sur ies techniques utilisées dans les preuves de vaiidité. En ce qui conceme la construction d'un progrerame & partir de ses spéci= fications, on ne dispose pas noa plus d'un meyen automatique. Toutefois, (on peut utiliser des méthodes quipermettent, 4 dfaut d'une certitude, d'accroi te considérablement le degré de confiance que I'on peut avoir dan’ les pro ‘grammes constraits, tout en rendant plus aisées leur modification et leur ‘mise au point. Ces méthodes sont examinées en 7.3 sous Ie titre général ec « Programmation structurée ». Tes langages utilisés pour l'écriture de systémes et les outils de mise au point sont examinés en 7.4. Enfin, un exemple tire d'un probléme rée!illustce en 7.5 application des méthodes présentées, 7.2 VALIDITE DES PROGRAMMES "Nous donnons iti un apergu des méthodes utilisées pour démontrer qu'un ‘Programme est valide, c’est-d-dire qu’il véritie ses spécifications. Nous suppo- sons que celles-ci sont donnée: sous la forme de relations, 00 assertions [Floyd, 67), entre ls variabls entrée t les variables de’ sortis du pro- gramme ; nous supposons en oatre quele programme ne comportepasd'extew- tion parallle 282 Systemes dexplottatton des ordimateurs Plus précisément, nous ééfinissons = — une assertion dentrée spécifiant les relations existant par hypothése entre les données du programme, — une assertion de sortie specifiant la relation souhaitée entre les variables de sortie et celles d'entrée, ou entre certaines variables de sortie. xemple 1. Soituneprocédate de calcul dea racine carte yan nombre don x, vee ne prison © ‘Awortion doatge: x > 0 Assertion de sorte ‘17? — x] mem et («= disque) )) rimoire et dspe teoréscoten des tables Ciaplanation des pases en memoie pre Goal ct sur disque. Nest naturel de considérer un programme comme une suite d’étapes; 4 chaque étape correspondent des assertions d'entrée et de sortie. Prowver la validité d'un programme (on d'une étape), c'est démontrer = que le programme se termine, c’est-i-dire quill atteint en un nombre fini d'opérations I'un des points de sortie prévus, — que les assertions correspondant 4 ce point de sortie sont vérifiges. Exemple, Calcul dea (J. King, cié dans (Dijkstra, 72). Etant donné deux eatiers a et b (a > 0,4 >0), la suite distractions ciapres affete A z la valeur * (on suppose déciaxés les enters x, 9. 2.2), xmasye bee ly fart gy # O fae impair) elrs début La fonction boolieane impair(y) prend la valeur vat st et seulement si Yentier 7 ot impair. =Méthodologie de conception et ce réclization 283 Remsrqe, Liateroruation de cee wit dintrctions fit appl & un crs sombre dasiomesimpiciement ada, sis 'il adres en outs avon foun dans une prev comple de va. Ce asomestraduset sous forme dations le proprates des civereopéatars ntoduiy e de teprescnaton det nos, ‘Aint toe prope de Topiratat = ex tad par at que anton de ete pours pom ay assertion d'enrés est: o ero a b>o Lassertion de sortie est @ La démonsiration comporte deux étapes 1) Désignant par / Tinstruction composés suivant tant que .. fare, nous allons abord démontrer que Tenécation de J Masse invariante la relation e o x>0 a yR0 a @asew Dvapeés (1), cette relation est vraie avant le premiére exécution de J Nous distinguerons deux eas pour la preuve d'invariance 4) y impair. Posons » = 2p + I (p > 0) et désignons par x’, valeurs prises par x, y, 7 aprds exécution de 7: Tes nouvelles weary On a done Pex” a rere (ey erect orae “ x20, 20 Six, y, 2 vérient (3) alors x’ ’, + verfent (2) également, 2) y pair. Posons y = 2p (p 2 0). Avec les mimes notations qu'en 2}, on trouve : katy yap vee oi Fee a 20/8 eee zee? e X20, veo etTinvariance 6e (3) est encore assurte On remarque que y 2 toujours use valeur paire avant V'exécution de y = y/2.ce ‘qui gurantit que y conserve des valeurs eniires, 2) Nous allons & présent démontrer que la boucle 2 que 9 termine. Si 'on note 7 la valear initial de y et y,sa valeur aprés la Fiéme exEcutioa ée I, alors on a pour tou # 2 0. ou bien y, = 0. ou bien »... <3. Les y, Giant non népatifs, existe done ‘un eatier & tel que y= 0, ce qui garantic Varrét de Ia boucle aprés K itérations. La 281 Systimes d exploitation dee ordnateurs relation (1), veaie initalement, reste vrai apeés k exéoutions de J Les valeurs finales dex. y. 2 vériiear done xo yao a oe Liassertion de sortie : = a* ex done veriée. (On pourra trouver dans [Hoare, 71] un autre exemple de preuve de validité, pour un programme plus complexe (tr). Les méthodes de preuve de validité de programmes sont encore trés loin etre entrées dans la pratique courante, mais on peut prévoir & long terme le développement d'outils (probablemeat interactifs) permettant Ia construc- tion de la preuve parallement a celle du programme (Floyd. 71 ; Soowdon, 1}. La possibilté d'exécution d'opérations paralléles introduit des difficultés supplémentaires dans les preuves de validité. Pour Scrire les assertions, on a besoin d'introduire des axioms supplémentaires liés au temps (indivisiblite de certaines opérations). Cela peut étre fait en spécifiant un mécanisme de synchronisation entre provessus, les démonstrations ne s‘appliquant alors qu’aux ensembles de processus utilisant ce mécanisme. C'est ainsi que le fonctionnement correct du. systéme producteur-consommateur (cf. 2.5) a puétre démontré en utilisant un théoréme sur les sémaphores. On trowvera dans [Dennis, 70] plusieurs tentatives de formalisation des proprieiés des processus. Dans tous les cas présentant quelque intérét pratique, la complexité de la demonstration est telle qu'elle exclut Theure actuelle utilisation courante des preuves de validité, notamment dans les systtmes. Nous développons done dans ce qui suit une voie d'approche moins formelle. 7.3. PROGRAMMATION STRUCTUREE, Considérons maintenant le probléme sous un autre angle :au lisu de prouver qu'un programme donné satisfait certaines spécifications, on se propose de construire un programme satisiaisant des spéciications données. Une solution idéale serait naturellement de construire automatiquement le programme, Ainsi (Simon, 63] décrit ua constructeur automatique de programmes IPL V dont les spécifications sont expriméss dans un sovs- ensemble de Tanglais. L'impossiilité oi 'on se trouve en général ¢'exprimer ormeliement les spévifications d'un probleme rend une telle solution inexploi- table dans la pratique On tente donc, de fagon plus pragmatique, de tirer parti de la iberté dont on dispose dans Pécriture du programme pour fui donner une siructure propre & faciliter 4 la fois la construction du programme et la démonstration de ca valigté, On désigne sous le terme général de programmation stracturéeMéthodologie de conception e: de réalisation 285 (Dijkstra, 72; Mills. 72: Wirth, 73], un ensemble de méthodes mises en ceuvre pour atteindre ces objects. On peut citer en particulier: — la décomposition des programmes en sous-ensembles pour aboutir a des éléments de complexité acceptable, le choix dune decomposition telle gue es interactions entre sous- «ensembles soient les plus simples possibles, cae BSReifeation pour chaque pete de programme d'assrtons deatiée Dans ce qui suit, nous allons développer de fagon plus détaillé les méthodes 4 géeompoition et de epéieation des programmes. Nous presenerons at s mi applicables aux gros programmes” séquentiels, puis nous essaierons de les généraliser aux cas ol le parallélisme intervient, 7.31 PROGRAMMES SEQUENTIELS Test généralement admis quela complexité dela réalisation d'un programme Gans chercher définir précisément cette notion) croit beaucoup plus rapi dement que le nombre d'instructions de ce programme, Dans ces conditions, Sion parvient a décomposcr la réalisetion d'un programume d'une part en la réalisation un ensemble de parties plus simples et d'autre part, en Tassem- blage de ces parties, on aura réduit la complexité globale de Topération. ‘Nous allons examiner deux méthodes de décomposition 7.311 Modules La decomposition d'un programme en modules est considérée comme classique depuis la réalisation de TOS/360 (Mealy, 66]. Un module est un « morceau de programme » a plusieurs entrées et plusieurs sorties pouvant réaliser un ensemble de fonctions. La décomposition offte les avantages suivants : — simplification de la conception : on peut définir P'abord la fonction ralisée par chaque module et ses relations avec les autres modules ; on ne Sintéresse qu’ensuite & la realisation des différents modules, = faclité de modification du programme par remplacement de modules : la réalisation de chaque module est indépendante de la realisation des autres, — accétération de Vimplantation si on peut affecter une équipe & la réali- de chaque module, — ceélération de la mise eu point. 1) Décomposition en modules ‘On ne connait pas de méthode générale de dévomposition des programmes (On doit done s'appuyer sar Pexpérience, c'estidire suivre dans la pratique une démarche essai-échec-nouvelle décomposition. On demande généralement 286 Systemes dexploitaion der ordnatenrs 4 une décomposition les qualites suivantes — la taille présumée de chaque module doit étre assez petite pour que le réalisation d'un module puisse ire confige & une équipe réduite, voire & une seule personne, —si l'on représente par un graphe les interactions entre modules (les modules étant des sommets, les arcs orientés représentant les appels d'un module per un autre), ce graphe doit étre le plus simple possible pour faciliter Ja démonstration de la valiité du sysieme. ‘Chaque module obtenu par décomposition peut Iuisméme, Sil est trop complexe, faire Vobjet d'une nouvelle décomposition, 2) Spécifications d'un module. Interface Une décomposition en modules doit s'accompagner d'une spécification précise et complete dela fagon dont le module se comporte visd-vis des autres modules. Une telle spécification est appelée interface. Pour conserver les vantages de Ia décomposition, et en particulier permetize le remplacement d'un module par un module de méme interface, il est impératif qu'un module donné ne soit accessible aux sutres modules qu’en utlisant son interface, Un programme appelant un module ne doit pas, en particulier. exploiter des renseignements sur la réalisation interne du module qui ne font pas partie de Uimterface. Une facon efficace de parvenir & ce but (Parnas, 71) consiste & faisser les programmeurs d'un module dans ignorance de la réalisation des autres (cette méthode autoritaire pouvant sans doute étre remplacée par une auto-discipline des programmeurs) Une définition plus formelle des notions de module et d'interface est pro- posée dans [Parnas, 72]. Un moduie est considéré comme un dispositif pouvant se trouver dans un certain nombre d'états. Chaque état est défini par les valeurs d'un ensemble de variables d'état. Les changements d'état sont provoqués par Fappel de procédures d'utilisation (avec ou sans paramétres). Linterface ‘est définie comme ensembledes veriablesd état ct des procédures d'utilisation. Les variables d'état peuvent étre consultées, mais ne peuvent tre modifites {que par 'appel des procédures d'utilisation; le donnée de leurs valeurs initiales fait partic de Vinterface. Le module peut comporter en outre des procédures et des variables internes, inaccessibies de Vextéricur du module, mais qui Peuvent apparaitre dans les procédures d'utilisation. Le traitement des cas erreur (ntilisation incorrecte du module) doit etre envisage. Une solution possible consiste & prévoir lors de la programmation du module tous les cas possibles d'erreur et & appeler dans chaque cas une procécure approprite extérieure au module. Ces procédures d'errour doivent aire spéeifiées au moment de Tappel du module. Exemple. Module de gestion d'une pile [Paraas, 72) (On défnit ici es spécifications d'un medule chargé de In gestion d'une pile. L'nter- face du module est défiie comme suit:Méthodclogie de conception et de réalisation 287 Variables | Type | Valeur initials sommer | enter il hautcer | enter o Procidures | Paramitres Bier empiler(a) | ontiera | = hauteur = max ‘lors er! sinon ‘but sommet = a; Faeur = heaeur + 1 fin ‘esempiler — | shaw = 0 alors err2: Ta séquence (empiler(a) : dksempler) quivautd une acion vie $i n'y fa pas d'appel de err ‘max est Ia hauteur maximal de la ple, e71.err2 sont des proctdures erreur, empier et dsempier sont les fonctions de changement dist; les variables d'état sont scmmer (valeur courante de Télement ex sommet de pile) et hawiew (nauteur courente de pile). La valeur mil correspond i une pile vide. Remarque. La défnition implicite de la forction dévempiler pout & premiére we surpreadre ‘ele a en fait &4érbduite au sect tinimum nécessire pour éviter toute hnypothise sur le mode de realisation du module. En effet, une definition explicite de esempiler nécesieralt Cexplicter le mécanisme ce passage d'un élément de la pile au suivant et au precédent, mécanssme qui dott reser inconnu 4 'extérour du module [Le mode de spécification ici utilisé a deux avantages — liste toate liberé au réslisateur pour la gestion interne de la ple (table, liste chaiaée, ..) = éviter que kes utlsateurs du module uilsent (voite modifint) les variables du module autrement qu'a travers interface. 7.312 Niveax La décomposition en niveaux (Zurcher, 68; Wirth, 71 ne différe pas fondamentalement de I méthode précédente : on se restreint 4 des découpages en modules tels que le graphe des interactions soit sans circuit, ‘On peut alors claster les différents modules par niveaux numérotés dans TTordre des enticrs naturels de la fagon suivante — au niveau J, on place les modules qui n’en appelient aucun autre, 12 niveau 2, les modules qui n’appellent que des modules du niveau J, appelient que des modules des niveaux 288 Systémes dexploitation des ordateurs Si on se place 4 un niveau donné, Fensemble des fonctions introduites 4 ce niveau définit un langage ou, ce qui revient au méme, une machine. Les modules de niveau inférieur aur niveau considéré forment linterpréteur du langage (ou implantation de la machine); les modules de niveau supérieur forment un programme écrit dans ce langage (ou s'exécutent sur cette machine). Le systéme luiméme fournit a ses utilisateurs un langage ou une machine. (On peut utiliser la conception par niveaux pour simuler des ressources virtuelles a partir de ressources physiques. Ces ressources virtuelles peuvent ‘tre utilisées & des niveaux supérieurs a celui de leur définition. Les commen- taires du 7.311 sur la définition et Pimerface des modules resient valables De plus, maintenant, on dispose de deux approches pour définir le décou- page : — conception descendante (« stepwise refinement ») : on part du résultat que Toa soubaite obtenir et on définit par éapes Son implantation ; & chaque étape, certaines fonctions sont complétement définies alors que limplantation des autres reste floue et scra prévisée dans une étape ultérieure, — conception ascendante : on part de la machine réelle et oa construit des modules qui étendent progressivement son jeu d’instructions et de données pour obtenir unc machine de plus en plus proche de celle désirée. ‘Comme la mise en @uvre d'une seule de ces approches est délicate (et ‘demande en tout cas une grande expérience de la conception de programmes comparables), on procéide dans la pratique alternativerent de haut en bas et de bas en haut, jusqu’a ce que 'on obticnne une solution convenable; par contre, la programmation se fait généralerment de bas en haut : on met d'abord au point les modules du niveau J, puis on intégre ceux du niveau 2 et ainsi de suite.