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 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.