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

List:       kde-kuml-devel
Subject:    Re: kUML repository and data integrity
From:       Carsten Kuckuk <ck () kuckuk ! com>
Date:       2000-09-21 16:34:52
[Download RAW message or body]

Hi everybody,

> [..] component model [..]

I think you are mixing technical implementation details with design.
The decision of how to technically implement certain elements (as a 
KPart or a Corba object, or who knows what) should come last.

> 1. GUI
> 2. Code generation
> 3. Reverse engineering
> 4. Persistence
> 5. Graphical model
> 6. Repository

I see several problems here:

(1) A UML project consists of things like classes, actors, use-cases,
and diagrams. So the data model that is manipulated consists of both:
logical and graphical elements. The "Graphical Model" and the 
"Repository" in my opinion are one and the same as far as UML model-
ling is concerned.

(2) With "Persistence" there are basically two options: The "File" 
approach and the "Database" approach. In the file approach, the whole
model is read from disk into RAM, then you work on the transient model
in RAM, and when you're done, you dump it into a file. So the basic
architecture is:
Layer   Functionality
  3     GUI: Dialogs, Menus, etc.
  2     Processing: Load Model, Save Model, Create Class,...
  1     Transient Data Model: Class, Relationship, etc.
In the database approach, the real data is stored in the database.
All interactions are done inside database-transactions, and next
to no information is stored in RAM:
Layer   Functionality
  3     GUI: Dialogs, Menus, etc.
  2     Processing: Import Model, Export Model, Create Class..
  1     O/R Mapping Layer: Proxies for objects in the database, SQL
        Statements
  0     Database Tables: CLASS, RELATIONSHIP, PROJECT,..
As database access is non-trivial, we should go for the file approach.

Carsten

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