Software Engineering / Génie logiciel

Entries feed - Comments feed

Last entries

Sun 29 May 2016

  • David Mentré
  • 1

Little Guide on Software Engineering

As a programmer and as a researcher in the software field, I've always been interested in trying to understand why a program or a system is well designed, fits its intended use, is maintainable, is scalable, etc. In short, how to make a good software.

I tried to summarize what I found so far in a very small (two pages long) "Little Guide on Software Engineering": 11 rules of decreasing importance with some references for further digging.

Of course, no revelations here. All those rules are found here and there in good books of Software Engineering. But defining and sorting those rules was an interesting exercise. :-) I'm not fully satisfied with the rule order and might change it. It is version 0.4 up to now and is still Work in Progress.

I would be pleased to get your feedback on those rules, so don't hesitate to send an email. The document is under CC0 license and there is a GitHub repository.

Tue 23 Feb 2016

  • David Mentré

Why are OO programs scalable?

For once, I am going to ask a concrete question: why are Object-Oriented programs supposed to be scalable? LibreOffice has about 10 millions line of code and Firefox has more than 18 millions lines of code. They are written in object-oriented languages (C++ for both of them). Is an object-oriented language a need for writing such big programs as it is often said or could it be done in any other language with appropriate modularity programming features?

The probably most famous counter-example is the Linux Kernel, written in plain C language and counting more than 20 millions lines of code. But the Linux Kernel is probably a very rare case of this kind (would you have another example?), developed in a very specific way by the most talented people on Earth.

I discussed this point with colleagues having done a lot of object-oriented programming, they told me the usual argument: object-oriented programs allow grouping related data and code, abstracting details from the outside, thus their scalability. But a lot a programming languages have such modularity features, dating back to Ada in 1983 up to more modern ML-like languages with complex module system (e.g. functors).

So, is there another characteristic or usage of object-orientation that helps in program scalability? Or could the same principles be applied to any kind of language (which I think for now)?

For now, I don't understand why object-oriented programs should be more scalable. But I'm very bad at object-oriented programming. So if you have explanations, I would very please to hear them. You can add comments below or contact me directly.

Tue 09 Feb 2016

  • David Mentré

The need for a new editor mixing texts and graphics

Every time you do some programming, you need a text editor (except when you program in graphical languages like SCADE). Some long-time well-known ones are Emacs (which I use) or VI. Such editors are focusing on their editing capabilities (you can edit huge files without any issue) and their ability to be programmed, for example they have dedicated modes to edit C language files or OCaml files. They are very versatile, you can find modes for obscure languages or even have dedicated mode for proof assistant (e.g. ProofGeneral for Emacs).

But those editors are focusing on the text. I think most if not all the time, they are using regex to match some specific keywords of a program and then color or indent them in a specific way, but they don't understand the program, e.g. what is a variable, an expression or a method call. Therefore people have proposed another kind of text editor dedicated to programming languages, like Eclipse or IntelliJ IDEA. Such editors are very powerful: they understand the program structure, propose useful contextual helps (like giving parameters of a method call) or help in code refactoring (e.g. encapsulating an object field so it can only be accessed to getter and setter methods).

Of course the distinction is not so binary: textual editor like Emacs or VI have advanced modes than can understand program structure and do refactoring.

But both kind of editors have a strong limitation: they focus on programming language and most of the time they are unable to mix text, graphics or other layouts like tables. This is not entirely true for Eclipse, but I'll come to that later. So, why would you like to mix text and graphics when editing a program? Because a program is more than just text! Wouldn't be useful to use a quick drawing to explain an algorithm? If you program manipulates state machines, wouldn't be useful to directly draw state machines and automatically convert them into code? That would certainly avoid some kind of programming errors. One could also imagine tables to specify the behavior of a function like Parnas tables (which could be even considered as a formal, albeit readily understandable, specification). Or one could imagine graphically draw the architecture of the system, then dive into usual text code to edit the software modules.

Such kind of editor exists, like mbeddr for C code or some Eclipse plug-ins like Rodin for Event-B formal language. But again I see a strong limitation to their use: they are storing the edited source code into a model generally saved in an XML file. It is very difficult to handle such XML files with usual programming tools. For example handling them in source control tool like Git is a nightmare, with merges very frequently corrupting the XML files.

So what would be the ideal programming editor mixing text, graphics and tables? I won't give precise specification :-) but only sketch here some characteristics:

  • Versatile, programmable, so as to handle various programming languages like Emacs or VI;
  • Able to directly draw graphics and edit tables, in a WYSIWYG way. For me this is a crucial point. Wiki-like approaches with special markers are not user friendly and practical enough. The ability to program the editor would allow transforming graphics or table into code text and vice-versa;
  • Store edited programs only in text files (and of course probably some binary files for graphics). One would probably need some tags stored as program comment to reference graphics within the code text and display it properly within the editor;
  • Hyperlink capabilities, to be able to navigate within the code, e.g. jump from a graphic element to the corresponding code text, maintain index and reference tables (for code documentation), ...
  • Fast, low on memory, disk and CPU resources. Everybody that has already used Eclipse understands what I mean. :-)

As far as I know, such a tool does not exist yet. If you have hints or even tool name that would be able to do what I would like, I'm very interested. ;-) Tell it to me through this blog comments or directly.

Tue 02 Feb 2016

  • David Mentré

"Software Aging"

In 1994, David L. Parnas published a provocative paper called "Software Aging". I recently read this paper and found it remarkably accurate!

Software is digital, so how could it age? Parnas identified two different causes for software getting "older" when time passes:

  • "Lack of Movement", i.e. the inability for the software to match evolving user or environment expectations. A computer environment evolves constantly; language and compiler changes, operating system and library changes. But this is also true for user expectations: in the 70' people expected a text interface, in the 90' a graphical interface and now they want a web interface accessible from any device or an App usable on their mobile devices;
  • "Ignorant Surgery", i.e. the inability to correctly adapt the software as time passes. When somebody modifies the software, probably not the original developer(s), she/he won't probably understand its design and probably modify it as she/he understand the software. At this point understanding the software means understanding the original design as well as the introduced new design. After several of such modifications, nobody can understand the software and in some cases it should be rewritten from scratch.

Although this idea of Software Aging was proposed 22 years ago (and appeared 47 years ago, the famous "Software Crisis", according to Parnas), it is striking to see that it is still true. When I see it takes nearly one year to make a new release of the Debian system, I view it at software aging at work: the environment evolves in unexpected ways and each software should be adapted to match its new environment. And sometimes, applying those changes can be very difficult and lead to Ignorant Surgery, like the famous Debian OpenSSL bug.

How to avoid this software decay? Parnas gives some advises, I just summarizes them here:

  1. Design for change, i.e. apply usual Software Engineering principles like Information Hiding, abstraction, separation of concerns, proper use of object orientation, etc.
  2. Document! Document your design, your choices and document for the people who'll come after you work on the software.
  3. Review! Review the design, code or other software artifacts by other members of your team, by experts in the domain on which your software is applying, etc.

Even for actual software, above principles can be applied, retro-actively. Parnas gives some advises.

All current software are aging. Hopefully, 22 years ago, Parnas gave some very good advises on how to develop and maintain software to limit this phenomenon. Listen to him, apply them.