[Uml-devel] Re: Umbrello design (was UML XML tree viewer)

[Andrew Sutton]

On Thursday 07 November 2002 5:44 am, Heiko Nardmann wrote:
> Okay, I got that. So looking at the XML/XMI file 01-10-05.xml using the DOM
> viewer of konqueror I would like to discuss the following things:

what is 01-10-05? UML?

> 1. we safely can ignore the header.

NO! we actually need the header. the header contains metadata for the entire 
document. we'd like to keep that around.

> 2. inside the Model:Package we can ignore both the ModelElement constraints
> and the Contraint definitions in the Model:Namespace at the first step. We
> can implement the handling of OCL stuff later.

right, but we should import the OCL into the class definitions. we can leave 
it rendered as text.

> 3. the PrimitiveTypes package is imported. This one is inside file
> 01-10-06.xml. But I did not find a link to this file in the MOF XMI file.
> So how should the parser know where to find the corresponding file? Maybe
> look at all XML files, check whether they describe the imported Package? Or
> should we in this case implement PrimitiveTypes manually? Better not so
> that we do not have inconsistencies inside the code (manually written code
> <-> generated code).

i assume we'll have to setup some kind of import path. current directory, 
system directories. good question, though. i hadn't started thinking of 
imports.

> 4. how should this initial parser be implemented? There are some
> alternatives: a) manual parser using QtDom and traversing the nodes ...
> 	b) bison (maybe in combination with QtDom); we do not have a real parsable
> grammar (only in the DTD file) ... so probably bison is oversized ...
> 	c) XSLT (xerces/xalan); Chris Moore did his first steps using some XSLT
> stuff ...
> 	d) ...

a d) option would be to parse MODL.

i think MOF needs to be recursively built. we should start with a lightweight 
MOF and use the libXMI mechanisms. that lets us spend alot of time working 
with libXMI. we should understand its operation quite well by the time it is 
deployed.

> 5. what shall be inside those classes? Do we need a reader (parser) and
> writer in each model element (load/save missing as Andrew Sutton stated in
> a former mail)?

the generated classes should implement the attributes and relationships 
described by the XMI file. nothing more. all other functionality is built 
separately for the following reasons:
	- lower coupling (at the component level)
	- higher cohesion (at the component level)
	- better separation of concerns
	- more maintainable

at least thats what we've convinced ourselves of, right :)

andy