MDA and Model-driven Development
David: What about process modeling? I’ve seem some people starting from a business process model and using that to derive both requirements and possibly first cut architectures for the application as a whole?
Ted: Our view on MDA is a little bit different. We believe there should be a standard set of data underneath. In traditional MDA you have your design data in a separate repository and then you have to generate all this code for implementation. A lot of the time that disconnect causes problems with changes being made later, or the design going out of date, or developers not wanting to use it because they don’t want to go back to this big modeller, they have a change they just want to do quickly in code.
We do have solutions today. One of our consulting departments has built a product called JHeadStart, and that will allow you to draw a business flow diagram and it will generate a Java application for you. But we’re really trying to figure out the problem. Look at Struts, which is a popular controller. It’s basically driven by an XML config file. So today in 10g, let’s say the three of us are working on a project. I can come in and check out the struts-config.xml, and I can hand edit that XML file because I know Struts and I know the XML and I’m fine with that, I’ll check that back in. The next day you could check that thing out, and maybe you’re not familiar with Struts or just don’t like working with XML, you could just bring up a Struts dialog editor, see that same information, edit it, and check that back in. And then finally a third person can come the next day and work in a visual environment and draw page flows. It’s all exactly the same struts-config.xml file, so our different developer preferences don’t effect the development, we’re all working off the standard core data.
Moving beyond 10g, let’s picture we’ve added a business modeller into the product. We’ve taken our state diagrams, and now someone else can come in and draw a high-level abstract drawing of the page flow in the application. In traditional MDA you’d save that as separate metadata and then generate stuff that the three of us could work on later. In the mode that we’re going towards you’d actually save that in a struts-config.xml file, and in our development style fill in the blanks and actually build that implementation. Now when the business person comes back and looks at it again, they see their abstracted view, but it’s all the same data, there’s no sync problem, there’s no overhead of MDA. In the same way that we’re trying to make UML usable, we’re trying to do the same thing with MDA. In the meantime we do have the traditional MDA tools.
Tim: What about MDA concepts like the platform independent model?
Ted: Metadata does allow you to do some platform-independent stuff if you want to, it does separate your business logic from the code, but in general MDA products, if you look at the WebPutty’s, the AltoWebs and those kind of things, they are very good at a particular type of application. They are normally databound, they can get your input fields, and your search fields pretty quickly, but as soon as you want to extend that or integrate that into something like an eBusiness suite or some custom apps, it breaks down. It breaks down so severely that people just end up throwing them out and not using them. A lot of those companies have struggled. Our focus is to build a dynamic platform you could build any application on, and then adding structure on top for particular types of application. We always allow the access down below to be able to extend it any way you need to if you have that knowledge.
David: I guess that’s what went wrong with the old CASE tools, people couldn’t carry the overhead of maintaining the diagrams.
Ted: Exactly. There’s strict MDA, and then some analysts have defined the term MDD, Model Driven Development, which I like. MDA is an acronym that the http://www.omg.org OMG owns, and they’re very strict over what it means. But model driven development makes sense. Having something where you can get proven patterns and architectures that you agree upon, and then have that drive your actual implementation, is a great idea. It’s just that when people have heard of this in the past they think, OK, I’m going to design something abstractly, save the data, and then generate implementation. And then everyone generated a whole bunch of code. We’re trying to not generate code. What we do instead is generate metadata. We have the code, we have ADF which is a set of libraries running on the server, and it’s code that can interpret metadata. We want to generate more metadata. It’s the same metadata you use in the lower levels to build your application. The metadata drives the code, whereas as soon as you start generating a lot of code you run into maintenance headaches.
Tim: What about refactoring and pattern-based tools in JDeveloper?
Ted: In the next version which you should see sometime this year, the JDeveloper IDE has full-blown refactoring. As far as templating goes, it is something that we’re interested in. In 10g one of the things behind our UML modellers is a new transformation engine. You can create today in JDeveloper a standard UML diagram, and you can say, “convert this to Java”. It’ll generate the Java for you and from that point on the diagram is working off the Java code, it’s synchronised. That generation and transformation is all done in our new transformation engine. The engine itself is capable of transforming anything into anything, XML to Java, UML to XML, whatever it happens to be.
We are going to start building on that and combine it with a templating engine that we have, and giving much more flexibility with the ability to generate back-end design patterns from templates as well as the front end, pages and page flows. That’s something we see big value in.
Tim: When will the next major release appear?
Ted: We haven’t announced this yet. We’re thinking about breaking down into different versions to appeal to different audiences, so having like a pure IDE version which is just like an IntelliJ or an Eclipse, just to let the coders code, and a J2EE version which adds the application server to allow you to build EJBs and servlets and JSP pages. And then a Studio version which is full ADF. Those things may be on different release dates, but you’ll start to see the next JDeveloper late this year, with the next version of ADF Studio coming probably Q1, Q2 next year.
Click here for part 1 of this interview
Copyright Tim Anderson Sept 23 2004