> You'll find some of my initial thoughts here - > http://argouml.tigris.org/servlets/SearchList?list=dev&searchText=modeleleme ntfacade&defaultField=subject&Search=Search
Thanks for the pointer. I never would have found a two year old discussion! I agree with the previous comments (Linus & Steffan ?) that maintaining such a set of proxy interfaces (or façade) by hand is an untenable proposition. We already have too much hand-maintained machinery of this type that duplicates information from the UML metamodel. The project that Steffan referenced http://argouml.tigris.org/servlets/ReadMsg?list=dev&&msgNo=17655 (which I think is the precursor to the Eclipse ATL project) might be one source of automated tools to deal with this. Also MDR actually builds a set of proxy interfaces like this by reflection when it reads in the XMI file representing the UML 1.4 metamodel (or any MOF 1.3 metamodel), so that the internal concrete MDR objects implement interfaces named org.omg.uml.foundation.core.ModelElement, org.omg.uml.foundation.core.GeneralizableElement, etc. It might be possible to leverage or intercept this machinery, but that wouldn't help us with anything MOF 2.0 or EMF based. That brings up the question of which metamodel do we automatically derive the interfaces from? Is it UML 1.4 or UML 2.1 or some EMF metamodel? The intersection of them all? The union of them all? (These last two would, of course, require us to hand create the merged metamodel). Note that the earlier thread contained some misinformation about EMF. It is *not* compatible with OMG's EMOF (if you read the Eclipse descriptions they are always surrounded with marketing weasel words like "similar to" or "culturally compatible with"). Even if they were compatible, UML 2.1 is specified using CMOF, not EMOF. (I think E="Essential" and C="Complete", but that's off the top of my head without verification). I have more comments on the details of the proposed implementation, but I'm not sure they're relevant unless we can resolve some of these overarching questions. Until we have a clear idea of where we're headed, I think there's too high a risk that this will be wasted effort. I know we want to get to UML 2.1, but I have no idea what the technological basis is going to be for our getting there. We need to figure that out before deciding on a migration path for the Model subsystem's API. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
