This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Code is Model, is Software, is Computer, is ... Thing
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
The feedback is beginning to swell on Harry's post "Code is Model" and I think that it's about time for me to join the fray.
First of all, I don't like "is-a" relationships so much outside the field of software design (a dog is-a mammal is-a animal is-a thing). I think that it pays to be precise. What don't I like? I don't like comparing things that exist at different levels.
Is code the same as a model? Does it serve the same purpose? If code is-a model, does that mean that model is-a code? From a purely logical analysis of "is-a" relationships we know that this isn't necessarily the case. In most cases, the level of precision of the left-hand-side is higher than the right-hand-side. A dog barks, we can't be that specific about an animal.
Why then does Harry suggest that the model be as precise as the code?
After boiling down the content of the article we find that a different relationship emerges. Both the code and the model are views of something else, the logical program. I find this statement more in line with my views on DSLs, and architecture in general.
When analyzing a problem, we do not holistically solve all facets at the same time. Rather, we create a solution for each facet. To be more precise, we explain one view of The Solution (which we don't fully grasp yet) that speaks to the given facet. The static structure of the system is one facet we analyze with class diagrams. The behaviour of the system is another facet analyzed with sequence diagrams. Durable storage of data is another facet analyzed with an ERD. And so on.
In my opinion, these models, these views will always be incorrect/imprecise exactly because they speak to one specific facet at a time. The main purpose of these models is to raise the level of abstraction so that the main idea is better understood.
This brings me back to the question of purpose. The purpose of code is to be compiled, runned, and maintained/changed over time. The purpose of a model is to communicate our understanding of the solution to someone else. The success criteria of code is much more stringent than that of the model. It's also much faster to draw up a quick sketch of certain elements of a system to explain how things work than to start going over code, line by line.
Previous Topic
