Issue 10353: UML2: Parameter::isException overlaps with Operation::raisedException (uml2-rtf)
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature: Uncategorized Issue
Severity: 
Summary: Section 12.3.41 in CompleteActivites extends Parameter with an isException property. Operation also has property raisedException. The relationship between parameters with isException true and the operation's raisedExceptions is unclear. Is it the intention that Parameter::isException is a notation for indicating the exceptions raised by an operation. If so, then it should be in Basic where raisedException is introduced and constraints need to be added to ensure these parameters are not included in the operation's ownedParameters, and are include in the operation's raisedException. See also Issue 9406: UML2: No notation for indicating Operation::raisedException. Hopefully this is not the case because it mixes parameter and exceptions together and results in redundancy in the metamodel. 

It is possible isException was added so Activities could have an ActivityParameterNode to output exceptions. But this did not get completely integrated with the rest of UML2. I will raise an issue for this too. Perhaps there should be ActivityExceptionNodes that correspond to an operation's raisedExceptions instead of mixing parameters with exceptions. 

Resolution: 
Revised Text: 
Actions taken:
September 19, 2006: received issue
Discussion: 

End of Annotations:=====
ubject: UML2: Parameter::isException overlaps with Operation::raisedException
X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005
From: Jim Amsden <jamsden@us.ibm.com>
Date: Tue, 19 Sep 2006 13:40:27 -0400
X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 7.0.1HF269 | June 22, 2006) at
 09/19/2006 11:40:28,
        Serialize complete at 09/19/2006 11:40:28



Section 12.3.41 in CompleteActivites extends Parameter with an isException property. Operation also has property raisedException. The relationship between parameters with isException true and the operation's raisedExceptions is unclear. Is it the intention that Parameter::isException is a notation for indicating the exceptions raised by an operation. If so, then it should be in Basic where raisedException is introduced and constraints need to be added to ensure these parameters are not included in the operation's ownedParameters, and are include in the operation's raisedException. See also Issue 9406: UML2: No notation for indicating Operation::raisedException. Hopefully this is not the case because it mixes parameter and exceptions together and results in redundancy in the metamodel. 

It is possible isException was added so Activities could have an ActivityParameterNode to output exceptions. But this did not get completely integrated with the rest of UML2. I will raise an issue for this too. Perhaps there should be ActivityExceptionNodes that correspond to an operation's raisedExceptions instead of mixing parameters with exceptions.