Thu Sep 24 10:39:42 CEST 2009

MARTE & UML modeling

( Important: do not confuse MARTE[1] with MARTES[2]. )

First, what makes my toe itch?  When I hear ``model'' I think of
mathematical model: something that can be handled with mathematical
(logic) tools, i.e. equations / relations: formal languages that can
be equipped with some well-defined relations to other objects
(semanitcs, implementation, ...).  The essential idea is that you can
make your model _interact_ with something.  Another model type that
has this property is scale models: here you use physics instead of
mathematics to interact with a scaled down prototype.

The cool thing about _mathematical_ modeling is that you can have a
weird bunch of people called logicians and mathematicians figure out
how to build a meaningful structure (once and for all), and map it to
your problem domain.  I.e. as engineer, you keep an intuitive view on
the modeling, but can rest assured that the substrate works, and that
you don't loose relational power between different abstraction layers
due to ill-defined concepts.  The mathematical construct used as
modeling language is an API for your ideas, without degrading into

In UML-lore, modeling is more about providing a basis for
communication and understanding, not necessarily using mathematical
tools (or physical) interactions.  I.e. the _interaction_ part is
mostly about software engineers talking to each other.

From the tutorial[3]:

  ``A model without its meta-model has no meaning.''

This translates to: the language (meta-model) you use to construct the
description (model = instance) needs to have a semantics, i.e. it
needs to be precisely linked to something that has meaning in some
well-understood way (i.e. a mathematical structure, physical law,
general belief, ...)

In the slide ``A Bit of Modern Software'' p.13 the question is posed:
``Can you spot the architecture'', wrt to a page of SystemC code that
links a producer and a consumer as part of an imperative program.  The
next page has the UML diagram.  In an FP approach, one would use
higher order functions or staging to combine both the diagram and its
implementation in the same source code (i.e the diagram _is_ the code).

A profile[4] is essentially a DSL: a set of high level primitives and
combining forms that compile to a lower level implementation.

This all smells so similar to FP/logic, to a point where mapping
between the two representations should be feasible.  This reminds me a
lot of the OO patterns approach: because the OO model itself has so
little structure, one _imposes_ structure trough interface patterns
with implicit meaning.  UML seems to try to add some meaning to such
interface patterns in terms of code generators.

Some heated comments from the Haskell list[5].  The thread contains a
link to Rosetta[6], a system level modeling language.

My conclusions: 1. as long as semantics isn't clear (a function from
syntax to some implementation: a compiler) this makes no sense at all.
2. too much rooted in object-oriented view of the world.

If there are compilers, then probably a meta-programming framework can
embed the ideas (interface _to_ OO/UML for tool integration but, don't
use it as a base in tools themselves).

I'm going to leave it at this humorous note [7].

[1] http://www.omgmarte.org
[2] entry://20090922-141319
[3] http://www.omgmarte.org/Tutorial.htmZ
[4] http://en.wikipedia.org/wiki/Profile_(UML)
[5] http://www.mail-archive.com/haskell@haskell.org/msg18185.html
[6] https://wiki.ittc.ku.edu/rosetta_wiki/index.php/Main_Page
[7] http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html