Daniel Moody on "Designing diagramming notations that work": the physics of notations

Daniel L. Moody from University of Twente gave a talk (and a full fledged tutorial) at OMG technical meeting in Reston, VA, on the principles for designing effective diagramming notations. His talk had this overall design:

(click to enlarge)

Daniel Moody wrote a famous paper on IEEE Transactions of Software Engineering titled:

IEEE TSE. November/December 2009 (vol. 35 no. 6). pp. 756-779

Program flow charts have been invented long time ago, in 1947.
Visual notations are effective communication tools because they rely on the highly parallel way of reasoning an processing signals of the human brain.
Therefore, they should be optimized for human mind processing. It’s not something that can be designed based on opinions. There are ways of measuring and proving results.
The measure of optimization is cognitive effectiveness. Effectiveness of existing notations is hampered by:

  • unclear goal of the notation
  • low attention to this aspect
  • lack of accepted design principles
Notations like ER diagrams expose significant flaws, but is accepted and preserved with no questions. UML has the same problem. In general, another point is that in current notations there is no motivation on why one choose one symbol or another for model elements. In other words, there is no rationale for design of notations. Basically, we are still in unselfconscious design culture (more or less the same as the way huts are built by primitive people: there are no architecture principles or books, the just build huts).
The same symbols are used again and again within the same language and across languages (e.g., think about the rectangle symbol).
There is lack of testing and principles. That’s why Moody proposes a set of objective principles based on scientific observation.
Out of that, he proposes a clear manifesto for design notations:
  1. At least equal effort and attention for notation and content
  2. Have a design rationale
  3. Decision must be based on evidence
  4. Design must be based on objective principles
  5. There must be explicit testing of the notations (user studies)

The purpose is to move diagramming from art to science.

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

My new book on Model-Driven Software Engineering

Model-Driven Software Engineering in Practice. Book cover
Model-Driven Software Engineering in Practice.
See more on www.mdse-book.com.

I’m really proud to announce that a huge joint effort with Jordi Cabot and Manuel Wimmer has finnally reached his end. Our new book on model-driven software engineering, on which we have been working for almost one year, is finally published!

First of all, I wish to extend my thanks to my coauthors for the wonderful teamwork and to Richard Soley, OMG Chairman, who accepted to write the foreword of the book. I actually found it one of the most inspiring outlooks on the field I’ve read.

The book discusses how model-based approaches can improve the daily practice of software professionals. Model-Driven Software Engineering (MDSE) or, simply, Model-Driven Engineering (MDE) practices have proved to increase efficiency and effectiveness in software development, as demonstrated by various quantitative and qualitative studies. MDSE adoption in the software industry is foreseen to grow exponentially in the near future, e.g., due to the convergence of software development and business analysis.

The aim of this book is to provide you with an agile and flexible tool to introduce you to the MDSE world.

This allows you to quickly understand its basic principles and techniques and to choose the right set of MDSE instruments for your needs so that you can start to benefit from MDSE right away.
As such, the book is not addressing only the hard-core software modelers, but also BPM practitioners, enterprise system consultants and analysts, and so on. Indeed, the book is targeted to a diverse set of readers, spanning: professionals, CTOs, CIOs, and IT team managers that need to have a bird’s eye vision on the matter, so as to take the appropriate decisions when it comes to choosing the best development techniques for their company or team; software and business analysts, developers, or designers that expect to use MDSE for improving everyday work productivity, either by applying the basic modeling techniques and notations or by defining new domain-specific modeling languages and applying end-to-end MDSE practices in the software factory; and academic teachers and students to address undergrad and postgrad courses on MDSE.

The book is organized into two main parts.

The first part discusses the foundations of MDSE in terms of basic concepts (i.e., models and transformations), driving principles, application scenarios and current standards, like the well-known MDA initiative proposed by OMG (Object Management Group) as well as the practices on how to integrate MDSE in existing development processes.

The second part deals with the technical aspects of MDSE, spanning from the basics on when and how to build a domain-specific modeling language, to the description of Model-to-Text and Model-to-Model transformations, and the tools that support the management of MDSE projects.

In addition to the contents of the book, more resources are provided on the book’s website we are currently setting up. There you can find the detailed TOC, the sources of the examples presented in the book, and the teaching materials we will build to support training activities based on the book.

If you want to buy the Model-Driven Software Engineering in Practice book, you can find it on Amazon or on the Morgan&Claypool website (printed and electronic versions available).

If you read and like the book, we will be glad if you post a review on Amazon!

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).

    Ed Seidewitz tutorial on Alf and fUML at OMG tech meeting, Arlington, VA, March 22, 2011

    These are my notes on Ed Seidewitz tutorial on Alf and fUML at Executable UML info day at today’s OMG technical meeting.

    Alf aims at allowing to program in UML, without bothering to go back and implement at low level things that are specified already at the design level.
    The role of Alf is to provide the missing details that cannot (or are very expensive to) be captured graphically by UML.
    The good thing is that Alf works at the same semantic level of the UML models.

    The picture will be:

    •  fUML = Executable UML Foundation
    •  Alf = Executable language for UML

    Versions will be shortly aligned so that: Alf will be based on fUML 1.1, which is a proper subset of UML 2.4 (and on its semplification UML 2.5 planned for end 2011). 
    The formal foundation of the executable models is specified based on First Order Logic (FOL) .
    The role of Alf is to provide a Java-like syntax that can be familiar for developers/designers. However, the surface syntax actually enables dataflow-based semantics.
    At resources naming level, Alf adopts the UML naming rules (you can have spaces in names; names are case sensitive; and so on. So names may need single quotes for containing the names).

    Several tricks need to be applied to actually design (even fairly simple) activity diagrams. For instance, you cannot have indeterministic semantics when you have outgoing outgoing data flows that land into several activities. A split node must be inserted, and thus the single token is copied into several ones. Or other peculiar cases, like the need of control+dataflows incoming in conditional nodes that produce only control flows. Or you may need to use datastores for multiplying incoming tokens. Or you may need implicit ouptup/input mapping in looping activities. Or to use parallel split for modeling ifs.
    Within activities you only have one scope, while stack of calls is relevant only among activity invocations.
    Alf does not constraint sequentiality. Parallel execution is allowed as soon as there is no dependency between activities.
    Some other critical syntax issues: array indexes start from 1 (as in UML), not from 0 (as in main programming languages); and then details on structural feature actions, comparison with null (equivalent to checking if an item is empty or not empty)
    In fUML an abstract operation has 0 methods, a concrete operation has only 1 method.
    fUML provides reified semantics for associations.
    Standard UML @Construct and @Destroy annotations are interpreted correctly.
    Receptions are optional in UML but are mandatory in fUML if you want an object to receive a signal.
    Profiles and stereotypes are currently not part of the fUML .

    And btw, the hello world example for Alf is:

    activity Hello(){
        WriteLine(“Hello World!”);

    Seems quite easy! 🙂

    The tutorial was given as part of the Executable UML Information Day at the OMG Technical meeting in Arlington, VA, on March 22, 2011. The full program of the day is available here:

    The official Alf specification is here:

    Disclaimer: This post is just a set of notes I took during the tutorial, it’s not meant to be complete or comprehensive, but I think it can provide a good understanding of the critical points.A more comprehensive post (by Ed himself) together with significant links is available here:

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

    Stephen Mellor tutorial on Executable UML at the OMG meeting, Arlington, VA, March 22, 2011

    “Models that don’t execute are like cars without engines”.

    Executable Models implement wrt 3GL the same paradigm that 3GL implemented through compilers or interpreters.

    The model is the system, it’s not something you should maintain or keep aligned separately.
    Executable models help reduce errors (at least of 10%, according to estimates), but most importantly they help to find the errors earlier in the development process, which is the actual critical advantage.

    One of the critical issues is interoperability between modeling tools. A common metamodel for Executable UML must be defined, so that

    The executable UML foundation is defined based on:

    • definition of the executable subset of UML (taken the entire UML metamodel, a subset of it is selected and defined as executable)
    • definition of execution semantics (defined using Executable UML itself)
    • a base semantics (mainly based on FSM and other mathematic model)

    An action language has been defined for foundational UML: it’s a Java-like syntax, with a dataflow underlying semantics (which grants more parallelism, …).

     A few issues need to be addressed, as highlighted during the discussion session: educational issues (make learners approach executable UML as their basic interface with programming, instead of other lower-level languages); integration with existing code, libraries, distribution, and so on.

    Disclaimer: This post is just a set of notes I took during the tutorial, it’s not meant to be complete or comprehensive, but I think it can provide a good understanding of the basic philosophy underlying Executable UML.

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

    Posts on BPM and UML interaction

    Here are the responses I gave on Jordi Cabot blog (www.modeling-languages.com) on the issue of business process modeling and of the new CFP for a UML profile for BPMN.

    Mixed feelings – but clear understanding Submitted on Thu, 09/16/2010.

    I have mixed feelings about this issue: first, about the objective of the move; second, about the advantages it will bring; and third, about the relevance of the discussion.
    1) Objective:
    If the target is to flatten all the modeling to just one notation and role(the software engineer), then this is definitely a wrong direction.
    BPMN and UML have two different focuses (business and software) and are used by different roles (analysts and softengs). We should not forget this… even more: bpmn itself is now perceived as not fully understandable by its target users.
    2) Advantages:
    Supposing we keep in mind the two focuses, the advantages
    of the proposal above could be to allow the orthogonal design of different aspects of the applications by different roles, also granting integrated design of the different orthogonal aspects in a unified design vision (old story on separation of concerns).
    3) Relevance:
    Well, to be honest I don’t see the discussion as so relevant. In the bpm field the notation issues are more and more seen as marginal aspects (someone is already wondering what will be the fate of BPMN 2.0). I don’t see why we shouldn’t start doing the same in the softeng community.
    In term of acceptance and utility of modeling notations, you can see the some lessons learned from our on the field activities here:

    Rules for BPM(N) modeling Submitted on Mon, 11/08/2010

    For methodological guidelines see also the online decalogue by Bruce Silver Associates:
    And also this paper by Michael Zur Muehlen on empirical analysis on the usage of BPM modeling languages (basically more or less a Pareto Rule for moveling languages concepts: less than 20% of the notation and patterns covers more than 80% of cases, or even more):
    This is in line with our experience too.