So I have finished the book by Rouson and Xu.
I started reading it because I turned out to be in the lead of the software development process, while not being fully qualified for it. So I needed some source of experience to substitute for my own poor knowledge.
To complement the text I need to mention the two links to the book materials:
The un-official github source page:
https://github.com/sourceryinstitute/Scientific-Software-Design
The official Cambridge university press page:
https://www.cambridge.org/core/books/scientific-software-design/CD0A2BA986E335E95D7FC91CF39BA30E
http://www.cambridge.org/cn/academic/subjects/engineering/engineering-general-interest/scientific-software-design-object-oriented-way?format=PB&utm_source=shortlink&utm_medium=shortlink&utm_campaign=rouson
What can I say about the book itself?
The book is mainly focused on writing differential equation solvers in an abstract way, because essentially, most scientific software revolves around solving PDEs.
There is a brief introduction into the process of numerical modellin, namely, physical modelling, PDE construction, semi-numeric modelling, and fully numeric modelling.
Afterwards, there is a brief short summary of object-oriented analysis for typical PDE objects, such as fields and operators, and basic patterns, which could be useful for mathematical modelling are given, thus building a link to the process of software design. It is interesting that the authors try to justify the usage of the advanced writing techniques by mathematical formulas describing average time for a bug search and fixing process, which is, I guess, not too precise, but a very scientific approach to talking to bosses.
The book doesn’t pay too much attention to the multithreading part of the programming, although it does say a few thing about using MPI and OpenMP, but the main emphasis is still more on the architecture, essentially just because there already is a huge base of knowledge on multithreading programming.
It was quite insightful to get deeper into the world of the ‘Hardcore old-school programmers’. I guess I should have a expected the book to have examples writen in Fortran, althought I hadn’t, and was pleasingly surprised to realize that Fortran is moving forward quite steadily, and the recent versions are fully object-oriented, support advanced allocation mechanisms, parallelism, et cetera.
However, I’m not totally satisfied with the book.
Firstly, althouth the examples and quite illuminating in terms of posed problems, but still there is a lot of things left out of the scope.
Secondly, personally, I didn’t feel that the problems were really solved beautifylly there. I understand that it’s a very shaky argument, but for a book that constantly references beauty and real (not software) architecture as its sources of inspiration, I can’t resist using this argument.
The style is quite readable, and although I sometimes felt that the authors tried to show off a bit by deliberately inventing more physically convoluted examples, those were quite entertaining and giving a feeling of joy before science.
One of the other reasons why I was interested in the book is that they were using UML as a helper tool in describing software architecture. And here, just as everywhere, I have to say that UML suffers from being (although quite illustrative) rather cumbersome to draw.
I am still quite sure that UML should not be drawn by hand, but rather only generated automatically from source code (maybe with a few helper comments.)
I also have to say a few words about the exersises. I haven’t finished them all, although this is in my plan, but I have to say that although they are good, they still leave a slight feeling of being unfiinshed.
As a conclusion: the book is sort of worth reading, as there are only a few book on scientific software architecture at all, and beggars cannot be choosers. Secondly, the advices and the exersises there certainly do give a lot of useful suggestions, they do leave a lot to the reader’s imagination, so perhaps should be used more of like the first step, rather than a full guide.
Do I recommend reading it? Well, rather yes than no.
Various Thoughts 