Those omniscient users

Despite repeating it in my courses every year, I end up getting this error from at least 10 – 20% of the students at each exam session.

When drawing the class diagram of a software application, they invariably add a User class (call it the role you want: customer, admin, professor, director, clerk and so on) and then they add the list of actions that the user can perform in that class, instead of putting them in the classes they pertain to.

So, for instance if you want a method for paying a ticket of a flight, the payTicket() method ends up in the user class!

If you have any doubt that this is correct just think that then:

  • you should put all the method triggered by user choices, in user classes
  • to invoke that action from a caller method you should do it through the user class. Something like:  JohnDoe.buyTicket()
    While the right approach should be: myTicket.buy()

Attribution of actions / objectives to users is something you do at requirement specification level (e.g., when defining goal diagrams, use cases or scenarios), not at design level.

Sufficiently advanced software development methodology

I’ve been intrigued today by a bold tweet by Meinte Boersma (see his blog to know more about him and his activities)

Any sufficiently advanced software development methodology is indistinguishable from model-driven.

Meinte, I personally fully agree with you. Being also an advocate of Model driven development (and model driven in general, as this blog’s title demonstrates), this is not surprising at all.

This also opened up a new line of discussion, on whether MD* should be named a methodology at all or not.
Personally, I’m again with Meinte and I would say that MD* is much more than a bunch of tools. I think it is actually a methodology, or even more an overall way of thinking. If we want to delve into it: I think it’s a way to make explicit how we should think.

But real question as I see it is :
why can’t an advocate of any discipline state the same it for its own approach?
(e.g., development approaches like: Agile, Lean, test-based, search-based, …)

My response:
MDE is actually in a much better position, because it’s a way for formulating, stating and formalizing ways of thinking that are inherent with the human way of seeing the world (i.e., abstraction). That’s why MDE / MDD advocates can actually say that advanced software development methodology is indistinguishable from model-driven.

What’s your response?

Let’s discuss them all here!

[Incidentally, this is my post #100 on this blog! Thanks to all of you readers and contributors]

To keep updated on my activities you can subscribe to the RSS feed of my blog or follow my twitter account (@MarcoBrambi).

Bruce Silver’s keynote speech at BPMN 2011 workshop: interoperability and other issues in BPMN and UML

Today at the BPMN 2011 workshop in Luzern, Bruce Silver gave an interesting talk on the status of BPMN 2.0, its adoption, and his proposal for improving its general usage.
I really appreciated the talk because:

  • it focused on the ambiguities of the BPMN notation, even in the so acclaimed 2.0 version
  • it highlighted how users tend to be confused once the notation is so complex.

Bruce presented his well-known approach, with the caveat that probably method and style is too weak as a position, so he proposes to move to the rules term, so that people feel somehow more obliged to comply 🙂 .

    The first issue I take away is the problem of interoperability.
    I would also identify a trend on what I heard here, through a parallel to what is happening in OMG within the Canonical XMI initiative (read something here), performed by the Canonical XMI Finalization Task Force: given a modeling language (or an exchange format like XMI) which is under-specified, too general, or too open for dialects generation, the need arises for putting some stricter limitations to the designers, for making the tools more interoperable and for improving the quality of the models. Interoperability is the explicit aim of XMI, but, since it failed to an extent. Probably the same would apply to XPDL itself: it was designed as an interchange format for business process models, but then ended up being prone to several dialects and interpretations as well. For XMI, the improved interoperability aim is now in charge of Canonical XMI (while no action is being taken on XPDL).  The same purpose is addressed by the BPMN-I initiative by Bruce Silver.

    A similar problem that has been addressed is executability:
    Also on this, I see strong parallelism with the UML world. There is definitely a push towards executability of models: just think about the executable UML fUML and Alf initiatives (you can find a nice overview on both on Jordi’s blog here), at OMG or also some new activities like MiUML, an open-source executable UML project.
    On the other side, also BPMN 2.0 is addressing executability and within WebRatio we are also providing somehow a pragmatic approach to BPMN executability, by generating running Web applications. The question is: are customers asking for that? The claim by Bruce is that they are not for BPMN. Most people only want to model, not to execute. Probably, if you look at the share of interested people, for UML it’s the same. However, I think executability is an interesting property that should be granted to give a general grounding to reality to models (although I acknowledge that some models may not need/allow that).

    A final take from the day is related to choreography.
    Interestingly enough, again people are not using it: neither in the BPMN world nor in the UML one. I don’t have stats on the usage of the different kinds of UML models, but I’m pretty sure people only use class diagrams basically. Some will use activity diagrams, and few sequence diagrams. Anything else?

    Bruce Silver, with Bruce Silver Associates,
    presenting his keynote at the BPMN 2011 workshop.

    To keep updated on my activities you can subscribe to the RSS feed of my blog or follow my twitter account (@MarcoBrambi).