[Uml-devel] Re: Thoughts on Umbrello 1.3

[Erik Engbrecht]

I'm new to this and don't mean to sound obnoxious on my first post, but
what is the vision for Umbrello?

I think this is really important because it is very easy to become
focused on building a framework to handle everything under the sun, and
as a result have core functionality - the functionality that draws users
and contributors alike - suffers.

For example, take rewriting the core model representation used by
Umbrello, or using Andrew Sutton's MOF implementation.  From a
theoretical standpoint, I think MOF is an amazing abstraction, and
Andrew has done a good job of mapping it to the UML model.  But MOF is a
monster of a specification (the spec is 500+ pages), and Umbrello2 looks
a lot more complex to me than the existing Umbrello code.

The bottom line is I think everything should be kept simple.  I also
think all improvements should occur in relatively small increments.  My
reason for this is that, at least to my knowledge, no one is being paid
to work on Umbrello.  That means all of its developers are part time at
best, and developing Umbrello is a hobby.  As a result, an effort needs
to be made to ensure that (1) competent developers that aren't
necessarily very familiar with Umbrello or UML can quickly become
contributing team members (keep it simple to control the learning
curve), and (2) it is easy for developers to lose focus or motivation to
work on the project (make them see results so they'll want to do more).

I think the best thing Umbrello has going for it right now is that it is
simple, both from an end-user and a code perspective. Just take a moment
to compare it to ArgoUML, which seems to me to never quite reach a truly
usable state. In my opinion, what it really needs right now is some
refactoring to make its internal model cleaner, more cleanly integrate
some of the features that have been simply tacked on, and buildup a
framework that makes it much easier to extend.

Of course, focusing on extensibility can easily lead to excessive levels
of abstraction, which in turn destroy extensibility by making the
framework too difficult to understand.  So a vision what type of
extensibility is required is needed.

Personally, my focus would be on enabling the construction of code
generators that take a Umbrello's XMI file as input.  Long term, I think
the focus should be on building a framework for constructing round-trip
code generators.

The key for code generators is making sure the model contains enough
information to reliably generate the code, without corrupting the UML
presentation.  For example, from a pure modeling/analysis point of view,
whether or not a function parameter is passed by reference, pointer, or
value (and add to the const or not const) is relatively irrelevant. 
However, from the perspective of defining a C++ class, these aspects can
be very important.  A simple translation of this into a requirement
could be that the user shall be able to add and edit structured
supplemental information associated with all elements of the model.  A
simple implementation of this could be to add support for UML tagged
values to Umbrello (I'm actually working on this).

Anyway, just my 2 cents.