Comment AndroMDA is special! (Score 3, Insightful) 62
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!"
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 ...
... , 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.
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.
... and ...
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 .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"
My J2EE development experience ended more or less with the arrival of TomCat in 2000. I spent the intervening time, up until a year ago, in UML work and project management. In early 2005 I was faced with teaching a badly obsolescent development team Eclipse, Ant, xDoclet, Subversion, Spring, Hibernate, Tiles, Struts and jBoss, with only scanty knowledge of any of them myself! I had to find a better way. Now I'm working very successfully with all of those, with the same scanty knowledge I started with! I can depend on the AndroMDA team's vastly superior knowledge to have created the right templates in the right patterns for the right tools, where I couldn't if I had five times as much time as I have. I merely have to ensure that my UML properly reflects the problem domain and I see eminently sensible code being generated for me.
The state of the project when I arrived (which was to implement optimizations to one of XML based parts of the code generator) was:
AndroMDA's generated code is only slightly bulkier than the hand-written code of an ordinary development team. A very experienced team might have a class library that merges into one tight set of classes what AndroMDA generates in many small variations. While this may result in a much smaller ear, the benefits of their class library accrue at development time, not at runtime, so the AndroMDA decision to live with a proliferation of similar generated files and gain the benefit of simpler, tighter templates has a large up-side (understandable code) and a tiny down-side (somewhat larger ears, wars and jars).
AndroMDA is great for quick prototypes -- once you are skilled with it. Admittedly, getting that skill is not quick. It took me at least a month to get confident. If you are already a Spring / jBoss wizard with a mature architecture then the pay-off may seem remote. But, if you inherit such a wizard's architecture you'll most likely end up hating him. On the other hand, if you inherit an AndroMDA wizard's project you'll be in heaven. Maintenance will be quite straightforward, and all the deeper complexities will be supported in the AndroMDA team's very responsive forum. You won't be all alone in the jungle.
As I say, AndroMDA does take time to learn; but it takes a LOT less effort to learn than becoming proficient with EJBs or with Spring/Hibernate.
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.
This is not applicable in the case of AndroMDA. Most of the development team will be generating business focussed apps sucessfully using AndroMDA as-is. Existing Struts developers will become faster Struts developers. Existing Hibernate developers will become faster Hibernate developers. Existing Web Services developers will become faster Web Services developers. You may want one wizard off in the corner performing special tweaks to templates and metafacades, but for the bulk of the code of the business, it's un-necessary.
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.
Obviously, there are (at least) two types of maintenance problem: application maintence and infrastructure maintenance. The whole point of AndroMDA is that the UML so thoroughly describes the code that no further documentation is necessary. When you've understood the model you've understood the application code. Infrastructure code, the 'donkey work' that AndroMDA handles so expertly, conforms to best-practice patterns such that no system developer should have any difficulty understanding all of it.
AndroMDA builds on all the benefits of many dozens of OSS projects, Maven especially. Maven, among many other things, is a tool for continuous build, continuous test. The load and stress testing you should already be doing applies unchanged to an AndroMDA project, and can be run automatically from your Maven scripts.
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.
In other words, the "MDA guru", a snake-oil merchant with a home-brew MDA, was *also* touting a home-brew O.R. mapping layer. X-( String him up by his short and curlies!
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 worked with those stinking things and you are absolutely right, they caused more problems than they solved, not to mention costing the earth. The real problem was, when they went sour on you, you hadn't a hope in hell of figuring out what went wrong.
Aside from being free as a bird, AndroMDA is wide open, so tracking down a problem is a question of educational exploration (seeing Java patterns well implemented) than guessware and "shots in the dark".
Where codegen MDA starts to fall over is ... where you need to spend extra effort installing and describing the modelling tools for downstream maintenance organizations.
This again is an appropriate criticism of roll your own MDA. My experience is that AndroMDA reduces the need for documentation almost to zero. The UML is a *very* thorough description of the system. It is also complete, consistent and tested UML, because the developers will not get through a cycle of iterative development of their piece of the problem while the UML is defective. The UML is the project documentation and, unlike UML done to plan a project, it is never obsolete.
It's worth adding that AndroMDA encourages a clear and strong separation between presentation layer, service layer and persistence layer. This becomes, in effect, a kind of "positional notation" (in the mathematical sense), that documents implicitly an artifact's role and purpose as a function of its logical location.
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!
Wrong.
AndroMDA permits short spells of very productive work on isolated bits of a large project without any risk of losing sight of the big picture, and very little effort needed to step into the code, understand what it is doing, and implement the fix, new feature or whatever. This means that a Web Service expert can do a thorough professional job on a service, while fleshing out a Stuts prototype of how the service should be accessed and a Hibernate prototype of the persistence upon which the service would depend. He can hand off those two bits to a Hibernate expert and a Struts expert, who can apply all their expertise to getting them exactly right, maximally efficient and conformant with existing persistence-layer artifacts and presentation-layer best-practice. And, I don't mean that they would look at the rough draft, understand it, and then start again, they would easily alter it and elaborate upon it, without confusion or wasted effort.
Each of those three experts would continuously up-grade his/her professional skills as contributor to the corresponding AndroMDA cartridge forum.
In my experience the AndroMDA team will turn around a submitted valid patch to a template or cartridge, in a version SNAPSHOT, in less than a week! This means that every time your team encounters a needed improvement to an AndroMDA artifact, it quickly becomes part of the shared code-base of all AndroMDA projects and is party to all the corrective measures, on an equal footing with the rest of the AndroMDA, of the entire AndroMDA community. In other words, your problem domain logic remains an in-house venture, while your architecture becomes an Open Source collaborative venture. This means that the more of your architecture you see successfully assimilated into AndroMDA, the less of it you will have to maintain! (And if you can't get it assimilated you should probably throw it out and use the AndroMDA equivalent.)
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.
It's hard to respond to this kind of dogmatism, but I'll try.
AndroMDA's BPM4Struts cartridge uses UML Activity diagrams to describe the 'conversation' between the end-user and the Struts server. Each server-side Action State represents a single data call to a Controller function. Each client-side Action State represents a single web page. Each transition from the former to the latter represents an HTTP response. Each transition from the latter to the former represents an HTTP request. You can include decision points, tagged values and parameters as necessary to completely describe what a Struts application would do. BPM4Struts generates a complete working Struts application with sample data for all fields, breadcrumbs, help links, menus, cascading style sheets, tiles, news & events sidebars, etc. All of these are provided in such a way that you can replace them when the time is right to do so. Meanwhile your customers can tinker with a realistic working use-case within a day of requesting it, even though there is as yet neither a persistence layer nor a service layer behind it.
Furthermore, all of the goodies I mention come from templates, so the cascading style sheets, the tiles definitions, the sidebars etc, will conform to you institution's standards as you refine them to do so.
The overall experience is like describing in Activity diagrams what you want a Struts expert to develop for you ... but he does it in two minutes!
AndroMDA's Spring/Hibernate cartridge uses UML Class diagrams to describe your service layer and the persistent entities the service layer manages. Aggregation dependencies, composition dependencies, whether one-one, many-one, one-many or many-many can be described completely. The resulting code contains interfaces, base classes and implementation classes for each entity, as well as interfaces, base classes and implementation classes for the DAO for each entity. If you model a class, apply a <<Value Object>> stereotype to it and make an <<Entity>> dependant upon it, the DAO will generate further Find and Load functions that can return the entity itself, a collection of those entities or a VO for the entity or a collection of those VOs. In the latter two cases, automatic transforms are generated to cause the creation of default run-time value objects. Those transforms defer to no-action 'impl' classes to which you can add special transform functionality if the defaults are inadequate.
This doesn't even scratch the surface of the 'donkey work' the cartridge gets out of the way. Like I said the same way above ... the overall experience is like describing in Class diagrams what you want a Hibernate expert to develop for you ... but he does it in two minutes.!
All comments gratefully received.
Hasan
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 with the arrival of TomCat in 2000. I spent the intervening time, up until a year ago, in UML work and project management. In early 2005 I was faced with teaching a badly obsolescent development team Eclipse, Ant, xDoclet, Subversion, Spring, Hibernate, Tiles, Struts and jBoss, with only scanty knowledge of any of them myself! I had to find a better way. Now I'm working very successfully with all of those, with the same scanty knowledge I started with! I can depend on the AndroMDA team's vastly superior knowledge to have created the right templates in the right patterns for the right tools, where I couldn't if I had five times as much time as I have. I merely have to ensure that my UML properly reflects the problem domain and I see eminently sensible code being generated for me.
The state of the project when I arrived (which was to implement optimizations to one of XML based parts of the code generator) was:
- The application required many many hours to generate/compile.
- The resulting code was so large and complex that any meaningful analysis of it was virtually impossible.
- It was also impossible to try out quick changes or do any kind of rapid prototyping.
- The architecture and tools were so complex that new staff required long training periods in order to be productive,
AndroMDA's generated code is only slightly bulkier than the hand-written code of an ordinary development team. A very experienced team might have a class library that merges into one tight set of classes what AndroMDA generates in many small variations. While this may result in a much smaller ear, the benefits of their class library accrue at development time, not at runtime, so the AndroMDA decision to live with a proliferation of similar generated files and gain the benefit of simpler, tighter templates has a large up-side (understandable code) and a tiny down-side (somewhat larger ears, wars and jars).
AndroMDA is great for quick prototypes -- once you are skilled with it. Admittedly, getting that skill is not quick. It took me at least a month to get confident. If you are already a Spring / jBoss wizard with a mature architecture then the pay-off may seem remote. But, if you inherit such a wizard's architecture you'll most likely end up hating him. On the other hand, if you inherit an AndroMDA wizard's project you'll be in heaven. Maintenance will be quite straightforward, and all the deeper complexities will be supported in the AndroMDA team's very responsive forum. You won't be all alone in the jungle.
As I say, AndroMDA does take time to learn; but it takes a LOT less effort to learn than becoming proficient with EJBs or with Spring/Hibernate.
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.
This is not applicable in the case of AndroMDA. Most of the development team will be generating business focussed apps sucessfully using AndroMDA as-is. Existing Struts developers will become faster Struts developers. Existing Hibernate developers will become faster Hibernate developers. Existing Web Services developers will become faster Web Services developers. You may want one wizard off in the corner performing special tweaks to templates and metafacades, but for the bulk of the code of the business, it's un-necessary.
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.
Obviously, there are (at least) two types of maintenance problem: application maintence and infrastructure maintenance. The whole point of AndroMDA is that the UML so thoroughly describes the code that no further documentation is necessary. When you've understood the model you've understood the application code. Infrastructure code, the 'donkey work' that AndroMDA handles so expertly, conforms to best-practice patterns such that no system developer should have any difficulty understanding all of it.
AndroMDA builds on all the benefits of many dozens of OSS projects, Maven especially. Maven, among many other things, is a tool for continuous build, continuous test. The load and stress testing you should already be doing applies unchanged to an AndroMDA project, and can be run automatically from your Maven scripts.
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.
In other words, the "MDA guru", a snake-oil merchant with a home-brew MDA, was *also* touting a home-brew O.R. mapping layer. X-( String him up by his short and curlies!
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 worked with those stinking things and you are absolutely right, they caused more problems than they solved, not to mention costing the earth. The real problem was, when they went sour on you, you hadn't a hope in hell of figuring out what went wrong.
Aside from being free as a bird, AndroMDA is wide open, so tracking down a problem is a question of educational exploration (seeing Java patterns well implemented) than guessware and "shots in the dark".
Where codegen MDA starts to fall over is
This again is an appropriate criticism of roll your own MDA. My experience is that AndroMDA reduces the need for documentation almost to zero. The UML is a *very* thorough description of the system. It is also complete, consistent and tested UML, because the developers will not get through a cycle of iterative development of their piece of the problem while the UML is defective. The UML is the project documentation and, unlike UML done to plan a project, it is never obsolete.
It's worth adding that AndroMDA encourages a clear and strong separation between presentation layer, service layer and persistence layer. This becomes, in effect, a kind of "positional notation" (in the mathematical sense), that documents implicitly an artifact's role and purpose as a function of its logical location.
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!
Wrong.
AndroMDA permits short spells of very productive work on isolated bits of a large project without any risk of losing sight of the big picture, and very little effort needed to step into the code, understand what it is doing, and implement the fix, new feature or whatever. This means that a Web Service expert can do a thorough professional job on a service, while fleshing out a Stuts prototype of how the service should be accessed and a Hibernate prototype of the persistence upon which the service would depend. He can hand off those two bits to a Hibernate expert and a Struts expert, who can apply all their expertise to getting them exactly right, maximally efficient and conformant with existing persistence-layer artifacts and presentation-layer best-practice. And, I don't mean that they would look at the rough draft, understand it, and then start again, they would easily alter it and elaborate upon it, without confusion or wasted effort.
Each of those three experts would continuously up-grade his/her professional skills as contributor to the corresponding AndroMDA cartridge forum.
In my experience the AndroMDA team will turn around a submitted valid patch to a template or cartridge, in a version SNAPSHOT, in less than a week! This means that every time your team encounters a needed improvement to an AndroMDA artifact, it quickly becomes part of the shared code-base of all AndroMDA projects and is party to all the corrective measures, on an equal footing with the rest of the AndroMDA, of the entire AndroMDA community. In other words, your problem domain logic remains an in-house venture, while your architecture becomes an Open Source collaborative venture. This means that the more of your architecture you see successfully assimilated into AndroMDA, the less of it you will have to maintain! (And if you can't get it assimilated you should probably throw it out and use the AndroMDA equivalent.)
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.
It's hard to respond to this kind of dogmatism, but I'll try.
AndroMDA's BPM4Struts cartridge uses UML Activity diagrams to describe the 'conversation' between the end-user and the Struts server. Each server-side Action State represents a single data call to a Controller function. Each client-side Action State represents a single web page. Each transition from the former to the latter represents an HTTP response. Each transition from the latter to the former represents an HTTP request. You can include decision points, tagged values and parameters as necessary to completely describe what a Struts application would do. BPM4Struts generates a complete working Struts application with sample data for all fields, breadcrumbs, help links, menus, cascading style sheets, tiles, news & events sidebars, etc. All of these are provided in such a way that you can replace them when the time is right to do so. Meanwhile your customers can tinker with a realistic working use-case within a day of requesting it, even though there is as yet neither a persistence layer nor a service layer behind it.
Furthermore, all of the goodies I mention come from templates, so the cascading style sheets, the tiles definitions, the sidebars etc, will conform to you institution's standards as you refine them to do so.
The overall experience is like describing in Activity diagrams what you want a Struts expert to develop for you
AndroMDA's Spring/Hibernate cartridge uses UML Class diagrams to describe your service layer and the persistent entities the service layer manages. Aggregation dependencies, composition dependencies, whether one-one, many-one, one-many or many-many can be described completely. The resulting code contains interfaces, base classes and implementation classes for each entity, as well as interfaces, base classes and implementation classes for the DAO for each entity. If you model a class, apply a <<Value Object>> stereotype to it and make an <<Entity>> dependant upon it, the DAO will generate further Find and Load functions that can return the entity itself, a collection of those entities or a VO for the entity or a collection of those VOs. In the latter two cases, automatic transforms are generated to cause the creation of default run-time value objects. Those transforms defer to no-action 'impl' classes to which you can add special transform functionality if the defaults are inadequate.
This doesn't even scratch the surface of the 'donkey work' the cartridge gets out of the way. Like I said the same way above
All comments gratefully received.
Hasan
