[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kuml-devel
Subject:    Re: Design change plan and tools
From:       Carsten Kuckuk <ck () kuckuk ! com>
Date:       2000-09-25 9:08:51
[Download RAW message or body]

>     Wouldn't it make sense to have the UML repository handle XMI persistence ?  I
> would tend to see XMI and UML v1.3 as closely linked standards so that it would
> make sense to treat them with closely linked software components. [..]

In my opinion, the model and export/import functionality should be kept
separately. The reasons foor this are:
- Separate things should be kept separately.
- UML and its XMI format will evolve over time. And suddenly you 
  are faced with the requirement to read old XMI files into a new
  UML repository or export the new XMI file format from an old 
  repository. Or you want to export into / import from an important
  industry standard file format. These requirements can be best dealt
  with sets of modules that share the interface. If I had to design
  this, I would define an Export base class and derive all kinds of
  exports from it. Same with imports. 
- By the same reasoning you could integrate drawing fucntionality 
  into the repository as there are pictures in the UML standard.

I am currently using CORBA in my real-world job, and it is such a pain
(debugging, writing lots of code, etc.) that I do not want to be 
forced to use it again if it's not really necessary. I think that 
c/s functionality for the repository should be left to version 2 or 3.

Carsten

[prev in list] [next in list] [prev in thread] [next in thread]