Let me help you become a software engineer

This blog aims to bring you, whoever you are, up to the same level of a master’s graduate in software architecture and verification, by means of a clear, easy to read, practical, and recreational content which requires no prerequisites, and without the stress of exams.

The idea to do it came to me in 2017 after my initiation to model-driven architecture (MDA) Object Management Group, 2014 at Netfective Technology. I was then involved in a European research project DICE Consortium, 2018; Kalwar et al., 2018 where French, British, Italian, Spanish, Greek, Romanian, and Slovenian researchers and engineers joined forces to design a new modelling language that would facilitate the development of Big Data applications (i.e. applications that massively collect or process data).

I could appreciate how modelling can make complex subjects accessible.

Many students in software development are put off by software verification. It is the science of techniques enabling us to prove that a piece of software behaves as expected, and this before running it, that is, without tests, with logical arguments alone.

Verifying software is not simple. Proofs take time. But one has really understood well a program only when he is able to explain why it works. Here, we will see how model-driven architecture can turn this somewhat arid subject into something very appealing.

There is a lot to talk about: without further ado, let’s get started. Click on the compass in the top left navigation bar to access the courses.

Questions

A piece of software is said to be correct if it behaves as expected. This is the technical term.

In your opinion, can a good test suite prove the correctness of a program? If yes, please precise what is a good test suite to you.
Will software verification render tests obsolete? If a program is proved correct, should we still test it?

Quotations

The relationship between the construction of a program and its proof of correctness should be so intimate as to make it impossible to detect which of the two is driving the other. It might then be reasonable to say that constructing a program is just constructing a proof.

Abrial, 1996, p. xi

When you write a program, think of it primarily as a work of literature. You’re trying to write something that human beings are going to read. Don’t think of it primarily as something a computer is going to follow.

Donald Knuth, interviewed in Woehr, 1996

Bibliography

Abrial, Jean-Raymond. The B-Book. Assigning Programs to Meanings. Cambridge, United Kingdom: Cambridge University Press, 1996.

DICE Consortium. Practical DevOps for Big Data. 2018. Available online from Wikibooks—last accessed on 27 July 2020.

Gonzalez-Gutierrez, Arturo. Minimum-Length Corridors: Complexity and Approximations. Santa Barbara, California: University of California, Santa Barbara, 2007.

Kalwar, Safia, et al. Performance Degradation and Cost Impact Evaluation of Privacy Preserving Mechanisms in Big Data Systems. In New Frontiers in Quantitative Methods in Informatics. Edited by Simonetta Balsamo et al. Springer International Publishing, 2018.

Object Management Group. Model Driven Architecture (MDA). MDA Guide rev. 2.0. 2014. Available online from Object Management Group—last accessed on 8 March 2022.

Woehr, Jack. An Interview with Donald Knuth. Dr. Dobb’s. 1996. Available online from Dr. Dobb’s—last accessed on 23 March 2018.

Photographic credits

Rawpixel.com (username on Shutterstock). Joyous graduates. n.d. Available online from Shutterstock (reference number: 174215792)—last accessed on 23 March 2018. Featured photo.