Issue 15100: VSL - Absence of rule for calling behaviors (marte-rtf) Source: Commissariat a l Energie Atomique-CEA (Dr. Arnaud Cuccuru, arnaud.cuccuru(at)cea.fr) Nature: Clarification Severity: Minor Summary: VSL doest not provide a rule for expressing behavior calls (i.e., it only supports call of operations). Since Behaviors are first class citizen of UML2, there is no fundamental reason for preventing this kind of expressions. Integrating a rule for calling behaviors does not require much effort (cf. following proposed resolution). Proposed resolution: - Modify text of B2.4 p.431 (p.443 of the pdf) Between paragraph starting with “An Operation Call Expression…” and paragraph starting with “This metamodel does not define…”, insert the following paragraph: A Behavior Call Expression refers to a behavior defined in a UML Namespace. The expression may contain a list of argument expressions if the behavior is defined to have parameters. In this case, the number and types of the arguments must match the parameters. - Modify figure B.4 p.432 (p.444 of the pdf) as follows: . Add a class BehaviorCallExpression, and a generalization relationship between this class and Expression . Add a composition relationship between BehaviorCallExpression and ValueSpecification, identical to the composition relationship between OperationCallExpression and ValueSpecification (this is to capture the arguments of the call) . On the diagram, add an abstract class Behavior, with a grey background like classes Property and Operation. . Add an association between BehaviorCallExpression and Behavior, identical to the association between PropertyCallExpression and Property, except that the name of the role should : definingBehavior . Add the following derived property to BehaviorCallExpression: /behavior:String - In section B.3.3.13: Replace: <expression> ::= <variable-call-expr> | <variable-declaration> | <property-callexpr> | <operation-call-expr> | <conditional-expr> By: <expression> ::= <variable-call-expr> | <variable-declaration> | <property-callexpr> | <operation-call-expr> | <behavior-call-expr> | <conditional-expr> - p.453 (p.465 of the pdf), insert the following section (and increment the number of remaining sections): // Beginning of section B.3.3.17 Behavior Call Expressions Behavior calls are particularly used in the MARTE context to call behaviors taking data type values as parameters. <behavior-call-expr> ::= <behavior-name> '('[ <argument-value> [','<argument-value>]* ]')’ <behavior-name> ::= [<namespace> '.'] <body-text> <namespace> ::= <body-text> Expression typing • The <behavior-call-expr> production rule should be evaluated to the type of the UML::Behavior that is called. • The <argument-value> production rule must be evaluated to the corresponding to UML::Parameter's type of an existing UML::Parameter owned by the UML::Behavior. Abstract syntax mapping • The <behavior-call-expr> production rule maps to the BehaviorCallExpression domain element described in Annex F (Section F.13.XX). Disambiguating rules • <behavior-name> should correspond to an existing UML::Behavior name. //end of section - In annex F, insert a section F.13.1 as follows (and increment of remaining sections): // beginning of section F.13.1 BehaviorCallExpression (from Expressions) Generalizations • Expression (from Expressions) on page 560 Associations • definingBehavior: Causality::CommonBehavior::Behavior [1] Called Behavior. • argument: VSL::ValueSpecification [*] {ordered} Arguments of the Operation Call. Attributes • /behavior: String [1] String with the qualified name of the called Behavior. This is a derived value obtained from the definingBehavior. Semantics A Behavior Call Expression refers to a behavior defined in a UML Namespace. The expression may contain a list of argument expressions if the behavior is defined to have parameters. In this case, the number and types of the arguments must match the parameters. // end of section Resolution: The absence of rules for calling behaviors indeed introduces an artificial limitation to the applicability of VSL. Concretely, all the available behavior signatures are currently defined following the object-oriented paradigm, in the form of operations (e.g., String.concat(String)), belonging to data types of the standard MARTE libraries. These behavior signatures could alternatively be defined following a procedural style (e.g. concat(String,String)). Designers who are familiar with procedural languages would probably feel more comfortable with this approach. Since UML natively offers support for describing behavior signatures in the procedural style, VSL should not prevent the usage of this kind of behaviors, and a rule should be added to support call of behaviors. The following figure illustrates the differences between the two paradigms, from both the perspective of libraries definitions (left hand side of the figure) and the perspective of usage in VSL (right hand side of the figure). Revised Text: see pages 148 - 150 of ptc/2010-08-30 for revised text Actions taken: March 1, 2010: received issue January 14, 2011: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 01 Mar 2010 07:51:10 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Arnaud Cuccuru Company: CEA LIST mailFrom: arnaud.cuccuru@cea.fr Notification: Yes Specification: MARTE Section: B.2.4 / B.3.3.13 / F.13 FormalNumber: formal/2009-11-02 Version: 1.0 RevisionDate: November 2009 Page: 431, 432, 453 Title: VSL - Absence of rule for calling behaviors Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: VSL doest not provide a rule for expressing behavior calls (i.e., it only supports call of operations). Since Behaviors are first class citizen of UML2, there is no fundamental reason for preventing this kind of expressions. Integrating a rule for calling behaviors does not require much effort (cf. following proposed resolution). Proposed resolution: - Modify text of B2.4 p.431 (p.443 of the pdf) Between paragraph starting with .An Operation Call Expression.. and paragraph starting with .This metamodel does not define.., insert the following paragraph: A Behavior Call Expression refers to a behavior defined in a UML Namespace. The expression may contain a list of argument expressions if the behavior is defined to have parameters. In this case, the number and types of the arguments must match the parameters. - Modify figure B.4 p.432 (p.444 of the pdf) as follows: . Add a class BehaviorCallExpression, and a generalization relationship between this class and Expression . Add a composition relationship between BehaviorCallExpression and ValueSpecification, identical to the composition relationship between OperationCallExpression and ValueSpecification (this is to capture the arguments of the call) . On the diagram, add an abstract class Behavior, with a grey background like classes Property and Operation. . Add an association between BehaviorCallExpression and Behavior, identical to the association between PropertyCallExpression and Property, except that the name of the role should : definingBehavior . Add the following derived property to BehaviorCallExpression: /behavior:String - In section B.3.3.13: Replace: ::= | | | | By: ::= | | | | | - p.453 (p.465 of the pdf), insert the following section (and increment the number of remaining sections): // Beginning of section B.3.3.17 Behavior Call Expressions Behavior calls are particularly used in the MARTE context to call behaviors taking data type values as parameters. ::= '('[ [',']* ]'). ::= [ '.'] ::= Expression typing . The production rule should be evaluated to the type of the UML::Behavior that is called. . The production rule must be evaluated to the corresponding to UML::Parameter's type of an existing UML::Parameter owned by the UML::Behavior. Abstract syntax mapping . The production rule maps to the BehaviorCallExpression domain element described in Annex F (Section F.13.XX). Disambiguating rules . should correspond to an existing UML::Behavior name. //end of section - In annex F, insert a section F.13.1 as follows (and increment of remaining sections): // beginning of section F.13.1 BehaviorCallExpression (from Expressions) Generalizations . Expression (from Expressions) on page 560 Associations . definingBehavior: Causality::CommonBehavior::Behavior [1] Called Behavior. . argument: VSL::ValueSpecification [*] {ordered} Arguments of the Operation Call. Attributes . /behavior: String [1] String with the qualified name of the called Behavior. This is a derived value obtained from the definingBehavior. Semantics A Behavior Call Expression refers to a behavior defined in a UML Namespace. The expression may contain a list of argument expressions if the behavior is defined to have parameters. In this case, the number and types of the arguments must match the parameters. Subject: TR: Resolution proposals for VSL issue 15100 Date: Mon, 8 Mar 2010 11:06:46 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resolution proposals for VSL issue 15100 Thread-Index: Acq7obJc8sOhcYTRQ3yET2mPlSsptQAACNagAMD5YCA= From: "CUCCURU Arnaud" To: Cc: "Huascar Espinoza" , Séstien Demathieu , "MRAIDHA Chokri 176997" , "Adrian Noguero" X-OriginalArrivalTime: 08 Mar 2010 10:06:46.0549 (UTC) FILETIME=[0FB00450:01CABEA7] Dear colleagues, I forward you some preliminary discussions we had with Huascar and Sebastien regarding issue 15100 and the draft resolution proposal I have already disseminated on the list. You.ll find in the discussion some complementary information which is probably useful to motivate the introduction of a mechanism for expressing behavior calls in VSL expressions. Opinions are welcome. Cheers, Arnaud -------------------------------------------------------------------------------- De : CUCCURU Arnaud Envoyé jeudi 4 mars 2010 15:34 À: 'Séstien Demathieu'; Huascar Espinoza Cc : MRAIDHA Chokri 176997; Adrian Noguero Objet : RE: Resolution proposals for VSL issues 15096, 15097, 15098, 15099, 15100 Regarding the parser, here is preliminary answer. The rule of OperationCallExpression is as follows: ::= ( '.' '('[ [',']* ]')') | ( | '(' ')' ) ::= ::= As far as I understand the rule (and if I omit the alternatives for infix notation), the value specification (depicting the object on which the operation must be called) is mandatory, as well as the .... I think that these two elements are enough to distinguish between OperationCallExpression and BehaviorCallExpression. Here is a completed version of the example. On the left hand side, the value of property p is specified using an OperationCallExpression. In the right hand side, it is specified using a BehaviorCallExpression (without or with a namespace prefix). Arnaud -------------------------------------------------------------------------------- De : Séstien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé jeudi 4 mars 2010 14:51 À: Huascar Espinoza; CUCCURU Arnaud Cc : MRAIDHA Chokri 176997; Adrian Noguero Objet : Re: Resolution proposals for VSL issues 15096, 15097, 15098, 15099, 15100 Also, it would be useful to understand how a parser could distinguish a BehaviorCallExperession from an OperationCallExpression. We currently have an ambiguity between PropertyCallExpression and VariableCallExpression, which gives us a hard time implementing parsers. If a new CallExpression is introduced we need to find a way to make it unambiguous. Séstien Huascar Espinoza a éit : Converging, converging Could you please complete your example with a VSL expression and its context (where it is specified) as well as a description on how the parser will unambiguosly know that the associated behavior is the specified below? Thanks! Huascar -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: jueves, 04 de marzo de 2010 14:17 To: Huascar Espinoza Cc: Séstien Demathieu; MRAIDHA Chokri 176997; Adrian Noguero Subject: RE: Resolution proposals for VSL issues 15096, 15097, 15098, 15099, 15100 .The example you mentionned below is motivated by a syntactic issue (right?). I cannot see another need beyong this in your discourse. No, the main motivation is not syntactic. This is related to two completely different paradigms. The current version of the VSL grammar makes strong hypothesis about the way behavior signatures need to be defined. Behavior signatures must be defined as operations on data types. This is the usual object-oriented way of defining behavior signatures. The current MARTE_data_types_library is consistent with this vision. In the extensions I propose, I have in mind that behavior signatures can also be defined in a procedural style. The fundamental difference between the two approaches is depicted in the figure below. VSL currently only supports the Object-Oriented vision. What I was saying in my proposition (and I don.t know if it is a sufficient argument for a revision) is that this limitation is artificial. I don.t know if adding support for BehaviorCallExpr can resolve your other issue. What is sure is that defining Type libraries (and associated behavior signatures) following the procedural vision can help you to limit the coupling between type definitions and behavior signature definitions (since signatures are no longer captured as operations of data types). Not that the two approaches are not mutually exclusive. I mean that you can define what you consider the most usual behaviors as operations on data types (OO style), and then leave the door open to extensibility by allowing the definitions of function libraries following the procedural style (which would not imply modifications of the original Type library). .The other motivation you mentionned, honestly, does not seem strong enought to add new complexity to MARTE and VSL. To be more direct, I am working in the context of a project where we need a typed expression language (such as VSL). I had in mind VSL, but I concretely can.t use it for the moment, due to the fact that it makes Object-Oriented assumptions (which are, to me, unnecessary). Arnaud CUCCURU CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Tel : + 33 1 69 08 49 61 Fax : + 33 1 69 08 20 82 -------------------------------------------------------------------------------- De : Huascar Espinoza [mailto:Huascar.Espinoza@esi.es] Envoyé jeudi 4 mars 2010 12:43 À: CUCCURU Arnaud Cc : Séstien Demathieu; MRAIDHA Chokri 176997; Adrian Noguero Objet : RE: Resolution proposals for VSL issues 15096, 15097, 15098, 15099, 15100 Arnaud, merci. I include Seb D. and Chokri as I guess that we can bring some preliminary resolution before brodcasting ideas to the mailing list. The example you mentionned below is motivated by a syntactic issue (right?). I cannot see another need beyong this in your discourse. We were discussing a related issue with Seb. D. and Chokri during the last RTF. In a few words: 1- VSL should support expressions of different math. functions (that need to be extended, as required). We solved this by using the OperationCallExpr as illustrated at the end of Annex B. 2- However, to do so, we created new Operations in the MARTE data types (e.g.; diff for derivatives). This means that if we want to create new library functions, we are forced to modify this library. 3- A more strainghforward approach would be to let declare new functions in libraries WITHOUT modifying the core MARTE (primitive) data types. 4- One proposal (by Seb. D.) was to use Behaviors and BehaviorCallExpr. 5- The problem is that we didn't find a good solution that solves (4) with that approach. --> The question is if you can find a solution now, with the new constructs you propose. The other motivation you mentionned, honestly, does not seem strong enought to add new complexity to MARTE and VSL. Let me know. Regards, Huascar -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: jueves, 04 de marzo de 2010 12:14 To: Huascar Espinoza Subject: RE: Resolution proposals for VSL issues 15096, 15097, 15098, 15099, 15100 Exemple : Admettons que tu veuilles valuer une proprié p de type String appartenant àne classe A. Admettons que A possè élement deux variables v1 et v2 de type String. Admettons que tu souhaites que p ait pour valeur par déut la concatétion de v1 et v2 OO Style : Avec un call operation expression, l.expression VSL ressemblerait à v1.concat(v2) , avec pour hypothè que le DataType String possè une opétion ayant pour signature : concat(String) : String Procedural Style : Avec un call behavior expression, l.expression VSL ressemblerait à concat(v1,v2) , avec pour hypothè qu.il existe un behavior (e.g., une activity ou un opaqueBehavior) dénie dans un namespace visible depuis A, ayant pour signature : concat (String, String) : String Dis-moi si l.exemple n.est pas clair. ++ Arnaud -------------------------------------------------------------------------------- De : Huascar Espinoza [mailto:Huascar.Espinoza@esi.es] Envoyé jeudi 4 mars 2010 11:56 À: CUCCURU Arnaud Objet : RE: Resolution proposals for VSL issues 15096, 15097, 15098, 15099, 15100 Salut Arnauld, As tu un example (15100 )? Merci. Huascar -------------------------------------------------------------------------------- From: CUCCURU Arnaud [mailto:arnaud.cuccuru@cea.fr] Sent: miéoles, 03 de marzo de 2010 18:29 To: marte-rtf@omg.org Cc: ESPINOZA Huascar 218344 Subject: Resolution proposals for VSL issues 15096, 15097, 15098, 15099, 15100 Dear colleagues, This week, I have raised five issues related to VSL. After synchronization with Huascar, I have added the issues to the Annex B WG of the wiki. In attachment, you.ll find some resolution proposals for these issues, and I would be happy to get your feedbacks: - 15096: The issue is clearly related to a bad copy paste, and should not raise much discussions - 15097 and 15098: These issues concern propositions that, to me, would make the VSL syntax clearer. These are just proposals, and I will not fight for them - 15099: This one should be closed without changes (I have submitted the issue too quickly. sorry for the inconvenience) I think that 15100 is however quite important. It is related to the fact that the grammar of VSL does not allow for calling behaviors (i.e., it only allows operation calls). To me, the absence of rules for calling behaviors indeed introduces an artificial limitation to the applicability of VSL. Concretely, all the available behavior signatures (that can be manipulated in the context of VSL expressions) must currently be defined following the object-oriented paradigm, in the form of operations (e.g., String.concat(String)), belonging to data types of (e.g.) the MARTE_primitive_types library. These behavior signatures could alternatively be defined following a procedural style (e.g. concat(String,String)). Designers how are familiar with procedural languages would probably feel more comfortable with this approach. Since UML natively offers support for describing behavior signatures in the procedural style (e.g., with activities or opaque behaviors), VSL should not prevent the usage of this kind of behaviors, and a rule should be added to support call of behaviors. Arnaud CUCCURU CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Tel : + 33 1 69 08 49 61 Fax : + 33 1 69 08 20 82 ************************************ DISCLAIMER ***************************************** This message may contain confidential, proprietary or legally privileged information. If you are not the intended recipient of this message, please notify it to the sender and delete without resending or backing it, as it is legally prohibited. ************************************* AVISO LEGAL **************************************** Este mensaje puede contener informacióonfidencial, en propiedad o legalmente protegida. Si usted no es el destinatario, le rogamos lo comunique al remitente y proceda a borrarlo, sin reenviarlo ni conservarlo, ya que su uso no autorizado estárohibido legalmente. ***************************************************************************************** ************************************ DISCLAIMER ***************************************** This message may contain confidential, proprietary or legally privileged information. If you are not the intended recipient of this message, please notify it to the sender and delete without resending or backing it, as it is legally prohibited. ************************************* AVISO LEGAL **************************************** Este mensaje puede contener informacióonfidencial, en propiedad o legalmente protegida. Si usted no es el destinatario, le rogamos lo comunique al remitente y proceda a borrarlo, sin reenviarlo ni conservarlo, ya que su uso no autorizado estárohibido legalmente. ***************************************************************************************** ************************************ DISCLAIMER ***************************************** This message may contain confidential, proprietary or legally privileged information. If you are not the intended recipient of this message, please notify it to the sender and delete without resending or backing it, as it is legally prohibited. ************************************* AVISO LEGAL **************************************** Este mensaje puede contener informacióonfidencial, en propiedad o legalmente protegida. Si usted no es el destinatario, le rogamos lo comunique al remitente y proceda a borrarlo, sin reenviarlo ni conservarlo, ya que su uso no autorizado estárohibido legalmente. ***************************************************************************************** oledata2.mso // end of section