Controversy at Code Generation 2007

Several members of our team will be at Code Generation 2007. I'll be on a panel session on 19th May.  Here's the abstract:

Standardised modelling languages, such as OMG UML and its younger cousins SysML and BPMN, emerged from the melee of competing modelling languages available in the mid-1990s. By creating widely used notations for common modelling concepts, these standard languages have made software modelling a mainstream activity supported by dozens of excellent tools. However, the Domain-Specific Language movement has a long and honourable tradition, recently given renewed impetus by Microsoft's support for DSLs in its Visual Studio tool set. DSL advocates argue that designing a modelling language specifically for a particular application domain allows clearer and more precise models than using a standard language. So who is right? When do the benefits of bespoke domain languages outweigh the advantages of using universally understood notations? Are the two approaches really in competition, or can they co-exist? Our panel of DSL and UML experts will lead the debate.

So what makes BPMN the "younger cousin" of UML?  The OMG's BPMN specification (which I notice is only available to members on the OMG site but freely available on the BPMN site) is defined in a completely different way (no metamodel), and has massive conceptual overlaps with areas of UML without any effort to integrate.  I guess that makes UML the younger cousin of CORBA.

Comments (3)

  1. Scooter says:

    Suppose I see it slightly differently.  It’s not domain specificity per se that differentiates the DSL approach from UML – it’s the attitude to model purpose and its resultant impact on precision.  UML was always founded on the principle of producing informal sketches.  DSLs in contrast have generally been focused on formal descriptions from which other formal assets – such as code – can be generated.

    It’s eminently possible to produce a formal but domain neutral language from which other formal assets can be generated.  That’s what programming languages are after all (and also the approach Steve Mellor & Sally Shlaer tried in vain to promulgate against the weight of the 3 amigos).

    That’s not to say DSLs don’t bring anything to the table of course.  Domain specific syntax and a focus on domain separation are both extremely valuable.

    WRT BPMN conceptual overlap, fully agree.  The UML now is a mess of a language; poorly abstracted, too imprecise (despite an encyclopedia’s worth of OCL) and with huge areas of non-integrated conceptual overlap.  

    Kind of a recursive proof of its own problems really; if you don’t start with precision and conceptual economy then you end up with overbloated imprecision.  And given that UML makes a big thing about being defined in UML…

  2. Murray Spork says:

    Re BPMN – my understanding is the BPDM will be the metamodel for BPMN

    Agree that this is seems a bit messy at the moment though – the easy part was defining a notation. They hit the difficult stuff now – trying to figure out the abstract model and semantics (is the mapping to BPEL normative?) and do that in such a way that keeps all the stakeholders happy (as you intimate – what is the formal relationship between BPMN and Activity Diagrams?). Seems like it could be an impossible task.

    Regardless – I think BPMN is gaining a lot of traction in industry – at least as an analyst’s notation. That would be fine if that was all it was intended for – problems come when they proclaim it to be a notation for executable processes as well.

Skip to main content