Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Paolo F Cantoni

Pages: 1 ... 349 350 [351] 352 353 ... 391
5251
Uml Process / What and How should things get Specialized?
« on: July 10, 2005, 11:30:15 pm »
Hi,

Following my posts on:It's pretty obvious I'm interested in Generalization/Specialization/Inheritance.

This thread is about discussing what and how should things be inherited when we connect two classes with the Generalization connector.

First, a few (hopefully normative) definitions.  If we can't agree on the definition, then they are what we should discuss, not the consequences therefrom.  Once we agree on the definitions, we can discuss the issues.

The UML 2 Superstructure Specification (abridged):
Quote
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.

This definition sounds good enough to me - although the impact of the definition isn't always clear (to me).

The key point about the definition is that the specialized classifier is an implicit or indirect occurrence of the generalized classifier.  Thus we can correctly say (in English) the descendant inherits the characteristics of the antecedent (ancestor).  Or the child inherits from the parent.  The inheritance manifests itself in the availability of the current feature signature and implementation in the parent to the child.

Because of the different ways in which the different languages manage Inheritance, I'm going to use a more generic set of concepts - which I'll define as I go along.

First of all, we need to recognise that the definition provides for an inheritance hierarchy.   By convention, we place the ancestors toward the "top" of the hierarchy and the descendants toward the bottom - which requires we understand that anything that is defined higher up the hierarchy is available to everything lower down the hierarchy.  This is also true of multiple inheritance.

In order for a feature (defined later) to be made available to a child, it must have it's signature (to be defined later) defined in the parent.  That is, we must know enough about the feature to be able to reference it in the child.

Once defined, a feature can be given effect (implemented or effected).  For any given descendant, the process of making the feature available is by (upward) traversal of the hierarchy until an effected definition of the feature is found in an ancestor.  That version of the feature is made available to the descendant.

A descendant may chose it's own version of the feature by one of a number of methods:
  • Redefining - where the signature of the feature is changed.  By implication, the feature is also reeffected.
  • Reeffecting - where the signature remains the same, but the implementation is changed.  If the feature has only been previously defined (usually designated abstract), this is usually known as implementing; if already implemented, this is known as overriding.
  • Undefining - where the definition is no longer available (to the descendant or its children).
  • Renaming - where the name is changed (for this descendant and its children)

If you are having difficulty visualising some of these concepts, EA itself can help you!  If you pick a class on a diagram for which you know there are ancestors, and use Set feature visibility (Ctrl-Shift-Y) to enable ALL the actual and inherited features, then EA current does a useful (but not complete job of visualising what's currently happening to the descendant class...
You will see that EA shows you which currently available attribute or operation is provided by which ancestor.  In addition, if you enable all the other compartments, you will see the same for Responsibilities, Tags and Constraints.

So, it seems to me, when we link a class to its parent by Generalization, we need to specify for each inherited feature if the descendant is going to change the version of the feature.  EA does that to some extent - it asks you which operations you wish to override when you first make the connection.
What EA (and other tools) don't seem to do is to retain memory of why a particular feature exists in a class.  For example, if I reeffected a feature (overrode it), and I no longer inherit the feature - because I'm now inheriting from another class or no class, shouldn't the tool at least ask the question "Do you still need this reeffected feature?"  Or when you link to a new class and there is a feature with the same name in both the parent (and all ancestors) and the child, it should ask what is to be the relationship between the two?

Finally, what do we mean by Feature?  Well, the UML 2 Superstructure Specification is pretty clear here:
Quote
7.3.20 Feature (from Kernel)
A feature declares a behavioral or structural characteristic of instances of classifiers.
Description:
A feature declares a behavioral or structural characteristic of instances of classifiers. Feature is an abstract metaclass.


So, it seems to me that ALL the behavioural and structural characteristics should be inheritable, this includes:
  • Attributes,
  • Operations,
  • Constraints,
  • Responsibilities,
  • Parameters(in the case of Parameterized Classes)
  • Arguments(in the case of classes bound to Parameterized Classes)
  • Stereotypes
  • The special characteristics: Persistence, IsSpeciaifcation, IsAbstract etc
  • Tagged Values
  • Scenarios


Well, that's what I think...

Discussion welcome.

Paolo






5252
Uml Process / Re: Generalization vs Realization
« on: July 10, 2005, 07:04:42 pm »
Quote
[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

5253
Uml Process / Re: Generalization vs Realization
« on: July 07, 2005, 03:33:46 pm »
Quote
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

5254
Uml Process / Re: Generalization vs Realization
« on: July 06, 2005, 02:34:28 pm »
Quote
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:
Quote
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")
Quote
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:
Quote
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:
Quote
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
):
Quote
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

5255
Uml Process / Re: Generalization vs Realization
« on: July 06, 2005, 06:26:00 am »
Quote
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.
Quote
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... ;D).  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).
Quote
I agree that copy is a bad implementation for inheritance because of the elements you mentioned.
We are in violent agreement then! ;D
Quote
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

5256
Uml Process / Re: Generalization vs Realization
« on: July 06, 2005, 01:31:04 am »
Quote
[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

5257
Uml Process / Re: Generalization vs Realization
« on: July 05, 2005, 07:12:13 am »
Quote
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. :(
Quote
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.
Quote
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.
Quote
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.
Quote
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

5258
Uml Process / Re: Generalization vs Realization
« on: July 04, 2005, 06:40:18 pm »
Quote
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
Quote
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.  
Quote
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

5259
Uml Process / Generalization vs Realization
« on: July 04, 2005, 07:05:50 am »
...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

5260
Uml Process / Re: Parameterized Interfaces
« on: July 08, 2005, 08:53:30 am »
Quote
Hi Paolo,
just to be sure I understood your question. Do you want to model something like "templates" in C++ ?

Regards Martin
Yes, Martin more or less...  I really want to create UML 2 templates, but the closest EA comes to them at present is Parameterized Classes.

The problem is compounded by the fact that C++ doesn't actually have Interfaces (say like Java and C# do).  We simulate an Interface by using a pure virtual Class.

Anyway, I want to be able to template Interfaces...

Paolo


5261
Uml Process / Parameterized Interfaces
« on: July 08, 2005, 01:24:36 am »
Today,  I had occasion to want to create a Parameterized Interface.

My reasoning was:  I use Parameterized Classes to enable me to define a set of Classes with identical characteristics but different instantiations.  Parameterised Interfaces would allow me to do the analogous thing...

EA won't let me create a Parameterized Interface, because it doesn't allow you access to the Detail tab of the Classifier.  That's no problem, says I, I'll just change the element to a Class, pop in the parameters and switch it back to an Interface - just like I have to do if I want to add a linked diagram or add a feature (by the scenic route). ::)

Imagine my frustration when, having added the parameters, the the parameters disappeared when I switched the element back to an Interface! :'(

Before I submit a formal bug report to Sparx, is there any reason why I shouldn't be able to create Parameterized Interfaces?

Cheerz,
Paolo

5262
Uml Process / Re: Altering Default Views in an EA project
« on: July 06, 2005, 04:26:26 pm »
Hi,

I have arbitrarily named View packages within multiple Project packages in a .EAP repository.

My environment is therefore not the same as yours,but so far I haven't experienced any problems...

I've generated code sing my own code generation templates, but I haven't used XMI since I reorganised.

Do you have specific issues with XMI?

HTH,
Paolo

5263
Uml Process / Re: Own defined attribute types
« on: July 03, 2005, 08:57:52 pm »
I've just had a look at the UML 2 Superstructure specification and it seems to me that the current EA rendering of an «Extension» association is incorrect.  The open arrow should be a closed, blocked in, arrow.

Cheerz,
Paolo

5264
Uml Process / Re: Own defined attribute types
« on: July 03, 2005, 07:50:51 pm »
Quote
Hey Martin,

I defined my attribute stereotypes by creating my own UML modelling profile (see the "Create a UML profile" topic in the help file).

[SNIP]

Pascal.
Hi Pascal,

I haven't got into Profiles as yet - for the present they don't seem to give me very much I can use at the current stage I'm at with my models.  [Not a criticism of EA, just an observation of where I am in relation to the questions I'm about to ask]

Do I understand correctly, that a profile gives you the ability to predefine a stereotyped element with preexisting tagged values (derived from attributes tab in the original extending stereotype) and constraints (derived from the constraints tab of the extending stereotype)?

You can merge a new definition of the stereotype with existing definitions.

Since I'm not yet using tagged values, this doesn't seem to give me much over simply stereotyping the original element.  Or have I missed something?

Also, does this work with multiple stereotypes?  Have you confirmed it does?  (Particularly if the profiled stereotype is not the primary one?)

If I correctly stereotype my elements and later create profiles, can I use the merge mechanism to add the profilable features to my existing elements using the profile merging mechanism?

Do you have any idea what the <Redefinitions/> clause is used for in the actual profile XML?

Cheerz,
Paolo



5265
Uml Process / Re: Is Specification - should it inherit?
« on: July 02, 2005, 06:30:54 am »
Quote
I agree with Paolo, specification should be inherited, but only if u are trying to create a new specification, it instead u are trying to create a class that is built to that specification u should use 'realize' (which doesn't inherit the stereotype). For that purpose, the 'IsSpecification' property should also be inherited.
Alexander, I'm not clear on what you are saying here.  Your words seem a bit self-contradictory.

Are you saying that for normal inheritance (Generalization), IsSpecification should inherit, and for Realization (the creation of a client according to the supplied specification), IsSpecification shouldn't inherit?  If you are, then I agree.
Quote
I remember that discussion about stereotype inheritance, i would like to know if u (Paolo) have been working to build something to implement this in EA and the problems you've discovered. If there is a topic where u have continue discussing this, can u point me to it?

The discussion on inheritability of stereotypes is found here:
http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=UMLPRO;action=display;num=1115649626
Additional discussions on multiple inheritance are found here:
http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=UMLPRO;action=display;num=1118716834;start=0#0
I have been working on some things, which may or may not be of interest to you.

The issue is compounded by EA's (self-)inconsistent behaviour when creating Generalization links.  Thomas Kilian was the first to raise the question as to whether EA has been built using OO principles, but he only beat me to it by a couple of days.
The way in which EA implements multiple stereotypes also doesn't help...

As it happens, based on my experiences over the last few weeks I was about to publish some thoughts on the questions of Generalization, Realization, Parameterized Classes, UML 2 Templates and so on.

If you are interested I can start a new thread on these.

Cheerz,
Paolo

Pages: 1 ... 349 350 [351] 352 353 ... 391