Generating thread safe code isn't hard at all, just don't use global mutable state, e.g. a sane concurrency model.

> 1. Graphical interfaces are not necessarily better than
> textual ones. I work with an ETL tool that is graphical:
> IBM WebSphere DataStage. The nice thing about it is that
> understanding programs written in it is easy. A screenshot
> of a program gives you an instantaneous high-level view of
> what it is doing. The bad thing is that the tools to
> manipulate the code are worse than windows notepad for
> code editing. Many of these GUI tools look fancy on the
> outside but lack good copy and paste, search, replace,
> refactoring, formatting, etc. At a more fundamental level
> they usually don’t support much abstraction either. You
> can’t just say: this thing is the same as over there just
> use that. You have to recreate everything again.

Exactly. The sometimes stated assumption that GUI tools inherently improve productivity is patently false. Often I find GUIs to cause very significant productivity decreases. Usually development in GUIs ends up requiring a much larger amount of mindless drudgery.

We have a GUI based tool that we use right now and not only does it slow me down a lot, it's really hard to figure out what things do because everything is buried in stupid little text boxes and dialogs. Instead of just scanning a developers work for errors, you must click on a billion little buttons to see what they've done. I ended up writing a style-sheet to convert their inscrutable XML export into something that we could work with. Actually, once exported to a usable format, I was able automate a lot of what is done in reviews.

GUIs have their place but it's clear to me that they should play a secondary role to text representations. The idea that GUI is always better is an outdated idea that's as stale as the slogan "the power of GUI at the speed of DOS" on an old software box near my desk.

ATL - Atlas Transformation Language (I think thats what it stands for) is pretty elegant and it might not have been approved by the MDA Group but then again who cares, they're being accepted as the model-to-model transformation language in the Eclipse modeling project.

There are a lot of transformations already created for various metamodels so its examples to learn from, and it also means its debugged more than other frameworks.

Its not just a language however but a model transofmration virtual machine, with its own model oriented instruction set, so it not only runs ATL but can also run other transormation languages that MDA ends up accepting for their QVT request for proposal. Very flexible, and a more longterm outlook which is great.

language is cool to work with, and not too complicated. sufficient plug-in for eclipse available as well for debugging and coding. talks of a modeling environment being put together as well, so you can model other model-transformations (talk about abstraction ;) ).

XMI is not something that I personally take very seriously. Its overrated, and something that I think missed its goal. Just the fact that there are a bunch of slight variations between most tool vendors kills the point. ECore is safe and productive, and evolves on need as oppose to a bureaucracy moving like a grandmother thats not in shape.

> The code that was generated was unreadable.

The Model is your 'source' code while the code is generated.
The goal of MDA is that you may generate your business rules independently by the platform/application committed.
A class diagram will be transformed into a POJO object, EJB, copy cobol, xml schema etc. you may redefine you framework without rewrite a hundred of business rules by hand, you have only to change the transformer.
Through uml paradigms static/dynamic diagrams, you trace the behavior of entire system.
You give to the business unit the power of define rules themselves.
The MDA approach is good both in small than in large application domain with different features of course (you have to justify the work of MDA development), but first model you application, model the data, keep MDA in mind. Use simple xml or your own model files definition or XMI or a model framework (EMF), but the concept is the same.

Yes, the generated code will be unreadable but as the definition it is generated, untouchable (despite you may use jmerge for merging generated and hand-modified code).

<<<The biggest problem I've seen in the past was that round trip engineering was non-existent or very weak/unstable. The code that was generated was unreadable.>>>

well this too depends on how you do it.
agreed i thought about it too and if the level of abstraction and the code level are too far from each other, sure, it would be very difficult to match between them in a fast intutitive way. but thats why you have transformations, you transform your own super-hight abstraction level layer into an intermediate (more implementation layer) and than add stuff to that to define more how it works, and then you translate that to UML, which is 1:1 with the code, so its a direct translation.

sure you can go directly from the abstraction to UML, which is fine too, but its more mental work then going at it with inbetween levels where you have time to progressively dig deeper into the implementation, so its easier on the frustration ;). Later to ease maintenance (or reduce complexity) you could merge some of these inbetween metamodels, but then again, this could very easily increase the complexity since now you would have larger metamodels to deal with, hence more complicated transformation programs.

<<<I've seen so many classes that have roseid comments but rose is no longer used. The short of it was that using the tool was more trouble than it was worth.>>>

not so.
yes it takes longer for the learning curve to happen, and to setup tools, write transformation programs, and code generation programs, and to define the metamodels, than to just jump into code and start hacking. But its crystal clear that code writing is by far the smallest part of any but the most basic projects, and instead debugging is the major time -consumer. With code generation refactoring becomes trivial comparing to regular hand coding since you're just tweaking a limited set of code generatiors as oppose to going through the entire code base (even if you're using plugins that help with searching). Also matching requirements and other configuration oriented work becomes transparent, and a much richer set of domain specific tools can be built on top of a well defined model than on top of pure code without a clear source model.

Its a tools problem, not a concept problem. As tools get better the approach will make more sense.
its interesting that the avionics industry is driving a lot of innovation in this area. For example 70% of any military/civil airplane project goes on building/debugging its software, and so modeling is getting bigger and bigger there. dig and you'll see that lockeedMarting is pushing a lot of model oriented resaerch, since it can affect debugging so much.

Its much easier to debug and logically check different models, and progressively decrease the abstraction, through intermediate metamodels. that way when you get to concrete code level the only thing that could go wrong is bugs in the API's, or in the code generators. those are relativelly easy to fix. The main logical and bad-architecture bugs were uncovered in the modeling stage, and thats why the concept is correct