[Uml-devel] UML XML tree viewer

[Andrew Sutton]

On Monday 04 November 2002 11:36 am, Sebastian Stein wrote:
> Andrew Sutton <ansutton at kent.edu> [021104 17:15]:
> > ...
>
> First of all I have to say that I like your approach very well. It seems to
> be the perfect way to go from simple to complex. Now I'm thinking of
> possible problems that might kill the approach. So I like to ask you to
> comment on these few issues I see:
>
> - performance
> - very high theoretical complexity

thank you for the good feedback :) that ideas been stirring around in my head 
for quite some time. writing it down helped.

performance:

i assume you mean performance of the XMI loader and not the end application. 
since we're just generating data objects i don't see performance being an 
issue with the end application.

for the xmi loader - all we'd really be doing is walking a DOM tree. i've 
toyed with implementing this about a month ago and found that it can chunk 
through the entire uml spec in a second or two (just printing elements to 
stdout).

there's really two general operations: walking the dom tree and operations on 
a "document stack". you have to recursively walk the DOM tree to get the 
elements in the document. for each element, you can look at the namespace/tag 
name and figure out what is responsible for implementing the semantics of the 
element.

the stack is used to keep track of the element that is currently having nested 
children applied to it.

the net result is fairly fast performance assuming that handlers are 
registered with the XMI implementation in such a way that they can be located 
in constant time (hash_map).

there's also an idea of an element registry - basically some mapping of 
elements to their id's (xmi-id?). something like that. we probably need to 
maintain that table too.

theoretical complexity:

i'm not really sure what you mean here. if you mean a theoretically complex 
design then you may be right - to an extent. it really isn't too bad. the 
theoretical design is highly component based and that's going to reduce 
complexity significantly.

the hardest part would be to automatically generate the semantic capabilities 
of each object - that is to say the codegen stuff. we may actually need to 
remove that capability from our codegen implementation and build it 
separately. that would mean that any autogenerated libraries *only* deal with 
their own attributes and relationships and the ability to save and load 
themselves. that should be simple enough.

the codegen would then follow a pattern similar to what it is now. we should 
be able to apply some (one of many perhaps?) codegen implementation to a MOF 
model to generate code to implement the metamodel described therein. does 
that make sense? it's kind of hard to see.

there's another added advantage to this model. we can use the pattern of code 
generation for both MOF and UML based models. good software engineering :) 
patterns!

i'm going to spend some time today working on a possible design for this 
thing. it might be kind of interesting to see it take shape.

andy