This is a static archive of the previous Open Grid Forum Redmine content management system saved from host redmine.ogf.org file /projects/glue-wg/wiki/Ideas_for_Model_Evolution?version=1 at Fri, 04 Nov 2022 15:13:43 GMT Ideas for Model Evolution - GLUE WG - Open Grid Forum

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.
This is a static archive of the previous Open Grid Forum Redmine content management system saved from host redmine.ogf.org file /projects/glue-wg/wiki/Ideas_for_Model_Evolution?version=1 at Fri, 04 Nov 2022 15:13:43 GMT