I keep finding myself thinking this over. Forgetting about EA (or any specific tool) at the moment, the issue you two have raised is quite deep.
Without any background on how you arrived at the position to make the post I will assume that your are in the "early" stages of implementation design and that you have good reasons for modelling both the interface and the realizing classes at the same time. Perhaps you are prototyping the interfaces? Whatever the reason, I keep stumbling over the thought "Once an interface has been published, it should not be changed".
The key word here is "published". Consider the havoc that would arise if a theoretical software seller "M", having issued a theoretical set of standard libraries, say ".N" decided offhand to change the name and/or return type of a method in a theoretical interface called, say, "ICollectionBase". Every realizing class would have to be rewritten to make it re-conform. Extrapolating backwards, the cost of having mutatable interfaces is still high at any project with more than one developer... and possibly quite high even with single developer projects.
On the other hand, what we need
is some way to develop interface specifications in an iterative manner - accepting the cost of changing the realization classes every time a change is made to the interface specification. During this time, we could say that the interface specification is "unpublished".
What happens when a change is made to an interface specification is still open to question. Pushing the interface out to code level in a project without altering the realizations should render any following build invalid. This is a problem for the IDE to handle and is what should happen now with EA.
Automatically cascading the change to the interface specification down the design chain, seems to me to "have fur on it". The cascade needs to be controlled and reversible. Controlled and reversible in the sense of "I want to see the effect of changing the interface spec in this way" and to do that "I want to change a selected set of realizations and test the impact on that subset of the system... and if its good then I want to propogate the change through the rest of the system ... but if its not I want to reverse the change forthwith." Whether or not the cascaded changes are manual or automatic, you can see that the impact on a project with wide use of the interface could be severe.
Secondly, there is the question of how far the cascade could/should go. Consider adding a new method to the interface. Realization classes would need to have the method added, how about specializations of those? Now consider a specialization class that has inadvertantly already got a method of the same name as the method added to the interface. What are the implications here (in terms of what should the modelling tool do)?
Finally, I am unsure as to whether these ideas are limited to interface classes, any modelling elements that impose some control over related elements may also need to be investigated before any automatic propagation of change is implemented.
IOW I see some type of state mechanism - other than simply locking an element from change - would be necessary to do this properly. The modelling tool would be exhibiting different behaviour depending on whether the element was published or unpublished. Both sets of behaviours are quite complex.
I'd love to see an MDA implementation of this
So, what I'm saying is, this is bigger than just propagating changes in interface elements to the first level of realizing classes. The very idea of "interfaces as a contract" means the type of functionality you are desiring in a modelling tool would have to be very carefully thought out.
rgrds
Bruce
