UML the answer? -- more

  • Article

Grady Booch writes : Will's blog had a number of errors of fact,

Ouch! Well, permit me to unruffle my feathers a bit. It's more a difference of emphasis.

But let's start at the top.

GB> I'm disappointed that Microsoft choose the term "software factory," because it's an emotionally-laden phrase that harkens to extremely mature manufacturing methods that focus on stamping out endless copies ...

Mmm. Well -- I was going to say, a rose by any other name .... Whatever you call it, the Software Factories idea is about raising the level of abstraction in software design, and therefore making it possible to do more, more quickly. The metaphor has some good resonances and some not so good ones; what we mean is, of course, the good bits. ;-)

GB>  Microsoft's rejection of the UML in favor of proprietary domain-specific languages

Nonsense! UML is good for lots of things, for example helping me analyse a new domain, or helping me design or understand code. It isn't good for painting my kitchen or designing my curtains (actually there's an idea...). Somewhere in between those extremes, there's a very fuzzy boundary of usefulness. There may be some differences on exactly where that boundary lies. We think (see https://blogs.msdn.com/jackgr/) that there are better ways of doing agile development in some areas.

ACW>>"A careful look at the specialization mechanisms for UML reveals their limitations. Stereotypes and tagged values allow you to change icons etc, although even simple alterations like decorating a box to show the state of some property isn't within range. You can't change the semantic constraints, or invent new sorts of diagram or new categories of element."

GB>This is incorrect: a stereotype allows you to define a set of associated constraints (in OCL, for example) that can capture the characteristics of your domain-specific context. While it is true that you cannot violate the semantics of the metaclass that you have stereotyped, this is actually an advantage of the stereotypeing mechanism. A stereotype is a type-compatible specialization of an existing UML concept. Consequently, you can reuse standard UML tools and expertise even though you are using a domain-specific language. Of course, if you want a language that is incompatible with UML, that is OK as well (specifically, you can define it using MOF), but you will be losing some of those benefits.

So in other words, you can augment the constraints without taking any away. This says to me that in some cases, you’ve got to bend the language. It’s directly analogous to a software framework that’s geared up to do a particular set of tasks. You’re going to find out that it’s well set up to do some of the things you’d like to do, and not for others. For those others, you’ve either got to bend the framework in an unpleasantly smelly fashion; or Do The Right Thing and make another one that fits properly. My feeling is that UML is excellently set up for many of the detailed aspects of software design, and many aspects of general analysis; but we envisage applying DSLs to a much broader range of business domains, for which the UML isn’t quite right.

For this purpose, we’d rather envisage a lattice of languages made up from composable components. Each component (we’re beginning to call them ‘traits’) defines a composable piece of language design – a syntactical style, a set of grammatical constraints, a kit of decorators, or an interactive facility. The languages you can make would include the family that is UML (the base language plus all the languages you can make using profiles) but will be wider than that too. I envisage a market in which you can get both individual traits (though you can’t use one without getting its dependencies too), and a range of standard base languages composed from them. Get the base that’s a good fit, and build your own bits upon it.

ACW>>"An important aspect of the definition of a modern language includes how you interact with it: how you navigate and elide or elaborate and edit etc - think of your favorite GUI composing tool, in which the GUI-defining language is scarcely separable from its editor. You can't do anything about these aspects in UML."

GB>We agree - but this has nothing to do with the UML but rather is all about the tool environment. IBM's tooling approach is to build upon the open standard of Eclipse, not a proprietary IDE.

Not really. In some languages, it's easy to separate out the static views from the interactive facilities of a tool, but there's always a dependency from the latter to the former: how you define the tools depends on the nature of the language. In a world where languages are defined from kits of parts, the interactive features are just more parts in the kit. And in any case, the power of some languages is their heavy use of interaction -- as in the GUI definition languages.

ACW>> "Your users have to understand an editor that's intended for something far more complex than they probably have in hand - or at least whose complexities are in a different direction."

GB>Again, this is a issue that confuses tooling with language definition.

No, the complexity of the tool is important.   Ultimately, it’s the tools you’re constructing, not the language. It’s the tools that your end-users will use. You’re trying to provide some facility for them to design phones or gardens or whatever it is, and what makes it easy or hard for them is what’s on the toolbox, and whether you can do convenient operations that fit with their use cases. It makes sense to integrate the definition of the interactive aspects into the language, because that's an important part of what they use, either as readers or writers. 

Steve Cook and Jack Greenfield have written some good stuff in reply to Grady.

Comments