Issue 8026: Contextualized attribute values Figures 121 (uml2-rtf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Critical Summary: Contextualized attribute values Figures 121 is an unworkable solution to defining contextualized attribute values. It requires restating all the parts and connectors in the composite class, otherwise the constructor would be incomplete. The class-based solution requires separate properties for each contextualized value with connectors to them from the contextualized property. The metamodel should be extended to include contextualized datatype properties, or at least a presentation option for the current cumbersome model (see Figure 12 and discussion in http://www.jot.fm/issues/issue_2004_11/column5 Resolution: Revised Text: Actions taken: December 30, 2004: received issue Discussion: Disposition: Deferred to UML 2.4 RTF End of Annotations:===== m: webmaster@omg.org Date: 30 Dec 2004 15:25:13 -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: Revision Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) Description Contextualized attribute values Figures 121 is an unworkable solution to defining contextualized attribute values. It requires restating all the parts and connectors in the composite class, otherwise the constructor would be incomplete. The class-based solution requires separate properties for each contextualized value with connectors to them from the contextualized property. The metamodel should be extended to include contextualized datatype properties, or at least a presentation option for the current cumbersome model (see Figure 12 and discussion in http://www.jot.fm/issues/issue_2004_11/column5 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 8026: Contextualized attribute values Figures 121 Issue summary Contextualized attribute values Figures 121 is an unworkable solution to defining contextualized attribute values. It requires restating all the parts and connectors in the composite class, otherwise the constructor would be incomplete. The class-based solution requires separate properties for each contextualized value with connectors to them from the contextualized property. The metamodel should be extended to include contextualized datatype properties, or at least a presentation option for the current cumbersome model (see Figure 12 and discussion in http://www.jot.fm/issues/issue_2004_11/column5 Discussion Figure 121 shows how to define constructors for (structured) classes graphically by associating an instance of a classifier with the classifier. It is unclear how the issue summary relates to this figure. The author of the issue is invited to clarify his concern in more detail. -- ThomasWeigert - 19 May 2005 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. -- ConradBock - 23 May 2005 Conrad, you are not clarifying but just repeating the summary... -- ThomasWeigert - 24 May 2005 The clarification is what the figure is attempting to do with the constructor. In past discussion, the issue of contextualized data values has been relegated to constructors. This figure shows how to go about it. The issue explains why the technique doesn't work, including the scaling problem Bran noted, and proposes another solution. -- ConradBock - 25 May 2005 It appears to me that the figure is perfectly clear and that the solution works well. Can you explain what you think does not scale and why the solution does not work. Just repeating over and over again it does not work really is not helpful. If you have some discussion elsewhere, please post it here... -- ThomasWeigert - 04 Jun 2005 Revised Test Resolution Issue 8026: Contextualized attribute values Figures 121 Issue summary Contextualized attribute values Figures 121 is an unworkable solution to defining contextualized attribute values. It requires restating all the parts and connectors in the composite class, otherwise the constructor would be incomplete. The class-based solution requires separate properties for each contextualized value with connectors to them from the contextualized property. The metamodel should be extended to include contextualized datatype properties, or at least a presentation option for the current cumbersome model (see Figure 12 and discussion in http://www.jot.fm/issues/issue_2004_11/column5 Discussion Figure 121 shows how to define constructors for (structured) classes graphically by associating an instance of a classifier with the classifier. It is unclear how the issue summary relates to this figure. The author of the issue is invited to clarify his concern in more detail. -- ThomasWeigert - 19 May 2005 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. -- ConradBock - 23 May 2005 Conrad, you are not clarifying but just repeating the summary... -- ThomasWeigert - 24 May 2005 The clarification is what the figure is attempting to do with the constructor. In past discussion, the issue of contextualized data values has been relegated to constructors. This figure shows how to go about it. The issue explains why the technique doesn't work, including the scaling problem Bran noted, and proposes another solution. -- ConradBock - 25 May 2005 It appears to me that the figure is perfectly clear and that the solution works well. Can you explain what you think does not scale and why the solution does not work. Just repeating over and over again it does not work really is not helpful. If you have some discussion elsewhere, please post it here... -- ThomasWeigert - 04 Jun 2005 Revised Test Resolution Closed no change Subject: RE: Proposals for Ballot 6 Date: Wed, 13 Jul 2005 05:14:11 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposals for Ballot 6 Thread-Index: AcWHIlNRt/pssoD6Rf2tMK21bz0XzAAZHUdA From: "Pete Rivett" To: "Thomas Weigert" , "Branislav Selic" , X-Virus-Scanned: by amavisd-new at sentraliant.com I just noticed a common typo - the heading below is 'Revised Test' instead of 'Revised Text' (with a penultimate 'x') It seems premature to close 8026. I repeat my comment made on previous resolutions that I don't think back-and-forth conversations belong in the formal issue resolution ballot and the eventual RTF report. I think the 'Discussion' section of the resolution should be a summary of any threaded discussions in terms of options considered, clarification of the issue and most importantly rationale for the actual revised text. Don't forget that the FTF Report is a formal OMG document. Nor is it necessary to have a change history for the resolution in the ballot/report. I guess what I'm saying is that the Discussion section should be a separate authored section in the Wiki and not just a copy of the change/discussion log. Pete 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: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Tuesday, July 12, 2005 9:23 PM To: 'Branislav Selic'; uml2-rtf@omg.org Subject: Proposals for Ballot 6 The following proposals are submitted at this point for ballot 6. Each has been soaking on the twiki for several weeks (in some cases months). http://modeldrivenengineering.org/bin/view/Umlrtf/CurrentProposals?ballot=6 Th. Issues attached below: RtfIssue1000000018 (12 Jul 2005 - 17:50 - r1.3 - ThomasWeigert) Issue 7967: An observed time value must be written into a structural feature Issue summary Time Observation Action? is a specialized Write Structural Feature Action?. An observed time value must be written into a structural feature. If modeling activities with that kind of action it would be useful to be able to write the time value to a variable instead of a structural feature. The time value is often used temporarily Discussion The issue is understandable. However, I believe that we will modify the simple time model (due to other issues) such that the Time Observation? and Duration Observation? will be something different from Actions. There may still be a need to record the current time within the model execution itself, and this can be achieved by letting 'now' be predefined literal of Time Expression? with the obvious interpretation. -- OysteinHaugen - 08 Jun 2005 Agreed with Oystein. Propose closing due to the unclear issue formulation. Revised Test Resolution Closed no change RtfIssue1000000020 (12 Jul 2005 - 20:18 - r1.6 - ThomasWeigert) Issue 8026: Contextualized attribute values Figures 121 Issue summary Contextualized attribute values Figures 121 is an unworkable solution to defining contextualized attribute values. It requires restating all the parts and connectors in the composite class, otherwise the constructor would be incomplete. The class-based solution requires separate properties for each contextualized value with connectors to them from the contextualized property. The metamodel should be extended to include contextualized datatype properties, or at least a presentation option for the current cumbersome model (see Figure 12 and discussion in http://www.jot.fm/issues/issue_2004_11/column5 Discussion Figure 121 shows how to define constructors for (structured) classes graphically by associating an instance of a classifier with the classifier. It is unclear how the issue summary relates to this figure. The author of the issue is invited to clarify his concern in more detail. -- ThomasWeigert - 19 May 2005 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. -- ConradBock - 23 May 2005 Conrad, you are not clarifying but just repeating the summary... -- ThomasWeigert - 24 May 2005 The clarification is what the figure is attempting to do with the constructor. In past discussion, the issue of contextualized data values has been relegated to constructors. This figure shows how to go about it. The issue explains why the technique doesn't work, including the scaling problem Bran noted, and proposes another solution. -- ConradBock - 25 May 2005 It appears to me that the figure is perfectly clear and that the solution works well. Can you explain what you think does not scale and why the solution does not work. Just repeating over and over again it does not work really is not helpful. If you have some discussion elsewhere, please post it here... -- ThomasWeigert - 04 Jun 2005 Revised Test Resolution Closed no change RtfIssue1000000021 (12 Jul 2005 - 20:09 - r1.3 - ThomasWeigert) Issue 8027: Connector multiplicity notation Issue summary Connector multiplicity notation The notation section of Connector End? says multiplicities shown on connector lines represent the multiplicities of both the association and the connector: These adornments specify properties of the association typing the connector. The multiplicity indicates the number of instances that may be connected to each instance of the role on the other end. But these multiplicity can be different, and have separate elements in the metamodel. Discussion The adornments on connector ends either specify properties of the association that types the owning connector (when that association is inferred) or it reflects properties of that association, otherwise. The multiplicity may be more specific than the multiplicity of the association typing the connector. Revised Test In 9.3.7., sub-section .Constraints. add [4] The multiplicity of the connector end may not be more general than the multiplicity of the association typing the owning connector. In 9.3.7., sub-section .Notation., replace .These adornments specify properties of the association typing the connector.. by .These adornments specify properties of the association typing the connector, if that association was inferred, or show properties of that association, otherwise.. Resolution Resolved RtfIssue1000000022 (12 Jul 2005 - 20:19 - r1.10 - 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 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 RtfIssue1000000063 (12 Jul 2005 - 17:46 - r1.8 - ThomasWeigert) Issue 8308: Section: 13.3.14 Issue summary Add OCL notation or a note that OCL is unable define a notation for the constraints. Discussion Regarding the solution below, what about recursive nesting level (e.g., the attributes of the attributes)? -- ThomasWeigert - 19 May 2005 Good question. I've changed the OCL slightly and introduced a recursive function. Please check! I'm not sure what happens if d.ownedAttributes is a empty set? Does it evaluate to true? -- Tim Weilkiens - 20 May 2005 Fixed recursive function to work on the type of the ownedAttributes not the attributes themselves. Fixed first constraint to test the size() of the select result. -- PeteRivett - 28 Jun 2005 Revised Test In constraints section of 13.3.14: Add OCL to constraints: [1] A function behavior has at least one output parameter. self.ownedParameters->select(p|p.direction=#out or p.direction=#inout)->size() >= 1 [2] The types of parameters are all data types, which may not nest anything but other datatypes. def: hasNestedDataTypes(d : DataType) : Boolean = d.ownedAttribute->forAll(a|a.type.isEmpty() or ( a.type.oclIsTypeOf(DataType) and hasNestedDataTypes(a.type))) self.ownedParameters->forAll(p|p.type.notEmpty() and p.oclIsTypeOf(DataType) and hasNestedDataTypes(p)) Resolution Reply-To: From: "Conrad Bock" To: "Thomas Weigert" , "'Branislav Selic'" , Subject: RE: Proposals for Ballot 6 Date: Thu, 14 Jul 2005 09:56:48 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Thomas, Thanks for the proposals, see comments below. Would it be possible to include the ones I posted for 8031 and 8032 some weeks ago (on the RTF list and wiki)? See attached. > The following proposals are submitted at this point for ballot > 6. Each has been soaking on the twiki for several weeks (in some > cases months). Just a reminder that the wiki is not an OMG forum. The soaking period begins when proposals are posted to the RTF list. Bran, I'd like to postpone 8026, and it seems like 7967 should be also. I think 8028 should be in different chapter, since it is more general than composite structure, and have some suggested revisions to OCL in 8308. Conrad - Issue 7967 (An observed time value must be written into a structural feature) Since the discussion points to a future resolution, it would be better to wait for that and address both. The issue is clearly written. - Issue 8026 (Contextualized attribute values Figures 121) I missed your response on the wiki asking for the reference to posted there (you can respond to it even if it isn't on the wiki, it's all off-list anyway). The discussion should also include Bran's comment on scaling in the discussion. I would like to post a short write up rather than take it to ballot right now. - Issue 8027 (Connector multiplicity notation) Perhaps the issue wasn't clearly written. The text says the adornments show the multiplicity of the association, omitting that they can also show the multiplicity of the connector end. Suggested rewording: In 9.3.7., sub-section Notation, replace "These adornments specify properties of the association typing the connector." by "These adornments specify properties of the association typing the connector, if that association was inferred. Otherwise, they show properties of that association, or specializations of these on the connector." BTW, what does it mean to "infer" an association for a connector? - Issue 8028 (create dependency Figures 103 and 121) Thanks, this uses <> consistently with the standard profile. But the convention defined here for constructors is more general than composite structure. It should go in Classes. - Issue 8308: Section: 13.3 This was intended to refer to return parameters (got confused with output pins): [1] A function behavior has at least one output parameter. self.ownedParameters->select(p|p.direction=#out or p.direction=#inout)->size() >= 1 I guess it could be generalized to: [1] A function behavior has at least one output parameter. self.ownedParameters->select(p|p.direction=#out or p.direction=#inout or p.direction=#return)->size() >= 1 In the second one, hasNestedDataTypes allows empty types for data type attributes, which are not allowed by the text of the constraint. Also the name hasNestedDataTypes implies there must be nested datatypes. [2] The types of parameters are all data types, which may not nest anything but other datatypes. def: hasNestedDataTypes(d : DataType) : Boolean = d.ownedAttribute->forAll(a| a.type.isEmpty() or (a.type.oclIsTypeOf(DataType) and hasNestedDataTypes(a.type))) self.ownedParameters->forAll(p|p.type.notEmpty() and p.oclIsTypeOf(DataType) and hasNestedDataTypes(p)) Suggested revision: [2] The types of parameters are all data types, which may not nest anything but other datatypes. def: hasAllDataTypeAttributes(d : DataType) : Boolean = d.ownedAttribute->forAll(a| a.type.oclIsTypeOf(DataType) and hasAllDataTypeAttributes(a.type)) self.ownedParameters->forAll(p|p.type.notEmpty() and p.oclIsTypeOf(DataType) and hasAllDataTypeAttributes(p)) The OCL spec is a bit unclear on whether forall over an empty collection is true, but it says it's false if one of the them is false, so I hope if there are none, then its true. That's the usual convention. 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 Subject: RE: DRAFT of ballot 6 Date: Mon, 18 Jul 2005 09:55:05 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DRAFT of ballot 6 thread-index: AcWLCt/b7305OBOARUqJofpn5FvgswAXbRCg From: "Tim Weilkiens" To: "Branislav Selic" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j6I889hh004628 7967 I agree with Pete. Issue can't be understandable and unclear at the same time. Isn't is useful to ask the submitter of the issue if it is unclear? I'm the source of this issue Probably my summary isn't understandable enough. The scenario is simple: Compare a timestamp stored in a property with the current timestamp (now). To model this it is necessary to store the current timestamp in another property although it is only used temporarily for the comparison. 8026 I can't see the argument that leads to the resolution to close the issue with no change. 8753 Discussion section contains a new issue (inconsistent BNF). Is that one submitted? Tim --- Tim Weilkiens, E-Mail tim.weilkiens@oose.de Instructor, Consultant, Coach OMG Representative, INCOSE member oose.de GmbH, Hamburg, CEO Bernd Oestereich, Internet http://www.oose.de > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Sunday, July 17, 2005 9: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 Reply-To: From: "Conrad Bock" To: "uml2rtf" Subject: RE: DRAFT of ballot 6 - issue 8026 Date: Tue, 19 Jul 2005 15:33:59 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, Regarding 8026: > [Bran] Although I dislike the current notation, it is in the adopted > spec and should only be eliminated if there is something incorrect > about it. I'm not recommending removing it, only that a presentation option that addresses its problems. Will incorporate in the wiki as Thomas requested. (Thomas, you can download the JOT PDF if you like, rather than the HTML). Conrad From: "Thomas Weigert" To: , "'uml2rtf'" Subject: RE: DRAFT of ballot 6 - issue 8026 Date: Tue, 19 Jul 2005 16:26:48 -0500 X-Mailer: Microsoft Outlook, Build 10.0.6626 Conrad, I cannot see how to download the PDF. Pleaes advise... Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Tuesday, July 19, 2005 2:34 PM > To: uml2rtf > Subject: RE: DRAFT of ballot 6 - issue 8026 > > > > Bran, > > Regarding 8026: > > > [Bran] Although I dislike the current notation, it is in > the adopted > > spec and should only be eliminated if there is something incorrect > > about it. > > I'm not recommending removing it, only that a presentation option that > addresses its problems. Will incorporate in the wiki as Thomas > requested. (Thomas, you can download the JOT PDF if you like, rather > than the HTML). > > Conrad > Reply-To: From: "Conrad Bock" To: "Thomas Weigert" , "'uml2rtf'" Subject: RE: DRAFT of ballot 6 - issue 8026 Date: Thu, 21 Jul 2005 13:31:44 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, > I cannot see how to download the PDF. Pleaes advise... Th. It's the little PDF icon on the right margin, to the right of the title. http://www.jot.fm/issues/issue_2004_11/column5. Reply-To: From: "Conrad Bock" To: "Thomas Weigert" , "'Branislav Selic'" , Subject: RE: Ballot 11 resolutions? Date: Fri, 21 Oct 2005 11:00:13 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Thomas, Bran, Comments on the Composite WG proposals. Conrad - Issue 8031: Destruction semantics in StructuredClassifier It says: Marking this issue as closed, as the proposed text is already essentially contained in the specification, in the section on connectors, please see p.171 of the current spec, Semantics of connector: "All links are destroyed when the containing classifier instance is destroyed." Note that the all links here refers to links due to connectors. So this is precisely what the proposed revised text is saying, ignoring that this is now proposed as a semantic variation. This would make the text inconsistent, as in the connector section this is not a semantic variation. The sentence "All links are destroyed when the containing classifier instance is destroyed." doesn't say which links. It is exactly the clarification above that the proposal addresses The proposed text was moved to a semantic variation because Bran didn't want it required. Presumably he would disagree with your interpretatioin of the existing text. The proposal is: In Section 9.3.13., subsection "Semantic Variation Point" add new paragraph at the end "When an instance of a structured classifier is destroyed, all links may be destroyed that exist only because of connectors between roles of the structured classifier. This clarifies the existing text and satisfies Bran's request that the semantics be a variation point. - Issue 8026: Contextualized attribute values Figures 121 http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue1000000020 I think waiting a month to respond and delaying on the last ballot isn't good process. I would like this included in ballot 11. Your comments on the web were: > I don't think this is ready for prime time for two reasons: > There are discussions in other groups for a different use of this > graphical construct, e.g., in Sys ML? to show nested parts. I think > that this is a sensible idea, however. The SST proposal already has this presentation option. It is useful generally. The lines in the diagram are still unclear. Maybe you could show the Buy Sell Dialog Class? definition, so that it would be more obvious what you are talking about with those lines. You say they are connectors, but (i) what do the role names mean (I know they are legal, but really have no meaning at all in UML, but you seem to attach semantics to them); (ii) they really appear to be more like associations in your example. The lines are connectors, as in an any composite structure diagram. As the text explains, this just modifies it to support shoing default property values on the type of a part. To: Cc: "Thomas Weigert" , uml2-rtf@omg.org Subject: RE: Ballot 11 resolutions? X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 24 Oct 2005 18:10:30 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 10/24/2005 18:10:40, Serialize complete at 10/24/2005 18:10:40 I agree with Conrad's ammendment on issue 8031. As for issue 8026, since there seems to be no consensus after a lot of discussion, I suggest that Thomas propose a resolution on which the RTF can vote. Conrad and others who have the same objections as he should freely lobby the other RTF members stating their objections and urging a "no" vote on that resolution proposal. The latter is to ensure that voters are fully informed of the contention about the proposed resolution. Cheers, Bran "Conrad Bock" 10/21/2005 11:00 AM Please respond to conrad.bock To "Thomas Weigert" , Branislav Selic/Ottawa/IBM@IBMCA, cc Subject RE: Ballot 11 resolutions? Hi Thomas, Bran, Comments on the Composite WG proposals. Conrad - Issue 8031: Destruction semantics in StructuredClassifier It says: Marking this issue as closed, as the proposed text is already essentially contained in the specification, in the section on connectors, please see p.171 of the current spec, Semantics of connector: "All links are destroyed when the containing classifier instance is destroyed." Note that the all links here refers to links due to connectors. So this is precisely what the proposed revised text is saying, ignoring that this is now proposed as a semantic variation. This would make the text inconsistent, as in the connector section this is not a semantic variation. The sentence "All links are destroyed when the containing classifier instance is destroyed." doesn't say which links. It is exactly the clarification above that the proposal addresses The proposed text was moved to a semantic variation because Bran didn't want it required. Presumably he would disagree with your interpretatioin of the existing text. The proposal is: In Section 9.3.13., subsection "Semantic Variation Point" add new paragraph at the end "When an instance of a structured classifier is destroyed, all links may be destroyed that exist only because of connectors between roles of the structured classifier. This clarifies the existing text and satisfies Bran's request that the semantics be a variation point. - Issue 8026: Contextualized attribute values Figures 121 http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue1000000020 I think waiting a month to respond and delaying on the last ballot isn't good process. I would like this included in ballot 11. Your comments on the web were: > I don't think this is ready for prime time for two reasons: > There are discussions in other groups for a different use of this > graphical construct, e.g., in Sys ML? to show nested parts. I think > that this is a sensible idea, however. The SST proposal already has this presentation option. It is useful generally. The lines in the diagram are still unclear. Maybe you could show the Buy Sell Dialog Class? definition, so that it would be more obvious what you are talking about with those lines. You say they are connectors, but (i) what do the role names mean (I know they are legal, but really have no meaning at all in UML, but you seem to attach semantics to them); (ii) they really appear to be more like associations in your example. The lines are connectors, as in an any composite structure diagram. As the text explains, this just modifies it to support shoing default property values on the type of a part. To: Cc: "Thomas Weigert" , uml2-rtf@omg.org Subject: RE: Ballot 11 resolutions? X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 24 Oct 2005 18:10:30 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 10/24/2005 18:10:40, Serialize complete at 10/24/2005 18:10:40 I agree with Conrad's ammendment on issue 8031. As for issue 8026, since there seems to be no consensus after a lot of discussion, I suggest that Thomas propose a resolution on which the RTF can vote. Conrad and others who have the same objections as he should freely lobby the other RTF members stating their objections and urging a "no" vote on that resolution proposal. The latter is to ensure that voters are fully informed of the contention about the proposed resolution. Cheers, Bran "Conrad Bock" 10/21/2005 11:00 AM Please respond to conrad.bock To "Thomas Weigert" , Branislav Selic/Ottawa/IBM@IBMCA, cc Subject RE: Ballot 11 resolutions? Hi Thomas, Bran, Comments on the Composite WG proposals. Conrad - Issue 8031: Destruction semantics in StructuredClassifier It says: Marking this issue as closed, as the proposed text is already essentially contained in the specification, in the section on connectors, please see p.171 of the current spec, Semantics of connector: "All links are destroyed when the containing classifier instance is destroyed." Note that the all links here refers to links due to connectors. So this is precisely what the proposed revised text is saying, ignoring that this is now proposed as a semantic variation. This would make the text inconsistent, as in the connector section this is not a semantic variation. The sentence "All links are destroyed when the containing classifier instance is destroyed." doesn't say which links. It is exactly the clarification above that the proposal addresses The proposed text was moved to a semantic variation because Bran didn't want it required. Presumably he would disagree with your interpretatioin of the existing text. The proposal is: In Section 9.3.13., subsection "Semantic Variation Point" add new paragraph at the end "When an instance of a structured classifier is destroyed, all links may be destroyed that exist only because of connectors between roles of the structured classifier. This clarifies the existing text and satisfies Bran's request that the semantics be a variation point. - Issue 8026: Contextualized attribute values Figures 121 http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue1000000020 I think waiting a month to respond and delaying on the last ballot isn't good process. I would like this included in ballot 11. Your comments on the web were: > I don't think this is ready for prime time for two reasons: > There are discussions in other groups for a different use of this > graphical construct, e.g., in Sys ML? to show nested parts. I think > that this is a sensible idea, however. The SST proposal already has this presentation option. It is useful generally. The lines in the diagram are still unclear. Maybe you could show the Buy Sell Dialog Class? definition, so that it would be more obvious what you are talking about with those lines. You say they are connectors, but (i) what do the role names mean (I know they are legal, but really have no meaning at all in UML, but you seem to attach semantics to them); (ii) they really appear to be more like associations in your example. The lines are connectors, as in an any composite structure diagram. As the text explains, this just modifies it to support shoing default property values on the type of a part. Reply-To: From: "Conrad Bock" To: "Thomas Weigert" , "'Branislav Selic'" Cc: Subject: RE: Ballot 11 resolutions? Date: Tue, 25 Oct 2005 18:28:09 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, > 1. Regarding 8031: > > It is inappropriate to have different sections of the > specification say inconsistent things. Personally, I think that > the existing text is perfectly clear. However, in the interest > of compromise I suggest to add the additional wording that > Conrad thinks provides additional detail into the existing text. > However, it should be inserted in the connector chapter, as > there is already text discussing the destruction of connectors. > > So, what about resolving 8031 in the following manner: > > In section 9.3.6. "Connector", subsection "Semantics", replace > the last sentence of the 2nd paragraph by: > > "All such links corresponding to connectors are destroyed, when > the containing classifier instance is destroyed." > > This reflects Conrad's phrasing "all links that exist only > because of connectors between roles of the structured > classifier". However, I use "corresponding to connectors" to > match the sentence before, where we talk about the creation of > links corresponding to connectors. The connectors being > destroyed are precisely those connectors that we speak about in > the previous sentence. I think this is clearer. This is fine with me, if it is clear from context that the connectors referred to are the ones owned by the class(es) of the object being destroyed. There could be links due to connectors owned by other classes, and these should not be destroyed. > 2. Regarding 8026: > http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue1000000020 > I have been asking for an explanation of the diagram with > Conrad's proposal, but still have not received such. That was on the 20th of this month, after a gap of a month since I posted the last revision. > understand this diagram. Certainly I cannot support a resolution > if I cannot understand what it actually is proposing. Agreed, it's just that there was a month when I didn't know you didn't understand, and it's getting late now. Water under the bridge in any case. > So, please, Conrad, can you give a clear explanation of what the > diagram means that you added to the TWiki. It would be best to > give a repository model, or at least, a clear description of how > this diagram maps onto a meta model. This is a proposal for the Presentation Option section, so the underlying model is no different than usual. The only change is in a optional notation in the structure diagram to show the properties of the classes of the parts (properties). The text is: "Default values for properties of the type of properties in a composite structure can be shown in the property symbol with the same syntax as properties on a class, for example, as shown in Figure ?." It doesn't indicate any other changes to the notation, so everything else is interpreted as normal, eg, lines between part rectangles are connectors, etc. Perhaps the text could be generalized to refer to all aspects of property notation, rather than focus on default values, and use the terminology of the structured classifier, and explain the diagram better. How about: "Properties of the type of properties of roles in a structure diagram can be shown inside the role symbol with the same syntax as properties on a class, for example, as shown in Figure ?. It shows a structured classifier with parts called name, buySellMenu, and okCancel. The properties of the types of these parts are shown in the rectangles for each part." From: "Thomas Weigert" To: , "'Branislav Selic'" Cc: Subject: RE: Ballot 11 resolutions? Date: Tue, 25 Oct 2005 21:22:45 -0500 X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j9Q2Jre4009132 Conrad, Even a presentation option results in something in the metamodel. Anything having to do with notation has to be given an explanation of what the instantiated metamodel is that results from the drawing. In the spec you will find such sentences usually with the phrasing "xxx represents yyy" where xxx is a symbol and yyy is a model element. I cannot make out what the lines are which you say are connectors. Here is what would help to understand: 1. A class diagram for the involved structured class, BuySellDialogClass and class diagrams for the classes typing the internal parts, TextBox, DropDownMenu, and OKCancelButton. 2. An initializer for the structured class using the standard UML 2 way, or alternatively, a repository model for the instance resulting from instantiating the BuySellDialogClass. I am sorry but I cannot fathom what the ":tabTo" connectors are. I understand how the part initialization works, and I think that is a good idea, providing it does not conflict with the two SysML proposals. In the specification, we would have to show the involved classes anyway, as the diagram is obviously not self-explanatory. Thanks, Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Tuesday, October 25, 2005 5:28 PM > To: Thomas Weigert; 'Branislav Selic' > Cc: uml2-rtf@omg.org > Subject: RE: Ballot 11 resolutions? > > > > 2. Regarding 8026: > > > > So, please, Conrad, can you give a clear explanation of what the > > diagram means that you added to the TWiki. It would be best to > > give a repository model, or at least, a clear description of how > > this diagram maps onto a meta model. > > This is a proposal for the Presentation Option section, so the > underlying model is no different than usual. The only change is in a > optional notation in the structure diagram to show the > properties of the > classes of the parts (properties). The text is: > > "Default values for properties of the type of properties in > a composite > structure can be shown in the property symbol with the same > syntax as > properties on a class, for example, as shown in Figure ?." > > It doesn't indicate any other changes to the notation, so everything > else is interpreted as normal, eg, lines between part rectangles are > connectors, etc. > > Perhaps the text could be generalized to refer to all aspects of > property notation, rather than focus on default values, and use the > terminology of the structured classifier, and explain the diagram > better. How about: > > "Properties of the type of properties of roles in a > structure diagram > can be shown inside the role symbol with the same syntax as > properties on a class, for example, as shown in Figure ?. > It shows a > structured classifier with parts called name, buySellMenu, and > okCancel. The properties of the types of these parts are shown in > the rectangles for each part." > > Conrad > From: "Thomas Weigert" To: "'Thomas Weigert'" , , "'Branislav Selic'" Cc: Subject: RE: Ballot 11 resolutions? Date: Tue, 25 Oct 2005 22:15:41 -0500 X-Mailer: Microsoft Outlook, Build 10.0.6626 I have updated the proposal 8031 per the feedback received from Conrad. Below are all the issues from structure/behavior again... I have updated the discussion on 8026 to reflect the recent emails. Th. RtfIssue1000000001 20 Oct 2005 - 07:54 - r1.6 ThomasWeigert Issue 6150: Notation for method Issue summary Provide a notation for a behavior used as a method of an operation Discussion How about waiting until later in the RTF, to see if any consensus builds? Users hit this notational gap right away using UML. -- ConradBock - 23 May 2005 The recommendation from the FTF remains: we need to gain experience with the various notations being considered for profiles before a solution is standardized. -- ThomasWeigert - 17 May 2005 I have struggled using UML2 in this area. If one wants to specify an Operation, specify a Behavior that implements the operation as an Activity, and then invoke the Operation in some other Activity, you have to specify the operation name and parameters many times: In an Interface specification: the operation name, parameters, and raised exceptions (this is good practice separating the specification from the realization) In any Class realizaing that Interface the operation names, parameters, and raised exceptsion have to be specified again. The same information is specified again in the Behavior whose specification is the Operation of the Class If the Behavior is an Activity, Activity Parameter Nodes? must be defined for each of the Behavior's parameters. This is the same information specified four times. Then there are differences in how the operation is invoked: When the Operation is invoked in this or some other activity, Pins must be created and mapped to each of the parameters. When the Operation is invoked in an Interaction models, Pins must be created for signals/call. This is a lot of repetition of the same information in the metamodel, and makes tools tedious to use because of the redundant information. Even if you don't have to type it, the information is there and navigators have to show it. Perhaps this issue could be used as a stimulus to simplify and normalize these aspects of the metamodel? Some possible ideas for simplification: A class implicitly has all the operations of any of its realized interfaces. They do not have to be re-specified in the class. A class can contain a behavior without a specification and that behavior can be shown in the operations compartment of the class (notation change only). The first part is already possible. A classifier can own a behavior that has no specification. It can even invoke this behavior without an operation being specified, but it cannot call this behavior from the outside. The second half (showing this in the operation compartment would be confusing, but we could add a method compartment). Note that this is within what is allowed already, but it is not explicitly stated in the specificaiton. --TW If a Behavior has a specification Operation, then it cannot have any name, parameters, or raised exceptions. These are all provided by the specification Operation. This won't work if you want to deal with dynamic dispatch situations. --TW Find some way to eliminate Activity Parameter Nodes? and just use the Behavior Parameters. I had proposed this during the original work but this was not agreeable to the activity group, but you can try again. --TW -- JimAmsden - 17 May 2005 Revised Test Resolution Deferred -------------------------------------------------------------------------------- RtfIssue1000000003 20 Oct 2005 - 07:55 - r1.9 ThomasWeigert Issue 6423: Section 9.3.4 page 161, Presentation Option Issue summary The statement 'A dashed arrow with a stick arrowhead may be used to show that a collaboration is used in a classifier, optionally labelled with the keyword «represents».' and the accompanying example are confusing. Please clarify what this presentation option is trying to accomplish. Discussion A search for practical applications of this presentation option has not revealed any examples. It is, therefore, proposed to delete this presentation option. -- ThomasWeigert - 18 May 2005 The issue is asking for a clarification and is not asking to remove the feature. If this is removed, there should be another way of depicting the Classifier::representation relationship (see figure 100). So, the resolution should provide an alternative to replace this notation and not just remove it. Alternatively, there should be an extended explanation of what this meta-association means. -- BranSelic - 19 May 2005 It is just that I have never seen any application of this. I did not feel I should remove this feature when we did UML 2.0 as at this time we did not have any evidence one way or the other. However, now I have searched for applications and am still coming up short. So in the spirit of making the language more manageable, removal of unused features that are in addition source of problems may be the best route? -- ThomasWeigert - 20 May 2005 If we can remove features we can add them. Which is fine with me in minor cases. -- ConradBock - 25 May 2005 I agree with Bran that this issue asks for clarification. Iit may be that no one is using it because no one understands it. -- ConradBock - 21 Jul 2005 I am not the right person to clarify this feature as I am not sure about it. I tried to reverse engineer the current description based on the UML1.x spec. Any takers? -- ThomasWeigert - 28 Jul 2005 Before deciding whether it is useful, it would be helpful to fix the paragraph above the figure. It mentions two stereotypes (represents and occurrence) and defines the second in terms of the first, with a figure that is only about the first. Is "occurrence" supposed to be "represents"? Judging from the description, it seems like a kind of usage dependency. -- ConradBock - 07 Aug 2005 Revised Test In Section 9.3.4., delete subsection .Presentation Option.. Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000004 19 May 2005 - 09:06 - NEW ThomasWeigert Issue 6433: 03-04-01 Chap 2 p. 112/Components: Different ways to wire components Issue summary Re Chapter 2, Components Figure 2-15, p. 112: The text of the fifth paragraph says: .A component has a number of provided and required Interfaces, that form the basis for wiring components together, either using Dependencies, or by using Connectors.. Is this really an either or choice? What is the real semantic distinction? And what is the semantic distinction between wiring via connectors without ports vs. wiring via connectors with ports? Recommendation: Clearly specify the semantic distinctions among the three ways of wiring components together: 1) Via Dependencies 2) Via Connectors without Ports 3) Via Connectors with Ports. If there are no semantic distinctions--that is, if the distinctions are purely mechanical--then the specification should probably changed such that there is one way to wire components together. Discussion Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000005 23 May 2005 - 15:11 - r1.2 FaySchafernak Issue 6866: Part subtype Issue summary Would be useful to be able to assign a subtype for objects that fill a part, to add additional characteristics. For example, a person fills the Employee part of a company, and is reclassified under a subtype of person that has an office. It is not sufficient to use the subtype as the type of the part, because the model wouldn't record what objects are allowed to fill the parts. The object is reclassified under the subtype after filling the part. Discussion The issue suggests a new feature of UML. While interesting, such is considered outside the scope of this RTF. Revised Test Resolution Deferred -------------------------------------------------------------------------------- RtfIssue1000000006 19 May 2005 - 09:06 - NEW ThomasWeigert Issue 7246: Figure 78 Issue summary Figure 78 - inconsistencies with Class Descriptions Figure 78 shows an enumeration Connector Kind? which is not defined in this chapter, however (see also Issue #7001). Suggestion: define Connector Kind? in section 8.3 - Class Descriptions. Figure 78 shows an association between Connector and Behavior with association end '+contract'. This association is not defined in Section 8.3.2 - Connector, however. Discussion Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000007 19 May 2005 - 09:07 - NEW ThomasWeigert Issue 7247: Connector - 'provided Port' and 'required Port' not defined Constraint 1 Issue summary Connector - 'provided Port' and 'required Port' not defined Constraint 1, '[1] A delegation connector must only be defined between used Interfaces or Ports of the same kind, e.g. between two provided Ports or between two required Ports.' uses the concepts 'provided Port' and 'required Port'. Neither of them is defined in the spec. Furthermore, a Connector is not expected to be defined between Interfaces, but an Association is. A Connector is defined between Connectable Elements? whose specializations are Property, Port, Parameter, and Variable, but not Interface. I suggest to replace Constraint [1] with '[1] A delegation connector must only be defined between a Connectable Element? (i.e. a Port) of the component and a Connectable Element? (i.e. a Property or a Port) of one of its internal parts.' Discussion Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000008 19 May 2005 - 09:07 - NEW ThomasWeigert Issue 7248: Connector - inconsistencies in Constraint [2] Issue summary Connector - inconsistencies in Constraint [2] Constraint [2] says: '[2] If a delegation connector is defined between a used Interface or Port and an internal Part Classifier, then that Classifier must have an .implements. relationship to the Interface type of that Port.' There are two problems with this constraint: 1. A connector cannot be defined between a used Interface and an internal Part, because Interface is not a Connectable Element?. 2. What is 'the Interface type of that Port' ? The Classifier given by port.type? This Classifier can be but does not have to be an Interface. Or one of the Interfaces given by port.required? Which one? Discussion Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000009 19 May 2005 - 09:07 - NEW ThomasWeigert Issue 7249: Connector - inconsistencies in Constraint[3] Issue summary Connector - inconsistencies in Constraint[3] Constraint [3] says: '[3] If a delegation connector is defined between a source Interface or Port and a target Interface or Port, then the target Interface must support a signature compatible subset of Operations of the source Interface or Port.' There are two problems with this constraint: 1. An Interface cannot be the source or the target of a connector, because Interface is not a Connectable Element?. 2. If a connector is defined between a source Port and a target Port (which is possible, because Port is a Connectable Element?) - what is the 'target Interface'? One of the Interfaces port.type is implementing? Or one of the Interfaces in port.provided? - what are the Operations of the source Port? The Operations of the Classifier given by port.type? Or the union of all Operations of all Interfaces given by port.required and port.provided? - what does 'signature compatible' mean for Interfaces? Discussion Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000010 19 May 2005 - 09:08 - NEW ThomasWeigert Issue 7250: Connector - inconsistencies in Constraint[4] Issue summary Connector - inconsistencies in Constraint[4] Constraint [4] says: '[4] In a complete model, if a source Port has delegation connectors to a set of delegated target Ports, then the union of the Interfaces of these target Ports must be signature compatible with the Interface that types the source Port.' There are two problems with this constraint: 1. What is 'the union of the Interfaces of these target Ports'? First, it is not clear, what a 'union of interfaces' is. A 'union of a set of interfaces' could be an anonymous Interface which specializes all the interfaces in the set of interfaces, but this should be made clear, because 'union of interfaces' is not defined somewhere else in the spec. Second, it is not clear what the Interfaces of a target Ports are. All Interfaces provided by the Classifier port.type including the Classifier port.type itself, if port.type is an Interface? Union the Interfaces in port.provided? Do we have to include the Interfaces in port.required as well? 2. What does 'signature compatible' mean? Discussion Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000011 19 May 2005 - 09:08 - NEW ThomasWeigert Issue 7251: Connector - inconsistencies in Constraint[5] Issue summary Connector - inconsistencies in Constraint[5] Constraint [5] says: '[5] An assembly connector must only be defined from a required Interface or Ports to a provided Interface or Port.' There are two problems with this constraint: 1. A connector cannot be defined from or to an Interface, because Interface is not a Connectable Element?. 2. It is not clear what a 'required Port' or a 'provided Port' is. Discussion Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000012 08 Jun 2005 - 14:58 - r1.2 OysteinHaugen Issue 7303: simple time model in Common Behavior? Issue summary For the 'simple time model' in Common Behavior?, it is unclear when the Duration Observation Action? and Time Observation Action? would be executed. For one, it is not stated when these actions are executed. I assume that when the execution of the model reaches the point of the attached model elements, then these actions are executed. Several problems: (i) It is unclear what determines when these actions are executed. If the actions are embedded in a sequence of actions, where control flow indicates when they execute, what is the meaning of the association to a named element? If that named element is reached later in the execution, does the execution wait? If it is reached earlier, does that element have to wait until the action sequence is enabled? (ii) There should be some constraint on the 'NamedElements' associated with Time Expression? that limits those to elements that can be enountered during execution, as these elements appear to determine when these actions are evaluated. There is a tension between these actions being embedded in a sequence of actions where their execution is determined by the control and data flow, and the associated 'NamedElements' that would determine the observation of time also. Normally, actions are used within a sequence of actions (an activity). These two actions are different in that they seem to make no sense within an activity due to that they have very special invocation points. They seem to only make sense as stand-alone elements. Maybe it should not be an action, but some other model element, that should dictate how time and duration are observed. Discussion -- OysteinHaugen - 08 Jun 2005 The description of the problem is adequate. However, the time and duration observation actions are not intended to be executed because they appear explicitly. They were intended to be executed as a result of the associated events having taken place. The associated event of a time observation may be such as 'the first event of a behavior' (where the behavior is the named element), or 'the reception of a message' (where the Occurrence Specification is the Named Element?). For a duration observation the action is to be implicitly executed when the last of the two boundary events have occurred. A duration may be 'from the start of an action to its termination' (where the Action is the Named Element). I agree that this use of the very imperative Action concept may not be the most adequate. The simple time model is basically in the realm of declarative specifications, but the intention is to let the constraints talk about concrete observations of time and durations in the sequence of events having occurred. As the Issue Source (Motorola) points out, there may be more apropriate to investigate whether these observations should be modeled by something different than Actions. The observations are actions on another level than the system execution, they are executions of some virtual or imaginary observation system (comparable to test context) that should not interfere with the execution of the model system at all. Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000013 12 Jul 2005 - 17:48 - r1.4 ThomasWeigert Issue 7304: Notation sections for Time Observation? and Duration Observation? Issue summary The Notation sections for Time Observation? and Duration Observation? seem inadequate: 1. The syntax for Time Observation? only allows 'now' as a Time Expression?, but indicates in the previous sentence that more complex expressions are possible. 2. The syntax for Duration Observation? includes the unexplained non-terminal symbol 'duration'. 3. In the example, figure 321, there are no associations to named elements shown. I assume that these refer to the begin and end of the arrow, but that is not indicated. Discussion The Notation sections are not entirely adequate. The sentences referring to use of arithmetic operators are confusing and should be either removed or moved to the description of Time Expression? or Duration. May I suggest the following rewrite of the Notation paragraphs: Notation (Time Observation Action?) The notation for a Time Observation Action? is a text associated with a Named Element? normally by a small line. Pure proximity to the Named Element? may also suffice. The text is of the form: ::= '= now'. Notation (Duration Observation Action?) The notation for a Duration Observation Action? is a text associated with one or two Named Elements? by either proximity or one or two small lines. The text is of the form: ::= '= duration'. I believe the explanation for Figure 321 is correct, but it may not be obvious that the Named Element? in question is the Message to which the duration observation text is close. The meaning of the example is fairly straight forward explained in the text, I believe. -- OysteinHaugen - 08 Jun 2005 Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000014 19 May 2005 - 10:11 - r1.2 ThomasWeigert Issue 7364: section on connectors in the component chapter Issue summary The section on connectors in the component chapter does not add any new functionality to the connectors defined in internal structure. It does provide an additional notation for assembly connectors. There is no reason to have this section in components. Everything that is said semantically about connectors here applies equally to the more general connector. Suggestion: Do not subtype connector in component but move the content of this section to the connector section in internal structure and merge with the section there. Adjust the examples to apply to structured classifiers in general (i.e., delete the component symbol). Further, the Connector Kind? should be derived as it is determined by the manner in which the connector is attached to connectable elements. Deriving this connector ensures that constraints are always true and allows to do away with some consistency constraints. (Actually, it is not clear what the value of this attribute is, as it is already determined from the attachments.) Alternatively, if the presentation option is not in general desired (albeit I cannot see why this additional consistency would not be wanted), the text can be moved up but the presentation option can be added in this section. Discussion Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000015 23 May 2005 - 15:16 - r1.2 FaySchafernak Issue 7398: Provide exception handling for all behaviors. Issue summary UML2 has added the capability of dealing with exceptional behavior. Exception handling can occur at various levels of the model. Unfortunately, the exception handling mechanism has not been systematically developed. Any kind of behavior should support the mechanism of catching and handling an exception that was raised somewhere within that behavior. Unfortunately, currently only activities allow for this. Similar capabilities should be available for interactions and statemachines, and even for use cases. Recommendation: Provide exception handling for all behaviors. Discussion This issue, while important, requires further study. Revised Test Resolution Deferred -------------------------------------------------------------------------------- RtfIssue1000000016 12 Jul 2005 - 17:47 - r1.3 ThomasWeigert Issue 7406: TimeObservationAction and DurationObservationAction Issue summary Time Observation Action? and Duration Observation Action? are described as actions, but are not really actions like the actions of the action chapter. They would never be used when defining a behavior, but are part of a metalanguage to define temporal constraints and to refer to measured times and durations in formulating such constraints. However, these two elements are the only aspects of this language, everything else is left to be defined later (see Time Expression?). Putting these two mechanisms into the specifications unduly constrains any profile that would want to define a notation for expressing temporal constraints. Such a language might not see a need to use the actions described in this chapter. My recommendation is to find a different way of expressing time observations and duration observations in the metamodel. The syntax examples clearly show that they are not meant to be used within an activity as actions. Note that the only way to use these observations is to create a 'fake' activity attached to the interaction (e.g., as a nestedClassifier) which contains only this action. A rather convoluted and heavy-weight means of expressing the simple concept of 'NOW' (as the point in time when some model element is executed). A simpler mechanism is clearly needed. Discussion This issue seems to coincide with Issue 7303 from the same source. At least my discussion note on Issue 7303 is applicable here. In short I agree with the observations and welcome a simple improvement that still achieves the purpose, namely to let time constraints and duration constraints refer to observations of observed time points and durations of the current execution. One possible solution to this is simply to drop the specialization from Action and recognize that Time Observation? and Duration Observation? are concepts of their own representing the naming of timestamps and "duration-stamps". The metamodel could remain fairly much the same as before. -- OysteinHaugen - 08 Jun 2005 Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000017 24 May 2005 - 00:25 - r1.2 ThomasWeigert Issue 7948: section 2.10.4.1 detailed semantics of collaborations Issue summary My question concerns section 2.10.4.1 (detailed semantics of collaborations). The last part of the 4th paragraph starts as follows: 'However, instances of different classifiers can play the role defined by the classifier role, as long as they have all the required properties.' Allow me to illustrate my interpretation of this section by means of an example. Suppose there is a class A with 5 operations, o1, o2, o3, o4 and o5, and there is a class B with 3 operations, identical to o2, o3 and o4. Suppose there is a classifier role R in a collaboration, which has A as its base. The role can then specify a subset of the features of A. These features are then required by instances which play the role. Suppose this subset consists of o2 and o3. Then the quote from the spec above claims that instances of B are allowed to play role R. Is this correct so far? Then, the spec goes on: 'Several classifier roles may have the same base classifier, even in the same collaboration, but their features and contained elements may be different subsets of the features and contained elements of the classifier. These classifier roles specify different roles played by (possibly different) instances of the same classifier.' So, considering again role R from my example, suppose there is now a different classifier role Q, which also has A as its base. Suppose Q specifies o3 and o4 as the required subset of A's features. Now the last sentence from the spec quote seems to say that only (possibly different) instances of A can play roles R and Q. This would mean that an instance of B is NOT allowed to play either R or Q, which would contradict my example above. Discussion This issue appears to be against UML 1.x, as the semantics of collaboration does not contain the cited passages and it relies on concepts that have been removed in UML 2.0. Collaborations have been clarified significantly in UML 2.0; the author of this issue is invited to check whether his concern still exists. Revised Test Resolution Closed no change -------------------------------------------------------------------------------- RtfIssue1000000018 21 Jul 2005 - 17:53 - r1.6 ConradBock Issue 7967: An observed time value must be written into a structural feature Issue summary Time Observation Action? is a specialized Write Structural Feature Action?. An observed time value must be written into a structural feature. If modeling activities with that kind of action it would be useful to be able to write the time value to a variable instead of a structural feature. The time value is often used temporarily Discussion The issue is understandable. However, I believe that we will modify the simple time model (due to other issues) such that the TimeObservation and DurationObservation will be something different from Actions. There may still be a need to record the current time within the model execution itself, and this can be achieved by letting 'now' be predefined literal of Time Expression? with the obvious interpretation. -- OysteinHaugen - 08 Jun 2005 The scenario is simple: Compare a timestamp stored in a property with the current timestamp (now). To model this it is necessary to store the current timestamp in another property although it is only used temporarily for the comparison. -- TimWeilkiens - 17 Jul 2005 Doesn't help when there is no action to compare data values. If there were one, it could take the result of the the current time action (assuming it had an output pin) and the Read Structural Feature Action? reading the property value. Wouldn't necessarily require the use of the activity model, just Action Input Pin?. -- ConradBock - 21 Jul 2005 Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000019 09 Aug 2005 - 22:42 - r1.15 ThomasWeigert Issue 7973: UML 2 Super / Incorrect statement on port visibility Issue summary The updated UML spec p162 states: 'UML Superstructure 2.0 Draft Adopted Specification A port of a classifier is shown as a small square symbol. The name of the port is placed near the square symbol. If the port symbol is placed overlapping the boundary of the rectangle symbol denoting that classifier this port is exposed (i.e., its visibility is public). If the port is shown inside the rectangle symbol, then the port is hidden and its visibility is as specified (it is protected by default).' This text was supposed to be removed by the FTF -- the placement of the port is independent of its visibility. Port placement is merely a question of graphical convenience. Their visibility is indicated by the usual means as for all other properties (+, -, and #). Discussion The author of this issue contends that the port notation should not define the visibility of ports through the placement of the port symbol. However, this is what the specification has defined; no discussion as to the removal of this notation has taken place, to my recollection. Moreover, this is a convenient notation to express visibility of ports. The author of this issue is invited to demonstrate, through examples, why this notation is not suitable. -- ThomasWeigert - 17 May 2005 I must admitt that I thought this was only applicable for the frame not for all classifier symbols. When e.g. a class symbol is used in the normal fashion, i.e. with compartments for name, attributes and operations it is not easy to put ports inside the symbol. But when reading the current text this seems to be the idea. So I think I would be in favour of making this a recommended style guide instead of an absolute rule. -- AndersEk - 17 May 2005 I happen to recall this discussion well (I think it was either in oslo or Stockholm), but let's not quibble about that. New arguments have come up since that discussion that favour not tying the graphical placement of structural elements of a composite to their visibility. Specifically, in Sys ML? as well as in several other applications in different domains that have come up from some of our users (e.g. in business modeling), there is a need to be able to connect directly to a part that has public visibility; that is, without having to go through an intervening public port. Unless we start putting parts on the border (which clearly does not scale up well and it looks godawful), we really have no choice. While connecting directly to parts (i.e., without going through an intervening public port and a delegation connector) is not possible in either SDL or UML-RT, it seems useful to be able to do that in other cases. After all, parts are properties and, like other properties such as attributes, they should be able to have either public or private visibility. It is a minor but useful (and, more importantly, required) generalization of what is already there. For those domains, such as UML-RT and SDL where this is not allowed, the appropriate profile simply has to define constraints that force all parts to be non-public. So, if we accept the possibility that parts of a composite can be made public and that they can be connected from the outside, then it will not be possible to retain the convention that things inside the border are necessarily private/protected. If this is the case for parts, then the same reasoning should apply to ports. -- BranSelic - 19 May 2005 Bran, it is not clear why the question of whether the placement of ports should carry special semantics is necessarily connected to the question of whether one can connect to parts directly. Your argument seems to be that because we might at some point need to allow direct connection to parts (and that is a big if) we should not have a notation for ports that differentiates between public and private ports. I don't quite see how that follows. -- ThomasWeigert - 04 Jun 2005 Regarding the need of the SysML to connect directly to parts... I have spent much time with the SysML on their need to connect to parts directly. I believe this need is due to a misunderstanding of what internal structure is. For example, equations about abstract relations between system properties are being represented as connectors and parts in SysML while they are best represented as collaborations. If you do the latter, no changes to the UML are required, and in addition, no questions about the instantiation of equiations as objects arise. SysML has insisted on representing items in a manner inconsistent with the UML2, where it would have been very easy to be consistent. I have no sympathy for such. -- ThomasWeigert - 20 May 2005 Couldn't find any technical content in the above, so I'll add a bit more nontechnical content: Thomas, you completely misunderstand what is happening in Sys ML?. Would be glad to discuss sometime. -- ConradBock - 25 May 2005 Conrad, why don't you go into some detail of why the SysML needs to connect directly to parts. As you know, if have provided the relevant chapter to SysML with only leveraging the UML 2 spec and not making any changes. That proposal, I believe accomplished everything they were trying to do without messing around with the UML 2. -- ThomasWeigert - 26 May 2005 Rereading the above, it seems like the issue is whether non-port properties can notated overlapping the border. It would be helpful to allow any property to be shown on the border. As to the semantics of overlapping, I guess people are assuming it means the element is public, but presumably alot of diagrams have fully contained elements that are public. It would be a hassle to put all public properties on the border. This would argue against allowing any property to overlap the border, I guess. Whatever the resolution of the above complications, there are going to be alot of parts that are public and support connectors to them. The only difference between a part and port is the isService / isBehavior forwarding stuff, which are actually the least used aspects among classical systems engineers. They use connectors as contextualized associations, per the RFP requirement that U2P said it supported with composite structure, see http://www.jot.fm/issues/issue_2004_11/column5. Sys ML? also uses connectors to non-part properties, for parametric constraints. -- ConradBock - 03 Jun 2005 Conrad, the issue is not whether there are symbols allowed at the border, as they are. The issue is whether there should be a semantic difference between ports shown on the border and ports shown inside the compartment. -- ThomasWeigert - 04 Jun 2005 As there have been no further discussion of the question as to whether the placement of ports on the border should carry semantics I propose to close this issue. -- ThomasWeigert - 20 Jul 2005 How are ports shown inside the border distinguished visually from other properties? -- ConradBock - 21 Jul 2005 The name of the port and its optional classifier are placed outside of the small rectangle symbol standing for the port, while for parts the name is inside the box. (see p. 190 in the spec) -- ThomasWeigert - 28 Jul 2005 Would be good to highlight that case on page 190. -- ConradBock - 07 Aug 2005 I have attached below a document that explains why I think that position of ports must not be used to indicate visibility. It's not too long (2.5 pages) but it does delve into some rather subtle issues of modeling layers. I am sorry it took me so long to document this. -- BranSelic - 09 Aug 2005 Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000020 26 Oct 2005 - 03:12 - r1.17 ThomasWeigert Issue 8026: Contextualized attribute values Figures 121 Issue summary Contextualized attribute values Figures 121 is an unworkable solution to defining contextualized attribute values. It requires restating all the parts and connectors in the composite class, otherwise the constructor would be incomplete. The class-based solution requires separate properties for each contextualized value with connectors to them from the contextualized property. The metamodel should be extended to include contextualized datatype properties, or at least a presentation option for the current cumbersome model (see Figure 12 and discussion in http://www.jot.fm/issues/issue_2004_11/column5 Discussion Figure 121 shows how to define constructors for (structured) classes graphically by associating an instance of a classifier with the classifier. It is unclear how the issue summary relates to this figure. The author of the issue is invited to clarify his concern in more detail. -- ThomasWeigert - 19 May 2005 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. -- ConradBock - 23 May 2005 Conrad, you are not clarifying but just repeating the summary... -- ThomasWeigert - 24 May 2005 The clarification is what the figure is attempting to do with the constructor. In past discussion, the issue of contextualized data values has been relegated to constructors. This figure shows how to go about it. The issue explains why the technique doesn't work, including the scaling problem Bran noted, and proposes another solution. -- ConradBock - 25 May 2005 It appears to me that the figure is perfectly clear and that the solution works well. Can you explain what you think does not scale and why the solution does not work. Just repeating over and over again it does not work really is not helpful. If you have some discussion elsewhere, please post it here... -- ThomasWeigert - 04 Jun 2005 It doesn't scale because you need to remodel the parts from the composite class as parts in the instance (says this in the issue text). I'd prefer a metamodel solution that provided for contextualized data values, analogous to the contextualized links between objects we currently have. But a more minimal change to have a presentation option on Property (from Internal Structures?) for showing the attributes of the class that types the property, including the default values: Then users can make specialized classes with default, readonly if needed, and see them in the notation (too bad we deferred Issue 6866: Part subtype). -- ConradBock - 21 Jul 2005 Added revised text proposal. -- ConradBock - 21 Aug 2005 Doesn't seem to be any more comment. Can we propose this for draft ballot 10? -- ConradBock - 08 Sep 2005 Conrad, I don't understand your diagram. What do the arrows between the boxes mean? -- BranSelic - 09 Sep 2005 It's just a composite structure diagram (with the proposed presentation option). It supports the association adornments, in this case, navigation arrowheads. The association of the connector is navigable in that direction. -- ConradBock - 23 Sep 2005 This category of association adornments is something new and has not been discussed before. I don't agree with it, since I know from experience that people want to use arrows on connectors for diverse other things (e.g., direction of (dominant) information flow, direction of control, etc.). In my view, the semantics of arrows on connectors should be an SVP in UML to allow for this diversity. Your proposal gives them a navigability connotation, I believe, which is just one special case. Therefore, I would be happier with your resolution if you removed those adornments. -- BranSelic - 23 Sep 2005 OK, I updated the revised text. However, using navigation arrowheads is supported by the spec, see Notation section of Connector End?: Adornments may be shown on the connector end corresponding to adornments on association ends (see .Association (from Kernel). on page 36). It doesn't restrict which association adornments can be shown on the composite structure diagram. - ConradBock - 23 Sep 2005 I don't think this is ready for prime time for two reasons: There are discussions in other groups for a different use of this graphical construct, e.g., in SysML to show nested parts. I think that this is a sensible idea, however. The lines in the diagram are still unclear. Maybe you could show the BuySellDialogClass definition, so that it would be more obvious what you are talking about with those lines. You say they are connectors, but (i) what do the role names mean (I know they are legal, but really have no meaning at all in UML, but you seem to attach semantics to them); (ii) they really appear to be more like associations in your example. -- ThomasWeigert - 20 Oct 2005 This is a proposal for the Presentation Option section, so the underlying model is no different than usual. The only change is in a optional notation in the structure diagram to show the properties of the classes of the parts (properties). The text is: Default values for properties of the type of properties in a composite structure can be shown in the property symbol with the same syntax as properties on a class, for example, as shown in Figure ?." It doesn't indicate any other changes to the notation, so everything else is interpreted as normal, eg, lines between part rectangles are connectors, etc. Perhaps the text could be generalized to refer to all aspects of property notation, rather than focus on default values, and use the terminology of the structured classifier, and explain the diagram better. How about: "Properties of the type of properties of roles in a structure diagram can be shown inside the role symbol with the same syntax as properties on a class, for example, as shown in Figure ?. It shows a structured classifier with parts called name, buySellMenu, and okCancel. The properties of the types of these parts are shown in the rectangles for each part." -- Main.Conrad Bock - 26 Oct 2005 Even a presentation option results in something in the metamodel. Anything having to do with notation has to be given an explanation of what the instantiated metamodel is that results from the drawing. In the spec you will find such sentences usually with the phrasing "xxx represents yyy" where xxx is a symbol and yyy is a model element. I cannot make out what the lines are which you say are connectors. Here is what would help to understand: A class diagram for the involved structured class, BuySellDialogClass and class diagrams for the classes typing the internal parts, TextBox, DropDownMenu, and OKCancelButton. An initializer for the structured class using the standard UML 2 way, or alternatively, a repository model for the instance resulting from instantiating the BuySellDialogClass. I am sorry but I cannot fathom what the ":tabTo" connectors are. I understand how the part initialization works, and I think that is a good idea, providing it does not conflict with the two SysML proposals. In the specification, we would have to show the involved classes anyway, as the diagram is obviously not self-explanatory. -- ThomasWeigert - 26 Oct 2005 Revised Test In Composite Structures, Property, in Presentation Option section, at end add new paragraph and figure: .Default values for properties of the type of properties in a composite structure can be shown in the property symbol with the same syntax as properties on a class, for example, as shown in Figure ?.. Figure ?: Presentation option for default values of property types. Resolution -------------------------------------------------------------------------------- RtfIssue1000000021 09 Aug 2005 - 21:09 - r1.6 ThomasWeigert Issue 8027: Connector multiplicity notation Issue summary Connector multiplicity notation The notation section of Connector End? says multiplicities shown on connector lines represent the multiplicities of both the association and the connector: These adornments specify properties of the association typing the connector. The multiplicity indicates the number of instances that may be connected to each instance of the role on the other end. But these multiplicity can be different, and have separate elements in the metamodel. Discussion The adornments on connector ends either specify properties of the association that types the owning connector (when that association is inferred) or it reflects properties of that association, otherwise. The multiplicity may be more specific than the multiplicity of the association typing the connector. -- ThomasWeigert Perhaps the issue wasn't clearly written. The text says the adornments show the multiplicity of the association, omitting that they can also show the multiplicity of the connector end. Suggested rewording: In 9.3.7., sub-section Notation, replace "These adornments specify properties of the association typing the connector." by "These adornments specify properties of the association typing the connector, if that association was inferred. Otherwise, they show properties of that association, or specializations of these on the connector." BTW, what does it mean to "infer" an association for a connector? -- ConradBock - 17 Jul 2005 How about In cases where there is no explicit association in the model typing the connector, these adornments specify the multiplicities of an implicit association. Otherwise...etc." -Main.BranSelic - 19 Jul 2005 The specification gives an explanation of what it means that an association is inferred: If the type of the connector is omitted, the type is inferred based on the connector, as follows: If the type of a role (i.e, the connectable element attached to a connector end) realizes an interface that has a unique association to another interface which is realized by the type of another role (or an interface compatible to that interface is realized by the type of another role), then that association is the type of the connector between these parts. If the connector realizes a collaboration (that is, a collaboration use maps the connector to a connector in an associated collaboration through role bindings), then the type of the connector is an anonymous association with association ends corresponding to each connector end. The type of each association end is the classifier that realizes the parts connected to the matching connector in the collaboration. Any adornments on the connector ends (either the original connector or the connector in the collaboration) specify adornments of the ends of the inferred association. Otherwise, the type of the connector is an anonymously named association with association ends corresponding to each connector end. The type of each association end is the type of the part that each corresponding connector end is attached to. Any adornments on the connector ends specify adornments of the ends of the inferred association. Any inferred associations are always bidirectionally navigable and are owned by the containing classifier. -- ThomasWeigert - 19 Jul 2005 Revised Test In 9.3.7., sub-section .Constraints. add [4] The multiplicity of the connector end may not be more general than the multiplicity of the association typing the owning connector. In 9.3.7., sub-section .Notation., replace .These adornments specify properties of the association typing the connector.. by .In cases where there is no explicit association in the model typing the connector, these adornments specify the multiplicities of an implicit association. Otherwise, they show properties of that association, or specializations of these on the connector.. Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000022 28 Jul 2005 - 07:59 - r1.15 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 -------------------------------------------------------------------------------- RtfIssue1000000023 26 May 2005 - 00:43 - r1.4 ThomasWeigert Issue 8029: underlined association name Issue summary underlined association name Figures 120 and 121 underline the association names, which doesn't seem consistent with the notation for instances in Figure 21. Discussion The issue is incorrect in that there is no such inconsistency. In fact, the text for Instance Specification?, section 7.3.22, clearly states that the links deriving from associations could be labeled by underlined names (albeit these names may be omitted if no confusion can arise). -- ThomasWeigert Section 7.3.22 actually says: "It is not necessary to show an underlined name where it is clear from its connection to instance specifications that it represents a link and not an association." and uses this convention in Figure 52. It's more consistent and easier to read than the underlining in Figures 120 and 121. -- ConradBock - 25 May 2005 Revised Test Resolution Closed no change -------------------------------------------------------------------------------- RtfIssue1000000024 26 Oct 2005 - 03:07 - r1.26 ThomasWeigert Issue 8031: Destruction semantics in StructuredClassifier Issue summary Destruction semantics in Structured Classifier? The destruction semantics in Structured Classifier? should include destruction of links created due to connectors between noncomposite properties Discussion Removed discussion not pertaining to this issue (see here) I object to removing the pertinent dicussion. Included the jist of it below. If you don't want to address it in composite structure, I'd be glad to take the issue in the Composite WG, as you originally requested. The proposal sets up a semantic dependency of actions on composite structure. It also introduces an ambiguity into the semantics of actions, because the same model will execute differently depending on which semantic variation an implementor uses. -- ConradBock - 03 Jun 2005 Conrad, your discussion pertained to Issue 8032, not to this issue. Also, I requested that you handle the second half of 8032. Your comment above does not apply to this issue either.... -- ThomasWeigert - 04 Jun 2005 See updated revised text in attachment: In Section 9.3.13., subsection .Semantics., add after the first sentence of the paragraph preceding the .Semantic variation point. heading: .All links created based on connectors between roles of the structured classifier as well as links created using link actions are destroyed.. -- ConradBock - 14 Jun 2005 See comments at 8032 (http://www.modeldrivenengineering.org/bin/view/Umlrtf/RtfIssue1000000025), these need to be addressed together. -- ConradBock - 05 Jul 2005 Here's a revised proposal modified from the original to not destroy links that shouldn't be. In Section 9.3.13., subsection .Semantics., add after the first sentence of the paragraph preceding the .Semantic variation point. heading: .All links created based on connectors between roles of the structured classifier are destroyed, including between roles that are non-composite properties.. -- ConradBock - 21 Jun 2005 Aren't "links between roles that are non-composite properties" included in "all links"? Why does this need to be highlighted? -- ThomasWeigert -- 12 Jul 2005 Didn't follow the first question above from Thomas, 12 Jul 2005, except I guess removing "All" doesn't change the meaning. Updated text in Revised Text section below. In Section 9.3.13., subsection .Semantics., add after the first sentence of the paragraph preceding the .Semantic variation point. heading: .Links created that exist only because of connectors between roles of the structured classifier are destroyed, including between roles that are non-composite properties. -- ConradBock - 17 Jul 2005 Conrad, what I was trying to say was that the first part "All links created that exist only because of connectors between roles of the structured classifier are destroyed" already includes the second part "including between roles that are non-composite properties", so why talk about it? -- ThomasWeigert - 19 Jul 2005 Why should links created by link actions not be destroyed when the classifier is destroyed? -- ThomasWeigert - 12 Jul 2005 For reference, the latest text propsed on the RTF list was: In Section 9.3.13., subsection .Semantics., add after the first sentence of the paragraph preceding the .Semantic variation point. heading: .All links created that exist only because of connectors between roles of the structured classifier are destroyed, including between roles that are non-composite properties. There may be many links between the instances playing the roles that were not created due to the connectors of the composite that is being destroyed. They might have been created by other composites not being destroyed, for example, or link actions of unrelated behaviors. These might be destroyed because the instance playing the role is destroyed, but that is a separate matter from the current issue. And of course some of the instances playing roles will not be destroyed, because the role is a noncomposite property. See discussion in atached proposal. For reference, here's the discussion that went with the proposal to the RTF list: The original text proposed for this issue was: In Section 9.3.13., subsection .Semantics., add after the first sentence of the paragraph preceding the .Semantic variation point. heading: .All links created based on connectors between roles of the structured classifier as well as links created using link actions are destroyed.. It would have resulted in destruction of links between objects in non-composite properties that were not created based on connectors. It is not necessary to refer to links created by link actions not based on connectors, since these are destroyed when one of their end objects is destroyed, if desired, see Destroy Object Action?. The text below corrects this and clarifies that the destroyed links include those based on connectors even for roles that are non-composite. The wording excludes those links that may exist because of connectors in other composites that are not being destroyed. -- ConradBock - 17 Jul 2005 Conrad, we cannot rely on a feature in DestroyObjectAction to define the destruction semantics here, as the Actions package might not be included. The semantics here cannot rely on some assumptions of actions. -- ThomasWeigert - 19 Jul 2005 Further, of course the links created by link actions, even if not based on connectors must be destroyed. Any link to an instance is destroyed if that instance is destroyed. Where would that link go to otherwise? We cannot have links into open space... -- ThomasWeigert - 19 Jul 2005 Thomas, > what I was trying to say was that the first part "All links created > that exist only because of connectors between roles of the > structured classifier are destroyed" already includes the second > part "including between roles that are non-composite properties", so > why talk about it? For clarity. > we cannot rely on a feature in DestroyObjectAction to define the > destruction semantics here, as the Actions package might not be > included. The semantics here cannot rely on some assumptions of > actions. Whether links are destroyed with their objects would be for the Classes chapter. Composite structure doesn't need to commit on that. > Further, of course the links created by link actions, even if not > based on connectors must be destroyed. Any link to an instance is > destroyed if that instance is destroyed. Where would that link go to > otherwise? We cannot have links into open space... The instances "in" a composite structure are only destroyed with the composite if the instances are referred to by a strong composite property. The other instances, refered to by shared or nonaggregate properties, are not destroyed. If there are links between these noncomposed instances created by link actions, those links should not be destroyed when the composite. -- ConradBock - 21 Jul 2005 Of course, but you still need to destroy all the links to and from instances that are owned by composition. Your suggestion below does not cover this. -- ThomasWeigert - 28 Jul 2005 Yes it does (when those links exist only because of the connectors). The "including" clause just clarifies one kind of link that will be destroyed, it doesn't exclude the linke between owned objects. -- ConradBock - 07 Aug 2005 But it does not matter why those links exist. When the object goes away, the links to it must go away, not matter how they were created... -- ThomasWeigert - 09 Aug 2005 Not the links between objects playing noncomposite roles, when the links are also due to connectors in a second composite object that is not being destroyed. Here's the decision tree on whether to delete a link when a composite object is destroyed: Is the link due to a connector owned by the class of the composite object being destroyed? No: Do not destroy it. Yes: Is the link due to a connector of another composite not being destroyed? Yes: Do not destroy it. The link is still justified by the other composite. No: Is the link between noncomposite properties? Doesn't matter, destroy it regardless of the ownership of the roles it links. Note: Separately from the above, the link will be destroyed if necessary when one of the end objects is destroyed. Will add similar tree and proposed text corrections to 8032. Slight edit to proposed text below (removed "created" since it is redudant with "that exist"). -- ConradBock - 12 Aug 2005 -- ConradBock - 21 Aug 2005, updated for Thomas' comment of 19 Aug 2005 In the above algorithm, does connector of the composite object mean a connector owned by the composite class typing the object being destroyed? Or does it refer to connectors to the role that this object plays? -- ThomasWeigert - 19 Aug 2005 The first, connector of the composite object = the connector owned by the composite class typing the object being destroyed. Updated the decision tree in 12 Aug 2005. Checked the revised text in the context of the spec and it looks like this will be clear. In revised text, moved "are destroyed" earlier in the sentence, and removed the "including" clause, since that was confusing before. -- ConradBock - 21 Aug 2005 See my discussion on issue 8032. This type of automated link maintenance is only acceptable in the spec if it is listed as a semantic variation point -- BranSelic - 21 Aug 2005 Similarly to 8032, changed to "may". -- ConradBock - 27 Aug 2005 Doesn't seem to be any more comment. Can we propose this for draft ballot 10? -- ConradBock - 08 Sep 2005 Please see my 09 Sep. comment on issue 8032. -- BranSelic - 09 Sep 2005 Update to revised text, per those comments to: In Section 9.3.13., subsection .Semantic Variation Point. add new paragraph at the end .When an instance of a structured classifier is destroyed, all links may be destroyed that exist only because of connectors between roles of the structured classifier.. -- ConradBock - 23 Sep 2005 Marking this issue as closed, as the proposed text is already essentially contained in the specification, in the section on connectors, please see p.171 of the current spec, Semantics of connector: "All links are destroyed when the containing classifier instance is destroyed." Note that the all links here refers to links due to connectors. So this is precisely what the proposed revised text is saying, ignoring that this is now proposed as a semantic variation. This would make the text inconsistent, as in the connector section this is not a semantic variation. -- ThomasWeigert - 20 Oct 2005 After further discussions with Conrad, proposing enhancements to the text on p.171 along the lines suggested by Conrad: In section 9.3.6. "Connector", subsection "Semantics", replace the last sentence of the 2nd paragraph by: "All such links corresponding to connectors are destroyed, when the containing classifier instance is destroyed." This reflects Conrad's phrasing "all links that exist only because of connectors between roles of the structured classifier". However, I use "corresponding to connectors" to match the sentence before, where we talk about the creation of links corresponding to connectors. The connectors being destroyed are precisely those connectors that we speak about in the previous sentence. I think this is clearer. -- ThomasWeigert - 26 Oct 2005 Revised Text In section 9.3.6. "Connector", subsection "Semantics", replace the last sentence of the 2nd paragraph by: "All such links corresponding to connectors are destroyed, when the containing classifier instance is destroyed." Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000025 20 Oct 2005 - 07:27 - r1.21 ThomasWeigert Issue 8032: Link maintenance in Structured Classifier? Issue summary Link maintenance in Structured Classifier? The semantics of Structured Classifier? should indicate that links are created/destroyed according to connectors when objects are added/removed from the connected properties. Extend Create/Destroy/ClearLinkAction and Add/Remove/ClearStructuralFeature with boolean properties that 'turn on' this semantics. Discussion This issue has two components: Link maintenance semantics for StructuredClassifier Support link maintenance in actions Only the latter will be dealt with in this issue resolution. -- ThomasWeigert - 26 May 2005 See attached document. Proposal written in a more minimalist way than I would have liked, but hopefully more acceptable to Thomas. Resolution: Revised Text: In Section 9.3.13., subsection .Semantics.: In first paragraph, before .or a later time., add .or in the case of links, when an object begins playing a role,.. after the paragraph preceding the .Semantic variation point. heading, add: .Links created based on connectors between roles of the structured classifier are destroyed when one or both of their end objects no longer play the roles on the ends of the connectors, including roles that are non-composite properties.. -- ConradBock - 21 Jun 2005 What does it mean to "no longer play a role". This does not appear to be a defined term in the specification. -- ThomasWeigert - 12 Jul 2005 It means "no longer a value of the role". Perhaps role should be replaced with "property"? See updated revised text below: In Section 9.3.13., subsection .Semantics.: In first paragraph, before .or a later time., add .or in the case of links, when an object is added as the value of a role,.. after the paragraph preceding the .Semantic variation point. heading, add: .Links created based on connectors between roles of the structured classifier are destroyed when one or both of their end objects are removed from the ends of the connectors, including roles that are non-composite properties.. -- ConradBock - 17 Jul 2005 As all discussion here duplicates 8031 and part (2) of this issue is not being addressed, closing this as a duplicate. -- Thomas Here's the difference: This (8032) is about created/destroying links when objects are added/removed from the values of properties. No destruction of objects. 8031 is about destroying links (the right ones!) when the composite is destroyed. Here's the proposal: In Section 9.3.13., subsection .Semantics., in first paragraph, before .or a later time., add .or in the case of links, when an object is added as the value of a role,.. -- ConradBock - 21 Jul 2005 Maybe it is better to just drop the phrase after the first parenthesis, i.e., replace The multiplicities on the structural features and connector ends indicate the number of instances (objects and links) that may be created within an instance of the containing classifier, either when the instance of the containing classifier is created, or at a later time. by The multiplicities on the structural features and connector ends indicate the number of instances (objects and links) that may be created within an instance of the containing classifier. Why do we need to enumerate the occasions on which links or instances might be created? -- ThomasWeigert - 28 Jul 2005 Because it's important semantics. Your suggested change above is about the objects, not the links. This issue (and 8031) are about link creation/destruction, as I explained in the 21st. See that entry for my proposal. Is there something that should be changed in it? -- ConradBock - 07 Aug 2005 Here's the decision tree on whether to add a link when an object is added as the value of (begins to play a) role: Are there any connectors to the role being modifed? No: Do not add any links. Yes: Are there objects as values of roles on other ends of the connectors to the roles being modified? No: Do not add links. Yes: Add links between the added objects and the ones that are values of roles on the other ends of the connectors to the role being modified. A decision tree on whether destroy a link when an object is removed as the value of (stops playing a) role: Is the link due to a connector of the composite object? No: Do not destroy it. Yes: Is the link due to a connector of another composite not being modified? Yes: Do not destroy it. The link is still justified by the other composite. No: Destroy it. Edit to proposed text of July 21 below to align with wording of 8031 proposal, and other clarification. Also removed clause about "including roles that are non-composite properties" since it doesn't apply to this case. -- ConradBock - 12 Aug 2005 So to just be clear, you are concerned in this issues with situations where an object is not destroyed but removed as the value of a property in a composite structure ("stops playing a role"), and similar for the adding case? -- ThomasWeigert - 19 Aug 2005 Right. -- ConradBock - 21 Aug 2005 As some of you may know, UML-RT, as implemented in our tools, actually supports the kind of automatic link maintenance semantics that are described above. However, I really do not feel that it is appropriate to force those semantics in the UML 2 spec, because this will mean that the structured classifier semantics will not be applicable to a large category of systems out there (e.g., systems in which link maintenance is something that is explicitly handled by the application code). So, I cannot condone any automated link maintenance semantics in the text unless it is formulated as a semantic variation point. -- BranSelic - 21 Aug 2005 See update to revised text. The first paragraph already says "may" from the FTF spec, so changed the second to say that also. -- ConradBock - 27 Aug 2005 Doesn't seem to be any more comment. Can we propose this for draft ballot 10? -- ConradBock - 08 Sep 2005 Sorry for going silent. I do not like the fact that this is before the semantic variation point. The whole construction/destruction semantics should be one variant under the SVP heading. -- BranSelic - 09 Sep 2005 OK, but some of the variation points are in the semantics section using the word "may", so I thought it would be more consistent. See update to revised text. -- ConradBock - 23 Sep 2005 I suggest to make this standard semantics as link destruction when a composite object is destroyed is already part of the standard semantics (see p.171, semantics of connector) it makes no sense to leave the link behind if the object is not in the structure any longer. The link would go to nowhere. Changed the revised text accordingly. -- ThomasWeigert - 20 Oct 2005 Revised Text In Section 9.3.13., subsection .Semantics., first paragraph, before .or a later time., add .or in the case of links, when an object is added as the value of a role,.. In Section 9.3.13., subsection .Semantics", at end, add new paragraph: .When an instance is removed from a role of a composite object, links that exist due to connectors between that role and others are destroyed.. Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000026 23 May 2005 - 15:21 - r1.2 FaySchafernak Issue 8033: Figure 119 missing multiplicity Issue summary Figure 119 missing multiplicity. Figure 119 (Connectors and parts in a structure diagram) is missing a multiplicity on the right side of the connetor Discussion The multiplicity on the right end of the connector has been purposefully elided, as defined in section 9.3.7 (Connector End?). Revised Test To make this clearer, insert the following parenthetical remark after .and two instances of the right wheel.: (as no multiplicity is specified for the connector end at the right wheel, the multiplicity is taken from the attached role) Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000028 23 May 2005 - 15:22 - r1.2 FaySchafernak Issue 8035: Notation for method Issue summary Need a notation for instances of the specification/method metaassociation (Figure 311). Discussion Duplicate of issue 6150 Revised Test Resolution Duplicate -------------------------------------------------------------------------------- RtfIssue1000000029 23 May 2005 - 15:24 - r1.3 FaySchafernak Issue 8103: Section: 8.3.1 Issue summary Add ending guillemets to specification in isIndirectlyInstantiated. Verify that OCL for /provided:Interface[*] is correct. 3rd and 4th lines don't look right to me Discussion -- BranSelic - 19 May 2005 Line 3 of the OCL constraint should say "RealizedInterfaces(self)" instead of "RealizeInterfaces(self)". Revised Test Insert ending guillemets after specification. Replace the term "RealizeInterfaces(self)" in line 3 of the OCL derivation expression for Component::provided on page 151 by the term "RealizedInterfaces(self)" Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000030 23 May 2005 - 15:25 - r1.2 FaySchafernak Issue 8104: Section: 8.3.1 - typo Issue summary Typo - Change 'Components' to Component in ownedMember:PackageableElement[*] 1st sentence Discussion Revised Test Change "Components" to Component in ownedMember:PackageableElement[*] 1st sentence. Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000031 12 Jul 2005 - 20:07 - r1.3 ThomasWeigert Issue 8105: Section: 8.3.1 Issue summary Add component icon to fig. 90 <> :ShoppingCart to be consistent with others in diagram Discussion Revised Test Add component icon to fig. 90, :ShoppingCart to be consistent with others in diagram Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000032 26 May 2005 - 02:37 - r1.2 ThomasWeigert Issue 8106: Section: 8.3.2 Issue summary Constraints have no OCL syntax or mention that constraints are not definable in OCL. Type in constraint [5] - delete 's' from first 'Ports'. Discussion Revised Test In constraint [5] - delete "s" from first "Ports". Resolution -------------------------------------------------------------------------------- RtfIssue1000000033 23 May 2005 - 15:27 - r1.2 FaySchafernak Issue 8108: Section: 9.3.1 Issue summary Page references are incorrect for 'Property' and 'StructuredClassifier'. Discussion Revised Test Update page references to latest status. Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000034 23 May 2005 - 15:28 - r1.2 FaySchafernak Issue 8109: Section: 9.3.2 Issue summary Better choice of word in Changes from UML 1.x would be to change the 'of' in last sentence to 'that.' Discussion Revised Test Change the last sentence in Changes. to .Together with the newly introduced internal structure concept replaces Collaboration.representedClassifier. Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000035 23 May 2005 - 15:37 - r1.2 FaySchafernak Issue 8110: Section: 9.3.3 Issue summary Incorrect page number for reference for 'Property' under Description Discussion Revised Test Update page number for reference for "Property" under Description Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000036 27 Jul 2005 - 20:08 - r1.2 BranSelic Issue 8111: Section: 9.3.4 Issue summary OCL notation is missing from Constraints. Please add or add note that OCL notation is not able to express constraints Discussion Revised Text Resolution -------------------------------------------------------------------------------- RtfIssue1000000037 23 May 2005 - 15:50 - r1.2 FaySchafernak Issue 8112: Section: 9.3.5 Issue summary Add Generalization Typed Element? (from Kernal) to fig. 96. Discussion The issue assumes incorrectly that a Connector End? is a typed element. This is not the case. Revised Test Resolution Closed no change -------------------------------------------------------------------------------- RtfIssue1000000038 26 May 2005 - 02:38 - r1.2 ThomasWeigert Issue 8113: Section: 9.3.6 Issue summary Need OCL notation for Constraints. Correct page reference number for Structured Classifier? Discussion Revised Test Correct the page reference number for Structured Classifier?. Resolution -------------------------------------------------------------------------------- RtfIssue1000000039 19 May 2005 - 03:05 - NEW ThomasWeigert Issue 8114: Section: 9.3.7 Issue summary Correct multiplicity of role:ConnectableElement[1] so that fig. 96 agrees with that defined in Associations. Add OCL notation for Constraints. Ports under Notation also reads to me like it could be expressed in OCL notation somewhere--like a constraint which would need to be added. Discussion Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000040 23 May 2005 - 15:51 - r1.2 FaySchafernak Issue 8115: Section: 9.3.9 Issue summary Add generalization for Invocation Action? to fig 101 to agree with text on 187 Discussion As a general rule, we do not show generalizations that are merge increments explicitly in the abstract syntax. Revised Test Resolution Closed no change -------------------------------------------------------------------------------- RtfIssue1000000041 07 Aug 2005 - 17:50 - r1.6 ConradBock Issue 8116: Section: 9.3.9 Issue summary Add OCL notation to Constraints. Notation says to see 'CallOperationAction' for an example, but no examples are given in that section Discussion I don't know how to find out the receiver object of the invocation action. It could be for example a Broad Cast Signal Action? that has no defined receiver objects since it is a semantic variation point. -- TimWeilkiens 30 May 2005 I'll propose to not provide an OCL constraint. I'm not sure if we should handle the Broad Cast Signal Action? problem described above. Do we need to update the constraint? -- TimWeilkiens 21 July 2005 I don't think Broadcast Signal Action? is a problem. If a port is specified, all the objects need to have the port. Not a common case, but not ill-formed either. -- ConradBock - 07 Aug 2005 Revised Test In notation, delete the parenthetical remark starting with .(for example... Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000042 19 Jul 2005 - 22:31 - r1.10 ThomasWeigert Issue 8117: Section: 9.3.10 Issue summary I can't find appropriate figure for the generalization 'Parameter (from Kernel, Association Classes?)'. Add appropriate OCL notation to Constraints Discussion It is unclear what the issue is pointing to. Parameter is appropriately specialized from Parameter in Kernel. The resolution will focus on the OCL only. -- ThomasWeigert - 18 May 2005 As far as I can see the Parameter (Collaboration) can't navigate to it's context. The associations from Connectable Element? to the context (Structured Classifier? or Collaboration) isn't navigable. Therefore it's not possible for the Parameter class to evaluate the constraint. -- TimWeilkiens - 20 May 2005 Tim, navigability is not meaningful in OCL 2.0, which means that your OCL expression can navigate against the arrow. -- BranSelic - 20 May 2005 Bran, in that case the OCL constraint is easy. However it sounds strange to me. How can the parameter (the context of the constraint) evaluate the expression? Could you give me the appropriate chapter reference in OCL specification? -- TimWeilkiens - 30 May 2005 The revised text below refers to section 9.3.20 but there is no section with that number. -- ConradBock - 17 Jul 2005 Corrected to 9.3.10 -- ThomasWeigert - 19 Jul 2005 Revised Test In constraints section of 9.3.10: Add OCL to constraint: [1] A parameter may only be associated with a connector end within the context of a collaboration. self.end.notEmpty() implies self.collaboration.notEmpty() Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000043 19 May 2005 - 09:09 - NEW ThomasWeigert Issue 8118: Section: 8.3.2 Issue summary Reword/rewrite the last two paragraphs of Semantics. Many grammatical mistakes between sentence subject and verb plurality (because of intervening phrases), hard to understand sentences, and an incomplete sentence (last one). Discussion Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000044 19 May 2005 - 09:09 - NEW ThomasWeigert Issue 8119: Section: 8.3.2 Issue summary 'In a system context where there are multople components that provide or require a particular interface, a notation abstraction can be used that combines by joining the multiple connectors.' Combines what? Client keyword missing from fig. 93. Discussion Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000045 23 May 2005 - 15:52 - r1.2 FaySchafernak Issue 8120: Section: 8.3.4 Issue summary Correct statement under Constraints to read 'No additional constraints.' Discussion Revised Test Change line following the .Constraints. heading to .No additional constraints.. Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000046 19 May 2005 - 03:06 - NEW ThomasWeigert Issue 8126: Section: 9.3.11 Issue summary According to fig. 97, Associations need multiplicities added to all and derived symbol to required:Interface and provided:Interface. Add OCL notation to Constraints Discussion Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000047 23 May 2005 - 15:53 - r1.2 FaySchafernak Issue 8127: Section: 9.3.12 Issue summary In Examples, the reference page number to Sturctured Classifier? is incorrect Discussion Revised Test In Examples, correct the reference page number to Sturctured Classifier? Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000048 09 Aug 2005 - 22:18 - r1.3 ThomasWeigert Issue 8128: Section: 9.3.13 Issue summary Associations need derived symbol added to role:ConnectableElement and /part:Property (as shown in fig. 95), a statement that role is derived, and multiplicities added to all associations (as shown in fig. 95). Discussion Agreed. These are all editorial fixes. It is not necessary to include an explicit derivation statement, since it is implied by the Subsets description. -- BranSelic - 27 Jul 2005 Revised Test On page 195 in the Associations subsection of Structured Classifier?, add a ./. in front of the .role:ConnectableElement. item to indicate that .role. is derived. Also, add an explicit multiplicity of [0..*] (i.e., .role:ConnectableElement [0..*].) On page 195 in the Associations subsection of Structured Classifier?, add a ./. in front of the .part:Property. item to indicate that .part. is derived. Also, add an explicit multiplicity of [0..*] (i.e., .part:Property [0..*].) On page 195 in the Associations subsection of Structured Classifier?, add an explicit multiplicity of [0..*] to .ownedAttribute:Property. (i.e., .ownedAttribute:Property [0..*].) On page 195 in the Associations subsection of Structured Classifier?, add an explicit multiplicity of [0..*] to .ownedConnector:Connector. (i.e., .ownedConnector:Connector [0..*].) Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000049 23 May 2005 - 15:54 - r1.2 FaySchafernak Issue 8129: Section: 12.3.13 Issue summary Under Notation change 'name of the part' to rolename to differentiate it from the name of the part (as in composition). Discussion Revised Test In section 9.3.13, under Notation, change the last paragraph to: .The name of the instance specification may be followed by the name of the role which the instance plays. The rolename may only be present if the instance plays a role.. Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000050 23 May 2005 - 15:56 - r1.2 FaySchafernak Issue 8130: Section: 12.3.13 Issue summary Fig 121 uses the word 'make' for the constructor. Unfortunately, this word could be misconstrued to be a noun and refer to the make of the car (Volvo, Audie, Ford) instead of the verb it is intend to be. Suggest changing 'make' to 'assemble.' Discussion Revised Test In figure 121 in section 9.3.13, change make(brand: String) to createCar(brand: String). Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000051 12 Jul 2005 - 20:08 - r1.3 ThomasWeigert Issue 8131: Section: 9.2 Issue summary There is no explanation in the chapter or the section on Strucutred Activities? as to why two Structured Activities? packages are drawn, both in fig. 94. Please clarify somewhere Discussion The issue misses that this section extends Structured Activities? (see Figure 102). Revised Test Resolution Closed no change -------------------------------------------------------------------------------- RtfIssue1000000052 19 May 2005 - 10:10 - NEW ThomasWeigert Issue 8168: Figure 89 on page 158 is incorrect Issue summary ptc/04-10-02: Figure 89 on page 158 is incorrect: the delegation connector on the left seems to be pointing the wrong way. More generally, it is not clear why an arrow is required on delegation connectors, since they are automatically implied when a port is connected to a part or a port on a part. The arrow can be misleading since some may interpret incorrectly it as a restriction on the direction of data flow. Note that the table 5 on page 166 does not show the arrow notation nor does table 7. Finally, the title of table 5 should say: 'graphic paths' instead of 'graphic nodes' Discussion Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000053 23 May 2005 - 15:59 - r1.5 FaySchafernak Issue 8292: Section: 13.1 Issue summary Figures 307 and 308 are identical. Fig. 308 does not show what the text is describing as the Communication Domain Model(especially the paragraph on pg 457 starting with 'As shown in Figure 308...'). Fig. 307 (and current 308) multiplicity for the association execution:BehaviorExecution is diagrammed as * but I wonder if it shouldn't be 0..* since the text indicates that an object may or may not cause the execution of a behavior. In the paragraph immediately following fig. 309, I believe that 'The execution of a send action results in a send request, which results in a signal event occurrence (not a call event occurrence as stated). Minor editing call - In the first line on page 457, change synchronously and asynchronously to synchronous and asynchronous. Discussion Apparently, an incorrect figure has crept in for Fig.308, as the issue points out. Regarding the comment on .*., this means the same as .0..*.. -- ThomasWeigert - 19 May 2005 Reverse the resolution by substituting "0..*" everywhere where "*" appears. Use a different figure than the one in the revised text as per Fig.308.doc -- BranSelic - 20 May 2005 Do we need to adjust the text below the figure to match the terminology of the diagram? I'll review this tonight... -- ThomasWeigert - 23 May 2005 Revised Test In the first line on page 457, change synchronously and asynchronously to synchronous and asynchronous, respectively. In the paragraph immediately following Figure 309, change .The execution of a send action results in a send request, which results in a call event occurrence when it is recognized by the target object.. to "The execution of a send action results in a send request, which results in a signal event occurrence when it is recognized by the target object.. Change the use of .invocation event occurrence.. to .invocation occurrence.. Change Figure 308 for the figure below. http://www.modeldrivenengineering.org/pub/Umlrtf/RtfIssue1000000053/Fig.308.doc Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000054 26 May 2005 - 02:44 - r1.2 ThomasWeigert Issue 8295: Section: 13.3.2 Issue summary Specialization mentioned for the association context:BehavioredClassifier[0..1] is not shown on figure 311. Multiplicities for ownedParameter:Parameter in the text do not agree with fig. 311. According to the text the ownedParameter:Parameter references a list of parameters 'that can be given' which implies that no parameters may be given and therefore the multiplicity should be [0..*]. This is not what is shown in fig. 311. Multiplicities for remaining associations listed do not agree between the text and the diagrams (fig. 311 & 313). Multiplicities should probably be [0..*] which are not what are shown in figs. 311 & 313. Add the specialization for the association redefinedBehavior:Behavior in the text to agree with fig. 311. Specializations listed for the associations precondition:Constraint and postcondition:Constraint do not agree with fig. 313. Figure 313 shows that these associations subset ownedRule. Add OCL notation to the constraints where possible or indicate that OCL notation is not available. Discussion With respect to the multiplicity .*., this is the same as .0..*.. The default rule when writing this specification was that association have multiplicity .*. when omitted. However, it is probably better to list these multiplicities explicitly. -- ThomasWeigert - 26 May 2005 Resolved, with the exception of OCL. -- ThomasWeigert - 26 May 2005 Revised Test In Section 13.3.2., context, mark context as derived. Delete the phrase .(Specializes Redefinable Element?.redefinitionContext.). In Figure 311, mark Behavior.context as derived. For all omitted multiplicities in the text of this section, add multiplicity .*.. For consistency, change the use of .0..*. in this section to .*.. For precondition and postcondition, change the parenthetical section to .(Specializes Namespace.ownedRule.). Resolution -------------------------------------------------------------------------------- RtfIssue1000000055 23 May 2005 - 16:00 - r1.3 FaySchafernak Issue 8297: Section: 13.3.3 Issue summary Multiplicities for the associations need to be added to the text for raisedException:Classifier[0..*], and changed in the associated diagrams to reflect the correct multiplicity (1 for method:Behavior (according to the text) and not * as shown in fig. 311 and 0..* for fig. 315). Unless 'specializes' means the same thing as 'redefines' change either the text for raisedException:Classifier from specializes to redefines or change fig 315. from redefines to specializes. Regardless, less confusion would occur if the text and the figure used the same word. Discussion The issue text confuses the description of Behavioral Feature?.behavior with a specificaiaton of multiplicity. Revised Test To avoid confusion, in Section 13.3.3, add .0..*. for all associations which do not have multiplicities shown. Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000056 21 Jul 2005 - 17:57 - r1.9 ConradBock Issue 8301: Section: 13.3.4 Issue summary Under sub-section Generalizations change 'Class' to 'Classifier.' Figures use italics for displaying the concept name so you need to mention that Behaviored Classifier? is an abstract class. Under sub-section Associations add package name Basic Behaviors? before the first two associations. Add the multiplicity which should probably be [0..*] and if this is correct then change fig. 311 to agree with [0..*] or 1 as is currently indicated by the text. If the multiplicity is as indicated in fig. 311 (*), then change the text to agree. For the association ownedTrigger:Trigger[0..*], fig. 316 does not indicate this multiplicity. Make the two agree. Add OCL notation or a note that OCL can not supply notation. The sub-section Semantics describes two Behaviored Classifiers? - an immediate event and an input event pool. Possibly consider making these children of Behaviored Classifiers? or of Event (fig. 316), i.e. Immediate Event Occurrence? and Input Event Pool?, instead of just Event. If this is done then two additional concepts would need to be added. Discussion Multiplicity for ownedTrigger is given in Figure 316. The semantics section does not describe two alternate kinds of Behaviored Classifiers?, but two possible manifestations of the behavior, depending on the Trigger associated. -- ThomasWeigert There may be some odd cases where a classifier behavior is a method. There is no reason to rule it out, that I can think of. Please post if I missed something. -- ConradBock - 17 Jul 2005 Revised Test Under sub-section Generalizations change "Class" to "Classifier." Under sub-section Associations add package name Basic Behaviors? before the first two associations. For increased clarity, for associations without multiplicities, add .*. as multiplicity. Change .0..*. to .*.. Constraints section of 13.3.4: Replace If a behavior is classifier behavior, it does not have a specification. with [1] If a behavior is classifier behavior, it does not have a specification. self.classifierBehavior.notEmpty() implies self.specification.isEmpty() Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000057 23 May 2005 - 16:01 - r1.3 FaySchafernak Issue 8302: Section: 13.3.7 Issue summary Add the specializes or subsets comment to the association to agree with fig. 317. Question: If the default value of a Boolean expression is true and its value changes to false would there be a corresponding changeExpression? To me the description and semantics imply that the default value for all Boolean expressions is set at false and this isn't true (e.g., Mutliplicity Element? attribute isUnique; Port attribute isService). Therefore, what happens when those values change? Discussion As stated, the change event occurs only when the value of a Boolean expression changes to true. This has nothing to do with what the default value for expressions is. -- BranSelic - 20 May 2005 Change "." notation to "::" notation. Revised Test At the end of the text for changeExpression, add .(Specializes Element::ownedElement.). Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000058 23 May 2005 - 16:01 - r1.3 FaySchafernak Issue 8303: Section: 13.3.8 Issue summary Under sub-section Description change 'each of its instance' to 'each of its instances.' The multiplicity for the association ownedReception:Reception in the text does not agree with fig. 314. If it is [0..*} both text and fig. 314 need changing. Specializes Classifier.feature is not shown in fig. 314 as a specialization of Class but rather as a subset of Interface. Correct either the fig. 314 or text. Discussion Specialization of feature is shown in Figure 314 as described in text. -- BranSelic - 20 May 2005 change "*" to "0..*" in revised text. Revised Test Under sub-section Description change "each of its instance" to "each of its instances." For increased clarify, for associations without multiplicities, add .0..*. as multiplicity. Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000059 23 May 2005 - 16:02 - r1.2 FaySchafernak Issue 8304: Section: 13.3.10 Issue summary Figure 318 shows an association of specification:DurationInterval[1] that redefines specification. Add this to the text or delete the association from the figure. Delete the '.' after 'DurationConstaint in Figure 320 caption. Discussion Revised Test In Association sub-section, add: Specification: Duration Interval? [1] The interval constraining the duration. Delete the "." after "DurationConstaint in the caption for Figure 320. Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000060 23 May 2005 - 16:03 - r1.2 FaySchafernak Issue 8305: Section: 13.3.9 Issue summary Reword the last sentence under sub-section Semantics. Assuming is not good. State clearly that the ending point in time and the starting point in time would swap. Change 'assuming' to 'because.' Under sub-section Notation, change 'Often a Duration is a non-negative integer expression...' to 'Often a Duration is an Unlimited Natural? number...' Use of the word 'often' implies that the notation could be expresses as a negative integer which, for Duration is an impossibility (at least in our universe Discussion Revised Test Delete the second paragraph in the Semantics sub-section. Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000061 19 May 2005 - 04:36 - NEW ThomasWeigert Issue 8306: Section: 13.3.11 Issue summary Describe more fully that Duration Interval? defines the range between the minimum and maximum duration times allowed. To be consistent with other mutliplicities, show the multiplicities of the associations on fir. 318. Add comment that the associations redefine minimum and maximum as indicated by fig. 318. Sub-section Notation mentions Duration Expression? but this concept is not defined. Add this as a concept. Discussion Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000062 23 May 2005 - 16:08 - r1.3 FaySchafernak Issue 8307: Section: 13.3.12 Issue summary To be consistent, add the multiplicity for duration:Duration[1] to figure 318. Also, fig. 318 indicates that the association redefines value. Please indicate this in the text. I am not familiar with BFN but should [illegible, ed.]? Discussion The first sentence in the issue description is a duplicate. -- BranSelic - 20 May 2005 the illegible part of the text said: I am not familiar with BFN but should "" be ""? (it was accidentally corrupted due to the OMG database software quirk which removes text between angular brackets). I don't think that this correction is necessary. also, changed dot notation to double-colon notation Revised Test In the specification of duration, add .(Specializes Value Specification?::value.). Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000063 09 Aug 2005 - 21:10 - r1.11 ThomasWeigert Issue 8308: Section: 13.3.14 Issue summary Add OCL notation or a note that OCL is unable define a notation for the constraints. Discussion Regarding the solution below, what about recursive nesting level (e.g., the attributes of the attributes)? -- ThomasWeigert - 19 May 2005 Good question. I've changed the OCL slightly and introduced a recursive function. Please check! I'm not sure what happens if d.ownedAttributes is a empty set? Does it evaluate to true? -- Tim Weilkiens - 20 May 2005 Fixed recursive function to work on the type of the ownedAttributes not the attributes themselves. Fixed first constraint to test the size() of the select result. -- PeteRivett - 28 Jun 2005 From message on rtf list after this was proposed for balloting: Constraint [1] was intended to refer to return parameters (got confused with output pins). I guess it could be generalized to: [1] A function behavior has at least one output parameter. self.ownedParameters->select(p|p.direction=#out or p.direction=#inout or p.direction=#return)->size() >= 1 In [2], hasNestedDataTypes allows empty types for data type attributes, which are not allowed by the text of the constraint. Also the name hasNestedDataTypes implies there must be nested datatypes. Suggested revision: [2] The types of parameters are all data types, which may not nest anything but other datatypes. def hasAllDataTypeAttributes(d : Data Type?) : Boolean = d.ownedAttribute->forAll(a| a.type.oclIsTypeOf(Data Type?) and hasAllDataTypeAttributes(a.type)) self.ownedParameters->forAll(p|p.type.notEmpty() and p.oclIsTypeOf(Data Type?) and hasAllDataTypeAttributes(p)) The OCL spec is a bit unclear on whether forall over an empty collection is true, but it says it's false if one of the them is false, so I hope if there are none, then its true. That's the usual convention. Copied above revision in revised text below. -- ConradBock - 17 Jul 2005 Revised Test In constraints section of 13.3.14: Add OCL to constraints: [1] A function behavior has at least one output parameter. self.ownedParameters->select(p| p.direction=#out or p.direction=#inout or p.direction=#return)->size() >= 1 [2] The types of parameters are all data types, which may not nest anything but other datatypes. def: hasAllDataTypeAttributes(d : DataType) : Boolean = d.ownedAttribute->forAll(a| a.type.oclIsTypeOf(DataType) and hasAllDataTypeAttributes(a.type)) self.ownedParameters->forAll(p|p.type.notEmpty() and p.oclIsTypeOf(DataType) and hasAllDataTypeAttributes(p)) Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000064 23 May 2005 - 16:09 - r1.3 FaySchafernak Issue 8309: Section: 13.3.15 Issue summary The association multiplicity in the text does not agree with fig. 314. If multiplicity is [0..*], both text and figure need to be changed Discussion -- BranSelic - 20 May 2005 changed to 0..* as per guidelines Revised Test For increased clarify, in 13.3.15, for associations without multiplicities, add .0..*. as multiplicity. Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000065 08 Jun 2005 - 16:09 - r1.6 OysteinHaugen Issue 8310: Section: 13.3.17 Issue summary Figure 318 shows the association specification:Interfal[1] that redefines specification. Add this to sub-section Associations in the concept since the concept is not as specialized Discussion The associations from Interval Constraint? and its subclasses named "specification" is not documented. Should this construct be removed? -- ThomasWeigert 18 May 2005 Usually the metamodel overrides omissions in the text, but if it's completely missing, we'd hafto to find out what the authors intended, which no one ever saw! -- ConradBock - 03 Jun 2005 The issue is about whether the specialization of the association is also written in the text as well as in the metamodel. The document is not consistent in either doing it or not doing it. As for what Thomas and Conrad talks about, that is a completely different matter. The association 'specification' originates from Constraint, and it is explained there as the specification of what is to hold. Regarding Interval what is to hold is that whatever is observed is within the interval. This is defined by an Interval Constraint?. So to sum up: The pair Interval Constraint? and Interval is a specialization of the pair Constraint, Value Specification?. The association that holds the pairs together is the 'specification' association. I really cannot see anything very peculiar with this. -- OysteinHaugen - 08 Jun 2005 Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000066 23 May 2005 - 16:10 - r1.3 FaySchafernak Issue 8311: Section: 13.3.19 Issue summary The multiplicity of the attribute language:String[*] in the text does not agree with that shown in fig. 311. Change fig. 311 to agree with the text. Delete the sub-section heading Examples are there none. Discussion -- BranSelic - 20 May 2005 changed to 0..* Revised Test In Figure 311, change multiplicity for language to .0..*.. In Section 13.3.19, delete sub-section .Examples.. Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000067 12 Jul 2005 - 20:09 - r1.7 ThomasWeigert Issue 8312: Section: 13.3.20 Issue summary Add OCL notation to or a note that OCL can not define the constraints Discussion Did I understand it right that "The behavior must not have formal parameters." means that there are no in,out,inout parameters? -- Tim Weilkiens What this means is that the Behavior that is at self.behavior must not have any parameter other than return parameters. Maybe the English text should be changed (there used to be an association "formalParameter"). We probably should change the text to say that it should only have return result parameters. -- ThomasWeigert - 24 May 2005 Revised Test Constraints section of 13.3.20: Change text of constraint [1] as follows and add OCL to constraints: [1] The behavior may only have return result parameters. self.behavior.notEmpty() implies self.behavior.ownedParameters->select(p|p.direction<>#return)->isEmpty() [2] The behavior must have exactly one return result parameter. self.behavior.notEmpty() implies self.behavior.ownedParameter->select(p|p.direction=#return)->size() = 1 Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000068 12 Jul 2005 - 20:09 - r1.5 ThomasWeigert Issue 8313: Section: 13.3.22 Issue summary Add OCL notation to constraint [2] or the note that ICL notation is not definable Discussion I propose to move the constraint to Class (from Communications) with the same text and the OCL: not self.isActive implies self.ownedReception.isEmpty() It isn't easy to navigate from Reception to Class. It's possible to go via Behavioral Feature?::method to Behavior and via Behavior::context to Behaviored Classifier?. Then checking if the Behaviored Classifier? is a Class (downcast) and evaluating the isActive property. So it's possible to define such a constraint, but it's not nice. And I think it's the responsibility of Class and not of Reception. -- TimWeilkiens This is a good idea. -- ThomasWeigert - 24 May 2005 Revised Test In Section 13.3.22., subsection "Constraints", delete constraint [2]. In Section 13.3.8., add subsection "Constraints" with the following constraint: [1] A passive class may not own receptions. not self.isActive implies self.ownedReception.isEmpty() Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000069 23 May 2005 - 16:16 - r1.2 FaySchafernak Issue 8314: Section: 13.3.23 Issue summary Under sub-section Description change wording to the following: 'A signal is a specification of a type of send request instances that communicated...' and 'The data...are representedas attributes...' Discussion Revised Test In 13.3.23, change the subsection .Description. to the following: A signal is a specification of send request instances communicated between objects. The receiving object handles the received request instances as specified by its receptions. The data carried by a send request (which was passed to it by the send invocation occurrence that caused that request) are represented as attributes of the signal. A signal is defined independently of the classifiers handling the signal occurrence. Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000070 27 Jul 2005 - 20:18 - r1.2 BranSelic Issue 8315: Section: 13.3.24 Issue summary Fig. 317 shows signal:Signal[1] as an association of Signal Event?, not an attribute. Either correct text or figure. Delete the '.' leading the first paragraph under the sub-section Notation Discussion It should be updated in the text to match the figure. I cannot see any leading ... Under the Notation sub-section (probably got confused with a smudge on the submitters screen ). -- BranSelic - 27 Jul 2005 Revised Text On page 487 in the Associations sub-section of Signal, replace the entry: ownedAttribute: Property [*] The attributes owned by the signal. The association is ordered and subsets Classifier. attribute and Namespace.ownedMember. with: signal: Signal [1] The signal that is associated with this event. Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000071 20 Oct 2005 - 07:53 - r1.8 ThomasWeigert Issue 8316: Section: 13.3.26 Issue summary Add package name Simple Time? to association when:TimeExpression[1]. Fig. 318 shows that this association redefines when. Add the association for the package Communications as shown in fig. 317. This is when:ValueSpecification[1] that subsets ownedElement. Discussion This is actually a bigger problem than stated above. There is a discrepancy between figure 318 and 317 regarding how the .when. value is specified. In the former case it is a ValueSpecification and in the latter a TimeExpression. The recommendation here is to replace ValueSpecification, which is too general and not suitable for any kind of timing analysis, with the more specific TimeExpression. However, to allow separation of the general model of time from the rather constrained model in the SimpleTime package, it is recommended to model TimeExpression in two merge increments. The first more general one, defined in Communications, would only have a value but not the additional specializations currently defined in SimpleTime (TimeExpression::event and firstTime attribute). These would be added in the SimpleTime package increment only. Note that the original definition of TimeExpression did not actually provide for a way of specifying the time value, which is why a .value. attribute needs to be added. Since time expressions can get very complex and may have a variety of different formats, this attribute should be typed by a ValueSpecification. This provides the most flexibility, allowing the case where the value could be specified by one of the literals already defined. (NB: a constraint is needed to prevent the ValueSpecification here from being a TimeExpression, since that would lead to needless recursion and complexity.) -- Main.BranSelic - 27 Jul 2005 I don't understand what you are trying to do here. TimeExpression, for example, is a ValueSpecification and yiedls a value. It does not need a value slot. Similarly, I don/t understand the changes to TimeEvent proposed. Maybe I am missing what you are trying to achieve, but it is far from clear. Also, can you attach the metamodel drawings... -- Main.ThomasWeigert - 28 Jul 2005 The relevant drawing is attached. ValueSpecification is an abstract class that does not have a value slot -- it needs to be added. Neither did TimeExpression as it was defined by Oystein. So, I added it. One of the things I wanted to do was give people the ability to model time without the need to import SimpleTime, which (and I've already made this clear a number of times) is quite inadequate and highly specialized. I could not add a value attribute to ValueSpecification because that would screw up all the subclasses that already had that attribute defined in a specialized way. At the same time, I did not want to change the SimpleTime model any. So, I split TimeExpression into two package increments: one general and one specialized for SimpleTime. If you want to talk about it, give me a time when. -- Main.BranSelic - 28 Jul 2005 I am equally unhappy with the simple time model, but am leary of propagating time models. I'd rather bite the bullet and fix the problem.... -- Main.ThomasWeigert - 29 Jul 2005 Fixing the time modeling problem is outside the scope of the RTF. The solution I have proposed provides the basis for such a solution, however, since it nicely isolates the simple time model. So, I would like to resubmit my proposal. It also happens to fix the original problem with simple time that there is no place to put the value of time. -- Main.BranSelic - 09 Aug 2005 Original proposal In figure 310 on page 458, add a package merge from SimpleTime to Communications. In figure 317 on page 462, replace the ValueSpecification class at the end TimeEvent::when with TimeExpression with one attribute defined: value : ValueSpecification Also, make the composition TimeEvent::when navigable from TimeExpression to TimeEvent. Finally add the ValueSpecification (from Kernel) class in the diagram with a generalization arrow from TimeExpression to ValueSpecification. In figure 318 on page 463, remove the TimeEvent class from the diagram and also the association TimeEvent::when. Change the heading for TimeExpression on page 491 from .TimeExpression (from SimpleTime). to .TimeExpression (from Communications, SimpleTime). In the Generalizations subsection of TimeExpression on page 491 add the entry: .TimeExpression (from Communications) on page . In the Attributes subsection of TimeExpression on page 491, right after the subsection header, insert the package header .Communications. followed by the item: value : ValueSpecification Specifies the instant when the time event occurs In the same subsection, following the item above but preceding the .event. item, insert the package header .SimpleTime.. In the Associations subsection of TimeExpression on page 492, insert the package header .SimpleTime. in front of the entry for .event. In the Constraints subsection of TimeExpression on page 492, replace the .No additional constraints. item with the following: Communications [1] The value of a time expression cannot be another time expression not (value.oclIsKindOf(TimeExpression)) (see TimeEventDiagram.pdf) -- Main.BranSelic Note that there is a much simpler solution, as described in Issue 8894, 9 Aug 2005. -- Main.ThomasWeigert - 09 Aug 2005 I am closing this issue as the solution proposed in Issue 8894 addresses this proposal also in much simpler form and appeared to be agreeable to the proposer of this issue. -- Main.ThomasWeigert - 20 Oct 2005 Revised Text Resolution Closed no change -------------------------------------------------------------------------------- RtfIssue1000000072 28 Jul 2005 - 22:04 - r1.2 BranSelic Issue 8317: Section: 13.3.27 Issue summary Under sub-section Description change 'represent' to 'represents.' Under sub-section Notation, reword 'Often a Time Expression? is a non-negative integer' to 'Often a Time Expression? is an Unlimited Natural? number.' Saying that often a Time Expression? is a non-negative integer implies that it may, at times, be a negative integer Discussion Editorial changes. The suggested reformulation is incorrect but a clarification of the text is in order. -- BranSelic - 28 Jul 2005 Revised Text In the section on TimeExpression on pages 491 and 492, make the following changes: In the first sentence of the Description subsection, change .represent. to .represents. In the Notation subsection, replace the sentence: Often a TimeExpression is a non-negative integer expression representing the number of .time ticks. after some given starting point. with A TimeExpression is an expression that evaluates to a non-negative integer representing the number of .time ticks. after some given starting point. Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000073 28 Jul 2005 - 22:09 - r1.2 BranSelic Issue 8318: Section: 13.3.28 Issue summary To be consistent with other multiplicities on the figure, add the multiplicities for the associations. Also mention that each association redefines minimum or maximum Discussion Indeed. The multiplicities are missing from figure 318 for both DurationInterval and TimeInterval. Also, in the text, the redefinitions should be noted. -- BranSelic - 28 Jul 2005 Revised Test In figure 318 on page 463, add the multiplicities 1 to the association ends TimeInterval::min, TimeInterval::max, DurationInterval::min and DurationInterval::max In the Associations subsection of DurationInterval on page 477, replace the two entries for min and max with the following: . min: Duration [1] Refers to the Duration denoting the minimum value of the range. Redefines Interval::min . max: Duration [1] Refers to the Duration denoting the maximum value of the range. Redefines Interval::max In the Associations subsection of TimeInterval on page 477, replace the two entries for min and max with the following: . min: TimeExpression [1] Refers to the TimeExpression denoting the minimum value of the range. Redefines Interval::min . max: TimeExpression [1] Refers to the TimeExpression denoting the maximum value of the range. Redefines Interval::max Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000074 28 Jul 2005 - 22:10 - r1.2 BranSelic Issue 8319: Section: 13.3.29 Issue summary To be consistent with other multiplicities in fig. 318, add the association multiplicity to the figure. Mention that the association redefines value as shown in the figure. I am not familiar with BNF notation but should [illegible, ed.] Discussion Most of this issue was resolved in the resolution to 8318. The capitalization of a BNF entry is a matter of taste . no need to change it. -- BranSelic - 28 Jul 2005 Revised Test Resolution Closed no change -------------------------------------------------------------------------------- RtfIssue1000000075 23 May 2005 - 16:17 - r1.3 FaySchafernak Issue 8320: Section: 13.3.30 Issue summary The generalization 'Dependencies' is not listed in fig. 316 under Named Element?. Add this to the figure. The association port:Port[*] is not diagrammed anywhere. Either remove this association from the text or add it to a figure. The sub-section Changes from UML 1.x indicates that the corresponding metaclass was changed from Event but names listed in the BNF definition are all children or grandchildren of the metaclass Event in fig. 317. I believe something needs to change or be clarified but I don't know what. Discussion The port association was moved into the composite structure package. Regarding the question as to the BNF, this is intended. The trigger references the specified event. Revised Test In 13.3.30, subsection .Generalizations., delete .Dependencies. from the list of generalizations for Named Element?. Delete specification of association end "port" from sub-section .Associations.. Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000076 12 Jul 2005 - 20:09 - r1.4 ThomasWeigert Issue 8322: Section: 13 Issue summary General comments: Add OCL notation to the constraints where possible. If not possible state that OCL notation is not available for the constraint. Either delete sub-section headings where there is no data for the sub-section or add the word 'None.' Make certain that the multiplicities for the associations agree between the text and the associated figures. There is inconsistency in representation of 0..* on figures, sometimes the figures use * to mean 0..* (according to the text definitions) and then sometimes 0..* is used. Several times the figures will note that an association is a redefinition of or subsets a class but the text does not mention this. Be certain to add the appropriate statement to the text definition. Discussion This duplicates a number of specific issues. Revised Test Resolution Duplicate -------------------------------------------------------------------------------- RtfIssue1000000077 19 May 2005 - 10:11 - NEW ThomasWeigert Issue 8385: UML 2 Super / Components / realizingClassifier Issue summary Interface Realization? is a subclass of Realization that inherits the attribute Realization::realizingClassifier (defined in the Components package). This attribute has a multiplicity of 1, which means that Interface Realization? must have a 'realizingClassifier', even though this attribute only makes sense when the target is a Component and not an Interface. This is complicated further by the fact that Interface Realization? has its own association end that serves a similar purpose called 'implementingClassifier'. But, this only makes sense for the case when the target of the realization is an Interface and not a Component. Interface Realization? should not be forced to have a 'realizingClassifier' attribute. The best way to fix this may be to define a separate subclass of Realization for the case of Components (e.g., Component Realization?) such that the two cases are kept apart. Alternatively, the multiplicity on Realization::realizingClassifier could be set to 0..1. Discussion Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000078 19 May 2005 - 10:11 - NEW ThomasWeigert Issue 8386: Section: 8.3.4 Issue summary Notation of a component realization is described as the same as the realization dependency, i.e. dashed line with open arrow-head. But the realization dependency has a triangular arrow-head. Please note that all component example figures use the open arrow-head. I would prefer the triangular arrow-head. Discussion Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000079 19 May 2005 - 10:12 - NEW ThomasWeigert Issue 8387: Section: 8.3.1 Issue summary Fig. 87 on page 157 shows a composite structure diagram. Therefore the horizontal line below the component name is missing (see 9.3.13 for composite structure notation). Discussion Revised Test Resolution -------------------------------------------------------------------------------- RtfIssue1000000080 23 May 2005 - 16:18 - r1.3 FaySchafernak Issue 8456: UML 2 Super / Collaborations / improper subset Issue summary In figure 100 of ptc/04-10-02, the association end Classifier::representation subsets .Classifier::occurrence. and should subset .Classifier::collaborationUse.. The fix should also be applied to the Associations specification for Classifier in the Composite Structures chapter on page 175. Recommendation: Change figure 100 as specified above. In the entry for Associations of Classifier on page 175, replace the parenthesized expression: Subsets Classifier.occurrence By the expression: Subsets Classifier.collaborationUse Discussion-- BranSelic - 20 May 2005 changed to double-colon convention Revised Test Change .subsets occurrence. in Figure 100 by .subsets collaborationUse.. In Section 9.3.2, Associations, replace under representation .(Subsets Classifier.occurrence..) by .(Subsets Classifier::collaborationUse.). Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000081 23 May 2005 - 16:19 - r1.2 FaySchafernak Issue 8463: UML 2 Super / Common Behaviors / missing multiplicites Issue summary In figure 318 on page 463, the multiplicities of Duration Observation Action?::duration and Time Observation Action?::now are not specified. This results in violations of the redefinition rules for these association ends. Recommendation: Set the multiplicities for these association ends to 1, to conform to the multiplicity of Write Structuralfeature Action?::value association end that they redefine Discussion Revised Test In figure 318 , set the multiplicities for Duration Observation Action?::duration and Time Observation Action?::now to 1. Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000000082 23 May 2005 - 16:19 - r1.2 FaySchafernak Issue 8476: Section: Common Behavior Issue summary Common Behavior: why does Figure 326 refer to Signal from Communications, but not Operation form Communications? (it looks like Communications can refer to Kernel:Operations rather than defining its own). Discussion In Communications, semantics and a semantic variation point are added to Operation. Defining this semantics requires the presence of concepts that are introduced in Commuincations. However, this semantics is not necessarily required for interactions, and thus Operation::Kernel is referenced there. Revised Test Resolution Closed no change -------------------------------------------------------------------------------- RtfIssue1000000083 09 Aug 2005 - 22:44 - r1.9 ThomasWeigert Issue 8038: Is Read Only? constriant Issue summary (done) Is Read Only? constriant Constraint on Structural Feature?::isReadOnly: if true and there is no intialization value, then the lower multiplicity must be zero Discussion Original proposal for resolution: Section 7.3.44, Constraints: Add [10] A read-only property with no default value must have a lower multiplicity of 0. self.isReadOnly and self.defaultValue.isEmpty() implies self.lower = 0 -- TimWeilkiens This looks like a Classes issue. Is the Classes WG using the wiki now? -- ConradBock - 21 Jul 2005 A Structural Feature? has no initial value. That's a feature of a property (defaultValue). Therefore I assume that this issue refers to Kernel::Property. -- TimWeilkiens - 27 Jul 2005 I don't agree with this one. The intial value could be set dynamically by a constructor, 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. -- ConradBock - 21 Jul 2005 What is the difference between initial value and default value? I can't find the initial value in the specification for structural features. I also can't find the concept of a constructor in the Kernel package. So I can follow your point, but by now I can't see the relation to this issue. -- TimWeilkiens - 29 Jul 2005 Better wording: 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. -- ConradBock - 02 Aug 2005 I'd like to recommend this as Closed No Change, for the reasons I gave on August 2nd. -- ConradBock - 07 Aug 2005 Agree with Conrad. -- ThomasWeigert - 09 Aug 2005 Revised Test Resolution Closed no change -------------------------------------------------------------------------------- RtfIssue1000008894 20 Oct 2005 - 07:48 - r1.11 ThomasWeigert Issue 8894: TimeExpression Issue summary TimeExpression should hold time value, but there is no attribute for that. Maybe TimeExpression should be inherited from OpaqueExpression and hold value in "body"? Discussion The issue is confused about how the "simple time" model works. TimeExpression is an expression that yields a value (it is a ValueExpression); it does not store a value. So no location to hold a value is required. -- ThomasWeigert - 27 Jul 2005 We clearly have a disagreement here (see my proposal for issue 8316). I don't think your idea works. If I want to say that something happens in 3.75 [whatevers], then where is the "3.75" going to be stored in the model if the TimeEvent::when model element is TimeExpression as currently defined in the SimpleTime model? I don't see any placeholder for it. Note that there is no string for storing the expression that might represent a time expression. -- BranSelic - 28 Jul 2005 Here is how I think that I originally thought: A Time Expression? is a subclass of Value Specification?. A Value Specification? has an attribute called expression:Expression[0..1]. This is what I have thought should be used to describe the actual value of the time expression given in the diagram. An Expression contains an attribute symbol:String. I thought this would in the end be what would be used.It is possible that Time Expression? should contain something more making this value clearer, but I did not intend to define the Time datatype as a basic datatype. -- OysteinHaugen - 03 Aug 2005 Unfortunately, ValueSpecification does NOT have an expression:Expression attribute -- note the navigability arrow in figure 6 on page 25 (see also section 6.5.2 on the meaning of this arrow). Therefore, there is no place to hold expressions if TimeExpression inherits from ValueSpecification. My suggested change was to provde that capability in TimeExpression. -- BranSelic - 03 Aug 2005 I think this issue is related with issue 7967, isn't it? I can't see why Time Expression? should hold a time value. My understanding of Time Expression? or in general of Value Specification? is that it specifies a value. The container of that value is something different. -- TimWeilkiens - 04 Aug 2005 I am confused by your comment Tim. If you look at the various concrete subclasses of ValueSpecification, you will actually see a container for the value. If your model says that a transition will trigger at 4 pm, there has to be a placeholder for the "4 pm" expression. TimeExpression has no such placeholder, so this information cannot be stored in the model. Note that I am not saying that ValueSpecification should have such a placeholder. It's abstract and does not need one. But, all the concrete subclasses do. -- BranSelic - 09 Aug 2005 Bran, this is not quite correct. A value specification is something that describes a value. That could be by holding some detail of that value (as in LiteralInteger, for example) or by its nature (as in LiteralNull, for example). So it really depends on what kind of value you are describing. As defined today, TimeExpression just returns a specific time value. There are two possibilities: TimeExpression.event is empty: In this case the value returned is the time at the point that this expression is evaluated otherwise, the value returned is the time that TimeExpression.event occurs (either beginning or end, depending on the firstTime flag. As you can see, there is no need for storing a value. However, what TimeExpression does not do is to allow you to state things such as "generate an event in 1 hour". Of course, this is a problem, since TimeEvent is supposed to trigger when the time denoted by its associated TimeExpression occurs. But this seems to be a bug in TimeEvent. Actually, what we need is two things: A way of describing a deadline for TimeEvent A way of describing a point in time (as todays TimeExpression) We should not be changing these things around until we have a good understanding of what we want this time model to be. I really think some surgery is required. -- ThomasWeigert - 09 Aug 2005 I just noticed that in issue Issue 8317 Bran has suggested that TimeExpression always yields a non-negative Integer (not some undefined time data type). Therefore, we could simply resolve this by changing TimeEvent.when to a ValueSpecification with the constraint to yield a non-negative Integer. It can then either hold a TimeExpression or a LiteralInteger, for example. In the latter case, this would be giving the desired deadline. -- ThomasWeigert - 09 Aug 2005 That might be an acceptable solution with a minimum of perturbation. -- BranSelic - 10 Aug 2005 Revised Test In figure 13.12., replace the TimeExpression at TimeEvent.when by a ValueSpecification. Note that this has already been done in the specification. In section 13.3.26, TimeEvent, change the assocation when: TimeExpression [1] to be when: ValueSpecification [1] In subsection "Constraint", add the following constraint: [1] The ValueSpecification when must return a non-negative Integer. Resolution Resolved -------------------------------------------------------------------------------- RtfIssue1000008900 07 Aug 2005 - 16:57 - r1.2 ConradBock Issue 8900: Page: 157,162,163 Issue summary Fig. 87, fig. 92, and fig.93 show composite structure diagrams with interfaces. For example fig 87; delegation connector from port to interface OrderEntry. How can a connector be linked to an interface? Discussion I agree with the issue that the notation is very confusing. This connector (while drawn between the interfaces) is actually between connectable elements (parts or ports); it does not really connect interfaces. It would be advisable to clarify this in the text or to replace this notation by a clearer one. -- ThomasWeigert - 20 Jul 2005 Revised Test It's a compact and intuitive notation, though. I think it is enough to clarify the mapping to the model. -- ConradBock - 07 Aug 2005 Resolution -------------------------------------------------------------------------------- RtfIssue1000008901 20 Oct 2005 - 07:37 - r1.8 ThomasWeigert Issue 8901: Page: 163 Issue summary Fig. 93: The only message of the notation abstraction is that some components offer and some components require an interface. That the same as in a component diagram. Fig. 93 shows an internal view of a component. A composite structure diagram must show how the components are wired together. For examples that :BackOrder uses :Customer and NOT :Organization or vice versa. I propose to not use the notation abstraction. Discussion Agree with the issue. The notation abstraction (should be called "notation option") is not well-defined in the text. -- ThomasWeigert - 20 Jul 2005 I think it's fine as a compact, intuitive notation to show the same interface provided/required by multiple component parts. The text above Figure 93 could be clarified by replacing "particular" with "the same", and "abstraction" with "presentation option". -- ConradBock - 07 Aug 2005 This is a confusing notation that does not clarify at all whether there is one connector or many involved. Like Thomas, I agree with the submitter. However, removing this notation at this point is likely to have a major impact -- I have seen it used too many times already in books and actual models. Too bad. -- BranSelic - 09 Aug 2005 OK, but that does not change the fact that it is not well-defined. Some work has to be done... -- ThomasWeigert - 09 Aug 2005 How about specifying how many connectors are implied? If it one interface to one interface, presumably it's one. If it's one interface to two on separate parts, it's two. PLus the clarifications in my entry of 07 Aug 2005. -- ConradBock - 12 Aug 2005 What I find unfortunate is that this notation implies (as well as the simple ball-and-socket notation) that there is a connector between two interfaces. But really this is not the case; instead the connectors are between roles. Basically, these are limited connectors such that required and provided interfaces must be the same and they are unidirectional only. The notation option on p.93 adds that if these constraints hold for more than one part, we can all connect them to the same interface. -- ThomasWeigert - 19 Aug 2005 Agreed, but I think this is more an issue for us metamodelers than users. It conveys the right thing informally, that communication can occur between the objects playing the roles, though the specified interfaces. Perhaps we could also show the connector notation, and just explain it is a shortand for that. -- ConradBock - 21 Aug 2005 Introducing a minimalist resolution, to just fix the incorrectly used terminology. -- ThomasWeigert - 20 Oct 2005 Revised Test On p.152, immediately after figure 8.17, add a subsection heading "Presentation Option". Replace the first paragraph after the caption for figure 8.17 by the following: "Where multiple components provide or require the same interface, a single symbol representing the interface can be shown, and lines from the components can be drawn to that symbol, indicating that this interface is either a required or provided interface for the components. This presentation option is applicable whether the interface is shown using "ball-and-socket" notation, as in figure 8.18 below, or just using a required or provided interface symbol. Resolution Resolved uml2composition-fig12-small.gif From: Steve Cook To: "conrad.bock@nist.gov" , "uml2-rtf@omg.org" Date: Mon, 15 Jun 2009 11:19:26 +0100 Subject: RE: Ballot 8 draft is available for review! Thread-Topic: Ballot 8 draft is available for review! Thread-Index: AcnquaCJCLRejHoGTj29HMYNJrjy2ACXF99AACLT+RA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n5FAJHwt013763 Regarding issue 8026: in my view, notwithstanding the recent flood of emails on this topic, there is a clear distinction between changes to the spec that make it possible to implement, and changes that are genuine enhancements. The latter enhancements incur additional costs to implementers and are out of scope of the RTF. I believe 8026 falls into this category and I do not propose to withdraw it from this ballot. If others disagree, then presumably it will not survive the vote and will end up deferred. On the other hand, for 11815 and 6083, I agree that there is a good argument that they represent flaws in the current spec, are not proposals for enhancements, and should be deferred. Thanks -- Steve -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: 14 June 2009 18:36 To: uml2-rtf@omg.org Subject: RE: Ballot 8 draft is available for review! Maged, et al, Here are my comments on draft ballot 8. Issues 11815, 6083, 8026 should be deferred if there's not enough time to address them, or removed from the ballot. Issue 9374 will need to be updated significantly. Conrad - Issue 11815 (Interaction Overview Diagram) As the resolution says, this is just a misunderstanding. It should be either clarified in the spec, or if the spec is clear enough already, closed as usual. It isn't a scoping issue. - Issue 6083 (More examples) This issue asks for more examples in the Interactions chapter, which are certainly needed. Since these are just clarifications, the are not out of scope. If there isn't enough time, it should be deferred. - Issue 9831 ("isLeaf") The issue asks for an OCL constraint for isLeaf, but the resolution does not address this. The resolution should say whether there is an OCL constraint, and add one if there isn't. - Issue 10515 (The concept of "this class cannot be subclassed" is missing in UML2) I think the meaning of the term "isLeaf" from UML 1.x should be preserved and "isFinal" used for redefinition. - Issue 8026 (Contextualized attribute values Figures 121) This can be answered by a presentation option, which is in scope of the RTF (presentation options are optional, which is why they are in different sections than notation). - Issue 12492 (Port) Couldn't this be resolved by modifying the constraint rather than removing it entirely? - 9374 (AssociationClass is severely underspecified) The proposed figure to replace Figures 7.17 and 7.27 should be included in the resolution for voters that don't have Eclipse installed. The change to last paragraph in Association.Semantics is incorrect and misleading. The first sentence mentions end ownership, which is not related to navigability, the topic of the paragraph. The second sentence starts with "For binary associations", when the rest of the sentence and paragraph apply to all arities. I suggest not changing this paragraph. The two constraints added to Association Class are incorrect. Association classes can have navigable ends like any other association. Same for the changes in semantics text reflecting these constraints. The updated description of AssociationClass should incorporate the existing text. Descriptions are typically in a rather loose style. The association class semantics does not need to duplicate the semantics of association (for example, the "n-1" paragraph, or any remarks starting "as with a regular association"). The example in Figure 7.27 shouldn't be removed. It is simple, which is good for examples. The suggested replacement might be a good adddition, but it is too complicated, uses UML terminology in other ways (eg, Activity), and doesn't show navigability of association classes. The changes to UML section should be updated for the changes above. The end of the revised text has changes referred to power types, which aren't the subject of this issue. - Issue 6111 (Reentrancy 1 ) The text for Subclause 11.3.8 is in the Actions chapter, so should not refer to tokens. Reply-To: From: "Conrad Bock" To: Subject: RE: Ballot 8 draft is available for review! Date: Mon, 15 Jun 2009 17:19:57 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnquaCJCLRejHoGTj29HMYNJrjy2ACXF99AACLT+RAAE56ksA== X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n5FLK3nN023005 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-MailScanner-Watermark: 1245705607.96897@AprNr0h1BEvWbASuLGy7cg X-Spam-Status: No Steve, > Regarding issue 8026: in my view, notwithstanding the > recent flood of emails on this topic, there is a clear > distinction between changes to the spec that make it > possible to implement, and changes that are genuine > enhancements. The latter enhancements incur additional > costs to implementers and are out of scope of the RTF. I > believe 8026 falls into this category and I do not propose > to withdraw it from this ballot. If others disagree, then > presumably it will not survive the vote and will end up deferred. Even under your extremely narrow guideline, the issue can be answered with a presentation option, which is obviously optional, and not a burden on implementers. Under the more workable guidelines RTF's normally use, this issue points out an inconsistency that should be addressed. Properties and undirectional associations are semantically identical, but connectors currently only provide contextualization for associations (the association that type connectors). The issue asks for this inconsistency to be rectified. This will also address the unusable solution currently given in the spec. Maged, I request this resolution be removed from the ballot or deferred for the reasons above. The other in/out scope questions are agreed, this one is the only controversial one left. Conrad Reply-To: From: "Conrad Bock" To: Subject: RE: Ballot 8 draft is available for review! Date: Tue, 16 Jun 2009 13:38:01 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnquaCJCLRejHoGTj29HMYNJrjy2ACXF99AACLT+RAAE56ksAAb+QKwABIlHkA= X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n5GHc6UD025196 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-MailScanner-Watermark: 1245778687.69542@jv3RIoM3zTZkVF7BYGgCKQ X-Spam-Status: No Steve, > Since you feel so strongly, let's withdraw 8026 from ballot > 8 and leave it deferred. Thanks. > You say the other scope questions are agreed. What about > 11815 and 6083? I have not seen agreement there, and they > are still on the ballot. Hadn't heard back but these were my comments: Issue 11815 (Interaction Overview Diagram), as the resolution says, is just a misunderstanding that the Interaction Overview Diagram is stored on the activity model. It could be either clarified in the spec, or if the spec is clear enough already, closed as usual. It isn't a scoping issue. Issue 6083 (More examples) asks for more examples in the Interactions chapter, which are certainly needed. Since these are just clarifications in an area that needs it, they aren't out of scope. If there isn't enough time, they can be deferred. Conrad