>> "The absence of large-scale empirical studies makes it impossible to state any guarantees that the approach will increase productivity or decrease defects"
You heard it here: procedural is non-OO, and is characterized by "functional flows". (Meyer must have missed this when adding his name.)
Moreover, requirements should use OOP too, not just the code, including inheritance!
When you read the paper, it's not so crazy.
Mainly, human language is already object oriented. The proposal is basically the use of object-oriented pseudo code to talk about requirements in OOP.
We already use inheritance in writing requirements (ones that are not about oop) whenever we take a shorcut and describe something as being almost exactly like something else, but with a difference:
For instance we might say things like "the mappend function has exactly the same syntax and argument semantic conventions as mapcar, but rather than returning a list of the items projected through the mapping function, the mapping function is expected to produce lists, which are catenated and returned.
I suspect that, in the first place, the philosophical plece where OOP comes from is interpreting the entities talked about in requirements literally in the code. The requirements talk about books and borrowing, so, okay, we will have some things in the code which represent books, and can be borrowed: when the real book in the real world is borrowed, there will be a corresponding operation involving the imaginary book inside the computer.
I don't think you can capture the actual high level requirements from users in OOP pseudo-code though. If you're listening to a user talk about what they want, but typing OOP-like pseudo-code into your note-taking app, that has to be regarded as seriously wrong. How will the user even sign off on that? If you have a separate requirements capturing document and then another one which uses this OOP pseudo-code, that second one won't be recognized by everyone as being a requirements document any more. It has the flavor of a high-level design, because many of the entities appearing in it will likely appear in code.
It's a strawman position to say that the only deliverables are requirements and code; every document that is not code is a requirements document, even if it contains pseudo-code, flow-charts, module decomposition diagrams, sequence diagrams, ... Now, there is a strict sense in which that is true: the sense that all code implements requirements, and the requirements it implements are those of the most detailed document that came immediately before the code, which makes that a requirements document. Such a document could dictate to you the exact C structure to use, and whether the function passes it by value or pointer, and so on. Usually we refer to detailed requirements spec as a design document (e.g. "detailed design"), not requirements. Requirements specifications for API's and programming languages go to that level of detail. The producers and consumers of those documents and the tools they represent are engineers.
Something with OOP pseudo-code is a "high level design" even if you rhetorically insist that the classes in it are not implementation classes but requirements classes. (The only thing which makes them requirements classes is that they are in a document and not executable code.)
> almost exactly like something else, but with a difference
Yeah, with all the hate that inheritance is getting these days, it is easy to forget that it models something extremely valuable: programming by difference.
Having something concrete and functioning as a base and then being able to say that your new thing is almost like this existing thing except for these small differences is very powerful.
I've found that inheritance works best if it is planned ahead, but that's not always how it was "sold" in OOP-promoting materials.
Maybe the tacit idea here is that if you start using inheritance right in your design document, where OOP pseudo-code gives detailed requirements, then due to all that forward thinking and planning, good use of inheritance will pop out in the actual product.
It's related to how reuse of any kind has to be planned for best results. Code not intended for reuse will not always reuse well, and that includes classes being reused via inheritance.
I just started reading the book (that I mentioned in my previous comment) and I am quite intrigued by the chapter dedicate to "OO requirements"... but it will take me a few weeks to get there, I suppose.
