Ingénierie du logiciel : allons-nous vers des systèmes plus fiables ?

05/09/2017
Publication REE REE 2005-11
OAI : oai:www.see.asso.fr:1301:2005-11:19814
DOI : You do not have permission to access embedded form.

Résumé

Ingénierie du logiciel : allons-nous vers des systèmes plus fiables ?

Métriques

16
4
3.75 Mo
 application/pdf
bitcache://1e7978a5fa55049bd4d1c741c610be445d537f49

Licence

Creative Commons Aucune (Tous droits réservés)
<resource  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns="http://datacite.org/schema/kernel-4"
                xsi:schemaLocation="http://datacite.org/schema/kernel-4 http://schema.datacite.org/meta/kernel-4/metadata.xsd">
        <identifier identifierType="DOI">10.23723/1301:2005-11/19814</identifier><creators><creator><creatorName>Thomas Lambolais</creatorName></creator><creator><creatorName>Olivier Gout</creatorName></creator></creators><titles>
            <title>Ingénierie du logiciel : allons-nous vers des systèmes plus fiables ?</title></titles>
        <publisher>SEE</publisher>
        <publicationYear>2017</publicationYear>
        <resourceType resourceTypeGeneral="Text">Text</resourceType><dates>
	    <date dateType="Created">Tue 5 Sep 2017</date>
	    <date dateType="Updated">Tue 5 Sep 2017</date>
            <date dateType="Submitted">Sat 17 Feb 2018</date>
	</dates>
        <alternateIdentifiers>
	    <alternateIdentifier alternateIdentifierType="bitstream">1e7978a5fa55049bd4d1c741c610be445d537f49</alternateIdentifier>
	</alternateIdentifiers>
        <formats>
	    <format>application/pdf</format>
	</formats>
	<version>33612</version>
        <descriptions>
            <description descriptionType="Abstract"></description>
        </descriptions>
    </resource>
.

1 1 1 SÛRETÉ DE FONCTIONNEMENT DES SYSTÈMES À FORTE COMPOSANTE LOGICIELLE Ir a m m m a Ingénierie du logiciel : allons-nous vers des systèmes plus fiables ? Mots clés Génielogiciel, Modélisation, Validation, Vérification, Fiabilité ParThomas LAMBOLAIS,01vier GOUT École des mines d Alès Laboratoire de génie informatique et d'ingénierie de production Si le logiciel se retrouve de plus en plus dans les systèmes actuels, qu'en est-il de sa fiabilité ? Cet article fait le point sur les méthodes, techniques et langages proposés ces dernières années pour limiter le nombre de défaillances logiciel les des systèmes. 1. Contexte Dans le cadre des systèmes totalement ou partiellement automatisés, allant des équipements électroménagers en apparence simples (lave-linge ou éléments hi-fi et vidéo) aux systèmes dits critiques, tels que des véhicules particuliers ou collectifs, la part du logiciel et de l'élec- tronique embarquée est de plus en importante, sinon en poids ou en volume, du moins en coût, par rapport à celle du matériel dit traditionnel (composants mécaniques). On estime par exemple que le coût des développements logiciels sur une frégate militaire de la Marine française atteint, voire dépasse les 60 % du coût de développement total. Dans le même temps, la confiance que l'on accorde au logiciel ne progresse pas : « le logiciel est toujours buggé ». Des utilisateurs s'étonneront vraisemblablement que leur dernier four micro-ondes flambant neuf ait un comportement erroné ; en revanche personne ne s'étonnera vraiment si le dernier jeu vidéo acheté ne s'installe ni ne marche correctement du premier coup. D'ailleurs, souvent, les vendeurs eux-mêmes n'en assumeront pas la responsabilité et vous diront simplement de télécharger les correctifs sur internet. En général, la licence des systèmes d'exploitation courants des ordinateurs particuliers décline toute responsabi- lité du fournisseur en cas d'endommagement de données et de matériel lors de l'utilisation ou de l'impossibilité d'utiliser le logiciel... En tout état de cause, la responsabilité du fournisseur ne dépassera pas le montant du logiciel [2]. Des compagnies célèbres ont su tirer ainsi profit de ce qu'elles considèrent (pour elles) l'âge d'or du logiciel, où il est possible de développer assez rapidement des logiciels à faible coût, en demandant à l'utilisateur d'accepter leurs possibles défaillances, ainsi que toutes les conséquences possibles de telles défaillances, en lui demandant tout en même temps de signaler toutes ces défaillances (pourquoi ne jouerait-il pas en plus le rôle de testeur ?), puis en lui demandant encore d'acheter les correctifs. Dans ce contexte grand public, on peut penser que si le logiciel n'est pas fiable, ce n'est pas uniquement parce que sa ESSENTIE Ces dernières décennies, le génie logiciel a proposé concepts, langages,méthodes, outils pour concevoir des systèmes, mais aussi pour les analyser, les vérifier et globalement chercher à garantirleur validité.Nous présentonsici les principales solutions exploréeset nous analysons leurintérêt en terme de fiabilité : il s'agit soit de solutions de modélisation depuis les premières phases du développementjusqu'aux phases de conception, de réalisationet d'exploitation,soit de techniques de validationparle test ou de techniques de vérification par des modèles formels. L'un des enjeux actuels consiste à coupler davantage les tech- niquesde validationet vérificationà celles de modélisation. SYNOPSIS These last decades, Software Engineering has proposed concepts, languages,methods, andtools to design,analyse,veri- fy and validate systems. We present here themainsolutionsand analysethem in term of reliability: these are either modelling solu- tlons, from the first development phases to design, realisation, and exploitation phases, or test validationtechniques and verifi- cationtechniquesby meansof formal models.Oneof the current challengesis to combine more closelysuch modellingtechniques with verificationand validationtechniques. REE N°H Décembre2005 Ingénierie du logicie : allons-nous vers des systèmes plus fiables ? complexité est telle que l'on ne sait pas maîtriser son développement ; c'est aussi pour des raisons de stratégie économique. Pour des systèmes critiques où la santé des utilisateurs est en jeu, et aussi où des organismes de certification doivent garantir une certaine qualité des produits, les techniques déployées pour satisfaire une certaine sûreté de fonctionnement sont différentes. Bien que faisant appel à plusieurs techniques de vérification et de validation (ces deux termes seront définis par la suite) a priori et a posteriori, même après de longues phases de déverminage (débuggage), de tels systèmes ne sont jamais considérés comme exempts d'erreurs : plusieurs solutions de redon- dance matérielle et logicielle sont ainsi mises en oeuvre. Cet article vise à faire le point sur les techniques actuelles et celles explorées ces dernières années dans le domaine du développement de logiciels de qualité, et en particulier dans le domaine de la fiabilité du logiciel. 2. Qualité du logiciel L'image de non-fiabilité du logiciel telle qu'elle est répandue dans le grand public trouve son origine dans les failles effectives des produits couramment utilisés, mais aussi dans des échecs célèbres. L. R. Wiener dans son livre « Les avatars du logiciel » [41 illustre paifaitement ce problème. On peut en citer deux exemples, repris également dans le cours de génie logiciel du professeur Jean-Pierre Fournier à l'école d'ingénieurs de Genève : . Le 22 juillet 1962, un programme qui comportait une omission mineure dans une équation coûta 18,5 millions de dollars au contribuable américain, parce qu'on détruisit par erreur une fusée Atlas- Agena. Cette fusée transportait la sonde Mariner 1 destinée à l'exploration de Vénus. Cette équation servait au système de guidage informatique. Il y manquait une « barre », un trait horizontal sur un symbole indiquant qu'il fallait utiliser des valeurs moyennes, et non pas des données brutes. L'absence de barre amena l'ordinateur à conclure que la fusée se comportait bizarrement, alors que ce n'était absolument pas le cas. Lorsque l'ordina- teur chercha à rectifier une situation qui n'exigeait aucune correction, il provoqua un comportement réellement imprévu, et la fusée a été détruite pour préserver les habitants de Cocoa Beach. 'A la fin juin et au début juillet 1991, une série de coupures affectèrent les abonnés au téléphone de Los Angeles, San Francisco, Washington, Baltimore, Virginia dans l'Etat de Virginie et Greensboro en Caroline du Nord. Les incidents provenaient d'un programme de commutation rédigé par une entreprise du nom de DSC Communications. Leur logiciel de routage d'appels comportait plusieurs millions de lignes de code (à raison de soixante lignes par page et cinq cents pages par volume, un million de lignes représente trente-trois gros livres de chevet.) Le programme avait été testé pendant treize semaines et marchait très bien. Puis ils procédèrent à une légère modification. Trois lignes, pas une de plus, sur ces quelques millions furent touchées. Ils estimèrent qu'il n'y avait pas lieu de soumettre de nouveau le logiciel aux treize semaines de test. Ils connaissaient les consé- quences exactes de ces modifications, et étaient convaincus qu'il n'y en avait pas d'autres. De plus, on peut supposer que le client voulait son produit sur-le-champ. Ils expédièrent donc leur programme de plusieurs millions de lignes, qui divergeaient de la version testée par trois lignes seulement, et il se bloqua à plusieurs reprises. 2.1. Crise du logiciel Non seulement « les logiciels sont toujours buggés » I mais « les coûts et temps de développement [logiciel] sont toujours multipliés par un facteur allant de 2 à... ». Depuis le congrès de Garmisch en novembre 1968 [6], le constat de la crise et de la non-maîtrise du logiciel a été réalisé. Ce congrès a marqué le début d'une nouvelle approche destinée à apporter plus de rigueur et plus de solutions à des problèmes récurrents dans les développe- ments logiciels. On peut ainsi précisément dater le début du génie logiciel à la fin des années 60. Durant les trente-cinq dernières années, le génie logiciel a proposé langages, techniques, outils et méthodes pour le développement, la validation et la maintenance de systèmes logiciels. Mais il ne faut pas perdre de vue qu'au regard d'autres disciplines d'ingénierie (génie chi- mique, génie civil, génie électrique voire électronique), cette discipline est encore très jeune : de nombreuses propositions variées et concurrentes ont vu le jour, basées sur des concepts et des paradigmes différents, parfois incompatibles. De manière évidente, le temps n'a pas encore fait son ouvrage : le tri dans l'ensemble des solutions proposées reste encore en grande partie à réaliser. 2.2. Critères de qualité Dans la première partie de son ouvrage de 1990, « Conception et programmation par objets, pour du logiciel de qualité » Bertrand Meyer présentait plusieurs prin- cipes de programmation devant aider à conduire les concepteurs et développeurs de logiciels à produire du code de meilleure qualité. Globalement, il ne faut pas oublier que la qualité la plus importante d'un logiciel, tout comme d'un système quelconque, est avant tout de répondre aux besoins de son futur utilisateur. Nous par- lerons alors d'un système valide, c'est-à-dire un système REE N°H Décembre2005 Dossier ) 1 1 1 SÛRETÉ DE FONCTIONNEMENT DES SYSTÈMES À FORTE COMPOSANTE LOGICIELLE i) ,v vO U Ji 1.. 1 Jj l,. w i i ta wM t./,- !-< '/-< t' rt t \./'. ".. : . Teipz Temp,,dé\'crma.c' !j :.rc Temps cCt. ob;.;jctc Temps .ij'itc.p.r'ad': Défaillancesm3t:eneUes DéfaillanceslogicieUes Figure 1. Évollitioiî des taux de déftiillance iiicitériel et logiciel génércileinent constatés. conforme à ce qu'on attend de lui. Parmi les attentes sou- haitées, cette conformité se décline en plusieurs aspects : . le respect des fonctions et des services attendus ; . les qualités elles-mêmes de ces fonctionnalités (que l'on appelle souvent les non-fonctionnalités) : - l'ergonomie, ou facilité d'utilisation ; - les performances telles que les temps de réponse et d'exécution, ou encore la gigue (synchroni- sation entre différentes applications temporisées, comme l'image animée et la parole) : - la précision des résultats ; - la maintenabilité et l'évolutivité ; - et enfin la sûreté de fonctionnement, regroupant : - sûreté : fiabilité, robustesse, disponibilité ; - sécurité : sécurité-innocuité (aptitude du système à ne pas engendrer de catastrophes) et résistance aux malveillances (virus, intrusions...). Il est très clair que plusieurs qualités internes du logiciel peuvent contribuer tout à la fois à sa sûreté et à sa main- tenabilité : par exemple, la lisibilité et la modularité du code permettront de faciliter la détection des erreurs de programmation, et aussi sa maintenabilité. En particulier, Bertrand Meyer insistait sur la modularité et son expression dans les langages orientés objet. Après maintenant un recul de quinze ans sur l'utilisation des langages de programmation orientée objet, et plus récemment les langages de iiiodélisation objet, nous reviendrons aux paragraphes 3.3.1 et 3.3.2 sur l'apport effectivement acquis en termes de fiabilité grâce à l'utilisation du para- digme objet.CD 2.3. Notion de fiabilité Il ne viendrait à l'idée d'aucun utilisateur censé de dire qu'un produit lui convient (et donc est valide) si celui-ci n'est pas sûr, ou tout au moins, suffisamment sûr. En particulier, nous nous intéressons dans la sûreté à la notion de fiabilité, c'est-à-dire à l'absence de défaillance en conditions normales d'exécution. Plus exactement, en suivant la définition donnée dans le numéro de décembre 2004 de cette même revue [14], la fiabilité est vue comme la probabilité d'absence de défaillance à un moment donné de la vie du système. Une défaillance est vue comme la conséquence d'une erreur du système, elle-même faisant suite à une faute externe (par exemple une mauvaise utilisation) ou interne (par exemple une,faute de programmation). Les notions, le vocabulaire et parfois les techniques pour traiter la fiabilité dans les domaines du matériel et du logiciel sont semblables. On constate cependant géné- ralement une différence en ce qui concerne l'évolution des taux de défaillance d'un système matériel et d'un système logiciel. La figure 1 illustre cette différence, essentiellement due aux lois de la physique, qui s'imposent aux domaines de la mécanique, de l'électronique ou bientôt des nanotechnologies. Il apparaît que le matériel, passé sa durée de vie utile, vieillit et se dégrade de plus en plus vite. A l'inverse, le nombre de défaillances logicielles ne cesse de décroître : nous pourrions être tentés d'en conclure que le logiciel ne vieillit pas, ou alors qu'il ne cesse de se bonifier dans le temps. En réalité, cette courbe correspond au cas favorable où le logiciel, bien qu'obsolète, est encore maintenu.ou c D'après Bertrand Meyer, il convient bien de parler de vieillissement, y compris dans le cas du logiciel. 2.4. Maintenabilité et notion de vieillissement du logiciel En apparence, le logiciel, de par sa nature immatérielle, tout comme une idée ou un concept, ou comme un résultat mathématique (proposition ou théorème) n'a pas lieu de s'user ; tout au plus pense-t-on qu'il peut se démoder. Il y a pourtant lieu de parler d'usure et de vieillissement logiciel. La maintenance effectuée sur le logiciel peut concerner soit l'ajout de nouvelles fonctionnalités et/ou l'amélioration des fonctionnalités existantes, soit la cor- rection de failles qui auraient dû être évitées ou détectées avant la commercialisation du produit. Comme l'appellation anglophone (software) le sou- ligne, le logiciel est quelque chose de flexible, c'est-à-dire REE No Il Décembre2005 Ingénierie du logiciel : allons-nous vers des systèmes plus fiables ? d'évolutif et d'adaptable. Cela présente des facilités de maintenance évidentes : il suffit de demander aux utilisateurs de télécharger des correctifs. Dans le cas de logiciel embarqué, seule une équipe spécialisée peut intervenir, mais les coûts restent encore bien inférieurs à ceux d'une maintenance matérielle. Mais la flexibilité du logiciel entraîne des difficultés de conception et de prévision des évolutions supplémentaires. Un logiciel, durant sa durée de vie, peut être conçu pour évoluer, par exemple pour apprendre et se modifier. Cela se décrit facilement dans des langages de programmation fonctionnels, par exemple, où le résultat d'une fonction peut être lui-même une fonction : le programme s'enrichit d'une nouvelle connaissance. Cette caractéristique d'auto-adapation n'est pas limitée à ce type de langages, ni aux applications d'intelligence artificielle, comme on pourrait le croire, où un programme de jeu d'échecs, par exemple, s'enrichira de l'expérience acquise. Dans une autre mesure, un système d'exploitation évolue régulièrement, ne serait-ce que par l'ajout de nouvelles librairies et de nouveaux éléments logiciels des différents composants matériels qu'il contrôle. De telles évolutions sont souvent source de nouvelles erreurs. Cette flexibilité peut donc également devenir synonyme d'usure ou de dégradation. 2.5. Nature des défaillances dans le cycle de déve- loppement : vers l'ingénierie des exigences Indépendamment des effets qu'elles peuvent avoir, on distingue deux types de défaillances : . les défaillances dont l'observation est aléatoire, qui peuvent trouver leur source au niveau de la pro- grammation (bug, voire défaillance de l'environne- ment de programmation lui-même) mais aussi au niveau de la plateforme matérielle. Ce sont en général des erreurs de bas niveau au regard du cycle de développement ; . les défaillances systémcatiques, dues à une erreur de conception voire d'analyse, de plus haut niveau que les précédentes. Il apparaît ainsi que l'origine des erreurs dans le cycle de développement, selon qu'il s'agisse d'erreurs amont ou plus tardives, se traduit par des défaillances différentes, et dont les coûts de réparation varient grandement. En particulier, la correction d'une erreur en phase d'analyse ou de conception se révèle la plupart du temps très coûteuse, car susceptible d'entraîner de nouvelles phases de conception, implantation et test, très consommatrices en temps. Les erreurs de spécification (analyse) et de conception sont donc parmi celles qui font l'objet d'une plus grande attention dans la communauté du génie logiciel. Plusieurs études américaines et européennes [10] ont montré que les erreurs les plus amont, dès les phases d'ingénierie d'exigences, étaient non seulement les plus coûteuses, mais aussi les plus tenaces et les plus fréquentes. Il est maintenant très clair que la crise du logiciel commence en premier lieu par la non-maîtrise de l'ingé- nierie des exigences. Ici, le problème n'est pas uniquement de savoir gérer des exigences (par exemple, en assurer la traçabilité dans le cycle de développement, établir une correspondance entre les exigences et les éléments conçus pour les satisfaire...), il s'agit de savoir identifier, voire faire émerger les exigences d'un nouveau système. Les difficultés se posent essentiellement dans le cas de systèmes entièrement nouveaux, pour lesquels aucune solution de référence ne peut être copiée ou améliorée. Les difficultés sont alors de plusieurs natures. Prenons un exemple : un entrepreneur à la tête d'une société de location de films souhaite moderniser son entreprise. Il dispose de plusieurs agences distribuant chacune DVD et cassettes vidéo. Il imagine pouvoir moderniser sa solution informatique de gestion et de distribution de films grâce à l'utilisation des réseaux informatiques à haut débit, qui devraient lui permettre soit de vendre des films à télécharger, soit d'éviter la circulation des films entre agences, comme elle est actuellement réalisée par coursier. Lorsque ce type d'entrepreneur s'adresse par exemple à une société de développement informatique, il n'a pas d'idée précise de ce qu'il souhaite. Tout au mieux, ce qui est souvent le cas, pense-t-il au problème en donnant déjà un exemple de sa solution : il pense à une solution de transfert électronique de films sur un réseau informatique. La première difficulté qui se pose à la société de développement logiciel est que le problème à résoudre n'est pas clairement énoncé. La seconde difficulté est que ces deux types d'individus ne sont pas du tout dans le même domaine : le fournisseur ne connaît pas le métier du client et ne pourra pas en réaliser une analyse pertinente ; le client ne sera pas à même d'évaluer les propositions du fournisseur. Quelques méthodes d'ingénierie des exigences ont été développées, telles que la méthode KAOS (Keep All Objectives Stitisfied) d'Axel van Lamsweerde [11]. À l'image d'un client désirant faire construire un bâtiment, qui peut discuter avec un architecte sur la base de plans compréhensibles par les deux parties, une des avancées les plus nettes de ces dernières années en matière d'ingénierie logicielle a été de définir des langages amont, architecturaux, simples et intuitifs pour la présentation des plans logiciels. Une réflexion sur ces langages sera donnée au paragraphe 3.2. 2.6. Logiciel zéro-défaut ? Est-il possible de concevoir et réaliser des logicielsc totalement dépourvus de bligs ? Faites le test en deman- dant autour de vous si les gens connaissent des looicielsc de taille assez conséquente et sans aucun bug : en général les réponses ne sont pas nombreuses. Pour donner des REE N " H Décembre2005 m Dossier D 1 1 1 SÛRETÉ DE FONCTIONNEMENT DES SYSTÈMES A FORTE COMPOSANTE LOGICIELLE exemples de logiciels qui doivent s'en rapprocher, nous pourrions citer les programmes TEX et METAFONT déve-Zn E loppés par Donald E. Knuth dans les années 1970 [15], et diffusés depuis 1980. Bien que ces programmes ne soient pas réellement connus du grand public, ils constituent un logiciel de formatage de textes scientifiques utilisé par des millions de personnes, diffusé librement. Entre la version 1.0 de TEX en 1980 et la version 3.14159 de 2000, Donald Knuth considère que presque toutes les erreurs de TEX ont été corrigées, et que les améliorations futures de TEX ne seront que mineures (en effet, si le numéro de version atteint désonnais la cinquième décimale, c'est que le programme ne pourra plus changer que d'un millionième). Le logiciel TEX n'a certainement pas fait l'objet de techniques de vérifications formelles extrême- ment pointues, telles que certaines que nous allons pré- senter par la suite, bien que plusieurs de ses algorithmes aient été prouvés, mais son auteur a fait preuve d'une rigueur et d'un savoir-faire extrêmes. La confiance qu'il a atteinte dans le code qu'il a produit est telle qu'il s'est enga- gé personnellement à rémunérer quiconque trouvant des erreurs dans son programme ou dans sa documentation. T EX est un logiciel de plusieurs centaines de milliers de lignes, réalisant des tâches complexes dans des temps remarquables. Cet exemple montre qu'il est possible de se rapprocher d'un certain idéal (au moins en termes de fiabilité et de robustesse, l'ergonomie et l'interface homme-machine, datant de vingt ans, n'étant plus au goût de tous) : mais son développement n'a été réalisé que par quelques personnes (Knuth a été aidé par quelques collè- gues), en demandant énormément de temps et de soins. On peut qualifier son développement d'artisanal, tant par le processus suivi que dans le résultat obtenu, à rappro- cher d'une oeuvre d'art'. Plutôt que de chercher, dans l'absolu, des pro- grammes dépourvus de bugs, la question qui se pose plusc raisonnablement est alors : disposons-nous actuellement ou disposerons-nous bientôt de techniques de conception et de développement industrielles de logiciels fiables ? 3. Ingénierie du développement de logiciels fiables Par techniques industrielles, il faut entendre des techniques économiquement viables, développant des systèmes dans des délais et à des coûts acceptables, par des équipes souvent amenées à évoluer. Il est clair que le cas du logiciel TEX n'entre pas dans cette catégorie.c b La première solution à laquelle on pense logiquement pour limiter le nombre de défauts d'un système, qu'il soit logiciel ou non, est d'intensifier les phases de tests et de correction. Malgré une ingénierie de développement aussi soignée que possible, il serait en effet utopique d'imaginer de pouvoir construire du logiciel entièrement a priori sans défaut. 3.1. Test de systèmes logiciels Les techniques de test sont aussi anciennes que celles de programmation. Tester un système ne signifie pas seu- lement l'essayer ou l'exécuter ; il s'agit de confronter le système à des scénarios judicieusement établis dans le but d'y trouver des erreurs (anomalies, non-conformités...). On comprend aisément qu'une validation par le test ne permettra jamais de garantir entièrement la correction ou la validité d'un produit : . d'une part l'ensemble exhaustif des tests à faire passer est en général infini ; . d'autre part, ne sachant pas a priori si un produit est déterministe, c'est-à-dire s'il se comporte toujours de manière identique lorsqu'il est soumis à des entrées identiques et dans des conditions d'exécution identiques, il est nécessaire de faire passer plusieurs fois les mêmes tests. Il est donc nécessaire de sélectionner avec soin les tests à faire passer. Cela se fait en général grâce à deux hypothèses : . l'hypothèse d'uniformité sur les données manipu- lées et acceptées en entrée, . l'hypothèse de régularité sur le comportement. Cela revient à s'appuyer sur une supposée continuité du système, en testant par exemple : les valeurs limites, les entrées aberrantes (test de robustesse), et un certain nombre de cas nominaux. Comme l'explique Hoare [12], ce schéma de test correspond à la figure 2 suivante. L " "' hucn'al accepté !. " ! - Lntemal .* k ! i - acccpté ', >C i 9< "/ ! x " ! -X X lx '' ! X,/Ré,Llltat.,...l "/,. X- " I ·..' escomptê .; 1 l'1 ""'" " X 1 ,. " 1,. ""./i i X i. ", 1 i i i i i X-- escorlipte Figure 2. Réjoiises dtiii s-,,stèi ; ie à desjeilx d ( test, (ejitrées) cloiiiié,. 1 C'estpendantl'écriture de sescélèbresvolumesdeTheArt oj'Coîiplitei- Pi- ( ? gi- (iiiiiiiiig,versla fin desannées1960,queDonaldKnuth a décidé d'entreprendrela réalisationdece programmedevantlui permettred'éditer lui-mêmesesformulesmathématiques: il s'estavéréqueTeX allaite êtrepluspuissantqu'initialement prévuet lui permettrade formaterl'intégralité de sesderniersouvragesscientifiques.Knuth a étérécompenséc parle prix Turing en 1974. REE Wll Décembre2005 Ingénierie du logiciel : allons-nous vers des systèmes plus fiables ? Les équipes de tests pensent dans tous les cas à solliciter le système en dehors de la plage des entrées pour lesquelles il est conçu, et choisissent judicieusement un ensemble d'entrées dans la plage de fonctionnement normal. On imagine alors, ou on suppose, que le compor- tement réel du système correspond à la courbe en poin- tillés passant par les points testés,en extrapolant des valeurs intermédiaires plausibles. Ces techniques de tests ne sont pas totalement spécifiques au logiciel, elles sont notam- ment largement déployées dans le cas des circuits élec- troniques. Mais cette approche de test fait l'hypothèse que le système est continu. Or les systèmes informatiques sont parfois très discontinus (une seule instruction peut changer tout un programme). En réalité, la courbe effec- tive reflétant le comportement du système logiciel peut très bien correspondre à celle de la figure 3. répon se s i/t rT' ; ! ; t.'v/i j) \ 1 A ; \--'- " -/" ' ÀL i , 1 i " i i 1 , l' i 1 i i 1 i l' i 1 ,Ii e/llrées (ld ! llise. eJllrén Réponse réelle Figtire 3. Réponse effective dbi sy.tèiiie. Une démarche complémentaire au test s'avère indis- pensable. Les autres solutions investiguées ces dernières années pour améliorer la fiabilité des systèmes logiciels reposent toutes sur l'utilisation de modèles, dans les dif- férentes phases du développement. 3.2. Langages et méthodes formelles Dans les années 80 et 90, les langages et méthodes formelles ont été étudiés dans le but de chercher à vérifier formellement des modèles des systèmes. Par formels, nous entendons des langages dont la sémantique est définie de manière suffisamment précise pour que la manipulation (exécution, transformation, évaluation, comparaison...) des textes du langage ne nécessite plus aucune interpréta- tion humaine : par la manipulation de la forme seule, des résultats peuvent être obtenus. Dès lors, il devient imagi- nable de demander à un ordinateur de vérifier, au moins partiellement, les systèmes. Les techniques de vérification proposées se distinguent en deux grandes familles : 'la vérification de propriétés (model-checking). l'ensemble des configurations et des états du système est analysé pour savoir si une propriété y est satisfaite. Plusieurs techniques de vérification permettant d'éviter un parcours systématique de tous les états possibles du système ont été développées, de manière à pouvoir appréhender des systèmes complexes de taille importante. Cette solution de vérification présente l'avantage d'être totalement automatique. Il « suffit » d'écrire la propriété à vérifier et le véri- ficateur conclut seul en renvoyant un verdict : soit la propriété est satisfaite, soit elle est violée et un scénario d'échec est exhibé. L'inconvénient de cette approche est qu'elle est assez rapidement limitée par la taille et la complexité des modèles du système ; 'lapreuve de théorèmes : les propriétés que le modèle doit satisfaire sont établies ou non en s'appuyant sur des hypothèses et des règles de transformation, exactement comme une preuve se construit « à la main ». Les prouveurs actuels permettent d'établir automatiquement plus de 95 % des propriétés, et sont d'une aide précieuse pour les propriétés ne pouvant être que partiellement prouvées. L'avantage de cette technique est qu'elle permet de prendre en compte des modèles complexes, mais elle demande une expertise certaine de la part des utilisateurs. Les techniques formelles ont été investiguées dans toutes les phases du développement logiciel : de la phase d'ingénierie des exigences (la méthode KAOS se base sur la logique temporelle) aux phases finales de test. Mais c'est principalement dans les étapes amont (spécification, analyse et conception) qu'elles ont été le plus étudiées. De manière simplifiée, les langages formels peuvent se classer en plusieurs familles : . logiques : logiques modales, d'ordre supérieur, logiques temporelles ; . langages algébriques : typesabstraits algébriques, algèbres de processus, . langages comportementaux : machines à états, réseaux de Petri ; . approches ensemblistes, telles que les langages Z et méthode B. Le principe de l'utilisation de langages formels pour la vérification d'un système est présenté à la figure 4. L'idée est d'étudier sur des modèles simplifiés si la solution de réalisation proposée répond aux exigences. Cela correspond à des vérifications de cohérence externe. Les exigences peuvent être formalisées dans le même langage ou un autre langage que la réalisation. Bien que, lors de la construction du système réel, son environnement d'exécution (réseau, ressources, utilisateurs...) ne soit en général pas construit, les travaux de vérification doivent intégrer cet aspect. Nous pouvons alors poser l'équation à vérifier sous la forme suivante : R Il E = S REE ? il Décembre2005 M Dossier 1 1 1 SÛRETÉ DE FONCTIONNEMENT DES SYSTÈMES À FORTE COMPOSANTE LOGICIELLE INFORMEL Client Idée Souhaits Vnliclutinn de lu réalisation n'elle Cahier des charges [ " alidcilioii dit iiiodèl ( construction ----------- Réalisation i'alidcitioti dit iiiodile <--1-- Environnement Validatioa dumodèlef/Jf/J? FORMEL VérificaTion de lu cohérence interne Modèle de la spécification : S 1 > 1 t Vérification : (R Il E) satisfait-il S ? Modèle de la réalisation : R Modèle de l'environnement : E Figure 4. Schéiiia d,il) llication des niéthodes foi-nielles potir la vérification. où R est un modèle de la réalisation, S est un modèle des exigences et E est un modèle de l'environnement. R ? t ! E désigne l'exécution parallèle du système dans son environ- nement, partageant ensemble des ressources. La relation d'équivalence notée classiquement = est utilisée pour savoir si les propriétés de la spécification sont satisfaites par le système dans son environnement d'exécution. Évidemment ces notations peuvent varier d'un langage à un autre. La représentation choisie ici s'inspire de celle définie par Robin Milner dans ses langages CCS (Calculus ofCommunicating Systems) et dans le -calcul [9]. Les méthodes formelles ont conduit à certains succès (dans le cas de la méthode B, on cite souvent pour cela l'exemple de la ligne 14 du métro parisien [5]), mais leur utilisation dans le milieu industriel reste encore timide. Leur coût d'apprentissage est assez important, mais surtout elles présentent encore plusieurs limitations : la plupart des environnements de vérification formelle sont d'origine académique, et peu d'outilleurs logiciels ne les ont vérita- blement intégrées à un outil au standard industriel (bien entendu, depuis 1990, plusieurs tentatives ont été réalisées, mais avec un succès modéré) ; leur utilisation permet de détecter de nombreuses erreurs (interblocages, exécutions infinies...), mais il s'agit essentiellement d'une vérification fonctionnelle ; enfin, elles se basent entièrement sur la construction de modèles coûteux à développer (le dévelop- peur a l'impression de réaliser le travail en double) et surtout coûteux à valider : il est indispensable ensuite de s'assurer que les modèles réalisés représentent fidèlement la réalité. Enfin, il faut remarquer que l'utilisation de méthodes formelles, qui correspond à un travail théorique, ne garantit jamais véritablement les propriétés attendues du système réel : la validité des modèles sur lesquels elle repose exige un travail de nature informelle. Ce dernier peut être conduit par des simulations, animations ou relectures. La véritable question ratique, qui consiste à savoir si le sys- tème effectivement construit satisfait les besoins de ses utili- sateurs, ne reçoit malheureusement, par l'utilisation de ces méthodes, qu'une réponse partielle. Comme elles ne dispen- sent pas d'utiliser des techniques de validation classique (simulation, test), on comprend pourquoi leur utilisation à grande échelle dans le monde industriel reste limitée. 3.3. Langage de modélisation unifié : quel gain pour la fiabilité ? La notation UML (Unijied Modeling Language) proposée depuis 1996 répond à la première critique formulée sur les méthodes formelles, à savoir leur complexité et l'impos- sibilité qui en résulte de les utiliser comme langage de communication, notamment entre clients et développeurs, comme dans l'exemple présenté au paragraphe 2.5. UML n'a pas à la base été pensé pour concevoir les systèmes en termes de fiabilité. Son origine vient des notations de modélisation variées proposées entre 1980 et 1995. Devant la diversité des notations que l'on pouvait dénombrer en 1995, le consortium OMG (Object Management Group), regroupant plus de quatre cents acteurs industriels et académiques du monde « orienté-objet », a décidé de fusionner plusieurs notations et de proposer un langage de modélisation unique. Les origines multiples d'UML se retrouvent dans ses différentes facettes, permettant à ses utilisateurs de décrire REE N°i ! Décembre2005 Ingénierie du logicie allons-nous vers des systèmes plus fiables ? plusieurs vues d'un système : UML s'est ainsi doté de notations pour représenter les exigences, fonctions et services attendus, pour décrire les concepts et entités du système, leur comportement, et leurs projections sur des solutions matérielles et des réseaux. Ces notations sont essentiellement graphiques, et se veulent intuitives. La compréhension de certains diagrammes peut se deviner, ce qui permet effectivement à des clients non experts de donner un retour sur les modèles proposés par les développeurs. Tout au moins cela est-il vrai pour les modèles amont, ceux décuvant le domaine d'application et les grandes fonctionnalités attendues. Avant d'évaluer l'apport des approches orientées objet pour la fiabilité du système, revenons sur les caractéristiques principales de la notion « d'objet ». 3.3.1. Orientation objet La programmation orientée objet a connu un véritable engouement depuis 1980. Des langages purement objet ont été proposés, tels que Simula, Smalltalk, Eiffel [8] ou plus récemment C#, alors que la plupart des langages de programmation classiques se sont vus doter d'une extension objet : le langage C avec C++, le langage ADA avec ADA 95, le langage Pascal (diverses variantes objet existent), PHP, et même les langages fonctionnels tels que LISP ou ML qui connaissent également leur variante objet. Le succès du langage Java tient aussi en partie dans ses caractéristiques objet. Pour évaluer l'apport des objets en terme de fiabilité, revenons sur ce concept. La littérature est abondante sur le sujet, et il peut être délicat de cerner son intégralité en quelques lignes. Un objet est une entité, passive ou active, avec laquelle il est possible d'interagir en lui envoyant des messages. Ces messages sont la plupart du temps des opérations que l'on demande à l'objet de réaliser ; dans le jargon objet, on les appelle des méthodes. La notion d'objet est ainsi aussi générale que celle définie dans le langage courant : un objet peut être soit une entité concrète telle qu'un stylo, une voiture, une chaise (le singulier est important ici : ce n'est pas la notion de voiture qui constitue l'objet, mais bien une voiture donnée) ; soit une entité abs- traite telle qu'une liste, un graphe, un point d'un plan, etc. La plupart des langages orientés objet sont des langages de classes, où les ensembles d'objets que l'on choisit de définir ou d'utiliser sont construits par des classes. Une classe définit alors en quelque sorte un type de données, ou encore un concept : c'est le résultat de l'opération par laquelle on généralise un ensemble de caractéristiques dominantes et stables. Plus simplement, une classe définit toutes les caractéristiques que posséderont les objets qu'elle définit, ainsi que toutes les opérations que ces objets pourront réaliser. Une classe Voiture défi- nira par exemple les opérations accélérer, freiner, faire le plein, et les caractéristiques de cylindrée, puissance, nombre de portes, niveau d'essence, vitesse, kilométrage... L'intérêt de la notion d'objet vient de ce qu'elle regroupe, dans une même construction, données et contrôle. Ces deux notions sont centrales dans tout programme : en simplifiant à l'extrême, le rôle d'un programme est d'opérer un traitement (c'est-à-dire des opérations de contrôle) sur des données. En programmation dite structurée classique, par opposition à la programmation objet, les techniques de définition et de représentation des données sont différentes de celles du contrôle. On définit d'une part les types de données, et d'autre part les opérations (fonctions et procédures) permettant de traiter ces données. Les langages de programmation classiques ont permis de construire des systèmes complexes de manière efficace, mais ils ne facilitent pas la gestion des évolutions des programmes. Il est en effet de la responsabilité des déve- loppeurs de maintenir en cohérence, lors des évolutions, la définition des données et celle des opérations sur ces données. Les principes fondamentaux au coeur de l'approche objet sont la modularité et l'encapsulation. Une présentation détaillée de ces principes peut se trouver dans [8]. La modularité consiste à définir comme séparées des entités effectivement distinctes (soit elles représentent des notions distinctes du monde réel, soit il s'agit d'abstractions différentes), communiquant peu et par des interfaces claires et aussi peu que possible. L'encapsulation consiste à n'accéder aux données que par l'intermédiaire de fonctions explicitement définies et jamais directement : ainsi le propriétaire d'une voiture ne pourra jamais faire le plein de son réservoir qu'en appelant la fonction prévue pour cela, et non en changeant directement la valeur du nombre de litres. Ces principes peuvent se respecter avec un langage classique non objet, mais les langages objet incitent davantage à les suivre, en offrant des constructions prévues. 3.3.2. Quel gain de l'orientation objet pour la fiabilité ? Les principes de modularité et d'encapsulation contri- buent efficacement à la maintenabilité et à la réutilisabilité du code. Si des modules sont clairement définis, de taille rai- sonnable, il est plus facile de les tester, de les comprendre et de les corriger. De plus cela incite les développeurs à suivre la stratégie bien connue des informaticiens : « diviser pour régner ». Un problème est découpé en sous-problèmes ; la construction de programmes volumineux peut ainsi être entreprise de manière incrémentale : on écrit, on évalue puis on corrige des parties de tailles raisonnables, puis on étend et on assemble ces parties. Si de plus les modules commu- niquent de manière contrôlée par des interfaces précises (et surtout sansjamais contourner les interfaces), la complexité de l'ensemble du programme reste davantage maîtrisable. REE ? !) Décembre2005 M Dossîer 1 1 1 SÛRETÉ DE FONCTIONNEMENT DES SYSTÈMES A FORTE COMPOSANTE LOGICIELLE La notion d'objet contribue donc significativement à la qualité du code. Ce constat est ici observé sur les lan- gages de programmation. Qu'en est-il pour des modèles plus amont ? 3.3.3. Modélisation orientée objet, réutilisation de composants, et validation Ce sont effectivement les notions de modularité et d'encapsulation, contribuant à la maintenabilité, qui sont à la base du langage UML. L'idée est qu'un logiciel même complexe doit pouvoir être présenté de manière claire. La notion de clarté setraduit en UML, le plus souvent, par des diagrammes dont la légende (la syntaxe) est simple, aussi intuitive que possible. Mais il est également nécessaire de pouvoir aisément décomposer, hiérarchiser, structurer ces diagrammes en parties. Bien sûr, les diagrammes restent simples à comprendre, mais sont plus délicats à concevoir : quoi qu'il en soit l'objectif premier, qui était de permettre à des clients de fournir un retour sur les vues globales et abstraites du futur système, semble ici atteint. Notion de composant : quel gain pour la fiabilité ? En plus d'améliorer la visibilité des systèmes, la notion de module constitue une grande avancée en termes de gain de temps de développement, en améliorant la réutilisabilité : cette dernière décennie a ainsi vu s'affiner la notion de composants, qui sont en quelque sorte une transposition des modules du domaine de la programmation, dans le domaine de la modélisation. L'idée de pouvoir concevoir un système complexe en allant acheter des composants sur étagère (COTS : Commercial off the shelf), ou en réutilisant sespropres composants, a fortement séduit le monde industriel. Néanmoins plusieurs risques ont été identifiés par cette approche. Si le gain de temps dans les phases de développement est indiscutable, qu'en est-il des coûts de maintenance engendrés par cette approche ? Les composants sur étagères, développés par des entreprises spécialisées, n'ont aucune raison d'être exempts d'erreurs : soit la maintenance des composants est assurée par ces entreprises si toutefois elles sont encore en vie, soit il est nécessaire de s'approprier, en phase de maintenance, la connaissance des sources des compo- sants. Il est clair que cette dernière option risque d'être sinon impossible, les sources d'un programme n'étant en général pas fournies, au moins très consommatrice en temps et en ressources. Cette dernière idée se traduit dans la figure 5. Évidemment la courbe en pointillés reflète plus une inquiétude qu'une étude statistique, la réalisation de grands systèmes à base de composants n'en étant qu'à ses débuts. A partir de la phase d'exploitation, la courbe des coûts est ici directement liée à celle du nombre d'erreurs identifiées et corrigées, soit à la fiabilité du produit. Si la phase de développement est sensiblement linéaire (ce qui coût Sysf'.'me !o!Huf!busc dcCOTS *' Svme S%,,Ièiiie iel t liz,se PhaseC : O1'S illie, 11, 10 L------------------------------------------- i i/i i,,/Sysrèmei lu_icirl i/développd eni i/ ,, mteiirei ii ii ii _ ii - i i ii i i ii i /r ir i /i iin i l'hasc Plwsed'rsolnitailon: icmcPhase tJcdc'cbppcmc ! H Plil%c : + Figure5. Évoltitioiis conïjgarées des cobits de développenietit et nîaiii- tenancedessvstèiiies logiciels.1 ne sera jamais vraiment le cas : selon les systèmes, les coûts de validation seront plus importants que ceux de développement, mais nous n'avons pas illustré cette nuance), la phase d'utilisation commence par une pente assez forte, où dans les premiers temps d'utilisation de nombreuses erreurs sont identifiées, puis se stabilise jusqu'à ce que le produit commence à être vieux, phase dans laquelle les coûts de correction sont plus élevés. Lorsque le produit est obsolète, on détecte en général de moins en moins de failles (cf. courbe figure 1), mais celles-ci sont très chères à corriger. S'il s'agit d'un développement à base de composants qui ne sont plus maintenus, cette dernière phase risque d'être très coûteuse. Les modèles UML présentent-il un gain pour la fiabilité ? A l'inverse des modèles développés par les méthodes formelles dont l'un des objectifs principaux est la vérifi- cation et la validation du système, nous avons insisté sur le fait que l'objectif principal des modèles UML est la documentation du système, ainsi que l'amélioration de la communication entre les différents intervenants. L'un des gains, indirects, si les modèles sont relus et échangés, est qu'ils sont fortement susceptibles d'être corrigés par leurs relecteurs. C'est bien une forme de validation non négligeable. Mais le langage UML permet-il d'autres formes de validation ? UML n'est pas un langage formel. Il dispose d'une notation précise avec une syntaxe précisément définie (cette syntaxe est d'ailleurs définissable elle-même en UML), mais il n'a pas de sémantique formelle. C'est-à- dire que la signification des concepts de modélisation présents dans le langage n'est définie qu'en langage naturel. Les documents définissant syntaxe et sémantique infor- melle sont publics, publiés par l'OMG [13]. Cette lacune n'a pas facilité la réalisation d'outils de construction et de manipulation de modèles UML, qui permettraient de contribuer à leur validation. A l'heure actuelle, très peu d'outils permettent ne serait-ce que de REE N°H Décembre2005 Ingénierie du logiciel : allons-nous vers des systèmes plus fiables simuler ou d'animer les vues comportementales des modèles UML. Les questions qui se posent par exemple quant à la validité de modèles UML sont : . les différentes vues du système, représentées dans des diagrammes différents, sont-elles cohérentes entre elles ? · différentes propriétés souhaitées sur le système sont-elles satisfaites par les modèles ? . les modèles sont-ils uniquement abstraits et théo- riques, ou ont-ils de fortes chances de correspondre à des solutions effectives, c'est-à-dire à de réelles solutions d'implantation pouvant fonctionner sur le matériel actuel réel dont on dispose ? Certes, ces questions ne sont pas faciles, et il serait utopique d'en espérer des réponses totalement automa- tiques. Mais c'est bien à ces mêmes questions que les méthodes formelles apportent des éléments de réponses certains. Le fait qu'UML ne permette principalement que d'établir des modèles que l'on pourrait presque qualifier de conteiiiplatifs n'est de toute évidence pas suffisant. Même dans le domaine de la génération de code, où les outilleurs font pourtant une large publicité, force est de constater que les performances actuelles des outils sont encore légères : ils permettent certes de générer des tem- plates (c'est-à-dire des schémas à trous que le développeur devra compléter), mais ils ne dispensent pas in fine les développeurs d'écrire de nombreuses lignes de codes détaillées, et donc facilement génératrices d'erreurs. Quel avenir pour UML ? Le langage UML, ou plutôt la famille de notations qu'il représente, n'est pas figé. D'une part le consortium OMG n'a cessé de l'améliorer depuis la version 1.1 en 1996. La version 2.0 actuellement proposée répond à de nombreuses critiques, mais les outils ne couvrent pas encore tous ses aspects. D'autre part, et cela même dans sa version initiale, UML a été conçu pour être extensible. Trois types de mécanismes d'extension ont été prévus dans le langage. Il est possible à l'utilisateur, si un concept de modélisation ne lui convient pas, de le redéfinir par une technique de spécialisation. Il s'agit bien là d'une spécialisation du langage, et non d'un élément du modè- le, ce que les langages à objets ont depuis leurs débuts déjà défini par les mécanismes de spécialisation des classes. En simplifiant, le principe de ce mécanisme d'extension est simple : nous avons dit plus haut que la syntaxe d'UML était définie elle-même en UML (c'est ce qu'on appelle le méta-modèle d'UML : c'est un modèle du langage UML). Si l'utilisateur souhaite modifier un élément du langage, il a la possibilité de modifier ce méta- modèle. Il change, ou plutôt étend ainsi le langage UML. Un ensemble d'extensions permet de spécialiser le langage UML pour un domaine particulier. Plusieurs ensembles d'extensions ont été proposés, dont certaines sont maintenant officiellement reconnues et diffusées par l'OMG. De tels ensembles d'extensions sont appelés des profils. Il existe ainsi des profils pour décrire plus précisé- ment les systèmes temps réels ( " Schedulabiliy,, Perfoniiance and Tiine Specification "), ou pour la qualité de service et la tolérance aux fautes ( "Modeling Quality of Service and Fault-Tolerance "). Cette dernière extension est donc a priori un pas en avant dans le domaine de la modélisation de systèmes sûrs de fonctionnement. Cependant, à l'heure actuelle, ces profils offrent essentiellement un guide de construction des modèles ; l'évaluation des modèles et de leur construction elle- même n'est pas intégrée au langage et à ses extensions. Ce ne sera pas réellement possible tant que la sémantique du langage et des extensions restera incomplète. Sans vérification sur ces modèles, leur utilisation dans la mise en oeuvre du système finalisé demeure impossible. A ce niveau-là, les modèles ne présentent encore principalement qu'un intérêt « documentaire », ce qui ne paraît pas suffisant au regard du coût en temps et expertise des phases de modélisation. 3.4. Vers l'ingénierie des modèles Parallèlement à cela, plusieurs études sont donc menées pour savoir évaluer les modèles. Parmi celles-ci, l'OMG encourage actuellement les travaux s'inscrivant dans le cadre de l'ingénierie dirigée par les modèles (IDM). L'approche IDM se base sur l'utilisation systéma- tique de modèles (et méta-modèles) tout au long du déve- loppement. L'approche IDM ne se limite pas à UML, voire s'en éloigne sur certains concepts : elle vise à créer des passerelles entre différentes technologies de modéli- sation pour tirer le meilleur de chacune d'elles. Dans l'ap- proche IDM, la notion de modèle est généralisée : les cahiers des charges, documents de spécification et d'analyse sont des modèles, mais le programme est lui aussi un modèle. L'objectif principal est d'avoir à chaque étape du dévelop- pement des modèles exploitables en termes de productivi- té. Cela sous-entend des modèles syntaxiquement corrects (IDM parle de conformité au méta-modèle), et définis dans des langages dont la sémantique est suffisamment formelle pour pouvoir les évaluer (tests, simulations, transformations...) et générer des composants réels du système de manière automatique. Si l'objectif premier est donc la productivité des modèles, toutes les phases d'éva- luation et de vérification intégrées par cette approche sont le terrain propice à l'amélioration des modèles pour la fia- bilité du système (ou composant) qui sera généré. Fiabilité dans l'approche IDM L'approche IDM intègre les concepts de fiabilité tout au long du développement. Une des particularités de cette approche est de s'intéresser fortement à la traçabilité des REE WI! t Décembre2005 Dos s ii e r 1 1 1 SÛRETÉ DE FONCTIONNEMENT DES SYSTÈMES À FORTE COMPOSANTE LOGICIELLE modèles. Il s'agit d'un des facteurs essentiels pour la conformité du système par rapport aux exigences. Cette traçabilité peut être mise en place à l'aide de notions de raffinement et de composition des modèles. Le raffinement est l'action de dériver, d'un modèle abstrait M, un modèle raffiné MRqui respecte toutes les propriétés de MA, les affine ou les détaille éventuellement, et en rajoute de nou- velles. Une démarche par raffinement, si elle est outillée correctement, permet d'assurer la conservation des proprié- tés tout au long du développement, des premiers modèles issus des exigences aux modèles finaux qui serviront à la génération du système. Cette démarche est suivie scru- puleusement dans le cadre de la méthode formelle B. Dans l'approche IDM, il est encore tôt pour pouvoir la suivre effectivement grâce à des outils et environnements de travail actuels. Toutefois, il s'agit d'un progrès indéniable par rapport aux (simples) environnements d'éditions de modèles UML. Plusieurs des résultats des méthodes for- melles commencent ainsi à s'intégrer dans des environne- ments d'analyse et de conception plus généralistes. 4. Bilan Le logiciel, et en conséquence les systèmes à compo- santes logicielles, ne sont en général pas aussi fiables que nous le voudrions. Depuis le constat de crise du logiciel effectué en 1968 jusqu'à nos jours, de nombreux progrès ont cependant été réalisés. Les langages de programmation ont été améliorés, notamment la notion d'objet offre plusieurs solutions pour réaliser des programmes plus faciles à maintenir. Cette notion s'est à présent généralisée à la plupart des langages de programmation. Ensuite, les langages de modélisation (analyse, spécification, conception, architecture globale...) se sont affinés et standardisés : ils sont à présent véritablement utilisables comme support de communication entre développeurs et clients, et ce même si ces derniers ne sont pas spécialistes de l'ingé- nierie logicielle. En parallèle, de nombreuses méthodes et techniques de vérification ont été proposées, basées sur le test, la simulation, la vérification de propriétés ou la preuve. A l'heure actuelle, les techniques de vérification ne sont encore que très timidement reliées aux langages de modé- lisation généralistes, tels qu'UML. Toutefois les évolutions récentes de l'ingénierie des modèles permettent aux outilleurs de concevoir désormais plus rapidement des passerelles entre différents outils et différents langages.ZDtD En particulier les couplages entre outils de vérification et outils de modélisation commencent à apparaître. Cette perspective optimiste ne doit pas occulter les difficultés réelles qui subsistent dans les procédés de construction de programmes et de modèles. Bien que la notion de difficulté soit une notion subjective, on peut admettre que les modèles de systèmes dynamiques (or les systèmes logiciels sont flexibles, évolutifs et donc dyna- miques) sont en général très délicats à construire. Si le génie logiciel a répondu à une première attente en définis- sant des langages de programmation et de modélisation de haut niveau d'abstraction, rigoureux et intuitifs, ainsi qu'en outillant ces langages par des outils d'évaluation et de trans- formation, il ne propose encore que peu de support quant aux procédés sûrs de fabrication des modèles et du logiciel. Références tll 1.SOMMERVILLE, " Le génie logiciel " ; 1992, Addson-VVes ! ey [2] " Contrat de licence d'utilisateur final ", Licence Microsoft Windows XP Pro, XP Familial et Tablet PC, 2005. [3] MC. GAUDEL, B. MARRE, F. SCHLIENGER, G. BERNOT, "Précis de génie logiciel " ; 1996, Masson. [41 L. R. WIENER, "Les avatars du logiciel ", Addison-Wesley, France, 1994. [5] P. BEHM, P. BENOIT, A. FAIVRE & J.M. MEYNADIER, "METEOR : A Successful Application of B in a Large pro- ject ", In Wing et al Formal Methods, 1999, pages 369-387. [6] B. RANDELL, "Software engineering in 1968, lntemationai Conference on Software Engineering ", Proceedings of the 4th international conference on Software engineering, Munich, Germany, Pages : 1 - 10, 1979. [7] J.P. FOURNIER, "Support de cours de génie logiciel ", Université de Genève, http//wwwinfelg,unlge,ch/support/se/ 81 B. MEYER, " Conception etprogrammation parobjets. Pour du logiciel de qualité ", Traducteur : Robert Mahl, InterEditlons, 1990, [91 R. M 1 LN E R, " Communicating and Mobile Systems, the Pi calculus ", Cambridge University Press, 1999. [10] The Standish Group THE STANDISH GROUP REPORT, 2003. http//wwwstandishgroup,com/index,php [11] A. VAN LAMSWEERDE, "Goal-Oriented Fiequirements Engineering : A Roundtrip from Research to Practice " Proceedings of RE'04, 12th IEEE Joint International Requirements Engineering Conference, Kyoto, Sept. 2004, 4-8 (Invited Keynote Paper). [12] C.A.F !. HOARE, " The Logic of Engineering Design, Microprocessing and Microprogramming ", 41 : 525-539, 1996. [13] OMG, UML 2.0 "Superstructure Specification ", OMG Final Adopted Specification ptc/03-08-02, août 2003. [14] REE,n'l 1 décembre 2004, Répères " Sûretéde fonctionnement ". [15] D.E. KNUTH Volume A, " The TeXbook ", Addison-Wesley, 1984, Volume B, " TeX The Program ", 1986, ISBN 0-201-13437-3, Volume C, " The METAFONTbook ", 1986, ISBN 0-201- 13445-4, Volume D, " METAFONT The Program ", ISBN 0- 201-13438-1, Volume E, " Computer Modern Typefaces ", 1986, ISBN 0-201-13446-2, Addison-Wesley. tB a u e u r s Thomas Lambolais est enseignant-chercheur à l'école des mines d'Alès, membre du LG12P (Laboratoire de Génie Informatique et d'hgén ! erfe de Production. Ses activités d'enseignement et de recherche, en génie logiciel, concernent les démarches de modélisation et de vérification de systèmes. s'intéresse principalement aux premières étapes de dévelop- pement et a étudié les approches basées sur les algèbres de processus. Il est membre du club 63 (systèmes informatiques de confiance) de la SEE Olivier Gout prépare une thèse à l'université de Montpellier Il. Ses travaux sont réalisés à l'école des mines d'Alès, au sein du LG12P.Ses activités concernent l'étude de démarches de construction incrémentales de modèles comportementaux orientés objet. Les modèles étudiés sont les machines d'états et machines d'états de protocoles UML. REE Nn il Décembre2005