Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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?

like image 397
Tone Avatar asked Apr 23 '10 21:04

Tone


People also ask

What are the benefits of model driven development?

Model-driven development is popular because it fosters collaboration, boosts productivity, and delivers better applications that meet users' needs. Optimized business-IT collaboration results in higher quality applications built in a fraction of the time.

What is model driven approach?

MDE is a software development methodology that focuses on creating models or abstractions, which will automatically generate processes, structures, code or program storage formats. This initiative aims to simplify the development stages, through abstraction and mutualisation of the components.


1 Answers

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.

like image 126
bitc Avatar answered Oct 06 '22 08:10

bitc