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 ... 353 354 [355] 356 357 ... 396
5311
Uml Process / Re: Business processes modelling
« on: July 17, 2005, 03:09:25 pm »
Quote
Kevin,
thanks for clarification :) It's really a different viewpoint.
Well, Thomas, both Kevin and I have the same viewpoint...  ::)

The key thing for me was the "the UseCase being extended must be completely functional in its own right".   Really makes it clearer for me.

Paolo

5312
Uml Process / Re: Business processes modelling
« on: July 12, 2005, 11:20:39 am »
Quote
The use case diagram only shows relationships between use cases, not the flow of events (or to put it more simply, Paolo's right, although this sounds like an <<include>> relationship to me.
Yes, Kevin,

It was late in my day, I'm at home with the "dreaded lurghie" (cold or influenza) and I had a slip of the brain - I agree it should have been an «include»! :-[

However, it does beg the question.  In order to achieve Martin's requirements, we do have to work at the Activity level don't we?  Any ideas?

Taking Thomas's advice, and your observation, I might turn the major UseCase into a diagram; place two Partitions (swimlanes) in the diagram, one representing the major UseCase, the other the included UseCase.  Distribute the Activities or Actions between them (as appropriate) and then use the Nesting relationship to formally bind these to the Partition.  You could then trace these with Automation to derive the information that Martin needs wouldn't you?  What do you think?

Paolo

5313
Uml Process / Re: Business processes modelling
« on: July 12, 2005, 05:39:06 am »
Quote
In my eyes this is simply a Use Case "Push Button" which <<extends>> another Use Case. Create your AD inside that UC and you're done.
I agree with you Thomas.  

But doesn't this approach pose the perennial problem of you only get one extend per pair of use cases.  Suppose in the primary UseCase, Actor1 pushes the button and later in the UseCase Actor2 also pushes the button, don't we under current UML 2 have to define only one «extends»?  This would not meet Martin's requirements as I understand them.

Questioningly,
Paolo

5314
Uml Process / Re: What and How should things get Specialized?
« on: July 11, 2005, 10:08:57 pm »
Quote
[size=13][SNIP][/size]I'd raise the question: is Sparx willing to start a re-design of EA? At what cost? In what time-frame? Are they willing to discuss structural changes in a public forum (probably not, since certain features are EA's USP)?[size=13][SNIP][/size]
Thomas,
I'm in agreement with you that, eventually, a redesign will be required.  But I think that's inevitable in order to correctly support UML2 and beyond.  The other tools are finding this also (notably the Lithuanian Tool).
However, in the interim, I think EA already does a very good job in handling inheritance (from a modelling perspective).  From my external view, it would seem a few "tweaks" would go a long way.

I don't know whether I'm teaching Grandmother to suck eggs here, or I being particularly Homer Simpsonish... ;D  But it only really struck me this weekend that from a modelling perspective (as, perhaps, distinct from a code RTE perspective), Inheritance is about rendering to the descendant class that which is available to it from its ancestors.

Reiterating, EA does a very good job in rendering!  As you point out, Thomas, a little bit more OOO TM and a tiny bit more CCC TM would help, but it doesn't really detract from the fact that EA really helps you, the modeller, understand what's happing in the descendant as a result of its parentage.

1) EA already provides a mechanism for optional display of inherited attributes and operations
2) EA also optionally displays inherited constraints, responsibilities and tags.
3) EA also optionally displays parentage (especially for off-digram parents)

4) EA should be able to display inherited Parameterized Class Parameters, and Arguments (it doesn't display local Arguments - but if it did...)
5) Similarly, it should be able to display inherited Stereotypes.
4) and 5) should be able to be accomplished using the existing techniques - remember all these things aren't propagated into the descendants, they are merely rendered on the diagrams.
Similarly, the special features IsSpecification etc can be rendered to indicate if they are merely inheriting the value or whether the value has been overridden in the current class.
The other features, I'm not too fussed about at present.  Indeed, I've not fully thought out whether scenarios are inherited, but my suspicion is they are.  So these others can wait for the redesign.

In my view, the leverage to be gained by implementing 4) and 5) above will repay, what I believe to be, the relatively simple enhancement to existing processes.  And provide yet another USP for EA?

Cheerz,
Paolo

5315
Uml Process / Re: What and How should things get Specialized?
« on: July 11, 2005, 09:41:08 pm »
Quote

No, what you need to do is trawl through the Class Descriptions and look at the superclass pointers under the heading "Generalizations". Alternatively, you can search the diagrams in the Abstract Syntax sections.

You will find that Kernel::Feature generalizes Kernel::StructuralFeature, Kernel::BehavioralFeature, InternalStructures::Connector, and nothing else. Now repeat for each of those...
KP,

If you're talking about the Superstructure document, I did check Kernel::StructuralFeature and Kernel::BehavioralFeature before posting.  I didn't find anything that inhibited the list I gave as not being either a structural or behavioural feature.  For example, you could define a Stereotype as a behavioural feature with no parameters.  Or Parameterized Class parameters as Structural Features.

But as I indicated, if your view is correct; then EA has already deviated from the UML standard - in which case complete the job.  If my view is correct, EA has partially implemented the standard, -in which case complete the job.  The outcome is the same.

Paolo

5316
Uml Process / Re: What and How should things get Specialized?
« on: July 11, 2005, 09:32:09 pm »
Quote
Hi Paolo,
at first I wrote a pretty long answer to you message, but than I found out that I am not that good with EA yet, to argue with you :) So I have following three questions.

What you mean with "Redefining" ?
What you mean with "Undefining" ?
What you mean with "Renaming" ?
Hi Martin,
I'll take the easier one first...
Renaming:  When you multiply inherit, you may inherit the same named feature from more than one parent.  If the both features are actually instances of the same feature (but by different routes) then the signature should be identical and renaming isn't required.  However, if the signatures are different and the semantics are different, then we can't have two different features with the same name at the same time, therefore we need to rename one.
Given we can (must) rename in the multiple inheritance environment, we can also rename for single inheritance.  For some valid reason, we may want to name an inherited feature differently in the child than in the parent.  Vehicle carries Items, Bus carries Passengers and so on.
Redefining: If the name remains the same, but the signature changes then we are redefining what that name means.  BTW, I'm not formally defining what the term signature means here.  Also, see below on language examples.
Undefining: When abstracting, you often come across a situation where you may have a number of subtypes, most are the same but some don't inherit all of the Features of the Parent.  If you require that the child inherit ALL the features of the parent, you end up creating complex hierarchies to achieve that.  However, if you can say A is a B except if doesn't do q then you can create more compact hierarchies that better express the taxonomic relationships.  The process of restricting a feature from the descendants is known as Undefining.  The outcome is that the child (and its descendants) can't use the feature.

You can get a more precise definition of these terms in: Chapters 14 & 15 of Object-Oriented Software Construction by Bertrand Meyer.
Quote
Can you write some short examples to those three, say, in C++ ?
Well, not really, most languages don't actually support these concepts directly.  C++ is quite problematic here as it allows multiple definitions of the same operation name with different signatures to be considered the the same operation. (I think that's the correct way to describe it - language experts can correct me).
Renaming is NOT allowed in C++ (I believe) - if you inherit the same named feature, you need to rely on C++'s signature recognition.  Otherwise - tough.  Virtual inheritance is a method for telling the compiler that the feature derived by multiple routes is the same feature.
Redefinition in C++ is normal overriding.
Undefining isn't allowed in C++ (as far as I know)
Quote
I am not sure if you don't want too much from the inheritance in EA. Personally I need EA supporting some "standard" inheritance, where this "standard" is unambiguous.

Regards Martin
Well, in my view, EA claims to be a UML tool.  The UML is quite (perhaps not completely) clear on what inheritance means.  EA should conform.  In another post, I'll be suggesting how conformance might be achieved in stages.  The problem for EA is that it is also used for Code round-trip-engineering and as I have said, not all languages support all of the UML concepts (nor even in the same same way sometimes).  My feeling, is that by ensuring they support the UML properly, they get a better handle on how to interface to the physical languages they have to (decide to) support.

HTH,
Paolo

5317
Uml Process / Re: What and How should things get Specialized?
« on: July 11, 2005, 07:19:37 pm »
Quote
According to UML, attributes (aka Properties) are Features, Operations are Features. Nothing else in your list.
KP,

Can you give the exact reference to support your assertion?  You are correct that Attributes are Features and Operations are Features, but not, in my view from the quoted definitions I gave, that they are the ONLY features.  

In any event, if this were so, why does EA itself (optionally) display "inherited" Constraints, Responsibilities and Tagged Values?  You can't have it both ways...
Quote
Of course, inheritance will take on specific (trying to think of a word that has no UML meaning but approximates to property, feature, attribute... quality?) qualities of the parent in the child, and some of the items in your list will come into that category. For example, Operation may own an ordered set of Parameters, and that set should be inheritable. I will investigate further...
Why not use the UML word?  Characteristics - they chose it for a reason. ;)

BTW by parameters and arguments, in my list I was specifically referring to the Parameters and Arguments of Parameterized classes.  I took it as self evident that parameters and arguments of Operations would be inherited.

Cheerz,
Paolo

5318
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






5319
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

5320
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

5321
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

5322
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

5323
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

5324
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

5325
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

Pages: 1 ... 353 354 [355] 356 357 ... 396