updating an interface

[soril]

A class realizes interface I, When I link them up, I can clearly see that A implements I, but when I modify the interface of I, A is not updated to reflect the changes but it is still realizing I , why ? Any way to synchronize A ?

Have a nice day !

Sébastien

[Andreas_G]

Hi Sébastien,

have a look to the thread http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=general;action=display;num=1121095867

bye
Andreas

[sargasso]

At the risk of inciting "swakal"  

An interface is a contract.  Don't know where but I recall reading this in many places.

If you define the architectural contract, and handed it off to the builder, got s/him to start building and then decided you wanted to change the contract,  why would you expect s/him to "automatically" change what s/he is building because you unilaterally changed the contract?

Same with UML interfaces.  


bruce

[mikewhit]

Google gives:

swakal  (also -swapal) i. to come quickly, to hurry, to be easy: _ (ku) makàs to have quick hands

Or acronym ?

[thomaskilian]

This is likely Aussie slang
But Bruce is right. An interface is nothing to be changed on the fly. And the comparison with a contract is excellent.

[soril]

Hey guys!

Thank you for your help, I think you're right and an interface (or a contract... should not be changed so "automatically", but since EA allows to override implementation, it can be useful to use it after you noticed a change as it saves time. EA offers the best of the two worlds !

I haven't tried the "synchronize" (nor MDG Link) yet, but I wonder if you change the code, the corresponding model, for example the implementing class will be updated as well to show that now it implements the new interface. If yes, then it can be a poweful tool and the need for automatic override implementation is less important if you use that kind of strategy. Even better, if there was a tool that could tell you the "changes" that need to be made to the code to reflect new conceptual model given some source files and offer you to synchronize automatically or step by step. If that tool could handle all kind of diagrams then it would be a must, but even only the conceptual model would be a start.

Sébastien

[Paolo F Cantoni]

This is likely Aussie slang
But Bruce is right. An interface is nothing to be changed on the fly. And the comparison with a contract is excellent.

As a certified Aussie (I wasn't born here but I have a beautiful certificate...  )  And having lived all over Oz, I don't think it is slang.  We'll just have to wait for bruce to enlighten us...

An Interface is the specification of the contract.  Each Realization is an implementation of the contract according to that specification!

In the discussion on:Generalization vs Realization I point out that Realization is a (essentially) copy.   Thus we have the problem of comparing the copy with the original.  Programming languages typically check that the implementation conforms to the specification and will generate a compilation error on failure.

However, in the model this is more problematic as we don't (as yet) compile the model and check that the Interface Realizations still conform to the referenced Interface.  Following on from my (somewhat controversial) thread on What and How should things get Specialized?  I was going to publish some thoughts on What and how should things get Realized?.  So This discussion is very useful for me.

Sébastien, Everyone is right to warn against changing interfaces.  I'm also pretty comfortable in assuming that you understand this also.  Explicit and implicit changing of the contract is one of the greatest sources of difficult to find problems in any system of other than trivial size.  However, you imply that by having a model, you should have more flexibility in this - and you are right!  The problem is how to achieve it?

I recently developed a conceptual framework for the management of the evolution of Interfaces, based on a superset of Design by Contract.

I believe that (an extended) Design by Contract is the key to allowing us to manage the evolution of Interfaces and their implementations.  But my thougths aren't well enough formed yet... So keep talking...

HTH,
Paolo

[mikewhit]

With software tools now permitting a more iterative approach, it's useful to be able to revise 'local' interfaces as part of the design refinement process.

I have not explored the code engineering aspects of EA.

However, given that some reverse-engineering is possible in EA, it might be helpful if forward and reverse dependencies in this chain could be explicitly identified and edited. Interfaces could be one of several cases in this category.

[alexander]

I liked the way COM handled this, if you want to change the interface build another one with the changes u want but keep supporting the old one just the same.
Since old programs would ask about the 'old' interface they would not notice the change, and new programs could ask for the 'new' interface and exploit the benefits of the changes.

[thomaskilian]

How would one represent such interface versions in EA? Using a versioning tool?

[sargasso]

hmmm swakal must be too localised...

I meant that the comment I was making was composed in a hurry and that if it missed the original poster's point or failed to provide a direct answer then please dont get uptight.

I though it was some nordic? russian? other cryllic? deity who's wrath you incurred if you answered questions too quickly.

bruce

[KP]

hmmm swakal must be too localised...

I meant that the comment I was making was composed in a hurry and that if it missed the original poster's point or failed to provide a direct answer then please dont get uptight.

I though it was some nordic? russian? other cryllic? deity who's wrath you incurred if you answered questions too quickly.

bruce

I had a bit of a trawl through the Pantheon last night and the best I could come up with was Phoebe, the Greek Goddess of "Wise Counsel, Thoughtful Replies and Snappy Answers." And UML Forums, presumably?

[thomaskilian]

hmmm swakal must be too localised...

It's obviously Bantu (an African dialect). So Mike was right (see here)