Issue 7967: An observed time value must be written into a structural feature (uml2-rtf) Source: oose Innovative Informatik eG (Mr. Tim Weilkiens, tim.weilkiens(at)oose.de) Nature: Enhancement Severity: Minor Summary: TimeObservationAction is a specialized WriteStructuralFeatureAction. 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 Resolution: Discussion: These actions were removed as part of an earlier fix. Revised Text: N/A Disposition: Closed, no change Revised Text: Actions taken: December 3, 2004: received issue October 27, 2008: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 03 Dec 2004 08:27:54 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Tim Weilkiens Company: oose.de GmbH mailFrom: tim.weilkiens@oose.de Notification: Yes Specification: UML Superstructure Section: 13.3.29 FormalNumber: ptc/04-10-02 Version: 2.0 RevisionDate: 10/08/2004 Page: 493 Nature: Enhancement Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Description TimeObservationAction is a specialized WriteStructuralFeatureAction. 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. 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 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 > 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