Issue 6150: Notation for method (uml2-rtf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Significant Summary: Provide a notation for a behavior used as a method of an operation Resolution: Disposition: Deferred to UML 2.4 RTF Revised Text: Actions taken: August 30, 2003: received issue Discussion: OMG Issue No: 6150 NIST (Mr. Conrad Bock, conrad.bock@nist.gov conradb@cme.nist.gov) It is probably worthwhile to define a graphical syntax representing BehavioralFeature.method. This could take the form of either • showing the name of the instance of Behavior which is the method along in the compartment where the behavioral feature is exhibited • having a graphical link between the behavioral feature and a symbol representing the behavior instance (similar to how it is shown that a CollaborationOccurrence represents a Classifier (see Figure 106). The downside of either is that users typically don’t think of the behavioral feature and the behavior as separate things and usually would not dream of naming the behavior (of course, this is not required). In particular, if the behavior is described by a body string a convenient way of showing that body string with the behavioral feature would be desired. Today tools typically use the property sheet for the behavioral feature to show the associated behavior. There are already different vendor specific solutions for some behaviors as methods. We need to gain better experience before standardizing as solution. Disposition: Deferred It is probably worthwhile to define a graphical syntax representing BehavioralFeature.method. This could take the form of either . showing the name of the instance of Behavior which is the method along in the compartment where the behavioral feature is exhibited . having a graphical link between the behavioral feature and a symbol representing the behavior instance (similar to how it is shown that a CollaborationOccurrence represents a Classifier (see Figure 106). The downside of either is that users typically don.t think of the behavioral feature and the behavior as separate things and usually would not dream of naming the behavior (of course, this is not required). In particular, if the behavior is described by a body string a convenient way of showing that body string with the behavioral feature would be desired. Today tools typically use the property sheet for the behavioral feature to show the associated behavior. There are already different vendor specific solutions for some behaviors as methods. We need to gain better experience before standardizing as solution. The situation has not changed from the discussion in 2003. There have been no new developments in tool specific notations for method, nor have there been further requests for such notation. However, the issue seems still relevant. Therefore, the suggestion is to defer further. Revised Text: N/A Disposition: Deferred End of Annotations:===== Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Nature: Revision Severity: Significant Subject: Notation for method Provide a notation for a behavior used as a method of an operation. Reply-To: From: "Thomas Weigert" To: "Branislav Selic" , Cc: "Thomas Weigert" Subject: Proposed issue resolution for common behavior and composite structure working groups Date: Sat, 29 Nov 2003 19:55:36 -0600 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal Dear all, please find attached two documents discussing the issues assigned to the common behavior and composite structure working group, respectively. Each document has a summary page indicating the proposed action. Most issues do not require any change, as the UML 2.0 most often has already resolved the issue. There are 2 proposed changes for common behavior and one proposed change for composite structure, all minor. Regarding common behavior there are three issues (6148, 6149, and 6150) which I propose for discussion. While they would not require any change as the solution in the document is as was intended, the issues nevertheless could be addressed: 1. 6148 and 6149 implicitly propose an alternative means of showing textually defined behavior as associated with the Behavior metaclass and making that metaclass concrete. This is as good a solution as the one currently implemented; in my opinion a matter of taste. 2. 6150 requests a notation for method which is reasonable but should be decided upon by teamwork (as nobody ever is satisfied with notation). Please provide feedback on the proposed solution and also provide input to the issues labeled as for discussion. I will propose solutions for those after I have heard from at least several others on the FTF. All the best, Th. Common behavior issues resolution.doc OMG Issue No: 6150 Title: Notation for method Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Provide a notation for a behavior used as a method of an operation Discussion: It is probably worthwhile to define a graphical syntax representing BehavioralFeature.method. This could take the form of either · showing the name of the instance of Behavior which is the method along in the compartment where the behavioral feature is exhibited · having a graphical link between the behavioral feature and a symbol representing the behavior instance (similar to how it is shown that a CollaborationOccurrence represents a Classifier (see Figure 106). The downside of either is that users typically don.t think of the behavioral feature and the behavior as separate things and usually would not dream of naming the behavior (of course, this is not required). In particular, if the behavior is described by a body string a convenient way of showing that body string with the behavioral feature would be desired. Today tools typically use the property sheet for the behavioral feature to show the associated behavior. There are already different vendor specific solutions for some behaviors as methods. We need to gain better experience before standardizing as solution. Disposition: Defer OMG Issue No: 6150 Title: Notation for method Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Provide a notation for a behavior used as a method of an operation Discussion: It is probably worthwhile to define a graphical syntax representing BehavioralFeature.method. This could take the form of either · showing the name of the instance of Behavior which is the method along in the compartment where the behavioral feature is exhibited · having a graphical link between the behavioral feature and a symbol representing the behavior instance (similar to how it is shown that a CollaborationOccurrence represents a Classifier (see Figure 106). The downside of either is that users typically don.t think of the behavioral feature and the behavior as separate things and usually would not dream of naming the behavior (of course, this is not required). In particular, if the behavior is described by a body string a convenient way of showing that body string with the behavioral feature would be desired. Today tools typically use the property sheet for the behavioral feature to show the associated behavior. There are already different vendor specific solutions for some behaviors as methods. We need to gain better experience before standardizing as solution. Disposition: Defer To: "Thomas Weigert" Cc: uml2-rtf@omg.org Subject: Issue 6150: Notation for method X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Tue, 17 May 2005 09:47:21 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.5.4|March 27, 2005) at 05/17/2005 07:47:30, Serialize complete at 05/17/2005 07:47:30 Thomas, I have struggled using UML2 in this area. If one wants to specify an Operation, specify a Behavior that implements the operation as an Activity, and then invoke the Operation in some other Activity, you have to specify the operation name and parameters many times: 1. In an Interface specification: the operation name, parameters, and raised exceptions (this is good practice separating the specification from the realization) 2. In any Class realizaing that Interface the operation names, parameters, and raised exceptsion have to be specified again. 3. The same information is specified again in the Behavior whose specification is the Operation of the Class 4. If the Behavior is an Activity, ActivityParameterNodes must be defined for each of the Behavior's parameters. This is the same information specified four times. Then there are differences in how the operation is invoked: 1. When the Operation is invoked in this or some other activity, Pins must be created and mapped to each of the parameters. 2. When the Operation is invoked in an Interaction models, Pins must be created for signals/call. This is a lot of repetition of the same information in the metamodel, and makes tools tedious to use because of the redundant information. Even if you don't have to type it, the information is there and navigators have to show it. Perhaps this issue could be used as a stimulus to simplify and normalize these aspects of the metamodel? Some possible ideas for simplification: 1. A class implicitly has all the operations of any of its realized interfaces. They do not have to be re-specified in the class. 2. A class can contain a behavior without a specification and that behavior can be shown in the operations compartment of the class (notation change only). 3. If a Behavior has a specification Operation, then it cannot have any name, parameters, or raised exceptions. These are all provided by the specification Operation. 4. Find some way to eliminate ActivityParameterNodes and just use the Behavior Parameters. "Thomas Weigert" 05/17/2005 01:28 AM To "'Branislav Selic'" , cc Subject RE: Ballot 3 Reissue -- discard old version Dear all, please find at the URL http://modeldrivenengineering.org/bin/view/Umlrtf/IssuesUnderDiscussion a set of 23 issues concerning composite structures put up for discussion. You can view each item by clicking the text icon, or edit by clicking the "text with pencil" icon (but you need to have registered before you can do so). Please enter discussion in the "Discussion" section. If there is no feedback within a week I'll consider these sufficiently agreed upon to deliver to Bran for the "soaking" period. Cheers, Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, May 16, 2005 3:33 PM To: uml2-rtf@omg.org Subject: Ballot 3 Reissue -- discard old version My apologies to all, but due to some belated input (and a screw up on my part), I have removed 4 proposed resolutions from Ballot 3. They are 6126, 6372, and 8161 (removed until Actions/Activities groups reach consensus on them) 6446 (removed because SysML raised objections to the current resolution) The new revised ballot is attached. Please discard the previous version. Regards, Bran Reply-To: From: "Conrad Bock" To: "Thomas Weigert" , "'Branislav Selic'" , Subject: ,cs, Composite WG discuissionfor ballot 4 Date: Mon, 23 May 2005 15:23:47 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Thomas, I put comments on the composite WG resolutions in the wiki, and below for folks signed up for that. Conrad - Issues 6150: Notation for method How about waiting until later in the RTF, to see if any consensus builds? Users hit this notational gap right away using UML. - Issue 8026: Contextualized attribute values Figures 121 Constructors are a way of specifying the values for attributes of objects that play parts in composites, that is, contextualized values. The problems with modeling contextualized values this way are given in the issue and a proposed resolution is linked there also. - Issue 8028: create dependency Figures 103 and 121 The resolution defines the semantics for usage dependencies between an operation and an instance value as specifying the return value. However, the semantics of usage dependency says: "The usage dependency does not specify how the client uses the supplier other than the fact that the supplier is used by of the definition or implementation of the client." The specific semantics in the resolution would need a stereotype, and should be From: "Thomas Weigert" To: Cc: "'Thomas Weigert'" Subject: Proposals for next ballot Date: Sat, 4 Jun 2005 14:07:33 -0500 X-Mailer: Microsoft Outlook, Build 10.0.6626 Dear all, below please find the proposals I selected to be considered for the next ballot from Structure and Behavior WG... For participation in discussion, please click on the link above each of the issues.... Cheers, Th. RtfIssue1000000001 23 May 2005 - 19:08 - r1.5 ConradBock Issue 6150: Notation for method Issue summary Provide a notation for a behavior used as a method of an operation Discussion How about waiting until later in the RTF, to see if any consensus builds? Users hit this notational gap right away using UML. -- ConradBock - 23 May 2005 The recommendation from the FTF remains: we need to gain experience with the various notations being considered for profiles before a solution is standardized. -- ThomasWeigert - 17 May 2005 I have struggled using UML2 in this area. If one wants to specify an Operation, specify a Behavior that implements the operation as an Activity, and then invoke the Operation in some other Activity, you have to specify the operation name and parameters many times: In an Interface specification: the operation name, parameters, and raised exceptions (this is good practice separating the specification from the realization) In any Class realizaing that Interface the operation names, parameters, and raised exceptsion have to be specified again. The same information is specified again in the Behavior whose specification is the Operation of the Class If the Behavior is an Activity, Activity Parameter Nodes? must be defined for each of the Behavior's parameters. This is the same information specified four times. Then there are differences in how the operation is invoked: When the Operation is invoked in this or some other activity, Pins must be created and mapped to each of the parameters. When the Operation is invoked in an Interaction models, Pins must be created for signals/call. This is a lot of repetition of the same information in the metamodel, and makes tools tedious to use because of the redundant information. Even if you don't have to type it, the information is there and navigators have to show it. Perhaps this issue could be used as a stimulus to simplify and normalize these aspects of the metamodel? Some possible ideas for simplification: A class implicitly has all the operations of any of its realized interfaces. They do not have to be re-specified in the class. A class can contain a behavior without a specification and that behavior can be shown in the operations compartment of the class (notation change only). The first part is already possible. A classifier can own a behavior that has no specification. It can even invoke this behavior without an operation being specified, but it cannot call this behavior from the outside. The second half (showing this in the operation compartment would be confusing, but we could add a method compartment). Note that this is within what is allowed already, but it is not explicitly stated in the specificaiton. --TW If a Behavior has a specification Operation, then it cannot have any name, parameters, or raised exceptions. These are all provided by the specification Operation. This won't work if you want to deal with dynamic dispatch situations. --TW Find some way to eliminate Activity Parameter Nodes? and just use the Behavior Parameters. I had proposed this during the original work but this was not agreeable to the activity group, but you can try again. --TW -- JimAmsden - 17 May 2005 Revised Test Resolution Composite structure issues resolution.doc