What are the benefits and risks of moving to a Model Driven Architecture approach?

Question

I work for a company with about 350 employees and we are in the process of growing. Our current codebase is not structured very well and we are looking both at how to improve it immediately (by organizing objects into namespaces, separating concerns, etc.) and moving to a model driven architecture approach, where we model and design everything first with uml, then generate code from that model. We have been looking heavily at Sparx Systems Enterprise Architect (EA) (which is UML 2.0 capable) and we are also considering the tools in VS 2010. I know there are other tools out there (Rational XDE being one) but I really do not think we can spend $1500+ per license at this point.

I'm not looking for answers on which tool is better than another but more for experiences moving from a cowboy coding environment (that is, little planning and design, just jump in and start coding) to a model driven architecture. Looking back was it helpful to your organization? What are the pain points? What are the risks? What are the benefits?

Answer 1

We did that once with a 3 mloc logistics planner system, and it worked well. However, we realized early on that UML would not be sufficient. It was simply too obtuse to capture the level of detail needed for the specification. The best way was actually to use pseudo-code (everyone was using it anyway for communicating ideas)! That's how the realization was made. Using UML felt like a step away from clarity.

As the ideas started to narrow down to a solution a version control system was employed in order to track the changes of the pseudo-code (and use cases etc). So, everyone in the group followed the changes. Bit by bit parts were translated into actual code alongside of documentation and references to motivations and discussions.

In the end the transision from model to code was very smooth. The really nice part was, imho, the use vcs which allowed you to see even the original pseudo-code without switching environment.

Answer 2

I wrote my bachelor thesis about Model Driven Software Development and I just want to warn you, that it is really important to use a good approach for doing what your company intends. There are many things which might go wrong, like e.g. editing generated code directly, being able to generate only once, becaause manually edited code would be erased after generation, you have to do some domain analysis to create a good meta model and use a good code generation framework... Please do not understand me wrong, I think MDSD is great, but just take care how you will do it. The original MDA and books about it suggest really bad appproaches, which are too costly and too brittle. I suggest you looking at voelter.de website, where you can find papers, presentations and podcasts from Markus Voelter, who is a very experienced consultant in that area.

Answer 3

For me, the key aspect is to be pragmatic sometimes. Modeling should not be a boolean activity (we do not either model or not model). We should be able to adapt the modeling level/precision to the characteristics of the project (see for instance what people working on agile modeling do) and the company. Too little or too much modeling may be problematic (with too little you may not see the benefits, too much may be overkilling fo your company, specially if you are beginning the transition or you don't have the required tools)

In my portal/blog (http://modeling-languages.com) we often discuss about the benefits of modeling or how modeling should be used. You may find it interesting

Answer 4

Our current codebase is not structured very well and we are looking both at how to improve it immediately [...] and moving to a model driven architecture approach, where we model and design everything first with uml, then generate code from that model.

First, it's great that you and your company realize that there are some deficiencies in your software development process and that there is a willingness to improve.

It seems like however that there is quite a bit of work in front of you, and many things to improve in different directions. My first advice would be to not try to change everything at once. People are generally reluctant to changes, and everybody needs some time to digest new changes. It's also very important to create a common understanding about what needs to be set up. This common understanding will not be created in one day. Such change require a mid- or long-term commitment.

Then, regarding MDA, it's important to notice that it requires some discipline. Depending on your team, the first part might well to work on that first in a way to prepare the next step, which would be to introduce MDA. I'm saying that because you say you have a "cowboy" process, which means people are probably used to do whatever they want -- it's a no-go for MDA.

Then comes the introduction of MDA itself. There are various way to do MDA (and I won't expand about thsat here), but the still predominant way to do it, is the so-called round-trip engineering. The biggest problem then is to keep the model and the source synchronized.

( My take is that MDA leads to a positive return on investment only if the model can be reused for several projects. This means that you must have identified the things that you do over and over, and have a sufficient clear view on the problem to be able to create a sufficiently complete model and transformations that you can reuse across project. I don't believe that MDA works if each project is completely different; the time spent to get the model right and the transformation, etc. will be bigger than working only with code and documentation. )

Another appraoch is to not do MDA completely -- you don't generate code from the model -- but to increase the awareness of people about modeling and design issue, e.g. with UML. This way you won't face round-trip issue but still improve the maturity of your software development process.