Book a Demo

Author Topic: Implementing Redefines in Java  (Read 7469 times)

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Implementing Redefines in Java
« on: September 04, 2005, 08:12:47 am »
In Java, how does one implement the property string redefines?

From page 130, OMG UML 2.0 Structure Spec.:
Quote
redefines <property-name> means that the property redefines an inherited property identified by <property-name>
...All redefinitions shall be made explicit with the use of a {redefines <x>} property string. Redefinition prevents inheritance of a redefined element into the redefinition context thereby making the name of the redefined element available for reuse, either for the redefining element, or for some other.

If it can't be done directly, is there a work-a-round?
« Last Edit: September 04, 2005, 10:19:09 am by jeshaw2 »
Verbal Use Cases aren't worth the paper they are written upon.

thomaskilian

  • Guest
Re: Implementing Redefines in Java
« Reply #1 on: September 05, 2005, 01:03:28 am »
I haven't heard or seen anything like that in EA - but that doesn't mean much ;) I could think of a work around via a Tag "redefines".

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Implementing Redefines in Java
« Reply #2 on: September 05, 2005, 10:25:22 am »
It isn't directly handled in EA, but I have requested that they do so.  

I have tried the Tagged Value approach, but I can't get them to appear on the diagrams.  The display specification for property strings is that they appear inside {curly braces}.  Using the New Text Element tool seems to get the notation on the drawing for now.

The heart of my question is what will the Java code look like when one manually codes this design specification?

In case you're wondering, this issue arrises in the context of specalizing composite classes.  Consider, for example, an abstract composite class Vehicle having as an internal structure two parts:  PowerSource and PowerDriver, which in turn are also abstract classes.  An abstract association, Powers, connects the two parts.  All of these appear on the Class and Composite Structure diagrams.  We are trying to make sure that the PowerSource in a vehicle instance Powers the PowerDriver in the same vehicle instance and not in another. Vehicle may be specalized into things like car, airplaine, boat, or even bicycle.  

Lets specalize Vehicle into Car.  On the Class Diagram, we specalize Vehicle into Car, PowerSource into AutoEngine, PowerDriver into Wheel and show the composite association among the three.

On the Composite Structure diagram, we add the specalized Vehicle Car as having internal parts AutoEngine and Wheel.  We use the Property String Redefines to show that AutoEngine redefines PowerSource and that Wheel redefines PowerDriver.

Having now completed my model, I toss it over the wall to a developer  :D who immediately generates the following Java:
Code: [Select]

// in file Vehicle.java
Abstract class Vehicle {
    PowerSource powerSource;
    PowerDriver powerDriver;
}

//in file PowerSource.java
Abstract class PowerSource{
    String horsePower;
    Public double getHorsePower() {return horsePower;}
}

// in file PowerDriver.java
Apstract class PowerDriver{
    String color;
    public String getColor(){return color;}
}

// in file AutoEngine.java
public class AutoEngine extends PowerSource {}

// in file PowerDriver
public class Wheel extends PowerDriver {}

and now, given that AutoEngine redefines PowerSource, we wish to write:
Code: [Select]

public class Car {
    private double horsePower = AutoEngine.getHorsePower;
}


The problem is that Car inherits a reference to powerSource not autoEngine...  We need to make autoEngine redefine powerSource...How does the developer make this work?  ???  


Verbal Use Cases aren't worth the paper they are written upon.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Implementing Redefines in Java
« Reply #3 on: September 05, 2005, 12:03:23 pm »
Jim,

you might want to see some thoughts on : Generalization vs Realization and forward and reverse engineering.

With the proviso that the forward engineering engine and the reverse engineering engine are NOT the same, I would try reverse engineering the code you expect to be generated and seeing how that behaves, then forward engineering that.

You can make tags visible on the diagrams by using the Show Feature Visibility (Ctrl-Shift-y) dialog.

HTH,
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Implementing Redefines in Java
« Reply #4 on: September 05, 2005, 09:24:31 pm »
Paolo
Quote
you might want to see some thoughts on : Generalization vs Realization and forward and reverse engineering.

That thread is very interesting and related to other Property Strings like Subset.  I'll pick up on those thoughts in that thread.

Quote
I would try reverse engineering the code you expect to be generated and seeing how that behaves, then forward engineering that
My problem is that I don't know what code to expect.  In the Java API, I cannot find a redefines language feature. Therefore, I can't write it for the reverse engineering pass. :'(

Quote
You can make tags visible on the diagrams by using the Show Feature Visibility (Ctrl-Shift-y) dialog.

Yes, but the taged values are only available in class elements.  To specalize an abstract association, I need property strings, on the association ends.  Except for using the Added Text approach, I have not found a way to do that in EA.

I'm beginning to think that both EA and Java come late to the UML 2.0 party  ;D
Verbal Use Cases aren't worth the paper they are written upon.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Implementing Redefines in Java
« Reply #5 on: September 05, 2005, 10:56:21 pm »
Quote
[size=13][SNIP][/size]My problem is that I don't know what code to expect.  In the Java API, I cannot find a redefines language feature. Therefore, I can't write it for the reverse engineering pass. :'(
Ah... I understand, you'll note in that thread I referenced Eiffel...
Quote
Yes, but the tagged values are only available in class elements.  To specialize an abstract association, I need property strings, on the association ends.  Except for using the Added Text approach, I have not found a way to do that in EA.
yes, I understand your problem now...
Quote
I'm beginning to think that both EA and Java come late to the UML 2.0 party  ;D
Java has an excuse... EA doesn't...

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Implementing Redefines in Java
« Reply #6 on: September 06, 2005, 09:26:30 pm »
Paolo
I've been in communication with a major contributor to the UML 2 Composition Model.  According to him, property strings are not meant to be used by code generators.  They are textual elements for human consumption only.  Bummer!

Given that property strings are not supported in Java either, it now seems to me that inheritance of composite classifiers is done manually, prior to coding, with only the final concrete class being written in code.  I guess that really enforces the favoring of composition over inheritance!  ;D

Well, back to the drawing board for additional thinking.
Verbal Use Cases aren't worth the paper they are written upon.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Implementing Redefines in Java
« Reply #7 on: September 06, 2005, 10:40:11 pm »
Quote
Paolo
I've been in communication with a major contributor to the UML 2 Composition Model.  According to him, property strings are not meant to be used by code generators.  They are textual elements for human consumption only.  Bummer!
With due respect to whomever that was, this is patent CRAP!  The property strings either represent renderings of the underlying metadata according to the defined semantics or they don't.  If they do, then they are usable by whomever and whatever wishes to use them.  If they don't, then what function do they serve? {Rhetorical question ;D}  
Any UML tool needs supply whatever controls are required to set/get these metadata.  I expose these properties on my interface and my generators will make use of them (as required/appropriate).
Quote
Given that property strings are not supported in Java either, it now seems to me that inheritance of composite classifiers is done manually, prior to coding, with only the final concrete class being written in code.  I guess that really enforces the favoring of composition over inheritance!  ;D

Well, back to the drawing board for additional thinking.
Did you also look at: What and How should things get Specialized? in your travels?  Would any of that help?

Also, just to be clear by composite classifiers do you mean classifiers with nested sub-classifiers?  If not, can you define the term?

Paolo
« Last Edit: September 06, 2005, 10:40:34 pm by PaoloFCantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Implementing Redefines in Java
« Reply #8 on: September 07, 2005, 07:14:52 am »
Paolo
Quote
Also, just to be clear by composite classifiers do you mean classifiers with nested sub-classifiers?  If not, can you define the term?

Generally, yes, that's what I mean.  However, I need to be carefull about the term nested.  Nested brings to mind the Java syntax of classes defined within other classes.  For example:
Code: [Select]
public class Car() {
...
    private class Wheel() {}
...
}
I've heard of these being called helper classes.

My concept is broader than that. So far in my research, my context is composition via dependency injection. Does Classifiers having an internal structure consisting of other classifiers which are associated either by value or by reference help?  I'm not yet sure I include the helper classes in this concept.  However, I do include multi-level heirarchies of composite classifiers.

For the time being, by classifier I mean class, but I'm keeping my options open to include other classifiers.

I agree with your opinion on my "expert".  Given the nature of the questions I ask, and the amount of reflection needed to answer them, he may have been giving me the brush-off.  But I'm not done pursuing my dreams in the area of specalization.

You have given me a lot of food for thought in the two threads you have referenced for me to read.  A quick scan of them tells me I need to curl up by the fireplace with a bit O'grog and read them deeply.  Lots of good stuff in there.

By the way, have you read:http://www.jot.fm/issues/issue_2004_11/column5?

Cheers,
« Last Edit: September 07, 2005, 07:17:48 am by jeshaw2 »
Verbal Use Cases aren't worth the paper they are written upon.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Implementing Redefines in Java
« Reply #9 on: September 07, 2005, 11:12:42 am »
Quote
Paolo
Generally, yes, that's what I mean.  However, I need to be careful about the term nested.  Nested brings to mind the Java syntax of classes defined within other classes.  For example:
Code: [Select]
public class Car() {
...
     private class Wheel() {}
...
}
I've heard of these being called helper classes.
I thought in Java these were called Inner classes.  Anyway, that's what I mean.
Quote
My concept is broader than that. So far in my research, my context is composition via dependency injection. Does Classifiers having an internal structure consisting of other classifiers which are associated either by value or by reference help?  I'm not yet sure I include the helper classes in this concept.  However, I do include multi-level hierarchies of composite classifiers.
I'm not sure how one can have structural composition by reference?  Can you give an example?  BTW: I'm not suggesting you can't have the same class nested in two superior classes.  This is possible from a specificational point of view.  The instances will, of course, be distinct and will therefore compose into the appropriate superior.
Quote
For the time being, by classifier I mean class, but I'm keeping my options open to include other classifiers.
[size=13][SNIP][/size]
You have given me a lot of food for thought in the two threads you have referenced for me to read.  A quick scan of them tells me I need to curl up by the fireplace with a bit O'grog and read them deeply.  Lots of good stuff in there.
Thanks, I always find trying to get my thoughts down on paper (such that they are intelligible) helps me sort out my "little brain".
Quote
By the way, have you read:http://www.jot.fm/issues/issue_2004_11/column5?

Cheers,
Yes, excellent paper!  Recommended!
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Implementing Redefines in Java
« Reply #10 on: September 08, 2005, 06:36:16 am »
Quote
I thought in Java these were called Inner classes.
Actually, Helper classes are specalized Inner classes which, in turn, are specalized Nested classes.  Note that Nested classes are members of their enclosing class and are wholly dependent upon the enclosing class.

I have two thoughts which lead me to reserve my position on inclusion of Nested classes in a definition of Composite Classifiers:
  • In my mind, a Composite Class is dependent upon its components, not the other way around as with Nested Classes.  The composition of an opera is dependent upon the roles of the singers and the music of the orchestra, not the other way around.  (Now don't start with Shakespear's "A Mid Summer's Night Dream ;D...things are confusing enough for me)
  • I'm not convinced that membership in a class is a composition form of association.  Being a member of the opera does not make one a part of its composition.  If I remember correctly, when I reverse engineered a nested class structure in EA, the resulting diagram showed the two classes with a <<nested>> association and the proper dependency direction, but it did not use the composition diamond.
Quote
BTW: I'm not suggesting you can't have the same class nested in two superior classes.  This is possible from a [UML 2?] specificational point of view.  The instances will, of course, be distinct and will therefore compose into the appropriate superior.
I don't believe this can be realized in Java...However, multiple objects having instances of nested objects could be instantiated....

Quote
Classifiers having an internal structure consisting of other classifiers which are associated either by value or by reference
I may have been a bit cavallier with my language here.  Let's pick this apart:

Classifiers having an internal structure - I mean classifiers appropriately modeled using the UML 2 Composite Structure diagram.

consisting of other classifiers - classifiers playing a role in the context of the composite classifier.

associated either by value - the composite class ownes the component class.

associated by reference - the composite class contains the component (without owning it), but gains access to it via dependency injection.

I am not convinced that ownership is a requirement for composition just as I'm not sure that membership qualifies as composition.

At this point, the typing of an Aggregation, be it Shared or Composite, may enter this discussion.  I have a problem with this.  I know that UML 2 defines Composition as a form of Aggregation and many UML tools must comply with that view.  However, UML comes lately to the OO world and many other OO practitioners convincingly assert that Aggregation is a form of Composition.  Yet a third group argues against any generaliztion/specalization relationship between them.  I suspect that the introduction of the Component Structure diagram in UML 2  is the begining of an attempt to reconcile these views.  I'll be interested in what UML 3 brings to the table in this area.  In the mean time, I'm keeping all options open.

I hope this clarifies my meaning for you.

Cheers



Verbal Use Cases aren't worth the paper they are written upon.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Implementing Redefines in Java
« Reply #11 on: September 09, 2005, 02:31:55 am »
Quote
[size=13][SNIP][/size]

I hope this clarifies my meaning for you.

Cheers
Sure does...
I agree with you that UML's "Composition is a strong form of Aggregation" isn't enough.  I don't have time right now to post a reply (I'm leaving work for home), but it seems to me we need to better define:

Composition
Nesting
Container (Containment)
Collection
Aggregation

so that each has a specific meaning that is (hopefully) disjoint.

Cheerz,
Paolo
« Last Edit: September 09, 2005, 02:32:26 am by PaoloFCantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Implementing Redefines in Java
« Reply #12 on: September 09, 2005, 06:31:01 am »
From another thread you wrote:
Quote
1) Ownership: I control you (including who can access you and who create and destroy you)
2) Nesting: You cannot be accessed, except through me
3) Containment: I hold you within me - but you are not of me
4) Collection: You are in a group
 I like these definitions. To these I've been contemplating:
5) Stewarding/Stewardship: Except by me, you cannot be accessed, but I do not Own you.  (I'm thinking about dependency injection here... perhaps this is a minor variant|extension of Containment?)
Verbal Use Cases aren't worth the paper they are written upon.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Implementing Redefines in Java
« Reply #13 on: September 09, 2005, 07:28:48 am »
Quote
[size=13][SNIP][/size]
5) Stewarding/Stewardship: Except by me, you cannot be accessed, but I do not Own you.  (I'm thinking about dependency injection here... perhaps this is a minor variant|extension of Containment?)
I see... If you're talking about Dependency Injection, wouldn't it be better expressed as:
5) Direction:  Except through my action, you cannot be accessed.
I'm not an expert on dependency injection, but it seems to me that once I've made the injection, I really take no further part in the proceedings.  Have I misunderstood?

Cheerz,
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Implementing Redefines in Java
« Reply #14 on: September 09, 2005, 08:31:40 am »
Quote
5) Direction:  Except through my action, you cannot be accessed.
Two points:
First, it depends upon who is speaking, the Injector or the Injectee.
Second, it depends upon whether or not ownership is implicitly transferred with the injection (as I believe it is in the Spring Framework where dependencies are wired in via an XML file).  Ownership may, or may not transfer when a setter method is used for injection.  UML, in its desire to remain language neutral, my not directly address this concern.  Ah!, but that would not be possible for Nested classes...

In Java, the garbage collector removes objects that have no more references to it.  So, if the Injecting object sets its reference to the injected component(created via a constructor) to NULL, then implicitly, ownership is transfered to the injectee.  When the injectee is destroyed, it will take the last reference to the component with it, leaving the component available for garbage collection.  If the Injecting object retains its reference, it retains ownership of the component.

In languages like C++, someone must take responsibility (ownership) for calling the component's destructor method.

Gee!  A light bulb just went on!  Now I see what you were getting at earlier.  The injector could inject a single instance of a component object into two different composite structures...Then both composite objects would be co-dependent on a single object.  Humm....I'll have to think about this some more.  I think some rules may be violated here...Ah!, but that would not be possible for Nested classes.
« Last Edit: September 09, 2005, 09:30:14 am by jeshaw2 »
Verbal Use Cases aren't worth the paper they are written upon.