Subsetting vs. redefinition vs. association specialization vs. association class specialization
azzam
UML 2 introduces more than one concept regarding relation between associations: Subsetting, redefinition, association specialization, association class specialization.. The semantics of these concepts as it appears in the standard is ambiguous and the current information is confusing.
I could understand the semantics of subsetting and redefinition, but I don't understand the semantics of association specialization and association class specialization. I feel that association specialization is the same as redefinition. The most confusing is generalization between association classes.
I would appreciate if any one clear these consepts for me.
Azzam
Jim Logan
Hello,
UML 2 introduces more than one concept regarding relation between associations: Subsetting, redefinition, association specialization, association class specialization. . The semantics of these concepts as it appears in the standard is ambiguous and the current information is confusing.
I could understand the semantics of subsetting and redefinition, but I don't understand the semantics of
association specialization and association class specialization. I feel that association specialization is the same as redefinition. The most confusing is generalization between association classes.
I would appreciate if any one clear these consepts for me.
Azzam,
It took a lot of effort to get these straight in my own head, so I'll share my findings with you.
Property subsetting indicates that adding a value to the set of values in the subsetting property causes it to appear in the set of values in the subsetted property. This is similar to property specialization in OWL, where inferencing automatically creates missing subsetted properties. Property subsetting often goes hand-in-hand with a derived union. If you set the subsetted property to {union}, it becomes derived, read-only, and the union of all of its subsets.
Property redefinition specifies that the redefined property changes the name, multiplicity, type, default value, derived-ness, or strengthens other constraints of an inherited property. This is similar to a class restriction in OWL, where a class can constrain the domain, range, or multiplicity of a property. I don't see anything in the specification about what happens when you access the redefined property from the context of the supertype (e.g., up-cast), but because the spec says, "the redefined feature must conform to the compatibility constraint on the redefinitions (e.g., the type of the feature must be a subtype of the feature’s type in the more general context)," I infer that you can access the redefining property through the redefined property.
To me the UML 2 spec leaves the semantics of association generalization ambiguous. What I infer is that association generalization implies the specializing association ends both subset and redefine the corresponding general association ends. The general association ends should contain instances from the general and specializing association ends, but the specializing association ends should only contain more specific instances. In my opinion, one should not use association generalization by itself; one should always use {subsets} and / or {redefines} to make the intention explicit.
Association Class generalization further specifies that the specializing association class inherits all of the features of the general association class, not just the association ends.
I hope that helps.
-Jim
vincent...@atosorigin.com
On Mar 21, 11:18 pm, azzam <m...@cs.bgu.ac.il> wrote:
> I could understand the semantics of subsetting and redefinition, but I
> don't understand the semantics of association specialization and association
> class specialization. I feel that association specialization is the same as
> redefinition. The most confusing is generalization between association
> classes.
Specialization isn't the same as redefinition.
I think the more appropriate examples to illustrate these concepts
are :
SendObjectAction::request (redefines InvocationAction::argument)
(11.3.44)
SendObjectAction::target (subsets Action::input) (11.3.44)
and Action::input (specializes Element::ownedElement) (11.3.3)
An Action can have input pins (Action::input). Hence, Action::input
specializes Element::ownedElement, as input pins are owned by the
Action. This means that the input relation has a more precise semantic
than ownedElement relation. Also, the specialization enables to have a
different type than the original relation (input requires an InputPin,
whereas ownedElement requires only an Element). This does not mean
that all Element::ownedElement are Action::input. An Action owns a lot
of other elements than input pins.
A SendObjectAction has a target (SendObjectAction::target). Subsets is
not very different than Specializes. The semantic also becomes more
precise, but the required class is the same (SendObjectAction::target
and Action::input both require an InputPin). As for the
specialization, the set of elements linked by the parent relationship
contains the elements linked by the sub-relationship.
Finally the SendObjectAction has a request pin
(SendObjectAction::request). This relation redefines
InvocationAction::argument. Contrary to subsets and specializes, this
means there can be no other argument pin in a SendObjectAction than
the request pin. In java, for example, the SendObjectAction::argument
accessors would be deprecated, and the implementation would either
throw an exception or redirect to SendObjectAction::argument depending
on the level of tolerance wanted.
As for a generalization between association classes, I think the
generalization focuses mainly on the class aspects. The associations
themselves are unchanged (except contrary indication), though the
semantic may differ a little.
I hope it helps you.
Vincent.
azzam
--
You received this message because you are subscribed to the Google Groups "UML Forum" group.
To post to this group, send email to umlf...@googlegroups.com.
To unsubscribe from this group, send email to umlforum+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/umlforum?hl=en.
--
Azzam Maraee
Department of Computer Science
Ben-Gurion University
ISRAEL
ma...@cs.bgu.ac.il
972-8-6428044 (o)
azzam
Again, thanks for your answers, it is really helpful "but" (in our field there is always a "but" :) )
> It took a lot of effort to get these straight in my own head, so I'll share my findings with you..
I think that redefinition and subsetting are incompatible. Subsetting implies the existence of a "super" association, that is, an object of the subclass which has the subsetted property of the super class. Consider the following class diagram:
A-a-----------b-B
C-c-----------d-D {subsets b}
where C and D are the respective subclasses of the classes A and B. Now, the subsetting constraint implies the following:
For an instance of class C, the collection d is a subset of collection b. This is equivalent to the OCL constraint: context C inv: b->includesAll(d).
If we replace the subset constraints with redefines, we get
an instance where C no longer participates in the links of the association a—b, but only in the links of the association c-d, which means that c.b (c an object of C) yields an error. This, of course, renders the a-b association redundant from the point of view of class C and D.
So, adding both redefinition and subsetting to the association end creates a consistency problem.
Is this not so?
> Specialization isn't the same as redefinition…
If we look carefully at the UML metamodel, "specialization", as an independent notation, is not used. The example you gave used the word "specialize", but the class diagram (in the metamodel) included "subset" on the association end and not "specialize" (page 237, near the association end there is a "subsets owned element")
I don’t understand the meaning of the specialization concept. If, as you say, it means "the set of elements linked by the parent relationship contains the elements linked by the sub-relationship" then this is the same thing as subsetting.
Sorry for asking again, but I feel that the concept is still a bit confusing. If we look at the abovementioned example and replace "redefinition" with "specialization", then - what does it mean?
--
You received this message because you are subscribed to the Google Groups "UML Forum" group.
To post to this group, send email to umlf...@googlegroups.com.
To unsubscribe from this group, send email to umlforum+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/umlforum?hl=en.
vincent...@atosorigin.com
> So, adding both redefinition and subsetting to the association end creates a
> consistency problem.
>
> Is this not so?
I think you've understood the meanings of subsets and redefines.
Like you said, subsets is equivalent to the OCL constraint: context C
inv: b->includesAll(d).
Redefinition means :
"You see that relation, up there ? Well, this is quite like the
relation we have here, but not exactly it. As this old one makes no
sense for this element, we simply erase it and replace it with our new
one."
> If we look carefully at the UML metamodel, "specialization", as an
> independent notation, is not used. The example you gave used the word
> "specialize", but the class diagram (in the metamodel) included "subset" on
> the association end and not "specialize" (page 237, near the association end
> there is a "subsets owned element")
>
> I don’t understand the meaning of the specialization concept. If, as you
> say, it means "the set of elements linked by the parent relationship
> contains the elements linked by the sub-relationship" then this is the same
> thing as subsetting.
Well, maybe I was a bit wrong saying about subsetting
"the required (end) class is the same (SendObjectAction::target
and Action::input both require an InputPin)"
In fact, it's the other way than what I was figuring :
Subsets does not require associations types being the same (just
inheritance implied by the OCL rule).
On the other hand, specialization is a kind of subsetting, where the
association end type differs from the parent relation's type.
But generally, the main difference we mean when using specialization
rather than subsetting, is a semantic one. The specializing relation
has a semantic which is generally much more precise than the parent
relation's semantic.
Jim Logan
Again, thanks for your answers, it is really helpful "but" (in our field there is always a "but" :) )
�
> It took a lot of effort to get these straight in my own head, so I'll share my findings with you..
�
I think that redefinition and subsetting are incompatible. Subsetting implies the existence of a "super" association, that is, an object of the subclass which has the subsetted property of the super class. Consider the following class diagram:
A-a-----------b-B������������
C-c-----------d-D {subsets b}
�������������
�
where C and D are the respective subclasses of the classes A and B. Now, the subsetting constraint implies the following:
For an instance of class C, the collection d is a subset of collection b. This is equivalent to the OCL constraint: context C inv: b->includesAll(d).
If we replace the subset constraints with redefines, we get
an instance where C no longer participates in the links of the association a�b, but only in the links of the association c-d, which means that c.b (c an object of C) yields an error. This, of course, renders the a-b association redundant from the point of view of class C and D.
Azzam,
A redefinition implies that collection "d" commandeers the management of collection "b". Thus, if you think of implementing this with operations, C::addD(d: D) will add instances of D to both the "d" collection and the "b" collection. Any instance of C when up-cast to an A will only have instances of D in collection "b". In addition, using A::addB(b: B) will succeed only when an instance of type D is passed and the redefined multiplicity is acceptable. There is effectively only one collection "d" and collection "b" is derived from it.
In contrast, subsetting implies that the "d" collection will contain all the instances of type D, even when they are added through collection "b", and the "b" collection will include instances of type D (possibly in addition to instances of other types), even when they are added through collection "d". This implies that you can add instances of type D to collection "b" or "d". In effect, collection "d" behaves like a filter on collection "b".
-Jim
azzam
--
You received this message because you are subscribed to the Google Groups "UML Forum" group.
To post to this group, send email to umlf...@googlegroups.com.
To unsubscribe from this group, send email to umlforum+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/umlforum?hl=en.