Model Driven Architecture State of the Union

Discussions

News: Model Driven Architecture State of the Union

  1. Model-Driven Architecture, or MDA, is still evolving as a standard, and many products now claim to be compliant with it and early adopters are developing apps with them. An article on ADTMag discussses the concept, developer mistrust, available MDA tooling, and the experiences of some MDA early adopters.

    Read Tools for the code generation.

    Threaded Messages (106)

  2. MDA vs. Java[ Go to top ]

    The problem with MDA (as a standard/specification from OMG or any other standards from such an organization) is that they do not give a you a free reference implementation. This is actually the biggest advantage of Java as a platform. Sun + JCP do not only give you the specifications but they also provide you with free reference implementations + test suites for those specifications.

    So, in MDA world each vendor can implement MDA as free as they like. This has been seen in CORBA world. I would like to know, whether there are organizations already used MDA with tool X and then they changed into tool Y without any modifications or problems (I know there is a spec like XMI but I need a fact ;-)). The compatibility problems begin already in your UML diagram tool, if you want to change to another UML tool for example.

    Without any free reference implementation of MDA from OMG (just like J2EE reference implementation from Sun), MDA won't get any further, IMO (I know there is a good MDA Open Source project like AndroMDA but this is not the same like Tomcat for servlet's reference implementation).

    At the end we always need a "language" to write our application. The question is:
    - Will MDA (Top - Down approach) be our language? If so, everything will be done in UML, OCL, etc. You model your PIM and transform it into your PSM. In couple of years maybe you just build your PIM and you don't care about your PSM, because you can compile your PIM directly into a running application (you also don't care anymore in what language your application will be running, so you don't have to implement your application in Java anymore, you just have to use UML more precisely).
    - Or maybe Java (Bottom - Up approach -> see meta data, Together's approach and Sun's research projects: Ace, Jackpot) will be our language? Is visualization just one of the many aspects in Java? Using tool like Together can make this very real. With many extensions to Java, we will see that Java as a language will become very highly abstracted from the maschine itself. We already see this with GC, VM. and now the coming meta data, etc.

    At the end of the day, all we want is a higher abstraction level language to write our applications, as the history always tells us. So let's the competition begins!

    Regards,
    Lofi.
    http://www.openuss.org
  3. RE: MDA vs. Java[ Go to top ]

    Firstly I have to say I don't know much about MDA and therefore am probably missing something. But I don't see how it will replace the need for languages such as Java (which is the ultimate goal is it not?)

    The advantage of text is that it is concise. They say "a picture says a thousand words" therefore in the realm of computers how do you visually express your logic without ambiguity. Or more importantly is it better (easier/faster) to visually express logic then it is textually?

    I find UML useful to show the domain objects and how they relate. And the important workflows in the system (eg. order processing). But I find text to be the best medium for details.

    Also remember UML diagrams are as the name says, just models. For instance, when explaining how gravity works you might place objects onto a sheet to show how the heavier objects bend the sheet the most and therefore pull in the other objects. But in reality space is 3D (unlike the 2D sheet and therefore gravity is more complex the in this demostration. Anyway I'm getting offtopic now.

    My 2 cents
    Cameron Zemek
  4. RE: MDA vs. Java[ Go to top ]

    I don't think any serious MDA proponents are actually proposing MDA will replace programming languages anytime soon. As a matter of fact that would eliminate the Platform Specific Model (PSM) layer of MDA. Basically, MDA proposes that high-precision modeling can render a design so complete that tools should be able to generate the code to create the technical architecture of an application automatically (regarding implementation language as an open variable). It's supposed to generate the application's architecture; that's why it's called Model Driven Architecture; not Model Driven Development. If you read the OMG spec and the books that are out about it, they're being very careful to avoid overhyping it like IBM and Knowledgware and others overhyped CASE in the late 80s/early 90s (yup; I'm old enough to remember that).

    The REAL conversation should be about how MDA fits into an overall software development methodology (realizing additional and highly disciplined coding still needs to be done manually after the results of MDA have created an architecturally complete code base). Nobody is seriously talking about MDA replacing programming skills or languages; it's supposed to augment both.
  5. RE: MDA vs. Java[ Go to top ]

    I'd disagree a bit, as a few number of MDA tool vendors claim it to be the be-all end-all thing.
    OMG might not be overhyping it, but the marketing departments/sales people of various vendors will. And I think if anything can kill any concept, it's overhyping it.
    Regards,
    Vlad
  6. Benefits of MDA[ Go to top ]

    The real benefit of MDA at the moment is the seperation of "application" and "system" developers.

    The system developers build the whole infrastructure and the application developers build the whole applications. This seperation has many advantages to big companies as the application developers should only understand the domain of the application (UML, OCL -> PIM) and not the technical/architectural concepts, which should be understood by the system developers (PSM -> target system/J2EE).

    As you can see, there are only few good architects in J2EE but there are a lot of application developers available. The idea is just simple: let the experts do all the architectural design (PSM) and any other application developers should only use those design (PIM). You can save a lot of time and money by doing this in big companies.

    Lofi.
    http://www.openuss.org
  7. The real benefit of MDA at the moment is the seperation of "application" and

    > "system" developers.
    >

    In my experience there is no clear separation between "application" and "system" developers. One of the strangest observations I make is that people still believe this. A lot of "system" tasks (or concerns if you want a more hyped term) are more often than not deeply interwoven with the "system" tasks. Most trivial systems show this and almost all complex systems do. Concurrency strategy, access control etc. are usually at the very heart of "application logic". This being the case, it is very likely that such a separation will actually *increase* project risks, because the "system developers" output may not match the "application programmers" requirements.
  8. Application vs. System developers[ Go to top ]

    yes, you're right. That's why we have a lot of problems with J2EE ;-) J2EE also tries to seperate those concerns (Container + App). At least J2EE's vendors hope that the application programmers should never need to touch the "container concepts" by themself. At the end we know, that we also have to learn how the container really works, to write a good J2EE application ;-)

    This problem is also applicable in every single computer science aspects. To become a good application developer, you need to understand how a computer works ;-). This is also why we at the university never teach our students to use wizards-, drag&drops- and assistants-like environment because they should understand the concept behind them ;-)

    So, you think that the concept of PIM and PSM is worthless?

    Lofi.
    http://www.openuss.org
  9. Application vs. System developers[ Go to top ]


    > So, you think that the concept of PIM and PSM is worthless?
    >

    Hmm, a good question. I think that they are, well, of very limited value. Or, lets put it a bit differently: What is advocated as the platform for a platform independent model - and is thus at the core of MDA - is in my opinion inadequate for describing the platform independent aspects/concerns of most software systems.

    Likewise, if we end up with "application developers" doing the PIM and "system developers" doing the PSM, this seems like the wrong way. One could argue, that developing in a PIM should be *easier* and that thus it should be the domain where the application developers would be working.

    Also, I find the term MDA fully inadequate, the PSM is merely mapped from the PIM. That's it. The model does not drive the architecture, it is mapped to an architecture (or one out of n architectures are selected). True MDA would derive from my model and my usage pattern, what kind of architecture is suitable for my application (1-tier, 2-tier, n-tier, Hub-and-Spoke, Bus-Like...), what kind of security infrastructure I am most likely to use, what persistence mechanism and communication infrastructure (HTTP, SOAP, RPC, IIOP...) fits my usage patterns best etc.
  10. Maybe it's just semantics and maybe it's not, but for one thing, I don't think it's "application vs system developers"; I think it's more like "application architecture before application development".

    One excellent point Karl makes is that it's the transformation from PIM to PSM where the "magic" of MDA happens. I'm studying a particular MDA tool (just starting) and also reading David Frankel's MDA book. According to the vendor of the tool I'm studying, they apply a set of "technical" patterns to transform the PIM to the PSM.

    This vendor stores all the metamodel (PIM) information as Meta Object Facility (MOF) within XMI on the file system and they provide an API to that repository that allows the customer's architects to "influence" the architecture that the tool creates for the application as it generates the PSM from the PIM.

    Also, in this tool, the PSM is not the final executable code layer. There is another "Code Model" layer beneath the PSM (or "Application Model") and therefore another transformation process. This final transformation to the Code Model involves the tool applying a set of "implementation" patterns (again, this process can be "influenced" via API) - these are the design patterns we are most familiar with (e.g., GoF patterns; J2EE Blue Prints; etc.)

    I'm not sure to what degree this more detailed discussion changes or doesn't change anyone's mind philosophically about MDA, but I think it increases the value of such a discussion to introduce more detail at this point. I see the emerging MDA tool landscape as being new, and therefore prone to change and problems, but also as potentially providing significant improvements in shortening development cycles and improving quality, by imposing the role of architecture (many projects severely lack this skill set today). I'm sure there are other IT shops with excellent architects involved; for those, maybe MDA tools in their current state don't offer the value. But for the vast majority, I think MDA makes a lot of sense, provided they offer a usable API to "influence" the magical model transformations.
  11. Application vs. System developers[ Go to top ]

    So, you think that the concept of PIM and PSM is worthless?

    >
    > Hmm, a good question. I think that they are, well, of very limited value. Or, lets put it a bit differently: What is advocated as the platform for a platform independent model - and is thus at the core of MDA - is in my opinion inadequate for describing the platform independent aspects/concerns of most software systems.

    I think MDA will be fine for expressing solutions where the behaviour is naturally expressed in in terms of cooperating Finite State Machines. OTOH, if you have a constraint-based problem, then IMHO MDA won't be much help.


    > Likewise, if we end up with "application developers" doing the PIM and "system developers" doing the PSM, this seems like the wrong way. One could argue, that developing in a PIM should be *easier* and that thus it should be the domain where the application developers would be working.

    The split between "developers with domain-specific knowledge" (i.e. your application developers) and "developers with technology specific knowledge" (i.e. your system developers) is valid and useful in large companies or for large projects. But nobody should think that it will remove the need for the
    appDevs to understand what the sysDevs have done for them.

    Ideally the appDevs and sysDevs should sit next to each other, so that they
    can understand each other's problems and code.


    > Also, I find the term MDA fully inadequate, the PSM is merely mapped from the PIM. That's it. The model does not drive the architecture, it is mapped to an architecture (or one out of n architectures are selected). True MDA would derive from my model and my usage pattern, what kind of architecture is suitable for my application (1-tier, 2-tier, n-tier, Hub-and-Spoke, Bus-Like...), what kind of security infrastructure I am most likely to use, what persistence mechanism and communication infrastructure (HTTP, SOAP, RPC, IIOP...) fits my usage patterns best etc.

    There are a number of companies that have a particularly interesting attitude in that respect. The companies (e.g. Kennedy Carter) presume that they don't know what your PSM environment will be, and so allow you to define the mapping yourselves. An interestign feature of KC's product is that the mapping is "self-hosting" in that the mapping algorithm is defined in MDA. They claim that you can used their tool's MDA debugging facilities to debug the mapping process itself. (N.B. I haven't used their tool, nor am I connected with the company)
  12. I think MDA will be fine for expressing solutions where the behaviour is naturally expressed in in terms of cooperating Finite State Machines. OTOH, if you have a constraint-based problem, then IMHO MDA won't be much help.


    I beg to differ. Read David Frankel's MDA book. He points out not only that Object Constraint Language (OCL) is a UML dialect that is leveraged by MDA, but makes a more generalized case for Design By Contract (DBC). Frankel says many modelers today don't use the full power of UML tools, in particular, they don't capture enough constraints. He argues that DBC design practices (pre and post conditions and invariants) can add enough semantic details to Domain Models to automate generation of most exception handling, test harnesses, etc.

    There is more to MDA than Class Diagrams and Finite State Machines. It's a relatively new idea and neither the "standards" nor the tools are all the way "there" yet. I agree that overhyping MDA could kill it. On the other hand, I think we owe it to ourselves to study it and learn more. I believe in the core premise that modeling should drive architecture, which should support and bound development, and that much of this could and should be automated.
  13. I think MDA will be fine for expressing solutions where the behaviour is naturally expressed in in terms of cooperating Finite State Machines. OTOH, if you have a constraint-based problem, then IMHO MDA won't be much help.

    >
    > I beg to differ. Read David Frankel's MDA book. He points out not only that Object Constraint Language (OCL) is a UML dialect that is leveraged by MDA, but makes a more generalized case for Design By Contract (DBC). Frankel says many modelers today don't use the full power of UML tools, in particular, they don't capture enough constraints. He argues that DBC design practices (pre and post conditions and invariants) can add enough semantic details to Domain Models to automate generation of most exception handling, test harnesses, etc.

    I can believe that, and welcome anything which encourages DBC.

    However, I was too terse when using the phrase "constraint-based problem". I intended to imply problems of the ilk "find me one of the solutions where the price is above cost and everybody has a fair share". The algorithm for solving such problems doesn't map onto FSMs.


    > There is more to MDA than Class Diagrams and Finite State Machines. It's a relatively new idea and neither the "standards" nor the tools are all the way "there" yet. I agree that overhyping MDA could kill it. On the other hand, I think we owe it to ourselves to study it and learn more. I believe in the core premise that modeling should drive architecture, which should support and bound development, and that much of this could and should be automated.

    Hmmm. I'm looking at what is available today. I'm also concerned that, whereas MDA is currently relatively small and well-defined, if it attempts to become too all-encompassing then it risks becoming too unfocussed. I'd prefer to have a tool that does one job well and predictably, and that can be easily integrated with other such tools, rather than a tool which does several things poorly or where I can't predict the tool's output.

    "Modelling" is another of those ill-defined words. To an engineer of physicist, modelling implies an approximation to reality which is used to gain an insight into some aspect of The Real World. Softies tend use it to mean the precise specification (and preferably executable specification) of their code. There is a significant difference!
  14. Application vs. System developers[ Go to top ]

    Karl wrote:

    "Also, I find the term MDA fully inadequate, the PSM is merely mapped from the PIM. That's it. The model does not drive the architecture, it is mapped to an architecture (or one out of n architectures are selected). True MDA would derive from my model and my usage pattern, what kind of architecture is suitable for my application (1-tier, 2-tier, n-tier, Hub-and-Spoke, Bus-Like...), what kind of security infrastructure I am most likely to use, what persistence mechanism and communication infrastructure (HTTP, SOAP, RPC, IIOP...) fits my usage patterns best etc."

    I like the idea very much. But I think we have to be patient. Karl's suggestion, taken to the world of 3GLs, would mean that I write my 3GL (e.g. Java) program, and the compiler tells me what OS and hardware to run it on. We still like Java even though javac doesn't tell us that much. But isn't it great news that MDA allows you to change your security or presistence mechanism without much hassle, reusing the security and persistence specifications you provided in your models? I think this goes way beyond what we have without MDA. One step at a time.

    -- Axel
  15. Yes, MDA could be seen as a somewhat backward misnomer, because it really stands for model driven develelopment, which is driven by the architecture. I guess that the OMG just needed a trade-mark, so it's no big deal. One company I know who was doing this even before the OMG coined MDA calls their tool an "Architectural IDE" and they let you automate your particular architectural style with MD techniques. That's why the tool is called ArcStyler (www.ArcStyler.com)...
  16. Yes, MDA could be seen as a somewhat backward misnomer, because it really stands for model driven develelopment, which is driven by the architecture.

    The specification of the user's custom application is itself data. Model driven is a specialized example of data driven. The data first appears in the automated production pipeline as XMI encoded models. The generated classes are projections of model data. A model manifests itself as class files in a portion of the application's code base. Code generation templates are model driven as such.

    The architecture's other contribution to the executable is its reusable run time library (aka Shlaer-Mellor "mechanisms"), which interacts with the generated classes. The models execute in accordance with their generated logic. The architecture run time is so driven by generated classes. But generated Java logic is itself tramsformed data. Obviously model driven.
  17. Abstraction is the issue[ Go to top ]

    I am new to the standards that comprise MDA, and have not used any of the tools yet, having just downloaded AndroMDA. I am an unemployed programmer stalled in my development halfway between being a rank and file application developer and maybe oneday a software guru. I have always tried to avoid repetition, and it is my opinion that automation and software "product lines," in the sense of the phrase used by Czarnecki and Eisenecker, are the future, so I am predsiposed to view MDA in a positive light. These are just my opinions. I am not a very rigorous thinker and I am out of my depth so please forgive me ahead of time.

    Some things bother me about MDA or the claims made about it. Here is my list:

    1. UML expresses programs at a higher level of abstraction than 3GL, thus it is the future - I don't see that this is true. As other posters have observed, UML is a tool for visual OOAD at the exact same level of abstraction as if one modelled a system only using Java interfaces for example. This is not a point against UML or MDA, but if you labor under the idea that MDA, using UML, is by its very nature conferring the well-known productivity gains of a higher-level language over a lower-level language, you are heading in the wrong direction.

    2. Visual representation of software systems is better than text, and is the future - not my future. I can only make productive use of UML or other visual tools to a very limited degree. The proliferation of notation details in visual form quickly becomes visually confusing (for me) when expressing systems that are not very large. Is anyone in a position to comment on the HUTN for UML posted on the OMG site? I downloaded the spec but I am having a hard time digesting all these specs at once. It looks like HUTN is what someone like me would want to speed the plough.

    3.UML Profiles will divide domains from each other yet preserve reuse - yes, the same say all the different XML-based standards are different and incompatible. MOF and XMI are generic and flexible enough that you can express just about anything with them. This power seems cool, but it seems to me that this opens us up to the exact same barriers to reuse that seem to motivate pure modellers to disain reuse through libraries and components. In other words, truly reusable software artifacts are diffult and expensive to accrete. In the meantime, people write lots of similar libraries and components that are just a bit different, and the addition of a new feature can result in the same combinatorial explosion of complexity between Models with dependencies as it does in dependent libraries. Czarnecki again says in Generative Programming that the way around this is to capture the rules for generating components, and share those, rather than sharing the components themselves. This seems to be a concept that is beyond the reach of MDA. MDA gives you the language, but does not provide tools to specify features or DSLs that are any more powerful than existing techniques. Is this off the mark?

    4.Don't generate what you don't understand - I am not arguing against generative programming, but this rule of thumb is IMO extremely important and exends to other areas than code generation. Other posters have alluded to the necessity of understanding, to some extent, the internals of the containers upon which we stack our J2EE apps. But all productivity gains are ultimately founded on our unquestoninng reliance on things that just work like compilers JVMs, etc. It takes time for an area of software to become a truely horizontal domain, and people should not leap into that dark area, but rather walk slowly.

    I think that the key way the MDA makes us more productive is through reuse of generative patterns - not by modellers specifying UML that is fine-grained enough to execute on its own, given the right compiler. It would be nice if a community of practice could arise that emphasized using MDA to create Domain-Specific Languages and perform other so-called domain engineering tasks. But I do not believe that there is anything pure about what software people call Modelling as opposed to any other way of specifying programs. All that matters is that the notation can be easily adapted to analysis and transformation by automated tools.

    MDA should not be so ambitious that it claims to answer any questions. OMG should be happy to just provide languages that make it easier for us to pursue generative programming techniques. I do not think that the promise of MDA lies in a giant all-encompasing repository of UML Profiles that give us a system of Classification in the Platonic sense from which programs will be generated by a Modelling priesthood. Pursuing this line of thought basically is the same as deciding that you want to use C# instead of Java. It may be fun for some personality types to embark on a new project of classifying the whole world anew in a different language, but that is not new and will not result in big gains in productivity. That is the same kind of red herring as the early concept of OO reuse that imagined that all organizations would share one Person class between them. We need an intersection of AOP, MDA, DSL generators from feature models, then we might be getting somewhere.

    Sorry for the long post, it does not claim to be authoritative. I am interested to hear your reponses.
  18. Benefits of MDA[ Go to top ]

    The real benefit of MDA at the moment is the seperation of "application" and "system" developers.

    Exactly. A few would become architects, and the rest of us would be analysts. And that's exactly how applications should be developed. MDA is trying to fundamentally restructure our craft so that teams don't need architects. A team of analysits could use their subject matter expertise to capture proprietary models. They could then buy a commodity architecture and use it to generate their software deliverable. The on-site human architect would be eliminated. J2EE's made great strides at this sort of deskilling. This could free up more programmers to become business analysts. Presumably with model translation, the analysts are more productive then they were as programmers, so industry produces grander software. Well, that's the premise of MDA.
  19. Benefits of MDA[ Go to top ]

    MDA is NOT intended to do away with architects; it will actually raise their visibility levels and generate demand for MORE of them. The MDA tool I'm investigating has an Architect edition that allows users to author their own design ("implementation") patterns, which could then be automatically applied to generated applications. MDA raises the abstraction level of software development, ideally to completely design using modeling. This places greater emphasis on the importance not only of architecture, but of architects.

    Even for programmers, the intention of MDA is not to replace programmers or coding but to automate as much of the "drudgery" of it as possible. At least for the forseeable future, application development will NOT be totally automated no matter how good the tools get. MDA will take it as close as possible given the limits of technology and standards.
  20. Benefits of MDA[ Go to top ]

    Whatever they may be called, but MDA will hopefully do away with
    people, who produce quality-unassured paperware
    and diagramware and who unfortunately more often than not are
    in a position where they can lay the fundaments for serious havoc
    in your project.


    And on another topic:
    I don't see a "MDA vs. agility"-conflict, as you can use all your
    agility and XP-skills to develop your PIMs and all your agility and
    XP-skills to develop your PSM-generating generators.

    Uwe
  21. On the contrary...[ Go to top ]

    The on-site human architect would be eliminated. J2EE's made great strides at this sort of deskilling. This could free up more programmers to become business analysts.

    I am not sure if this is irony :-). In fact J2EE/Corba/.NET are the very architectures that require a human architect, because the infrastructure itself is so complex that you need a specialist for the infrastructure. I am not aware that you needed a software architect when developing COBOL or even simple distributed RPC applications. I would even assume, because the translation of the PSM to the PIM is very weakly defined in MDA, there would be architects needed who "enhance" the PSM before translation, e.g. by proper parametrization etc.
  22. On the contrary...[ Go to top ]

    <quote>
    I would even assume, because the translation of the PSM to the PIM is very weakly defined in MDA, there would be architects needed who "enhance" the PSM before translation, e.g. by proper parametrization etc.
    </quote>

    I assume that you meant PIM to PSM? The point is you can let specialized architects to do the job for doing all those enhancements. In the future maybe you can just buy those transformation stuffs out of box. So, an application (domain) developer should only handle the PIM and he will buy a "PSM slot" for J2EE or .NET and can run his application on the top of that. Surely this is questionable, because of the standardization of MDA. As I mentioned in my 1. thread, as long as OMG does not provide us with such a reference implementation, I could hardly believe that this will happen soon.

    Regards,
    Lofi.
  23. Benefits of MDA[ Go to top ]

    A few would become architects, and the rest of us would be analysts. And that's exactly how applications should be developed. MDA is trying to fundamentally restructure our craft so that teams don't need architects. A team of analysits could use their subject matter expertise to capture proprietary models.


    I don't know much about MDA other than what I've picked up here on TSS, but to me in my position of ignorance this statement sounds exactly like what people were saying about CASE tools ten or fifteen years ago. With CASE, we wouldn't need programmers, we could get together some business analysts who were experts in the business domain and they would use their expertise to build a system without having to worry about the low-level technical problems of how it was actually implemented. We all know how well that worked. (Sarcasm alert.)

    Can anyone explain to me in simple terms how MDA is different from CASE and not just the same basic idea packaged up with new buzzwords and trendy phrases? Or point me to a good website that gives an idiot's guide to MDA and why it's not just CASE rebranded for a new generation of managers looking for an easy fix to the ever-challenging problem of developing good software.
  24. MDA vs. CASE[ Go to top ]

    Check out this PDF file:

    http://www.omg.org/mda/mda_files/DFrankel_MDA_v01-00_PDF.pdf

    Regards,
    Lofi.
  25. Benefits of MDA[ Go to top ]

    A few would become architects, and the rest of us would be analysts. And that's exactly how applications should be developed. MDA is trying to fundamentally restructure our craft so that teams don't need architects. A team of analysits could use their subject matter expertise to capture proprietary models.

    >
    > I don't know much about MDA other than what I've picked up here on TSS, but to me in my position of ignorance this statement sounds exactly like what people were saying about CASE tools ten or fifteen years ago. With CASE, we wouldn't need programmers, we could get together some business analysts who were experts in the business domain and they would use their expertise to build a system without having to worry about the low-level technical problems of how it was actually implemented. We all know how well that worked. (Sarcasm alert.)

    Oh yes, the sense of deja vu is overwhelming, but on closer inspection there are a few important differences:
      - a standards body (OMG) is at the forefront
      - the pretty pictures plus action language is executable
      - it can be characterised as UML minus the poorly specified bits
        plus what's necessary to make it executable
    Which is, I suspect, closer to the claims of the 4th generation tools than to CASE tools.


    > Can anyone explain to me in simple terms how MDA is different from CASE and not just the same basic idea packaged up with new buzzwords and trendy phrases? Or point me to a good website that gives an idiot's guide to MDA and why it's not just CASE rebranded for a new generation of managers looking for an easy fix to the ever-challenging problem of developing good software.

    It is certainly being presented as the latest silver bullet, but IMHO it will be successful when applied appropriately. Young managers, or those with attention deficit disorder will be taken in by the claims.

    Can I suggest that you dig around on http://www.kc.com and look for their
    powerpoint presentation on xUML (xUML Tutorial.pps). Remarkably for a ppt file, it contains useful hard technical information of the kind you are looking for. You may have to register in order to access the file.
  26. MDA Resources[ Go to top ]

    Can anyone explain to me in simple terms how MDA is different from CASE and not just the same basic idea packaged up with new buzzwords and trendy phrases? Or point me to a good website that gives an idiot's guide to MDA and why it's not just CASE rebranded for a new generation of managers looking for an easy fix to the ever-challenging problem of developing good software.

    Frankel's book is excellent. Another good resource is MDA Explained. Here's a link where you can get a couple of the chapters online (registration required), or buy the book with a discount:

    http://javacentral.compuware.com/optimalj/demo_edition/index.htm

    Mike Burba
    Compuware OptimalJ
  27. Benefits of MDA: [MDA vs. CASE][ Go to top ]

    Can anyone explain to me in simple terms how MDA is different from CASE and not just the same basic idea packaged up with new buzzwords and trendy phrases? Or point me to a good website that gives an idiot's guide to MDA and why it's not just CASE rebranded for a new generation of managers looking for an easy fix to the ever-challenging problem of developing good software.


    There are plenty of articles to read on OMG, but this one has section on CASE vs. MDA. Appears to be originally from a staffing company.

    http://www.omg.org/mda/mda_files/MDA32.pdf
  28. In simple terms MDA versus CASE[ Go to top ]

    1) CASE was proprietary, you had little to no control over generated code
    2) CASE made claims that never came to fruition and little was gained in the area of productivity for many.

    3) MDA is an open industry standard --nothing proprietary about it.
    4) MDA simplifies architecture if your implementation uses patterns and best practices to transform you from a Platform independent model to a Platform specific model to Code.
    5)MDA provides productivity improvements if you take advantage of automatic pattern implementation based upon your original domain / business model.
    6) MDA promises to accelerate change via the reuse of domain and PSM's to automatically generate new code based upon changes in your business model.
    7)MDA makes no claim that you will replace developer or architects with their methodology. Actually you still need skilled people in this area to succesfully implement their methodolgy to achieve higer levels of productivity when developing enterprise applications.
  29. Bravo Michael; that's exactly the conclusion I'm in the process of coming to as I investigate MDA and today's tools (specifically, OptimalJ). It shares code generation with CASE but nothing else. Automation is a GOOD thing, given the proper framework.

    I don't know about the rest of you but I've noticed a serious trend toward offshore development. If North American developers don't find ways of seriously increasing productivity, there will continue to be negaitve pressure on the job market for developers here as a result of economics (Adam Smith's principle of Comparative Advantage). Not that MDA can't and won't be adopted worldwide. The point is that corporate IT is increasingly unwilling to accept the status quo in terms of productivity. Something has to change. If XP does the trick, XP will proliferate. If MDA does the trick, MDA will proliferate. Personally, I think the two will merge (Architected RAD, or ARAD).
  30. If North American developers don't find ways of seriously increasing productivity, there will continue to be negaitve pressure on the job market for developers here as a result of economics (Adam Smith's principle of Comparative Advantage).

    That assumes demand for custom software is fixed. Actually it's always grown.
  31. That assumes demand for custom software is fixed. Actually it's always grown.


    Actually, it hasn't been growing the past 3 years, which is why the job market has been in the toilet during that time. Up until then, yes - uninterrupted growth. We have now experienced our first interruption, proving that growth in this career field does NOT benefit from some magical force field of protection that insulates it from the overall economy.

    As a matter of fact, I could make a very strong argument that the maturation of the Information Economy has led to the consequence that IT careers (particularly in the area of customer development) might now be hypervulnerable to the vagueries of the overall economy, contrary to the historic trend. With IT assets ubiquitous, management seems to have adopted the mindset that IT vendors are snakeoil salesmen, that they have all the software (custom or shrinkwrapped) they need, and I believe HR managers (after decades of bending over backwards to recruit valued IT employees) are only too happy to execute the business of propping up the bottom line by laying off expensive developers.

    I believe business does understand the value of software but they are unwilling to obtain those benefits at the exhorbitant cost levels of yesterday. They can and will go offshore for their needs. They are demanding higher productivity. Something must deliver that level of productivity. MDA is not a silver bullet but it just might be the best answer the IT industry has to offer today.
  32. They can and will go offshore for their needs.

    In which case Amerika's appetite for custom software is much like its appetite for oil: pervasive and insatiable. This is good for developers, even us domestic ones. But if the software industry ever does face excessive competition and consolidation, surely the craftsmen with the most capable automation will win, as is the case with any saturated sector of production. The folks who insisted on weaving cloth by hand are a footnote in economic history, even in India. We've always asked what software can do for our customers. Let's also ask what software automation can do for us developers. Certainly machines can improve quality by reducing defects. Machines also work faster than people.
  33. MDA, CASE, etc.[ Go to top ]

    I think that MDA is a brilliant concept, and that it's goal is an admirable one. But IMHO "Software Automation" only works in a perfect world. In the real world, we don't know all the requirements before we start development. Even the requirements we do know, it's quite likely that we've misunderstood them. Heck, in all probability, even the users of the system you're developing don't know what they really want. In this world, software automation is good upto a point, beyond which it starts to hinder the progress of the project. I believe that MDA like CASE before it, crosses that point.

    I have to say tho', that I would love to be proved wrong, because you are right in that software automation is the only "easy" way to increase productivity and reduce defects.

    Since I seem to be the only one on serverside who thinks MDA is impractical, maybe I am wrong...

    Disclaimer: I am in no way or form related to Rational or the Agile Alliance. These opinions are mine and mine alone.
  34. MDA, CASE, etc.[ Go to top ]

    <Nilesh Pereira>
    Since I seem to be the only one on serverside who thinks MDA is impractical, maybe I am wrong...
    </Nilesh Pereira>

    Your not alone, I too think this but going to check it out in more detail. Hopefully I am wrong about MDA.
  35. MDA, CASE, etc.[ Go to top ]

    In the real world, we don't know all the requirements before we start development. Even the requirements we do know, it's quite likely that we've misunderstood them.

    That's the compelling argument for MDA. Remember that the development pipeline is an expanding cone of elaboration. A little analysis is elaborated into a big design, which is in turn elaborated into an immense codebase. So a small requirement change can result in big swath of destruction in the codebase. If elaboration is a manual chore, then much tedious handiwork is lost when requirements change. But if elaboration is generated, then little handiwork is lost. Therefore MDA is more agile than Agile modeling.
  36. MDA, CASE, etc.[ Go to top ]

    <Brian>Therefore MDA is more agile than Agile modeling.</Brian>

    If you only use MDA for generating architectural building blocks and framework components like Entity Beans, then I would agree. Unfortunately, proponents of MDA are talking about using MDA as a visual programming tool for application and business logic as well. This would make it tougher to adapt to change than if you didn't use MDA, because visually generated logic is like "magic" - tough to understand, and tougher to change. Ask any VB programmer...
  37. MDA, CASE, etc.[ Go to top ]

    Unfortunately, proponents of MDA are talking about using MDA as a visual programming tool for application and business logic as well. This would make it tougher to adapt to change than if you didn't use MDA, because visually generated logic is like "magic" - tough to understand, and tougher to change.

    You misunderstand diagraming and model compilation, both of which make application maintenance easier. Diagrams are more readable than text, and model compilation is easier than hand coding.
  38. MDA, CASE, etc.[ Go to top ]

    Diagraming and model compilation make application creation easier. The only way they would make application maintenance easier was if they did away with programming altogether. As long as you have developers having to change logic in visually generated code, it's always going to be tougher.

    Anyway, I think I've hijacked this thread long enough, so I think I'll stop now ;)
  39. 7)MDA makes no claim that you will replace developer or architects with their methodology. Actually you still need skilled people in this area to succesfully implement their methodolgy to achieve higer levels of productivity when developing enterprise applications.


    8) CASE didn't support lifecycle. CASE tools excelled at designing and generating, but when an application had to be modified in a way not supported by the tool, you ended up with a pantload of code that had to be manually maintained or had to reapply mods if you ever regenerated the app.
  40. In simple terms MDA versus CASE[ Go to top ]

    I understand and agree with most of your points here, with the exception of point (2). It's still too early, IMHO, to know whether or not MDA will deliver on this, or whether it will go the same way as CASE and 4GLs in this regard. Or maybe I'm just an old cynic. Still, I live in hope. One of these days, I'll never have to write another line of code.
  41. Benefits of MDA[ Go to top ]

    As you can see, there are only few good architects in J2EE but there are a lot of >application developers available. The idea is just simple: let the experts do all >the architectural design (PSM) and any other application developers should only >use those design (PIM). You can save a lot of time and money by doing this in big >companies.


    Exactly. And the result of developing the architecture is manifested in a set of mapping functions when using an MDA approach. This ensures that application developers always and automatically produce results that comply with the architecture that the system developers have designed.

    -- Axel
  42. MDA vs. Java[ Go to top ]

    Surely MDA won't replace any programming language very soon but I think this is where they want to go. MDA is not only UML but also OCL (Object Constraint Language = textual constraints) and many other components. You are correct that we always need textual details for any programs but UML will also cover this area. If you see how they expand the capabilities of UML from 1.4 to 2.0, UML becomes a very complete and detailed, in couple of years UML will become a full blown language to replace any low level languages like Java to be used at the level of "application programming" language ;-)

    You surely have those Java developers but they just use Java for "system programming". This is just comparable with Java nowadays as "application programming language" and "C/C++/Assembler" for the "system programming language". We write our application nowadays in Java but all the guys, who write the Java Virtual Maschine still use C/C++/Assembler.

    In MDA world:
    - Application programming: you use UML, OCL, etc. This becomes your PIM. After this you translate your PIM into PSM and run it. You as application programmmers will never touch the PSM. Because it's already done for you (Just like any other compilers). In Java world this is comparable by writting your application in Java and using "javac" for translating and "java" for running your application.
    - System programming: all the system programmers write those translations from PSM into the "real" code (Java, C#, etc.). In Java world this is comparable with all the guys write JVM. You as application developers don't write the JVM by yourself, right? ;-) This is also applied to the PSM. You as application developer will never touch the PSM by yourself.

    So, if you see this, MDA will change the language to be used to write "applications". And this way, the "application" programming language will go one abstraction level higher. The question is (as I mentioned in my 1. thread) Java will also go "up" one abstraction level higher... So, it would be very interesting to see, who will win ;-)

    Regards,
    Lofi.
    http://www.openuss.org
  43. Having predefined PSM's is likely unavoidable for the forseeable future. However, there is at least one vendor (Compuware) that offer the architects the ability to influence how the code is generated from their PSM's. This is achieved via what they call "Pattern Authoring" and it enables you to generate working application according to your standards versus out of the box standards provided by the vendor.

    Who wouldnt like generated code that is built they way you want it? Finally, as it relates to MDA nobody see's this as a threat to development languages at least for the next 10-15 years out. MDA will get you their faster by shielding many from the complex J2EE architecture, and the automatic generation of all the glue code related to the original domain/PIM. Skilled developers are then free to and expected to have the skills to focus on the high value business logic related to the business application being developed. They are no longer in the mode of spending all day working CRUD and the like as it relates to the business systems being designed.

    Start with a good business model PIM, push a button and generate PSM's push a button generate code, compile it, start you web and ejb servers, start your data base and shazam you have a working application! Now that application is a rapid prototype of which you build on with your skilled developers. Apply your business rules and other required logic that is not a part of the PIM, spiff up the JSP's and poof -- your done. So skilled developers will always be a requirement for any MDA type project you take on. Once you implement MDA their is even greater promise in your ability to be more productive because the models and patterns implemented can be reused over and over again in a consistent manner. You also greatly influence the amount of time spent worrying and testing for errors. If you trust your patterns, do you need to spend a lot of time testing already proven code?

    Ok, off my MDA bandwagon -- if you have not done so do yourself a favor and check these tools out. I believe they are the coming wave of the future. Where else will you go to be anymore productive at this current time?
  44. MDA vs. Java[ Go to top ]

    First of all, I'm biased as I'm with an MDA tool vendor ;-) I agree that freely available reference implementations tremendously help improve the adoption of a concept or technology. That's why AndroMDA is a good thing. However, (and I guess I'd also say this if I wasn't with an MDA tool vendor) there's more to MDA than consuming XMI streams and XDocletting them into other ASCII streams. To me, an important aspect of MDA that you'll see only after really employing MDA to a real problem is that of "software engineering" for your model transformations aka mapping functions. As you realize this problem, it turns out XDoclet (and other purely XMI-based technologies) poses several problems. Think about reuse of mapping functions, as we do reuse in OO. Think about managing large or huge mapping function specifications. Think about combining several mapping functions and assembling them into a larger context. At least for now I'm convinced that commercial tools (and in particular, or course, ours ;-) ) solve these problems a lot better than an XDoclet-based approach.

    If you compare the current state of MDA with the EJB story, we're probably at the EJB 1.0 stages or even earlier. The EJB 1.0 spec didn't say much, so many vendors were able to claim to be "compliant". Yet, the spec made clear the general direction. So does the MDA "spec" / guide today. Tool vendors explore the solution space, and users pick and choose their favorites. The OMG will confine the MDA standard more and more, leaving more and more vendors behind, just as in the EJB world. At the same time, interoperability and maturity will improve. Evolution at its best.

    We offer a free community edition of our tool to foster the adoption of MDA (www.ArcStyler.com) and support a web site (www.mda-at-work.com) where mapping function implementations ("cartridges" as we call them) can be uploaded and downloaded for free to plug them into the tool's MDA engine. Furthermore, the tool is entirely free for any non-commercial use. You can extend cartridges by means of cartridge inheritance (OO for MDA mapping functions), and you can view and edit mapping functions using UML diagrams (MDA applied to mapping functions!).

    I agree that 3GLs will continue to be important. I know that some people (e.g. my friend and co-author (look out for "MDA Distilled" this fall) Steve Mellor, Hi Steve ;-) ) argue that it should be possible to specify your systems entirely in UML (executable UML, this is). I agree that this will be possible for a certain range of platforms and application types. However, from my experience, today it's more convenient in many scenarios to provide specification information at various different levels of abstraction. Some stuff can be expressed in a very abstract and thus portable way. Other things have to be said in a very platform-specific manner. If you don't support this you end up as Java in some respect, having people blame you for not supporting this or that property of a specific platform at its best.

    UML tools will play the role of your favorite source code editor in the future. I guess we'll see the same "Emacs vs. VI" wars in the UML tool space. I guess, we already see them today. Several of our customers say they dislike Rose (which we're currently tightly integrated with). If you ask them which tools they like they answer with tools such as Poseidon, Argo or the Borland / Together Control Center. Others say MagicDraw is it. We've thoroughly evaluated some 30+ UML tools. The answers we hear from customers and potential customers don't reflect in any way substantial quality aspects such as UML support, performance, scalability, robustness or many other criteria we could think of. Because we anticipatereligious precocceptions about which UML tool to use, we've opened up our tool architecture in our upcoming 4.0 release to make the integration of a UML tool and its underlying repository as easy as possible. We've prototyped integrations for some four or five tools in little time and have decided to do a premium integration with our partner NoMagic's MagicDraw.

    Existing (JMI 1.1, MOF 1.4, UML 1.3/1.4) and upcoming (UML diagram interchange, UML 2.0, MOF 2.0) standards will make tool interoperability less of a hassle. BTW: It's ok already for a one-time migration. Taken together with the current de-facto standard for UML diagram interchange (Unisys), migration from one tool to another can actually be done between several existing UML tools.

    A last comment con Cameron's posting: text-based specifications can be fine. We still suggest this approach for the body of a user-specified operation (the if-else stuff). I don't think MDA requires you to use any predefined _representation_ for models. Sure, UML and UML profiles seem pretty central to representing models in the scope of MDA, and it proves very helpful for many cases. But I regard Java programs (and analagoudly, programs in any other programming language) a model in the sense of MDA, too. How else could it be the result of an MDA model transformation, anyawy? It has a formal metamodel that you can write down in MOF. I'd say MDA has no problems at all with text-based representations of models. The exciting question to me is rather how much and which parts of a system's specification we should express in text-based representations. Probably even more exciting: what is the ideal "chain of metamodels" (very abstract, a little bit abstract, concrete, detailed down to the least bit of a platform specification) to refine your specification in, and what do the mapping functions linking these metamodels have to look like. What factors affect this decision (portability, ease of use, standardization of metamodels, level of adoption, specificity to a certain platform, ...). This is about language design and, if you will, compiler construction.

    History doesn't stop repeating itself...

    Cheers,
    -- Axel
  45. I have been using AndroMDA for a while now, it is an open-source project on SourceForge (http://andromda.sourceforge.net) founded by Matthias Bohlen.

    It generates any code you want from a UML diagram (XMI), by default it generates XDoclet compatible code for J2EE applications, mainly EJB. Recently there has been an update and a new release has been made available, also supporting Hibernate.

    All generated code can easily be changed via Velocity templates, so if you see something you don't like you can change it without a hassle.

    If you feel you spent too much time writing the same code over and over again, if you find yourself updating UML diagrams after the implementation etc... (I think we all have been there ;-) ... then this tool might be for you.

    For me personally the combination of MDA and XDoclet has increased efficiency as well as maintenance by a factor of at least 5x. Not to mention project documentation is always up to date (by default UML documentation is copied as Javadoc into your code)

    I use AndroMDA 2.0.1 (relatively old, but stable)
    Poseidon CE
    XDoclet 1.2

    I did not use the most recent release yet, but it is recommended for new users. There is an active forum in case you have any questions

    Good luck

    Wouter.
  46. I have been using AndroMDA for a while now, it is an

    > open-source project on SourceForge (http://andromda.sourceforge.net)
    > founded by Matthias Bohlen.
    >
    > It generates any code you want from a UML diagram (XMI),
    > by default it generates XDoclet compatible code for J2EE
    > applications, mainly EJB. Recently there has been an update
    > and a new release has been made available, also supporting Hibernate.

    If I understand AndroMDA, it only makes use of the UML class diagrams; it doesn't do anything with the UML StateCharts. OMG's MDA, OTOH, uses the class diagrams to specify the data relationships, and Finite State Machines (i.e. StateCharts) to define the time-dependent behaviour.

    To me, one without the other is relatively uninteresting.
  47. AndroMDA[ Go to top ]

    At least AndroMDA is an Open Source project. You are surely very welcome to add those functionalities into AndroMDA by yourself ;-)

    Lofi.
    http://openuss.sourceforge.net
  48. <Tom Gardner>
    If I understand AndroMDA, it only makes use of the UML class diagrams; it doesn't do anything with the UML StateCharts. OMG's MDA, OTOH, uses the class diagrams to specify the data relationships, and Finite State Machines (i.e. StateCharts) to define the time-dependent behaviour.
    To me, one without the other is relatively uninteresting.
    </Tom Gardner>

    Hi Tom and the others,

    a colleague pointed me to this magnificent thread, so I thought it would be the right time to contribute "from the source". (This web page already says that I founded the AndroMDA project, so I do not need to repeat that. :-))

    First of all, let me comment on your statement "AndroMDA ... only makes use of the UML class diagrams; it doesn't do anything with the UML StateCharts". Later on, in a separate posting, I'll tell you a little about where AndroMDA is today and where we're going.

    First, AndroMDA ignores diagrams, it only cares about the model. Some readers may ask: What's the difference between a model and a diagram?

    Well, a model is represented by a so-called "abstract syntax tree (AST)" - it is a tree (or better: a graph) of many connected, tiny little Java objects in memory which represent UML model elements, i.e. classes, attributes, methods, associations, states, transitions, stereotypes, OCL constraints, etc.

    Diagrams are only graphical visualizations of the model. AndroMDA does not need the diagrams at all.

    At the beginning of processing, AndroMDA reads this AST from an XMI file which has been produced by a CASE tool. It analyzes the stereotypes attached to each model element. When it hits a stereotypes that it knows (e.g. "Entity", "Service", "WebAction" and many others), it invokes a template engine (Velocity) that generates code for this model element. It passes the AST to the template engine which can pull data (e.g. names, multiplicities, visibility and other tags) from the model elements and generate code depending on them.

    OK, now what you said is partly right and partly wrong:

    * Yes, we currently ship templates for the static part of a model, only! (Classes, attributes, methods, associations, etc.).
    * No, we're not limited to that because we have the *entire AST* in memory and can generate code for the dynamic part of the model, too.

    Generating a finite state machine from a UML model would be a snap, if someone took the time and wrote a few templates for this. One of our most active developers, Tony Mowers, has written such templates for himself but did not find the time to publish them, yet. Maybe he'll do this for a future release.

    Believe me, writing AndroMDA templates is really easy, once you have read the docs on our website and understood the Velocity template language (described on the Apache Jakarta website). The templates shipped with AndroMDA (for EJB, Hibernate or Struts artifacts) are only examples for what you can do in your own project. They show that code generation really works and give the architect(s) of the target project a starting point to develop templates for their own project-specific and architecture-specific artifacts.

    So, if you wanna generate dynamic time-dependent behaviour, just write it down as a Java sample, test it until it works and then convert your sample Java code into a template by introducing placeholders for the actual metadata from the AST that represents the UML model. Tell AndroMDA which stereotype should trigger your template and: off you go with your own support for statechart diagrams etc! (No, not the diagram but the model that corresponds to that diagram, of course...)

    In case you should have problems with this, subscribe to andromda-user at lists dot sourceforge dot net and post a question there. We'll be happy to help you.

    Cheers...
    Matthias

    ---------

    Matthias Bohlen
    "Consulting that helps project teams to succeed..."
    http://www.mbohlen.de/
  49. OK, now let's do the second part of the thing.

    Let me talk about what AndroMDA does today and what it does in the future.

    We are just on the brink of a new release, AndroMDA 2.0.2 final (as opposed to the alpha release that we have got today). To make it really *final*, there are a number of things to do:
     
    2.1) Currently, AndroMDA is delivered in several ZIP files, one for each purpose (core, cartridges, samples, etc.). Users have reported that this is too complex to handle and install. So, the goal for 2.0.2 is to deliver only two ZIPs: one for the binaries, one for source code. This makes the ZIPs much larger but also much easier to install and run.

    2.2) The web pages mention a wizard that creates an empty code generation project as a good starting point for new users to work with AndroMDA. This wizard was broken (by me!) when the software was reorganized and the cartridge mechanism was introduced. I did not have time to fix this, Tony (author of the wizard) had neither. The wizard must be working again before we release. The wizard consists of only one XML file, so that one should be easy to change (but must be throughly tested!).

    2.3) Each cartridge that we have should be demonstrated with a template project that new users can copy and extend. Tony Mowers wrote a template project for the EJB cartridge, I have written a template project for the Hibernate cartridge. This will also be included in 2.0.2.

    2.4) A new XDoclet release has come out. AndroMDA V2.0.2 should contain and use it.
     
    OK, these were the goals for V2.0.2.
     
    After the release of 2.0.2, we plan to create a branch in CVS for 2.x maintenance releases and continue with the development of V3.0 on the main trunk. My main goals for the V3.0 release are:
     
    3.1) Make AndroMDA usable in an agile context. Examples: It should be possible to rename a class, attribute or method or move a class into a different package, etc. without breaking the compile cycle. With 2.x this is impossible because AndroMDA does not know that a model element was renamed or moved and happily generates a new one, keeping the old one as an orphan. This breaks the code and the user has to re-arrange it manually which is very tedious. I dream of an integration of AndroMDA as an Eclipse plugin, making AndroMDA aware of model changes. AndroMDA should then invoke the Eclipse JDT to do the refactorings on the code level. I don't know if this is possible, but at least that's the goal.
     
    3.2) Richard Kunze has supplied a sophisticated and powerful new EJB cartridge as a patch. This should become part of the 3.x release, too.
     
    3.3) Andy Soroker works on a JDO cartridge (hi Andy, how is it?). This should also become part of the 3.x release.
     
    3.4) Netbeans MDR (the metadata engine we use in the core) has the possibility to notify AndroMDA when it creates an instance of a metamodel class. Upon that event, AndroMDA could instantiate a cartridge-supplied decorator class for this metamodel class that implements model consistency checks and fine grain support for Velocity scripts. The most trivial example: A Hibernate entity class decorator could verify that at least one of the entity's attributes is marked as a primary key and stop the code generation if it is not. There are more complex things possible with this approach. Users of AndroMDA could write their own decorators for their own UML profiles.
     
    I am really excited about 3.0, we'll need more developers to help us. There's more to come, so join us and stay tuned...

    Cheers...
    Matthias

    ---------

    Matthias Bohlen
    "Consulting that helps project teams to succeed..."
    http://www.mbohlen.de/
  50. What I hate about MDA[ Go to top ]

    When people come to me and start talking about MDA, how cool it is etc, I keep asking mainly one question: "Show me how it can drive (or generate) the architecture!" Turns out, it doesn't. There is simple nothing in MDA that drives or even creates an architecture.
    There are only predefined architectures, and this is precisely the problem: To use MDA (or a lot of generative approachs for that matter) you will always lose a lot of freedom and flexibility.
    The question is: Do you gain more than you lose? Most people will agree, gains outweighs losses with Structured Programming over Assembler, OO over Structured Programming (debatable :-)) etc. There are generative approaches that enable very high productivity, manageability etc. However most of the ones I have seen, rely more on directives, metadata and higher level languages than on graphical notation. And after 20 years computer programming, I tend to think that this might not be a coincedence but a general rule.
  51. What I hate about MDA[ Go to top ]

    There is simple nothing in MDA that drives or even creates an architecture. There are only predefined architectures...

    An architecture is a package of features, almost like any other package, so much of an architecture could modeled and generated. A generated architecture could be parameterized and pluggable. In practice an architecture is likely to rely on J2EE. That is, J2EE is part of the architecture. There's no reason a servlet or EJB container couldn't itself be the product of MDA. Maybe a JVM, or operating system, or Mozilla would be compiled from models, if the tools were mature.
  52. "Show me how it can drive (or generate) the architecture"


    Most MDA products will generate some standard architecture for you, which will never completely suit your needs and I think there will never be a product that will. I've seen how OptimalJ lets you generate custom architectures. It provides a number of ready made ones, but you can add your own. This is to generate code from a PSM. Another thing is that you can create your own transformations between PIMs and PSMs. IMHO it allows you to do most of what you'd want.
  53. What I hate about MDA[ Go to top ]

    Karl,

    maybe you've been using the wrong tools then. When using the MDA approach, your architecture is encoded in the set of mapping functions aka model transformations that you use. The degree to which the tool supports changing / creating the mapping functions decides about their usefulness for somebody who wants to support their proprietary architectures.

    So I suggest you look out for tools that help you by providing you with a set of predefined mapping functions, but also allowing you to adapt them or extend them (e.g. by "inheriting" them and then adding / removing mapping rules in the inheriting mapping function). [same note on biasedness of a tool vendor's employee, ...] Take a look at www.ArcStyler.com. We do that stuff. Check it out and let us know how this affected your view of MDA.

    -- Axel
  54. use your own architecture[ Go to top ]

    The point of MDA for me is to have a way for developers
    to specify what and not how. The how is the architecture.
    Once the how is encoded, XP not withstanding, it's brutal
    to change in a large product. The architecture is largely
    project specific. I don't think using someone elses code
    will work most of the time. The expertise is developing
    the architectural components that express the higher level
    description.

    If i can i want to send this message to this client with this
    degree of reliability that's all i need to say. The implementation
    should does not need to be coded by a developer. There are opportunities
    of this type all over this place. The MDA is not code. It's not
    another implementation language.

    MDA is the thought the programmer has before the code gets written.
    It's i want to do X. The details of doing X may be simple or very
    complex, but it starts with an intent, a plan, a decision. Capturing
    details at that level is a big win. We can code the implementation
    of those details separately.
  55. RE: use your own architecture[ Go to top ]

    <thoff thoff>
    MDA is the thought the programmer has before the code gets written.
    It's i want to do X. The details of doing X may be simple or very
    complex, but it starts with an intent, a plan, a decision. Capturing
    details at that level is a big win. We can code the implementation
    of those details separately.
    </thoff thoff>

    This is how I see modelling, and using UML in MDA is too formal IMO. I only like to show what is important to the problem and not all the details. For instance a JavaBean property requires defining the member and getters/setters. When modelling I only want to show it has a property (TogetherJ does this but is too pricey for me). I find source code the best medium for details. Text is just simpler (for me) at describing details then diagrams.

    Also is UML is heading to the point of replacing languages such as Java, then will it not just be as complex as source code? Maybe I'm missing something, put programming is complex and not for the faint hearted IMO.
  56. It's interesting to see that MDA is backed by Rational and other Tool vendors who would love to see you spend more money on their tools, while the software gurus in the Agile Alliance are moving towards less up front architecture and design. The proponents of MDA seem to think that UML diagrams should have so much detail that they can be used as blue prints for implementation, while the agile methodologies teach that diagrams should have only enough detail as required for effective communication. Since the members of the Agile Alliance live and work in the "real world", it loos like MDA is going to be yet another brilliant but impractical concept from OMG that fails miserably.

    Since theserverside.com is always teeming with lurkers from various Tool vendors, I think I should put my asbestos suit on...
  57. Hi Nilesh,

    First, I swear on my grandmother's grave I don't work for any vendors. Heck; I don't work for anybody right now. I am genuinely interested in MDA on a personal level, although it's conceivable I might wind up working for a tool vendor in the future (I've worked for some in the past).

    Second, you're absolutely right tool vendors are lining up to support MDA and hope to make lots of money selling MDA-compliant tools. Welcome to capitalism in all it's glory.

    Third...

    >>Since the members of the Agile Alliance live and work in the "real world", it loos like MDA is going to be yet another brilliant but impractical concept from OMG that fails miserably.

    Really? It seems to me UML is a success, not a failure (I know; they simply inherited stewardship). I would also categorize CORBA as at least being a mild success. For an industry consortium I would say OMG has at least a decent record of success. I'd say it's way too early to predict a victor between the Agile Alliance and the OMG (for MDA). Further, I'm not convinced the two cannot learn to co-exist peacefully. It's a matter of degree (regarding design activity; this is not an impassible barrier. MDA proponents would be foolish to resist the concept of rapid application development. The Agile Alliance would be similarly foolish to refuse to acknowledge a major technology advance for software development as if it didn't exist (MDA has the potential to be that; it isn't there yet).

    Just because there's money to be made in MDA does not automatically make it evil.
  58. Well, I'm not saying that MDA is evil... all I'm saying is that it's goal seems to be an impractical "holy grail". Also, what I was trying to say is that Rational and other Tool vendors seem to be focusing on what "should work in theory", i.e more detailed models, while the Agile Alliance seem to be focusing "what works in practice", which is less up front design, refactoring, more testing and quicker delivery of working solutions. The question then comes down to - will MDA help you to adapt to change, or hinder you?
  59. MDA is not about "more" detailed models. If you as an "application developer" just have to create your PIM because you can be sure that the transformation into PSM and the running code will go smoothly, then this is comparable with programming in Java ;-)

    The word "refactoring" will be also adapted in MDA world but in a higher abstraction level. You will also need to refactor your PIM sometimes. As you may understand that your model's view may not always apply to the subjective view of your customer.

    Regards,
    Lofi.
  60. <Lofi>
    MDA is not about "more" detailed models. If you as an "application developer" just have to create your PIM because you can be sure that the transformation into PSM and the running code will go smoothly, then this is comparable with programming in Java ;-)
    </Lofi>

    If using MDA is comparable with programming in Java, then that's more detail I'm willing to put in a model. Unless you're saying that MDA does away with programming in java all together...

    Upfront design and architecture is good, but over doing causes problems as faults in the design and architecture only become apparent during implementation. Therefore, IMHO, adding detail to a design model is only useful upto a certain point, beyond which it starts to become a liability due to the impossibility of keeping it in sync with the code.

    I believe that using a few key UML diagrams to get my point accross to the developers, and a simple but easily configurable code generator would be more productive. Keeping my UML diagrams in sync with my code generator and code seems to be a colossal waste of time and energy.

    For an interesting read - http://www.martinfowler.com/articles/designDead.html
  61. If using MDA is comparable with programming in Java, then

    > that's more detail I'm willing to put in a model.

    Agreed.


    >Unless you're saying that MDA does away with programming in java all together...

    Simple (i.e. base level) MDA is UML class diagrams, plus FSMs to indicate the order in which events can occur, plus ASL which is a procedural language defining what occurs in response to events. To over-simplify, the class diagrams plus FSMs define what Java beans are required plus their relationships, and the ASL defines the code that "goes in" the Java Beans

    So yes, it is possible to "do away with programming in Java". Or at least to get rid of an awful lot of Java. Large projects in one or other form of MDA indicate that 40-60% of the code can be autogenerated. If that is the code that is changing frequently, then it is a big win.

     
    > Upfront design and architecture is good, but over doing causes
    > problems as faults in the design and architecture only become
    > apparent during implementation. Therefore, IMHO, adding detail
    > to a design model is only useful upto a certain point, beyond
    > which it starts to become a liability due to the impossibility
    > of keeping it in sync with the code.

    It is possible, with care, to separate the "business level" logic (PIM) from the "framework code" (PSM). If the "business level" logic can be sensibly expressed in terms of FSMs, then it is possible to execute and debug the business logic independent of the underlying framework. That can be a big win.


    > I believe that using a few key UML diagrams to get my
    > point accross to the developers, and a simple but
    > easily configurable code generator would be more
    > productive. Keeping my UML diagrams in sync with my code
    > generator and code seems to be a colossal waste of time
    > and energy.

    Most definitely. It is only of benefit if you *don't* have to do that manually, which brings us back to the semi-automatic code generation.
  62. Unless you're saying that MDA does away with programming in java all together.

    Fine grained process in specified in MDA as action semantics. Since the syntax of MDA's action semantics haven't yet been standardized, today the vendor picks a syntax -- either a proprietary scripting language or a general purpose one such as Java. The Action Semantics Consortium submitted the best proposal so far to OMG. Their submission proposes a meta description of fine grained process modeling which can be captured as scripts or flow diagrams. In theory a replacement for Java could emerge. Perhaps MDA's replacement for Java would be visual, in which case the future of procedural text would be uncertain.
  63. <Pereira>
    The proponents of MDA seem to think that UML diagrams should have so much detail that they can be used as blue prints for implementation, while the agile methodologies teach that diagrams should have only enough detail as required for effective communication.
    </Pereira>

    This is what I meant by my previous post. I like to think of software systems as organic creatures that are constantly growing. Modelling approaches like MDA would work if software was like (building) construction. Howerver having said that some upfront design is still required. I personally like to drive design by coding. With coding comes insight into the problem. Although this usually means you throw away some code, but so what? I find it is just as quick if not quicker since I have working code.
  64. MDA vs Java[ Go to top ]

    <quote>
    I personally like to drive design by coding. With coding comes insight into the problem.
    </quote>

    so you are for the bottom up approach (see my 1. thread MDA vs. Java) ;-) If we see a tool like Together, it's not impossible to do this. With the coming meta data in Java maybe we can enrich our Java interfaces and classes with some "visualization" meta data. Just like JavaDoc but for visualization (class diagrams, state diagram, use case diagram, etc.). Maybe this is already available? Do you know whether we have something like this with XDoclet?

    Lofi.
    http://www.openuss.org
  65. MDA vs Java[ Go to top ]

    <Dewanto>
    so you are for the bottom up approach?
    </Dewanto>

    I'm for uses models informally to communicate core/important concepts and details. For this reason I've never liked foward or reverse engineering of models. Even with TogetherJ that lets you hide details in the model, since changing the code require effort to get the UML diagrams simple.

    I find the most useful diagrams are those showing overall system design and complex collaborations between objects. And small details like a class method calling a simple method in the same class clutter the diagram and make it more diffcult to communicate the required information.
  66. I personally like to drive design by coding.

    So do I, and I totally dig Rapid Application Development which encourages this. Actually RAD primarily encourages the delivery of a superficial application, which MDA can easily produce. When the model is the code, the design-by-modeling is design-by-coding -- only easier.

    With coding comes insight into the problem. Although this usually means you throw away some code, but so what? I find it is just as quick if not quicker since I have working code.

    Of course early execution is paramount, and you're thankful to have it. This is the spirit embodied in MDA's executable models and simulation.
  67. The proponents of MDA seem to think that UML diagrams should have so much detail that they can be used as blue prints for implementation, while the agile methodologies teach that diagrams should have only enough detail as required for effective communication.

    Notice though that both MDA and Agile agree that developers should use UML. An agile modeler would be a fool to reject model compilation if it were available and workable. Eventually both camps will use model compilation, presumably since they both want to produce better applications with less effort.
  68. Yeah, but model compilation is useful only if your model is fairly complete. Creating a model to develop your software and creating one to communicate with team members are two very different things.
  69. Yeah, but model compilation is useful only if your model is fairly complete.


    Why? An executable MDA model contains all the "business logic" PIM information. Creating a skeleton MDA model is equivalent in all respects to creating skeleton business-level code. Some tools allow you to execute the model.

    If the PIM and PSM->PIM translator is available, it is also possible to execute that skeleton code in the real framework, which can be useful for quick performance tests et al.

    > Creating a model to develop your software and creating one to
    > communicate with team members are two very different things.

    Agreed
  70. <Tom Gardner>
    > Creating a model to develop your software and creating one to
    > communicate with team members are two very different things.

    Agreed
    </Tom Gardner>

    So MDA is a visual programming language not a modeling language? I've taken a look at some of the links provided on this thread and this appears to be the case. For this reason I have some deep concerns with MDA.

    Additionally it is trying to cleanly separate application concerns from system concerns. This is good in theory but doesn't work in practice IMO. For example User Authentication is both an application and system concern.
  71. <Tom Gardner>

    > > Creating a model to develop your software and creating one to
    > > communicate with team members are two very different things.
    >
    > Agreed
    > </Tom Gardner>
    >
    > So MDA is a visual programming language not a modeling language?
    > I've taken a look at some of the links provided on this thread
    > and this appears to be the case. For this reason I have some
    > deep concerns with MDA.

    I share your concerns. But I'm not going to be drawn into a discussion where modelling stops and coding begins, since I don't want to disappear down that rathole.

    When one vendor's MDA tool was first thrust under my nose and pushed (hard) as being the solution to all our current woes, my first reaction "oh yes, Yet Another Proprietary Scripting Language plus Software Thru Pictures. Yawn".

    On deeper inspection I found it to be theoretically sound and *very* good for *some* classes of problems (those that can be best expressed in FSMs).

    So yes, it is software thru pictures, but the pictures are a useful limited subset of the UML notation (of which I'm not a great fan).


    > Additionally it is trying to cleanly separate application concerns
    > from system concerns. This is good in theory but doesn't work in
    > practice IMO. For example User Authentication is both an application
    > and system concern.

    Agreed. As an engineer I try to determine where a tool is beneficial and where it is a irrelevant. I believe that for a significant class of problems it will be able to autogenerate around 50% of the code. Fortunately I am as last making progress in getting other people in my company to recognise that, but it has been a long and unproductive struggle.
  72. So yes, it is software thru pictures, but the pictures are a useful limited subset of the UML notation (of which I'm not a great fan).

    In MDA this "useful limited subset of UML" is called a "UML profile" -- it's the subset of UML that an architecture's code generation templates recognize and that an architecture's runtime supports.
  73. So yes, it is software thru pictures, but the pictures are a useful limited subset of the UML notation (of which I'm not a great fan).

    >
    > In MDA this "useful limited subset of UML" is called a "UML profile" -- it's
    > the subset of UML that an architecture's code generation templates recognize
    > and that an architecture's runtime supports.

    Yes. Then MDA adds the Action Semantics Language to allow the models to be executable. I know I'm simplifying, but that's the main thrust and value proposition of MDA.
  74. MDA - Rational Vs Agile Alliance?[ Go to top ]

    Tom wrote

    <em>Yes. Then MDA adds the Action Semantics Language to allow the models to be executable. I know I'm simplifying, but that's the main thrust and value proposition of MDA.</em>

    True. ActionSemantics will turn out as a great value to MDA. Think about a scenario where you model your system, then decide to project one part to technology A, another part to technology B. Interfacing the parts may require glue code. If you have the cross-part calls expressed in ActionSemantics, the corresponding glue code can be generated automatically by an MDA tool. This is wonderful.

    BTW: The link between ActionSemantics and MDA is probably not as close as Tom suggests. I see MDA being based on MOF. You can express any type of behavior-capturing metamodel in MOF. UML activity diagrams or sequence charts are just one example of this, and Action Semantics is another one. You can also jot down the "metamodel" for a 3GL such as Java using MOF, no problem. With this, you can use Java as the target, but theoretically also as the source of a model transformation.

    -- Axel
  75. user access control[ Go to top ]

    For example User Authentication is both an application and system concern.


    In my mind your user authentication would be developed in the normal way.
    In the model the services of user authentication are used where
    ever they are needed. The code generator takes the model spec and
    generates the code to use the user authentication access.

    Now you have two points of leverage. The authentication code itself
    can be changed without impacting the generated code. This is normal
    encapsulation.

    Now let's say you have to switch to a different library for some
    reason. The generated code can be changed and the model doesn't
    need to change if the approaches are similar enough. If not maybe
    the model as to change.

    Now let's say you have to pick an authentication method depending on
    context and your encap library can't handle this. You could generate
    the code to perform this logic without changing the model.

    Now let's say your authentication library was wrong and people cut
    and pasted the code to 100 places in the code. This ia a large change
    and people aren't that excited about the risk so close to a release.
    With MDA you could generate the code in a less risky way. You don't
    have to rely on 100 separate correct edits and tests.

    Now let's say you want to target an html web app instead of a swing app.
    The code generated can be retargeted and the model will not have changed.


    There's no magic. Some of the same results can be achieved in other
    ways, but it can be very powerful if used appropriately.
  76. MDA vs. Java[ Go to top ]

    <quote>
    Now let's say you want to target an html web app instead of a swing app.
    The code generated can be retargeted and the model will not have changed.
    </quote>

    Yes, this approach of MDA is very interesting. I think, the main "thing" in MDA is the transformations (PIM->PSM, PIM->PIM, etc.). This makes the example you've shown, easy to implement.

    But what about using Java for this? You can also do the "model" in pure Java language and implement in different ways. Using interfaces in Java (+ Design by Contract) you can model your app and implement it in different ways (swing and html). No problem :-) Surely you need to implement them by hand, but you can also use code generations (transformations) just the same as MDA.

    <quote>
    Now let's say your authentication library was wrong and people cut
    and pasted the code to 100 places in the code. This ia a large change
    and people aren't that excited about the risk so close to a release.
    </quote>

    If you see ACE or Jackpot research project from Sun, they are working on optimizing this (refactoring, visualizing, etc.) so in the future you don't need to do "cut" and "paste", instead refactor the bad code and everything is done for you automatically.

    You can also do "copy" and "paste" in MDA (modelling your application) if you are not carefull ;-) This is not only a mistake that can happen in Java programming but also in modelling with UML.

    So, I think, Java still has a capability to become an "overall" language. It's only the time will tell us, whether pure Java or MDA (UML, OCL, XMI, etc.) is the way to go.

    Lofi Dewanto.
    http://www.openuss.org
  77. MDA vs. Java[ Go to top ]

    Refactoring complex things is diffcult. One example from my embarrased
    past is the use of messages sent over an interface. The messages were
    hard to build. The error cases from a message send were hard to deal with.
    And the interface allowed developers to make decisions, ala timeouts, that
    they shouldn't have been allowed to make. What resulted is a complex tangle
    that was impossible to cleanly refactor when we wanted to change how
    it was done. As you might expect in a large project there are thousands
    of such calls so we decided not to change anything.

    The UML model also needs to be refactored. Hopefully a lack of implementation
    details will make this less necessary. To some extent we are just moving
    problems to a different level. But there is power in that level jump.

    I don't think representing the same thing in code is as powerful
    because the power is in the mapping between the model and the environment.
    The mapping is where the decisions are made, this is where the code is.
    If you remove the intelligence in this mapping you are stuck with static
    relationships that aren't changeable without programmer driven refactoring.
  78. MDA vs. Java[ Go to top ]

    <quote>
    The UML model also needs to be refactored. Hopefully a lack of implementation
    details will make this less necessary. To some extent we are just moving
    problems to a different level.
    </quote>

    agree.

    <quote>
    I don't think representing the same thing in code is as powerful
    because the power is in the mapping between the model and the environment.
    The mapping is where the decisions are made, this is where the code is.
    If you remove the intelligence in this mapping you are stuck with static
    relationships that aren't changeable without programmer driven refactoring.
    </quote>

    code is just a textual representation of your application. To write an application we always need a language (just like a normal language, so we can communicate). UML (that's why L == Language) and Java are both languages only with different abstraction level:

    - UML for modelling -> coarse grained and
    - Java for programming -> fine grained (at the moment).

    With MDA and the development of UML 2.0 the UML is becoming more fine grained (and still can be used for coarse grained modelling). With the development of meta data in Java, Jackpot, etc. Java is becoming more coarse grained (and still can be used for fine grained programming). So, I can imagine that Java can be extended to have some visual representations, maybe some sound representations as well? ;-) And this is very usefull if we can adapt this into the coarse grained Java.

    As it's usefull to have transformations in MDA, it's also usefull to have this in Java (meta data, Jackpot especially the "Code Analysis and Transformation" part makes this real).

    So, I still have a hope that Java could be the "lingua de franca" ;-)

    Regards,
    Lofi.
    http://www.openuss.org
  79. MDA vs. Java[ Go to top ]

    So, I still have a hope that Java could be the "lingua de franca"

    Presumably if action semantics become detailed enough, then eventually all algorithmic handiwork could be expressed solely as XMI, in which case all Java could be emitted by stylesheets.
  80. MDA vs. Java[ Go to top ]

    <quote>
    Presumably if action semantics become detailed enough, then eventually all algorithmic handiwork could be expressed solely as XMI, in which case all Java could be emitted by stylesheets.
    </quote>

    Yes, and this is what I don't like ;-) So we are back again in the discussion "XML (because XMI is XML) vs. Java" ;-) I cannot imagine if I have to write the whole algorithmen in XML. I know, I can use that or this tool, I don't have to edit the XMI file with text editor, but I feel that Java is more natural than XML as a language.

    Lofi.
  81. MDA vs. Java[ Go to top ]

    I guess i don't think trying to make UML include all the programming
    details as useful. Java is a text representation of a program,
    but i'm not trying to specify a program. I'm trying to specify
    what i want and have a program built to implement it. They are
    very different things and the difference is in the details.

    If i say i want a bidirectional relationship, i shouldn't also
    also add the detail of implementation using link lists. The
    mapping will figure out how to implement it given the environment.
    This implementation could be very differetn depending on the
    environemnt.

    In another arena consider the US president tells joint chief of
    staff to fight a war. Generals are told to defend or take an area.
    A captain is told to defend a hill. A squad is told to defend this
    part of a hill. A fire team mans a position. An individual soldier
    makes many many tactical decisions. And no point did any layer try
    to tell the lower layers how it was done. The goals and constraints
    were specified. Each layer mapped that into their environment.
    A president trying to control individual soldiers and every layer
    inbetween won't work and it won't work in programming. In programming
    our model of power implies we can control each detail, but it hasn't
    worked.
  82. MDA vs. Java[ Go to top ]

    <quote>
    A president trying to control individual soldiers and every layer
    inbetween won't work and it won't work in programming. In programming
    our model of power implies we can control each detail, but it hasn't
    worked.
    </quote>

    agree, that's why "coarse grained" Java, meta data and transformation in Java. You don't have to be detailed in Java. Interface for example. You don't have any detail information here.

    I think, this is all about my language preference. I still like Java more than XML (XMI) ;-)

    Lofi.
  83. MDA vs. Java[ Go to top ]

    Generals are told to defend or take an area. A captain is told to defend a hill. A squad is told to defend this part of a hill. A fire team mans a position. An individual soldier makes many many tactical decisions. And no point did any layer try to tell the lower layers how it was done.

    This is called "recursive design" in the Shlaer-Mellor methodology, which is the methodology that most inspired MDA. Steve Mellor is one of MDA's active contributors.
  84. MDA vs. Java[ Go to top ]

    It's really just the old idead of building little
    languages with more elaborate code generation.

    One thing about using java instead XML is i don't see
    how you build complex datastructures and relations of
    things without resorting to coding. I've never like
    that aspect of using java instead of XML.
  85. MDA vs. Java[ Go to top ]

    I think I really need to checkout some of the current MDA tools. I'm interested to see how people who are for agile modeling are handling the formal/informal modeling difference between agile modeling and MDA modeling.
  86. MDA vs. Java[ Go to top ]

    I think I really need to checkout some of the current MDA tools. I'm interested to see how people who are for agile modeling are handling the formal/informal modeling difference between agile modeling and MDA modeling.

    I am aware of one offshore company with resources in US that is using consultants locally to do formal modeling and then shipping the code generated from the model to India for final implementation. If they are really pulling it off, has to be ultra-cheap way to develop software. No idea how it effects time-to-market though.
  87. MDA vs. Java[ Go to top ]

    I'm interested to see how people who are for agile modeling are handling the formal/informal modeling difference between agile modeling and MDA modeling.

    The difference between Agile and MDA is that MDA is the methodology where the diagrams and the code haven't diverged over time. An agile modeler might find his stale diagrams useful as tiolet paper.
  88. So MDA is a visual programming language not a modeling language?

    False dichotomy. Programing is synonomous with process modeling.
  89. <Brian Miller>
    > So MDA is a visual programming language not a modeling language?

    False dichotomy. Programing is synonomous with process modeling.
    </Brain Miller>

    My point is that with MDA you are using the UML diagrams in a formal manner and this is visual programming. I use UML diagrams informally to communicate important details and concepts.

    One of the links in this thread shows a comparision of informal/incomplete UML diagrams to formal/complete UML diagrams. And the informal diagrams are easier to understand especially the activity diagram.

    This is an important issue that I think people forget. I'm for agile modelling and MDA is more for those that used CASE tools to generate code.
  90. MDA - Rational Vs Agile Alliance?[ Go to top ]

    Nilesh,

    first I swear I _do_ work for a tool vendor ;-)

    As a matter of fact, I don't think at all that every detail of your system's specification should be put into a single model. To the contrary! I think this would turn the whole MDA effort into a lost cause. One central aspect is the portability and longevity of your specifications. Sometimes, though, parts of a specification simply _have_ to make mention of platform-specifics. These have to be put into a set of marks or a more detailed and separate model so that the more abstract model can still be used to derive implementations for other platforms.

    <flamesuit>
    I assume that some tool vendors suggest to use a single complete model because it's more difficult to implement a tool that copes with several models at different levels of abstraction which all have to be kept in sync somehow.
    </flamesuit>

    Seriously: It can be tricky to manage manual changes to a model / sourcecode when this model / sourcefile has resulted from an automated mapping function. For sourcefiles, markups solve this problem. For other models, such as UML models, this problem can be much more tricky.

    -- Axel
  91. MDA - Rational Vs Agile Alliance?[ Go to top ]

    Axel,

    > first I swear I _do_ work for a tool vendor ;-)
    You made me laugh out loud with this!

    > Seriously: It can be tricky to manage manual changes to a model / sourcecode > when this model / sourcefile has resulted from an automated mapping function.

    Exactly! That's been my concern all along! And the only responses I've received to that have been:

    1. It won't
    2. It's the future
    3. You don't understand diagramming & model compilation

    -Nilesh
  92. MDA - Rational Vs Agile Alliance?[ Go to top ]

    Nilesh,

    > > Seriously: It can be tricky to manage manual changes to a model / sourcecode > when this model / sourcefile has resulted from an automated mapping function.
    >
    > Exactly! That's been my concern all along! And the only responses I've received to that have been:
    >
    > 1. It won't
    > 2. It's the future
    > 3. You don't understand diagramming & model compilation

    we do it today at least for generated source-code artifacts. Some people blame us for marking up the code, but OTOH this is a general approach that works neatly for any kind os ASCII-based generated artifact, including XML, COBOL (yes, we've shown that in a project where Deutsche Bank Bauspar used ArcStyler, see related TSS article) and any kind of architecture you choose to target by writing your own ArcStyler cartridge.

    We plan to do the same thing for models. As you may know, we're a submitter for the OMG's QVT RFP. Our submission currently mentions this issue in a remark only. I think the solution has to work similar as in the ASCII-based case: there's the last reference copy of a part of the target model that was generated during the last cartridge feature execution; there's the current copy that may contain manually-edited pieces; and there's the new reference copy of that part of the target model as generated during the latest cartridge feature run. Do a smart "diff3" on the three artifacts and intelligently merge the user-imposed changes into the new reference copy. That'll do the trick.

    TBD: a generic diff3 for a model whose metamodel is MOF-based
    TBD: a smart way to define a "realm" of stuff to be treated this way in a cartridge
  93. MDA - Rational Vs Agile Alliance?[ Go to top ]

    As you may know, we're a submitter for the OMG's QVT RFP.

    We'll have to take your word for it. Sadly, OMG hasn't publicized the QVT RFP, the submitters, or their submissions. Of course qvtp.org is helpful, but that's only one rival submitter that's opted for publicity. Alas, back room politics as usual at OMG.
  94. Agile MDA[ Go to top ]

    It is crucial for an MDA tool to support an Agile methodology. OptimalJ has been built with that objective in mind from the ground up.

    Extendable out-of-the box transformation patterns for PIM->PSM->code are provided. A toolset to create transformation patterns from scratch are also included. You can choose among the architectures we provide, you can extend them, you can also build your own from scratch or take ours as an example.

    After a first iteration, you can change your PIM, PSM and code. The transformation process will preserve your changes. If you want to revert to the default transformation, you can do so at a granular level.

    Each elements of the PSM are linked to source code files and PIM elements. Transformation patterns know whether elements were changed and can act accordingly.

    Gyl Savoie
    Product Manager - OptimalJ
    Compuware Corporation
  95. Agile MDA[ Go to top ]

    It is crucial for an MDA tool to support an Agile methodology. OptimalJ has been built with that objective in mind from the ground up.

    I know very little about MDA, but I can't see how MDA and Agile development can ever go together. Agility is about discovery through imperical feedback. From what I've seen, MDA is about Big Upfront Design - top down.
     
    As I understand it MDA models aren't executable directly, and some translation is required. The issue then is how long does it take to get feedback on your design? How long is the build-test cycle?

    With a text based language using a modern IDE the build-test cycle can be as little as seconds. Can MDA achieve the same?
  96. Agile MDA[ Go to top ]

    Paul,

    <quote>
    With a text based language using a modern IDE the build-test cycle can be as little as seconds. Can MDA achieve the same?
    </quote>

    Yes this is possible. Maybe not for seconds because your development PC should be very fast to achieve this :-) Because you need a UML modeler and an IDE at the same time...

    The idea is quite simple and very pragmatic (E-MDA):
    1) Model your app within your UML modeler. Output: XMI file.
    2) Compile the model (XMI file) with your model-model- or model-text- or model-code-transformations (you can chain these transformations as you wish) to create specification, business, data, prentation, test, etc. in Java for example. Output: Java files.
    3) Extend the "generated codes" for your purpose in your IDE. Using Eclipse for Java for example.
    4) Compile to Java classes. Output: Class files.
    5) Run.

    Always do this in short cycle and don't forget your model is always your source code ;-)

    The bottleneck at the moment is the speed of model compilation. But for this problem there are some solutions. The next version of AndroMDA (model-text- and model-code-transformations tool) can be started as a "server" so that it always be there in the memory and does not need to reopen the models everytime it has to compile them.

    Please check out this article series for more details:
    http://www.jaxmagazine.com/itr/news/psecom,id,21908,nodeid,146.html

    I'm also preparing an article about Pragmatic Model Transformations for Developers...

    Cheers,
    Lofi.
  97. Now I want to be a little provocative, so as to give other people a chance to modify my prejudices :)

    I can see that MDA is clearly applicable and beneficial for solutions that can be expressed in terms of Finite State Machines (FSMs), because MDA uses StateCharts plus ASL to define the time-dependent behaviour of objects. But can MDA *practically* be used to express other forms of function and behaviour?

    Examples of other ways of expressing solutions:
      - forward chaining production systems (as exemplified by Ilog's Rules,
        Haley's CIAServer, Jess et al)
      - backward chaining goal-seeking constraint satisfaction engines
        (as exemplified by Prolog)
      - data driven pattern matching in which the required result is a complex
        stateless mapping function based on multiple data fields (e.g. a
        pricing calculation based on product, weight, carrier, phase of moon)

    If your application naturally leant itself to being expressed in those terms, would you try to use MDA, would you use MDA to invoke the relevant library, would you avoid using MDA altogether?

    In other words, what would you regard as contradications against using MDA?
  98. MDA is no silver bullet, is not going to change the world, will not make architects obsolete, or turn us all into analysists.

    From my experience, <vendor-plug> mostly gained with our own tool, iQgen </vendor-plug>, an MDA tool can simply help you to avoid wasting your time with doing monkey tasks, such as implementing yet another entity bean exactly the same way you implemented the last 500. It also helps you very much in case you ever need to change the way you use your underlying technology platform, e.g. moving from EJB to JDO or vice versa, which is possible with a good tool by changing the transformation (while preserving existing code). That's not to say that you should stop using Java, or a more generic approach based on runtime configuration, or whatever is best for the task at hand. There is simply a class of problems that are most efficiently solved by code generation driven by a model - with the added benefit that you have model and code in sync at all times.

    Back in december, I wrote an article for TSS that generated a similar discussion as this one (see 'MDA From a Developer's Perspective'). I have posted a slightly edited version of the article on my weblog.

    From my perspective, the key to success with MDA is to take a pragmatic approach and make sure it's you who decides what your architecture should look like. Once you have played around with a decent MDA tool and experienced the increase in productivity, I predict you'll never go back.

    Stefan
  99. <Stefan>
    From my perspective, the key to success with MDA is to take a pragmatic approach and make sure it's you who decides what your architecture should look like. Once you have played around with a decent MDA tool and experienced the increase in productivity, I predict you'll never go back.
    </Stefan>

    Couldn't agree more. Worked at a client using MDA-tool that delivered 'architecture in a box' provided by vendor with customization allowed by user. Please make sure if you look a tool, you have complete control of the what architecture should be. Waiting on the vendor or trying to get support integrating with something you don't have access to is no way to increase productivity.

    OTOH, generating all the monkey code and focusing on the value-add to the user/business was refreshing.

    This thread mentions OptimalJ and iqgen. Is anyone using anything else? Especially something they like.
  100. OTOH, generating all the monkey code and focusing on the value-add to the user/business was refreshing.

    Ie, we developers would rather be doing analysis. The intellectual reward isn't in the bit twiddling.
  101. <quote>Ie, we developers would rather be doing analysis. The intellectual reward isn't in the bit twiddling.</quote>
    I believe this is not an issue at all. If you have better tools, you can achieve more in less time. That doesn't free you from having to think about functional as well as non-functional requirements. Instead of writing a document that describes how to implement persistence, how to transfer data between tiers, how to handle object identity etc., the architect designs and tunes the transformation templates.

    As an architect, I couldn't care less about the business domain. I care about scalability, performance, architectural design patterns, maintainability, and so on. With an MDA tool, I can just do it more efficiently. And I find it extremely rewarding.

    Some more thoughts on monkey code here.

    Stefan
  102. "Ie, we developers would rather be doing analysis. The intellectual reward isn't in the bit twiddling."
    I believe this is not an issue at all.


    You imply that job satisfaction doesn't matter, which is an interesting position for a tool vendor to take. Anyway, analysis is much more fun than coding, and this amounts to a spiritual imperative for MDA.
  103. <quote>You imply that job satisfaction doesn't matter</quote>

    You misunderstood me - I just don't think that with MDA, all that's left to do is analysis. I am in violent agreement with you if you meant to say that developers can focus on creative work with an MDA approach (and do away with stupid, mind-numbing, repetitive tasks).

    Stefan
  104. Brian,

    Ie, we developers would rather be doing analysis. The intellectual reward isn't in the bit twiddling.

    if the amount of bit twiddling someone does is creative and unique, he/she'll probably be an architect in the sense of defining MDA mapping functions. Only that this will only be necessary once per smart idea for the entire system. If the bit twiddling is tather the "monkey" stuff mentioned several times on this thread, it may be better to resort to doing analysis :-)

    -- Axel
  105. Michael,

    again, a surely biased statement ;-), but you asked. While we make ArcStyler, we also use it in several projects, from small-scale (2 people, 2 years) to large-scale (50 people, several years). Also, we use the tool in developing the latest release of ArcStyler (4.0) itself. In two areas we would be helpless if we didn't have ArcStyler: anything related to repository integration (note the broadness of the UML metamodel and think about JMI adapters to existing UML tools...), and the MDA cartridge (implementation of model transformations) modeling. We have tons of UML models of our different cartridges and generate >90% of their implementations from the models. We expose this feature to our customers, and we have several reference customers who use this way of creating their own cartridges, either from scratch or by inheriting from the cartridges at www.mda-at-work.com, or by downloading the cartridge sources from that same website and then modify the cartridge models / sources.

    Sorry, not necessarily meant as a commercial, but Michael asked... ;-)

    -- Axel
  106. again, a surely biased statement ;-),


    I am sure it is :)

    > Sorry, not necessarily meant as a commercial, but Michael asked... ;-)

    I guess I did.

    From the little tool perusing I have done, here is what I come away with. Everyone uses UML to one extent or another to design/build the application spec. The differences seem to be in how they get that to code. I have yet to see one of these cartridges or templates or metaprograms that perform such magic ;) AndroMDA mentions using Velocity templates. Seems simple enough, but I don't know much about them. Given I'll have to learn (as well as teach) UML already, I'd like to avoid another new technology.

    Guess my question is what does a cartridge look like? Is it Java, XML, other? I couldn't find the project you mention on Source Forge.

    MT
  107. Michael,

    look for it at www.mda-at-work.com and go to the "Cartridges" link. This provides you with an overview of the stuff that's available. Once you install the free community edition of ArcStyler (see here), you can download these cartridges for free from within the tool.

    The cartridge spec is expressed using UML again. From that, we generate J(P)ython code where we have to fill in the one or the other protected area where we specify, for example, output syntax and formatting details. Eventually, ArcStyler executes the JPython code. It can be precompiled into a single precompiled .bin file which makes it easy to bundle, deploy and distribute.