Issue 16249: State::stateInvariant multiplicity too restrictive (uml2-rtf) Source: Northrop Grumman (Mr. Christopher McClure, christopher.mcclure(at)ngc.com) Nature: Enhancement Severity: Minor Summary: The multiplicity of State::stateInvariant is specified as [0..1]. This seems to restrictive, as it common for states to have multiple invariants, especially since this is the most convenient mechanism for specifying the actual values for properties, etc. that define the state. Furthermore, widening the multiplicity to [*] would be in alignment with the multiplicities of pre/postconditions on operations, etc. Resolution: Revised Text: Actions taken: May 16, 2011: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 16 May 2011 20:32:18 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Christopher McClure Employer: Northrop Grumman Corporation mailFrom: christopher.mcclure@ngc.com Terms_Agreement: I agree Specification: UML Superstructure Specification Section: 15.3.11 FormalNumber: 10-11-14-1 Version: 2.4 Doc_Year: 2011 Doc_Month: March Doc_Day: 01 Page: 568 Title: State::stateInvariant multiplicity too restrictive Nature: Enhancement Severity: Minor CODE: 3TMw8 B1: Report Issue Description: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=lR6d4RotDVFz1UgtzviKBSbIeB5+YX2bpkUnygh8p8U=; b=YboIf/ezaAsrTDcVPejtEwPYpzs+kG75alJfYNKP7oeT8nSz3EzV9E2FWNY76LGs2W pi/aEdcWPaliWCvm8pQbJsJBesVaNdf0l13DjydB4eSf+WE6TAXXshRlokn2RKPoaexe oMXurCyEs30+zkT97BZFuz1i17bBvm5QwjR8k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=ea+aqoQaoQMVKUr8qfmxbuRiduSxbGkQFl3M2HUzKGCLoGGVClV3sJ/8FTX6GYYvd7 sGymMqTUujTVzHdxvAclPhZH2PiPFXkcHexW06H8H3y9bjcMPAlDgfRiGJ39eY/N1cjr TgZugS6N7jirpeUvTcR2zAtCVh7sZtntrCILk= Sender: bran.selic@gmail.com From: Bran Selic Date: Tue, 17 May 2011 15:43:30 -0400 X-Google-Sender-Auth: QpH5CQ8Fc61Za9RJdVuXNXBNRB4 Subject: Re: issue 16249 -- UML 2 RTF issue To: Juergen Boldt Cc: issues@omg.org, uml2-rtf@omg.org Presumably, the desired effect can be achieved by a simple conjunction (AND) of the various invariants into a single invariant. I am not sure this is a limitation. Bran On Tue, May 17, 2011 at 1:21 PM, Juergen Boldt wrote: From: webmaster@omg.org Date: 16 May 2011 20:32:18 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Christopher McClure Employer: Northrop Grumman Corporation mailFrom: christopher.mcclure@ngc.com Terms_Agreement: I agree Specification: UML Superstructure Specification Section: 15.3.11 FormalNumber: 10-11-14-1 Version: 2.4 Doc_Year: 2011 Doc_Month: March Doc_Day: 01 Page: 568 Title: State::stateInvariant multiplicity too restrictive Nature: Enhancement Severity: Minor CODE: 3TMw8 B1: Report Issue Description: The multiplicity of State::stateInvariant is specified as [0..1]. This seems to restrictive, as it common for states to have multiple invariants, especially since this is the most convenient mechanism for specifying the actual values for properties, etc. that define the state. Furthermore, widening the multiplicity to [*] would be in alignment with the multiplicities of pre/postconditions on operations, etc. Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org From: "BERNARD, Yves" To: "uml25-ftf@omg.org" Date: Fri, 9 Aug 2013 14:18:17 +0200 Subject: [UML 2.5 FTF] ballot 8: #16249 Thread-Topic: [UML 2.5 FTF] ballot 8: #16249 Thread-Index: Ac6U+odpvYvP+D+rSHSlqT6cF1R4QA== Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Homogenizing the way the multiplicities of the subsets of ownedRule (e.g. precondition, stateInvariant, .) are managed within the metamodel makes sense to me. However, I understand that it would break the compatibility with 2.4.1. This issue should be deferred rather than close with no change. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: Steve Cook To: "BERNARD, Yves" , "Bran Selic (selic@acm.org)" CC: "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] ballot 8: #16249 Thread-Topic: [UML 2.5 FTF] ballot 8: #16249 Thread-Index: Ac6U+odpvYvP+D+rSHSlqT6cF1R4QAACroFQ Date: Fri, 9 Aug 2013 13:37:38 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.101] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(365934002)(189002)(199002)(47976001)(512954002)(47736001)(83322001)(33656001)(81342001)(16406001)(74662001)(81686001)(80022001)(6806004)(74366001)(4396001)(79102001)(19580395003)(19580385001)(16796002)(59766001)(77982001)(80976001)(31966008)(47446002)(16236675002)(65816001)(63696002)(54316002)(74876001)(71186001)(44976005)(53806001)(15202345003)(77096001)(49866001)(56776001)(20776003)(56816003)(76482001)(46102001)(19300405004)(54356001)(50986001)(74502001)(51856001)(76796001)(83072001)(69226001)(74706001)(76786001)(81542001)(55846006)(19580405001);DIR:OUT;SFP:;SCL:1;SRVR:BLUPR03MB034;H:mail.microsoft.com;CLIP:131.107.125.37;RD:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0933E9FD8D X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 131.107.125.37 X-MS-Exchange-CrossPremises-AuthSource: BN1AFFO11FD012.protection.gbl X-MS-Exchange-CrossPremises-AuthAs: Anonymous X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating;SFV:NSPM;SKIP:0; X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: BLUPR03MB034.namprd03.prod.outlook.com X-Virus-Scanned: amavisd-new at omg.org This is for Bran to comment, I think. From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 09 August 2013 13:18 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot 8: #16249 Homogenizing the way the multiplicities of the subsets of ownedRule (e.g. precondition, stateInvariant, .) are managed within the metamodel makes sense to me. However, I understand that it would break the compatibility with 2.4.1. This issue should be deferred rather than close with no change. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Bock, Conrad" To: "Manfred R. Koethe" , "uml25-ftf@omg.org" Date: Fri, 9 Aug 2013 11:19:03 -0400 Subject: RE: [UML 2.5 FTF] Ballot 8 - Preview 5 , 16249 Thread-Topic: [UML 2.5 FTF] Ballot 8 - Preview 5 , 16249 Thread-Index: Ac6VE7RaOGjNRCVGRliqWZKJ22wRsw== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org P.S. One from the Close No Change section. Conrad - 16249 (State::stateInvariant multiplicity too restrictive) I think this is a legitimate issue, especially when redefining states that might collect inherited invariants. Since it's a metamodel change, it can be deferred. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=DgNKPTM2UWaM4RkZu3F2D5Oapkr+jhv1/gGP0M3GGyk=; b=EfDGkiBjhPcadRLj6h19Vv24ew1Hm+mmTdrTk/yU9fLTb0JHuXfTZ32EYUITCI2H+v U1MT6LM/ENk9RYwQF1denqf7P4ylj09KzTfzpy3kPBgh1gvXzQ4zTZ2nhGR+E4+Dmh8w zNfzhgH9Ur+ViFvI8h3su3FD3c6U7On/LFdBqqjG8iE7EHMj5ZWK8K1ljYbubKC3Ez9y VKLiHRheYstwMbHMwcUZTq8ViV23fkr3Pca8nCPGo6ZeGzdy3webVDb2eR8RQYebBEFk cFN8JVL9D7tecf2iRVUvJqOG4j5sqMMB36OuNns91Ops1Ya9m3cHnJK9j/MeMnj/ZsCm AHRw== X-Received: by 10.221.24.75 with SMTP id rd11mr710782vcb.81.1376062106607; Fri, 09 Aug 2013 08:28:26 -0700 (PDT) Sender: bran.selic@gmail.com From: Bran Selic Date: Fri, 9 Aug 2013 11:27:45 -0400 X-Google-Sender-Auth: 7DXIgHNJqKf-xqw9W-NBdNlolzY Subject: Re: [UML 2.5 FTF] Ballot 8 - Preview 5 , 16249 To: "Bock, Conrad" Cc: "Manfred R. Koethe" , "uml25-ftf@omg.org" X-Virus-Scanned: amavisd-new at omg.org Good point, Conrad. Yves also objected to this one. Manfred, please remove 16249 from the ballot. Thanks...Bran On Fri, Aug 9, 2013 at 11:19 AM, Bock, Conrad wrote: P.S. One from the Close No Change section. Conrad - 16249 (State::stateInvariant multiplicity too restrictive) I think this is a legitimate issue, especially when redefining states that might collect inherited invariants. Since it's a metamodel change, it can be deferred. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=ZXxf8dmWeI+H3ktdnExjmKY+SqEIKw04GrsJ6B2ABkA=; b=VB04XHRSqMyWCB3BXhbdHpAZiQW/gJJ6biWHmpuv912gliR7yMAjwuqWWFQPEQQFvD MZqwPpBEikjYMAJKocixEOkJz5V1t7t7sYkO6i1GPLHuD3bC/ml2JOTMPsBJqpVt/EZO 1EOqrVnf2lkNKgwSNPD+2fXVr327jWPUEGpoXpMJar5jZCOQT0N+9ZRUUzokI1Ya0uRV Z0rkJmQ1KDqCqiW7s22mUhmD8lWWlWojNq3g8VrmaaCkvND7rvKywyNOEvaDOd6SPWaR 2MFbaJcgL2ut8IAYR/aMEdi0TVhFyKwcL6c6b2hcBHK1vwmbt3ntjWYy2HOOyt0KP6wQ 6hEQ== X-Received: by 10.58.100.234 with SMTP id fb10mr764504veb.5.1376062722979; Fri, 09 Aug 2013 08:38:42 -0700 (PDT) Sender: bran.selic@gmail.com From: Bran Selic Date: Fri, 9 Aug 2013 11:38:02 -0400 X-Google-Sender-Auth: vKzf5xQzUc7zUn41I1kDVFkseEA Subject: Re: [UML 2.5 FTF] ballot 8: #16249 To: Steve Cook Cc: "BERNARD, Yves" , "uml25-ftf@omg.org" X-Virus-Scanned: amavisd-new at omg.org I've asked that this resolution proposal be pulled from the ballot. However, it really strikes me that the point raised by both Conrad and Yves is a more general issue (or, even multiple issues) that should be addressed at a broader scope than just state machines. Bran On Fri, Aug 9, 2013 at 9:37 AM, Steve Cook wrote: This is for Bran to comment, I think. From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 09 August 2013 13:18 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot 8: #16249 Homogenizing the way the multiplicities of the subsets of ownedRule (e.g. precondition, stateInvariant, .) are managed within the metamodel makes sense to me. However, I understand that it would break the compatibility with 2.4.1. This issue should be deferred rather than close with no change. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "BERNARD, Yves" To: Bran Selic , Steve Cook CC: "uml25-ftf@omg.org" Date: Fri, 9 Aug 2013 18:17:09 +0200 Subject: RE: [UML 2.5 FTF] ballot 8: #16249 Thread-Topic: [UML 2.5 FTF] ballot 8: #16249 Thread-Index: Ac6VFontIVPXqZ51QW6YPcFvJBSkkQABSDzA Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Bran, I agree. Not only state machines have subsets of ownedRule. Yves From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: vendredi 9 aoû13 17:38 To: Steve Cook Cc: BERNARD, Yves; uml25-ftf@omg.org Subject: Re: [UML 2.5 FTF] ballot 8: #16249 I've asked that this resolution proposal be pulled from the ballot. However, it really strikes me that the point raised by both Conrad and Yves is a more general issue (or, even multiple issues) that should be addressed at a broader scope than just state machines. Bran On Fri, Aug 9, 2013 at 9:37 AM, Steve Cook wrote: This is for Bran to comment, I think. From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: 09 August 2013 13:18 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] ballot 8: #16249 Homogenizing the way the multiplicities of the subsets of ownedRule (e.g. precondition, stateInvariant, .) are managed within the metamodel makes sense to me. However, I understand that it would break the compatibility with 2.4.1. This issue should be deferred rather than close with no change. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The multiplicity of State::stateInvariant is specified as [0..1]. This seems to restrictive, as it common for states to have multiple invariants, especially since this is the most convenient mechanism for specifying the actual values for properties, etc. that define the state. Furthermore, widening the multiplicity to [*] would be in alignment with the multiplicities of pre/postconditions on operations, etc.