Synchronization of interfaces

[drampulla]

It would be a very convient feature if EA would remember which methods are realized from an interface and update them in the realized classes when the interface changes.

[«Midnight»]

One of the Sparxians posted an explanation of Sparx' reasoning about this issue some time back. You'll have to search for it, but it might be worth your time.

If I remember correctly it was kind of a catch-22. There were compelling problems no matter which way they went.

David

[thomaskilian]

Search for posts from sargasso with keywords "interface contract"

[sargasso]

I say nozzing,

...

yet awhile


bruce  

[drampulla]

I found this posting:  http://www.sparxsystems.com/cgi-bin/yabb/YaBB.pl?board=general;action=display;num=1132682437;start=2#2

I understand that I can redo the the overrides on a per class basis; however it has the following limitations
1. If methods are renamed, it doesn't rename the method, but instead adds an entirely new method
2. Requires a manual step on every class that realizes this interface to get it to update

I guess what I'm asking for is that internally EA maintains the knowledge that methodX in the class actually came from overriding interfaceY's methodX1.   Then whenever methodX' changes, those changes get reflected in all the derived classes' methodX.  

[ocroquette]

I vote for this feature too!

[«Midnight»]

Tricky, but it would be nice to have.

EA would have to maintain some additional state information during the session, but what's wrong with that?

Add my vote!

[sargasso]

No, No, No, No ... No

Let me put it as simply as I can.

The probability of breaking an entire model, build, system, if this was allowed is approximately 99.9997%



What is needed (IMO) is a way to define an interface as being in "prototype" mode.  If so, then changes to the interface should raise big ugly red blobs all over any and all affected classifiers affected.  Then, if it's not in prototype mode changes should be disallowed with 150kV through the keyboard should any idiot try to change it.

While in prototype mode, EA should not change, alter, modify, stuff around with or even think about any affected element.  No name changes, no signature changes, no nothing.

I have seen this happen in three major projects. Some monkey decided that the declared interface "wasn't exactly what he needed" and changed it.  I'd guess the total cost of this was around $AU150k, after we stuffed around for days trying to figure out why libraries no longer compiled, builds broke etc etc.

Changing an interface is a major architectural decision, e.g. lets just change "+" to always return a single precision floating point ..... or maybe define collections to hold a maximum of 1 element ... or strings to be a zero delimited array ...  or "iSerialable.write" to output in EBCDIC.

Do you understand yet???

bruce

[drampulla]

With all due respect the problem you described was not a problem with the tool, it was a problem in the process.  A tool's purpose is to make my job easier to perform, not to restrict me from doing things; unless those things I want to do are completely illogical.  Changing an interface is a perfectly logical operation.  Interfaces change all the time as a product or a design evolves and it would be nice if the tool automated some of that for me.  It sounds like what caused the problem described above was a breakdown in the process.  Someone should have been approving/reviewing changes to the model before it could impact the build process. There should also have been a dependency report generated which would have indicated all the modules/classes/components/whatever that would have been impacted by this change and it would have been rather obvious that all the compilations errors arose from
those classes listed in the dependency report.  Don't get me wrong, I'm not trying to tell anyone how to do their job or follow a process.  I'm just saying different people have different needs and restricting a tool shouldn't be the first response.  I think the first response should be "What do I need to do in my process to enforce this restriction?"

My 2 cents (and obviously I still want the feature   )

[ocroquette]

Some monkey decided that the declared interface "wasn't exactly what he needed" and changed it.  

This has nothing to do with updating the implementation classes automatically when configured so.

The issue you mention can be avoided by :
1. forbidding changes to the interface in the tool
2. forbidding changes to the interface in the review process

To implement 1. you propose to have "locked" interfaces. Why not, but it has nothing to do with the original issue.

By the way 2 is a valid option too.

Changing an interface is a major architectural decision

Not always, for example if you are in preliminary design phase or have control of all the depencencies.
(no, UML is not used only in giant project with big money)

But even when it's a major change in the project, it can be a necessary change. Then it's nice to have support from the tool to make it easier.

[Paolo F Cantoni]

You are ALL right...

We need the tool to supply the controls when the controls need to be applied and to make it easy when we want to make it easy...  It's a balancing act; but a balance, in my view, that IS achievable.

However, to do this requires, I believe, a fundamental change to the way in which EA considers and implements both Realization (copying) and Inheritance/Generalization/Specialization (making available).  Not to mention the changes the the way in which EA handles model evolution overall.

When I've had to manage evolvability of cascading concepts, I've tended to adopt sargasso's approach...  Show what would change as a result and get humans to confirm/deny the change on an affected case by affected case basis.  I have also allowed the automatic application in certain cases - however that required new transformation geometries which EA doesn't yet support.

My suggestion is to start a new thread in the UML category to think about and investigate this.  Needless to say, I previously had one (about 2 years ago) which started to address these questions, [size=13]Generalization vs Realization [/size].

We can either continue/resurrect that one or start another.  But we need to provide clear guidance to Sparx if we are to achieve our collective aims (which, as I said above, I believe is possible).

Paolo

[«Midnight»]

Paolo makes this seem like quite a quagmire.

IMHO he's got it exactly right; murky as it seems, it couldn't be clearer.

David

[cuninghamd]

gets my vote

[midshipman]

I agree with drampulla!!

I will love this feature although it seems difficult to implement it...