[Uml-devel] U2 questions / comments

[Andrew Sutton]

On Tuesday 01 April 2003 1:28 pm, Luis De la Parra Blum wrote:
> Hi Andy, hi all,
>
> I just got me a copy of umbrello2-cvs and am in the process of building it.
> hopefully in the next days I'll have a bit of time so that I can start
> playing around with it, but first some questions / comments:

cool.

> about the metamodels: could you please give a brief expl. about the
> different classes?, for examle, for UML::Class I've found Core::Class,
> Core::Class_Impl and Core::Class_Class ?

right. Core::Class (actually, its going to be UML::Class because its imported 
into a different namespace) is the interface defined by the specification. It 
contains the abstract accessors and mutators for the interfaces attributes. 

the UML::Class_Impl is the actual implementation of those pure virtual methods 
- and all the methods from any parent classes (maybe UML::Classifier, 
UML::Namespace, UML::GeneralizeableElement, UML::ModelElement and 
UML::Element if i remember). it also implements the reflective interfaces for 
RefBaseObject, RefFeatured and RefObject. the reason that UML::Class has an 
implementation while UML::Namespace does not, is because UML::Class is not 
abstract. UML::Namespace is - hence, no _Impl class.

the UML::Class_Class is what's known as a class proxy. it really serves two 
different purposes. 1st, it's the factory for objects of that class. you can 
create new objects of that type by calling:

UML::Class_Class::instance()->create();

2nd, the class proxy is the owning extent for objects of that type and class. 
objects can have more than one type (i.e. it's a Class, it's a Namespace and 
its a Classifier), but they only ever have one type (i.e., it's a Class). 
collections of all objects are returned via the refAllOfType and 
refAllOfClass methods on the RefClass interface.

> what is the role of each of them? for what I can tell, the Class does
> nothing but return a pointer to a Class_Impl, which is the one doing all
> the work... question: why did you implement it this way? (instead of having
> the Class have all the methods?
> I guess the Class_Class is the reflective interface for the Class... but
> how do you use it?

this follows the JMI mapping specification to a certain degree. the roles... 
interface (Class), implementation (Class_Impl) and factory (Class_Class).

> - about the app: I think that having  the version number in the class/file
> name is not a good idea at all... I know it's a complete re-write and
> everything, but what are you going to do with Umbrello2App when we get to
> version 3? -> either you're gonna get some inconsistency in the names, or
> you're going to have to re-write large parts of code.
> By having version number as part of the name, you are saying good bye to a
> smoot evolution of the project ( slowly improving the code till you get to
> v3 ) and are forcing a rewrite for the next major version.
> It's not for nothing that KMainWindow is not named KMainWindow3_1_1 ...

good point... i don't know. i think the rationale was that 2 was such a 
departure from 1 that anything after that could be said to use the umbrello2 
framework. i suppose the better idea would be to remove all versioning 
information from everything (including the uml-1.4 and mof-1.4) libs and move 
it all over to a new "umbrello" module. since 1.x is still in the uml module.

> another point is, I think that a vanilla Document/View model is not going
> to be enough for U2.... we are going to have one document (our Model), but
> ther's going to be many types of views. (diagram views, "model browsers",
> etc, etc ) Each view looks at one part of the document and or from a
> different point of view

right. doesn't document/view support multiple views of the same underlying 
data? i thought that it would.

andy