Issue 8028: create dependency Figures 103 and 121 (uml2-rtf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Clarification Severity: Significant Summary: create dependency Figures 103 and 121 use create dependencies, which do not apply to the example. Standard stereotypes defines create for BehavioralFeature as: "Specifies that the designated feature creates an instance of the classifier to which the feature is attached. May be promoted to the Classifier containing the feature." Resolution: Revised Text: In Figure 103, invert the arrow and delete the stereotype «create». Insert the stereotype «create» before the operation name “make”. Change the paragraph preceding figure 103 as follows: A usage dependency may relate an instance value to a constructor for a class, describing the single value returned by the constructor operation. The operation is the client, the created instance the supplier. The instance value may reference parameters declared by the operation. A constructor is an operation having a single return result parameter of the type of the owning class. The instance value that is the supplier of the usage dependency represents the default value of the single return result parameter of a constructor operation. (The constructor operation is typically denoted by the stereotype «create», as shown in Figure 103). In Figure 121, invert the arrow and delete the stereotype «create». Insert the stereotype «create» before the operation name “make”. Actions taken: December 30, 2004: received issue August 23, 2006: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 30 Dec 2004 15:26:18 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Notification: No Specification: UML 2 Super Section: Composite FormalNumber: ptc/04-10-02 Version: 2.0 RevisionDate: 04-10-02 Page: - Nature: Clarification Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) Description create dependency Figures 103 and 121 use create dependencies, which do not apply to the example. Standard stereotypes defines create for BehavioralFeature as: "Specifies that the designated feature creates an instance of the classifier to which the feature is attached. May be promoted to the Classifier containing the feature." Reply-To: From: "Conrad Bock" To: "Thomas Weigert" , "'Branislav Selic'" , Subject: ,cs, Composite WG discuissionfor ballot 4 Date: Mon, 23 May 2005 15:23:47 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Thomas, I put comments on the composite WG resolutions in the wiki, and below for folks signed up for that. Conrad - Issues 6150: Notation for method How about waiting until later in the RTF, to see if any consensus builds? Users hit this notational gap right away using UML. - Issue 8026: Contextualized attribute values Figures 121 Constructors are a way of specifying the values for attributes of objects that play parts in composites, that is, contextualized values. The problems with modeling contextualized values this way are given in the issue and a proposed resolution is linked there also. - Issue 8028: create dependency Figures 103 and 121 The resolution defines the semantics for usage dependencies between an operation and an instance value as specifying the return value. However, the semantics of usage dependency says: "The usage dependency does not specify how the client uses the supplier other than the fact that the supplier is used by of the definition or implementation of the client." The specific semantics in the resolution would need a stereotype, and should be Issue 8028: create dependency Figures 103 and 121 Issue summary create dependency Figures 103 and 121 use create dependencies, which do not apply to the example. Standard stereotypes defines create for Behavioral Feature? as: 'Specifies that the designated feature creates an instance of the classifier to which the feature is attached. May be promoted to the Classifier containing the feature.' Discussion The issue is correct in pointing out that the notation for constructors could be improved. -- ThomasWeigert - 18 May 2005 Personally, I think this notation is not useful at all. It is imprecise and takes up too much real-estate to do this. I would suggest removing it altogether. -- BranSelic - 19 May 2005 Defining constructors in terms of the instances which are created is widely actually being used. -- ThomasWeigert - 20 May 2005 The resolution defines the semantics for usage dependencies between an operation and an instance value as specifying the return value. However, the semantics of usage dependency says: "The usage dependency does not specify how the client uses the supplier other than the fact that the supplier is used by of the definition or implementation of the client." The specific semantics in the resolution would need a stereotype, and should be defined in the classes chapter, and used here. -- ConradBock - 23 May 2005 It is not the usage dependency that does anything. The client just uses the pointed to supplier to create an instance. This is not defined by the dependency, but part of the semantics of the client. So I believe this is exactly in line with how to use dependencies. Otherwise, you would have to have stereotypes for any kind of usage dependency. -- ThomasWeigert - 24 May 2005 If the meaning of the dependency is up to the client, then this is not a standard way to define constructors and shouldn't be in the spec. -- ConradBock - 25 May 2005 Conrad, "dependency" in UML does not carry semantics but just indicate a relationship. This is also true here. But a client is free to say what happens when such relationships exist. That is how one would use dependencies. For example: a child is dependent on a parent. Some children leave home early, and some are still living at home when they are 40. This is not part of the semantics of dependency, but is an aspect of the child (probably the parent to, but let's ignore that sociological aspect here...) -- ThomasWeigert - 26 May 2005 Dependencies may not have direct runtime semantics, but they do say something about the specifications being related, which in turn places a constraint on runtime. For example, the <> stereotype of the Uses dependency indicates that some operations on the client create instances of the supplier. In this case we're discussing now, the dependency is trying to say that the operation must have a return result that conforms to the instance specification. The current proposal leaves this meaning up to the implementation, ie, does not standardize it, so could only be included in the example section. Not sure I follow the analogy to parent/child. -- ConradBock - 03 Jun 2005 The current proposal gives no additional semantics to the dependency. Instead it defines the semantics of the client differently, depending on whether there is such dependency or not. Similarly, when a child relies on one's parents kindness by living at home at age 40 this is not part of the definition of the parent-child relationship, but a special behavior of the child. -- ThomasWeigert - 04 Jun 2005 Revised Test In Figure 103, invert the arrow and delete the stereotype «create». Insert the stereotype «create» before the operation name .make.. Change the paragraph preceding figure 103 as follows: A usage dependency may relate an instance value to a constructor for a class, describing the single value returned by the constructor operation. The operation is the client, the created instance the supplier. The instance value may reference parameters declared by the operation. A constructor is any operation having a single return result parameter of the type of the owning class. The instance value that is the supplier of the usage dependency represents the default value of the single return result parameter of a constructor operation. (The constructor operation is typically denoted by the stereotype «create», as shown in Figure 103. In Figure 121, invert the arrow and delete the stereotype «create». Insert the stereotype «create» before the operation name .make.. Resolution Issue 8028: create dependency Figures 103 and 121 Issue summary create dependency Figures 103 and 121 use create dependencies, which do not apply to the example. Standard stereotypes defines create for Behavioral Feature? as: 'Specifies that the designated feature creates an instance of the classifier to which the feature is attached. May be promoted to the Classifier containing the feature.' Discussion The issue is correct in pointing out that the notation for constructors could be improved. -- ThomasWeigert - 18 May 2005 Personally, I think this notation is not useful at all. It is imprecise and takes up too much real-estate to do this. I would suggest removing it altogether. -- BranSelic - 19 May 2005 Defining constructors in terms of the instances which are created is widely actually being used. -- ThomasWeigert - 20 May 2005 The resolution defines the semantics for usage dependencies between an operation and an instance value as specifying the return value. However, the semantics of usage dependency says: "The usage dependency does not specify how the client uses the supplier other than the fact that the supplier is used by of the definition or implementation of the client." The specific semantics in the resolution would need a stereotype, and should be defined in the classes chapter, and used here. -- ConradBock - 23 May 2005 It is not the usage dependency that does anything. The client just uses the pointed to supplier to create an instance. This is not defined by the dependency, but part of the semantics of the client. So I believe this is exactly in line with how to use dependencies. Otherwise, you would have to have stereotypes for any kind of usage dependency. -- ThomasWeigert - 24 May 2005 If the meaning of the dependency is up to the client, then this is not a standard way to define constructors and shouldn't be in the spec. -- ConradBock - 25 May 2005 Conrad, "dependency" in UML does not carry semantics but just indicate a relationship. This is also true here. But a client is free to say what happens when such relationships exist. That is how one would use dependencies. For example: a child is dependent on a parent. Some children leave home early, and some are still living at home when they are 40. This is not part of the semantics of dependency, but is an aspect of the child (probably the parent to, but let's ignore that sociological aspect here...) -- ThomasWeigert - 26 May 2005 Dependencies may not have direct runtime semantics, but they do say something about the specifications being related, which in turn places a constraint on runtime. For example, the <> stereotype of the Uses dependency indicates that some operations on the client create instances of the supplier. In this case we're discussing now, the dependency is trying to say that the operation must have a return result that conforms to the instance specification. The current proposal leaves this meaning up to the implementation, ie, does not standardize it, so could only be included in the example section. Not sure I follow the analogy to parent/child. -- ConradBock - 03 Jun 2005 The current proposal gives no additional semantics to the dependency. Instead it defines the semantics of the client differently, depending on whether there is such dependency or not. Similarly, when a child relies on one's parents kindness by living at home at age 40 this is not part of the definition of the parent-child relationship, but a special behavior of the child. -- ThomasWeigert - 04 Jun 2005 Revised Test In Figure 103, invert the arrow and delete the stereotype «create». Insert the stereotype «create» before the operation name .make.. Change the paragraph preceding figure 103 as follows: A usage dependency may relate an instance value to a constructor for a class, describing the single value returned by the constructor operation. The operation is the client, the created instance the supplier. The instance value may reference parameters declared by the operation. A constructor is any operation having a single return result parameter of the type of the owning class. The instance value that is the supplier of the usage dependency represents the default value of the single return result parameter of a constructor operation. (The constructor operation is typically denoted by the stereotype «create», as shown in Figure 103. In Figure 121, invert the arrow and delete the stereotype «create». Insert the stereotype «create» before the operation name .make.. Resolution Resolved Subject: RE: DRAFT of ballot 6 Date: Sun, 17 Jul 2005 23:31:54 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DRAFT of ballot 6 Thread-Index: AcWLDFwjyVCT4WBHSaSGhlQjAkpekAALdleg From: "Pete Rivett" To: "Branislav Selic" , X-Virus-Scanned: by amavisd-new at sentraliant.com See detailed comments below. I think 8706 needs more work and so should probably be pulled this time round. The discussion for 7967 is contradictory: Oystein says the 'issue is understandable' yet the second comment that 'agrees with Oystein' says the issue should be close due to 'unclear issue formulation'. It cannot be both understandable and unclear! There may be valid reasons to close the issue with no change but this does not seem to be one of them. 8026 seem premature to close - unless Conrad can confirm that he's been convinced. 8028: it seems intuitively wrong to have a constructor dependent on an instance. Also the definition of a constructor as "A constructor is any operation having a single return result parameter of the type of the owning class. " seems over-general. e.g. the Person::getMother() operation returns a Person but is not a constructor by any stretch. Furthermore there are genuine constructors that are not defined on t he owning class (e.g. those owned by factory classes). 8167: Should not be 'closed no change' since it contains a revision to text. 8180: proposes adding "(Specialized from Action:output)" to a property. However there is no such thing as 'specialized from' for a property in UML: it should be subsets. 8508: I disagree with making Model::viewpoint single valued. It both makes a viewpoint mandatory, and is over-restrictive compared with the accompanying text: for example where a model composes two other models (each with different viewpoints it seems reasonable for the containing model's viewpoint to have two values. Restricting the multiplicity in this way seems unnecessary at RTF stage and uncalled for by the issue (which seems to be complaining about the purely textual difference between [0..*] and [*].) 8454 If ObjectNode is not a MultiplicityElement (which seems to be true) then why does it have constraint [2] isUnique=false - since it will not have such a property. However I must admit I cannot make sense of my original issue - sorry. 8593: The preferred style seems to be 'None.' rather than 'No additional associations'. Issue 8706: First para of Discussion is misleading since the mechanism is not based on Import but metamodel/classReference. Need to expand on the practical meaning of 'accessible (visible)' in para 2 of revised text. And the meaning of "the most detailed namespaces " The last clause of this paragraph 2 needs reformulating/punctuating: "only the referenced elements which owned elements are not referenced are filtered (shown) by the profile". As well as not scanning, it seems mistaken in equating 'filtered' (which is normally used in the sense 'filtered out') with '(shown)' Need to say what happens if a normal PackageImport is used by a Profile. In the example I don't see why Metaclass1 is hidden - since it's contained by the Package which is <>d. And why an explicit reference is needed for Metaclass2 when it's owned by the Package. There is clearly something going on that I'm not getting - and I was involved in t he calls on this subject! I think we could do with some OCL to be clear exactly what the set of 'accessible' elements is. Likewise I do not understand the paragraph about combining imports if one Profile imports another. If P1 imports P2 when why combine 'at the P2 level'? Generally there are several typos and the English needs tidying up. 8752: the Issue summary is missing words - it says " instead of " 8759: revised text should refer to "OpaqueAction, Generalizations" not "Actions, Generalizations". 8867: again the final 2 sentences should have 'subsets' not 'specializes'. Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Sunday, July 17, 2005 8:55 PM To: uml2-rtf@omg.org Subject: DRAFT of ballot 6 Importance: High Slim pickings this time around -- just 31 resolution proposals. However, with vacation season on us, I guess this is to be expected. It does mean, however, that we will need to pick up our pace. We still have close to 400 issues to deal with. Please look at these carefully and raise any concerns that you have with these proposed resolutions before noon EDT on Friday, July 22. Regards, Bran To: uml2-rtf@omg.org Subject: Feedback on draft of ballot 6 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 18 Jul 2005 11:15:33 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 07/18/2005 11:15:34, Serialize complete at 07/18/2005 11:15:34 Here is my feedback on the proposed resolutions for ballot 6 (there are so much mechanics in putting together a ballot, that I often do not have time to actually read the proposed resolution texts): 7967: I believe that this is really a recommendation to defer the issue until the simple time model is reworked. (The issue text looks perfectly clear to me and asks for a reasonable generalization that the target of this action should be either a variable or an attribute.) I think that I will pull this proposal until we've had a chance to discuss it further. 8026: Although I dislike the current notation, it is in the adopted spec and should only be eliminated if there is something incorrect about it. This is not the case. The issue text is proposing an alternative, which I do not believe has been explored enough (the discussion is limited to an attack and defense of what is currently there -- this is really not addressing the issue). I am inclined to pull this one as well. 8028: The proposed resolution eliminates the need for one of the variants of the «create» standard stereotype. Therefore, it should also propose removal of the corresponding stereotype (including the reference to it on page 745) 8167: The revised text seems to address a different issue than the one that is in the submission. I think that the different issue should be raised and resolved separately and that this one should simply be a "closed, no change" (I can do this as an editorial fix.) 8180: The form "Specialized from " only appears in the Actions chapter, instead of the standard form "Subsets " used elsewhere. I think that this particular resolution should go in but a separate issue raised that changes all of these non-standard forms to the standard form. 8407: the item that changes "no additional attributes" to "None" should be removed from the resolution (see my previous e-mail) The subsets should follow the standard convention of qualifying the property, thus "subsets ownedElement" should be "subsets Element::ownedElement" The above two changes need to be made also to resolutions to issues 8408, 8409, and 8410 There is a spurrious paragraph beginning with "Depending on the context" which should be removed from the resolution -- although some explanation should be provided for how this part of the issue was resolved. Except for the last item, I will make all the changes to the resolutions above, since they are editorial. 8706: The resolution only provides a fix for the Superstructure -- a fix for the infrastructure should also be added (I can add that as an editorial fix). To summarize, it looks like 7967, 8026, and 8028 will be pulled from the ballot. Two new issues need to be raised related to 8167 and 8180 (I will raise them) and a number of editorial fixes to the proposed texts need to be made. Regards, Bran To: "Pete Rivett" Cc: uml2-rtf@omg.org Subject: RE: DRAFT of ballot 6 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 18 Jul 2005 11:53:29 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 07/18/2005 11:53:31, Serialize complete at 07/18/2005 11:53:31 Comments on Pete's comments for ballot 6: > I think 8706 needs more work and so should probably be pulled this time round. Since Philippe is not around to defend it, I guess I will pull it. (Also, as I noted earlier, it needs to have an Infra section.) > The discussion for 7967 is contradictory: Oystein says the 'issue is > understandable' yet the second comment that 'agrees with Oystein' > says the issue should be close due to 'unclear issue formulation'. > It cannot be both understandable and unclear! There may be valid > reasons to close the issue with no change but this does not seem to > be one of them. Agreed. > 8026 seem premature to close - unless Conrad can confirm that he's > been convinced. Personally, I think that this is an issue that will require a vote, since I don't think that Conrad will ever be convinced. However, I will pull the issue because I don't think the presentation option proposed by Conrad has been discussed enough. In my view, it can only go as an optional form, since the current form is already in the adopted spec. Although I don't like it myself, it is wrong to argue that the notation is unusable as the example in the document shows. > 8028: it seems intuitively wrong to have a constructor dependent on > an instance. > Also the definition of a constructor as "A constructor is any > operation having a single return result parameter of the type of the > owning class. " seems over-general. e.g. the Person::getMother() > operation returns a Person but is not a constructor by any stretch. > Furthermore there are genuine constructors that are not defined on t > he owning class (e.g. those owned by factory classes). Disagree. We already argued in the past that the meaning of source and destination of a dependency is sometimes ambiguous. It's a problem with the Dependency concept and not with this particular resolution. Nevertheless, I will pull this issue for other reasons, as stated in my comments. > 8167: Should not be 'closed no change' since it contains a revision to text. Will remove the revision and raise an issue for the revision. > 8180: proposes adding "(Specialized from Action:output)" to a > property. However there is no such thing as 'specialized from' for a > property in UML: it should be subsets. Correct. However, I think that this requires a special issue, which I have raised. Leaving this resolution in, in its current (incorrect) form, will at least make the chapter consistent throughout. I have already raised an issue for the more general problem. > 8508: I disagree with making Model::viewpoint single valued. It both > makes a viewpoint mandatory, and is over-restrictive compared with > the accompanying text: for example where a model composes two other > models (each with different viewpoints it seems reasonable for the > containing model's viewpoint to have two values. > Restricting the multiplicity in this way seems unnecessary at RTF > stage and uncalled for by the issue (which seems to be complaining > about the purely textual difference between [0..*] and [*].) I disagree. The spec is pretty clear when it says that a "model captures a view" (note the singular case), which does not remove the possibility of having other models with different views in them. If we allow multiple viewpoints in a single model, then we will not be able to clearly delineate them, since they would all be batched into a single model package. The only question I have here is whether the multiplicity should be [0..1] allowing models that are not committed to any particular viewpoints. This would allow models for specific viewpoints to be grouped into a common viewless model. > 8454 If ObjectNode is not a MultiplicityElement (which seems to be > true) then why does it have constraint [2] isUnique=false - since it > will not have such a property. However I must admit I cannot make > sense of my original issue - sorry. > > 8593: The preferred style seems to be 'None.' rather than 'No > additional associations'. See my previous comments on this. > Issue 8706: First para of Discussion is misleading since the > mechanism is not based on Import but metamodel/classReference. > Need to expand on the practical meaning of 'accessible (visible)' in > para 2 of revised text. And the meaning of "the most detailed namespaces " > The last clause of this paragraph 2 needs reformulating/punctuating: " > only the referenced elements which owned elements are not referenced > are filtered (shown) by the profile". As well as not scanning, it > seems mistaken in equating 'filtered' (which is normally used in the > sense 'filtered out') with '(shown)' > Need to say what happens if a normal PackageImport is used by a Profile. > In the example I don't see why Metaclass1 is hidden - since it's > contained by the Package which is <>d. And why an > explicit reference is needed for Metaclass2 when it's owned by the > Package. There is clearly something going on that I'm not getting - > and I was involved in t he calls on this subject! > I think we could do with some OCL to be clear exactly what the set > of 'accessible' elements is. > Likewise I do not understand the paragraph about combining imports > if one Profile imports another. If P1 imports P2 when why combine > 'at the P2 level'? > Generally there are several typos and the English needs tidying up. Will pull this. > 8752: the Issue summary is missing words - it says " instead > of " I will fix this. > 8759: revised text should refer to "OpaqueAction, Generalizations" > not "Actions, Generalizations". Good eye. I will fix this editorially. > 8867: again the final 2 sentences should have 'subsets' not 'specializes'. See above. Thanks...Bran From: "Thomas Weigert" To: "'Branislav Selic'" , Subject: RE: Revised draft of ballot 6 Date: Mon, 18 Jul 2005 16:50:21 -0500 X-Mailer: Microsoft Outlook, Build 10.0.6626 Dear all, no problem with delaying the items below... some comments... 7967: So sorry, Tim, I completely misread the issue and Oystein's comments. 8026 (not 8206): I would suggest that the alternative presentation should be clearly discussed on the wiki, not just referenced. On my browser, I cannot even print the JOT article (it cuts of half of the right edge), so it is difficult to comment on. 8028 (not 8208): I couldn't find the comment that Bran had which warrented withdrawal from the ballot... please add to the wiki... Thanks, Th. P.S. I added the comments from the emails to the wiki.. please post your feedback there to maintain the discussion trace.... -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, July 18, 2005 11:21 AM To: uml2-rtf@omg.org Subject: Revised draft of ballot 6 Attached is a new version of ballot 6 with all changes made based on comments from Tim, Pete, and myself. If you enable the "view changes" feature in Word, you can see precisely what has changed. (The changes also explain the seemingly pointless blank pages in this draft -- however, those will disappear in the final version.) Resolutions pulled from this draft: 7967 8206 8208 8706 This ballot is down to a paltry 27 resolutions. But, at least we are back in business. Thanks, Bran Subject: RE: Feedback on draft of ballot 6 Date: Tue, 19 Jul 2005 08:43:46 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback on draft of ballot 6 thread-index: AcWLrEJvozwoIC/OQW+XhiKBguLnpAAf9fdQ From: "Tim Weilkiens" To: "Branislav Selic" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j6J6uqhh020322 > 8028: > The proposed resolution eliminates the need for one of the > variants of the standard stereotype. Therefore, it > should also propose removal of the corresponding stereotype > (including the reference to it on page 745) I can't find the reference to the stereotype. Maybe I'm blind, but I can't see the relationship to the stereotype. <> is defined twice (p. 754): As a stereotype of the Usage relationship between two classifiers. That's not the case for fig. 103/121. As a stereotype of the BehavioralFeature to specify e.g. a constructor. That's also not the case for fig. 103/121. Tim > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Monday, July 18, 2005 5:16 PM > To: uml2-rtf@omg.org > Subject: Feedback on draft of ballot 6 > > > Here is my feedback on the proposed resolutions for ballot 6 > (there are so much mechanics in putting together a ballot, > that I often do not have time to actually read the proposed > resolution texts): > > 7967: > I believe that this is really a recommendation to defer the > issue until the simple time model is reworked. (The issue > text looks perfectly clear to me and asks for a reasonable > generalization that the target of this action should be > either a variable or an attribute.) I think that I will pull > this proposal until we've had a chance to discuss it further. > > 8026: > Although I dislike the current notation, it is in the adopted > spec and should only be eliminated if there is something > incorrect about it. This is not the case. The issue text is > proposing an alternative, which I do not believe has been > explored enough (the discussion is limited to an attack and > defense of what is currently there -- this is really not > addressing the issue). I am inclined to pull this one as well. > > 8028: > The proposed resolution eliminates the need for one of the > variants of the standard stereotype. Therefore, it > should also propose removal of the corresponding stereotype > (including the reference to it on page 745) > > 8167: > The revised text seems to address a different issue than the > one that is in the submission. I think that the different > issue should be raised and resolved separately and that this > one should simply be a "closed, no change" (I can do this as > an editorial fix.) > > 8180: > The form "Specialized from " only appears in the > Actions chapter, instead of the standard form "Subsets > " used elsewhere. I think that this particular > resolution should go in but a separate issue raised that > changes all of these non-standard forms to the standard form. > > 8407: > the item that changes "no additional attributes" to "None" > should be removed from the resolution (see my previous e-mail) > The subsets should follow the standard convention of > qualifying the property, thus "subsets ownedElement" should > be "subsets Element::ownedElement" > The above two changes need to be made also to resolutions to > issues 8408, 8409, and 8410 > There is a spurrious paragraph beginning with "Depending on > the context" which should be removed from the resolution -- > although some explanation should be provided for how this > part of the issue was resolved. > Except for the last item, I will make all the changes to the > resolutions above, since they are editorial. > > 8706: > The resolution only provides a fix for the Superstructure -- > a fix for the infrastructure should also be added (I can add > that as an editorial fix). > > To summarize, it looks like 7967, 8026, and 8028 will be > pulled from the ballot. Two new issues need to be raised > related to 8167 and 8180 (I will raise them) and a number of > editorial fixes to the proposed texts need to be made. > > Regards, > Bran > To: "Tim Weilkiens" Cc: uml2-rtf@omg.org Subject: RE: Feedback on draft of ballot 6 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 19 Jul 2005 09:04:30 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 07/19/2005 09:04:30, Serialize complete at 07/19/2005 09:04:30 Tim, You wrote: > I can't find the reference to the stereotype. > Maybe I'm blind, but I can't see the relationship to the > stereotype. <> is defined twice (p. 754): > > As a stereotype of the Usage relationship between two classifiers. > That's not the case for fig. 103/121. > > As a stereotype of the BehavioralFeature to specify e.g. a constructor. > That's also not the case for fig. 103/121. In addition to the two standard <> stereotypes, there is also a keyword <> (see table entry on page 747 -- there is also a reference to this keyword on page 745). I had erroneously assumed that figure 103 was using the first case of the <> system stereotype. However, the text on page 175 clearly says that the keyword was intended (my apologies to Thomas for not reading this carefully enough). It seems that the notation description attached to the < keyword on page 747 should now be changed, because the resolution no longer uses the old notation. Bran Issue 8028: create dependency Figures 103 and 121 Issue summary create dependency Figures 103 and 121 use create dependencies, which do not apply to the example. Standard stereotypes defines create for Behavioral Feature? as: 'Specifies that the designated feature creates an instance of the classifier to which the feature is attached. May be promoted to the Classifier containing the feature.' Discussion The issue is correct in pointing out that the notation for constructors could be improved. -- ThomasWeigert - 18 May 2005 Personally, I think this notation is not useful at all. It is imprecise and takes up too much real-estate to do this. I would suggest removing it altogether. -- BranSelic - 19 May 2005 Defining constructors in terms of the instances which are created is widely actually being used. -- ThomasWeigert - 20 May 2005 The resolution defines the semantics for usage dependencies between an operation and an instance value as specifying the return value. However, the semantics of usage dependency says: "The usage dependency does not specify how the client uses the supplier other than the fact that the supplier is used by of the definition or implementation of the client." The specific semantics in the resolution would need a stereotype, and should be defined in the classes chapter, and used here. -- ConradBock - 23 May 2005 It is not the usage dependency that does anything. The client just uses the pointed to supplier to create an instance. This is not defined by the dependency, but part of the semantics of the client. So I believe this is exactly in line with how to use dependencies. Otherwise, you would have to have stereotypes for any kind of usage dependency. -- ThomasWeigert - 24 May 2005 If the meaning of the dependency is up to the client, then this is not a standard way to define constructors and shouldn't be in the spec. -- ConradBock - 25 May 2005 Conrad, "dependency" in UML does not carry semantics but just indicate a relationship. This is also true here. But a client is free to say what happens when such relationships exist. That is how one would use dependencies. For example: a child is dependent on a parent. Some children leave home early, and some are still living at home when they are 40. This is not part of the semantics of dependency, but is an aspect of the child (probably the parent to, but let's ignore that sociological aspect here...) -- ThomasWeigert - 26 May 2005 Dependencies may not have direct runtime semantics, but they do say something about the specifications being related, which in turn places a constraint on runtime. For example, the <> stereotype of the Uses dependency indicates that some operations on the client create instances of the supplier. In this case we're discussing now, the dependency is trying to say that the operation must have a return result that conforms to the instance specification. The current proposal leaves this meaning up to the implementation, ie, does not standardize it, so could only be included in the example section. Not sure I follow the analogy to parent/child. -- ConradBock - 03 Jun 2005 The current proposal gives no additional semantics to the dependency. Instead it defines the semantics of the client differently, depending on whether there is such dependency or not. Similarly, when a child relies on one's parents kindness by living at home at age 40 this is not part of the definition of the parent-child relationship, but a special behavior of the child. -- ThomasWeigert - 04 Jun 2005 Thanks for the revised text below, it uses <> consistently with the standard profile. But the convention defined here for constructors is more general than composite structure. It should go in Classes. -- ConradBock - 17 Jul 2005 it seems intuitively wrong to have a constructor dependent on an instance. Also the definition of a constructor as "A constructor is any operation having a single return result parameter of the type of the owning class." seems over-general. e.g. the Person::getMother() operation returns a Person but is not a constructor by any stretch. Furthermore there are genuine constructors that are not defined on t he owning class (e.g. those owned by factory classes). -- PeteRivett 17 Jul 2005 Pete, you are right on the comment regarding over-generalization. I did not think of it this way, but I can see that one could read the text you cite as a definition of constructor and that is wrong. It meant to state a necessary condition, not a sufficient condition... I changed "any" to "an" which should clarify this... -- ThomasWeigert - 18 Jul 2005 I think that the old notation should be retained since I have not seen any convincing arguments why it should be removed (even though I dislike the notation myself), especially since removing it might create problems for tool vendors that may have already implemented it. However, the proposed resolution has removed any reason for retaining the <>. system stereotype of Dependency. Hence, as part of this resolution, there should be a corresponding fix that removes this stereotype and all of its references from the spec (they are limited to Appendix C, I believe). -- BranSelic - 18 Jul 2005 It's fine with me to keep it, but it should be in Classes. It is a generic notation, not specific to composite structure. -- ConradBock - 21 Jul 2005 I agree with Conrad, but that does not appear to be feasible. I don't think the compliance level for classes would like to add this additional presentation option? -- ThomasWeigert - 28 Jul 2005 Revised Test In Figure 103, invert the arrow and delete the stereotype «create». Insert the stereotype «create» before the operation name .make.. Change the paragraph preceding figure 103 as follows: A usage dependency may relate an instance value to a constructor for a class, describing the single value returned by the constructor operation. The operation is the client, the created instance the supplier. The instance value may reference parameters declared by the operation. A constructor is an operation having a single return result parameter of the type of the owning class. The instance value that is the supplier of the usage dependency represents the default value of the single return result parameter of a constructor operation. (The constructor operation is typically denoted by the stereotype «create», as shown in Figure 103. In Figure 121, invert the arrow and delete the stereotype «create». Insert the stereotype «create» before the operation name .make.. Resolution Resolved RtfIssue1000000041 (28 Jul 2005 - 07:59 - r1.5 - ThomasWeigert) Issue 8028: create dependency Figures 103 and 121 Issue summary create dependency Figures 103 and 121 use create dependencies, which do not apply to the example. Standard stereotypes defines create for Behavioral Feature? as: 'Specifies that the designated feature creates an instance of the classifier to which the feature is attached. May be promoted to the Classifier containing the feature.' Discussion The issue is correct in pointing out that the notation for constructors could be improved. -- ThomasWeigert - 18 May 2005 Personally, I think this notation is not useful at all. It is imprecise and takes up too much real-estate to do this. I would suggest removing it altogether. -- BranSelic - 19 May 2005 Defining constructors in terms of the instances which are created is widely actually being used. -- ThomasWeigert - 20 May 2005 The resolution defines the semantics for usage dependencies between an operation and an instance value as specifying the return value. However, the semantics of usage dependency says: "The usage dependency does not specify how the client uses the supplier other than the fact that the supplier is used by of the definition or implementation of the client." The specific semantics in the resolution would need a stereotype, and should be defined in the classes chapter, and used here. -- ConradBock - 23 May 2005 It is not the usage dependency that does anything. The client just uses the pointed to supplier to create an instance. This is not defined by the dependency, but part of the semantics of the client. So I believe this is exactly in line with how to use dependencies. Otherwise, you would have to have stereotypes for any kind of usage dependency. -- ThomasWeigert - 24 May 2005 If the meaning of the dependency is up to the client, then this is not a standard way to define constructors and shouldn't be in the spec. -- ConradBock - 25 May 2005 Conrad, "dependency" in UML does not carry semantics but just indicate a relationship. This is also true here. But a client is free to say what happens when such relationships exist. That is how one would use dependencies. For example: a child is dependent on a parent. Some children leave home early, and some are still living at home when they are 40. This is not part of the semantics of dependency, but is an aspect of the child (probably the parent to, but let's ignore that sociological aspect here...) -- ThomasWeigert - 26 May 2005 Dependencies may not have direct runtime semantics, but they do say something about the specifications being related, which in turn places a constraint on runtime. For example, the <> stereotype of the Uses dependency indicates that some operations on the client create instances of the supplier. In this case we're discussing now, the dependency is trying to say that the operation must have a return result that conforms to the instance specification. The current proposal leaves this meaning up to the implementation, ie, does not standardize it, so could only be included in the example section. Not sure I follow the analogy to parent/child. -- ConradBock - 03 Jun 2005 The current proposal gives no additional semantics to the dependency. Instead it defines the semantics of the client differently, depending on whether there is such dependency or not. Similarly, when a child relies on one's parents kindness by living at home at age 40 this is not part of the definition of the parent-child relationship, but a special behavior of the child. -- ThomasWeigert - 04 Jun 2005 Thanks for the revised text below, it uses <> consistently with the standard profile. But the convention defined here for constructors is more general than composite structure. It should go in Classes. -- ConradBock - 17 Jul 2005 it seems intuitively wrong to have a constructor dependent on an instance. Also the definition of a constructor as "A constructor is any operation having a single return result parameter of the type of the owning class." seems over-general. e.g. the Person::getMother() operation returns a Person but is not a constructor by any stretch. Furthermore there are genuine constructors that are not defined on t he owning class (e.g. those owned by factory classes). -- PeteRivett 17 Jul 2005 Pete, you are right on the comment regarding over-generalization. I did not think of it this way, but I can see that one could read the text you cite as a definition of constructor and that is wrong. It meant to state a necessary condition, not a sufficient condition... I changed "any" to "an" which should clarify this... -- ThomasWeigert - 18 Jul 2005 I think that the old notation should be retained since I have not seen any convincing arguments why it should be removed (even though I dislike the notation myself), especially since removing it might create problems for tool vendors that may have already implemented it. However, the proposed resolution has removed any reason for retaining the <>. system stereotype of Dependency. Hence, as part of this resolution, there should be a corresponding fix that removes this stereotype and all of its references from the spec (they are limited to Appendix C, I believe). -- BranSelic - 18 Jul 2005 It's fine with me to keep it, but it should be in Classes. It is a generic notation, not specific to composite structure. -- ConradBock - 21 Jul 2005 I agree with Conrad, but that does not appear to be feasible. I don't think the compliance level for classes would like to add this additional presentation option? -- ThomasWeigert - 28 Jul 2005 Revised Test In Figure 103, invert the arrow and delete the stereotype «create». Insert the stereotype «create» before the operation name .make.. Change the paragraph preceding figure 103 as follows: A usage dependency may relate an instance value to a constructor for a class, describing the single value returned by the constructor operation. The operation is the client, the created instance the supplier. The instance value may reference parameters declared by the operation. A constructor is an operation having a single return result parameter of the type of the owning class. The instance value that is the supplier of the usage dependency represents the default value of the single return result parameter of a constructor operation. (The constructor operation is typically denoted by the stereotype «create», as shown in Figure 103. In Figure 121, invert the arrow and delete the stereotype «create». Insert the stereotype «create» before the operation name .make.. Resolution Resolved RtfIssue1000000041 (28 Jul 2005 - 07:59 - r1.5 - ThomasWeigert) Reply-To: From: "Conrad Bock" To: Subject: RE: Draft ballot 7 -- please review Date: Tue, 2 Aug 2005 15:36:09 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Bran, Comments on draft ballot 7. Conrad - Issue 8021: Section: Classes The discussion says "There are no constraints or any other connection between properties B::aend and SubB::subA", but there must be. For example, if there is an instance of SubB, and you navigate from it along the inherited B::aend, the result should be the instances of A related by that association, including the ones created on instances of SubA with SubB::subA. How can it have this semantics if B::aend and SubB::subA aren't related? Needs more discussion, especially in relation to the text references in Association Semantics, see 8023 below. - Issue 8023: Association specialization semantics This didn't address the issues that some of the text applies to Generalization. The cited text, including the proposed revision, is especially confusing because the semantics of Generalization in UML is that all the instances of the subtype are instances of the supertype, so subtyping in UML implies subsetting. It is not necessarily proper subsetting, as the cited text explains, but that is a minor point. Subsetting/specialization in UML can be achieved by subtyping (adding attributes, etc), but can only be done by adding constraints to the subtype. In particular, for association classes, the user should be able to specialize an association class with another association class with the same semantics as to subsetting ends. Should discuss more. - Issue 8028: create dependency Figures 103 and 121 This way of modeling a constructor should be in Classes, which Thomas agrees with. His question on the wiki was about whether compliance levels permitted it, but I can't see why they wouldn't. Seems like it can be moved to Classes with no adverse effect. - Issue 8038: IsReadOnly constriant This is overconstrained, because the default value could be set dynamically before initialization, rather than a default value. As long as this happens before initialization is over, there is no violation of multiplicity. In any case, UML doesn't enforce when constraints are evaluated or inconsistencies repaired. Tim's response on the wiki only came on the 29th, so I hadn't replied, but it was only about the wording I used on the wiki, which I corrected to the above. Never mind that I filed the issue! - Issue 8078: Actor is a specialized Classifier and not BehavioredClassifier There isn't anything I can find on BehavioredClassifier that says it supports interfaces. - Issue 8677: token movement In the revised text, update the new sentence to "For brevity, the specification uses the terms "flow", "pass", "traverse" interchangeably in relation to tokens to mean offering tokens, and movement of tokens when offers are accepted. - Issue 8751: Relations I agree with the filer here. We should discuss more. - Issue 8758: Association in UseCase diagram Can't say there hasn't been enough discussion, but use cases have had associations between them for so long, that it doesn't seem