Discussions

News: Martin Fowler speaks out on MDA

  1. Martin Fowler speaks out on MDA (81 messages)

    Martin Fowler has recently posted a blog entry on Model Driven Architecture (MDA).

    "Some people think that Model Driven Architecture (MDA) will be biggest shift in software development since the move from assembler to the first high level languages. Others think that it's nothing more than Night of the Living Case Tools. I'm in the latter camp but feel the need for more than a slick saying."

    Strong words. He compares MDA to the CASE tool talk of the 1980's.

    Read Martin Fowler in ModelDrivenArchitecture

    Threaded Messages (81)

  2. MDA[ Go to top ]

    <fowler>
    In many ways I'd love to be wrong about this. I would really like to see software development raised by a level of abstraction. (Not to mention that the UML's success would be good for me personally.) But I don't see that the UML provides this abstraction jump - and without it the MDA will not succeed.
    </fowler>

    I don't know how Mr. Martin Fowler defines "higher level of abstraction" but if it's the definition of Mr. Grady Booch (see the interview at
    http://www.theserverside.com/news/thread.jsp?thread_id=23684):

    <booch>
    That is what Java and C Sharp and C++ are all about. Each one of these things moves me further away from the bare hardware and actually allows me to express things where once I had to expand them out and through the bare hardware by many orders of magnitude. This allows me as a human to start addressing the problem further away from the machine and closer to the problem area.
    </booch>

    then IMO, UML + MDA has sofar provided a higher level of abstraction. In PIM you model your domain totally independent of all those "platform specific stuffs" like J2EE.

    Example:
    -> I just simply say: a student can hear many lectures and a lecture can be watched by many students. That's it. I don't care whether the class Student and Lecture has to implement EntityBean and EJBObject or maybe just a simple POJO... And this is *exactly* how we start to move closer to the problem area.

    At the moment we haven't had any possibilities to compile directly a UML diagram into a running application, at least not in Open Source world, but I don't see this as a problem. IMO, the development lifecycle would look like this:
    - Draw your PIM.
    - Transform the PIM into PSM (This step is optional)
    - Compile the PIM (XMI) and generate the beginning code.
    - Implement the code.
    - etc...

    You'll have one step more: draw and compile your PIM but this is where you go closer to the problem area instead of digging into the platform specific detail. The coding will stay there, no worry ;-) So, the combination of both worlds:
    "Model Driven + Sourcecode Centric" will rule in the next generation. In the practical Open Source world, you can combine AndroMDA for the model driven and EJOSA for structuring your code.

    I think Mr. Fowler has to check out some MDA tools out there ;-) I can recommend him to take a look at AndroMDA (http://www.andromda.org). Matthias and his team have developed a very nice and pragmatic MDA tool there. Just try it!

    Also a very good book about MDA: Model Driven Architecture: David S. Frankel. A very nice book, IMO.

    Cheers,
    Lofi.
    http://www.openuss.org
  3. MDA + Sourcecode Centric[ Go to top ]

    Forget to tell:

    you can also see how important XMI is by looking at NetBeans and Eclipse. They both offering projects in this area: NetBeans MDR and Eclipse EMF + UML2

    Thanks,
    Lofi.
  4. MDA[ Go to top ]

    I think there are two big differences between CASE and MDA that Martin is missing.

    Firstly, in the days of CASE we were often modelling architecture as well as business. With MDA the architecture is almost a commodity so we can focus our time and detail on the business.

    Secondly, the PIM -> PSM translation is all about patterns. Transforming a generic business model into a set of patterns appropriate for a particular platform. When CASE was around, patterns were much less mature and understood. With CASE we were also modelling and inventing all the patterns as well and this made the whole thing many orders of magnitude more complex.
  5. One point people seem to be missing here from Fowler's posting is that just because MDA is *possible* doesn't mean it would be *practical*. Sure, for domain modeling give me a visual tool every time, but can you imagine creating a significant application just through diagrams? It would be a nightmare!

    The better approach is the one Together Control Center takes which is to treat the Java as the model and allow that to be manipulated visually. In the past TCC was a bit weak on one-to-many relationships, but generics in 1.5 should allow these to be modelled explicitly.

    Cheers,

    Ian.
  6. MDA[ Go to top ]

    <fowler>
    In many ways I'd love to be wrong about this. I would really like to see software development raised by a level of abstraction. (Not to mention that the UML's success would be good for me personally.) But I don't see that the UML provides this abstraction jump - and without it the MDA will not succeed.
    </fowler>

    I agree 100% with Mr. Fowler.

    <!--
    I don't know how Mr. Martin Fowler defines "higher level of abstraction" but if it's the definition of Mr. Grady Booch (see the interview at
    http://www.theserverside.com/news/thread.jsp?thread_id=23684):

    <booch>
    That is what Java and C Sharp and C++ are all about. Each one of these things moves me further away from the bare hardware and actually allows me to express things where once I had to expand them out and through the bare hardware by many orders of magnitude. This allows me as a human to start addressing the problem further away from the machine and closer to the problem area.
    </booch> -->

    Yes C# and Java provide you the abstraction, but there is a limit of abstraction one can achieve due to constraint of these languages. I mean these languages are imperative at the end of the day, and writing compilers to generate Java and C# code from high level business processes is still a daunting task.... and so far not very practical.
  7. The Middle Path[ Go to top ]

    As rightly pointed out in many posts,

    MDA can be very effective tool to enhance productivity, but as of now it will not be pragmatic at all to expect MDA to do all the coding for you.

    I do not have any practical experience with MDA, but based on what I have read, I believe it should be effective in generating the initial PIM and PSM and the first cut of skeleton and plumbing code based on the PSM. It should also allow the designer/architect to incorporate well established patterns, which solve the problem under consideration and may be (depending upon the tool) the option to choose the best starategy to implement that pattern (Given that we have well established nomenclature of patterns and different implementation strategies for each pattern).

    Having done that, nothing stops the developer to work on the code itself, and as the need arises revert back to the tool.

    May be things will further evolve in future which will allow developers to generate nearly 100% implementation code from the model itself.

    Philosophically speaking, I would go for a middle path, be it code generation or development methodologies. Based on my experience, even for development methodologies, I have found a middle path (somewhere between RUP and extreme programming) to be more effective than any of the extremes.
  8. UML lacks on the behavioral level[ Go to top ]

    Although MDA and MOF do not enforce a meta-model, UML is in de facto the only meta-model most of the industry get to work with (CWM for instance is not that common).
    As a system architect I confess that in most practical cases I find the Class-Diagram to be the most useful design tool for my work. The problem starts when I am to describe java design using the various behavioral UML diagrams. Ranging from Sequence through Collaboration and Activity, I sometime find these diagrams unfit for my work. I usually end up describing the API via few sequence diagrams but will refrain in most cases from using any other diagram.
    The problem in my opinion is that UML heavily lacks on the behavioral level. In my opinion it should have some unified behavioral diagram. This diagram should unify most of the behavioral elements that modern OO language such as Java and C# use. Such elements could be threads (working in parallel) and algorithm work flow atoms by which I as an architect can give the developers a better understanding of the required implementation. In my opinion the UML behavioral diagrams are too loosely related to the code that we aim to manufacture.
    Hence in my opinion, using MDA or any other "case" tool which is based on a UML meta-model and its diagrams, would obviously carry with it the behavioral difficulties inherent in the UML itself.
  9. I do not think it is feasible. Just like EJB, its all hype.
    Practical feasibility of 100% code generation is outright impossible.

    It is waste of time. You heard it here first.
  10. Martin Fowler speaks out on MDA[ Go to top ]

    I'm not big on the hyperbole that's so typical of this industry, so I won't ever jump on any bandwagon declaring MDA as the next big thing since sliced bread. It's really not. I do, however, find it to be an extremely useful tool in my toolbelt. I'd compare its usefulness to a really good IDE. It's an incredible timesaver and once you start using it a lot, you can't really live without it.

    There are innumberable practical uses for MDA, if used intelligently. I use it on a daily basis and it's the main reason why I can handle so many projects simultaneously. I've spent a lot of time working on architectures for different clients, and using MDA (specifically, AndroMDA), I'm able to very quickly deploy that architecture across very large business models. If I have 5, 10, or 50 business entities, there's no real difference in the time it takes me to roll out the code for about 80% of the code that's needed. That includes POJOs, database configuration, internationalization files, logic frameworks, even web framework config and page layouts. The biggest advantage I've seen is using MDA when your framework is evolving. I no longer need to worry that a given framework handles everything perfectly, because when I run into issues or limitations, I can fix them or expand the framework, and then pretty much instantly roll the changes out across all of my business entities.

    The biggest reason, I think, that I've had success with MDA is that I haven't attempted to make it's something it's not. It's a tool, and a useful one, but there's no getting around the fact that it's not going to do everything. I'll be really surprised the day that I see people compiling directly from UML and even more surprised if the result is ever going to be worth anything. MDA can take care of about 80% or so of your drudgery coding, but the rest will usually always need to be customized. As with anything else, it's that last 20% that kills you, but I'd rather spend my time dealing with the difficult, exceptional cases than pounding out line after line of repetitive POJO code. Especially when one minor change in requirements or technical issues can invalidate most of the hand-written boiler-plate code.

    One thing I've spent a lot of time on is working out ways to make sure that I've isolated the tricky 20% from the rest as much as I possibly can. One nightmare I ran into in my early use of MDA was the fact that as you start customizing code-generated files, you can't overwrite them on the next generation. It's a slippery slope. Most of what I've done with MDA revolves around solving this problem. I've found the use of interception to be extremely useful (I use xwork at a logical level), along with creative subclassing (abstract base classes get generated, custom code goes into subclasses) and the use of interfaces to mark where outside frameworks link up to your business model (e.g, abstracting an authorization framework so that it can get its configuration from a set of business model classes; the business model classes have to be fully modeled because they're fully editable by the end user).

    I'd be interested to hear more about other people's practical experience with MDA. That's a lot more valuable to me than predictions about what it might become in the future.
  11. MDA + Sourcecode Centric[ Go to top ]

    Drew, agree with your post 100%!

    Therefore I always say = "Model driven + Sourcecode centric". You still have to write your application but in such a manner that is more structured (therefore I integrate EJOSA with AndroMDA). Like seperating the "src-generated" and "src" directory, so that you'll never change the generated sources. Also just doing forward engineering like "compiler" has done.

    Cheers,
    Lofi.
  12. Martin Fowler speaks out on MDA[ Go to top ]

    I've been using AndroMDA to do the same thing, customise the cartridges to create the code that I want and then create the static model. To avoid overwriting code I use AOP to implement much of the custom code, the only code that is difficult to autogenerate is the HTML code from JSPs because they are subject to UI change.

    AndroMDA is a great product, but the documentation needs to improve, the site is still using the wrong stereotypes for struts actions/forms etc. The examples are also too big, if you choose to use AndroMDA it can be safely assumed that the audience knows how to compile & deploy applications. The first thing I had to do was cut out all the targets in the build file that I knew about and then focus on the stuff I didn't.
  13. AndroMDA[ Go to top ]

    <quote>
    AndroMDA is a great product, but the documentation needs to improve, the site is still using the wrong stereotypes for struts actions/forms etc. The examples are also too big, if you choose to use AndroMDA it can be safely assumed that the audience knows how to compile & deploy applications. The first thing I had to do was cut out all the targets in the build file that I knew about and then focus on the stuff I didn't.
    </quote>

    This is what I try to do in EJOSA (http://ejosa.sourceforge.net), simple example, simple structure, simple development process with different impl. techniques with all Open Source products. I'm adding AndroMDA on the top. Hope that this can lead to more acceptance with MDA (MDA for Dummy) ;-)

    Cheers,
    Lofi.
  14. Martin Fowler speaks out on MDA[ Go to top ]

    <snip>
    To avoid overwriting code I use AOP to implement much of the custom code, the only code that is difficult to autogenerate is the HTML code from JSPs because they are subject to UI change.
    </snip>

    The AndroMDA team is thinking/talking about the possiblity of making the cartridges update only that part of the generated code that needs update, that way you could do incremental generation cycles not losing any manual implementation. But there's nothing concrete yet.

    > AndroMDA is a great product, but the documentation needs to improve, the site is still using the wrong stereotypes for struts actions/forms etc.

    Indeed, the existing cartridge for struts featured only class diagrams, that not really helps since process flow should be expressed with behavioral elements, the ones that make up the dynamic part of a UML model.

    That's why a new cartridge has been developed and will be released in the near future, it is called 'bpm4struts' and it features use-case and activity graph modeling for your front-end process flow logic, it should support most of the desired features (also via XDoclet) : validation, struts-config.xml, auto-generation of default JSP implementations, minimal user intervention

    it should also be easy to reuse this cartridge to adapt it to WebWork, Velocity, or whatever you want ...

    check it out here: http://www.andromda.org/tiki


    about Martin Fowler's blog:

    "As an example, consider behavioral logic. I can't see that drawing sequence diagrams or activity diagrams is as good, let alone better, than writing code in a modern language. I find this is true even when I have to write code to a greater degree of precision than the diagrams, as I do if I want to execute and test them."

    I think this is not a point against MDA or UML in /se/, but more a lack of creativity on Fowler's part.

    Behavioral model elements provide the means of abstraction required for process modeling, as an example I refer to the AndroMDA cartridge implementation of the Struts framework. The combination of class diagrams (MVC) and activity graphs (struts-config.xml) permits generation of 85% of the code (if not more): JSPs still need proper layout and actions need some methods implemented (mostly a simple delegation to your back-end)

    Everything else is taken care of: exception handling, URL rewriting, even rendering the appropriate widgets in the JSPs (depending on the type of the field).

    But MDA is not only about UML and generating code... It allows and helps you to think more in terms of use-cases, IMO very underestimated. I understand the feeling against CASE tools, but (given the right tools) don't make the mistake of thinking about modeling your application as a burden when it will actually help you, it's naive (I have met people saying they don't think XDoclet will help their development because they will lose time learning it... I mean, really!)

    I am using MagicDraw 7.x with AndroMDA 3.x, I generate EJBs, Hibernate POJOs and Struts sources, and reduce the amount of hand-written code to a minimum... I love it.

    just my 2cents
    Wouter.
  15. Martin Fowler speaks out on MDA[ Go to top ]

    I think you're talking about UML from code generation perspective but IMHO it's another story-writing good "code generator" is art by itself so not mix in UML here.
    I'm not right?
  16. 50% is better than nothing[ Go to top ]

    Right on Drew!

    Martin and I have spoken about this months ago. He warned me he was going to get even more negative about MDA over time, and he has. He admitted that he just doesn't have time to get around to trying out some of the MDA tools/concepts.

    I also spent a day with Scott Ambler last Fall. Scott is similarly disposed towards MDA. Wait til you see his latest in SD magazine. Scott feels that "MDA is doomed." Of course, I told him he was being silly and it was a ludicrous thing to say.

    Their main "problem," IMHO, is they are reading the OMG MDA website too literally. Of course modeling behavior is difficult in UML. Of course we can't fully specify a real application with only UML. Only a fool would believe that. However, who would deny that it is a good gravitational pull to attempt to move our sad industry to a better state of improved performance.

    But, MDA *can* bring value to some percentage of an application with a tool like OptimalJ or even a lightweight MDA tool like AndroMDA. OptimalJ is a powerful vision of an MDA tool -- and it preserves your code changes during iterative development of the business model or even the framework "translation rules."

    The development paradigm will shift to being more model-driven. Those comfortable in the old "sling code" paradigm will naturally be less apt to let the shift happen without some grousing. Many will likely be outsourced, or replaced.

    This all deja vu for me... <waxing nostalgic> I was "out on a limb" when I shifted to OO back in the late 80s/early 90s. The IT folks in the Software Group at the DOD consulting company where I worked, could only throw insults my way and make snide remarks about how slow C++ was (I headed up the Aerospace Group, we did lots of real-time stuff). By the time I left that company in 1995 to form my own company (winning a major contract to build a C++ MES app for IBM computer factories, no less), the top folks in the Software Group finally recognized my "vision" in moving to OO when I did. </waxing nostalgic>

    While folks like Martin and Scott (whom I respect deeply) rant and rave, others will quietly go about and just make MDA work.

    There are no points for grunt work. Those that recognize strategic value of MDA will axcel in the marketplace. Others will...
  17. Something very strange[ Go to top ]

    Something very strange is happening here on TSS - I totally expected lots of uninformed remarks on how MDA is not suitable for real world scenarios, and instead I find thoughtful comments by people who actually 'get it'. I totally agree that MDA is no silver bullet (nothing is). I also agree that both UML, XMI, and the OMG itself have their significant share of problems. Dismissing the approach because of that, though, means missing an excellent opportunity to focus on the important stuff instead of the monkey work.

    Stefan Tilkov
    http://www.innoq.com/blog/st
    http://www.innoq.com/iqgen
  18. Martin Fowler speaks out on MDA[ Go to top ]

    Completely agree with Martin more powerful programming languages/"abstraction concepts" became less useful application for MDA/UML tools I see.
    Look at Xen/X# initiative, why I ever need something more? Only for references purposes maybe...
  19. Martin Fowler speaks out on MDA[ Go to top ]

    I've posted some more thoughts here: http://www.innoq.com/blog/st/archives/000574.html

    Stefan
  20. Martin Fowler speaks out on MDA[ Go to top ]

    <Stefan>
     Instead of spreading knowledge about design patterns, programming language idioms and platform details across a multitude of different artifacts, where they are mixed with domain/business knowledge, this technical knowledge is localized in code generation rules.
    </Stefan>
    Microsoft respond(sort of):
    framework implies implementation of programming design patterns, programming
    language- expression those patterns' idioms,so we constantly expand language to include basic programming domain's idioms(XML+SQL+OO+...=Xen).
    Nice, isn't it?
  21. Martin Fowler speaks out on MDA[ Go to top ]

    My point is: Why would I care from a domain perspective?
    Lots of valuable knowledge about business data and processes is buried in COBOL code and thus not easily accessible. Why would we want to make the same mistake again?
    I don't really care that much about UML or any other standard - as long as I can be sure that I can get at the information 10 years from now. That's something that XMI (or XML, for that matter) gives me.
  22. Martin Fowler speaks out on MDA[ Go to top ]

    Because: you can think only about things lunguage allow...
    Anyway,you blog entry propose very interesting position ;-)
  23. there's a backend too[ Go to top ]

    I think martin may be missing that part of MDA
    is a backend code generator that is very different
    than case tools which tried to do it all.

    You can use off the shelf backends if you wish,
    but you can also write your own backend to map
    to your own application framework. A lot of the
    problems of MDA go away when you realize you
    are not locked in and that part of your job is
    to write the code that writes the code. Much like
    we do for state machine decriptions, message descriptions,
    database descriptions, etc.
  24. Bottom up code generation[ Go to top ]

    Rose, TogetherJ, and OptimalJ are top down approaches to code generation that are synonymous with MDA and I don't like them. But these products aren't the only way to get something out of UML and code generation. Tools that are less ambitious than MDA seem more practical.

    Hibernate's SchemaExport tool takes the O/R mapping file and generates database schemas for your database of choice. Their CodeGenerator tool takes the O/R mapping file and generates domain model skeletons. These are simple time saving tools. It's a logical next step to generate the mapping file from UML.

    AndroMDA does something like this with UML -> Xdoclet -> Java source -> mapping file. I've only dabbled with AndroMDA but I assume this is a more expedient approach than creating the transforms for UML -> XML Metadata Interchange -> mapping file. I'd like to hear what people think of the XML Metadata Interchange approach.

    Once we're creating domain objects from UML a chain of code generators could follow. Generate an IOC configuration file to wire up domain objects for example. In fact using UML to generate configuration files seems more practical than trying to use it for behavior.

    If XML Metadata Interchange doesn't take long to figure out I'll give this a shot and if open source developers want to do some XSL a UML front end would be nice to have.

    Gary
  25. Bottom up code generation[ Go to top ]

    "If XML Metadata Interchange doesn't take long to figure out I'll give this a shot and if open source developers want to do some XSL a UML front end would be nice to have."

    I agree but I would like to navigate UML models (just the core diagrams + stereotypes, off course) with something like http://qdox.codehaus.org + Velocity templates to parser XMI files. It would be very easy and fast way to customize/change the code generation.

    "Once we're creating domain objects from UML a chain of code generators could follow. Generate an IOC configuration file to wire up domain objects for example. In fact using UML to generate configuration files seems more practical than trying to use it for behavior."

    AndroMDA and JAG, for example, generates Struts + EJB (JAG uses XDoclets tags) artifacts. It´s great and anybody who want could extend it. For myself, if I have a decision role in the project I would prefer to work with Spring, for example.
  26. Putting the programmer in control[ Go to top ]

    Putting the programmer in control is, IMO, essential - that's why I view the ability to change the way stuff is generated as essential for any code generation tool to be useful. With our own tool, iQgen, we take the approach to provide only an engine - the templates can be (and need to be) written according to the specific project's requirements.
  27. Putting the programmer in control[ Go to top ]

    Agreed. There are a number of MDA tools that claim to do everything for you but that's a ridiculous claim. If you're going to use it effectively, you have to have control over the templates. And you have to be able to effectively deal with the fact that the generation isn't going to solve everything. It's only going to take care of the easy stuff. If I recall, innoq actually has some sort of tag that allows certain portions of code to be preserved across generations. I'm not sure how effective it is when the template changes wildly, but it's definitely the kind of thing that is needed (disclaimer: i tried innoq and was generally pleased but I much prefer velocity templating for code than the more verbose jsp used in innoq).
  28. Putting the programmer in control[ Go to top ]

    There are a number of MDA tools that claim to do everything for you but that's a ridiculous claim.

    Can you cite a vednor's false advertising, or are you just gassing?
  29. Putting the programmer in control[ Go to top ]

    Well, any vendor who claims that UML is fully executable without use of a real programming language (that standardized rule language, "O-something or other", doesn't count; it's halfway between user-readable and expressive, failing at both) is making a false claim. I think there's a limit to what can be expressed visually in UML, and if you try to get past that, you end up marking up your UML with all kinds of things that make the UML itself harder to maintain than simple source code. Executable UML is pie-in-the-sky, just like do-it-all CASE tools. MDA and a lot of what it brings to the table is extremely valuable, so I'd hate to see its real worth get trampled over by people invalidating false vendor claims.
  30. Putting the programmer in control[ Go to top ]

    Well, any vendor who claims that UML is fully executable without use of a real programming language (that standardized rule language, "O-something or other", doesn't count; it's halfway between user-readable and expressive, failing at both) is making a false claim.

    Unless you can cite a vendor, I can only consider you another passive-aggressive gasser, like Rickard and Martin.
  31. executable UML[ Go to top ]

    Executable UML is pie-in-the-sky, just like do-it-all CASE tools.


    How much of UML should be executable? Class diagrams certainly are, as TogetherJ shows. Sequence and collaboration diagrams, being instance-based, and indeed object diagrams (e.g. catalysis snapshots) cannot be though. State diagrams are type-based and can be used to represent behavior (but would seem to work best for real-time stuff, as an earlier respondee mentioned about their Shlaer Mellor work).

    Vendors like Kennedy Carter who claim to do Executable UML notably use only type-based diagrams (class, state) and ignore instance-based diagrams.
  32. executable UML[ Go to top ]

    Vendors like Kennedy Carter who claim to do Executable UML notably use only type-based diagrams (class, state) and ignore instance-based diagrams.

    That seems enough to author a web service singleton.
  33. executable UML[ Go to top ]

    How much of UML should be executable? Class diagrams certainly are, as TogetherJ shows. Sequence and collaboration diagrams, being instance-based, and indeed object diagrams (e.g. catalysis snapshots) cannot be though.


    FWIW: TCC is not executable in the sense of being able to "run" a class diagram and see a UI. A class diagram is just a visual representation of a class. It does not execute. But maybe I misinterpret your meaning?

    Now, if you mean it represents code? Yes. So does Sequence diagrams. State diagrams aren't far behind in this regard either. (Associate a state diagram to a class. States can be constants. State transitions can be methods.)
  34. executable UML[ Go to top ]

    How much of UML should be executable? Class diagrams certainly are, as TogetherJ shows. Sequence and collaboration diagrams, being instance-based, and indeed object diagrams (e.g. catalysis snapshots) cannot be though.

    >
    > FWIW: TCC is not executable in the sense of being able to "run" a class diagram and see a UI. A class diagram is just a visual representation of a class. It does not execute. But maybe I misinterpret your meaning?
    >
    > Now, if you mean it represents code? Yes. So does Sequence diagrams. State diagrams aren't far behind in this regard either. (Associate a state diagram to a class. States can be constants. State transitions can be methods.)

    State diagrams are more complete than sequence diagrams:
      - sequence diagrams illustrate a *single* execution sequence (unless you make them so complex that it is easier to read the code :) whereas
      - state diagrams define *all* possible execution sequences (unless deliberately subsetted)
    In both cases it is highly beneficial to have a "conventional language" encoding the processing in that takes place in the actions. That language can, for example, be Java, C, VHDL, Verilog, or (one of) MDA's Action Semantics Language.
  35. Putting the programmer in control[ Go to top ]

    <Drew>
    If I recall, innoq actually has some sort of tag that allows certain portions of code to be preserved across generations.
    </Drew>
    Yes; you can mark areas in your templates as "protected areas", and the generated code will contain comment markers. You can then write code between those markers, and this code will be merged when you re-generate. (BTW, innoQ is the company; the product is called iQgen.)
    <Drew>
    I'm not sure how effective it is when the template changes wildly, but it's definitely the kind of thing that is needed
    </Drew>
    It works to a certain degree. You need to use something like the model element's id to make sure your generation step survives things like changing method names and signatures. But there's definitely a limit; when you have really big changes, you sometimes need to do it via some script or manually.
    <Drew>
    (disclaimer: i tried innoq and was generally pleased but I much prefer velocity templating for code than the more verbose jsp used in innoq).
    </Drew>
    Perfectly valid; while you can use taglibs or call out to Java helper classes, this is mostly a matter of taste.

    Stefan Tilkov
    http://www.innoq.com/blog/st
    http://www.innoq.com/iqgen
  36. Bottom up code generation[ Go to top ]

    My experience with XMI in MDA: don't use it. It's a nightmarishly verbose standard, designed more for compatibility and standards than for actual ease of use. I personally think XSL is also a nightmare, and should be saved for occasions where it and only it is appropriate.

    AndroMDA, like many other approaches, pulls the XMI into an object model representing the logical structure of your code. This is what your templates manipulate, making for some (relatively) easy-to-understand templates. The alternative, with XSL, is just a complete nightmare. Basic things like iterating through attributes or associations to output variable declarations in a POJO class become far more complicated than they need to be if you're using XSL. With, for example, AndroMDA's velocity templates, it's a simple iteration:

    #foreach ($sttr in $class.attributes)
      private ${attr.type.name} ${attr.name};
    #end

    I think that the MDA standard, whatever that is, has some sort of recommendation that the UML be represented as an intermediary object model. I think they even have a fancy acronym for it, PIM (platform independent model). That approach makes a lot more sense to me than getting all caught up in circa-2000 "XML! XML! XML and XSL can do everything!" hype.
  37. Bottom up code generation[ Go to top ]

    Rose, TogetherJ, and OptimalJ are top down approaches to code generation that

    >> are synonymous with MDA and I don't like them.

    You're wrong to lump Together in with Rose. They require completely different mindsets, as I discuss in my book. In many ways Together is the antithesis of MDA, but Borland understandably are going to use MDA marketing nomenclature because they need to sell their product against the market leader.
  38. Bottom up code generation[ Go to top ]

    AFAIK, Rose does not even claim to be MDA, Together very clearly is not (Dan's antithesis statement is 100% true), and OptimalJ is, to put it mildly, not representative of the MDA tool market.
  39. Bottom up code generation[ Go to top ]

    Rose, TogetherJ, and OptimalJ are top down approaches

    > to code generation that are synonymous with MDA
    > and I don't like them.

    I disagree 2x... Rose (better, XDE) and TCC are *not* MDA tools no matter how much dope you smoke. Also, these tools do operate with importing information as a starting point -- they are not always top-down.

    Of the two, Together is the only viable tool to be addressed in this forum. Together (I used it since 1994) was great in that it was a visual manipulation layer for the code. If I changed a class, or an association, that one (maybe 2) file changed. I repeat: a tool for abstracting a java file into a visual rectangle and keeping them in sync. Nothing more. Nothing less. Basically one-to-one between code and diagram symbol.

    If I am modeling an entity (class) in OptimalJ, I am up a few layers of abstraction from a simple java or hpp file (as in TCC). Because the transformations in OptimalJ dictate what happens when I indicate that an attribute in a class is "mandatory," the MDA tool will generate the necessary code. Or, because I have a many-to-many association in the Domain Model, I will be sure to get 3 tables from the transformation logic in use. In addition, the MDA transformations go all the way to generating a JSP with error messages to enforce the mandatory setting on the attribute. Rose or TCC pale in comparison to a true MDA tool. (And I spent from 99-2002 making TCC a household name.)

    An MDA tool is probably an order-of-magnitude more powerful than a simple UML modeling tool.
  40. Just some comments on MDA[ Go to top ]

    The Shlaer Mellor model, IMHO was the first attempt at MDA and speaking as somebody who used to work in the architecture team for a very large Shlaer Mellor project in the mid 90s, building the engine which compiled the model into working code, it doesn't really work. Sure it's useful and helps the analyst create working models but all the real complexity and nuances for building and architecting systems just gets pushed into the code generator which can never realy build optimised code for different classes of application.

    Also MDA will require something equivalent to the old "Action Language" created by Shlaer Mellor to describe the business rules and algorithms required for the application functionality. This Action Language tends to evolve into just another programming language just slightly more abstract than Java or C++ etc.

    The real benefits of MDA really come when modelling very tightly constrained systems of interacting state machines like Real Time systems. I have yet to see how we could build complext n-tier architecture applications using MDA approaches and as someone pointed out in an earlier post GUIs used to really screw up the Schlaer Mellor models.
  41. Just some comments on MDA[ Go to top ]

    Also MDA will require something equivalent to the old

    >"Action Language" created by Shlaer Mellor to describe
    >the business rules and algorithms required for the
    >application functionality.

    Yes. Its called the "Action Semantics Language". Note that it is specifically "semantics", not "syntax", which I think is preferable.

    > This Action Language tends to evolve into just another
    > programming language just slightly more abstract than Java
    > or C++ etc.

    I'd say "simpler" rather than "more abstract". Think of it (loosley) as a scripting language dealing with classes/objects specified in UML class diagrams, and events/actions specified in the UML Statechart/FSM diagrams.

    > The real benefits of MDA really come when modelling very
    > tightly constrained systems of interacting state machines
    > like Real Time systems.

    Definitely. I've seen some people claim that it is *the* completely generic future of programming, but they're wrong of course. I'd *love* to see someone use MDA try to code up something that is better expressed in terms of forward-chaining production rules or backward-chaining constraint satisfaction, or even a regular expression pattern matcher.


    >I have yet to see how we could build
    > complext n-tier architecture applications using MDA approaches

    The PIM doesn't address that, of course. Nothing in MDA's PSM and the mapping from PIM to PSM prevents implementation in n-tier architectures. It is perfectly reasonable to use an MDA PIM to define a web-service that executes in an n-tier application server.
  42. Another sycophant?[ Go to top ]

    The old school tone of the entry in Martin's blog made me suspicious enough to verify that in the blog entry he makes no claim of having tried MDA. I don't doubt that he's criticizing something he has no experience with. Another sycophant like Rickard?
  43. You are right[ Go to top ]

    The old school tone of the entry in Martin's blog made me suspicious enough to verify that in the blog entry he makes no claim of having tried MDA. I don't doubt that he's criticizing something he has no experience with. Another sycophant like Rickard?


    You are exactly right....he has never used MDA on a project let alone sat down and evaluated a tool.
  44. Hidden Bias[ Go to top ]

    Could there be a hidden bias in Martin's crticism of MDA as it does not seem to fit well with the 100% code centric paradigm of Extreme Programming?
  45. Hidden Bias[ Go to top ]

    Could there be a hidden bias in Martin's crticism of MDA as it does not seem to fit well with the 100% code centric paradigm of Extreme Programming?

    Code generation meshes well with XP, so that couldn't be his bias. Martin and Rickard are biased against MDA. I suppose their bias is political and not technical. MDA promises to commodify architectural best practices. MDA won't displace developers, but architects might not fair as well. Demand for architects could decrease, and so a architecture guru's audience would shrink. An architecture guru would have no more celebrity than a compiler guru.
  46. Hidden Bias[ Go to top ]

    Demand for architects could decrease, and so a architecture guru's audience would shrink. An architecture guru would have no more celebrity than a compiler guru.
    I am in violent disagreement with this. MDA makes an architect's life easier, but it doesn't mean that there's a single best architecture (or even a limited set) for every project. This is like saying 3GL languages decreased demand for programmers - it didn't, because it allowed people to solve problems more easily.
  47. MDA makes an architect's life easier...

    We don't hear Martin saying that, and he's the architectural genius. I hope that MDA eliminates much architectural analysis, so that I can spend more time on application development.
  48. We don't hear Martin saying that, and he's the architectural genius.
    Then again, he seems to never have tried it out ...
  49. Hidden Bias[ Go to top ]

    Demand for architects could decrease, and so a architecture guru's audience would shrink. An architecture guru would have no more celebrity than a compiler guru.

    I am in violent disagreement with this. MDA makes an architect's life easier, but it doesn't mean that there's a single best architecture (or even a limited set) for every project. This is like saying 3GL languages decreased demand for programmers - it didn't, because it allowed people to solve problems more easily.
    ------------------------------------------------
    I completely agree....My experience with MDA allows architect to focus on standards to streamline the application development and deliver business solutions faster than the traditional hand-to-hand combat.

    In 1960, COBOL was hailed as the savior to drive out the need for developers....wrong.

    In 1990, I sat on a board with a group of CEOs/CTOs/CIOs that made a public annoucement that C++ and object-oriented paradigms were going to reduce their needs for developers in the corporate world.....wrong.

    Now...MDA will not reduce the need for architects and developers. It compress the development lifecycle and get developers to focus on the business solution, which they can model...or generate by hand. You choose. MDA is about delivering projects quicker and faster. The byproduct of that will be companies will need MDA Practitioners and Object Modelers to speed the development process. If anything...these people will command the highest value because they understand the business and the techology to solve/captialize on opportunities faster than their competitors.
  50. Higher level, higher requirements[ Go to top ]

    <quote>
    Now...MDA will not reduce the need for architects and developers. It compress the development lifecycle and get developers to focus on the business solution, which they can model...or generate by hand. You choose. MDA is about delivering projects quicker and faster.
    </quote>

    yup, this is typical in computer science:
    We are going higher in our abstraction level, but the requirements are also getting higher!

    - With Assembler nobody needs to have GUI. Simple text-based.
    - With OO we all needed sophisticated GUI, reusable GUI.
    - With Aspects (like EJB) we all needed more sophisticated transactions management, security, reusable business components, etc.
    - With MDA we will have higher requirements like faster time to market.

    So, learning from history, we'll get better instruments for handling programming but at the same time the requirements are also getting higher!

    Cheers,
    Lofi.
    http://www.openuss.org
  51. Higher level, higher requirements[ Go to top ]

    So, learning from history, we'll get better instruments for handling programming but at the same time the requirements are also getting higher!

    No doubt MDA is a way to cope with that customer demand. I totally wanna cope.
  52. Higher level, higher requirements[ Go to top ]

    So, learning from history, we'll get better instruments for handling programming but at the same time the requirements are also getting higher!

    >
    > No doubt MDA is a way to cope with that customer demand. I totally wanna cope.

    Cope? I'm hoping to continue to exist (in this industry). Then definitely cope.
  53. Higher level, higher requirements[ Go to top ]

    Brian:

    All corporate companies are trying to cope....

    When you look at strategic pressures this is what you are dealing with:

    CEO Problems:
    1. Culture of the company
    2. Fall back to old ways of doing things when times get tough
    3. Strategic pressures from the board
    4. Fear of Technology
    5. Credibility with Techies - Rightful so....
    6. Communication with balancing of strategic plan with tactical execution
    7. Budget

    CIO Problems:
    1. Backlog of Development - Too many things to do
    2. Limited Budget - IT budgets cut by 50% - That's our life
    3. Cutbacks - same as above
    4. Legacy Staff - What do you do with people who have the business logic...
    5. Staff Politics - People who say MDA won't work
    6. Culture - same as above...This is usually the problem
    7. Credibility - That says it all...usually a big stumbling block.

    Once you understand with what these people are trying to 'cope' with and how MDA can compress the development time from design modeling to actual source code...then you can start with justification of MDA.
  54. Higher level, higher requirements[ Go to top ]

    Brian: ... Once you understand with what these people are trying to 'cope' with and how MDA can compress the development time from design modeling to actual source code -- then you can start with justification of MDA.

    I've been stumping on TheServerSide for MDA since July 2002. Back then TheServerSide staff were ambivalent; Floyd was skeptical. As for your remark about MDA as an alternative to outsourcing, well, I first raised that here in July 2003. You're preaching to the faithful.
  55. Lofi...

    You are correct in the assessment that a higher level of abstraction is needed to cope with different architectures within an organization. The worst is when you have to do a system consolidation...like when one company buys out another company. Its been my experience developers and architects have a distrust of anything source code generated. I for one sure did. I remember I had Java architects pouring over the code that was generated from a tool. If something was missing, we just added the code at the PSM level and regen the PIM. When I had the development team coming up with little reasons why this would not work, I knew I was onto something...this was back in early 2000.

    If believe that history can help one guide you through the future...I remember back in 94 & 95 when so called industry experts told the IT community the 'web was only a fad'. Now 8 years later, look at the market.

    Corporate change is hard, companies do not change unless they have a gun to their heads. After hours of research, I was trying to find one articule that addresses alternatives to outsourcing. All these experts say outsourcing is iffy at best...but no one has a solution. I don't believe MDA is the total solution, but as an executive manager, with blood-around my feet with traditonal development, this is worthwhile for a company to look at...too many business reasons to look at from the C-level.
  56. Code generation and MDA[ Go to top ]

    What is the difference between "mere" code generation and "MDA"?
    Discussions in this thread show many people find code generation useful.
    I do not think Martin is questionning "code generation" in general.
    <Martin>
     I'd rather draw up a database schema with a graphical schema designer than typing SQL into TextPad.
    </Martin>

    I am not a heavy user of any code generation tools. But, IMHO, most of
    the successful code generation tools focus on the "static" aspects of the
    system. Generating entity classes (entity beans, POJOs , or whatever) falls
    into this category.
    On the other hand, it seems to be difficult to generate code for the dynamic system behaviors, which are typically described with the sequence diagrams.
    MDA may be different from the "mere" code generation in that they also target such difficult areas.

    I think Martin's point is not whether MDA is good or bad as a whole, but whether it is appropriate to apply code generation to such bahavioral aspects of the system, espesially by enhancing UML diagrams to be more "computationally complete".
    I share the same concern with him. I believe the success of a code generation tool depends on its ability to convert a "declarative" specification to a fragment of excutable code.
    From this point of view, UML diagrams representing complicated logic(sequence diagrams or activity diagrams) are not "declarative " but rather procedural.
    Their strength exist not in specifying the requirement in a declative manner but in presenting high-level view of the overall process flow and collaboration
    of the involved objects. So I do not deem them as good input information for
    code generation.
    I would like to here the opinions of those with more experience in code generation.

    Kei
  57. Code generation and MDA[ Go to top ]

    hello Kei,

    you make some good points, but I would like to know what you think is missing in modeling behavoiral elements. I agree it's far from complete or perfect, but in general it gets the job done in a clean way: in an activity graph you may put different types of states, on transitions you may put triggers, guards, events, etc. so you have a wide range of possiblities to model applications in a consistent manner.

    I have not tried yet to model a complete Swing application like this, only web front-ends, so I should maybe try that first. Nevertheless, I already see room for improvement, mainly in the area of linking static uml classes to dynamic model elements such as action states (although MagicDraw allows it) and defining more strict modeling rules (as you probably know, everybody hs a different idea on how something should be modeled).

    best regards
    Wouter.
  58. Code generation and MDA[ Go to top ]

    you make some good points, but I would like to know what you think is missing in modeling behavoiral elements.

    UML still lacks fine-grained process modeling, without which it's impossible to specify algorithms. Eventually UML action semantics will fill that void, but that's still a couple years away from public release.
  59. Code generation and MDA[ Go to top ]

    The expected granularity of algorithm modeling is
    interesting.

    I would expect for someone to say something like "Find(X)"
    and have the logic for find plugged in from an existing package
    or generated by the programmers writing the translation.
    I would not expect someone to "write" a quick
    sort in UML to perform the find command.
  60. Code generation and MDA[ Go to top ]

    The "benefits" of diagramming behavior (reusability across platforms (a dubious need for most apps), ease of change, etc.) have to far outweigh the cost of simply coding it. Current technologies and behavioral languages have a ways to go yet, most likely.
  61. Code generation and MDA[ Go to top ]

    Jon, thank you for your comment. I do not question the effort to create platform-independent languages. It should be much valuable when achieved. But if it is the goal of the MDA, why can’t we just create ordinary “language” instead of using UML diagrams?

    <Wouter>
    you make some good points, but I would like to know what you think is missing in modeling behavoiral elements. I agree it's far from complete or perfect, but in general it gets the job done in a clean way: in an activity graph you may put different types of states, on transitions you may put triggers, guards, events, etc. so you have a wide range of possiblities to model applications in a consistent manner.
    </Wouter>

     Wouter, I agree that these diagrams are useful in many contexts. But I cannot imagine specifying every aspect of a system (as we do with programming languages) with them.
    Activity diagrams are much process-oriented. IMO, they are actually the evolved version of the flow charts. As such, they have weak connections with “objects” (in the OOP sense). Sequence diagrams are instance-based. If an invocation of use-case involved hundreds of the object instances (which I think is very common), it is not possible to write a “complete” sequence diagrams. When we write sequence diagrams, we only include the objects we consider most important for communication purpose, at the expense of the correctness.
    Actually, I think beauty of these diagrams exists in communicating the most important things clearly by abstracting the details. If you add more and more details to them, their clarity should decline.
  62. Martin Fowler speaks out on MDA[ Go to top ]

    There is an overall disconnect of the history of what Fowler is saying, or should I say is attempting to say.

    The problem with CASE Tools in the late 80's early 90's timeframe was that the vendors...Knowledgeware, Oracle, etc....bound the developers, designers to the architecture, usually two tier. 99% of the time, the CASE Tool bound the users to the architecture, that was dicated by the software vendor. Well I remember I spent so much time on the phone with vendors to get the vendor to change the pattern of the source code generation. Since the architecture is always changing in a corporation, the CASE Tools was powerless to adapt to the changing technology landscape of the company. That is the primary reason why CASE Tools failed. Presently, MDA abstracts and decouples the architecture and business logic. Meaning if I wanted to generate a J2EE application I can from the PIM, but if I wanted to take that same business model to .Net, I then would change the PSM, then generate to new target architecture. If I did not like the J2EE generated code, then I would change the PSM, then regenerate. I did this for a software vendor client, and MDA reduced their overall system maintenance by 80%, while reducing the development time almost 70%.

    Some of the postings are concerned with overall diagrams in a UML model being hard to read. I can say from experience, that it is better to read a class activity diagram, then to read 50K line of J2EE code and try to read the minds of programmers what they were original trying to accomplish.

    Overall, I have lead 5 MDA Projects some small, most large scale(which by the way, MDA works very well), although most of the tools do the same thing, the biggest benefits are the collateral activities:
      - Visual representation of the application business logic flow. This is
        important to get sign off with operations.
      - Generation of documentation for the system.
      - Reduce system maintenance by 80%
      - Reduce application development effort by 50%.
      - Having the business logic actually = the design: priceless...Users then
        approve designs models.

    On another note, its interesting with developers and architects when they go through application development, what they preceive as important factors for application development. Usually its around JSPs, EJB, entity beans, the list goes on. What MDA really gets you thinking about is the business logic or domian. Which I think is what you should be worried about for the company(client). Its true that these tools do not generate all the code, what they do give you is the piping that you have to usually maintain by hand. For exmaple, ask yourself, the next time there is a new release of Java, going into the code and changing it by hand, on a fairly large system can be a nightmare, is there a better way... There is no business value assocaited with maintaining the system by hand. In MDA, the architectural changes in the pattern within the PSM, then generate the code. We looked over the completeness of the code, and we were encouraged by the output. Of course you have to do the due dilgence of testing, but a change that would take 4 or 5 days to make, we could do in 6 or 7 hours on a project. This is also applies to adding field on screens, changes to the database, incorporating new technologies etc.... This point is compressing the time for new adaptions and integration points of new technologies which is what MDA is suited for by design.

    I can say with reasonable experience, it takes a project or two to truly understand the value of appreciation of MDA. I was on the guarded side, wanting to see results. I was surprised how things worked out. As far as making a statement about MDA. I look at it this way....you still have to design. If you are going to design you might as well get some workable source code from it.
  63. MDA Resources[ Go to top ]

    By the way you might want to take a look at the following links to help with a deeper understand of MDA, you can never have enough knowledge.

    http://www.omg.org/mda/
    http://www.omg.org/mda/mda_files/11-03_Sewall_MDA_paper.pdf
  64. Martin Fowler speaks out on MDA[ Go to top ]

    Stan,
      If you don't mind, can and haven't already, could you describe the toolset you are using to accomplish your MDA development?

    Thanks.
  65. Toolset[ Go to top ]

    Mark:

    Sure...Best to email me at stan dot sewall at juno dot com. A doctor would never a prescription without knowing the symptoms.
  66. Stan,

    You make much in your post and your OMG article of the advantages of having users sign off on the UML design.

    I find that even seasoned BAs can have trouble with UML. Important distinctions, such as between aggregation and composition, or just quite what realization means, can be very hard to get your head around.

    I was going to ask you to elucidate as to how you managed to get business users to understand your UML well enough to sign off on it. But instead I'll be blunt. If you're using UML as a true spec language to generate code then you need to be writing precise, tight UML (UML as a programming language). If you're doing that then I cannot believe that non-technical people will really be able to understand whether or not your UML is correct.

    Sean
  67. Business User != UML Designers[ Go to top ]

    Sean:

    Sorry to lead you down the path with this thought...I should clarify. I have and never will be a big supporter of tools that are marketed to companies, that BAs or Subject Matter Experts 'just model the business' and push the button and the system is magically built. Believe you me, there are a lot of tools out there that say they can do this. The best development model is to have the SMEs detail the screens, and verify with the operational units the skelton HTML data fields are correct. Not very hard by the way, and users will tell you what fields need to be incorporated and what fields not. Then it gets down to the business logic, or operations of the screen in the PIM. I have found that creating an inventory functional list from the user, then start in on the modeling with the business flow and the operations in the PIM. Once you have that completed, loop back with the SMEs/BAs and walk through the application. Then you describe the actions (behavior) of the model. The user sees the generated HTML with links, then a description of the behavior. The users signs off on that, then they can use that same inventory list to sign off for quality control testing. If you have another way I would be interested to know. I am always refining the approach on a project by project basis. Sorry for the misudestanding.
  68. Platform Independent Design[ Go to top ]

    Stan,

    Piping code is trivial, annoying, and if you automate generation of it for very little work that's great. But it occupies very little of my time, because it's trivial... and testers rarely spend much time on it because it's *easy*. It's also something that a wide variety of tools which are much lighter-weight than MDA address.

    In enterprise apps it's the subtle business logic where the subtle bugs that eat up all the testing and maintenance time occur - and that's exactly the code which MDA does not generate. Which is why I flatly disbelieve your cost claims are true for enterprise systems ("80% reduction in system maintenance" !!!).

    <quote>
    > Its true that these tools do not generate all the code, what they do give you is the piping that you have to usually maintain by hand. For exmaple, ask yourself, the next time there is a new release of Java, going into the code and changing it by hand, on a fairly large system can be a nightmare, is there a better way... There is no business value assocaited with maintaining the system by hand.
    </quote>

    Stan, I think that's gibberish. Because we don't go in and change our big enterprise systems just because there's "a new release of Java". Why would we?

    People do sometimes go in and change things because of new versions of J2EE: they change areas of their design to take advantage of new technology. But they're not just changing "piping" code when they do that. Still, you say that MDA is good for "compressing the time for new adaptions and integration points of new technologies". So you acknowledge that people will re-design if they're given different technological options.
     
    But...
    You also say that you get platform independence with MDA (push one button and it generates J2EE code! push another and it generates .Net!). That platform independce claim conflicts with the notion that technology is a driver for design - either you're considering what J2EE technology provides in doing your design, and designing with that in mind, or you aren't.
     
    Now don't try to paint me as someone saying that technology is more important than business needs in doing design - I'm not someone who makes that particular mistake. But both business needs and technology drive design, which is why "platform independent design" is something I'm so wary of.


    Sean
  69. Platform Independent Design[ Go to top ]

    You also say that you get platform independence with MDA (push one button and it generates J2EE code! push another and it generates .Net!). ... But both business needs and technology drive design, which is why "platform independent design" is something I'm so wary of.

    I suppose you either don't know of or don't believe in Project Ace, which Sun describes as:

    "Ace has been very carefully designed to be architecture-independent. That means developers can use Ace to regenerate the application's code for new architecture and technology choices, just like a conventional compiler can generate code for different processors. For example, a developer could create an application initially for use in a 2-tier architecture and, as the volume of usage increases, simply regenerate it later for use in the more powerful 3-tier."
  70. Platform Independent Design[ Go to top ]

    Sean:

    Piping is not trival....in enterprise applications in order to make a changes to the application, is often a large feat, even for a simple change. Adding a field to the screen:
    1). Change database table ( often multiple tables)
    2). Change the DAO
    3). Change the Query statement
    etc....etc....etc...the list goes on.

    On mature systems in the web architectures (if they exist), subtle changes to the business logic in the method, can cause casacading changes to a system that can go on forever trying to find the cause. On large enterprise wide systems, more than 80 web pages, excluding help pages of course, I have found that changes that would take a developer to make in week, could now be done with MDA in 6 to 7 hours. The developer focuses on the business logic only, not the cutting and pasting of code for the piping. Now if you compound multiple changes between releases and having to keep the 'piping' glued together, becomes a different story with multiple programmers working on different sections of the system. Which compounds the complexity of system maintenance, which is want you find in large system with large development teams.
     
    <Sean quote>
    <quote>
    > Its true that these tools do not generate all the code, what they do give you is the piping that you have to usually maintain by hand. For exmaple, ask yourself, the next time there is a new release of Java, going into the code and changing it by hand, on a fairly large system can be a nightmare, is there a better way... There is no business value assocaited with maintaining the system by hand.
    </quote>

    Stan, I think that's gibberish. Because we don't go in and change our big enterprise systems just because there's "a new release of Java". Why would we?
    <Sean quote>

    What if a new Java Feature is released and it demanded an upgrade to use the feature. Maybe a better example, being a senior developer and you want to enforce certain functionality on the team. You would enforce it at the PSM level. Give the 'enforced' PSM to the development team, and have then work on the PIM, with your rules for the architecture. I actually like this on projects.

    <Sean quote>
    You also say that you get platform independence with MDA (push one button and it generates J2EE code! push another and it generates .Net!). That platform independce claim conflicts with the notion that technology is a driver for design - either you're considering what J2EE technology provides in doing your design, and designing with that in mind, or you aren't.
    <Sean quote>

    Actually, I think that the platform claim underscores the importance of the business logic. The Driver is the design to solve the business problem.

    <Sean quote>
    Now don't try to paint me as someone saying that technology is more important than business needs in doing design - I'm not someone who makes that particular mistake. But both business needs and technology drive design, which is why "platform independent design" is something I'm so wary of.
    <Sean quote>

    In my experience with MDA, the term "Platform Independent Design" goes back to my first paragraph in the earlier response. Most people think of CASE tools, which locked you into the architecture. As a developer this drove me up the wall. Too many ours on the phone with Oracle CASE Team late 80's. When I studied MDA, I found I had control of source code at a system level, and if I don't like it, I did change it at the PSM level...that to me is platform independence. Going from .Net to J2EE in the real world happens very seldomly, but I have been on projects, in midstram where that has occured because of change of management.

    Enjoyed the response.
  71. Platform Independent Design[ Go to top ]

    When I studied MDA, I found I had control of source code at a system level, and if I don't like it, I did change it at the PSM level...that to me is platform independence. Going from .Net to J2EE in the real world happens very seldomly, but I have been on projects, in midstram where that has occured because of change of management.


    Which tools were you using?
  72. Platform Independent Design[ Go to top ]

    When I studied MDA, I found I had control of source code at a system level, and if I don't like it, I did change it at the PSM level...that to me is platform independence. Going from .Net to J2EE in the real world happens very seldomly, but I have been on projects, in midstream where that has occured because of change of a management.


    >Which tools were you using?

    Sure....drop me an email at stan dot sewall at juno dot com.
  73. Platform Independent Design[ Go to top ]

    Going from .Net to J2EE in the real world happens very seldomly, but I have >been on projects, in midstram where that has occured because of change of >management.


    More than likely because they couldn't (cost too much or didn't know how). The same goes for database vendor changes. Applications are written in such a way that it is expensive to do. So when I suggest using Hibernate/JDO/... I get the "Why? Nobody changes databases." Well, they might if they could. The side benefit of this abstraction is that it forces the vendors to provide good tools not depend on lock-in.
  74. Platform Independent Design[ Go to top ]

    Going from .Net to J2EE in the real world happens very seldomly, but I have >been on projects, in midstram where that has occured because of change of >management.


    > More than likely because they couldn't (cost too much or didn't know how). The same goes for database vendor changes. Applications are written in such a way that it is expensive to do. So when I suggest using Hibernate/JDO/... I get the "Why? Nobody changes databases." Well, they might if they could. The side benefit of this abstraction is that it forces the vendors to provide good tools not depend on lock-in.

    I have been part of project where they have because the contract situation didn't work out....like Oracle pricing strategy with their RDBMS. So the CIO said "We are going to be an Informix Shop". I said "What!!!"...that was a crazy day, but it does happen and people at the executive level..CFOs ususally don't understand what it takes to do something like that...they think its push of the button. Some execs are pretty good and well listen.
  75. Martin Fowler speaks out on MDA[ Go to top ]

    Brian, in what way does MDA match with XP?
    XP is anti-frameworks. It is do the simplest thing.
    It is write a unit test first. It is about very little
    design up front. It considers code the design. It
    is about code. There doesn't seem to be a match
    with MDA at all.
  76. XP, Martin Fowler speaks out on MDA[ Go to top ]

    Brian, in what way does MDA match with XP?

    MDA reduces edit/debug iteration latency. So MDA is more agile than other paradigms. This facilitates speculative development. Hence MDA is the most RAD. Thus MDA is the easiest way to do XP. My experience confirms this.


    XP is anti-frameworks.

    Bull$hit. XP is urgency driven, which biases the buy/build decision toward off-the-shelf infrastructure. Trick tooling matters to RAD and XP.


    It [XP] is write a unit test first.

    XP doesn't need a coded unit test. XP allows unit testing to be devised after system integration or skipped entirely.
  77. XP, Martin Fowler speaks out on MDA[ Go to top ]

    Brian, apparently has entered the stage
    where it is whatever the believer wishes.
    After many discussions with mr jeffries,
    i don't recognize much of what you consider
    to be XP.
  78. XP, Martin Fowler speaks out on MDA[ Go to top ]

    Brian, apparently has entered the stage where it is whatever the believer wishes. After many discussions with mr jeffries, i don't recognize much of what you consider to be XP.

    You suggested MDA and XP don't mix, which is wrong; they do. You also ludicrously claimed, "XP is anti-frameworks." Can you cite literature in support of either of these two weird claims? Dude, is this comedy hour for you?!
  79. XP misconceptions?[ Go to top ]

    Brian, in what way does MDA match with XP?


    MDA provides agility. XP is an agile method.

    > XP is anti-frameworks. It is do the simplest thing.

    Can't a framework be the simplest thing? Do you really need to invent a better loggere than Log4J (or similar), a better MVC than Struts or Maverick or Spring, etc.?

    > It is write a unit test first.

    This is TDD. Much of the grunt work of writing the test harness is easily automated...

    > It is about very little design up front.

    Or, just enough design up front. The most important thing to design is your understanding of the business model and your overall requirements. Next comes the design of your overall architectural approach. Now put them together...

    > It considers code the design. It
    > is about code. There doesn't seem to be a match
    > with MDA at all.

    MDA is all about code at the end of the day. It just recognizes that you can easily achieve the bulk of your code in a consistent manner.

       Business Model + Construction Rules ==> Code (java, ddl, xml, jsp)

    Turn the proverbial "crank" and have the business model cross-cut the technology model and spit out code that refelects both (kind of AOP-like). Shake well. Repeat as necessary.
  80. MDA and XP[ Go to top ]

    MDA and XP match very well! In fact, using an MDA approach has enabled us to try out architectural changes by changing code generation rules. For example, you can change the way state is transfered between your application's layers, measure the performance, and decide whether this change is worth it with a working system. The most important value proposition of XP is, IMO, to reduce the cost of changes - with is exactly what MDA enables you to do.
  81. Martin Fowler speaks out on MDA[ Go to top ]

    Fowler gets it right most of the time, and every now and then, since he's so good, kind of gets carried away... There was something in his blog long ago about "who needs MDA when Java gives you platform independence" - which IMHO, was a total brain fart statement... In case he doesn't believe whether MDA solves a big problem in the current state of affairs, all he needs to do is check out Kabira and what they use to design their software. UML2 should include Action Semantics as part of the spec, thereby allowing for 100% (or nearly so) code generation.

    As someone above mentioned, in order to use MDA, one needs to think in the level of patterns.. Most software is deja-vu for the most part when it comes to the data structures and/or algorithms used, and MDA (UML+Action Semantics) can be used to fully specify a model from which one could concievably generate 100% of the code... And unless you are doing something really specific, like writing operating systems or embedded software, there's hardly any facet of SW development that MDA could not cover...

    It's not just 'another CASE tool' - one could say that even CASE tools were _vastly_ misunderstood and people did not have the skillset or thorough understanding in order to use them.

    Just because 90% of programmers are chaff, does not give anyone the right to dismiss a particular technology as "just another fad"... unless they took proper time to understand it.
  82. MDA's goal of moving software development to a higher level is laudable. Equating higher level with visual programming like the UML is extremely naïve.

    Read more at http://www.brodwall.com/johannes/blog/archives/000085.html