Issue 18778: Specification of Incr and Decr is ambiguous (kdm-rtf) Source: Benchmark Consulting (Dr. Stephane Vaucher, ) Nature: Clarification Severity: Significant Summary: The micro definition for kinds Incr and Decr is ambiguous. First, they are described in the preamble of A.2 and A.3. The description indicates that they should have a Reads and a Writes, which makes sense since they might represent the code for something like 'i++'. Second, they are described in the table under A.4. Control Actions. This would imply that they are used for control, but I don't understand why that would be the case. Furthermore, these ActionElements would have only an Addresses relationship, but that does not match the definition of an Addresses class (access to complex data structure/pointer). It would be helpful to know what is the correct description. Resolution: Revised Text: Actions taken: June 13, 2013: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 13 Jun 2013 11:44:27 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Stephane Vaucher Employer: Benchmark Consulting mailFrom: svaucher@benchmarkcanada.com Terms_Agreement: I agree Specification: Architecture-Driven Modernization (ADM): Knowledge Discovery Meta-Model (KDM) Section: Annex A FormalNumber: ptc/2010-12-12 Version: 1.3 Doc_Year: 2010 Doc_Month: December Doc_Day: 12 Page: 314-318 Title: Specification of Incr and Decr is ambiguous Nature: Clarification Severity: Significant CODE: 3TMw8 B1: Report Issue Remote Name: modemcable.benchmarkcanada.com Remote User: HTTP User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36 Time: 11:44 AM Description: The micro definition for kinds Incr and Decr is ambiguous. First, they are described in the preamble of A.2 and A.3. The description indicates that they should have a Reads and a Writes, which makes sense since they might represent the code for something like 'i++'. Second, they are described in the table under A.4. Control Actions. This would imply that they are used for control, but I don't understand why that would be the case. Furthermore, these ActionElements would have only an Addresses relationship, but that does not match the definition of an Addresses class (access to complex data structure/pointer). It would be helpful to know what is the correct description.