Issue 6440: Excessive syntactic and semantic overlap between structured Classifiers (uml2-superstructure-ftf) Source: Pivot Point (Mr. Cris Kobryn, ) Nature: Uncategorized Issue Severity: Summary: There is excessive syntactic and semantic overlap between two kinds of structured Classifiers: StructuredClasses::Classes and Components. It is confusing to users how to choose between these constructs, and how to apply them correctly. The confusion extends to how Ports and Interfaces are used with these constructs, since it is unclear how to use both of these in a complementary manner. Recommendation: Remove one of these structured Classifiers, or clarify how to choose between and apply them. Also explain how to apply Ports and Interfaces in a complementary manner for both black-box and white-box views of structured Classifiers. Resolution: Revised Text: Actions taken: November 6, 2003: received issue March 9, 2005: closed issue Discussion: The issuer may not have been aware that this overlap is due to the fact that Component is simply a special kind of structured Class, so that this “overlap” is to be expected. Components should be used where the additional specializations that they provide are useful. Disposition: Closed, no change End of Annotations:===== eply-To: From: "Cris Kobryn" To: "Juergen Boldt" , Subject: UML 2 Superstructure Issues Date: Thu, 6 Nov 2003 23:28:19 -0800 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal Hello Juergen, Please record the following issues for UML 2 Superstructure Final Adopted Specification (OMG doc# ptc/03-08-02). Thanks, Cris ---------------------------------------------------------------------------- ---------- Reference: UML 2 Superstructure, OMG doc# ptc/03-08-02. Chapters 8 and 9 Issue: Excessive syntactic and semantic overlap between structured Classifiers Description: There is excessive syntactic and semantic overlap between two kinds of structured Classifiers: StructuredClasses::Classes and Components. It is confusing to users how to choose between these constructs, and how to apply them correctly. The confusion extends to how Ports and Interfaces are used with these constructs, since it is unclear how to use both of these in a complementary manner. Recommendation: Remove one of these structured Classifiers, or clarify how to choose between and apply them. Also explain how to apply Ports and Interfaces in a complementary manner for both black-box and white-box views of structured Classifiers. From: "Thomas Weigert" To: "Branislav Selic" , , Subject: RE: Ballot 24 resolutions from Bran Date: Wed, 18 Aug 2004 22:29:33 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, comments so far.... 6395: This solution is not complete. If you want something to be redefinable, you also need to establish the redefinition context as well as add an association that redefines "redefinedElement". However, the resolution itself is inappropriate, I believe. There is a reason why Trigger is not redefinable: The souce state/trigger tuple uniquely identifies a transition. So redefining the Trigger would mean to redefine the transition. Thus you should just redefine the transition directly, by changing the Trigger, for example. There would be no point in redefining the Trigger itself. 6440: I personally think that the issuer raises a legitimate concern that many users will struggle with. The additions afforded by Component should just be available to StructuredClasses::Classes. This duplication of capability is more than confusing. 6902: In 6.3.3, there is a paragraph in black saying something about the causality model. The phrasing needs to clarified to make sure that the passing of information between behaviors in this manner is through the arguments passed by the invocation. As it stands now it reads as if two behaviors could wantonly exchange information during execution without sending messages. Any such information exchange that does not rely on the message exchange discussed in the basic causality model can only be through the parameters (or global variables). 6988: The use of "We may also represent..." is inappropriate wording for the specification. Use something like "An execution occurrence may also be represented by ...." instead. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, August 18, 2004 9:54 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Ballot 24 resolutions from Bran Attached, please find proposals for 24 issue resolutions for ballot 24 (rhymes nicely, doesn't it?) Many of them are deferrals, but some of them are real resolutions. They cover a range of areas including classes, state machines, components, interactions, and "general" stuff. Since some of them were originally assigned to other FTF members, please have a look at them, just in case you are working on a resolution to the same issue. Regards, Bran To: "Thomas Weigert" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Ballot 24 resolutions from Bran X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 18 Aug 2004 23:50:05 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/18/2004 23:50:07, Serialize complete at 08/18/2004 23:50:07 Thanks, Thomas. Feedback embedded below: > 6395: This solution is not complete. If you want something to be > redefinable, you also need to establish the redefinition context as > well as add an association that redefines "redefinedElement". > > However, the resolution itself is inappropriate, I believe. There is > a reason why Trigger is not redefinable: The souce state/trigger > tuple uniquely identifies a transition. So redefining the Trigger > would mean to redefine the transition. Thus you should just redefine > the transition directly, by changing the Trigger, for example. There > would be no point in redefining the Trigger itself. There seems something wrong with the reasoning here: a transition is a model element that has identity. Redefining one of its "features" in a subclass does not change its identity. The purpose of redefinition is to maximize reuse. (Anyways, I'll think about this one a bit more -- I'm not thinking straight any more.) > 6440: I personally think that the issuer raises a legitimate concern > that many users will struggle with. The additions afforded by > Component should just be available to StructuredClasses::Classes. > This duplication of capability is more than confusing. Personally, I agree with you -- I do not see much value in the extra capabilities that components add. However, this is an argument that was prolonged and rather bitter and not one we will ever resolve by ourselves (the market will). I also believe that the folks who raised the issue, were not aware of the inheritance relationship between these two. What would you suggest? > 6902: In 6.3.3, there is a paragraph in black saying something about > the causality model. The phrasing needs to clarified to make sure > that the passing of information between behaviors in this manner is > through the arguments passed by the invocation. As it stands now it > reads as if two behaviors could wantonly exchange information during > execution without sending messages. Any such information exchange > that does not rely on the message exchange discussed in the basic > causality model can only be through the parameters (or global variables). What you have there is Cornad's last revision. I have no more energy or time to work on this, so I just put it out for comment. If people feel that it is busted, I will pull it and defer it until kingdom come. I am quite disappointed with how this one turned out. > 6988: The use of "We may also represent..." is inappropriate wording > for the specification. Use something like "An execution occurrence > may also be represented by ...." instead. Actually I agree with you. However, the colloquial "we" is used throughout this chapter and fixing it in this one place only makes it inconsistent. The problem of idiosyncratic writing and formatting styles is endemic throughout the spec. Thanks...Bran From: "Thomas Weigert" To: "Branislav Selic" , "Thomas Weigert" Cc: , Subject: RE: Ballot 24 resolutions from Bran Date: Wed, 18 Aug 2004 23:11:58 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, please see below... -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, August 18, 2004 10:50 PM To: Thomas Weigert Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Ballot 24 resolutions from Bran Thanks, Thomas. Feedback embedded below: > 6395: This solution is not complete. If you want something to be > redefinable, you also need to establish the redefinition context as > well as add an association that redefines "redefinedElement". > > However, the resolution itself is inappropriate, I believe. There is > a reason why Trigger is not redefinable: The souce state/trigger > tuple uniquely identifies a transition. So redefining the Trigger > would mean to redefine the transition. Thus you should just redefine > the transition directly, by changing the Trigger, for example. There > would be no point in redefining the Trigger itself. There seems something wrong with the reasoning here: a transition is a model element that has identity. Redefining one of its "features" in a subclass does not change its identity. The purpose of redefinition is to maximize reuse. (Anyways, I'll think about this one a bit more -- I'm not thinking straight any more.) Probably no great harm is done in making this redefinable, albeit I cannot quite see the application. However, if you decide to, you will have to add the associations described in the first paragraph, otherwise it does not work. > 6440: I personally think that the issuer raises a legitimate concern > that many users will struggle with. The additions afforded by > Component should just be available to StructuredClasses::Classes. > This duplication of capability is more than confusing. Personally, I agree with you -- I do not see much value in the extra capabilities that components add. However, this is an argument that was prolonged and rather bitter and not one we will ever resolve by ourselves (the market will). I also believe that the folks who raised the issue, were not aware of the inheritance relationship between these two. What would you suggest? Yes, this is a difficult question. I noticed that at least one of the popular UML text books got this all confused, so I worry about the user. Maybe a "Defer"? Your call. > 6902: In 6.3.3, there is a paragraph in black saying something about > the causality model. The phrasing needs to clarified to make sure > that the passing of information between behaviors in this manner is > through the arguments passed by the invocation. As it stands now it > reads as if two behaviors could wantonly exchange information during > execution without sending messages. Any such information exchange > that does not rely on the message exchange discussed in the basic > causality model can only be through the parameters (or global variables). What you have there is Cornad's last revision. I have no more energy or time to work on this, so I just put it out for comment. If people feel that it is busted, I will pull it and defer it until kingdom come. I am quite disappointed with how this one turned out. I understand your frustration. How about changing the first sentence following Fig. 2 to "The causality model also subsumes behaviors invoking each other and passing information to each other through arguments to parameters of the invoked behavior, as enabled by CallBehaviorAction (see page XXX)." > 6988: The use of "We may also represent..." is inappropriate wording > for the specification. Use something like "An execution occurrence > may also be represented by ...." instead. Actually I agree with you. However, the colloquial "we" is used throughout this chapter and fixing it in this one place only makes it inconsistent. The problem of idiosyncratic writing and formatting styles is endemic throughout the spec. I see. You are right. Making this one change is just a drop in the bucket... Thanks...Bran