Issue 6148: Concrete Behavior (uml2-superstructure-ftf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Significant Summary: Behavior should be a concrete class so behaviors can be defined without committing to which model will be used to specify them later Resolution: Revised Text: Actions taken: August 30, 2003: received issue March 9, 2005: closed issue Discussion: The solution to issue 6149 introduces a metaclass for behavior that is specified only textually, without committing to a particular behavior model (OpaqueBehavior). This is mirrored on ValueSpecification, where OpaqueExpression defines an abstract value, and Expression, the subtypes of LiteralSpecification, and InstanceValue give concrete models, while OpaqueExpression describes a value textually only, without committing on how it is finally described. The solution 6149 makes this issue obsolete. Disposition: Closed, no change End of Annotations:===== Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Nature: Revision Severity: Significant Subject: Concrete Behavior Behavior should be a concrete class so behaviors can be defined without committing to which model will be used to specify them later. 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 Composite structure issues resolution.doc Discussion: This argument could be made for any abstract metaclass. However, the general style of the UML specification is that all concrete metaclasses would make sense in a final model. The metaclass Behavior, however, would not, as it is not able to specify any concrete behavior. However, see the related issue 6149 for an alternative solution. Disposition: Discuss together with 6149 From: "Thomas Weigert" To: Subject: ,cb, Input needed re primitive behaviors Date: Sun, 18 Apr 2004 21:27:32 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal Currently, the common behavior model allows the specification of behaviors to be given in simple textual form relying on the metaclass CommonBehaviors::Activity, which has a body attribute that takes a string in a given language (as specified by the language attribute). There are two issues pending pertaining to this topic: 6148 suggests that the abstract metaclass Behavior should be concrete to allow definition of a behavior without committing that this behavior be either a a statemachine, activity, interaction, etc. 6149 suggests that the body and language attributes of CommonBehaviors::Activity be moved to Behavior. If at all, these suggestions should be adopted together. Then one could give a definition of a behavior in some abstract way using Behavior with an associated text string, and later replace it with the concrete behavior. However, there are the following downsides with this solution: 1. The general style of the UML specification is that all concrete metaclasses would make sense in a final model. The metaclass Behavior, however, would not, as it is not able to specify any concrete behavior. 2. The body and language attributes are inherited to all subtypes of behavior. One would have to define what happens if both a body string and a structural explication is given in a subtype of Behavior (Activities::Activity should contain such explication but does not) as these two descriptions could be inconsistent. 3. When replacing the abstract behavior with a more concrete one (as suggested in 6148) one still needs to replace one metaclass with another, so nothing was really gained. I think that there are two possible approaches to this problem: A. Introduce an additional metaclass "TextualBehavior" or something like that, which has the body and language attributes. This allows the description of a behavior by just some text string. If one wants to refine that into a statemachine, say, one just replaces the metaclass with a StateMachine. B. Move the body and language attributes to behavior but leave behavior abstract. Add a rule to the effect that if a concrete subtype of behavior is supplied with structure (e.g., states, etc.) then the structure defines the behavior and the string must be empty or is interpreted as a comment. In that manner, one states that eventually one intends a behavior to eventually be one of the concrete behaviors, but initially can just give a textual description of the intended behavior. I would appreciate input to this topic. To: "Thomas Weigert" Cc: uml2-superstructure-ftf@omg.org Subject: Re: ,cb, Input needed re primitive behaviors X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 19 Apr 2004 08:07:47 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 04/19/2004 08:07:49, Serialize complete at 04/19/2004 08:07:49 Thomas, My preference is for solution A. It is consistent with the approach we have taken in other places, such as OpaqueExpression. Bran "Thomas Weigert" 04/18/2004 10:27 PM To cc Subject ,cb, Input needed re primitive behaviors Currently, the common behavior model allows the specification of behaviors to be given in simple textual form relying on the metaclass CommonBehaviors::Activity, which has a body attribute that takes a string in a given language (as specified by the language attribute). There are two issues pending pertaining to this topic: 6148 suggests that the abstract metaclass Behavior should be concrete to allow definition of a behavior without committing that this behavior be either a a statemachine, activity, interaction, etc. 6149 suggests that the body and language attributes of CommonBehaviors::Activity be moved to Behavior. If at all, these suggestions should be adopted together. Then one could give a definition of a behavior in some abstract way using Behavior with an associated text string, and later replace it with the concrete behavior. However, there are the following downsides with this solution: 1. The general style of the UML specification is that all concrete metaclasses would make sense in a final model. The metaclass Behavior, however, would not, as it is not able to specify any concrete behavior. 2. The body and language attributes are inherited to all subtypes of behavior. One would have to define what happens if both a body string and a structural explication is given in a subtype of Behavior (Activities::Activity should contain such explication but does not) as these two descriptions could be inconsistent. 3. When replacing the abstract behavior with a more concrete one (as suggested in 6148) one still needs to replace one metaclass with another, so nothing was really gained. I think that there are two possible approaches to this problem: A. Introduce an additional metaclass "TextualBehavior" or something like that, which has the body and language attributes. This allows the description of a behavior by just some text string. If one wants to refine that into a statemachine, say, one just replaces the metaclass with a StateMachine. B. Move the body and language attributes to behavior but leave behavior abstract. Add a rule to the effect that if a concrete subtype of behavior is supplied with structure (e.g., states, etc.) then the structure defines the behavior and the string must be empty or is interpreted as a comment. In that manner, one states that eventually one intends a behavior to eventually be one of the concrete behaviors, but initially can just give a textual description of the intended behavior. I would appreciate input to this topic. From: "Thomas Weigert" To: "Thomas Weigert" , Subject: RE: ,cb, Input needed re primitive behaviors Date: Wed, 21 Apr 2004 07:09:31 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal Based on input by Jim A. we should add another option: C. Leave as is, but add a rule in Activity that resolves the conflict when both body string and structure are present. Th. P.S. Resent as I received a delivery error for the omg mail server today for this mail. Please excuse any duplication. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Sunday, April 18, 2004 9:28 PM To: uml2-superstructure-ftf@omg.org Subject: ,cb, Input needed re primitive behaviors Currently, the common behavior model allows the specification of behaviors to be given in simple textual form relying on the metaclass CommonBehaviors::Activity, which has a body attribute that takes a string in a given language (as specified by the language attribute). There are two issues pending pertaining to this topic: 6148 suggests that the abstract metaclass Behavior should be concrete to allow definition of a behavior without committing that this behavior be either a a statemachine, activity, interaction, etc. 6149 suggests that the body and language attributes of CommonBehaviors::Activity be moved to Behavior. If at all, these suggestions should be adopted together. Then one could give a definition of a behavior in some abstract way using Behavior with an associated text string, and later replace it with the concrete behavior. However, there are the following downsides with this solution: 1. The general style of the UML specification is that all concrete metaclasses would make sense in a final model. The metaclass Behavior, however, would not, as it is not able to specify any concrete behavior. 2. The body and language attributes are inherited to all subtypes of behavior. One would have to define what happens if both a body string and a structural explication is given in a subtype of Behavior (Activities::Activity should contain such explication but does not) as these two descriptions could be inconsistent. 3. When replacing the abstract behavior with a more concrete one (as suggested in 6148) one still needs to replace one metaclass with another, so nothing was really gained. I think that there are two possible approaches to this problem: A. Introduce an additional metaclass "TextualBehavior" or something like that, which has the body and language attributes. This allows the description of a behavior by just some text string. If one wants to refine that into a statemachine, say, one just replaces the metaclass with a StateMachine. B. Move the body and language attributes to behavior but leave behavior abstract. Add a rule to the effect that if a concrete subtype of behavior is supplied with structure (e.g., states, etc.) then the structure defines the behavior and the string must be empty or is interpreted as a comment. In that manner, one states that eventually one intends a behavior to eventually be one of the concrete behaviors, but initially can just give a textual description of the intended behavior. I would appreciate input to this topic. From: "Thomas Weigert" To: "Thomas Weigert" , Subject: RE: ,cb, Input needed re primitive behaviors Date: Mon, 19 Apr 2004 14:27:33 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal Based on input by Jim A. we should add another option: C. Leave as is, but add a rule in Activity that resolves the conflict when both body string and structure are present. Th. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Sunday, April 18, 2004 9:28 PM To: uml2-superstructure-ftf@omg.org Subject: ,cb, Input needed re primitive behaviors Currently, the common behavior model allows the specification of behaviors to be given in simple textual form relying on the metaclass CommonBehaviors::Activity, which has a body attribute that takes a string in a given language (as specified by the language attribute). There are two issues pending pertaining to this topic: 6148 suggests that the abstract metaclass Behavior should be concrete to allow definition of a behavior without committing that this behavior be either a a statemachine, activity, interaction, etc. 6149 suggests that the body and language attributes of CommonBehaviors::Activity be moved to Behavior. If at all, these suggestions should be adopted together. Then one could give a definition of a behavior in some abstract way using Behavior with an associated text string, and later replace it with the concrete behavior. However, there are the following downsides with this solution: 1. The general style of the UML specification is that all concrete metaclasses would make sense in a final model. The metaclass Behavior, however, would not, as it is not able to specify any concrete behavior. 2. The body and language attributes are inherited to all subtypes of behavior. One would have to define what happens if both a body string and a structural explication is given in a subtype of Behavior (Activities::Activity should contain such explication but does not) as these two descriptions could be inconsistent. 3. When replacing the abstract behavior with a more concrete one (as suggested in 6148) one still needs to replace one metaclass with another, so nothing was really gained. I think that there are two possible approaches to this problem: A. Introduce an additional metaclass "TextualBehavior" or something like that, which has the body and language attributes. This allows the description of a behavior by just some text string. If one wants to refine that into a statemachine, say, one just replaces the metaclass with a StateMachine. B. Move the body and language attributes to behavior but leave behavior abstract. Add a rule to the effect that if a concrete subtype of behavior is supplied with structure (e.g., states, etc.) then the structure defines the behavior and the string must be empty or is interpreted as a comment. In that manner, one states that eventually one intends a behavior to eventually be one of the concrete behaviors, but initially can just give a textual description of the intended behavior. I would appreciate input to this topic. From: "Thomas Weigert" To: Subject: ,cb, Input needed re primitive behaviors Date: Wed, 28 Apr 2004 12:52:19 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Dear all, this request for input was sent earlier and I have received three inputs so far: one supporting option A, one B, and one C. Please provide your input so that I can resolve these issues in a manner that is satisfactory to most. Thanks, Th. Currently, the common behavior model allows the specification of behaviors to be given in simple textual form relying on the metaclass CommonBehaviors::Activity, which has a body attribute that takes a string in a given language (as specified by the language attribute). There are two issues pending pertaining to this topic: 6148 suggests that the abstract metaclass Behavior should be concrete to allow definition of a behavior without committing that this behavior be either a a statemachine, activity, interaction, etc. 6149 suggests that the body and language attributes of CommonBehaviors::Activity be moved to Behavior. If at all, these suggestions should be adopted together. Then one could give a definition of a behavior in some abstract way using Behavior with an associated text string, and later replace it with the concrete behavior. However, there are the following downsides with this solution: 1. The general style of the UML specification is that all concrete metaclasses would make sense in a final model. The metaclass Behavior, however, would not, as it is not able to specify any concrete behavior. 2. The body and language attributes are inherited to all subtypes of behavior. One would have to define what happens if both a body string and a structural explication is given in a subtype of Behavior (Activities::Activity should contain such explication but does not) as these two descriptions could be inconsistent. 3. When replacing the abstract behavior with a more concrete one (as suggested in 6148) one still needs to replace one metaclass with another, so nothing was really gained. I think that there are two possible approaches to this problem: A. Introduce an additional metaclass "TextualBehavior" or something like that, which has the body and language attributes. This allows the description of a behavior by just some text string. If one wants to refine that into a statemachine, say, one just replaces the metaclass with a StateMachine. B. Move the body and language attributes to behavior but leave behavior abstract. Add a rule to the effect that if a concrete subtype of behavior is supplied with structure (e.g., states, etc.) then the structure defines the behavior and the string must be empty or is interpreted as a comment. In that manner, one states that eventually one intends a behavior to eventually be one of the concrete behaviors, but initially can just give a textual description of the intended behavior. C. Leave current situation, but fix Activities::Activity to explain what happens if both types of behavior descriptions are present and inconsistent. I would appreciate input to this topic. From: "Thomas Weigert" To: Subject: ,cb, Input needed re primitive behaviors Date: Wed, 12 May 2004 00:01:47 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Dear all, last chance to comment before I resolve this issue. I have received four inputs so far: two supporting option A, one B, and one C. Thanks, Th. Currently, the common behavior model allows the specification of behaviors to be given in simple textual form relying on the metaclass CommonBehaviors::Activity, which has a body attribute that takes a string in a given language (as specified by the language attribute). There are two issues pending pertaining to this topic: 6148 suggests that the abstract metaclass Behavior should be concrete to allow definition of a behavior without committing that this behavior be either a a statemachine, activity, interaction, etc. 6149 suggests that the body and language attributes of CommonBehaviors::Activity be moved to Behavior. If at all, these suggestions should be adopted together. Then one could give a definition of a behavior in some abstract way using Behavior with an associated text string, and later replace it with the concrete behavior. However, there are the following downsides with this solution: 1. The general style of the UML specification is that all concrete metaclasses would make sense in a final model. The metaclass Behavior, however, would not, as it is not able to specify any concrete behavior. 2. The body and language attributes are inherited to all subtypes of behavior. One would have to define what happens if both a body string and a structural explication is given in a subtype of Behavior (Activities::Activity should contain such explication but does not) as these two descriptions could be inconsistent. 3. When replacing the abstract behavior with a more concrete one (as suggested in 6148) one still needs to replace one metaclass with another, so nothing was really gained. I think that there are two possible approaches to this problem: A. Introduce an additional metaclass "TextualBehavior" or something like that, which has the body and language attributes. This allows the description of a behavior by just some text string. If one wants to refine that into a statemachine, say, one just replaces the metaclass with a StateMachine. B. Move the body and language attributes to behavior but leave behavior abstract. Add a rule to the effect that if a concrete subtype of behavior is supplied with structure (e.g., states, etc.) then the structure defines the behavior and the string must be empty or is interpreted as a comment. In that manner, one states that eventually one intends a behavior to eventually be one of the concrete behaviors, but initially can just give a textual description of the intended behavior. C. Leave current situation, but fix Activities::Activity to explain what happens if both types of behavior descriptions are present and inconsistent. I would appreciate input to this topic. Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 12 May 2004 11:14:25 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: Re: ,cb, Input needed re primitive behaviors Thomas, by A, do you intend that the text will be removed if the user replaces the TextualBehavior with a different kind? B and C allow both text and another specification. That enables the user to compare the two, to ensure that the second behavior agrees with the text. What is the practical advantage of making this difficult (look at a different model) or impossible (the text is lost)? Cordially, Joaquin I have received four inputs so far: two supporting option A, one B, and one C. A. Introduce an additional metaclass "TextualBehavior" or something like that, which has the body and language attributes. This allows the description of a behavior by just some text string. If one wants to refine that into a statemachine, say, one just replaces the metaclass with a StateMachine. B. Move the body and language attributes to behavior but leave behavior abstract. Add a rule to the effect that if a concrete subtype of behavior is supplied with structure (e.g., states, etc.) then the structure defines the behavior and the string must be empty or is interpreted as a comment. In that manner, one states that eventually one intends a behavior to eventually be one of the concrete behaviors, but initially can just give a textual description of the intended behavior. C. Leave current situation, but fix Activities::Activity to explain what happens if both types of behavior descriptions are present and inconsistent. Reply-To: From: "Conrad Bock" To: Subject: RE: ,cb, Input needed re primitive behaviors Date: Wed, 12 May 2004 14:21:45 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Thomas, > last chance to comment before I resolve this issue. I have > received four inputs so far: two supporting option A, one B, and one C. Could have sworn I sent this, but maybe not. Conrad Hi Thomas, I'd suggest proposal D: - Promote body/language to Behavior. - Add concrete Opaque/Textual/UninterpretedBehavior that doesn't add any new attributes. Motivation/comments below, Conrad > 6148 suggests that the abstract metaclass Behavior should be > concrete to allow definition of a behavior without committing > that this behavior be either a a statemachine, activity, > interaction, etc. > > 6149 suggests that the body and language attributes of > CommonBehaviors::Activity be moved to Behavior. > > If at all, these suggestions should be adopted together. Then > one could give a definition of a behavior in some abstract way > using Behavior with an associated text string, and later replace > it with the concrete behavior. > > However, there are the following downsides with this solution: > > 1. The general style of the UML specification is that all concrete > metaclasses would make sense in a final model. The metaclass > Behavior, however, would not, as it is not able to specify any > concrete behavior. > 2. The body and language attributes are inherited to all subtypes of > behavior. One would have to define what happens if both a body string > and a structural explication is given in a subtype of Behavior > (Activities::Activity should contain such explication but does not) > as these two descriptions could be inconsistent. The body/language attributes specify the behavior in textual form, like an action language. The model is the "compiled" form. Should be available on all behaviors. > 3. When replacing the abstract behavior with a more concrete one (as > suggested in 6148) one still needs to replace one metaclass with > another, so nothing was really gained. Didn't follow this. > I think that there are two possible approaches to this problem: > > A. Introduce an additional metaclass "TextualBehavior" or > something like that, which has the body and language attributes. > This allows the description of a behavior by just some text > string. If one wants to refine that into a statemachine, say, > one just replaces the metaclass with a StateMachine. Doesn't work for the application above. > B. Move the body and language attributes to behavior but leave > behavior abstract. Add a rule to the effect that if a concrete > subtype of behavior is supplied with structure (e.g., states, > etc.) then the structure defines the behavior and the string > must be empty or is interpreted as a comment. In that manner, > one states that eventually one intends a behavior to eventually > be one of the concrete behaviors, but initially can just give a > textual description of the intended behavior. No need for the rule in the application above. > C. Leave as is, but add a rule in Activity that resolves the conflict > when both body string and structure are present. There is no conflict in the application above. User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Wed, 12 May 2004 14:28:17 -0400 Subject: Re: ,cb, Input needed re primitive behaviors From: James Odell To: Hi Thomas, Promoting body/language to Behavior might be the best compromise. I support Conrad's Option D. -Jim On 5/12/04 2:21 PM, "Conrad Bock" indited: > > Hi Thomas, > >> last chance to comment before I resolve this issue. I have >> received four inputs so far: two supporting option A, one B, and one C. > > Could have sworn I sent this, but maybe not. > > Conrad > > > Hi Thomas, > > I'd suggest proposal D: > > - Promote body/language to Behavior. > > - Add concrete Opaque/Textual/UninterpretedBehavior that doesn't add > any new attributes. > > Motivation/comments below, > > Conrad > >> 6148 suggests that the abstract metaclass Behavior should be >> concrete to allow definition of a behavior without committing >> that this behavior be either a a statemachine, activity, >> interaction, etc. >> >> 6149 suggests that the body and language attributes of >> CommonBehaviors::Activity be moved to Behavior. >> >> If at all, these suggestions should be adopted together. Then >> one could give a definition of a behavior in some abstract way >> using Behavior with an associated text string, and later replace >> it with the concrete behavior. >> >> However, there are the following downsides with this solution: >> >> 1. The general style of the UML specification is that all concrete >> metaclasses would make sense in a final model. The metaclass >> Behavior, however, would not, as it is not able to specify any >> concrete behavior. > >> 2. The body and language attributes are inherited to all subtypes of >> behavior. One would have to define what happens if both a body string >> and a structural explication is given in a subtype of Behavior >> (Activities::Activity should contain such explication but does not) >> as these two descriptions could be inconsistent. > > The body/language attributes specify the behavior in textual form, like > an action language. The model is the "compiled" form. Should be > available on all behaviors. > > >> 3. When replacing the abstract behavior with a more concrete one (as >> suggested in 6148) one still needs to replace one metaclass with >> another, so nothing was really gained. > > Didn't follow this. > >> I think that there are two possible approaches to this problem: >> >> A. Introduce an additional metaclass "TextualBehavior" or >> something like that, which has the body and language attributes. >> This allows the description of a behavior by just some text >> string. If one wants to refine that into a statemachine, say, >> one just replaces the metaclass with a StateMachine. > > Doesn't work for the application above. > >> B. Move the body and language attributes to behavior but leave >> behavior abstract. Add a rule to the effect that if a concrete >> subtype of behavior is supplied with structure (e.g., states, >> etc.) then the structure defines the behavior and the string >> must be empty or is interpreted as a comment. In that manner, >> one states that eventually one intends a behavior to eventually >> be one of the concrete behaviors, but initially can just give a >> textual description of the intended behavior. > > No need for the rule in the application above. > >> C. Leave as is, but add a rule in Activity that resolves the conflict >> when both body string and structure are present. > > There is no conflict in the application above. From: "Thomas Weigert" To: , Subject: RE: ,cb, Input needed re primitive behaviors Date: Wed, 12 May 2004 15:03:53 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Conrad, if you define a body attribute on behavior, you need consistency rules that ensure that the behavior so specified does not violate structurally specified behavior on the same metaclass. E.g., you have a state machine and also a body attribute. Do both define part of the behavior of the class? Does only one count? Do they need to specify the same behavior? And how do you know it is the same behavior? I am not sure why you think this is not needed, but it is not clear from your mail below. Currently there is a defect in Activities in that this is not defined. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Wednesday, May 12, 2004 1:22 PM > To: uml2-superstructure-ftf@omg.org > Subject: RE: ,cb, Input needed re primitive behaviors > > > > Hi Thomas, > > > last chance to comment before I resolve this issue. I have > > received four inputs so far: two supporting option A, one B, and one C. > > Could have sworn I sent this, but maybe not. > > Conrad > > > Hi Thomas, > > I'd suggest proposal D: > > - Promote body/language to Behavior. > > - Add concrete Opaque/Textual/UninterpretedBehavior that doesn't add > any new attributes. > > Motivation/comments below, > > Conrad > > > 6148 suggests that the abstract metaclass Behavior should be > > concrete to allow definition of a behavior without committing > > that this behavior be either a a statemachine, activity, > > interaction, etc. > > > > 6149 suggests that the body and language attributes of > > CommonBehaviors::Activity be moved to Behavior. > > > > If at all, these suggestions should be adopted together. Then > > one could give a definition of a behavior in some abstract way > > using Behavior with an associated text string, and later replace > > it with the concrete behavior. > > > > However, there are the following downsides with this solution: > > > > 1. The general style of the UML specification is that all concrete > > metaclasses would make sense in a final model. The metaclass > > Behavior, however, would not, as it is not able to specify any > > concrete behavior. > > > 2. The body and language attributes are inherited to all subtypes of > > behavior. One would have to define what happens if both a body string > > and a structural explication is given in a subtype of Behavior > > (Activities::Activity should contain such explication but does not) > > as these two descriptions could be inconsistent. > > The body/language attributes specify the behavior in textual form, like > an action language. The model is the "compiled" form. Should be > available on all behaviors. > > > > 3. When replacing the abstract behavior with a more concrete one (as > > suggested in 6148) one still needs to replace one metaclass with > > another, so nothing was really gained. > > Didn't follow this. > > > I think that there are two possible approaches to this problem: > > > > A. Introduce an additional metaclass "TextualBehavior" or > > something like that, which has the body and language attributes. > > This allows the description of a behavior by just some text > > string. If one wants to refine that into a statemachine, say, > > one just replaces the metaclass with a StateMachine. > > Doesn't work for the application above. > > > B. Move the body and language attributes to behavior but leave > > behavior abstract. Add a rule to the effect that if a concrete > > subtype of behavior is supplied with structure (e.g., states, > > etc.) then the structure defines the behavior and the string > > must be empty or is interpreted as a comment. In that manner, > > one states that eventually one intends a behavior to eventually > > be one of the concrete behaviors, but initially can just give a > > textual description of the intended behavior. > > No need for the rule in the application above. > > > C. Leave as is, but add a rule in Activity that resolves the conflict > > when both body string and structure are present. > > There is no conflict in the application above. From: "Thomas Weigert" To: "James Odell" , Subject: RE: ,cb, Input needed re primitive behaviors Date: Wed, 12 May 2004 15:13:59 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Jim and Conrad, if we have a special class Opaque/Textual/UninterpretedBehavior we do not need these attributes on the other classes. See Expression for the parallel situation. Th. > -----Original Message----- > From: James Odell [mailto:email@jamesodell.com] > Sent: Wednesday, May 12, 2004 1:28 PM > To: uml2-superstructure-ftf@omg.org > Subject: Re: ,cb, Input needed re primitive behaviors > > > Hi Thomas, > > Promoting body/language to Behavior might be the best compromise. > I support > Conrad's Option D. > > -Jim > > > On 5/12/04 2:21 PM, "Conrad Bock" indited: > > > > > Hi Thomas, > > > >> last chance to comment before I resolve this issue. I have > >> received four inputs so far: two supporting option A, one B, and one C. > > > > Could have sworn I sent this, but maybe not. > > > > Conrad > > > > > > Hi Thomas, > > > > I'd suggest proposal D: > > > > - Promote body/language to Behavior. > > > > - Add concrete Opaque/Textual/UninterpretedBehavior that doesn't add > > any new attributes. > > > > Motivation/comments below, > > > > Conrad > > > >> 6148 suggests that the abstract metaclass Behavior should be > >> concrete to allow definition of a behavior without committing > >> that this behavior be either a a statemachine, activity, > >> interaction, etc. > >> > >> 6149 suggests that the body and language attributes of > >> CommonBehaviors::Activity be moved to Behavior. > >> > >> If at all, these suggestions should be adopted together. Then > >> one could give a definition of a behavior in some abstract way > >> using Behavior with an associated text string, and later replace > >> it with the concrete behavior. > >> > >> However, there are the following downsides with this solution: > >> > >> 1. The general style of the UML specification is that all concrete > >> metaclasses would make sense in a final model. The metaclass > >> Behavior, however, would not, as it is not able to specify any > >> concrete behavior. > > > >> 2. The body and language attributes are inherited to all subtypes of > >> behavior. One would have to define what happens if both a body string > >> and a structural explication is given in a subtype of Behavior > >> (Activities::Activity should contain such explication but does not) > >> as these two descriptions could be inconsistent. > > > > The body/language attributes specify the behavior in textual form, like > > an action language. The model is the "compiled" form. Should be > > available on all behaviors. > > > > > >> 3. When replacing the abstract behavior with a more concrete one (as > >> suggested in 6148) one still needs to replace one metaclass with > >> another, so nothing was really gained. > > > > Didn't follow this. > > > >> I think that there are two possible approaches to this problem: > >> > >> A. Introduce an additional metaclass "TextualBehavior" or > >> something like that, which has the body and language attributes. > >> This allows the description of a behavior by just some text > >> string. If one wants to refine that into a statemachine, say, > >> one just replaces the metaclass with a StateMachine. > > > > Doesn't work for the application above. > > > >> B. Move the body and language attributes to behavior but leave > >> behavior abstract. Add a rule to the effect that if a concrete > >> subtype of behavior is supplied with structure (e.g., states, > >> etc.) then the structure defines the behavior and the string > >> must be empty or is interpreted as a comment. In that manner, > >> one states that eventually one intends a behavior to eventually > >> be one of the concrete behaviors, but initially can just give a > >> textual description of the intended behavior. > > > > No need for the rule in the application above. > > > >> C. Leave as is, but add a rule in Activity that resolves the conflict > >> when both body string and structure are present. > > > > There is no conflict in the application above. > Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 12 May 2004 14:32:10 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: ,cb, Input needed re primitive behaviors if you define a body attribute on behavior, you need consistency rules that ensure that the behavior so specified does not violate structurally specified behavior on the same metaclass. E.g., you have a state machine and also a body attribute. Do both define part of the behavior of the class? Does only one count? Here is how i feel: Do they need to specify the same behavior? Yes. And how do you know it is the same behavior? From what little i know about these matters, in the general case it is impossible to know. (Can't i show that is equivalent to the halting problem?) That's why it is unnecessary to have such consistency rules: it's impossible. But isn't the problem solved by providing that, if there is "structurally specified behavior," then that is the behavior the model specified? Do both define part of the behavior of the class? No, both define all. Does only one count? Yes, the "structurally specified behavior" counts if present, the text otherwise. That rule, it seems to me, solves the problem of conflict, while enabling a model that includes both the text and the UML specification of behavior, so that the model can be tested for inconsistency, by machine, insofar as that is possible, and by humans when necessary or desirable. Cordially, Joaquin Subject: RE: ,cb, Input needed re primitive behaviors Date: Wed, 12 May 2004 19:54:07 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,cb, Input needed re primitive behaviors Thread-Index: AcQ4dGmGsiLPYpLrQISDwxrpk3BUxgABvxOQ From: "Karl Frank" To: "Joaquin Miller" , "UML Superstructure FTF" X-OriginalArrivalTime: 12 May 2004 23:54:08.0622 (UTC) FILETIME=[6A72B8E0:01C4387C] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4CNx6un002202 It appears the choices being actively discussed are between Conrad's suggestion that: Behavior remains abstract. The body/language attributes move up to Behavior, thereby being inherited by all 3 concrete subtypes Thomas' suggestion A that: A new peer of Activity and Statmachine and Interaction be introduced The body/language attributes move over to this peer, thereby being available to modelers The disadvantage of Conrad's suggestion is that it opens a door to inconsistency, which Joaquin says is not such a big deal really, but which I thought was objectionable. The disadvantage of Thomas' suggestion is that it add yet another metaclass to an already overpopulated metamodel. This is not just a schoenheits failing, but a problem for tools in that there is yet another distinct tool in the toolbar. I voted initially for Thomas' suggestion, but pragmatism in the design of toolbars may win me over. - Karl -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Wednesday, 12 May, 2004 5:32 PM To: UML Superstructure FTF Subject: RE: ,cb, Input needed re primitive behaviors >if you define a body attribute on behavior, you need consistency rules >that ensure that the behavior so specified does not violate >structurally specified behavior on the same metaclass. E.g., you have a >state machine and also a body attribute. Do both define part of the >behavior of the class? Does only one count? Here is how i feel: >Do they need to specify the same behavior? Yes. >And how do you know it is the same behavior? From what little i know about these matters, in the general case it is impossible to know. (Can't i show that is equivalent to the halting problem?) That's why it is unnecessary to have such consistency rules: it's impossible. But isn't the problem solved by providing that, if there is "structurally specified behavior," then that is the behavior the model specified? >Do both define part of the behavior of the class? No, both define all. >Does only one count? Yes, the "structurally specified behavior" counts if present, the text otherwise. That rule, it seems to me, solves the problem of conflict, while enabling a model that includes both the text and the UML specification of behavior, so that the model can be tested for inconsistency, by machine, insofar as that is possible, and by humans when necessary or desirable. Cordially, Joaquin Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 13 May 2004 08:56:19 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: ,cb, Input needed re primitive behaviors The disadvantage of Conrad's suggestion is that it opens a door to inconsistency, which Joaquin says is not such a big deal really, but which I thought was objectionable. Forgive me for repeating myself, please. Without the inconsistency in the model, it will be impossible to discover the error. The inconsistency we are talking about is an inconsistency between a text specification of a behavior and a subsequent UML specification of that behavior. Any solution that removes the text when the UML specification is inserted ditches extremely valuable information. ....... Sure, it is risky keeping the text in the model. Readers may rely on the text and assume that the UML model agrees. Each of the following is a greater risk: Throw the text away. Leave it in some previous version of the model. Keep it in some document outside the UML modelling system. All make it much more likely that an error will not be detected until the software is in use. Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: ,cb, Input needed re primitive behaviors Date: Thu, 13 May 2004 14:40:59 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Karl, et al, > The disadvantage of Conrad's suggestion is that it opens a door to > inconsistency, which Joaquin says is not such a big deal really, but Same here, since it is just a string with a syntax defined by the vendor, it's their problem. It's like the documentation string inherited from Element, which also describes the behavior in an uncheable way. However, A is fine. It's a useful case to distinguish, and better than proposal D in that the new metaclass will have some attributes to justify tis existence. Conrad Reply-To: From: "Conrad Bock" To: "UML Superstructure FTF" Subject: RE: ,cb, Input needed re primitive behaviors Date: Thu, 13 May 2004 16:34:21 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, Looks like this issue needs to be addressed along with the one you just filed that state machines should use Behavior instead of Activity. If we adopt proposal A without fixing your second issue, then state machines would lose the capability of modeling uninterpreted behaviors, which is currently done with Activity. Conrad Date: Fri, 14 May 2004 09:51:11 +0100 From: Guus Ramackers Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Joaquin Miller CC: UML Superstructure FTF Subject: Re: ,cb, Input needed re primitive behaviors Joaquin, > The inconsistency we are talking about is an inconsistency between a text specification of a behavior and a subsequent UML specification of that behavior. This kind of inconsistency is possible in UML in many places. It is up to tools and methods to lay down consistency rules between different types of behaviors (or indeed between the same kind of behaviors: e.g. it is quite easy to make two state machine specs that form an inconsistent spec.). Having the option to store textual (early life cycle) descriptions in the model (as opposed to in external docuemnts) is important from the perspective of having all design information in one place.. Thanks, Guus Joaquin Miller wrote: The disadvantage of Conrad's suggestion is that it opens a door to inconsistency, which Joaquin says is not such a big deal really, but which I thought was objectionable. Forgive me for repeating myself, please. Without the inconsistency in the model, it will be impossible to discover the error. The inconsistency we are talking about is an inconsistency between a text specification of a behavior and a subsequent UML specification of that behavior. Any solution that removes the text when the UML specification is inserted ditches extremely valuable information. ....... Sure, it is risky keeping the text in the model. Readers may rely on the text and assume that the UML model agrees. Each of the following is a greater risk: Throw the text away. Leave it in some previous version of the model. Keep it in some document outside the UML modelling system. All make it much more likely that an error will not be detected until the software is in use. -- __________________________________________________________ Guus Ramackers Product Manager UML and Web Services, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 OMG Issue No: 6148 Title: Concrete Behavior Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Behavior should be a concrete class so behaviors can be defined without committing to which model will be used to specify them later Discussion: The solution to issue 6149 introduces a metaclass for behavior that is specified only textually, without committing to a particular behavior model (OpaqueBehavior). This is mirrored on ValueSpecification, where OpaqueExpression defines an abstract value, and Expression, the subtypes of LiteralSpecification, and InstanceValue give concrete models, while OpaqueExpression describes a value textually only, without committing on how it is finally described. The solution 6149 makes this issue obsolete. Disposition: Closed, no change OMG Issue No: 6148 Title: Concrete Behavior Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Behavior should be a concrete class so behaviors can be defined without committing to which model will be used to specify them later Discussion: The solution to issue 6149 introduces a metaclass for behavior that is specified only textually, without committing to a particular behavior model (OpaqueBehavior). This is mirrored on ValueSpecification, where OpaqueExpression defines an abstract value, and Expression, the subtypes of LiteralSpecification, and InstanceValue give concrete models, while OpaqueExpression describes a value textually only, without committing on how it is finally described. The solution 6149 makes this issue obsolete. Disposition: Closed, no change