Source Code And Modeling

Pulled from TheSourceCodeIsTheDesign:

Heard from TrygveReenskaug, "Modeling is how you write down everything that you want to say that you can't say in the source code. There shouldn't be anything that you want to say that can't be put in the source code." What would a programming language be like where this was true?

I think that they would be the same. However, the development environments would generate UML for you on the fly to give you a concise high level view of your source. To me, this seems more important than generating code from models.

Of course several of the UmlCaseVultures claim to do this - they call it ReverseEngineering. In practice, it doesn't seem to work very well. There is one good tool I've used that works like this though - sort of a UML-based browser/editor. Try http://www.zilker.net/~object/ . YMMV. --PeterMerel

This link appears to be broken, the search engine on www.zilker.net returns nothing useful for "UML" or "editor". Do you have any other pointers.

I can see wanting to say things that are not in the code, but in that case you are talking to other people, not the computer. You are also filtering out details. -- MichaelFeathers

SeeVsSay --RonJeffries

You can reverse-engineer machine code to get C++, but it isn't very good C++ because the machine code doesn't contain all the information. It only contains what the machine needs to know. The compiler has thrown away the rest.

What you seem to be claiming here is that in going from a design to Smalltalk (or C++?) there's no similar loss. That the case tool has all the info it needs in the code and just has to process it and present it. I think that's unlikely. There will be emergent phenomena that are being aimed for, but which (by definition) won't be explicit in any one place in the code, and there will be criteria and relationships which code can't express easily (I'm thinking here of things like universal quanitifiers in assertions). -- DaveHarris

Yes, I'm sure there is some loss but on the other hand, many people around here seem very happy to go without the diagrams at all. I'm pretty sure that someone could take Smalltalk code and translate it mechanically to UML. There are issues of formatting and detail selection for various diagrams. No one can do that as well as a human, IMHO.

Frankly, I'm much less enamored with source->model than I was, but I still like it much better than model->source. I've been using Rose a bit recently and the jumps back and forth between model and source (with all the bzyantine Rose generated embeddings) gets pretty tiresome.

-- MichaelFeathers

Presumably the point of the diagram is to communicate. A computer program isn't going to accomplish that, because it doesn't know. To me, the dark side of a notation like UML is that it becomes a major process and almost religious in application, when the real benefit comes from the little picture that brings out the essential idea one needs. That's why I like MartinFowler's little book: it guides you in the direction of simplicity. --RonJeffries

One can make a good mathematical argument that the code can't be sufficient to describe the system - it is called Goedel's theorem. Basically, no system can explain itself, you must step outside the system for explanation. Presumably, that is what comments in the code are for... And, wasn't it Turing that proved that you couldn't even tell, by looking at the code, whether or not the system would even finish?

So it is clear that the code is not the System, it is just the implementation of a system, and the test cases are there to prove that the system you implemented is the system you wanted. In XP the definition of the system you wanted is captured in the stories and the tests, in other methods it is captured in other models.

Speaking of models, one of the things I don't like about the UML is that its focus is on documenting the Code, rather than documenting the System. But that's another story... --DanRawsthorne

See GoedelsTheoremAbused.