Generalization vs Realization

[Paolo F Cantoni]

...Or what should/gets inherited/transferred/made available when we Generalize a Class (from descendant to ancestor) or Realize a Interface/Class(from specification to instance - although the link is drawn from instance to specification).

As a result of a request from Alexander, I'm opening a thread to discuss these topics.

The starting point is the agreement that Alexander and I have that normal "inheritance" should be modelled as Generalization and that the instantiation of a specification should be modelled by a Realization.

When we use the Generalization relation, EA conveniently provides a number of (optional) services to us, the modellers:
You can view the names of the immediate parents of the Class (if they are off diagram - but you can't as yet list the entire ancestry)
You can view the inherited Features, attributes and operations, (with some, though not complete indication of Feature override).

These services appear to work pretty well for multiple inheritance but do not allow you to handle the full range of issues concerned with multiple inheritance (such as those identified in Chapters 14 & 15 of Object-Oriented Software Construction by Bertrand Meyer).

When you actually attach the Generalization, EA will copy (not inherit) the stereotype of (one of) the multiple immediate parents.

I haven't done a lot of round-trip engineering with EA (since I've taken an alternate path and my principle concern at present is the generation of conceptual models) however, I did to enough to discern that if you create a Realization link, and forward engineer and then reverse engineer, then EA will remove the Realization link on import and replace it with a Generalization link.

The reason is that on forward engineer, EA creates what appears to be an inheritance and, naturally, on import can't distinguish between them.

So that's enough to kick off the discussion...

Some questions to consider:
What is the essential difference between the Generalization and Realization relationships?  I think, but it's not a well formed thought as yet, that there are many similarities and some distinct differences between the two relationships.
Assuming we can come to agreement on these similarities/differences, what should EA display (provide via API) when we make that kind of linkage between two classes.
In addition to the "inheritance" of Features, should other properties of the ancestor Class (IsSpecification, Stereotypes, Tagged Values etc) should also be made available (in one way or another) to the descendant class.

Finally, what is the relationship between a Parameterized Class (the closest EA currently gets to a full UML 2 Template) and the instantiated (bound) Class therefrom.

For the purposes of this discussion, I'd recommend using the UML 2 Superstructure Specification as the normative reference.

Let the games begin...

Paolo

[alexander]

The specification states that a generalization should inherit all the 'features' of the father into the son.

My first question is, should attributes be considered features? I have been unable to make EA inherit attributes unless they where specified as properties in which case only the setter and getter methods where inherited.

My second question is, should it be possible to inherit only some of the features of the parent without an explicit overwritte? EA allows to select the methods to be inherited enabling only part of the features to be in the child class.
Realizations have the same issue, but i find it usefull since some times i want to specify an interface that is realized by several concrete classes and i don't want to design a delegator between to map each of the methods to the class that implements it.

I haven't been able to give a scope to what 'features' of a clasiffier could mean, i will try again tomorrow to search throu the documentation for some insight into.

[Paolo F Cantoni]

The specification states that a generalization should inherit all the 'features' of the father into the son.

My first question is, should attributes be considered features? I have been unable to make EA inherit attributes unless they where specified as properties in which case only the setter and getter methods where inherited.

Alexander, your problem may be in the use of the word inherit.  Inherit does not mean copy, it means make available.  Thus if you show the inherited attributes and operations on the Diagram, you will see how EA makes them "visible" in the descendant class.  If you don't see this at the Diagram level, then that's your first problem.  We need to solve that first.
You are able to override both the attributes and operations.
If your question is directed at the language code generation, then that's a separate issue.  As I mentioned I don't have a lot of experience with EA code generation (and particularly with Round-trip-engineering) but I didn't notice any problems in this regard (apart from that which I mentioned).  Perhaps others could comment

My second question is, should it be possible to inherit only some of the features of the parent without an explicit overwrite? EA allows to select the methods to be inherited enabling only part of the features to be in the child class.

Yes, I too am of that view - you can only perform part of the inheritance services mentioned by Bertrand.  

Realizations have the same issue, but i find it useful since some times i want to specify an interface that is realized by several concrete classes and i don't want to design a delegator between to map each of the methods to the class that implements it.

I haven't been able to give a scope to what 'features' of a classifier could mean, i will try again tomorrow to search through the documentation for some insight into.

Paolo

[alexander]

Ok, so the methods you select when generalizing are the ones you want to override and EA helps you by copying the method firm so you can override the behaviour?
I finally found the option to make the inherited features show in the diagram, it was in the class's feature visibility option.

I think it is important to discuss the difference between inherit and copy, the problem is that inheritage is usually implemented by copying the parent's features into the son. But i see why u separate them and complain when EA does that to inherit stereotypes.

Perhaps we should discuss if copying the stereotypes and tags is really the best way to implement these features inheritage. I have always found dissapointing the way EA allows you to select types and stereotypes by 'name' instead of by reference, not helping you to centralize types and  stereotypes definitions. The same politic seems to be all over the place, when selecting operations in the comunication's messages, when selecting roles in an association, and so on... I fail to see the advantage of this 'relaxation' of references.

I will try to make some round trip tests and see how 'realization' is implemented in different languages.

[Paolo F Cantoni]

OK, so the methods you select when generalizing are the ones you want to override and EA helps you by copying the method firm so you can override the behaviour?
I finally found the option to make the inherited features show in the diagram, it was in the class's feature visibility option.

Yes, you need to manually override the attributes.

I think it is important to discuss the difference between inherit and copy, the problem is that inheritance is usually implemented by copying the parent's features into the son. But i see why u separate them and complain when EA does that to inherit stereotypes.

I think that is a language dependent issue.  Not all languages require that.  I will leave that up to the language experts.

Perhaps we should discuss if copying the stereotypes and tags is really the best way to implement these features inheritance. I have always found disappointing the way EA allows you to select types and stereotypes by 'name' instead of by reference, not helping you to centralize types and  stereotypes definitions.

Yes and no, the problem is that UML does not require references, just names.  Also when you import you may encounter previously unknown stereotypes.  As a Data Management person, I can provide patterns that can automatically accommodate these new stereotypes, but they require a small amount of work to set up.

The same politic seems to be all over the place, when selecting operations in the comunication's messages, when selecting roles in an association, and so on... I fail to see the advantage of this 'relaxation' of references.

Since EA is based upon a repository (one of its great strengths) as I said before it's a little bit (but only a little bit) more difficult to retain referential integrity, but provide the flexibility of accommodating new values.  In my experience, most programmers have little or no idea about DB design.  (No particular reflection on the Sparxians - how much time did your lecturers spend on DB design?)
Even though EA has defined relationships (open the .EAP file with MS Access  and look at the Relationships screen) - Referential Integrity is not enforced.

I will try to make some round trip tests and see how 'realization' is implemented in different languages.

That should prove interesting, please let us know what you find.

Paolo

[Paolo F Cantoni]

[size=13][SNIP][/size]
I think it is important to discuss the difference between inherit and copy, the problem is that inheritance is usually implemented by copying the parent's features into the son. But i see why u separate them and complain when EA does that to inherit stereotypes.
[size=13][SNIP][/size]

Alexander,
I've thought some more about this and it seems to me that one of the essential differences between Generalization and Realization is that:
Generalization is never a copy and Realization is always a copy!

In Generalization there are a number of concepts in play when you wish to change the nature of the availability of the feature:
1)  If you have repeated inheritance, then you need to determine whether the repeated feature is the Identical via all paths (or not).  If not, then you may have:
2)  If there is a naming conflict (two different features with the same name) then this must be resolved via Renaming.
3)  If you wish to have a feature with the same name as the inherited one, but with a different implementation, then you need to Redefine (Override).
4)  If you wish to make an Abstract feature Concrete, you need to Effect it.
5)  If you wish to hide, defer, undefine a Concrete feature - so that is is no longer available to your descendants, then you need to Undefine it.

Similarly, in Realization, there are a number of concepts in play:
1)  The nature of the transformation in the Realization process.  Are you Realizing (instantiating) an Interface? - in which case the signatures of the features MUST be identical - even though the implementation may vary.
2)  Are you Realizing (Instantiating) a Template? - in which case the signatures may vary according to some transformation rules - such as object or name substitution.
3)  During Template Realization are you Binding to the Template? - Such that the instantiated Class (or the Template or both) retain knowledge of the linkage and also the instantiation process for that Class.

Does this help?

Paolo

[alexander]

I think we are falling into the implementation of the relationship here.
As i understand it Realization is the implementation of the specification given by one model element by another. It is only logic, that the element providing the method specification's firm is copied into the element implementing it.
But that doesn't mean that copy is the only way to implement this behaviour.

I agree that copy is a bad implementation for inheritance because of the elements you mentioned.

In regard to the previous answer, are u sure UML doesn't require reference and only names? i have never found anything in the specification that would lead me to the conclusion that the relationship of any of the elements i mentioned was merely a 'name' reference.
It seems to me the model would be much more powerfull if the link of these associations was stronger.

[Paolo F Cantoni]

I think we are falling into the implementation of the relationship here.

Alexander,

I can now see I wasn't as careful in my choice of words as I should have been...  When I used the word copy I guess I really meant that an actual feature exists in the client (which one could - without too much trouble look as a transformed copy of the supplier feature specification) as a result of the Realization.  In the case of Generalization, there is no actual feature, just the availability (or access) to the feature - which EA nicely presents on the Classifier display in the Diagram.

As I understand it Realization is the implementation of the specification given by one model element by another. It is only logic, that the element providing the method specification's firm is copied into the element implementing it.
But that doesn't mean that copy is the only way to implement this behaviour.

Yes, your understanding of Realization is correct (or at least it's the same as mine... ).  I also agree that, initially, you don't need to provide an actual feature (just as with Generalization).  However, the whole intent of Realization (as far as I can see) is to provide some instance in the client from the supplier.  Whereas in Generalization the opposite is the intent (to reuse features in the supplier).

I agree that copy is a bad implementation for inheritance because of the elements you mentioned.

We are in violent agreement then!

In regard to the previous answer, are u sure UML doesn't require reference and only names? i have never found anything in the specification that would lead me to the conclusion that the relationship of any of the elements i mentioned was merely a 'name' reference.
It seems to me the model would be much more powerful if the link of these associations was stronger.

There is no specific requirement in UML for there to be a separate process for the definition and referencing of stereotypes (although one might be implied).  However, I strongly agree it would be good for a tool to manage stereotypes better.

Paolo

[SF_lt]

Realization doesn't create father-son relation as opposite in a generalization case.
And forward and backward engineering can't change this - if EA does it, it's the bug.

Generalization:
A -> B --> class A : public B{}
A is B also
Realization:
A -> B --> class A{}
A isn't B

Generalization copies everything from father to son - attributes and methods, there is no way to prevent copying (but there is a way to forbid to use some father's features).
Realization requires copy only methods and their functionality, there is no requirement to copy attributes

[Paolo F Cantoni]

Realization doesn't create father-son relation as opposite in a generalization case.
And forward and backward engineering can't change this - if EA does it, it's the bug!

Yes, SF_lt, it is a bug.  Although convincing Sparx of this was (maybe is still) problematic.  You are correct in pointing out that Realization ISN'T an ancestral relation, hence:

Generalization:
A -> B --> class A : public B{}
A is B also

To be precise, an A is also a B (that is, we use the instances to denote the ancestry - "a cat is also an animal")

Realization:
A -> B --> class A{}
A isn't B

Generalization copies everything from father to son - attributes and methods, there is no way to prevent copying (but there is a way to forbid to use some father's features).
Realization requires copy only methods and their functionality, there is no requirement to copy attributes

I have two issues with the last part of your posting:
1)  We need to be very careful (as I discovered) with using the word "copy".  In another thread (on Inheritability of Stereotypes), Sparxian KP correctly points out that EA copies a Stereotype (from ancestor to descendant) when you add the Generalization link - it doesn't inherit it.  If you remove the Generalization link afterwards, the copied Stereotype remains!  Now you can (as I do) disagree with this functionality, but it DOES serve to clearly differentiate between copy and inherit!  In addition, the UML 2 Superstructure Specification (abridged) clearly states that:

7.3.20 Generalization (from Kernel, PowerTypes)
A generalization is a taxonomic relationship between a more general classifier and a more specific classifier. Each instance of
the specific classifier is also an indirect instance of the general classifier. Thus, the specific classifier inherits the features of
the more general classifier.
Description:
A generalization relates a specific classifier to a more general classifier, and is owned by the specific classifier.
Semantics:
Where a generalization relates a specific classifier to a general classifier, each instance of the specific classifier is also an
instance of the general classifier. Therefore, features specified for instances of the general classifier are implicitly specified for
instances of the specific classifier. Any constraint applying to instances of the general classifier also applies to instances of the
specific classifier.

whereas:

7.3.45 Realization (from Dependencies)/
Description:
Realization is a specialized abstraction relationship between two sets of model elements, one representing a specification (the
supplier) and the other represents an implementation of the latter (the client). Realization can be used to model stepwise
refinement, optimizations, transformations, templates, model synthesis, framework composition, etc.
Semantics:
A Realization signifies that the client set of elements are an implementation of the supplier set, which serves as the
specification. The meaning of ‘implementation’ is not strictly defined, but rather implies a more refined or elaborate form in
respect to a certain modeling context. It is possible to specify a mapping between the specification and implementation
elements, although it is not necessarily computable.

2)  I have often seen your assertion that Realization only copies the methods.  (for example:A SIMPLIFIED, PRACTICAL OVERVIEW OF
UML CLASS DIAGRAMS):

Realization is another special form of inheritance where the child class inherits the declaration of a class or interface operation, but not its definition.  This means that the the child inherits only the "signature" of an operation, i.e. the operation name along with its arguments.  This relationship is mainly used between an interface and a class that "implements" that interface. i.e. the developer is required to define all the operations declared in the interface.   (Remember that the interface construct is not available in all OOPL, e.g. C++, so this is not relevant to C++ (although it can be simulated).)

However, I think this view violates the definition in the Superstructure document.  In particular, UML 2 specifically states that Realization is a Dependency, whereas Generalization (inheritance) is a Taxonomic relation.  Therefore, a Realization (as you yourself pointed out), CANNOT be a form of inheritance.

I think the key point is that in Generalization there is NO implementation in the client (unless overriding or effecting) whereas in Realization there is ALWAYS an implementation.

HTH,

Paolo

[SF_lt]

infrastructure and superstructure is right thing, but in most cases I find them too formal, too abstract. And without provided examples this is a source of many fallacies. Guess, not only for me
This partly is corrected by books, but again - not everything is covered :-/

[Paolo F Cantoni]

infrastructure and superstructure is right thing, but in most cases I find them too formal, too abstract. And without provided examples this is a source of many fallacies. Guess, not only for me
This partly is corrected by books, but again - not everything is covered :-/

Yes, the Infrastructure and Superstructure are formal and abstract - but they are necessary to provide a normative reference.

I, too, would like more provided examples...  In fact, given they have now published the XMI standard, I'd like them to publish an XMI export of the model itself!

And you are right, even the books don't cover everything.  In particular, good books that effectively cover UML 2 are hard to find!  That's why this forum is so useful.

Regardz,
Paolo

[Paolo F Cantoni]

[size=13][SNIP][/size]
Yes, the Infrastructure and Superstructure are formal and abstract - but they are necessary to provide a normative reference.
[size=13][SNIP][/size]

However, it should be noted that although the OMG UML documents provide a normative reference, they aren't necessarily correct in all places.  Certainly in some places there are (deliberately?) vague.

A possible example of self-inconsistency is the use of Generalization itself!  As a colleague pointed out to me on Friday, most UML connectors represent (and are named) the relationship of the client (source) with respect to the supplier (target, destination or sink).  Thus for example, Realization - the client realizes the supplier.  With Generalization, you can't say the client generalizes the supplier - it's the other way round) .  Perhaps, the relationship should be called Specialization?

Consistency, Consistency, Consistency! ^TM

Cheerz,
Paolo

[alexander]

If you review the superstructure document you can see how most of the examples were added after the first couple of revisions so you can probably conclude that the discussion where this documents are created must be in a very theoretical and abstract way.

I have also struggled with the direction of some of the relationships, it would make a LOT of sense if they would 'design' the relationships so all would follow the flow of specification.
Take for example: include, extend, generalize and realize; include is from client to supplier, extend is from supplier to client, generalize is from client to supplier but you must ignore what all logic the name can provide, generalize is from client to supplier.
The worst thing is this four relationships appear in the same diagrams, for example, use-case diagrams, where dependencies are impossible to follow if you let yourself be guided by the direction of the relationships (I usually end up using some explicit 'dependency', or 'trace' relationships for this)

[thomaskilian]

(I usually end up using some explicit 'dependency', or 'trace' relationships for this)

The same with me. Funny that introducing a multitude of relation representations leads to users just utilizing a few of them. I still remember how long it took until I realized the rough semantics of these relations.