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.