[Uml-devel] Thoughts about U2 "tree view"

[Andrew Sutton]

On Monday 12 May 2003 10:31 am, Sebastian Stein wrote:
> Andrew Sutton <asutton at mcs.kent.edu> [030512 16:27]:
> > the only thing that i'd suggest being careful of is the data independence
> > of what's represented in the tree view. that could represent several
> > objects from several different metamodels - we always use UML as the
> > example, but it could also represent CWM data. actions corresponding to
> > objects in different metamodels will almost certainly be different.
>
> So we have to look at MOF was basic elements it defines and which actions
> could be done with these elements. I think of a class can contain
> operations, so an action add an operation to a class is needed.

essentially, yes. except the MOF is probably going to be a read-only thing in 
or system. it doesn't make sense to change it unless we're going to 
implement, compile, and link modifications at run time ;) the specification 
of generic actions is really, really hard to do because the creation of 
objects like classes, attributes, operations, whatever are specific to 
metamodels. there just isn't that much common stuff going on. we might be 
able to define some generic actions for navigation (click on this, go to a 
diagram?). click on this, go to properties... that type stuff.

in my thinking, each metamodel is going to have to define its own actions - it 
sounds kind of crappy, but there's too much metamodel specific stuff going 
on. also, we need to constrain which actions are available to which objects. 
for example, we shouldn't be able to create attributes within packages or 
classes within operations (that would be some wild code :)

if each metamodel plugin is responsible for creating and managing its own 
actions, then we need to find some way of making sure of distributing those 
actions to the rest of the application in a fairly generic method - that's 
probably the base functionality you're talking about.

i think one possibility would be to define some kind of action manager that 
implements a publish/subscribe style interface. components can subscribe to 
sets of actions (defined by text strings or maybe an enum). when the app 
reaches a state where a set of actions need to be updated, the subscribed 
apps are notified by a published message and they can do whatever they have 
to. of course, i might be re-inventing a wheel with this, but i'm not a 
KAction guru by any stretch of the imagination.

andy