Slashdot Mirror
Pros and Cons of MDA Code Generators?
amartel asks: "Four years ago, Ask Slashdot asked if anyone was using a Model-Driven Architecture. The number of MDA tools are now almost overwhelming, and I strongly believe that comments to the same questions would be rather different nowadays. What are the drawbacks, difficulties and limitations of MDA? What percentage of code can actually be generated? I would like to add a few more: is it realistic to create a custom GUI rather than CRUD operations with these tools? Finally, what about Microsoft, the new competitor on the scene, and their DSL Tools?"
The first step to recovery is admitting you have a problem...
This space intentionally left blank.
I really like MDA for game creation because it allows me to focus on game mechanics (great for simulation/conquest games) rather than coding. With all the tweaking of game mechanics and in-game entities, code changes can be very tedious. Having auto-generated database and XML mappings doesn't hurt either!
The implementation of said tool was unfortunately fairly mediocre, and I finally gave up on trying anything non-trivial using ECO, after the third time that the source code and model became 'out of synch' and my 1000's of lines of generated code would not compile.
If I had the time, I would like to try an updated version of ECO, or perhaps another alternative, but overall, I still prefer the safety net of being in control of the coding process, and actually understanding what is going on under the hood.
Pick a tool that you are comfortable with, code with it. It should be fast to code. Once you have your application working, it might become obvious that you need more control over your architecture. Then you are at square one, writing a costume MDA that works for you. At least that's how it happened to me. It might sound like re inventing the wheel, but I feel there's a time and a place to REALLY tweak your code to make something great. I've been migrating my application to my own architecture, and while it still needs some tweaking and optimizing, the product is quite nice. In fact right now it does a couple of things that some experts believed that were impossible.
please excuse my apathy
I've always considered MDA tools as a good way to bootstrap your project. Once I'm moving along, I'll usually stop using the tools except for things like persistance layer mapping.
Oh, wait ... you mean Model Driven Architecture as opposed to Monochrome Display Adaptor. And here I though I could make a killing unloading all the old Hercules cards in my closet. Nuts.
James
There's always been a fundamental disconnect between the underlying model (data and their relationships to one another) and the tasks that users need to perform. Nearly always, users need to bring together data from disparate parts of the model to perform their tasks, generally in the same context (e.g on the same web page or in the same window).
I'm a WebObjects hacker, and I've tried to use the Direct-to-Web and Direct-to-Java Client technologies as the basis for an application many times. These read the underlying data model and automatically generate either a web application or a Java Swing application for you, customizable via a set of conditional rules. However, every time that I've done so I have ended up either re-doing the application via a more conventional WebObjects implementation, or the amount of customization has ended up being so great that the level of effort was roughly the same as if I had started from scratch.
Don't believe the snake oil salesmen, and don't let your management believe them either.
--Paul
IANAAD (I am not an Acronym Dependent) but, the FSTR is admitting YHAP...
O.K.?
However, I really don't like OMG's MDA. There's an article on the Web by David Frankel that explains very well why UML isn't quite up to the task (see http://www.bptrends.com/publicationfiles/01-04%20C OL%20Dom%20Spec%20Modeling%20Frankel-Cook.pdf, and see also http://www.martinfowler.com/ieeeSoftware/mda-thoma s.pdf).
This is not to say I fully agree with Microsoft's DSL and Software Factory concepts. I certainly see more debate is needed. In a sense, MDA is bad because I feel it will stall the debate, as vendors rush to implement their tools around a model some considered flawed, and a great many just plain hard to use in practice.
The revolution will not be televised.
AndroMDA could be worth a look. Works with Poseidon and some expensive UML tools. You'd better be up on your UML if you want to do some MDA. One of the best code generation strategies I've worked with was using XDoclet tags to generate mappings and Hibernate's schema export to take those mappings and generate DDL.
My entire datalayer is designed arround some of this theory. It takes me about 2 minutes to create a data object for a predefined table, or about 15-30 for custom views. But that is a fraction of the total time spent developing. Because pretty much ever thing I do depends on the data layer, and much of my higher level code can use multiple data object, the ratio of functional code to generated code in use is tiny, while that relationship is inverted for development time. Which means I can spend a lot of time going over business req and fine tuning applications, with out having to bother with data interaction.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
I've used an ORM to code the data-layer CRUD operations on a data model with 1200 tables, which probably saved at least a man-year of effort.
I've also struggled trying to use UML to generate business logic. That just didn't work.
The model is developed using ArgoUML. The output is a zipped XMI file that I convert to a EMF ecore model using the argo2ecore Eclipse plug-in. From there I generate the model and editor code using EMF. After that, I use the Elver plugin to generate the corresponding hibernate mappings.
So from the UML source, I can generate EMF model and edit code to serve the presentation and hibernate mappings for persistence to an RDBMS -- all using free software.
There are a couple of big challenges, namely distributed object persistence (including transactions). For this we're attempting to use the EMF SDO (Service Data Objects) implementation. Also implementing business behavior is a bit of a challenge since ideally we'd be able to mark certain EMF methods as "biz logic" such that the factory generates a stub for the client, and I could fill in real business logic for the server side.
To put this in English... MDA is basically a system for auto-generating data access routines and/or syncing data schema with access routine changes?
I'm wondering; is all this model driven code generation just a paradigm shift from text-based programming to graph-based programming?
Seems to me that the amount of knowledge of the tools required for these code generators closely matches the amount of knowledge of a language required to create a decent app.
Replacing one set of syntax (that of code) with another (that of the graph "language", reflected in it's file format), without taking away any of the complexity.
If it were really easier to use code generators, one would expect less skillfull people to be able to use them; is this the case?
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
I agree with you that graph-based programming has the same complexity as text-bases programming. On the other side: a couple of years ago I used Labview, a 'graph'-based programming language/environment. It was incredible how fast I could implement something and debug it.
I still wonder why we still code in text files (as I do myself today). We invent dedicated databases for other to use, but we fail to use them ourselves for our main task. Would you go to a doctor if you knew doctors never go to doctors themselves?
In the meantime they invent these code generation tools, which are in my opinion the worst way to go because as soon as you have to edit the non-source code, you loose the connection with your 'graph'.
Therefore I stick to text as source, from which the objects, libraries and application are created in a consistent way.
My experience with Model Driven Architecture left me with a bad feeling about it. While the theory and goals are admirable, I worry that practical implementations don't meet expectations. Basically, I think that MDA is presented as a silver bullet, and the type of companies likely to by 'targeted' by MDA (e.g. those that must 'fix' their development methodology) are the least likely to benefit from it. I am willing to accept that highly skilled and well managed project teams will experience massive productivity gains using MDA, but such project teams (unfortunately rare in our industry) would probably succeed using pretty much any methodology.
I worked one summer on a Java based project whose goal was to develop a system for managing health insurance policies. The company and project were flawed for a number of reasons, not directly related to MDA, but the choice of MDA made the situation much worse. The end of this story is that the company went out of business because it was unable to deliver the software it had promised.
Near the start of the project, the company had hired an MDA guru, who designed the MDA and, I belive implemented most of its core. Over time the MDA core portion expended in into a massive code generator that took hours to run and required tons and tons of memory.
The state of the project when I arrived (which was to implement optimizations to one of XML based parts of the code generator) was:
I think the worst result of MDA, was that the nature of the MDA process caused a large divide to develop between the 'system' programmers, maintaining the underlying MDA library, and the 'application' developers.
The system people, generally well qualified programmers, had little or no interest in the end application. The were fascinated by the tools and viewed the production of a functioning application as 'an exercise for the application programmers'.
The application programmers, on the other hand, had absolutely no understanding (though through necessity they had interest) of the underlying architecture and no ability to predict the performance implications of their design choices.
The result was a massive resource hog. The two system programmers, truly interested in ensuring the that MDA system could actually be used create an salable application had to work overtime to try to hold everything together. Unfortunately, they failed, though not for want of trying.
The main technical problem, beyond the complexity of the tools, was their attempt to map the MDA's OO data model to a relational database. (I'm not sure if this is a core principal of MDA, so I welcome your feedback). While OO data modeling might be good for user interfaces. I don't feel it's that suitable for modeling typical business data, like insurance policies. And the OO modeling concepts seemed to confuse the business domain experts, who tended to think in relational model terms.
It may well have been that this particular implementation of MDA was badly flawed. That said, the nature of MDA, that of hoping to implement your application by 'drawing pictures', and then filling in snippets of code to complete the it, seems naive. It reminds me of the early 90s when 'strong CASE' was the rage and the CASE proponents said all application design would be done using diagramming tools and then filling in the bodies of the subroutines.
I suspect that over the years, MDA will generate a minor following, like strong CASE did, but then a new fashion will emerge and interest in MD
---- It won't be as bad as you fear or as good as you hope, but it will take twice as long as you plan.
I have had (am having) the displeasure of being part of a pilot project for an in-house MDA utility based on Rose and Eclipse. In a nutshell: it sucks.
There are two general problems that I've encountered:
The granularity problem is that you have to spend a lot of time specifying fine-grained details in the model that are more easily expressed in code. Examples are: method calls, persistence, behavior parameters, etc. Often these details don't even show up on the screen. This makes them almost useless for someone trying to understand what is going on. This is a big problem and not going away.
The tool problem is that if the tools don't help you work effectively, the whole process fails. Using Rose is like sticking pins under your toenails and kicking a wall. Rose seems to get in your way on purpose with a hideous interface. Sure, this problem is tool-related, but its impact is huge. It can turn what should be simple into a marathon of pain.
So far, we've spent weeks on a toy application that should have taken two days. Perhaps these in-house tools will evolve to the point of usability, but somehow I doubt it.
IanWe use "lightweight" MDA to codegen code for limited scope portions of an overall design, like communications protocols, state machines (for UIs and embedded systems), data models, and data flow engines. We use models to generate SQL, C (dialects for 8-bit SOC through Win32, .NET and Linux), C++, C#, Perl, HTML, and XML.
We often use diagrams to design our models, but the models themselves are (to date) are written in textual forms (XML, text outlines, or custom mini-languages) rather than graphical editors. The textual forms are useful because we can use any text editor (like your favorite IDE or programmer's editor or sometimes even notepad.exe or a wiki) to maintain them anywhere. Also, it takes a lot of time to build a graphical editor and tools like Eclipse, Visio, etc. still take too long to whip up a GUI in unless you're already a guru in that tool. Implementing and tweaking ad-hoc extension in to a text-based modelling tool is also relatively easy. I'd much prefer to be able to use graphical model editors, but haven't had the time to roll our own and haven't found a tool that makes rolling our own that easy.
Tool-based MDA offers better return than raw coding does under a few conditions: (1) where the model's structure represents the solution more intuitively or concisely than source code (state machines and dataflow, for instance), (2) where the model can be used to generate repetetive code and reduce the chances of human error (all of the examples listed above), (3) where many artifacts can be created from one model, and thus kept in sync automatically, for instance in data modelling (SQL schema, SQL queries and C++/Perl/etc. wrapper codegen from 1 model, multiple endpoints of a comms channel), (4) where a team can build an MDA tool *once* and then apply it to many problems.
In some sense, you can think of item 1 in that list as being true when the model you've chosen is also one of the best ways to document the implementation.
Where codegen MDA starts to fall over is (1) when the implementation requires a number of different "one-off" solutions that can't easily and naturally be incorporated in the model (for instance, where the model is based on an early, simplistic view of how the application should behave; late-arriving requirements can clobber a model's utility), (2) where developing or installing, configuring and customizing the modelling tool is more work than writing the code (when the developer can whip up the code faster than you can install, configure and customize the modelling tools for your application), and (3) where you need to spend extra effort installing and describing the modelling tools for downstream maintenance organizations.
(3) doesn't prevent MDA, but it does place extra emphasis on having the model generate maintainable code so you can cut away from the modelling tool at some point.
MDA is quite useful, but like every other TLA and FLA (SOAP?, XML?, COM?, SQL?, REST?) or four letter word (Java? Perl?), you should only use it where it helps meet your needs.
- Barrie
MDA's central failing is that current implementations use UML. As Booch et al. say "the full value of MDA is only achieved when the modeling concepts map directly to domain concepts rather than computer technology concepts." (MDA Manifesto, Grady Booch, Alan Brown, Sridhar Iyengar, Jim Rumbaugh, Bran Selic, MDA Journal, May 2004). In other words, MDA is the OMG's attempt to copy something that has been going strong for over a decade: Domain-Specific Modeling.
Domain-Specific Modeling is about creating modeling languages whose concepts map to your problem domain concepts, rather than everybody's solution domain concepts. UML concepts - at least those from which code is generated - are from the solution domain: classes, attributes, operations. DSM concepts are different for each domain - buttons and icons for digital watches, menus and text message sending for phones, mouse buttons and cacodemons for FPS games. Models are thus at a significantly higher level of abstraction, and independent of any particular implementation technology. They capture just enough (and no more) detail to enable full code generation - and of course the code generators too are domain-specific.
As always, the more specific a tool is for a job, the more productive it can be for that job. It turns out it's best to create a modeling language and generator specific to a single range of products for a single company: the cost of creating the language is more than offset by the higher productivity, providing you're building more than a couple of products. Industrial cases of DSM consistently show productivity increases of 500-1000%. Compare that with MDA, where even vendor-sponsored studies show only 35%.
Whilst it's early days yet for the Microsoft DSL tools, other mature DSM tools exist, both for commercial and research use. I've been involved with one for 13 years, so a) you should suspect me of being biased, and b) I have some small experience of how this stuff actually works in the real world. One key thing is that with a decent DSM tool, building your language, code generator and modeling tool support has to be easy - both at the start and as you evolve the language based on experience. Even our largest customer - with several hundred users and the biggest modeling language we've seen - only has one person assigned part time to that task.
Or do you want to be a manager? MDA tools are great for managers who want to get code done quickly, with no art, exactly to specs. These people are the type who played Nintendo growing up instead of getting their parents to buy a real computer- people who care about end results more than the process of getting to those end results. MDA is just the latest version of RAD- and while RAD has it's place, you sacrifice something for getting the program done fast in terms of useability and resource utilization, as well as just plain art of coding. But if your ends justify your means, and profit/cost is the overriding factor in all that you do, well, memory, hard drives, and microprocessors are cheap in comparison to good code.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
GME: The Generic Modeling Environment
"The Generic Modeling Environment is a configurable toolkit for creating domain-specific modeling and program synthesis environments. The configuration is accomplished through metamodels specifying the modeling paradigm (modeling language) of the application domain. The modeling paradigm contains all the syntactic, semantic, and presentation information regarding the domain; which concepts will be used to construct models, what relationships may exist among those concepts, how the concepts may be organized and viewed by the modeler, and rules governing the construction of models. The modeling paradigm defines the family of models that can be created using the resultant modeling environment."
StarUML: The Open Source UML/MDA Platform
"StarUML - The Open Source UML/MDA Platform
StarUML is an open source project to develop fast, flexible, extensible, featureful, and freely-available UML/MDA platform running on Win32 platform. The goal of the StarUML project is to build a software modeling tool and also platform that is a compelling replacement of commercial UML tools such as Rational Rose, Together and so on."
Recommended book:
The Laws of Software Process: A New Model for the Production and Management of Software
"Phil's first book covers in depth the issues he has been exploring in his The Business of Software column in Communications of the ACM, namely that software is best thought of as a knowledge storage medium and software development as a knowledge acquisition activity."
And this corroborates my experience: defining a model that is detailed and correct enough to generate release code (as opposed to prototype code) is every bit as hard as writing the code itself.
MDA's are great for quick prototyping, but once you get into the optimization and functional peculiarities of the business domain, the modeling tools get in the way. Once you find yourself writing/designing your business objects and logic to be compatible with the tool, you've gone too far. Drop the tool, stop looking at the schematics and start focusing on the mechanics.
If you post it, they will read.
You correctly point out that poor or inadequate qualification contributed to the downfall of the project. Which leads to the point: What was the purpose of MDA for this project?
...
IMHO there exists the theory in PHB's minds that if you can do something graphically, it's much easier and you can hire less qualified people to accomplish great feats. The whole description of the project had this written all over and in big letters.
Just think of joice quotes from the GP like "caused a large divide to develop", "system people, generally well qualified programmers, had little or no interest", "application programmers, on the other hand, had absolutely no understanding", "OO modeling concepts seemed to confuse the business domain experts".
I can literally see some PHB there telling his peers: "Great, lets get rid of all this command line stuff and text editing, spend x amount of money on fancy software, get the same result faster and overall save a bundle!" Unfortunately a person who knows how to design a great software architecture is hard to find but still required, whether you use MDA or whether you have cheap code monkeys for the grudge work.
And if you compare the likely output from one genius + MDA versus a similar genius + many code crunchers, chances are the second choice works out better. While the many code crunchers may not be geniuses, they usually do contribute useful thoughts and feedback, something an MDA doesn't! Have you ever seen a GUI design tool which told you straight in your face: "Don't put this menu item here, nobody would find it there!" ?
You may need fewer people but a much greater genius to make a project fly with MDA. Unfortunately it's just those geniuses who are so hard to find in the job market. The reason why PHBs are willing to spend big money on MDA is because they want to save the money spent on the big genius!
If you've seen many projects (as I'm sure you have), you've seen even more people who are in the wrong position but the only people available at the time. And sometimes it still works out, especially if they are able to learn their way into the project internals. This, of course requires hiring smart people. The use of MDA was most likely not the reason for said project to fail (at least not technically), but chances are that the marketing of MDA caused the business guys at the responsible company to make poor hiring decisions.
While the late 90s were the time of the software gods (usually some social misfits with great coding skills and even more attitude, think dotcom), the last few years have tried to completely do without them. Evidently this way doesn't work so well either
Having come from a company where we had built everything ourselves in the past (dbconnectivity, caching, logging, etc) I wanted to move in the right direction with a new startup and new product. Spring and hibernate were a must and leveraging existing libraries was key as well. I came upon AndroMDA and while the learning curve was a bit steep (banging head on desk for a week), eventually it became extremely useful. Additionally, the small handful of guys who 'are AndroMDA' are incredible with support and help.
1) You can describe your entire system with a model and validate it in MagicDraw.
2) You focus more on the design of the system rather than the monkey coding.
3) It allows changes in the system to be made without much headache. You simply provide the business logic in the Spring service Impls.
4) Adding OCL (Object Constraint Language) allows you to explicity put your queries in the model and get them validated as well. OCL will translate to HQL in code which will ultimately get translated to SQL during runtime.
Ultimately, will I use MDA again?
* Definitely!
What are the problems?
* In my opinion, it's a steep learning curve. I wasn't a pro in UML design, so that may been a problem at first. Additionally, you have to learn to understand how the models are designed and how they interact with other diagrams.
There's a number of good books about this:
"MDA Distilled" - great overview and how MDA can help you
"Enterprise Patterns and MDA" - a GREAT selection of existing patterns for the MDA world
"The Object Contraint Language" - a great reference for understanding OCL
So how do you feel about the argument that LISP's power comes from the ease in which one can create inline DSL's (Macros)
"MDA's central failing is that current implementations use UML. "
MIT's Alloy Analyzer doesn't, and yet here we are several years later. IMHO I simply think that we're not ready for anything beyound "cowboy programming" level. Just read all the responses to this "ask slashdot", and read between the lines.
"If it were really easier to use code generators, one would expect less skillfull people to be able to use them; is this the case?"
So does tools like Maya and Lightwave mean that "less skillful people" are creating more mediocrity, and does that mean we shoud go back to "hand drawn methods" because it will raise the quality, and keep out the undesirables?
How about programmimg? Real men do it all in machine language, and tools like compilers, and other high-level languages allow the "less skillful" to invade the programming profession, lowering our high standards.
"Replacing one set of syntax (that of code) with another (that of the graph "language", reflected in it's file format), without taking away any of the complexity."
That's *assuming* two things. One the audiance is the same. e.g. programmer. And two that both are saying the same thing. e.g. "a picture is worth a thousand words".
What are the drawbacks, difficulties and limitations of MDA?
I wish I had a dollar for every time somebody in charge of "the model" (multiple people from different projects at different companies) told me that the requested change wasn't possible because the tool didn't support that, leading the feature to be devloped by a macro around the generated code, or in duplication of hand generated accessor transformation across a large code base, or worse.
If you have a cookie cutter project, it's great. If you don't your tool becomes the ball and chain. Make sure the tool you pick has the features you need, and make sure there isn't a zealot in charge of tool selection.
Automate the repetitive parts, like the code that wraps a stored procedure into a language specific call (If you have lots of stored procedures), and maybe some of the UI if it follows a very clear pattern (which you find after writing the same thing with a number of variants, like the number and type of fields in a record).
You can also generate automated tests for the generated code, to test for build consistency, etc.
Avoid writing your own database access layer and use a proven o/r mapper like hibernate, it simplifies your life incredibly. Note that for some operations you still need to write stored procedures (bulk processing).
Writing your own code generator very, very fun and a great learning experience but chances are there is something better out there that already works, remember that you are writing an application not a code generator.
If it's an area you don't have a lot of experience with, estimating can be very hard. Do some research but be prepared to do it the conventional way if time is a limiting factor.
I've been working with AndroMDA for about a year and, while I sympathise with the dire experiences recounted above, my reaction is, "But that isn't the case with AndroMDA!"
...
... , but overall, I still prefer the safety net of being in control of the coding process, and actually understanding what is going on under the hood.
... and ...
.NET corporate architecture goes immensely beyond that. There is an AndroMDA .NET suite underway. AFAIK, at this time it is not possible, but in the mid-term you will be able to generate a J2EE and a .NET system simultaneously from a single UML model. This is incredible leverage of the "amount of knowledge of a language required to create a decent app"
If your development team has already gone down the widely accepted route of -- Eclipse / Ant / xDoclet / Subversion / Spring / Hibernate / Tiles / Struts / jBoss -- you would be crazy not to give AndroMDA a chance. It permits you to continue doing exactly what you do now, but takes over the donkey work. If Maven is like Ant on steroids; AndroMDA is like xDoclet on steroids.
This SlashDot topic was sent to me by a colleague worried about my push for MDA where we work. Rather than comment privately just to him, I thought I'd make my views public. I hope you find the following helpful
I've had the same experience in the past with products that make all the easy bits easier -- and the hard bits impossible.
AndroMDA generates established best-practice Java patterns in a clear and concise structure. All the generated code is visible and available for editing (I refresh my Eclipse project and see all changes). Code that you need to alter is kept in separate directories and written there once. On the rare occasions in which you need to substitute 'unalterable' generated code with something special, you specify a substitution directory that precedes the targets directory in the build path. Due to the very consistent and sensible pattern adherence, there are a lot of very small java files. When you do need to substitute, the likelihood of your substitution AND the original both needing edits is low.
My experience is that I am completely in control of the coding process. A key thing about AndroMDA is that it actually tries to do very little . The yet-to-be-generated code resides in Velocity templates. AndroMDA loads UML into an object map (metafacade) that Velocity scripts traverse while filling in template fields as they go. Those many Velocity scripts are orchestrated with Maven. By leveraging so many best-in-class OSS projects the AndroMDA team keeps its own efforts very tightly focussed.
I have only looked briefly at xDoclet, but if you are concerned about "being in control of the coding process" AndroMDA is scarcely more invasive than xDoclet.
Then you are at square one, writing a custom MDA that works for you.
Near the start of the project, the company had hired an MDA guru, who designed the MDA and, I belive implemented most of its core. Over time the MDA core portion expended in into a massive code generator that took hours to run and required tons and tons of memory.
That is about as necessary and sensible as creating your own http server. If you have someone breathing down your neck for results, don't even think about creating your own MDA. If you have that much time on your hands &/or a special need, create a new cartridge for AndroMDA that takes over where its existing cartridges leave off.
Seems to me that the amount of knowledge of the tools required for these code generators closely matches the amount of knowledge of a language required to create a decent app.
In the case of AndroMDA that's about right. However, developing an n-tier J2EE &/or
My J2EE development experience ended more or less
Harder, because you have to waste all that time and effort getting the shelfware the boss got from Big Company to try to actually work. Am I implying that the tools are buggy? No, I'm saying that MDA tools are created to fulfill a marketing need and aren't ever intended to actually work beyond what the sales engineer shows you. The primary product development requirement is its ability to sell for $kilobucks.
I've never used LISP on a big enough project to be sure, but others' experience is certainly like you say. Smalltalk is similar. Both are great. One downside is that you are constrained by the original syntax of the language. Smalltalk is somewhat better than LISP there, since it reads more like natural language. Another downside is the textual format itself: any time you want to refer to something else, you have to do it by typing the same series of characters. It's much more intuitive to use a graphical representation, with a line to the other node. Good modeling tools also let you refer directly to another object, e.g. in UML the data type of an Attribute could be a reference to another Class you have created. The Attribute refers directly to the Class, rather than just copying its name, so if the name is later changed in the Class, the Attribute still points to the right thing (and sees the right name).
Alloy isn't MDA - that's an OMG trademark (and not a very good description: in what way is the architecture model-driven?). It looks like Alloy is a DSL, and it may be that the Alloy Analyzer extends that to a graphical DSM language. If I'm reading right, though, the Analyzer simply shows an analysis of a textual Alloy program in a graphical format - I haven't spotted anything that says you can build the graphical models first.
In any case, your point was presumably that you think Alloy is a good solution for improving the software development process (in some situations). That's great, and there are loads of things like it. None has yet had a major effect on the way the whole community builds software. Certainly a major reason for that is the "cowboy programming" you mention. Most organisations are at that level, but there is a growing number who are moving up the SEI's CMM maturity scale (or even some more realistic measure of maturity).
Most IT systems and game engines are developed from scratch plus copy-paste from old systems, with some 3rd party frameworks and in-house components. For other kinds of systems, like embedded systems, companies tend to have a larger number of programmers working on a larger number of products, but with more similarities between those products, and longer lifespans for these product families. This situation has pushed them to improve their software development processes, making reuse more systematic and paring down the new work needed for each product to a minimum. Those are the industries that are first to reap the benefits of Domain-Specific Modeling.
DSM will do to code what code did to assembler, what assembler did to machine code, and what chips and machine code did to building your own hardware. The industry as a whole will always need the lower levels, and there will still be advances in them, but most developers will be insulated from them and can work at a higher level of abstraction and productivity.
I recommend the book at the end of that list. He really does have some good insights on the software development process, and a possible future.
Four years ago, a friend of mine
Asked me to write this rhyme...
"My main beef with AndroMDA is trying to go straight from model to code. IMHO there should be an intermediate step (something that MDA, with PIM->PSM transformation, somehow contemplates)."
AndroMDA has the intermediate PSM, they are called "meta-facades".