Introduction

Compuware is graciously allowing me to start a newsletter = series to discuss and ponder these things we do in the name of software = development. In roughly monthly installments, I’ll discuss various = ways to improve the chances that your software development projects = succeed in meeting their goals. Topics will range from being agile, to = modeling, to project management, to model-driven development, to = model-driven architecture, to bettering the UML. Since I travel the = world a lot, see lots of customers and go to various industry events, I = will be able to present lots of different stories and insights along the = way. I also hope to bring in the occasional guest ranter, er, I mean = speaker ;=3D) These will also be a bit tongue-in-cheek at times, as = poking fun at ourselves can be a welcome relief. As usual, feedback = encouraged (see my e-mail information to the right).

UML & Design World 2005 in Austin, Texas

I spent four days in lovely Austin, TX, and I probably have = months’ worth to talk about, from whether the OMG should lie = dormant every few years, to Ivar Jacobsen’s Smart Agents for = helping do software development tasks.

My two biggest observations:

1. MDA as presented by some (maybe everyone I saw?), is nowhere = near how we at OptimalJ address MDA. Geesh.

2. Microsoft’s DSL presentations left me realizing = that, over the past few years, OptimalJ has already done much of what = Microsoft is proposing. Only, their GUI is better (as usual) = <g>.

I’ll address the MDA side of things this go-round, and = leave the DSL and other topics for later.

MDA – Just what is it?

After attending the UML show, I am not sure that people = have a fair idea about MDA. I’ll try to shed some light on why = this confusion might exist…

I admit, I have a very pragmatic and likely skewed view of = MDA purely from the perspective of OptimalJ. After all, the very reason = I came to work for the OptimalJ team was because of the vision I saw = lurking under the covers of the tool (certainly not for the marketing = hype – which was non-existent). For my money, OptimalJ represented = bold, new tooling that happened to have captured how I (and many others) = have been successfully running software projects for a decade or more. = In fact, that is how I have described OptimalJ’s vision of MDA = over the past two years – from the perspective of simply helping = to automate some of the aspects of doing software right!

At the show, however, there also seemed to be views around = “Executable UML” and around the OMG’s original, = UML-centric vision. These views caused the most “blank = stares” in my opinion. Let’s examine the definitions:

[Executable = UML]

involves the creation of platform-independent […] = UML diagrams […] supported by the action semantics-compliant = Action Specification Language (ASL). […] Multiple executable UML = models can be assembled together [and] then translated into […] a = wide variety of target architectures without changes to the models.

OMG:

MDA […] is built on the solid foundation of = […] UML®, […] XMI™, […]; and = CORBA™, the most popular open middleware standard.

I’ll go into Executable UML in a later installment = – and try to address the confusion I could see on many = attendees’ faces when a multi-executable model elevator example = was being explained.

For now, let’s focus on the OMG’s “holy = grail” definition for MDA that involves the following elements, = which I will address one-by-one:

UML – Okay, I agree that the UML = does have a foundation. But is it solid? In my opinion (and that of M= artin Fowler and Scott = Ambler), the UML is an insufficient modeling language for doing = pragmatic MDA. OptimalJ has been forced to build many small, little = languages (these have also been known as  “DSLs,” a = name given them as long ago as 1986?). We have built additional models = for databases, page-flow modeling and user interface modeling. This is = huge! Think about it. For the presentation layer and the persistence = layer, UML is completely lacking and devoid of standards. So just how = are we supposed to consider that UML is all that you’ll ever need = to do MDA? And don’t pull a fast one on me by crying out = “profiles” and “stereotypes” are the answer. = That’s like saying we can model all domain classes using just two = abstract classes. Sure, we could, but it doesn’t mean we = should.

XMI – Having personally struggled = with XMI at my former company (TogetherSoft), and again here in OptimalJ = land, and seeing many customers cry out, XMI is hardly a silver bullet = for exchanging models. It is downright lousy at exchanging diagrams = – which many people put a lot of stock into for model-driven = development. I still maintain that unidirectional interchange of models = is fine for getting started. However, doing bi-directional exchange in a = repeated, iterative manner is likely unreasonable for anything short of = the most elemental aspects of a UML model. That is, two tools can only = interoperate with XMI files when both tools are using only the lowest = common denominator (or intersection) of model properties. Jack = Greenfield, of Microsoft, mentioned to me that a better medium for = interchange is to agree upon the schema – as they typically do for = EDI or ETL. So, to think that XMI is sufficient for one MDA tool to = interchange with another tool is a pipedream.

MOF – Interesting to tool vendors, = but not too many developers.

CORBA – yes, a great idea. The most = popular? Who uses it? A search on DICE.com revealed not many:

I like to think of the OMG’s MDA vision as merely = that – a vision!

MDA is a great idea to help move the industry in the = undeniably positive direction of modeling the business and keeping = technology at arm’s length. Both really good goals!

However, the OMG MDA vision is also possibly its Achilles = heel! Maybe it is just a bit too idealistic and academic for most = developers to unequivocally embrace. At the show, I sometimes would find = myself describing something that we do in OptimalJ as a defense of the = MDA concept. Each time, I would get pushback saying that “yeah, = but while you’re doing something smart at OptimalJ, it = wasn’t what the OMG defined.” Almost as if the OMG’s = own definition was being used against me… Bummer.

Scott Ambler is also very concerned about MDA being = maligned as he felt it was in many of the sessions. Scott is concerned = that, if MDA somehow “fails,” then it might take down = modeling with it. To that end, he frequently points out that at least = OptimalJ has taken a very pragmatic approach to the concept of being an = MDA tool. But Scott remains a harsh critic of the idealism espoused by = the OMG.

Could modeling be the problem?

As a long-time modeler, I am still surprised that software = development teams still do not model as much as I would expect. Why is = that? We had a panel or two to discuss this. I’ll blog about this = in detail later. For now, suffice to say that the UML is certainly not = in widespread use. Could it be that folks do not find enough = “return” for their modeling efforts?

Improving UML for the rest of us.

Could the UML be the problem? Working with Scott Ambler, we = have begun to coalesce a simpler set of modeling requirements for doing = software development. Beginning with the UML as a foundation, we will = explore what the community really needs from models.

You can find out more here...

Can DSLs be the answer?

I have lots of problems with software factories and DSLs as = often presented by Microsoft. But, I think it is mostly because of the = terms “factory” and “domain” and how they may = not be what they seem.

However, I’ll save it for another day!

I’m all ears.