Laissez-moi vous aider à devenir ingénieur logiciel
Ce blogue ambitionne de vous amener, qui que vous soyez, au même niveau qu’un diplômé en master d’architecture et vérification logicielles, grâce à un contenu limpide, facile à lire, pratique, récréatif, qui n’exige aucun prérequis, et sans le stress des examens.
L’idée de le faire me vint en suite à mon initiation à l’architecture conduite par la modélisation — aussi connue sous le sigle MDA, de l’anglais Model-Driven Architecture Object Management Group, — chez Netfective Technology. J’étais alors impliqué dans un projet de recherche européen DICE Consortium, ; Kalwar et al., où des chercheurs et des ingénieurs français, britanniques, italiens, espagnols, grecs, roumains et slovènes s’étaient associés pour concevoir un nouveau langage de modélisation afin de faciliter le développement des applications Big Data (c.-à-d. des applications qui collectent ou traitent massivement des données).
Je pus apprécier à quel point la modélisation peut rendre accessibles des sujets complexes.
La vérification logicielle rebute beaucoup d’étudiants en développement logiciel. Elle est la science des techniques permettant d’apporter la preuve qu’un programme fonctionne comme prévu, et ce avant de l’exécuter, c.-à-d. sans tests, uniquement par des arguments logiques.
Vérifier un logiciel n’est pas chose simple. Prouver prend du temps. Mais on a vraiment bien compris un programme qu’à partir du moment où on sait expliquer pourquoi il marche. Ici, nous verrons comment l’architecture conduite par la modélisation peut transformer cette matière un peu aride en quelque chose de très attrayant.
Il y a beaucoup à dire : commençons sans plus attendre. Cliquez sur la boussole dans la barre de navigation en haut à gauche pour accéder aux cours.
Questions
Un programme est dit correct s’il fonctionne comme prévu. Tel est le terme technique.
- Selon vous, un bon jeu de test peut-il prouver la correction d’un programme ? Si oui, veuillez préciser ce qu’est un bon jeu de test à vos yeux.
- La vérification logicielle rendra-t-elle les tests caducs ? Si un programme est prouvé correct, doit-on encore le tester ?
Citations
Développer un logiciel et prouver sa correction devraient être des activités intimement liées ; il devrait être impossible de discerner laquelle des deux permet de mener à bien l’autre. Il serait alors normal de dire que la construction d’un programme est en fait la construction d’une preuve.
Regardez le programme que vous écrivez comme une œuvre littéraire avant tout. Vous écrivez quelque chose que des êtres humains vont lire. Ne le considérez pas en premier lieu comme quelque chose qu’un ordinateur va exécuter.
Bibliographie
Abrial, Jean-Raymond. The B-Book. Assigning Programs to Meanings. Cambridge, Royaume-Uni : Cambridge University Press, .
DICE Consortium. Practical DevOps for Big Data. . Disponible en ligne sur Wikibooks — dernier accès le .
Gonzalez-Gutierrez, Arturo. Minimum-Length Corridors: Complexity and Approximations. Santa Barbara, Californie : Université de Californie, Santa Barbara, .
Kalwar, Safia, et al. Performance Degradation and Cost Impact Evaluation of Privacy Preserving Mechanisms in Big Data Systems.
Dans New Frontiers in Quantitative Methods in Informatics. Édité par Simonetta Balsamo et al. Springer International Publishing, .
Object Management Group. Model Driven Architecture (MDA). MDA Guide rev. 2.0. . Disponible en ligne sur Object Management Group — dernier accès le .
Woehr, Jack. An Interview with Donald Knuth.
Dr. Dobb’s. . Disponible en ligne sur Dr. Dobb’s — dernier accès le .
Crédits photographiques
Rawpixel.com (nom d’utilisateur sur Shutterstock). Diplômés joyeux. n.d. Disponible en ligne sur Shutterstock (numéro de référence : 174215792) — dernier accès le . Photo mise en avant.