Model-driven Development with Executable UML models

Last November I did a lecture on Model-driven Development with Executable UML models to a class of Software Engineering undergrad students at UVic. Here are the slides:

I think it gives a good summary of my views on model driven development (with Executable UML or not):

  • even though problem domains are typically not very complex, enterprise software is complex due to the abundance of secondary crosscutting concerns (persistence, concurrency, security, transactions etc)
  • there are two dominant dimensions in enterprise software: business domain concerns and technological concerns
  • they are completely different in nature (change rate, abstraction level) and require different approaches (tools, skills, reuse)
  • MDD is a strategy that handles well that divide: models address business domain concerns, PIM->PSM transformation addresses technological concerns
  • brainstorming, communication, documentation and understanding (rev. engineering) are not primary goals of MDD – to produce running code in a productive and rational way is
  • models in MDD must be well-formed, precise, complete, executable, technology independent
  • graphical representations are not suitable for executable modeling (textual notations are much better)
  • diagrams != models, text != code (that would look good on a t-shirt!)

I guess those who know me won’t have seen anything new above (these ideas make the very foundations of the TextUML Toolkit and AlphaSimple).

Do you agree with those positions?

EmailFacebookLinkedInGoogle+Twitter

10 thoughts on “Model-driven Development with Executable UML models

  1. Damien Cassou

    February 7, 2011 at 3:44am

    That’s an interesting point of view. However, as models are diagrams and diagrams are required for “brainstorming, communication, documentation and understanding (rev. engineering)”, how would you link both sets of diagrams (models and documentation)?

  2. rafael.chaves

    February 7, 2011 at 8:56am

    Hi Damien,

    > However, as models are diagrams and diagrams are required
    > for “brainstorming, communication, documentation and
    > understanding (rev. engineering)”

    My point above was that “models are *not* diagrams“. Do you mean: “as models *may* be exposed as diagrams”?

    > how would you link both sets of diagrams (models and documentation)?

    Models for MDD can include documentation (just like Java code has javadoc) so one can automatically derive diagrams suitable for communication/documentation from them. For instance, check the “Model Diagram” tab for:

    http://alphasimple.com/project/show/276

    (but maybe I misunderstood your question)

  3. Damien Cassou

    February 8, 2011 at 12:29am

    >> However, as models are diagrams and diagrams are required for
    >> “brainstorming, communication, documentation and
    >> understanding (rev. engineering)”

    > My point above was that “models are *not* diagrams“. Do you
    > mean: “as models *may* be exposed as diagrams”?

    I thought that even if “diagrams != models”, “models => diagrams”
    was still true. I was wrong, sorry. (it looks like I forgot what
    I recently read about TextUML and Alf)

    Your rephrasing is correct though.

    >> how would you link both sets of diagrams (models and
    >> documentation)?

    > Models for MDD can include documentation (just like Java code
    > has javadoc) so one can automatically derive diagrams suitable
    > for communication/documentation from them. For instance, check
    > the “Model Diagram” tab for:
    > http://alphasimple.com/project/show/276 (but maybe I
    > misunderstood your question)

    Ok, now I understand. However, if your model is suitable for
    execution, I guess parts of it are unadequate for documentation.
    For example, in the project you reference in your reply, I may
    not want to see the Unit.clone() operation in the documentation
    diagram. How would you restrict documentation diagrams to only
    show interesting parts of the model?

  4. rafael.chaves

    February 8, 2011 at 12:37am

    Thanks for clarifying, Damien, now I think I fully understand what you mean.

    That is an interesting point. I guess one could filter what kinds of elements to include in a diagram generated for documentation (by convention). For instance, omit non-public elements.

    In the case of Unit.clone(), I think that method should have been modeled as package private. We don’t want the prototype to expose that either. Does that make sense? Do you see a caveat with doing that?

  5. Damien Cassou

    February 9, 2011 at 3:00am

    That makes perfect sense, thanks for the explanations. A possible problem could arise when you want to have multiple documentations for different stakeholders: you may want to show/hide different elements.

  6. Andreas Graf

    April 25, 2011 at 10:32pm

    Re: Multiple documentations. Not really a problem, this is one of the reasons we are using models: Different views on the model. Either by direct tool support or m2m transformation.

  7. Damien Cassou

    April 26, 2011 at 11:32pm

    @Andreas: I don’t really see how this could work. You would have one view for each different stackeholder’s role? Who takes care of maintaining these views? Do you have real case studies in which this is done?

    • rafael.chaves

      April 27, 2011 at 8:03am

      @Damien I’d like to hear about Andreas’ experience as well, but I will pitch in on this one.

      Have you read the MDA Guide? It’s short, and it is oldish, but still is my #1 reference for MDD:

      The MDA Guide talks about “markings” and “additional information”, which are things external to the PIM that allow driving transformations.

      Speaking more concretely, imagine that a tool that automatically renders diagrams (views) from models. This view will imply choices on what is included and what is left out. Imagine that those choices are configurable. For instance:

      - based on the kinds of elements: only classes and relationships, or include attributes, but not operations, or only state machines.

      - based on stereotypes: only classes marked as <<Entity>> (and their related <<ValueObject>>), or only elements from packages marked as <<Business>>;

      - based on the PIM: only elements of packages named “*.business.*”, or something very particular such as everything directly related to the “Order” class.

      IOW, one can define views that are useful for a particular viewpoint and yet don’t have to be tightly coupled with the model at hand, so they will continue to be valid as the model evolves.

      Similar strategies can be applied when generating code (the “views” apply architectural patterns in that case, driving code generation).

Comments are closed.