Express [posted Nov. 1st 2006 00:27]

Some time back I was discussing MDA principles (with you know who) and it struck me that UML is a great way to express ones thoughts in a structured visual way (being able to communicate a lot in a relatively easy to understand compact manner) but it or rather the tools one has to use to create it are very ineffective/inefficient. I have wondered many times how it can be that modelling tools have only a fraction of the capabilities that modern IDE's have whereas they are used to do the same thing (persist abstract thought in a structured manner). Not only are they used for the same thing they are used by people doing both modelling and coding. MOreover they are written/created by people working on IDE's. Why doesn't anybody creating a modelling tool seem to be bothered by the fact that making models is pretty inefficient. There further is usually very minimal or no support for team modelling, version control, authorisation, merging, configuration management and so on.

Setting my frustration on all these points appart I was mainly p***ed off with the fact that one, in most cases, cannot write UML like you can write code. Not that I love writing code but I can write code a hell of lot faster than I can model the same amount of meaning into UML. Wouldn't it be great if you could just write UML like code. At the moment I think you would have to write your own text to UML/XMI converter to do that or use the OMG standards of which I don't know if there are many implementations (other than producing text rather than using it as a bases) or write XMI directly if you're a real die hard. That would however not even speed up things since XMI is rather verbal. Ron once pointed out that most developers are text oriented rather than picture/figure oriented, suppose that is true for me.

Anyway to take this though a bit further I thought about why not using Java as a language to code ones model in. It is a language that has a meta language definition so why not use the OMG MDA principles to convert it to UML and from there do the [www.omg.org/mda/|MDA] thing. A more dynamic approach with more possibilities could be achieved using a more dynamic language I assumed. This led me to [www.ruby-lang.org/|Ruby] or possibly Groovy (which Ron pointed out to me). The last seemed close to dying at the time and I focussed on Ruby. Not too much later Ruby on Rails began its much famed rise. When I saw the use [http://www.loudthinking.com/|DHH] made of Ruby I was confident that Ruby would be able to deliver what was needed. It actually opened new ideas/possibilities and hopefully would make my life easier.

The idea was to create a framwork that woud support two things.

First it would support code generation based on the principle of enabling domain modelling and defining platform specific artifacts in architectural patterns, a marking model (an idea borrowed from the MDA Workbench) or Aspects. In other words the domain model stays clean and close to the language of the business and as abstract and precise as possible.

Secondly the framework would support prototyping. The importance of prototyping cannot be underestimated I think. In all projects that I have ever worked on I have seen that having something to look at and preferably work with will bring so much more understanding and inspiration to future users of a system than any model that I have ever made. It is with this that Ruby on Rails will hopefully take a lot of work out of my hands. Yes I would like to have frased this "it took a lot of work out of my hands" but I have been busy too much doing client satisfaction.

These two features would give an executable model that would be as abstract as possible and would take as little coding as possible. The executable model would help the definition of the content of the model and at any given time the model could be used to generate code fit for different platforms and architectures. This double cutting sword would possibly be more complex than a static code generation tool, but it would ensure succesfull short cycled iterations. This approach would possibly prevent a lot of hassle with round trip engineering since the code would evolve in the model and the code would hopefully only be generated to enable installing it in the target environment to test it on non functional requirements.

The way things are modelled in the dynamic model is along the lines of RoR (in fact when I first saw the "has_many" style of relationship declaration in RoR it scared me thinking DHH had created everything I thought of already) extending on it to hold more details to enable successfull generation. In fact the extensions or added information (hashes) could be specific for a certain platforms/architecture and not interfere with other target platforms. However, this is probably better addressed with marking model like constructs. The extensions will not interfere with the workings of the RoR framework allowing that to work its magic. Since the platform/architecture of that is set and proven to work the prototyping/dynamic modelling environment is ready to go.

One of the hard bits will be to generate code other than Ruby from the code written in the RoR/dynamic model. To enable this it will probably be necessary to code as much as possible in a generic way not doing any of the Ruby magic since that leaves relatively straight translation into say Java or .Net nearly impossible.

At the moment Groovy seems to be more alive than ever and JRuby is going strong. These are important it seems to me. Not because I think Ruby is not capable of doing a good job but because Java is a much more accepted language and runtime environment which is not something to take lightely in the Enterprise world. It seems to me that having a JVM as a base is more than welcome in getting companies having Enterprise environments to accept concepts like the one described here. Whatever one may think of Enterprise environments I have enough respect for them not to want to be the one standing outside having all the right ideas.

Enough talk/writing for now, time to proof that it can be done. Hopefully, with a little (or lot of) help from a my friends we can show it works soon. Any ideas on a name for the framework are welcome ;-).

Rails might be Ruby's killing application [posted Nov. 1st 2006 00:27]

Recently I held a presentation on Ruby and Ruby on Rails and one of the conclusions I drew at the end surprised me/hit me just when I wrote these conclusions only an hour before presenting.

The only way that Ruby will get out of its niche position is when it can enter the Enterprise world. It has been doing so not directly but certainly ideas that were, in my mind, formed from Ruby concepts like dependency injection have penetrated the Enterprise world.

The main driving force behind a lot that is going on in the Ruby world at the moment and certainly the source of attention is the Ruby killer app Ruby on Rails. However since it is opinionated software and it has a very opinionated (not to say irritating at times) front man in the shape of [http://www.loudthinking.com/|David Heinemeier Hansson] eager to proof the Enterprise world wrong it could well be that if the Ruby community doesn't get the message accross that Ruby is not only RoR, Ruby will never get into the Enterprise environment.

Basic types go home [posted June 10th 2005 15:49]

As we did see at least in UML 2 there seems an equal treatment of associations and attributes. But why do we need the difference between composites and attributes anyway? They will never be treated comletely equal because you can name the two sides of an association and only name and attribute ones.

Why do we need to make the distinction between a composition and an attribute? One reasons that springs to mind is the much less cluttered class diagrams one gets using attributes. This however is just a way of representing a model visually. I can not let that one count.

The only reason I can think of is the fact that you can not have a composite association to basic types. Ehm, so why did we need those again? There are quite a number of OO languages that do without them. Is it a coincidence that these languages also have a realy elegant feel to them (Small Talk to name but one, and did I mention Ruby, getting to know that one, too little time though).

I guess one does not have to use the basic types, hmmm, I shall give it a serious try next modelling job I take on.