Community
Participate
Working Groups
I create an interface IInt, a class A that implements IInt and another class B. I then create an association between B and IInt. All this works fine and the diagrams look as they should do. Now I create an instance-diagram and I add instances of classes A and B - looks good. However, now I attenpt to create an instance of the association, but this fails. I think we should, as a matter of principle, be able to create instances of any concrete model element in an instance diagram. It may be that we should also allow the creation of instances of non-concrete model elements to be understood as a short-hand for "an instance of any concrete derivative". Note that we cannot substitute a dependency for an association because a dependency is much weaker than an association. A dependency might simply mean that an argument passed to an operation is of the type to which the dependency runs. An association means that the client object holds a reference in some way to the server object. A good case where we need associations to interfaces is if we were to model Eclipse plugins. A plugin defines interfaces to be used in extension-points that it offers to providers. We frequently want to hold a list of all those providers so we can iterate through them or whatever, so in model terms we would have an association running from a plugin class to the interface. Were we to create an instance-diagram to show the configuration of objects, we would want to be able to instantiate the association. I have marked this as major since I need it for IRD work.
Indeed. This seems like a valid case. There are 2 things to consider to implement this... 1) As a hint for whoever is going to look into this, I believe the initDialog() method of the AssociationInstanceEditDialog in the org.eclipse.tigerstripe.workbench.ui.instancediagram.diagram plugin builds up the list of "allowed" associations to be instantiated. I believe the case described here is not taken into account when assembling the list. It should be possible to find all the "implemented" interface. 2) I believe each instantiated association is tracked against the corresponding association, but in this case, the removal of a "implements" relationship should invalidate the diagram which will require additional logic to find candidate association instances to be removed.
The UML Superstructure Specification, v2.1.2, section 7.3.24 Interface says "An association between an interface and any other classifier implies that a conforming association must exist between any implementation of that interface and that other classifier. In particular, an association between interfaces implies that a conforming association must exist between implementations of the interfaces." Note that associations between interfaces are definitely allowed in UML.
Not sure how this would be implemented in Java. From http://java.sun.com/docs/books/jls/third_edition/html/interfaces.html it says in 9.3 Field (Constant) Declarations "Every field declaration in the body of an interface is implicitly public, static, and final."
This should really be part of the work on instance diagrams.
This is really an enhancement
Done. I added two things to implement this functionality 1. Possibility to add an interface instance to an instance diagram and make associations to the interface. 2. Possibility to make associations between concrete classes. In other words, now you can make association between instances if there is any association between their implemented parents
Verified. Thanks!
