random cognition

A modelling language focused on Relationships?

2010-01-28T13:36:00.000-08:00

As with all things, interest in modelling languages is cyclic. In the 90s object orientation was big, leading to the creation of UML. Interest then tailed off, but recently modelling languages have come back in to focus with the rise (again) of domain specific languages.

With each renewed interest comes a renewed search for the one true modelling language - 'one language to rule them all'. It's not as if we're short of candidates: there's MOF (the foundation of UML) and myriad offshoots such as eclipse EMF. Then there are less mainstream alternatives like GOPPRR. More recently there's GModel and a proposal by Atkinson et al.

Each has strengths and weaknesses. UML cemented concepts like classes, objects, binary relationships and subtyping in the mainstream vocabulary, and provided a default graphical syntax. However it's an extremely complex language, not self-consistent and too imprecise for direct interpretation.

GOPPRR provides a much smaller language: easy to understand yet one that's proven useful and workable at the coal face. GModel and Atkinson bring some novel concepts to the space, such as multi-level instantiation.

Though different - significantly so in some respects - all seem to share a common, implicit philosophy. They all appear to arise from first asking the question "what are the useful concepts we need to express?" then secondarily "and how do they relate to each other?".

That's understandable. It's what every book on OO modelling tells us: find the interesting abstractions, and figure out how they fit together. Yet experience says the key to unlocking a problem domain lies in understanding the relationships.

That gives rise to a question: what happens if we focus first on the relationships instead of the things being related? Is there some minimal set of useful relationship types? What would a resultant modelling language look like? And would it actually be any use in practice?

Lifted... and let down

2009-03-27T14:57:00.000-07:00

Alternative languages on the JVM are very 'in' at the moment, Scala in particular. Almost inevitably, there's a web framework for Scala - Lift. I looked at it briefly a while ago when embarking on a new web application. The 'sales pitch' was compelling, pulling together the best aspects of other frameworks whilst exploiting the power, scalability and safety provided by Scala. However, it was very early in its development with little documentation and few plugins. I decided in the end to use Grails.

Lift has matured somewhat since then so I took another look. I'm still very much taken by the pitch; the framework has matured significantly and the documentation has improved beyond all recognition (i.e. there is now some - including an incomplete but nevertheless good online book. There are also tutorials starting to pop up, so I thought I'd take another look.

Setup is easy, making extensive use of Maven. Next up is creating domain classes - and I'm afraid the first disappointment. Per all web frameworks, Lift comes complete with its own Object Relational Mapping capabilty - named, appropriately, Mapper. The tutorial uses a "ToDo" class as an example, with each item having the following properties: a "done" flag (boolean), a priority value (Integer), a description (String) and a relationship to the Owner of this particular item.

Very simple. In Grails, I'd code this as:

class ToDo {
Boolean done
Integer priority
String description
User owner
}

Pretty intuitive, intentional and economic.

Here's the Lift equivalent from the Tutorial:

class ToDo extends LongKeyedMapper[ToDo] with IdPK {
def getSingleton = ToDo

object done extends MappedBoolean(this)
object owner extends MappedLongForeignKey(this, User)
object priority extends MappedInt(this) {
override def defaultValue = 5
}
object desc extends MappedPoliteString(this, 128)
}

object ToDo extends ToDo with LongKeyedMetaMapper[ToDo]

Wow! Now granted, this is my first introduction to Scala and Lift. But there seems to be an awful lot going on there:

a class and an object with the same name;
the main ToDo class extends a parameterised type - which is parameterised with ToDo itself
a singleton ToDo which extends the ToDo class with another type parameterised with ToDo (the object or class? Not sure...)
a slew of names evidently drawn from the world of relational databases (PK, ForeignKey, MappedXX types).

Lets deal with the last point first. It's a philosophical discussion over whether the domain classes should provide a "clean" Object view of the concepts and hide the Relational mapping - or expose the Relational concepts explicitly. Grails takes the former approach, Rails the latter. Django is somewhere in between. My personal preference is the former - but its personal preference, so let's put that aside.

But even allowing for that, why does it have to be so complicated? From my perspective as a Scala and Lift newbie, it almost looks like a case of "we have all this cool stuff at our disposal, lets use it". Hence objects, classes, extension, traits and generics all make it in there.

Now I'm all for using the power of the language. But surely it should be used to both make things more intuitive and improve economy of expression? That certainly doesn't seem to be the case above.

Concept vs. Representation

Scala has some powerful XML handling capabilities, and Lift exploits these to enable tailoring of the way in which elements will be presented. Here's a snippet from one of the tutorials:

override def _toForm: Can[NodeSeq] = {
val funcName = S.mapFunc({s: List[String] => this.setFromAny(s)})
Full(</span><textarea style="font-family: courier new;" name="{funcName}" rows="{textareaRows.toString}" cols="{textareaCols.toString}" id="{fieldId}">{is.toString}</textarea><span style="font-family:courier new;">)
}

Powerful indeed. But wise? First off, it's mixing representation information with the domain class. Or, in MVC terms, mixing part of the View in with the Model. MVC says they should be separate, based on the principles of low coupling and high cohesion. It also complicates the workflow if a graphic designer is doing the UI / layout and a programmer doing the logic. As above, it seems like another case of wilful rather than judicious use of power.

And I'm afraid that's as far as I got. Maybe I should have persevered; Scala's Actor support holds significant promise for efficient scaling. But for now I'm not sold. Grails (and Groovy) may not have some of Scala's power features but the 'user interface' is significantly cleaner. So I'll continue grooving for now.

Relationships are more fun - part II

2009-03-24T15:33:00.000-07:00

Trygve Reenskaug and James Coplien have just posted an article questioning the fundamentals of Object Orientation and the Model-View-Controller pattern.

It's interesting (if perhaps a little more wordy than necessary). And I don't agree with all of it (more of that later). But their characterisation of the relationship between the User's mental model and the Object model represented in software is spot on. But perhaps more interesting is their questioning of one of OO's central tenets: that all behaviour belongs in Objects (or Classes in programme language terms).

They assert that, whilst some behaviour does belong within the Object, much doesn't. To use their example: responsibility for increasing or decreasing an Account's balance properly lies with the Account. External parties can ask the Account to perform those operations, but it's up to the Account to do it. That's fully in line with the principles of Abstract Data Types on which OO is founded.

But what about performing a Transfer of funds from one Account to another? Where does that belong? Reenskaug and Coplien assert this doesn't belong with the Account Object - I agree. But that's how it would typically be handled in today's OO languages; so the Account class would typically have a method named "transferTo()", used as follows:

Account src;
Account dest;
src.transferTo(dest, 20.00);

What's wrong with that? From a mental model perspective, it doesn't work. When I think about transferring funds, I don't think about the responsibility lying with either the source or destination account. Sure they're both involved, but neither is responsible.

So where does it belong? In OOP terms we have nowhere else to put it other than in a Class. Reenskaug and Coplien suggest the notion of Interactions as first class entities; however their model still portrays an asymetric pattern (i.e. the responsibility for executing the transfer still lies with either the source or destination objects).

I prefer to think about it lying outside of either. But that doesn't mean the OO model is broken. Maybe it's just the way we use it today. Coming back again to the code example above:

src.transferTo(dest);

Now what happens if we look at this from a relationship perspective? What's the nature of the relationship? It's pretty obvious there's some link between the source and destination accounts - even if it's only transient. Here's an initial view as a UML class diagram?

Both source and destination are instances of Account, so the relationship would have to be recursive on Account. OK. Naming the ends? Easy; one is source, the other destination. Cardinality? Hmm, that's a bit more difficult. A given transfer has exactly one source and one destination account; and any account can be the source and/or target for many transfers. But we can't represent that on our relationship:

1:1 would only allow each account to be related to a single other: i.e. at most one transfer.
many:many would only allow each account to be related to every other; but for every pair there could only be one transfer. Again, not what we need.

Let's revisit naming the relationship ends. I used "source" and "destination" above, which are role-based names. As I've stated previously, I prefer verb-based names because they bring out the "why" of the relationship. So how would we name the relationship ends using verb phrases?

Each Account may be the transfer source of one or more other Accounts
Each Account may be the transfer destination of one or more other Accounts

Kinda works, but it looks clumsy; it smells bad. So the cardinality doesn't work and the relationship naming is ugly. What does that tell us? Maybe there's no relationship? Well that's not true. It may be transient but both accounts are undeniably involved in something - otherwise there's no transfer.

Transfer. Hmm. What if, rather than looking at transfer as a verb, we treat it as a noun? What would that mean? Let's rework the model:

Let's examine the relationships again:

Each Transfer must debit exactly one Account
Each Account may be debited in one or more Transfers
An Account need not be debited in any Transfers

Each Transfer must credit exactly one Account
Each Account may be credited in one or more Transfers
An Account need not be credited in any Transfers

That's much better. The cardinality and phrasing capture exactly what we're trying to express - so the relationships look OK. But what about that "Transfer" class? Is it a proper class? Well, what does it mean to be a "proper" class? It's definitely an abstraction of behaviour - the transfer behaviour. What's more, it's a well encapsulated abstraction of behaviour. We are not loading the Account class with the responsibility for executing transfers; it need only respond to "credit" and "debit" requests: appropriate since it maintains the account balance.

What about state? That's OK too. The transfer value again properly belongs with the Transfer. We could also, if required, capture details of the time and success/failure of each transaction. Finally, we could, if required, track the state of each Transfer as it executes ("debiting source account", "crediting destination account", "completed successfully", ...).

There are critics of this approach who disagree with the idea of reification - treating behaviour as things. Rather, objects should be tangible things: Accounts, Customers, Chairs, Telephones, whatever - the things that are things in the real world.

The trouble is that doing so causes the situation that leads to a.transferTo(b). In fact, most of the interesting behaviour doesn't happen in the tangible objects. Transfer is an example of an Interaction object; one that coordinates a protocol amongst other objects. Interaction objects are useful and interesting precisely because they enable clean abstraction of behaviour amongst a number of other objects.

So is the OO model broken? No, not really. We just need to learn to use it properly. Going back to Coplien and Reenskaug, maybe it would help to promote Interactions to first class status, and hence increase focus on collaborations. Key to that is learning to love relationships - they're where all the fun happens.

Relationships are more fun

2009-03-24T14:27:00.000-07:00

A number of years ago, I was fortunate enough to work for Steve Mellor's company. I remember vividly the first time I met him; I was very nervous. He was reviewing a domain model that I'd built, and I was amazed at how quickly he found a couple of logical flaws. One thing he said during the review has stuck with me ever since: "the fun is always in the relationships". It struck me as strange at the time; as someone schooled in OO, I had come to view Objects as the things that mattered. Relationships? Just pointers between Objects, right?

Wrong. Very wrong. Experience has fully vindicated Steve's assertion that the interesting stuff really does lie in the relationships, not the objects. In fact, the key to understanding any domain always comes down to formalising the relationships among the domain concepts. So I'm constantly frustrated by models in which relationships are second class citizens, demoted to pointers between objects with perhaps a role name. Something like this:
Why? Because it says nothing about the semantics of the relationship. Why does a Customer have a list of Accounts? Moreover, it says little about the domain - and doesn't prompt discussion or questions about the relationship. Can a customer really have more than one Account? How many Customers is each Account related to? What does the relationship mean when viewed from the Account's perspective anyway?

Steve (and my colleague, close friend and boss at the time Alistair Blair) instilled in me the importance of naming relationships using verb phrases. I've found it extremely valuable, more recently adopting the style recommended in Simsion and Witt's excellent book on Data Modelling. So the model above becomes:
With very little extra effort this provides much more information. We now know the relationship represents "Account Ownership". It doesn't cover being an authorised signatory, or a benefactor, or anything else. Are those things necessary? They may be. The point is the model now prompts that question.

The model also makes assertions about the relationship. An Account must be owned by exactly one Customer. Is that right? What about joint Accounts? Again, the model prompts the question. And so on. We can also generate textual facts (or "business rules") directly and algorithmically from the model, according to the technique described by Simsion and Witt. So we'd get:

Each Person may own one or more Accounts

Each Account must be owned by just one Customer

Furthermore, it tells us something about the behaviour, or interaction between Customer and Account. On first glance it's pretty simple: create a new account, assign it to the owner. Job done. But what happens if the Customer goes away? In typical OO programming terms, that responsibility would lie with the customer:

foreach a in self.accounts:
a.delete()

But why should it belong with the Customer? The required behaviour arises because of the Relationship: it's not intrinsic to the Customer. Another case in point is transfer of ownership. Where does that belong? The Customer? The Account? No. It belongs in the relationship.

So the fun does really happen in the Relationships - thanks Steve and Alistair for enlightening me.

grails property conundrums

2009-02-23T13:02:00.000-08:00

Been writing an application using grails. Very nice framework, but as always there's the usual slew of learning curve conundrums. One in particular had me perplexed (and obsessed) for days.

I needed a class to hold plans; here it is:

------------Plan.groovy---------------------
class Plan {

  String name
  Date startDate
  Date endDate
  static hasMany = [tasks : Task]

  Integer numDays
  public void setNumDays(Integer numDays) {
    this.numDays=numDays
  this.endDate = this.startDate.plus(this.numDays)
  }
}

Simple really; only thing remotely out of the ordinary is the setNumDays() method which automatically calculates the end date from the start date and duration. And here's the corresponding test class:

import java.text.SimpleDateFormat
class PlanTests extends GroovyTestCase {

  void testDates() {
    def sdf = new SimpleDateFormat("yyyy-MM-dd")
    def plan = new Plan(name:"test1",
        startDate: sdf.parse("2009-02-22"),
        numDays: 7 )

    //this shouldn't be necessary!?!
    plan.setNumDays(7)

    plan.save()
    assert plan.name == "test1"
    assert plan.startDate == sdf.parse("2009-02-22")
    assert plan.numDays == 7

    //Fails without call to setNumDays() above
    assert plan.endDate == sdf.parse("2009-03-01")

  }
}

The strange thing is that without the explicit call to plan.setNumDays() the final assertion fails. This was perplexing. I tried testing as a native groovy class with accompanying test script; contents exactly as above (minus the hasMany in the class and call to plan.save() in the test script). This worked without the explicit setNumDays() call.

I tried various things but couldn't get to the bottom of it - until finally I initialised the startDate field:

------------Plan.groovy---------------------
class Plan {
//...
Date startDate = new Date()
//...
}

With that in place the test works without the explicit setNumDays() call. Initial theory was that numDays was being set before startDate (I had assumed groovy would initialse in the order defined in the new() method call - but maybe not).

However, that doesn't seem to be the case. It doesn't matter which of the date fields is initialised, as long as at least one of them is. But it fails if neither is. Explanation? I'm really not sure...

Good service = profitable customers

2008-10-09T12:46:00.000-07:00

John Seddon has written some wonderful stuff on the application of Lean principles to service organisations. Of particular note is the link among efficient process, customer experience and cost of operation. It's a "cake and eat it" situation: efficient processes make for a good customer experience and low operational costs. Good service also contributes to top line performance: i.e. good service makes for profitable customers.

I had a perfect counter-example with my ISP this week. I'm with Virgin, who are generally OK as long as the system is running. Email has been intermittent recently, and went down again 2 days ago. I checked the online status page - which informed me everything was OK. I called the freephone status line which told the same story. My internet access was up, I could still access gmail, just couldn't get my virgin mail. So, I thought I'd let them know they had a problem. I called the reporting line, navigated the IVR forest, eventually arriving at the usual musical entertainment. After 5 minutes I gave that up and decided to look for electronic submission instead. Sure enough there's a form to submit, the contents of which are mind-numbing. Nevertheless, I persevered.

I got the usual immediate, automated response telling me they'd look in to my query. 2 days later I got the following message:

Thanks for getting in touch with the Virgin Media Support team.

We're sorry that you are having problems with your e-mails. To help with this we need to get your issue resolved by our colleagues at Virgin.net

In order for your support query to be dealt with efficiently, could you please click on the following link:

http://www.virgin.net/customers/contactus/

This will ensure that the correct team will receive your form.

The link points to another page from whence one may submit a query (quite how virgin.net and virgin media differ I have no idea - and to be frank, don't really care). So it took 2 days to register my complaint, generate a unique ID in their tracking system, and invite me to re-submit my issue. Why? I can't say for sure, but I'd stake the combined value of the UK banking system (or the loose change in my pocket, whichever is greater) on the following:

Virgin's customer service team have targets for responding to customer queries (the website states 48 hours)
My query was edging towards the target, so someone (or something) decided a response was needed.
So they sent me another stock email that didn't solve my problem, but hey it met the target - so that's good, right?

Well, no. It's not actually. At the start of the debacle I was mildly inconvenienced by the service outage. Not a major problem. But now I'm really irritated. Not only was the submission form ridiculously over-complicated, I've had 2 pointless, valueless emails from which the only message is "we haven't looked at your mail, but please feel free to re-submit again".

In other words: "this is a service call. There's no money to be made from service, so we won't really give it much priority".

Of course, had I wanted to upgrade my package, I could have called any of the numbers emblazoned on the web site and spoken to someone instantly (I tried, just to make sure). What Virgin don't seem to get - and they're by no means in a minority - is the influence of service on the customer relationship. Sales are key: cold calling, outbound marketing, lead generation systems, the list goes on. Service? That's a necessary inconvenience.

How wrong they are. Good service is a - maybe even the - key factor in a customer's propensity to terminate a relationship. Companies would save a lot more money by keeping their existing customers instead of spending vast resources attracting new ones. I was reasonably happy with Virgin before this debacle. I'm now researching alternative ISPs.

Update 3/2/09: I'm no longer with Virgin. I found another ISP who responded quickly and personally to my initial inquiries and were knowledgeable and professional. They managed the swap without fuss or problem and have been similarly responsive with a couple of service-related queries since. So good in fact, I recommended them to a friend who has similarly just moved there - from Virgin. Enough said. What's more, they're more expensive than Virgin were - considerably more than the reduced rate the Virgin adviser promised me if I stayed put.

(And final joy of joys: BBC iPlayer now works flawlessly. Wall to wall Top Gear!)

Erlang

2008-09-06T13:51:00.000-07:00

Just bought Joe Armstrong's book on Erlang and have started working through it. Erlang's an interesting language: although it's been around for years it's recently seen a sudden rise in popularity. Why the sudden interest? Concurrent programming. Moore's law is disintegrating for single core processors, and multi core/multi-processor machines are seen as the way forward. For those used to programming in traditional imperative languages (C, C#, Java, ...) multi-threading has always been difficult and error prone. Erlang was conceived from the beginning to support hundreds, thousands, even millions of concurrent processes, communicating with each other by passing messages. Armstrong contends this makes concurrency much, much simpler than trying to force it on top of the inherently sequential, shared memory model underpinning imperative languages.

Erlang is a functional language which, among other things, means it doesn't support mutable state. 'Variables' aren't; once assigned a value, it's not possible to re-assign a variable to a new value. So variables would be more accurately described as 'immutable single assignment references', although that's admittedly a bit less catchy.

As someone schooled in mutable state since Amstrad CPC464 basic, that's a violent, disruptive change to the mental model. In fact, it's a disruptive change for anyone used to observing the world around them as entities with properties that change over time: bank account balances that vary from day to day, people whose age increases every birthday.

It's a practical problem for functional languages too, since for most any program to be useful it needs to persist or change the state of the world around it. (That's why Haskell has its monad system).

Erlang supports programs that need to store, update and use mutable state; it has its own relational database system (Mnesia) which - since it's written in Erlang - is fully ditributable, concurrent and fault tolerant. Oh, and it doesn't need an object-relational mapping layer either since it's built to work natively with Erlang's type system.

I'm looking forward to getting into Erlang. The concurrent, message passing model is very appealing conceptually and offers lots of possibilities in the new multi-core world. But more than anything else in the book, I'm looking forward to getting my head around marrying the functional model with mutable state.

Textual Input / Graphical Output - the best of both worlds?

2008-08-22T13:42:00.000-07:00

Textual vs. Graphical representation was a recurring theme at this years Code Generation Conference. Thankfully, we seem to have moved beyond the “models are graphical, code is textual” misconception. The discussions were more focused on the relative strengths and weaknesses of each.

Arno Hasse and Sven Efftinge categorised it really nicely: graphics are best for visualisation, text is best for editing. There's been some work to integrate the two; for example, it's now possible in Eclipse to generate both graphical and textual editors that act on the same underlying model simultaneously. Marcus Volter has also demonstrated generating graphical visualisations automatically from models using a couple of auto-generation tools (graphviz and prefuse).

Outside of software development tools, this is nothing new: Autocad has for years allowed designers to create drawings with textual commands. Whilst users can draw directly on the canvas, they can also use a textual dsl enter commands - such as lineto(20,100) - with the results rendered graphically.

It would be good to think software tooling will catch on to these possibilities - and it looks like Openarchitectureware may be in the vanguard.

WebDSL and the missing abstractions

2008-08-22T13:34:00.000-07:00

“drinking from the firehose” must be on everyone's buzzword bingo all-time greats list. Nevertheless, it's a very apt description of how I felt in Eelco Visser's talk on WebDSL during the code generation 2008 conference.

The core subject matter has been occupying my thoughts in the last few months; there are myriad lightweight web frameworks around now, all of which offer easy definition of the core domain objects and most of which will generate a standard CRUD GUI. All good stuff. But move beyond the auto-generated GUI into something custom and you're on your own. It's down to hacking some form of web template language (JSP/RHTML/Django templates/...) and patching up the link to the domain model through controllers.

I'd been thinking there must be a better, higher level set of abstractions for describing the UI – which could in turn be mapped onto the underlying technology. WebDSL addresses exactly that problem. At least I think it does. There was so much good stuff in Eelco's talk that I couldn't take it all in. I'll need to dig deeper – but right now it looks promising.

Editing Generated code - an anti-pattern?

2008-06-27T00:33:00.001-07:00

In the 1970s, Ivor Tiefenbrun revolutionised the hi-fi world. Perceived wisdom held that, since the loudspeakers produced the sound, they were the most important part of the system. So, for a given budget, the largest portion should be assigned to the speakers.

Tiefenbrun disagreed. He believed the most important part was the input. Since the sound originated from the record (vinyl in those days), the most important component was therefore the turntable. So he invented the Linn Sondek, revolutionising the industry with a product that is still for sale today.

Tiefenbrun's lesson came to mind at the code generation 2008 conference in Cambridge – stimulating content in a fantastic setting.

During a discussion in Anneke Kleppe's session, a delegate asked about good practice for editing / modifying / augmenting generated code. The usual solutions came up (Generation Gap pattern, protected blocks) but for me the answer is clear: any kind of modification to the generated code is bad. It's an anti-pattern, there only because of deficiencies in the input and/or lack of customisation in the generator. It's often necessary, in many cases simply because the input language doesn't allow the full model to be expressed (this is true for most mainstream UML tools). But we should be striving to fix the real problem – insufficient or incorrect input – instead of trying to fix the symptom. We need to apply the 'Tiefenbrun principle'.

Agile and the pragmatists

2008-01-28T12:42:00.000-08:00

I listened to the Naked Agilists latest podcast the other day.

Brian Marick's pitch in particular sparked my interest. He compares agile adoption against Geoffrey Moore's technology adoption curve and observes a discrepancy; namely the seeming dearth of pragmatists. As I listened, a fundamental question immediately sprung to mind:

- Do we really have a case where the standard curve doesn't fit, or
- Are we looking at the data incorrectly?

Moore's curve is of course statistical and hence variation is to be expected. Nevertheless, I can't help wonder if there's something else going on.

Software projects can be viewed in terms of 4 dimensions: cost, time, quality and function (per e.g. Kent Beck in "Extreme Programming"). The software industry can also be split roughly into IT and Product Development (PD) - the difference being that IT delivers solutions for use within a business; product development builds products that are sold to the market.

I've worked in and/or experienced a variety of both IT and PD companies. Despite both being ostensibly focused on software delivery, there are some notable differences. In particular, there seems to a different bias on the 4 project dimensions:

- IT seems to focus more on cost and schedule;
- PD tends to focus more on function and quality.

I've some theories about why that might be, but will save for later - it's not relevant here. The interesting question is whether this difference in any way explains Brian's observation.

Here's my thoughts:

Agile primarily manages delivery of working software --> focuses on function & quality over cost & schedule
IT projects are often implementations of purchased products
The majority of Agile use is associated with building systems rather than implementing products
IT is generally more conservative than PD

Therefore:

Agile's lack of penetration into the pragmatist market is a consequence of the increased IT representation in that segment.

Some observations arising from that assertion:

What would the curves look like if we separated IT & PD? My gut feeling is each would more or less follow Moore's model. Agile probably has crossed the chasm for PD; and the size of the segment is probably in line with Moore's curve. Agile in IT is however much earlier in the lifecycle, and crucially hasn't crossed the chasm yet.
For agile to cross the IT chasm, two things are required:

There needs to be much more support for agile product implementation to complement that for agile system building
It needs to be presented in a way that resonates with people whose primary focus is cost and schedule over function and quality. That means IT project/programme managers brought up on a diet of MS Project and interpreting PRINCE2 as a waterfall process.

I'm aware the assertions above are based on a very narrow - and therefore statistically insufficient - sample. I know, for example, of at least two IT organisations locally who've embraced agile principles. Thoughts and comments welcome.

UML vs. Domain-Specific Languages - a false dichotomy?

2007-07-21T12:39:00.000-07:00

I have just listened to the panel discussion at code generation 2007 entitled UML vs. Domain-Specific Languages - a false dichotomy?

It's very interesting. The panel includes some very well known luminaries from the modelling world (e.g Steve Cook) and some less well know but equally capable (such as Tony Clarke of xactium).

Perhaps the heart of the discussion is given over to the subject of modelling versus programming languages. This is something I've come across in various contexts, where the following views are not uncommon:

"Modelling languages are for drawing pictures, you build software with programming languages"
"If it's graphical, it's a modelling language; programming languages are textual"

Both views are as understandable as they are wrong. Promulgating them is perhaps the most heinous crime of the uml juggernaut. Even today, Grady Booch - one of the uml's originators - maintains it should be used for sketching things out; clarifying your thoughts before writing code. There are plenty of others who also support the view (e.g. Scott Ambler).

As a result the majority body of opinion equates uml - and therefore graphical notation - with sketches. Something that precedes the real work (coding).

That's a great shame - and baseless. In other industries (mechanical engineering and construction for example) graphical notations are standard. Not for sketching, but as the normative specification. The code if you like.

Graphical notations can be used in software too. Some companies have formalised a subset of the uml into a language that is precise, executable and graphical. Conversely this post is textual - but definitely not executable.

Abstract Syntax, Concrete Syntax and Semantics

UML 2.0 wasn't all bad. One of the good things it popularised was a way to look at languages as consisting of three parts: abstract syntax, concrete syntax and semantics. (I prefer to name them concepts, representations and meanings, but that's personal preference):

Concepts (or Abstract Syntax) are the things we want to talk about: 'Cars', 'Accounts', 'Dogs', 'Equations', whatever.
Representations (or Concrete Syntax) are how we depict those concepts; textual, graphical, aural, olfactory...
Meanings (Semantics) are, well, what we mean when we discuss concepts.

It's often difficult to separate representation from concept, since we can only communicate concepts by giving them representation. Using different representations for the same concepts is so intrinsic to our way of life we don't even notice it. (Imagine the confusion if we didn't know the sound 'car' referred to the same concept as the word 'car').

But analysing languages in terms of their concepts, representations and meaning provides a useful framework for classifying languages.

So is UML vs DSLs a false dichotomy?

Let's consider it from the 3 perspectives.

Concepts. At its (most useful) core, the uml is intended for describing concepts, their relationships and behaviour. So its concepts - classes, relationships, states, events, etc. - are those useful for describing other concepts. The concepts in a DSL are, by definition, specific to the domain in question. So perhaps Dogs, Breeds and Owners in the domain of pedigree competition. Is that a dichotomy? No. Just a different focus. In fact the raison d'etre of UML's core is to enable description of other domains. The uml is, in effect, a DSL for describing other domains.
Representations. UML ascribes a graphical notation to many of its concepts - perhaps most obviously the boxes and lines in class diagrams or state charts. Many would argue - and with good cause - this is in fact the most useful thing about UML. DSLs usually enable a representation appropriate for the domain. It might be graphical (perhaps an image for each dog appropriate to its breed), symbolic (the extended alphabet used in mathematical equations) - whatever suits the problem. Is that a dichotomy? Again, no. However it does expose a limitation in UML, in that it doesn't explicitly allow for representations to be ascribed to concepts described in a UML model.
Meaning. The semantics of UML is a subject of life study, not a paragraph in a blog. Despite its supposed formalisation, UML does not have a precise semantics in any useful meaning of the term. That belies its origins as a sketching tool. While some have divined a precise subset it's been done despite the language rather than because of it. DSLs, by comparison, assume that the results of modelling will be machine processed: translated into some other executable form or interpreted directly. Is that a dichotomy? Fundamentally yes. Those are two very different philosophies.

So UML and DSLs do share significant properties. DSLs extend UML in their support for domain specific representation, but it's an extension rather than a conflict. Were UML to allow the assignment of domain-specific notation to the models this difference would disappear.

Where the two fundamentally differ is on semantics. As long as the majority influence on UML supports the standpoint of a sketching toolkit, the dichotomy will remain. There will continue to be those who provide a formal semantics for some subset of uml and in such cases there is no real dichotomy; however those are the exception and not the rule.