Home » Modeling » EMF » Implementing inheritance: restricting instead of extending ancestor class
| Implementing inheritance: restricting instead of extending ancestor class [message #418993] |
Wed, 07 May 2008 13:53  |
 Zsolt Török
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Hi all,
Sorry for the cross-post (I already asked a related question on the GMF
newsgroup), but I figured I might reach a bigger modeling-savvy audience
via this newsgroup.
A quick summary of my requirements:
* Create a metamodel in Ecore
* Using this metamodel, create a "blueprint" model instance, containing
predefined building blocks (simply put, instances of classes with a set of
attributes) and relationships between them. This model instance contains a
hierarchy of class instances, which restrict their parent class as opposed
to extending it, like it usually happens.
* create a model editor (tree and GMF based diagram) which enforces the
constraints of restriction (e.g. a class instance can only have a given
attribute, if any of its ancestors had this attribute)
I did some online research but couldn't find a modeling standard which
uses this restriction paradigm, so I don't have any reference regarding
design and/or implementation.
My initial idea was to hook into the EMF Validation Framework and query
the blueprint (which is an instance of the above mentioned Ecore-based
metamodel) to see if e.g. a given attribute can be added to the given
class, considering its ancestors, but I don't know if that's a feasible
concept or not.
I'm really hoping that among so many modeling experts someone can give me
some advice or point me to related online resources I might have
overlooked.
Thanks in advance,
Zsolt Török
|
|
| | |
| Re: Implementing inheritance: restricting instead of extending ancestor class [message #419024 is a reply to message #418998] |
Thu, 08 May 2008 01:19  |
Eclipse User |
|
|
|
Originally posted by: give.a.damus.gmail.com
Hi, Ed,
Naturally, I agree with you and Zsolt that XSD-like type restriction
is contrary to the common notion of taxonomy that is implied by
inheritance in OO design and modeling. Even in UML, constructs like
redefinition are constrained to maintain consistent semantics (or,
where they aren't, they should be).
Speaking of redefinition, this is the principal mechanism offered by
UML (and implemented by MDT UML2 in its code generation, though Java
doesn't support the complete semantics of redefinition, which includes
renaming). Validation can help inasmuch as specializing classifiers
can add constraints (esp. invariants and operation postconditions) to
the more general contract.
Not sure if that is the kind of comment you were looking for ...
Christian
On Wednesday 05-07-2008 (10:53), Ed Merks wrote:
> This is a multi-part message in MIME format.
> --------------070809090808000609090804
> Content-Type: text/plain; charset=ISO-8859-15;
> format=flowedContent-Transfer-Encoding: 8bit
> Zsolt,
> XML Schema has restriction ideas similar to this. I'd explored how
> to support this but have never had time to complete it:
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=51210>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=51210
> Perhaps Christian will have some thoughts about it...
> I've always found the concept of restriction "odd". Given an
> instance of X's API, I'd have all kinds of assumptions about what I
> could do based on that. To find out that because an X is actually a
> derived instance Y, all kinds of things that would be valid for X
> are no longer valid for Y is problematic to a client who might not
> even realize their X is a Y...
-----8<-----
--
I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo
|
|
| |
| Re: Implementing inheritance: restricting instead of extending ancestor class [message #419056 is a reply to message #419026] |
Fri, 09 May 2008 13:19 |
| Eclipse User |
|
|
|
Originally posted by: give.a.damus.gmail.com
Hi, Zsolt,
I'm afraid I didn't get from your initial posting how the prototype
object is involved in constraining the model. Do you mean to suggest
that validation would perform a structural comparison of your model
against the "blueprint" and report any deviations? I suppose the EMFT
Compare component could be leveraged to implement that.
Cheers,
Christian
Zsolt Török wrote:
> Hi Christian,
>
> Thanks for your comment, good to know that both Ed and yourself agree
> with me that it's an unusual concept. However, I'm looking for some more
> practical advice on how to go about implementing it using EMF and
> related technologies (Validation, etc.). Does the validator module I
> described earlier (querying the "blueprint") make any sense to you? I
> know the proper way would be to define constraints using either OCL or
> Java, but all I have is the "blueprint" model instance. Maybe I could
> generate OCL and/or Java from this file (I'm using
> openArchitectureWare's transform engine for other features anyway), but
> this looks even more complicated to me than the above solution.
>
> Zsolt
>
|
|
|
| Re: Implementing inheritance: restricting instead of extending ancestor class [message #419059 is a reply to message #419056] |
Fri, 09 May 2008 14:19 |
Zsolt Török
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Hi Christian,
> I'm afraid I didn't get from your initial posting how the prototype
> object is involved in constraining the model.
No wonder, it's a weird concept, as I already said before.
> Do you mean to suggest
> that validation would perform a structural comparison of your model
> against the "blueprint" and report any deviations?
Well, more or less... Let me give you a simplified example:
* The blueprint defines the base classes A, B and C, and a couple of
subclasses.
* The blueprint also defines associations between the base classes: A - B,
B - C.
* In the actual model editor (GMF based diagram in this case) the user
would insert a subclass of A and a subclass of C.
* Drawing an association between these should be disallowed based on the
fact that the blueprint didn't have a connection between A and C.
> I suppose the EMFT
> Compare component could be leveraged to implement that.
Good idea! I know the EMFT Compare Framework from an earlier project, but
somehow it didn't occur to me that I could use it for that...
Thanks for taking the time to try and wrap your head around this.
Cheers,
Zsolt
|
|
|
Goto Forum:
Current Time: Fri Apr 26 20:06:04 GMT 2024
Powered by FUDForum. Page generated in 0.03584 seconds |
] 
Search
Help
Register
Login
Home
