[Uml-devel] u2 diagram bs

[Andrew Sutton]

okay... plentry of discussion on diagrams and visualization and what have you. 
its time to move on.

we need to establish a basic design for how this is going to work. lets assume 
for the time being that we'll be using karbon14 as our drawing framework. i 
think it passes the test. we need to establish a basic design that defines 
the following:
- document model (alright... diagram model) for uml diagrams
- graphical artifacts (not just uml stuff)
- alternate notations for an artifact (consider interfaces and classes)
- dialogs for presentaiton options
- dialogs for data manipulation
- plugin structure
- how this is going to be stored
- representing tools for modifying diagrams

my thought is that we're going to introduce a pseudo-metamodel into the core 
library to handle this stuff. its going to need to tie into the the 
reflective layer at some level for xmi integration and object-diagram 
relationships. how that's going to work, we'll have to see - i've got a 
decent idea for it. we should probably specialize the diagram types. maybe 
one plugin per diagram. that would be kind of cool. because we could build 
the whole thing piece-wise (class diagrams first :) and publish beta or minor 
releases as we finalize stuff for each type of diagram.

on the artifact side, we basically need to identify various graphical things 
that we want to put on diagram. each type of notation or artifact could be a 
provider. that means that we're going to need some kind of class that could 
provide a selection mechanism for artifacts with alternative notations. for 
example, if we stereotype something as a boundary object, we might choose to 
draw that very, very differently. see the uml standard - profile for software 
development processes for examples of notations. i suppose we could define 
some kind of virtual VShape or whatever as the container for actual notations 
(which would also be derived from VShape).

for presentaiton options, we clearly have one for the virtual notation 
provider - being able to select the actual provider. we might be able to put 
some other things in there like color to could be passed as parameters to 
actual providers. each actual should might have its own presentation dialogs. 
we can probably identify common properties among gfx providers to reduce the 
amount of code for the dialogs.

we already know that most metamodel objects are going to have data dialogs. 
we'll just have to figure out how to group the attributes that are being set 
in order to minimize the amount of code we right for them (shouldn't be too 
hard).

as for storage - we might be able to use the karbon14 document model - unless 
that's all svg, but i don't think it is (i haven't looked yet). essentially, 
we're storing a collection of objects that a) store display settings and b) 
optionally reference a single data element (probably via an xmi.idref xml 
attribute). if we build the diagram stuff as a psuedo-metamodel and tie it 
into the reflective layer, we can basically associate diagrams as contained 
by any object derived from RefObject (like packages and classes). that's 
good.

on the tool side of things, we'll probably need to define a set of KActions 
that represent the modification of a diagram. we also need to figure out 
exactly how these operations are going to to react with the underlying 
document - which contains the model and of course, all the diagrams. this 
might be a little more complicated that we think because we want to allocate 
space for persistent UML databases so we can talk about truly collaborative 
modeling. also, we can use this mechanism to implement some form of 
round-trip engineering. think kdevelop publishing various actions to modify a 
uml model as code changes. moreover, the much un-discussed xmi difference 
engine could use these actions to modify the model and/or diagrams. i think 
on this topic, we basically end up with two distinct actions - one to alter 
the model and one to alter the diagram (if we're changing the diagram) - 
think translating <XMI.difference/> elements into KActions. this event-driven 
modification could be pretty useful... i hope.

so... does somebody want to throw together a prototype design? i really don't 
have the time right now. i've got to finish my paper, make a presentation for 
it, write a bottom up operator precedence parser (4 hours :), tutor some 
people in computer org and assembly, try to find funding to go to a 
healthcare industry conference, go to the conference (1 week), and then i 
have finals. busy busy busy. ah the life of a grad student ;)

we just need to get started on it, but i'm not really available to truly get 
started just yet.

andy