[Uml-devel] Re: Thoughts on Umbrello 1.3

Andrew Sutton asutton at cs.kent.edu
Sat Jan 31 06:13:13 UTC 2004


> 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.

thanks, but i think you're misunderstanding some of the relationships between 
the metamodels and my implementation. anyway, who cares how long either the 
MOF or UML standard is... the OMF (open modeling framework) implements them 
as completely as i know how.

just a quick history lesson. umbrello2 was my work too. the omf actually 
evolved out of my umbrell2 implementation of the uml metamodel. i just 
trimmed off all the ui shit to focus on the api.

> 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).

that's what the omf does... it keeps as simple as possible but still 
implements all of UML... but it does let you build anything you want as a 
hobby. hell, you can write command line programs to do uml analysis using the 
omf. there's nothing that says it only has to be used for umbrello (of 
course, a nice integrated ui would be nicer :) actually, the size of the 
implementation turns out to be "a good thing". developers can pick and choose 
to implement some new and interesting feature using a very limited subset of 
the implementation and it doesn't really have to be coupled to any other part 
of umbrello. for example, i could write a ui that lets me manage template 
instantiations within a package, plug that into the (imaginary) umbrello 
framework, and it's all good. limited scope. rapid development. easy 
deployment :)

> 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.

umbrello wasn't originally designed for this... any attempt to modularize it 
is going to be heavily intrusive and probably introduce more bugs than not.
 
> 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.

i agree with sebastian's vision here... let the omf handle model and data 
extensibility and let umbrello be something more like kdevelop - completely 
modular.
 
> 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.

my understanding of roundtrip engineering is that there really isn't "code 
generation". i've always felt that roundtrip engineering was defined by its 
"immediateness" of process. make a change to the model, it's reflected 
_immediately_ in the code. make a change to the code, it's reflected 
_immediately_ in the model.

and actually, the omf CAN do that. one of my upcoming side projects (after i 
get the omf a little more stable) is to write a roundtrip plugin for 
kdevelop. of course, there won't really be any diagrams, but hey! close 
enough :)
 
> 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).

code generation is... a little more than code generation. the stuff you're 
talking about is model transformation, and this isn't something very well 
understood. what code generation actually does is:
1. start with a system, language independent uml model
2. transform it to a language specific model (c++)
3. map that onto a platform model (gnu/linux)
4. map that onto a project model (automake/autoconf, msdev)
5. map that onto a source model (how the code is laid out)

so... you still want to work on this ;) that's about how configurable code 
generation process should be. you should be able to take a completely generic 
model and transform it into any language, and platform, any tool and any code 
style and end up with the complete code. these should all be options in a 
wizard somewhere... actually, that would be really nice.

anyway, the first two steps are somewhat artificial because people tend not to 
create purely system independent models - we think too much about the 
languages we use. that's what stereotypes are for. exactly how all this stuff 
is going to work, i just don't know, but i don't think that tagged values are 
necessarily the answer.

the answer might be to create a c++ specific metamodel that actually 
implements the features of c++ that uml is missing - like pass by reference/
value notation or const notation.

> Anyway, just my 2 cents.

and 2 more :)

andy




More information about the umbrello-devel mailing list