Community
Participate
Working Groups
A class CLS is defined with attributes: CLS.ct1 : AbsCT, where AbsCT is an abstract datatype. In instance diagram create an instance of CLS. A dialog box comes up to define attributes' values Check the box next to ct1, move to the Value column and click the ... button What should happen: A dialog box should be displayed and a choice for a concrete subtype should be displayed What happebs: A dialog box comes up WITHOUT cjoice for concrete subtype but with the option for creating an instance Now the instance of the abstract datatype is created. Try this by directly dragging the abstract type into the diagram and it behaves correctly -- an error is displayed about not being allowed to create instances of abstract types. Ramifications: You can't specify the CLS instance at all in an instance diagram
Hi Yoram, good point. I remember indeed when we implemented this a year ago, about putting a check on a direct drag-n-drop, but not on the indirect creation (from an attribute). We'll into scheduling a fix for it.
We seem to have contradicting requirements, where being able to DnD a abstract artifact allows to show how concrete artifact would relate to artifacts thru a parent association. I believe this should be junked?
Eric: "I believe this should be junked?" No, no... I don’t think so. I outlined a behavior below (in the original post) that can be implemented to resolve the conflict. My point is this: abstract classes should not be allowed to be instantiated but when one drags an abstract class to a diagram one should be offered an opportunity to create an ad-hoc concrete subtype that only exists in this diagram. This behavior is similar to the opportunity given to create an instance of a datatype when an atribute is to be populated in an instance diagram and that attribute has a type that requires datatype... Allowing instances of abstract classes is embarrassing at least and quite misleading otherwise. *Yoram
(In reply to comment #3) > Eric: "I believe this should be junked?" > > No, no... I don’t think so. I outlined a behavior below (in the original post) > that can be implemented to resolve the conflict. > My point is this: abstract classes should not be allowed to be instantiated but > when one drags an abstract class to a diagram one should be offered an > opportunity to create an ad-hoc concrete subtype that only exists in this > diagram. This behavior is similar to the opportunity given to create an > instance of a datatype when an atribute is to be populated in an instance > diagram and that attribute has a type that requires datatype... > > Allowing instances of abstract classes is embarrassing at least and quite > misleading otherwise. > > *Yoram Thanks for your answer Yoram. That makes a lot of sense. Richard? I hope you're watching this :-)? Just added you on the cc-list anyway... Eric
The issue contradicts current assumptions in TS. There were several issues related to this. Now users are able to instantiate any abstract type on instance diagrams.
