Standards » Management Area » GLUE WG

h1. Ideas for Model Evolution

Ideas for evolving GLUE 2.0 Conceptual Model

The discussion will start after a relevant implementation experience of GLUE 2.0. We can envision that this will not happen before Jun 2010. Meanwhile, we collect ideas in this page

* From the theoretical point of view, you can not imply that pointing to a class you have access to its subclasses, but just to its superclasses because of the definition of inheritance in the object oriented programming. So I would propose two solutions here depending on what you wanted to describe:

** Inheritance is a way to form new classes (instances of which are called objects) using classes that have already been defined. The inheritance concept was invented in 1967 for Simula (http://heim.ifi.uio.no/~kristen/FORSKNINGSDOK_MAPPE/F_OO_start.html).

** Solution: Taking all "inherited association" ends from subclasses out from the Inherited Association End list.

** Sergio: alwasys focus on the fact we are using UML Class Diagram for the conceptual model; in the UML class diagram, when a class is specialized by another class, it will inherit all the attributes *and relationships*; therefore this is consistent with the adopted modeling language

*** I got your point, there are two possible solutions:

*** remove them

*** add one more section for "implied assocation ends" or similar; it could be useful for implementors to verify that all associations are taken when designing the mapping, especially for not powerful data models such is LDAP

** Final: OK. Will be removed, unless the majority prefer the second option.

* Try to restrict the uses of Multivalue attributes if they are not very used so they can be used as Extensions

** Entity class: The "OtherInfo" attribute could be replaced by the use of Extensions, because that is what they are meant for

** ComputingActivity class: The "OtherMessages" attribute could be replaced by the use of Extensions, because that is what they are meant for.

** In the AdminDomain entity (page 11), the AdminDomain relationship is defined two times. This is because you want to specify both ends. I think both ends should be named for consistency. As simple as "end1" and "end2" or something similiar.

** This improvement could be made also in: Service (page 13)

** Sergio: the semantics of each end is different, this should be represented somewhat; for the AdminDomain, if you look at the description, you can read it; for the Service, the association is directed; the same issue applies; we need probably to clean the way this difference is described in the table; in the UML it is possible to label the association ends; need to clean this

* In Contact (page 10), two relations are specified: Service and Domain, and both are zero to many. What you really meant is that a Contact should be related minimum to either a Service or a Domain, but that couldn't be specified in UML. Possible solutions:

** Make two children of Contact: ServiceContact and DomainContact. ServiceContact will have a relation to Service one to many. DomainContact will have a relation to Domain one to many.