Issue 15769: Operation with multiple return parameter (uml2-rtf) Source: International Business Machines (Dr. Maged Elaasar, melaasar(at)ca.ibm.com) Nature: Uncategorized Issue Severity: Summary: We are talking about an operation declared in the UML metamodel, so Operation::returnResult() : Parameter [0..1] is definitely valid UML notation. while Operation::returnResult() : Set(Parameter) which is the way it is now in spec is definitely not valid UML notation, it is supposed to be: Operation::returnResult() : Parameter [*] In both cases, the way OCL interprets the result of such opertion is similar to how it interprets any value, as a collection, and as such collection operations can be called on it. Therefore, to be consistent, this operation should be changed have a simple "Parameter" as a return type. However, if we are going to leave this operation with * multiplicity to be more robust or OCL friendly, then at least we should be consistent in those other cases, where we have singular return result. OperationHasSingularReturnResult : 16 operation = <Operation> UML::Vertex::containingStateMachine () : StateMachine operation = <Operation> UML::Transition::redefinitionContext () : Classifier operation = <Operation> UML::Transition::containingStateMachine () : StateMachine operation = <Operation> UML::Stereotype::profile () : Profile operation = <Operation> UML::Stereotype::containingProfile () : Profile operation = <Operation> UML::StateMachine::LCA (s1 : State, s2 : State) : Namespace operation = <Operation> UML::State::redefinitionContext () : Classifier operation = <Operation> UML::State::containingStateMachine () : StateMachine operation = <Operation> UML::Region::redefinitionContext () : Classifier operation = <Operation> UML::Region::containingStateMachine () : StateMachine operation = <Operation> UML::Property::opposite () : Property operation = <Operation> UML::Package::containingProfile () : Profile [0..1] operation = <Operation> UML::Operation::type () : Type operation = <Operation> UML::LinkAction::association () : Association operation = <Operation> UML::Extension::metaclassEnd () : Property operation = <Operation> UML::Extension::metaclass () : Class Resolution: Revised Text: Actions taken: October 15, 2010: received issue Discussion: End of Annotations:===== ubject: Fw: Operation with multiple return parameter To: Juergen Boldt X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Thu, 21 Oct 2010 14:33:03 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/21/2010 14:33:04 This one too please... We are talking about an operation declared in the UML metamodel, so Operation::returnResult() : Parameter [0..1] is definitely valid UML notation. while Operation::returnResult() : Set(Parameter) which is the way it is now in spec is definitely not valid UML notation, it is supposed to be: Operation::returnResult() : Parameter [*] In both cases, the way OCL interprets the result of such opertion is similar to how it interprets any value, as a collection, and as such collection operations can be called on it. Therefore, to be consistent, this operation should be changed have a simple "Parameter" as a return type. However, if we are going to leave this operation with * multiplicity to be more robust or OCL friendly, then at least we should be consistent in those other cases, where we have singular return result. OperationHasSingularReturnResult : 16 operation = UML::Vertex::containingStateMachine () : StateMachine operation = UML::Transition::redefinitionContext () : Classifier operation = UML::Transition::containingStateMachine () : StateMachine operation = UML::Stereotype::profile () : Profile operation = UML::Stereotype::containingProfile () : Profile operation = UML::StateMachine::LCA (s1 : State, s2 : State) : Namespace operation = UML::State::redefinitionContext () : Classifier operation = UML::State::containingStateMachine () : StateMachine operation = UML::Region::redefinitionContext () : Classifier operation = UML::Region::containingStateMachine () : StateMachine operation = UML::Property::opposite () : Property operation = UML::Package::containingProfile () : Profile [0..1] operation = UML::Operation::type () : Type operation = UML::LinkAction::association () : Association operation = UML::Extension::metaclassEnd () : Property operation = UML::Extension::metaclass () : Class Subject: Operation with multiple return parameter To: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Fri, 15 Oct 2010 15:01:34 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/15/2010 15:01:35 Hi All, If we have this constraint in 7.3.37 Operation saying: [1] An operation can have at most one return parameter (i.e., an owned parameter with the direction set to .return.). ownedParameter->select(par | par.direction = #return)->size() <= 1 why then do we declare the following query with a many multipliclity? [2]The query returnResult() returns the set containing the return parameter of the Operation if one exists; otherwise, it returns an empty set. Operation::returnResult() : Set(Parameter); returnResult = ownedParameter->select (par | par.direction = #return) it should be: Operation::returnResult() : Parameter; Maged From: "Bock, Conrad" To: "uml2-rtf@omg.org" Date: Fri, 15 Oct 2010 15:19:11 -0400 Subject: RE: Operation with multiple return parameter Thread-Topic: Operation with multiple return parameter Thread-Index: Actsm5TtRjgXay1NS567wtdX9K7YxQAAe5pw Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov Maged, > If we have this constraint in 7.3.37 Operation saying: > > [1] An operation can have at most one return parameter > (i.e., an owned parameter with the direction set to 'return'). > ownedParameter->select(par | par.direction = #return)->size() <= 1 > > why then do we declare the following query with a many > multipliclity? > > [2]The query returnResult() returns the set containing the > return parameter of the Operation if one exists; otherwise, > it returns an empty set. > Operation::returnResult() : Set(Parameter); > returnResult = ownedParameter->select (par | par.direction > = #return) It makes the spec more robust when someone decides to remove the constraint, which really shouldn't be there. There's no reason an operation can't return multiple values. Conrad Subject: RE: Operation with multiple return parameter Date: Fri, 15 Oct 2010 15:27:23 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Operation with multiple return parameter Thread-Index: Actsm5TtRjgXay1NS567wtdX9K7YxQAAe5pwAAA3MhA= From: "Ed Seidewitz" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o9FJAWLQ023598 I am also never quite sure how a multiplicity of 0..1 is to be represented in OCL typing. Semantically, a value with this multiplicity is supposed to be either the empty set of a set of one value -- which is what is returned by the returnResult operation: either the empty set or the set containing the single return parameter (note the use of the singular in the tense). My guess is that the return type of Set(Parameter) was intended to capture this. However, I think a return type of Parameter would also be OK (at least if we keep the restriction to only one return parameter), because I think OCL allows such a function to also return the empty set (though I feeling to lazy to check the OCL spec right now...). -- Ed -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Friday, October 15, 2010 3:19 PM To: uml2-rtf@omg.org Subject: RE: Operation with multiple return parameter Maged, > If we have this constraint in 7.3.37 Operation saying: > > [1] An operation can have at most one return parameter > (i.e., an owned parameter with the direction set to 'return'). > ownedParameter->select(par | par.direction = #return)->size() <= 1 > > why then do we declare the following query with a many > multipliclity? > > [2]The query returnResult() returns the set containing the > return parameter of the Operation if one exists; otherwise, > it returns an empty set. > Operation::returnResult() : Set(Parameter); > returnResult = ownedParameter->select (par | par.direction > = #return) It makes the spec more robust when someone decides to remove the constraint, which really shouldn't be there. There's no reason an operation can't return multiple values. Conrad Subject: RE: Operation with multiple return parameter To: "Bock, Conrad" Cc: "uml2-rtf@omg.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Fri, 15 Oct 2010 15:31:28 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/15/2010 15:31:28 Conrad, According to the semantics of Parameter in 7.3.42: "The parameter direction specifies whether its value is passed into, out of, or both into and out of the owning behavioral feature. A single parameter may be distinguished as a return parameter. If the behavioral feature is an operation, then the type and multiplicity of this parameter is the same as the type and multiplicity of the operation itself." This says that an operation can indeed have multiple output parameters, but only a single one is distinguished as a "return" parameter. "Bock, Conrad" "Bock, Conrad" 10/15/2010 03:19 PM To "uml2-rtf@omg.org" cc Subject RE: Operation with multiple return parameter Maged, > If we have this constraint in 7.3.37 Operation saying: > > [1] An operation can have at most one return parameter > (i.e., an owned parameter with the direction set to 'return'). > ownedParameter->select(par | par.direction = #return)->size() <= 1 > > why then do we declare the following query with a many > multipliclity? > > [2]The query returnResult() returns the set containing the > return parameter of the Operation if one exists; otherwise, > it returns an empty set. > Operation::returnResult() : Set(Parameter); > returnResult = ownedParameter->select (par | par.direction > = #return) It makes the spec more robust when someone decides to remove the constraint, which really shouldn't be there. There's no reason an operation can't return multiple values. Conrad pic18946.gif Subject: RE: Operation with multiple return parameter To: "Ed Seidewitz" Cc: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Fri, 15 Oct 2010 15:34:58 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/15/2010 15:34:58 You can certainly write self.returnResult()->isEmpty() in OCL even if the return result's upper bound is 1. "Ed Seidewitz" "Ed Seidewitz" 10/15/2010 03:27 PM To cc Subject RE: Operation with multiple return parameter I am also never quite sure how a multiplicity of 0..1 is to be represented in OCL typing. Semantically, a value with this multiplicity is supposed to be either the empty set of a set of one value -- which is what is returned by the returnResult operation: either the empty set or the set containing the single return parameter (note the use of the singular in the tense). My guess is that the return type of Set(Parameter) was intended to capture this. However, I think a return type of Parameter would also be OK (at least if we keep the restriction to only one return parameter), because I think OCL allows such a function to also return the empty set (though I feeling to lazy to check the OCL spec right now...). -- Ed -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Friday, October 15, 2010 3:19 PM To: uml2-rtf@omg.org Subject: RE: Operation with multiple return parameter Maged, > If we have this constraint in 7.3.37 Operation saying: > > [1] An operation can have at most one return parameter > (i.e., an owned parameter with the direction set to 'return'). > ownedParameter->select(par | par.direction = #return)->size() <= 1 > > why then do we declare the following query with a many > multipliclity? > > [2]The query returnResult() returns the set containing the > return parameter of the Operation if one exists; otherwise, > it returns an empty set. > Operation::returnResult() : Set(Parameter); > returnResult = ownedParameter->select (par | par.direction > = #return) It makes the spec more robust when someone decides to remove the constraint, which really shouldn't be there. There's no reason an operation can't return multiple values. Conrad pic02974.gif Subject: RE: Operation with multiple return parameter Date: Fri, 15 Oct 2010 15:39:42 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Operation with multiple return parameter Thread-Index: ActsoCPA/dH52kqHQpm8NIeLqwSurwAAHX+w From: "Ed Seidewitz" To: "Maged Elaasar" Cc: Yes, but does declaring returnResult():Parameter effectively mean that the return result also has the default lower bound of 1, in which case it should never be empty? -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, October 15, 2010 3:35 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Operation with multiple return parameter You can certainly write self.returnResult()->isEmpty() in OCL even if the return result's upper bound is 1. "Ed Seidewitz" "Ed Seidewitz" 10/15/2010 03:27 PM To cc Subject RE: Operation with multiple return parameter I am also never quite sure how a multiplicity of 0..1 is to be represented in OCL typing. Semantically, a value with this multiplicity is supposed to be either the empty set of a set of one value -- which is what is returned by the returnResult operation: either the empty set or the set containing the single return parameter (note the use of the singular in the tense). My guess is that the return type of Set(Parameter) was intended to capture this. However, I think a return type of Parameter would also be OK (at least if we keep the restriction to only one return parameter), because I think OCL allows such a function to also return the empty set (though I feeling to lazy to check the OCL spec right now...). -- Ed -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Friday, October 15, 2010 3:19 PM To: uml2-rtf@omg.org Subject: RE: Operation with multiple return parameter Maged, > If we have this constraint in 7.3.37 Operation saying: > > [1] An operation can have at most one return parameter > (i.e., an owned parameter with the direction set to 'return'). > ownedParameter->select(par | par.direction = #return)->size() <= 1 > > why then do we declare the following query with a many > multipliclity? > > [2]The query returnResult() returns the set containing the > return parameter of the Operation if one exists; otherwise, > it returns an empty set. > Operation::returnResult() : Set(Parameter); > returnResult = ownedParameter->select (par | par.direction > = #return) It makes the spec more robust when someone decides to remove the constraint, which really shouldn't be there. There's no reason an operation can't return multiple values. Conrad From: "Bock, Conrad" To: "uml2-rtf@omg.org" Date: Fri, 15 Oct 2010 15:41:06 -0400 Subject: RE: Operation with multiple return parameter Thread-Topic: Operation with multiple return parameter Thread-Index: Actsn7IJuVYWyCMDT2KtMbMTMaQbiAAAD1ew Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov Maged, > "The parameter direction specifies whether its value is > passed into, out of, or both into and out of the owning behavioral > feature. A single parameter may be distinguished as a > return parameter. If the behavioral feature is an > operation, then the > type and multiplicity of this parameter is the same as the > type and multiplicity of the operation itself." > > This says that an operation can indeed have multiple output > parameters, but only a single one is distinguished as a > "return" parameter. Thx, I was confusing return with out. But the way the operation is written is more robust in not depending on the the parts of the spec you quote. In general using sets of values as OCL does insulates it from multiplicity decisions. Conrad Subject: RE: Operation with multiple return parameter To: "Ed Seidewitz" Cc: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Fri, 15 Oct 2010 15:51:19 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/15/2010 15:51:20 Sorry, I meant it to be returnResult() : Parameter [0..1] But in all cases, you can call any OCL collection operation on any attribute regardless of its multiplicity. "Ed Seidewitz" "Ed Seidewitz" 10/15/2010 03:39 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: Operation with multiple return parameter Yes, but does declaring returnResult():Parameter effectively mean that the return result also has the default lower bound of 1, in which case it should never be empty? -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, October 15, 2010 3:35 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Operation with multiple return parameter You can certainly write self.returnResult()->isEmpty() in OCL even if the return result's upper bound is 1. "Ed Seidewitz" "Ed Seidewitz" 10/15/2010 03:27 PM To cc Subject RE: Operation with multiple return parameter I am also never quite sure how a multiplicity of 0..1 is to be represented in OCL typing. Semantically, a value with this multiplicity is supposed to be either the empty set of a set of one value -- which is what is returned by the returnResult operation: either the empty set or the set containing the single return parameter (note the use of the singular in the tense). My guess is that the return type of Set(Parameter) was intended to capture this. However, I think a return type of Parameter would also be OK (at least if we keep the restriction to only one return parameter), because I think OCL allows such a function to also return the empty set (though I feeling to lazy to check the OCL spec right now...). -- Ed -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Friday, October 15, 2010 3:19 PM To: uml2-rtf@omg.org Subject: RE: Operation with multiple return parameter Maged, > If we have this constraint in 7.3.37 Operation saying: > > [1] An operation can have at most one return parameter > (i.e., an owned parameter with the direction set to 'return'). > ownedParameter->select(par | par.direction = #return)->size() <= 1 > > why then do we declare the following query with a many > multipliclity? > > [2]The query returnResult() returns the set containing the > return parameter of the Operation if one exists; otherwise, > it returns an empty set. > Operation::returnResult() : Set(Parameter); > returnResult = ownedParameter->select (par | par.direction > = #return) It makes the spec more robust when someone decides to remove the constraint, which really shouldn't be there. There's no reason an operation can't return multiple values. Conrad pic24484.gif Subject: RE: Operation with multiple return parameter Date: Fri, 15 Oct 2010 15:54:02 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Operation with multiple return parameter Thread-Index: ActsomgzylVCmwwsSReY9WFsECiDqgAACS7Q From: "Ed Seidewitz" To: "Maged Elaasar" Cc: But .Parameter[0..1]. is not legal OCL notation, while .Set(Parameter). is not legal UML multiplicity notation. So you need to decide which notation you are using for the operation signature. In any case, though, I think you are right about using OCL collection operations. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, October 15, 2010 3:51 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Operation with multiple return parameter Sorry, I meant it to be returnResult() : Parameter [0..1] But in all cases, you can call any OCL collection operation on any attribute regardless of its multiplicity. "Ed Seidewitz" "Ed Seidewitz" 10/15/2010 03:39 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: Operation with multiple return parameter Yes, but does declaring returnResult():Parameter effectively mean that the return result also has the default lower bound of 1, in which case it should never be empty? -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, October 15, 2010 3:35 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Operation with multiple return parameter You can certainly write self.returnResult()->isEmpty() in OCL even if the return result's upper bound is 1. "Ed Seidewitz" "Ed Seidewitz" 10/15/2010 03:27 PM To cc Subject RE: Operation with multiple return parameter I am also never quite sure how a multiplicity of 0..1 is to be represented in OCL typing. Semantically, a value with this multiplicity is supposed to be either the empty set of a set of one value -- which is what is returned by the returnResult operation: either the empty set or the set containing the single return parameter (note the use of the singular in the tense). My guess is that the return type of Set(Parameter) was intended to capture this. However, I think a return type of Parameter would also be OK (at least if we keep the restriction to only one return parameter), because I think OCL allows such a function to also return the empty set (though I feeling to lazy to check the OCL spec right now...). -- Ed -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Friday, October 15, 2010 3:19 PM To: uml2-rtf@omg.org Subject: RE: Operation with multiple return parameter Maged, > If we have this constraint in 7.3.37 Operation saying: > > [1] An operation can have at most one return parameter > (i.e., an owned parameter with the direction set to 'return'). > ownedParameter->select(par | par.direction = #return)->size() <= 1 > > why then do we declare the following query with a many > multipliclity? > > [2]The query returnResult() returns the set containing the > return parameter of the Operation if one exists; otherwise, > it returns an empty set. > Operation::returnResult() : Set(Parameter); > returnResult = ownedParameter->select (par | par.direction > = #return) It makes the spec more robust when someone decides to remove the constraint, which really shouldn't be there. There's no reason an operation can't return multiple values. Conrad Subject: RE: Operation with multiple return parameter To: "Ed Seidewitz" Cc: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Fri, 15 Oct 2010 16:11:30 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/15/2010 16:11:31 Ed, We are talking about an operation declared in the UML metamodel, so Operation::returnResult() : Parameter [0..1] is definitely valid UML notation. while Operation::returnResult() : Set(Parameter) which is the way it is now in spec is definitely not valid UML notation, it is supposed to be: Operation::returnResult() : Parameter [*] In both cases, the way OCL interprets the result of such opertion is similar to how it interprets any value, as a collection, and as such collection operations can be called on it. If we are going to leave this operation with * multiplicity to be more robust or OCL friendly, then at least we should be consistent in those other cases, where we have singular return result. OperationHasSingularReturnResult : 16 operation = UML::Vertex::containingStateMachine () : StateMachine operation = UML::Transition::redefinitionContext () : Classifier operation = UML::Transition::containingStateMachine () : StateMachine operation = UML::Stereotype::profile () : Profile operation = UML::Stereotype::containingProfile () : Profile operation = UML::StateMachine::LCA (s1 : State, s2 : State) : Namespace operation = UML::State::redefinitionContext () : Classifier operation = UML::State::containingStateMachine () : StateMachine operation = UML::Region::redefinitionContext () : Classifier operation = UML::Region::containingStateMachine () : StateMachine operation = UML::Property::opposite () : Property operation = UML::Package::containingProfile () : Profile [0..1] operation = UML::Operation::type () : Type operation = UML::LinkAction::association () : Association operation = UML::Extension::metaclassEnd () : Property operation = UML::Extension::metaclass () : Class "Ed Seidewitz" "Ed Seidewitz" 10/15/2010 03:54 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: Operation with multiple return parameter But .Parameter[0..1]. is not legal OCL notation, while .Set(Parameter). is not legal UML multiplicity notation. So you need to decide which notation you are using for the operation signature. In any case, though, I think you are right about using OCL collection operations. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, October 15, 2010 3:51 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Operation with multiple return parameter Sorry, I meant it to be returnResult() : Parameter [0..1] But in all cases, you can call any OCL collection operation on any attribute regardless of its multiplicity. "Ed Seidewitz" "Ed Seidewitz" 10/15/2010 03:39 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: Operation with multiple return parameter Yes, but does declaring returnResult():Parameter effectively mean that the return result also has the default lower bound of 1, in which case it should never be empty? -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, October 15, 2010 3:35 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Operation with multiple return parameter You can certainly write self.returnResult()->isEmpty() in OCL even if the return result's upper bound is 1. "Ed Seidewitz" "Ed Seidewitz" 10/15/2010 03:27 PM To cc Subject RE: Operation with multiple return parameter I am also never quite sure how a multiplicity of 0..1 is to be represented in OCL typing. Semantically, a value with this multiplicity is supposed to be either the empty set of a set of one value -- which is what is returned by the returnResult operation: either the empty set or the set containing the single return parameter (note the use of the singular in the tense). My guess is that the return type of Set(Parameter) was intended to capture this. However, I think a return type of Parameter would also be OK (at least if we keep the restriction to only one return parameter), because I think OCL allows such a function to also return the empty set (though I feeling to lazy to check the OCL spec right now...). -- Ed -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Friday, October 15, 2010 3:19 PM To: uml2-rtf@omg.org Subject: RE: Operation with multiple return parameter Maged, > If we have this constraint in 7.3.37 Operation saying: > > [1] An operation can have at most one return parameter > (i.e., an owned parameter with the direction set to 'return'). > ownedParameter->select(par | par.direction = #return)->size() <= 1 > > why then do we declare the following query with a many > multipliclity? > > [2]The query returnResult() returns the set containing the > return parameter of the Operation if one exists; otherwise, > it returns an empty set. > Operation::returnResult() : Set(Parameter); > returnResult = ownedParameter->select (par | par.direction > = #return) It makes the spec more robust when someone decides to remove the constraint, which really shouldn't be there. There's no reason an operation can't return multiple values. Conrad pic09302.gif Subject: RE: Operation with multiple return parameter Date: Fri, 15 Oct 2010 16:19:36 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Operation with multiple return parameter Thread-Index: ActspVPwZCjDBn04RiuzS4jGVBHQXQAAMEBA From: "Ed Seidewitz" To: "Maged Elaasar" Cc: Well, the signatures for operations in the spec document have traditionally been given using OCL notation (though usually somewhat loosely). Anyway, we can probably address this in UML 2.5, if we think it is important enough. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, October 15, 2010 4:12 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Operation with multiple return parameter Ed, We are talking about an operation declared in the UML metamodel, so Operation::returnResult() : Parameter [0..1] is definitely valid UML notation. while Operation::returnResult() : Set(Parameter) which is the way it is now in spec is definitely not valid UML notation, it is supposed to be: Operation::returnResult() : Parameter [*] In both cases, the way OCL interprets the result of such opertion is similar to how it interprets any value, as a collection, and as such collection operations can be called on it. If we are going to leave this operation with * multiplicity to be more robust or OCL friendly, then at least we should be consistent in those other cases, where we have singular return result. OperationHasSingularReturnResult : 16 operation = UML::Vertex::containingStateMachine () : StateMachine operation = UML::Transition::redefinitionContext () : Classifier operation = UML::Transition::containingStateMachine () : StateMachine operation = UML::Stereotype::profile () : Profile operation = UML::Stereotype::containingProfile () : Profile operation = UML::StateMachine::LCA (s1 : State, s2 : State) : Namespace operation = UML::State::redefinitionContext () : Classifier operation = UML::State::containingStateMachine () : StateMachine operation = UML::Region::redefinitionContext () : Classifier operation = UML::Region::containingStateMachine () : StateMachine operation = UML::Property::opposite () : Property operation = UML::Package::containingProfile () : Profile [0..1] operation = UML::Operation::type () : Type operation = UML::LinkAction::association () : Association operation = UML::Extension::metaclassEnd () : Property operation = UML::Extension::metaclass () : Class "Ed Seidewitz" "Ed Seidewitz" 10/15/2010 03:54 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: Operation with multiple return parameter But .Parameter[0..1]. is not legal OCL notation, while .Set(Parameter). is not legal UML multiplicity notation. So you need to decide which notation you are using for the operation signature. In any case, though, I think you are right about using OCL collection operations. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, October 15, 2010 3:51 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Operation with multiple return parameter Sorry, I meant it to be returnResult() : Parameter [0..1] But in all cases, you can call any OCL collection operation on any attribute regardless of its multiplicity. "Ed Seidewitz" "Ed Seidewitz" 10/15/2010 03:39 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: Operation with multiple return parameter Yes, but does declaring returnResult():Parameter effectively mean that the return result also has the default lower bound of 1, in which case it should never be empty? -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, October 15, 2010 3:35 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Operation with multiple return parameter You can certainly write self.returnResult()->isEmpty() in OCL even if the return result's upper bound is 1. "Ed Seidewitz" "Ed Seidewitz" 10/15/2010 03:27 PM To cc Subject RE: Operation with multiple return parameter I am also never quite sure how a multiplicity of 0..1 is to be represented in OCL typing. Semantically, a value with this multiplicity is supposed to be either the empty set of a set of one value -- which is what is returned by the returnResult operation: either the empty set or the set containing the single return parameter (note the use of the singular in the tense). My guess is that the return type of Set(Parameter) was intended to capture this. However, I think a return type of Parameter would also be OK (at least if we keep the restriction to only one return parameter), because I think OCL allows such a function to also return the empty set (though I feeling to lazy to check the OCL spec right now...). -- Ed -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Friday, October 15, 2010 3:19 PM To: uml2-rtf@omg.org Subject: RE: Operation with multiple return parameter Maged, > If we have this constraint in 7.3.37 Operation saying: > > [1] An operation can have at most one return parameter > (i.e., an owned parameter with the direction set to 'return'). > ownedParameter->select(par | par.direction = #return)->size() <= 1 > > why then do we declare the following query with a many > multipliclity? > > [2]The query returnResult() returns the set containing the > return parameter of the Operation if one exists; otherwise, > it returns an empty set. > Operation::returnResult() : Set(Parameter); > returnResult = ownedParameter->select (par | par.direction > = #return) It makes the spec more robust when someone decides to remove the constraint, which really shouldn't be there. There's no reason an operation can't return multiple values. Conrad Date: Fri, 15 Oct 2010 21:04:43 -0400 From: "Chonoles, Michael J" Subject: RE: Operation with multiple return parameter To: Ed Seidewitz , Maged Elaasar Cc: "uml2-rtf@omg.org" Thread-Topic: Operation with multiple return parameter Thread-Index: ActspVPwZCjDBn04RiuzS4jGVBHQXQAAMEBAAAmxdnA= Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-15_11:2010-10-15,2010-10-15,1970-01-01 signatures=0 I don.t see why an operation can.t have multiple return parameters. In some languages if there were multiple values returned, it would be difficult to pick one as the return. For example in Scheme, consider the following function defined in scheme (though I really don.t know Scheme) (define quotient-and-remainder-values (lambda (n d) (values (quotient n d) (remainder n d)))) It would be used (let-values ([(q r) (quotient-and-remainder-values n d)]) I don.t see any reasonable way of determining that Q is the return value R is a output value . they both seem to be equally a return value. Michael From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Friday, October 15, 2010 4:20 PM To: Maged Elaasar Cc: uml2-rtf@omg.org Subject: EXTERNAL: RE: Operation with multiple return parameter Well, the signatures for operations in the spec document have traditionally been given using OCL notation (though usually somewhat loosely). Anyway, we can probably address this in UML 2.5, if we think it is important enough. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, October 15, 2010 4:12 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Operation with multiple return parameter Ed, We are talking about an operation declared in the UML metamodel, so Operation::returnResult() : Parameter [0..1] is definitely valid UML notation. while Operation::returnResult() : Set(Parameter) which is the way it is now in spec is definitely not valid UML notation, it is supposed to be: Operation::returnResult() : Parameter [*] In both cases, the way OCL interprets the result of such opertion is similar to how it interprets any value, as a collection, and as such collection operations can be called on it. If we are going to leave this operation with * multiplicity to be more robust or OCL friendly, then at least we should be consistent in those other cases, where we have singular return result. OperationHasSingularReturnResult : 16 operation = UML::Vertex::containingStateMachine () : StateMachine operation = UML::Transition::redefinitionContext () : Classifier operation = UML::Transition::containingStateMachine () : StateMachine operation = UML::Stereotype::profile () : Profile operation = UML::Stereotype::containingProfile () : Profile operation = UML::StateMachine::LCA (s1 : State, s2 : State) : Namespace operation = UML::State::redefinitionContext () : Classifier operation = UML::State::containingStateMachine () : StateMachine operation = UML::Region::redefinitionContext () : Classifier operation = UML::Region::containingStateMachine () : StateMachine operation = UML::Property::opposite () : Property operation = UML::Package::containingProfile () : Profile [0..1] operation = UML::Operation::type () : Type operation = UML::LinkAction::association () : Association operation = UML::Extension::metaclassEnd () : Property operation = UML::Extension::metaclass () : Class "Ed Seidewitz" "Ed Seidewitz" 10/15/2010 03:54 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: Operation with multiple return parameter But .Parameter[0..1]. is not legal OCL notation, while .Set(Parameter). is not legal UML multiplicity notation. So you need to decide which notation you are using for the operation signature. In any case, though, I think you are right about using OCL collection operations. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, October 15, 2010 3:51 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Operation with multiple return parameter Sorry, I meant it to be returnResult() : Parameter [0..1] But in all cases, you can call any OCL collection operation on any attribute regardless of its multiplicity. "Ed Seidewitz" "Ed Seidewitz" 10/15/2010 03:39 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: Operation with multiple return parameter Yes, but does declaring returnResult():Parameter effectively mean that the return result also has the default lower bound of 1, in which case it should never be empty? -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Friday, October 15, 2010 3:35 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Operation with multiple return parameter You can certainly write self.returnResult()->isEmpty() in OCL even if the return result's upper bound is 1. "Ed Seidewitz" "Ed Seidewitz" 10/15/2010 03:27 PM To cc Subject RE: Operation with multiple return parameter I am also never quite sure how a multiplicity of 0..1 is to be represented in OCL typing. Semantically, a value with this multiplicity is supposed to be either the empty set of a set of one value -- which is what is returned by the returnResult operation: either the empty set or the set containing the single return parameter (note the use of the singular in the tense). My guess is that the return type of Set(Parameter) was intended to capture this. However, I think a return type of Parameter would also be OK (at least if we keep the restriction to only one return parameter), because I think OCL allows such a function to also return the empty set (though I feeling to lazy to check the OCL spec right now...). -- Ed -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Friday, October 15, 2010 3:19 PM To: uml2-rtf@omg.org Subject: RE: Operation with multiple return parameter Maged, > If we have this constraint in 7.3.37 Operation saying: > > [1] An operation can have at most one return parameter > (i.e., an owned parameter with the direction set to 'return'). > ownedParameter->select(par | par.direction = #return)->size() <= 1 > > why then do we declare the following query with a many > multipliclity? > > [2]The query returnResult() returns the set containing the > return parameter of the Operation if one exists; otherwise, > it returns an empty set. > Operation::returnResult() : Set(Parameter); > returnResult = ownedParameter->select (par | par.direction > = #return) It makes the spec more robust when someone decides to remove the constraint, which really shouldn't be there. There's no reason an operation can't return multiple values. Conrad X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 19 Oct 2010 14:19:54 -0400 To: Maged Elaasar , uml2-rtf@omg.org From: Juergen Boldt Subject: Re: Operation with multiple return parameter is this an issue or discussion? -Juergen At 03:01 PM 10/15/2010, Maged Elaasar wrote: Hi All, If we have this constraint in 7.3.37 Operation saying: [1] An operation can have at most one return parameter (i.e., an owned parameter with the direction set to .return.). ownedParameter->select(par | par.direction = #return)->size() <= 1 why then do we declare the following query with a many multipliclity? [2]The query returnResult() returns the set containing the return parameter of the Operation if one exists; otherwise, it returns an empty set. Operation::returnResult() : Set(Parameter); returnResult = ownedParameter->select (par | par.direction = #return) it should be: Operation::returnResult() : Parameter; Maged Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Subject: Fw: Operation with multiple return parameter To: Juergen Boldt X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Thu, 21 Oct 2010 14:33:03 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 10/21/2010 14:33:04 This one too please... We are talking about an operation declared in the UML metamodel, so Operation::returnResult() : Parameter [0..1] is definitely valid UML notation. while Operation::returnResult() : Set(Parameter) which is the way it is now in spec is definitely not valid UML notation, it is supposed to be: Operation::returnResult() : Parameter [*] In both cases, the way OCL interprets the result of such opertion is similar to how it interprets any value, as a collection, and as such collection operations can be called on it. Therefore, to be consistent, this operation should be changed have a simple "Parameter" as a return type. However, if we are going to leave this operation with * multiplicity to be more robust or OCL friendly, then at least we should be consistent in those other cases, where we have singular return result. OperationHasSingularReturnResult : 16 operation = UML::Vertex::containingStateMachine () : StateMachine operation = UML::Transition::redefinitionContext () : Classifier operation = UML::Transition::containingStateMachine () : StateMachine operation = UML::Stereotype::profile () : Profile operation = UML::Stereotype::containingProfile () : Profile operation = UML::StateMachine::LCA (s1 : State, s2 : State) : Namespace operation = UML::State::redefinitionContext () : Classifier operation = UML::State::containingStateMachine () : StateMachine operation = UML::Region::redefinitionContext () : Classifier operation = UML::Region::containingStateMachine () : StateMachine operation = UML::Property::opposite () : Property operation = UML::Package::containingProfile () : Profile [0..1] operation = UML::Operation::type () : Type operation = UML::LinkAction::association () : Association operation = UML::Extension::metaclassEnd () : Property operation = UML::Extension::metaclass () : Class