Another in the "Expert to Expert" series which has been on my harddisk for quite some time. Erik hardly needs and introduction anymore as the Haskell-guru interviewer. Bertrand is famous for having developed the Eiffel language, an OO language which includes contracts, and is the author of several books on OO.
I was more interested in the second half of the discussion which dove into the modelling/engineering debate. Both gentlemen fervently agreed that 'ideally' there should be no distinction between the modelling/specification language and the implementation language. I have, for the latter years, always supported the following view: Since there is -currently- a difference which is unlikely to disappear and is often quite substantial, fooling oneself that the ideal is possible is no option in industry, and I proposed the following distinct documents which should hold several models during my lectures.
One, the analysis document should contain the requirements and the domain/conceptual model of the real-world entities. Two, the design model should contain a 'Platonic' ideal of the software/system to be developed. Three, the implementation model should describe how that ideal is implemented in the hardware/language of choice. And four, a test document should describe the usual tests as derived from the requirements.
Why those distinctions? One reason is that it clearly divides the different stages in a software engineering process and attributes each stage with a product which should be the end-result. Another reason, a design document describes how a system should be implemented and may refer to the nuts and bolts used, whereas a domain specification should be used solely to disect the the domain. The implementation document describes how a design is translated to software and hardware and should contain hardware, OS, language specs and a description of how the Platonic design is translated to those cumbersome lego-bricks which fail the ideal. Testing is a distinct process which should be part of all stages, elavated from user/stakeholder requirements, to design conditions, to implementation restrictions, and should result in a test document for the resulting system.
In essence, a simplified model for teaching targeting problem space, solution space, construction and validation.
A particular view, I agree, but one which, in my opinion, makes a lot more sense than the proposed ideal, which I haven't observed anywhere in the real world.
P.S. Erik once boasted to be one of the most cited authors in CS, a fine placed pun, which had a lot to do with citing systems not being able to disambiguate between the several 'Meijer/Meyer's in the world, so it's nice to see them both in this interview.
P.P.S. Stages and documents in my opinion may be 'fused' together pending the complexity of the problem, and resources, at hand. I don't agree that there is one particular process which should be used in all settings, but, rather propose that a team decides on what process should be used for a particular project. But, for a mediocre complex project which warrants a reasonable decoration, this is one simple solution.
