MdaThisYearsSilverBullet

From SPA Wiki

I've put up ImmoHuneke's transcript of the session, follows by some conclusions. By all means add your own comments. -- DanHaywood

Why does OMG champion MDA? OMG is a not-for-profit organisation. We do standards so you don’t have to. Our interoperability standards ensure that the products you buy work together. For the vendors, UML has grown enormously in influence over the five years - 25% per year even through the recession. OMG owns MOF and UML as well as XMI.

MDA solves the business problem identified by the Standish Group (state of software development) that only 34% of projects deliver on time and budget - 15% failed completely (2002 figures). The 51% remaining were 41% over budget and 41% over time. Maintenance burden is over half the cost of ownership. Lost documentation, lost staff and expertise. So MDA is meant to help make applications more maintainable over their lifetime.

AshleyMcNeile's two minutes

AM: surprised to find myself described as a tool vendor. The tools side is just a side effect of being a practitioner. My view of MDA is that it promotes the role of modelling in the development and management of applications. This I agree with as a practitioner. I particularly like the idea of separating the PIM, domain model or essential model from something that represents the deployment of that model. I have a background in behaviour modelling, and I don’t think UML does this particularly well. Also I am not necessarily sure that code generation is the right way to use models. The models could be used in a number of ways, including interpreting, enhancing with code that performs actions etc.

Modelscope uses model execution as a way of validating both the model’s internal self-consistency and the understanding of the customer’s requirement. Modelscope doesn’t take you forward into development.

JohnDaniels' two minutes:

JD: why don’t we all use 4GL tools? Well, lots of them don’t really fit with modern thinking about architecture. But they were good for building certain types of systems. Modelling is a very good way of making thoughts clear. I’m a sketcher, like Martin Fowler. Only some of my sketches are pretty detailed!

Some of the time I am a coder, and have used many programming languages. If someone shows me a nice language that makes it far easier to build systems, I have no objection to using it. The day someone gives me a tool that allows me to develop systems directly in UML, I will be overjoyed. However, I suspect that at least early versions of those tools will be limited to building the types of systems that 4GLs were also suited for.

Why is there so little effort going into interoperability for MDA tools? AW: XMI is the interchange standard for UML CASE tools promoted by the OMG. Almost by accident, the MOF became the standard for model interchange. It had one problem - it didn’t convert diagrams between tools. This has been fixed by UML 2, which is just about finalised. The “draft” standard can be downloaded from OMG. Please comment if you find any problems in it.

Transformation rules are not addressed by the MOF. The major standards threads are UML, XMI, meta-model repository standards (MOF) and a standard for transforming between models. An RFP has been issued (QVT - query view transformation). Meta-model version control has been kicked off as another activity thread.

Dan: Do we expect AndroMDA, that uses Velocity templates to perform transformations, to be retrofitted to express both PIM and PSM as MOF instances and Velocity templates as instances of QVT? Andrew: … [sorry, not keeping up at this point]

Ashley: Issues about MDA that frighten some people: potential clash between MDA and the agile movement. We went through a stage when we had heavy-duty modelling-based methods. The result in many cases was “analysis paralysis”. Agile concentrates on delivering systems rapidly, with a lightweight process. If MDA means generating very detailed models, this could suck us back into analysis paralysis.

JD: but if the transformation from model to code is taken out of my hands, there is no such problem.

Andrew: someone still has to write the “compiler” from model to executable. If this were left entirely to the vendors, we would be back with the 4GLs. However, the architectural patterns used by the code generators are open to be modified and augmented by project teams. Steve Mellor’s paper on the OMG web site “Agile MDA” makes the point that agile methods do not oppose MDA.

JD: Agile developers are still waiting for the real tools to appear.

Martin Fowler (for it is he): it all depends what view you take of modelling. Kent Beck said that if you could program by drawing boxes and lines, that was perfectly in keeping with XP. The question is, does it work? We just don’t see UML as a viable programming language at this point. What can you say about a language with no syntax and no semantics? Until this is addressed, the controversy will continue. I can still write most applications more quickly in programming languages than by drawing interaction diagrams.

Dan: Executable UML claims to have all the information you need in the model. This augments UML with action semantics.

MF: some people claim that UML is irrelevant to MDA, so long as you use MOF. Much variation - some people say that manual intervention is required for the model-to-model transformations.

AW: There are tools out there that claim to be MDA tools. People using them claim productivity improvements of up to 40%.

MF: No-one has ever managed to measure productivity satisfactorily, so I don’t believe this.

AW: There’s a well documented case study where two teams of programmers implemented the well-known “pet store” application using (a) a commercial IDE and (b) an MDA tool. The second team used 35% fewer man-hours and said that it would have been even faster on the next project, now that they had learned the tool.

DH: if in five years’ time we have a much better platform than J2EE 1.4/EJB, won’t our investment in models have been wasted?

AW: Microsoft tries to persuade us that .NET already is such a better platform! EDS did a study of implementing pet store using Visual Studio.NET and using a MDA tool targeting J2EE. Again there were similar productivity improvements.

JD: Standard Java programmers using the usual IDEs spend a fair amount of time deciding how to architect the application in terms of which tiers to use, where to locate certain functionality. The MDA tool may simply be more productive because it takes away the need to do this brainwork. Experienced application developers may have the same kind of productivity advantage.

AW: tools like this help you to avoid optimising prematurely. You can make more assumptions explicit and leave decision-making until much later in the project. JD: I simply don’t buy that.

JD: Did the tool used in the pet store study provide complete translation from model to code? Andrew: no, it was OptimalJ and in this case the translation was approximately 50% automatic.

JD: in that case, wouldn’t the amount of rework required over the lifetime of an application to adapt it to different platforms negate the benefit of using the tool? You might have to do more work in the hand-crafted parts to adapt to changes in the generated code. AW: otherwise you might have to maintain the model and the code in step manually.

MF: writing entity bean applications, the only way to deal with the mass of bean-handling infrastructure required is to generate it automatically from configuration files. So this is already standard practice.

MF: The MDA pretends that this is all a brand-new thing. AW: no, I think it is evolutionary. It’s just a refinement of existing CASE tools.

JD: Have you done market research to see whether there is demand for MDA tools? AW: we don’t have to do market research to understand that developers want to do software development better, faster and cheaper. JD: Are you asking programmers or …

Richard Mitchell: You shouldn’t ask programmers, whose jobs might be threatened. We go into an organisation with some very good programmers who are also good modellers. They generate software 100% from JSD models. Customers keep asking for more. If we could cut the cost of producing software by a factor of 10, we could sell 20 times more of it.

AW: Developers in the West will have to become 10 times more productive to combat the threat of offshore development shops. MF: that’s a false argument, because the offshore developers can use the same tools as we do. DH: Diminishing returns - you still have to assign a full-time person to ride herd on the offshore developers. MF: in any case, we’ve been hearing the prediction that programmers will be out of work ever since assembler replaced machine code. It won’t happen.

RM: the modelling language needs to be more than just a business-oriented language. It has to be able to express user interface requirements, performance, implementation strategies (e.g. struts) etc. We generate 100% of code from OCL and OQL, not action semantics. It really works.

MF: Class diagrams and interaction diagrams work well in certain limited domains (Selleck). Can it expand to a broader class of applications? AM: I like state machines, but I wonder if Steve Mellor’s approach works well in business applications (being weighed down with lots of real-time baggage). Is an action language useful as a modelling language for processes? RM: You couldn’t write the Hokey Cokey from a declarative specification, so we don’t try.

DH: Consider the 20-year lifetime of typical business applications. Do models have that kind of lifetime? Are they actually that valuable, how fast do businesses change? I used to work at Sybase. We used to do logical data models etc. but few people seemed to attach very much value to them.

RM: If you’re in an organisation that writes Java and generates byte code, you maintain the Java. Value is attached to what is perceived as the definitive source.

AM: I have written code generators. The output code was impenetrable. When talking to customers, we had to explain that enhancements and changes to the application had to be applied to the high-level source. Customers then asked “what if in 10 years’ time you the vendor are no longer around to enable us to generate the code”? So the programming language needs to be standard, at whatever level of abstraction.

RM: Some people actually prefer to write programs in specialist non-standard languages! AW: and what about deployment scripts, test scripts etc? These are all written in environment-dependent languages.

AM: There are ways of solving this. People who write code generators in-house are comfortable with that - it is under their own control. If you purchase a translator, you need standards to support you.

RM: We give our customers the tool to take that worry away from them. They own the process, be it people-centred or tool-driven. It’s just very much more productive in the latter case.

DH: Our day-to-day work is changing. Do we think that we will be using more code generation technology (AndroMDA etc) going forward?

AM: This emphasis is partly driven by CASE tool vendors, who must compete with each other by plugging code-generators on the end. I believe that the distinction between modelling and programming languages is blurring, so that the emphasis on code generators is going to diminish.

Rob James: The industry has actually gone backwards in the last ten years by abandoning 4GL. An inclusive modelling language is needed that models everything, end to end, including systems, people, infrastructure.

DH: Mellor et al in the Translationist camp have achieved some success with this approach, in specific restricted domains such as avionics.

AW: I really want to combat this misunderstanding that business analysts will write software and put programmers out of work. Think of yourself as an EJB platform expert, rather than an EJB developer. The MDA tool can become your skills amplifier, letting you create code templates rather than code directly. Few customers will write templates from scratch, but adapt existing ones e.g. supplied by the vendor or distributed through practitioner networks.

RJ: I think we need to have a completely different view of how we use models to generate systems. The model must completely represent the business process and the systems on which parts of it are to be automated. This isn’t the same kind of model that MDA community is discussing.

Klaus Marquardt: I am a programmer and I love MDA for many reasons. It gets the right people to write code - the architects. They all suffer from the same pains and fears as I do. My architect has become scared because there are people around who are smarter than he is. They deal in another level of abstraction. I like to see the highest pay going to the smartest people. I also like the fact that tests are generated along with the code!

RM: Tests are not generated automatically. You still need tests that validate the model itself. Everyone (including Klaus) agrees that generating tests from the same model that generates the code proves nothing (see Hubble space telescope!).

MF: you will still have to generate tests and production code separately.

George Ntinolazos: What does MDA have to offer to customers whose main requirement is legacy integration? AW: almost every application has this requirement; there are virtually no green-field projects today. There is a group of people working on this - reverse engineering existing systems into the model. There are vendors around today who have developed specialist tools that assist the process, but it is not completely automatic.

George Ntinolazos: Are we going to see tools that can reconstruct the high level model from the low level code? AW: Round trip engineering is possible in some tools today. Code to model and back again.

Andy Carmichael: although the reverse transformation is the harder one, this is the most valuable. Start at the lowest human-readable level, not machine code. Can we capture the higher-level abstractions embodied in the code? That would get me over the objections to model transformation.

JD: This doesn’t make sense to me. If I am just developing at the PIM level, I am not interested in the low-level source code spat out at the bottom level.

DH: I’ve reverse-engineered databases. The referential integrity constraints in the database itself convey more information in many cases than the code. AC: yes, even there, there must be a human-readable database schema somewhere.

AM: Consider a de-compiler that creates Java source from byte code. If you then apply that to hand-written assembly code, you won’t get anything meaningful. Reverse compilers only produce even an approximation to the original source code if the assembler code was generated by an associated compiler.

GD: If you’ve reverse engineered from a legacy system, it won’t make much sense without reference to the original models.

KM: Every time another level of abstraction becomes available for developers to use, it is a step forward - this explains the explosion of popularity of C%2b%2b when compared with C. [ENDS]

Unfortunately, perhaps because of the large turnout and some rather distinguished speakers, this didn't really happen.

Conclusions

DanHaywood's viewpoint, by all means add your comments below

The difficulty with this goldfish bowl was always going to be getting the spectrum of opinion. Obviously AndrewWatson defended OMG's position with some good evidence, which AshleyMcNeile and RichardMitchell both put forward a pro-MDA approach from a vendor's viewpoint. However, every MDA-aligned vendor places their own take on what MDA means (or should mean) so this can make it difficult to help form an opinion.

The large turnout perhaps inhibited discussion from those who came just to see what MDA was about and form an opinion about it. MartinFowler's involvement, welcome (and courted!) as it was, might also have had something to do with this... though normally OT delegates aren't too shy in participating! In retrospect I might have done better to call a time-out after 20 minutes discussion or so and invite some "dumb questions" from the floor. Oh well, live and learn.

If you are reading this having attended the session and are still wondering what the difference is between the two flavours of MDA (elaborationist and translationist), let me explain. The elaborationist has the PIM (platform independent model), the PSM (platform specific model) and code as three layers, and allows for "elaboration" at the PSM and code layers. In other words, this is the code-gen plus tweaks approach. OptimalJ sits in this camp, where in the GB discussion AndrewWatson claimed 50% or more code gen. Other tools are ArcStyler and (I think) AndroMDA.

In contrast, the translationist approach really has only the PIM, with behaviour specified in a platform independent manner. This is the Shlaer-Mellor approach updated. I believe RichardMitchell's tool is in this camp, where they use only ObjectConstraintLanguage. An alternative way to express behaviour - imperatively rather than declaratively - is to use the new ActionSemanticLanguage. This is the route taken by KennedyCarter and BridgePoint.

For myself, I can't say I was convinced by any of the arguments put forward from the pro-MDA viewpoint. Of the two flavours of MDA, I have more sympathy with translationist. From what I've seen, what gets added in the "tweaking" of generated code in the elaborationist approach is actually a lot of the behaviour, e.g. as written in Java. In other words, the code generation creates only the static structure. This is only a part of the model.

The trouble with translationist though is that although it is proven in at least some domains such as avionics, it does mean you need to express that behaviour either declaratively in ObjectConstraintLanguage or imperatively using a vendor's own dialect of the ActionSemanticLanguage. As I said in the discussion (I don't think it got captured in the transcript), I just can't see all those Perl programmers abandoning Perl for either of these two languages.

If you are interested in learning more about MDA, then there is a 2-day conference 'Enterprise UML & MDA 2004' in May in London. I'll be putting forward the sceptics view again, though this time I'll be surrounded by all the pro-MDAers. Daniel in the Lion's Den, indeed. For more details, see http://www.enterpriseconferences.co.uk/day1.php.

My thanks to the speakers for their participation, in particular to AndrewWatson for coming up and staunchly defending OMG. And thanks again to ImmoHuneke providing the transcript above.

Back to OtTwoThousandAndFourOutput.

Comments

other comments welcome

A couple of quick comments

Andrew Watson

Firstly, the question mark got left off the title of this web page - it should really be "Is MDA this year's Silver Bullet?". I think the studies that I referenced show that it isn't - the productivity gains are real.

Here's a link to the first study I mentioned, comparing two development teams, one using a Java MDA tool, the other an ordinary Java development environment. This study showed a 35% effort saving by the MDA team:

http://www.compuware.com/dl/MDAComparisonTMCfinal.pdf

The other study I mentioned, showing that MDA%2bJava provides a more productive development environment than .NET is here:

http://www.eds.com/thought/thought_leadership_agility_model_arch.pdf

Happy reading. If anyone has any questions, please contact me at andrew (at) omg.org.

MdaThisYearsSilverBullet

From SPA Wiki

Contents

Introduction

Initial Participants

DanHaywood’s two minutes on MDA

AndrewWatson's two minutes

AshleyMcNeile's two minutes

JohnDaniels' two minutes:

Conclusions

Comments

A couple of quick comments

Views

Personal tools

Navigation

Search

Toolbox