I’ve had the chance to look over a draft version of the new MDA Foundation Model. This foundation model provides formal model for all basic concepts involved in a MDD/MDA approach to systems development. In particular, it defines the concepts of model, metamodel, transformation,… and the relationships between them.
This formal model is expected to be the basis for the revised version of the current MDA Guide now more than 6 years old.
The first thing I should say IS that I’m very happy with this initiative. It was time that all concepts used in MDA had a more “formal semantics” and “precise” definition.
The bad news is that, IMHO, this foundation model still needs a fair amount of work to be ready. Just to mention three issues, 1 – the model concept itself is not that clear (a UML class diagram and a UML Sequence diagram modeling the same system are one model or two? if two, how to represent the relationships between the two?), 2 – metamodels are simply defined as sets of metaelements (where metamodel is a subclass of the model class and metaelement a subclass of the element class), which is a too simplistic view of metamodels (i.e. a purely syntactic one, lacking of the semantic information allowing to correctly interpret the models instance of those metamodels) and 3 – Views can only contain a subset of elements of a single model (I think it would be useful to have views aggregating elements from several models).
Hopefully, the OMG will decide to release soon a (improved) first version of the draft so that all non-OMG members can give our opinion and help preparing the upcoming MDA 2.0. standard (until then, you can check some initial sketches of the foundation model here ).
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
Great…more stuff to read…
I’m a BIT worried about your statement regarding models. But THEN, even UML IS a BIT vague about them (a package WITH a _textual_ viewpoint?) – AND UML IS ALL about modeling! What would you consider a “model”?
I agree WITH your (2). Hopefully, that will GET resolved.
And your (3) goes back TO the definition OF a model.
I guess I’ll have to go and have a look now…
OK…So I was just too curious and I had a look at 09-03-02, which is _very_ incomplete. It does, however, have a definition of model that it close to what is in UML.
Or where you looking at 05-04-01, which is fairly old and very vague?
> a UML class diagram and a UML Sequence diagram
> modeling the same system are one model or two?
> if two, how to represent the relationships
> between the two?
Diagrams are just views to models. A single model can be depicted by several diagrams, of the same or different type. Relationships between diagrams occur through the model itself. The model is agnostic to the views and elements that appear in class and sequence diagrams are all first class citizens in the model. This post might be of interest:
http://abstratt.com/blog/2008/09/10/diagrams-models/
Cheers,
Rafael
I am looking AT the new one but still, the definition OF “model” seems a little BIT ambiguos TO me. I’d like to “type” the models and define that a system is specified through a set of models (static models, a behavioural models,…) . With the current definition we could model the complete system with a single model composed of very different kinds of model elements (e.g. a class and a state transition) where these different model elements would not be grouped together according to their kind.
Maybe the idea is to use viewpoints and views for that. Let’s see how this part OF the foundation model develops IN the future
Thanks for the link!
I should clarify that when I talk about diagrams I’m thinking IN “useful group of model elements that make sense altogether”. FOR instance, a GROUP OF class, association,attribute,generalization… instances give a particular VIEW (a static VIEW) OF the system.
Therefore, I think it IS interesting TO predefine OR “type” groups OF elements that we feel useful so that we can talk about the static model OF the system, the behavioural model,… AND we ALL know the kinds OF elements (AND knowledge OF the system) we can expect IN each OF those models/views/groupsofelements.
Let’s see if this is exactly the purpose of the concept of views and viewpoints sketched in the draft.
The ongoing discussion we are having with this post prompts me another question:
assuming that we can model the complete system using the same modeling language (i.e. the same metamodel), should we just use one big model for the whole system (and use views to show subsets of this model) or is it still useful to specify the system using more than one model (and if so, should we be able to “type” those different models?)?