Interfaces don't update

[morkus]

I have an interface which another class "Realizes" (the arrow points to the interface from the class.)

The issue I'm having is that if I add a method to the interface, EA (772) doesn't automaitcally add the method to the class which implements the interface.

But, if I drop the "Realizes" arrow and re-add it, all is OK.

Why doesn't EA automaticall update the class when I update the interface?

I don't see how to automate this.

Thanks in advance.

-- M

[Paolo F Cantoni]

I have an interface which another class "Realizes" (the arrow points to the interface from the class.)

The issue I'm having is that if I add a method to the interface, EA (772) doesn't automatically add the method to the class which implements the interface.

But, if I drop the "Realizes" arrow and re-add it, all is OK.

Why doesn't EA automatically update the class when I update the interface?

I don't see how to automate this.

Thanks in advance.

-- M

M,

This is part of EA's UI (Unique Interface).  If you search the forum you 'll see I had some differences of opinion with the Sparxians on this.  I took the same view as you...  (That EA should allow some form of post-facto Realization when the supplier changes).

Sorry...
Paolo

BTW, you can automate this.  but it does require a bit of work...  If you are interested in writing the automation, let us know and we can help you.  I don't have the time at present, I've got other projects to complete (see the forum).  But I would love a proper Realizer...

[morkus]

Thanks for your reply.

Not updating the class when the interface changes is, IMHO, a *MAJOR* UI defect pure and simple.

Not updating the class when the interface changes violates the contract between interface and class.

The interface shouldn't "leave it up to me" to do the hard work.

That's why I spent all this $$$ on the UML tool!

Yikes!!!

Thanks again

-- M

[Paolo F Cantoni]

Thanks for your reply.

Not updating the class when the interface changes is, IMHO, a *MAJOR* UI defect pure and simple.

Not updating the class when the interface changes violates the contract between interface and class.

The interface shouldn't "leave it up to me" to do the hard work.

That's why I spent all this $$$ on the UML tool!

Yikes!!!

Thanks again

-- M

Correct Generalization and Realization aren't as straight forward as most people seem to believe.

If you search the forum, you'll see I'm no apologist for Sparx, but I do try to be fair.

So, if you're still interested in automation, let us know.

Paolo

[morkus]

My point was that the genereated code is not correct based on the contract betwen the interface and the class that implements it -->

So, if you add a method to an interface, EA doesn't update the class with this interface method that the class *must* overload.

>>> So, the generated code will not even compile! <<<

I'm certainly no UML expert (another reason I bought the tool in the first place!), but this isn't what I was expecting or what I was hoping for when I bought this tool.

I appreciate your offer for automation, but with my project timelines, I'll just use EA for (mostly) documentation now.



Thanks very much for your kind replies!

-- M

[KP]

But, if I drop the "Realizes" arrow and re-add it, all is OK.

A better idea is to select the class and Ctrl+Shift+O.

Why doesn't EA automaticall update the class when I update the interface?

I don't know the reason, but I think it's intentional. Perhaps the idea is that secondary effects of operations in a UI can be confusing and can give the user the impression that they aren't in control.

[sargasso]

A note from one of those on the other side of the fence, aka EA should not automatically update changes to an interface element down to realizations.

While I agree that there should be some degree of automated flow down,  I firmly believe that it should be totally under the control of the user.  

The reason being that interfaces aren't suppose to change "on the fly".  The design of an interface, especially in a complex multi-developer situation, is intended to specify exactly what realisation classes must provide.  Imagine the confusion and rework that would occur if someone in M$ decided to change something like the ICollection or IEnumerable design halfway through the development of a new release of .Net  framework.    Those  interfaces are realised by dozens of classes in the framework.  

Further imagine if one designer added a method to an interface that had already been realised by one or more classes and the method name chosen was already implemented in those classes as a local process.  What should EA do - clobber the existing signatures and structure?  - leave the existing ones there and hope that they just happen to match the new interface method signature?  

IMO changes to an interface element are a major event in a development project and I would be very scared of a tool that just propogated chanegs of this nature.

jm2cw

bruce

[Paolo F Cantoni]

A note from one of those on the other side of the fence, aka EA should not automatically update changes to an interface element down to Realizations.

While I agree that there should be some degree of automated flow down,  I firmly believe that it should be totally under the control of the user.
[size=13][SNIP][/size]

My comments on automation were related to automated help in the user control of Interface Realization.

I agree totally with bruce that it should be under user control.  The reasons have to do with [size=13]Design by Contract[/size] issues.  Each specific Realization needs to define how much of the Contract is being Realized. That's what I meant about things not being straight forward.  bruce has outlined some of the consequences of this.

That having been done, it is possible to determine which Realizations are likely to be affected by a change in the Interface Contract.  These can then be marked for user update...

I recently built a similar system.  I documented how the previous interface was Realized for each item.  When the interface changed, all those items dependent upon it "went Red".  When the use clicked on the item, it presented the current Realization, and the proposed new Realization, based on applying the previous rules to the updated instance.  If the user was satisfied - they just clicked "update".  If not, they altered the rules  to get what they needed - then pressed update.  The Red went away...

Seemed like a good pattern to me...

With a bit of metadata support, there is a significant amount of automation that can be applied, whilst still retaining user control...

M2CW,
Paolo

[morkus]

Lots of good replies here.

I'd be happy if there were just an option where I could decide the behavior: manual or automatic.

That would leave it up to the user as many have written here.

In most projects, It's just me doing my part of the UML. I'm not implementig Microsoft's interfaces, just my own.

Since a class must implement all the interfaces the interface promises, then, yes, if somebody creates a new interface method, then the tool should create a new stub method in the classes that implement the interface. Then, the code will compile and the contract is maintained.

Even two *manual* right-click options would be an improvement: "Update realization" (for the current one selected), and, "Update all realizations" for the whole model.

I really wish the option were there to also have it update them automatically.

Hopefully in some future version.

Thanks.

-- M

[Paolo F Cantoni]

A better idea is to select the class and Ctrl+Shift+O.

I don't know the reason, but I think it's intentional. Perhaps the idea is that secondary effects of operations in a UI can be confusing and can give the user the impression that they aren't in control.

Just an observation:

Doesn't it concern users that we frequently see Sparxians confessing thay don't know why a particular piece of functionality is the way it is?

There's an Agile guideline/axiom:  "Prefer working code to documentation"

We often seem to get neither...

I would have thought that the one application that would be well documented would be a Modeller.  In particular, since the Sparxians have indicated EA is used to design EA (NOT always a commoon situation!).  The model would be documented with these UI (Unique Interfaces)

[KP]

Just an observation:

Doesn't it concern users that we frequently see Sparxians confessing thay don't know why a particular piece of functionality is the way it is?

There's an Agile guideline/axiom:  "Prefer working code to documentation"

We often seem to get neither...

I would have thought that the one application that would be well documented would be a Modeller.  In particular, since the Sparxians have indicated EA is used to design EA (NOT always a commoon situation!).  The model would be documented with these UI (Unique Interfaces)

If I have time, I will check the documentation and give you an answer.

[thomaskilian]

Just an observation:

Doesn't it concern users that we frequently see Sparxians confessing thay don't know why a particular piece of functionality is the way it is?
...

Not really. We had an issue with MS Sharepoint. After some months of waiting, we received information that the European specialist wasn't available - and if we'd mind that the issue would be treated in Egypt.   No
Then after some further months we received the answer from Redmont that the issue was due to some programming limitation which easily could be circumvented.

Effects and initial reasons for effects must not be close together. There can be a big gap which you will not find in even the best documentation.

However, there's always space for improvements