[Uml-devel] Thoughts on Umbrello 1.3

[Andrew Sutton]

i'm forwarding this to the kdevelop folks, because they might have some input 
too.

On Monday 19 January 2004 08:08 pm, Jonathan Riddell wrote:

> Unfortunately 1.2 has far too many bugs in it, many of them crashes.
> Cleaning up the unconfirmed beasties today it crashed several times.
> Worse, they're hard to repeat and harder to track down type crashes
> (which is why I didn't report them).  Changes to associations and the
> code generators seem to be the main culprit.  I gather that the rules
> for KDE 3.2 branch are the same as the recent deep freeze: fixes to
> major beasties only and no i18n() changes.  So any fixes to major
> problems should be done in HEAD and then merged back into 3.2
> carefully (cvs -j is rumoured to be good for this, ask if you have any
> problems).
> 
> Onto Umbrello 1.3.  Bartko pointed out the choices to me:

> a) improvement of Umbrello 1.2
> b) rewrite of Umbrello 1.2
> c) merge with Umbrello2
> d) something else?

> I strongly suggest the first choice.  Umbrello 1.2 is good and
> maintainable so we should maintain it and improve it.  There's plenty
> to be improved and added.

i'd go with a combo between b, c, and d. there's alot of instability in the 
umbrello code base related to stanardization changes. if you code a new 
feature for an association, then you have to modify existing dialogs, the 
save/load code and the code generators. even worse, suppose the underlying 
object model changes significantly, like realizing that templates are done 
completely wrong (i'm not saying they are... i haven't looked). this might 
require changes to a significant amount of code.

there have also been some requests for design changes to umbrello over the 
last couple years - most frequently would probably be to use kparts.

in terms of future direction i think its time to abandon the old code base and 
start fresh. continuing with 1.2 will probably just end up making the project 
age prematurely and we'll probable end up introducing more bugs with every 
fix.

here's what i'd suggest:
	- 1.2 continues in bug fix mode. no new features, etc.
	- 1.3 starts as a new development effort with a brand new design
	- use the omf (my work) as the data model and read/write capability
	- develop a kpart for each part of the ui
		- any model views (like the tree view)
		- read-only versions of all diagrams
		- read/write versions of all diagrams

the actual core of the application is really the model view and the omf 
library. i could probably get the thing started in about a week or two 
(badly) - just context menus and creating common uml objects (classes, 
packages, etc).

the diagramming component needs a serious design for the notation engine. i'd 
like to see a lot more options in terms of presentation options based on 
things like object type (if it's a UML::Class or UML::Package) and also 
different notations for different stereotypes.

> Code import for more languages features in bugs.kde.org but it may be
> best to tidy up the code generators we do have.  For example why does
> the C++ code generator not add a variable for a unidirectional
> association?

actually, code import can probably be done in conjunction with the rest of the 
development because the uml object model already exists. it would also be 
extraordinarily helpful to import libraries like stl, qt, kdelibs and create 
pre-defined models.

code generation is a significantly more complex issue and deals, to a pretty 
good extent, with model transformation. actually so does code import, but 
it's easier.

> Class diagrams should allow Objects in them (apparently, says the UML
> spec).  This allows for object diagrams (which are just class diagrams
> without the classes).

it should... objects can be connected to classes via an "instantiates" 
relation.

> The oft-requested KDevelop integration is probably a long way off.  It
> would be nice if done properly but is probably too much work.

you're already halfway there if you use the omf.

> QCanvas works well for us as a canvas but anti-aliasing and SVG export
> would be nice.  I suspect it's still the best going at the moment.

anti-aliasing would be superb. i looked at this months ago, but couldn't get 
much out of it.

> Standards compliance with XMI is happening now which is great.
> Eventually we may need to look at UML 2 but probably not for this
> release.

no... let's hold off on uml2. that way, we can release umbrello 2 to use uml 
2. it's a significantly different metamodel and not at all easy to implement 
in c++.

> Finally if anyone feels they would do a better job than me with the
> title of project admin do say so.  I've not been the most active
> developer in the last few months (having left university) but I do
> make an effort to ensure beastie reporters are thanked, all e-mail is
> replied to and the website is up to date.  Others do that as well
> though so maybe I should drop the title.

i think the project management has been exceptional. good work.

andrew sutton
asutton at cs.kent.edu