Semantic Werks

Part of my research used the Object Constraint Language to provide a model query language. Knowing nothing about OCL a year ago, I am now getting to be more familiar with it. The OCL specification is pretty well written, although hardly suffused with useful examples. Consequently, I bought the OCL book by Jos Warmer and Anneke Klepper.

OCL is associated with the OMG model-driven architecture (MDA) initiative. Consequently, the book assumes that a world in which all software is created by manipulating diagrams (ok, not all models are diagrams, but most are) is a good and inevitable one.

First off, diagrams are not necessary in doing modeling, in fact may be counter-productive. The authors bring out the modeling maturity levels, where 1 is denigrated as ‘the lowest level of professional software development’, with specifications residing in the developer’s head, and level 5 being full use of models to develop systems.

There is no evidence that I am aware of that shows that software built in level 1 is more {maintainable, usable, functional, cheaper} than level 5. This hierarchy is entirely based on conjecture, and as such is a good example of over-reliance on begging the question (i.e., let’s assume that in the ideal world, software will be built with models, and then start looking for premises to support that conclusion).

It would be a good study to compare software built ad-hoc (level 1), versus software built using models. Certainly the former approach has by far the greater degree of industry acceptance, so on the basis of adoption, at least, the modeling approach has completely failed to make its case.

This is why I argue for moving our field from one of ‘building solutions better’ to ‘understanding what to do’. Software engineering started in 1968 at a NATO conference on how to handle the massive amounts of software code that was clearly going to be a big part of the future. It was here that the idea that software production should be more systematic and repeatable — more like building a bridge — was first put forth.

And that’s all to the good. However, what we do as academics is not building things. I mean, I’ve written code, but I’m sure it’s horrible and unreliable. But it’s not my central concern. My central concern is science, and as I understand it, that means exploring new ideas and testing those ideas in the form of theories. Most of what passes for software engineering research, however, is the building of new and unproven technologies or, worse, ideas for new technologies in the form of frameworks. It’s as if physics was only theoretical, and never experimental.

When we consider the nature of software-based systems over time, software evolution, there is always a lot of talk about evolving that system. Most famously, perhaps, a set of “Laws” were proposed regarding software evolution.* And to date, most work on software evolution tends to be very focused on technical issues:

• backward compatibility
• transformations
• versioning
• comparison

However, at heart this issue is not just one of technical challenges (low-hanging fruit, if you will). You are dealing with a change in domain fundamentals — e.g., a Car no longer has a combustion engine — and this forces a change in nearly all other layers of your technology. Whether you believe in Model-Driven Something in Upper Case or not, reality is that the domain model does drive your software-based systems: as soon as cars can now have battery engines, your existing software is no longer adequate.

Resolving the technical details, like updating your UML class models with new BatteryEngine boxes, is a simple enough idea, I think (obviously the devil is in the details). More of an issue is figuring out “what” the change means and “why” there was a change. This presents a challenge because we technology types would rather worry about the “how” since it is more amenable to immediate tinkering.

To answer the what-it-means and why-the-change questions (as well as impact analysis), I think there is only one answer: you must maintain the domain model in some explicit form for the duration of the software lifecycle. What form the model takes is context-dependent: I wouldn’t bother with a complex modeling solution if I was building a web site for a client, for example. It might be a DSL for a very specific set of business rules, or a massive set of finite state machines and a model checker. But you cannot answer questions about change without some explicit model artifact (unless you have some savant developer who maintains the domain model and implementation details in her/his brain over many years).

Ideally, this model will be able to answer the why and what questions for you automatically, or nearly automatically. It will explore scenarios, evaluate impacts, and allow you to choose the preferred evolution path (for some context-specific set of preferences). Even better, this model will evolve quickly, so that you can push changes to the software quickly and nearly transparently.

* The term “Laws” is more reflective of the modernist and logical positivist origins of software engineering, a paradigm that has long outlived its usefulness. The notion that nature can be controlled has been flung happily into the trash in most other disciplines.

There has been some talk about the ‘pending death’ of UML. Industry consensus seems to be that it is mainly useful for sketching designs or communicating use cases to stakeholders. However, some of the modeling community have taken heart from recent remarks from Microsoft. In a recent keynote address, Bill Gates was asked the following question (via the Register):

QUESTION: I’m (Sheila Shovelin ?) from FedEx.

I have a question. You mentioned modeling tools as being a focus. Is there any effort being made to couple with the initiatives of the object modeling group?

BILL GATES: Yeah, which standards is object modeling group in? OMG, is that the –

QUESTION: UML.

BILL GATES: UML, okay.

QUESTION: Like the class diagrams you have in Visual Studio, they’re not quite UML.

BILL GATES: Right. Yeah, we’ll have additional support for UML in Visual Studio 10 for the specific modeling tools that are there. Then as we move forward and take the modeling platform to the next layer, we’ll get even more ability for you to create your own models.

So, you’re absolutely right that the modeling world is fairly disparate today. Even at Microsoft our people who do our business applications have some of their modeling environment. Excel in a sense is a pretty limited modeling type environment.

The thing that we’ve recognized is that by bringing those things together we can actually enable new things like what you do across the lifetime of an application. And underneath these models we actually use UML.

We think it’s very rare — a very rare person would actually want to look directly at the UML because it’s so kind of abstract, but underneath, both in terms of exchange with other people’s products and some of the exchange we’re doing between our own products, we do have UML based subscriptions of these models.

I’m not actually a UML expert. Hopefully, we have some breakouts where we can get more into that — okay, I guess (Brian Harry ?) will do that, where you’ll get more of a sense of this modeling roadmap, and how we connect up to all the modeling standards.

My interpretation of this is not quite so rosy… first, I think it’s clear UML is hardly on the radar for Microsoft’s senior executives. Secondly, it seems like UML is used mainly as the backend representation format, and not the user-facing modeling language — “a very rare person would actually want to look directly at the UML”.

What is positive is that Microsoft seems to be acknowledging the need for some form of hierarchical abstraction mechanism. They would like to enable developers to work with models of the architecture that are automatically created from source. This certainly seems to support the value of modeling, but I’m less certain it’s an endorsement of model-driven architecture or formal UML. And let’s keep in mind the vast numbers of developers Microsoft works with.  Perhaps my colleague Jorge, now at Microsoft for the summer, can shed some light on this issue.

Julio Leite reported on UML usage statistics, showing penetration of UML is ~23%. In an upcoming publication, Jorge Aranda surveyed small-sized software firms and found their use of modeling to be quite low, and typically of the UMLAsSketch variety. So…

Q. Why is UML so little-used, despite the fairly heavy-duty marketing and machinery behind it?

A. The long tail. See the graph below.

My contention is that of software development teams, the vast majority are working on less complex projects. For example, a month-long website redesign, a custom CRM extension, etc., etc. There are comparatively fewer working on multi-month, disruptive software systems.

Some questions, other than where can we validate such a claim.

1. How can we measure complexity? Time to completion? Size of written source code? Platforms targeted? Risk potential? Project budget? I would probably lean to project budget as a very rough guide — we all use dollars, and the cost usually reflects an a priori assumption about complexity.
2. What sorts of tools would the mushy middle of this tail need? I.e., those firms doing median complexity projects? Clearly the companies at the head of the curve don’t need the Thor’s hammer of UML or DOORS when the Owen’s* hammer of technologies like Excel do just as well. But there must be a tipping point where these technologies start to get more and more useful and important. But
3. Is there good empirical evidence that even the long-tail denizens need UML, DOORS, or Rational? Indeed, we might even expect that such large-scale firms would customize requirements management, configuration management and other helper technologies for their own purposes. This seems to be the case for Linux (GIT), NASA (SCR, formal methods, etc.), and probably others.

* Thor’s weaker and lesser-known half brother, an accountant in Little Wopping, England.