Re: knowledge distilled from the UML 2.0 infrastructure

Date view Thread view Subject view Author view Attachment view

From: Andy Evans (
Date: Mon 09 Jun 2003 - 21:01:08 BST

I think an important insight that was gained when both U2P and 2U attempted
to design the infrastructure and superstructure models in a more reusable
way, was that existing class based approaches to reuse were too fine grained
to support the practical design of large scale language definitions. Hence,
the development of package extension and merge mechanisms that aimed to
allow chunks of model abstractions to be extended and merged through the
combination of packages.

In the U2P approach, it was decided that package merge should be defined in
terms of class inheritance, hence the large inheritance tree you see today.
2U took the approach that such a tree should be flattened, thus resulting in
a more compact model. Both approach have their advantages and disadvantages
though. Inheritance based approaches result in large unmanageable trees,
whilst flattening tends to loose information about the design motivation
behind a model.

I think more work needs to be done on this very important topic. If we are
to meet the needs of MDA, we cannot afford to spend 2-3 years designing
language meta-models again. They should be quickly built from pre-existing,
large grained reuse libraries, and checked using tools.

As a side plug - York University are holding a workshop on meta-modelling
for MDA, where we hope to encourage debate on just this topic. All
contributions welcome (see below) !


Metamodelling for MDA
First Call for Papers
November 24th - 25th
York, England


The OMG Model Driven Architecture (MDA) promises to be a revolutionary step
in software engineering, by making models primary artefacts and thus
raising the level of abstraction in the software development process.
Whilst a lot of focus has been given to the transformation of
platform-independent models to platform-specific models, the scope of MDA
potentially covers the modelling of all aspects of a system throughout its
lifecycle. Metamodelling provides the foundation for this vision, by
enabling meaningful metamodels of languages to be defined precisely and
unified in a consistent framework. To this end, the OMG's Meta-Object
Facility (MOF) is stipulated as the language in which all languages for MDA
are expressed. As another iteration of the UML revision process nears
completion however, many issues have been raised concerning the means by
which MOF is applied, such that languages constructed to support MDA are
reusable, flexible and meaningful. This workshop then aims to investigate
the fundamental principles, tools and techniques that are needed for the
metamodelling of languages, in order to provide a foundation for MDA and
the long-term future for the role of modelling in software development.

Scope & topics

This two day workshop is aimed at anyone within industry or academia who
recognises that MDA is founded upon rigorous metamodelling. The workshop
seeks to explore the theories, principles and practice by which language
metamodels are constructed, transformed, related and used to support MDA.
It also aims to highlight lessons that have been learned from putting these
theories and principles into practice, and investigate the next generation
of tools that are needed to fully realise the MDA vision. It is anticipated
that some of the paper contributions will be published as a book.Potential
topics include (but are not limited to) the following:-

- Principles and mechanisms for constructing language metamodels
         o Principles (e.g. reuse, separation of concerns)
         o Mechanisms (e.g. layered architecture, templates, product lines)
         o Language components (e.g. semantics, user notation)

-  Architectures for MDA
         o  The metamodelling architecture (e.g reflection, layering)
         o  Requirements for future extensions to MOF
         o  Families of languages (e.g. profile mechanisms, product lines)

- Concrete languages
         o Mappings languages (including QVT)
         o Executable modelling languageso Domain specific languages (e.g.
real-time, systems engineering)
         o Ontologies and metadata (including semantic web, RDF)

-  Tools for metamodelling
         o  Meta virtual machines and executable modelling languages
         o  Implementation issues for metamodelling tools (e.g. efficiency)
         o  Model interchange and tool interconnectivity
         o  Metamodelling tool architectures and tool factories

Submission details

We invite two types of submission.  Full papers will be no longer than 15
pages and will be reviewed thoroughly.  Position papers will communicate
individuals' perspectives on MDA and will be subjected to a lighter
reviewer process.  The latter should be no more than 2 pages.  All accepted
papers will be included in a workshop technical report.  All papers must be
submitted via website (URL at top of message) by the 1st August 2003.

Important dates

Deadline for all submissions:    1st  August 2003
Notification to authors:        26th  September 2003
Final version of papers:        24th October 2003

On 4/6/03 9:45 am, "Daniel Duffy" <> wrote:

> Ed,
> Excellent! 
> Now is the time that the advocates of the "18 ancestors" to reply. Whose idea
> was it in the first place and how did this hierarchy evolve?
> My theory is: first, 18 levels CANNOT be correct and second if it is correct,
> nobody will understand it, let alone use it. So, we have a number of serious
> problems.
> Anyone remember the Taligent library? It had something like 100 classes
> hierarchies, lots of OO stuff and was difficult to understand. Alas ...
> Any answers to "why 18 levels"?
> regards
> Daniel
> -----Original Message-----
> From: Edwin Seidewitz []
> Sent: 03 June 2003 19:18
> To:
> Cc:
> Subject: RE: knowledge distilled from the UML 2.0 infrastructure
> OK, as the one who made the "has 18 ancestors" remark, and then never
> responded to Daniel's message, let me make a few points.
> First, whether inheritance is a "good" or "bad" thing isn't really quite the
> point, in and of itself (I can easily argue both sides of this issue -- I once
> wrote a paper entitled "Inheritance Considered Harmful", yet I still use it
> myself in various ways). As with anything else, inheritance has its good
> points and its bad points. On the good side it lets you define the common
> properties of a bunch of things in one place, were they can be understood one
> time and then applied to the whole bunch. On the bad side, a complicated web
> of highly factor, multiply-inheriting classes spreads the concepts relevant to
> any one "leaf" class all across the web, making it very hard to get an overall
> picture of such a class.
> Second, the term "inheritance" is used in many different ways. Personally, I
> don't like the terms "specification inheritance" and "implementation
> inheritance". To me, "inheritance" means that a subclass has the properties of
> its superclass and may specialize and add to those properties, whether used
> for specification or implementation. This is distinct from "polymorphism",
> which means that an instance of a subtype can be used correctly any place an
> instance of a supertype is expected. And it is also distinct from "dynamic
> binding", which is used to implement inheritance and polymorphism in most
> OOPLs (but is, strictly, only necessary to implement polymorphism, not
> inheritance -- but that's a whole different discussion).
> Third, the UML 2.0 Infrastructure heavily uses the UML
> generalization/specialization construct for both inheritance and polymorphism.
> This is not inherently "good" or "bad" as such, but it is a design decision of
> the submitters to highly "factor" the metamodel in a mixin-like way, in the
> hopes that this will make it easier to reuse individual chunks of useful
> concepts from the Infrastructure Library in the construction of new
> metamodels. Whether or not this was a "good" decision depends on how well this
> really works for the users of the specification.
> Finally, my comment that "Wow, there are 18 ancestors of
> Core::Constructs::Property" (and by "ancestors" I mean any direct or indirect
> generalization of Core::Constructs::Property) should be interpreted to mean
> that, whatever the intent of submitters, I found it really hard to find what I
> needed to about the Core::Constructs::Property class, and realizing that there
> were so many ancestors helped me understand why. The issue here is strictly
> "inheritance", as I defined it above. When you have as many as 18 pieces to go
> through, in a complicated "tangled hierarchy", the balance of "good" vs. "bad"
> inheritance starts tilting precariously, in my opinion, towards "making it
> very hard to get an overall picture". Even when using a tool like Rose to help
> navigate (it is even worse using the text document...).
> And, since many more people will be trying to understand the metamodel than
> will be writing new metamodels (even excluding the majority of people who will
> learn UML from textbooks and never look at the metamodel), I think this is a
> problem.
> -- Ed

Date view Thread view Subject view Author view Attachment view