Issue 18847: problems with BehavioralFeature::method (uml25-ftf) Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: We are experiencing problems while trying to support "functional allocations" - building behavioral/functional models separately from structural designs and reusing functions in alternative structural designs. The UML metamodel problems: 1. Behavior can't be owned "outside" Classifier owning the operation and used as it's method (so not behavior libraries are possible). 2. Behaviors can't be reused, cause it may have only one Operation ([0..1]) as specification (no reuse in alternative designs are possible) 3. Operation may have multiple methods ([0..*]) - redefining behaviors in subtypes. As a result, operation in super class is modified every time new behavior implements an operation and depends on subtypes, which is not acceptable. Clarifications and possible spec corrections are highly appreciated. UML 2.5 beta spec says:  method : Behavior [0..*] (opposite Behavior::specification) A Behavior that implements the BehavioralFeature. There may be at most one Behavior for a particular pairing of a Classifier (as owner of the Behavior) and a BehavioralFeature (as specification of the Behavior).  specification : BehavioralFeature [0..1] (opposite BehavioralFeature::method) Designates a BehavioralFeature that the Behavior implements. The BehavioralFeature must be owned by the BehavioredClassifier that owns the Behavior or be inherited by it. The Parameters of the BehavioralFeature and the implementing Behavior must match. A Behavior does not need to have a specification, in which case it either is the classifierBehavior of a BehavioredClassifier or it can only be invoked by another Behavior of the Classifier. Proposed changes: 1. Don't constrain where behavior must be owned to implement operation. 2. Let the same behavior be a method of more than one Operation. 3. change the rules, how Behavior::context is derived (now it is derived from the chain of the owners, but could be derived from the specification owner or ActivityPartition's represented elements) or make it non-derived. 4. Allow one method only and use redefining Operations instead. Resolution: Revised Text: Actions taken: August 1, 2013: received issue Discussion: End of Annotations:===== iler: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 01 Aug 2013 11:35:29 -0400 To: issues@omg.org, uml25-ftf@omg.org From: Juergen Boldt Subject: issue 18847 -- UML 2.5 FTF issue X-Virus-Scanned: amavisd-new at omg.org X-Trusted-NM: yes From: Nerijus Jankevicius Subject: problems with BehavioralFeature::method Date: Thu, 1 Aug 2013 18:20:35 +0300 Cc: "Lonnie VanZandt (lvanzandt@nomagic.com)" To: uml25-ftf@omg.org, "sysml-rtf@omg.org (sysml-rtf@omg.org)" X-Mailer: Apple Mail (2.1085) X-Virus-Scanned: amavisd-new at omg.org Hello, We are experiencing problems while trying to support "functional allocations" - building behavioral/functional models separately from structural designs and reusing functions in alternative structural designs. The UML metamodel problems: 1. Behavior can't be owned "outside" Classifier owning the operation and used as it's method (so not behavior libraries are possible). 2. Behaviors can't be reused, cause it may have only one Operation ([0..1]) as specification (no reuse in alternative designs are possible) 3. Operation may have multiple methods ([0..*]) - redefining behaviors in subtypes. As a result, operation in super class is modified every time new behavior implements an operation and depends on subtypes, which is not acceptable. Clarifications and possible spec corrections are highly appreciated. UML 2.5 beta spec says: ï method : Behavior [0..*] (opposite Behavior::specification) A Behavior that implements the BehavioralFeature. There may be at most one Behavior for a particular pairing of a Classifier (as owner of the Behavior) and a BehavioralFeature (as specification of the Behavior). ï specification : BehavioralFeature [0..1] (opposite BehavioralFeature::method) Designates a BehavioralFeature that the Behavior implements. The BehavioralFeature must be owned by the BehavioredClassifier that owns the Behavior or be inherited by it. The Parameters of the BehavioralFeature and the implementing Behavior must match. A Behavior does not need to have a specification, in which case it either is the classifierBehavior of a BehavioredClassifier or it can only be invoked by another Behavior of the Classifier. Proposed changes: 1. Don't constrain where behavior must be owned to implement operation. 2. Let the same behavior be a method of more than one Operation. 3. change the rules, how Behavior::context is derived (now it is derived from the chain of the owners, but could be derived from the specification owner or ActivityPartition's represented elements) or make it non-derived. 4. Allow one method only and use redefining Operations instead. Thanks, Nerijus Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org From: "Rouquette, Nicolas F (313K)" To: Nerijus Jankevicius , "uml25-ftf@omg.org" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" CC: "Lonnie VanZandt (lvanzandt@nomagic.com)" , "Robert Karban" Subject: Re: problems with BehavioralFeature::method Thread-Topic: problems with BehavioralFeature::method Thread-Index: AQHOjsrzUCpkaqcKd0yrorN53Gd4GpmAfByA Date: Thu, 1 Aug 2013 15:36:12 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Nerijus, Relax.. The solution is to use the "Block-Specific Type" technique that I developed at JPL. Here's an example: Here, I want to use a state machine, SM1, as the method of two operations: A::op1() and B::op1(). Without specialization, you'd be correct . I'd have to choose one or the other but not both. That's a good thing! With specialization, the model is conceptually correct . thhat is, "A.op1 . SM1", a specialization of SM11, represents semantically the specific behaviored classifier specifying the method of A::op1(). If you read Conrad's "Ontological Behavior Modeling" paper, you'll eventually realize that modeling behavior is no different than modeling structure. In either case, context matters. The notion of "part" makes sense ontologically if it represented using a "PropertySpecificType" (invented in SysML!) We're just applying this technique to contextualize everything. It makes many "contextualization"-related problems simpler . No need for NestedConnectorEnd, InvocationOnNestedPoortAction, ElementPropertyPath, etc.. Because everythingg is, by definition, contextualized such that each part plays ontologically a unique role for its owning classifier context. - Nicolas. From: Nerijus Jankevicius Date: Thursday, August 1, 2013 8:20 AM To: "uml25-ftf@omg.org" , "sysml-rtf@omg.org" Cc: "Lonnie VanZandt (lvanzandt@nomagic.com)" Subject: problems with BehavioralFeature::method Hello, We are experiencing problems while trying to support "functional allocations" - building behavioral/functional models separately from structural designs and reusing functions in alternative structural designs. The UML metamodel problems: 1. Behavior can't be owned "outside" Classifier owning the operation and used as it's method (so not behavior libraries are possible). 2. Behaviors can't be reused, cause it may have only one Operation ([0..1]) as specification (no reuse in alternative designs are possible) 3. Operation may have multiple methods ([0..*]) - redefining behaviors in subtypes. As a result, operation in super class is modified every time new behavior implements an operation and depends on subtypes, which is not acceptable. Clarifications and possible spec corrections are highly appreciated. UML 2.5 beta spec says: . method : Behavior [0..*] (opposite Behavior::specification) A Behavior that implements the BehavioralFeature. There may be at most one Behavior for a particular pairing of a Classifier (as owner of the Behavior) and a BehavioralFeature (as specification of the Behavior). . specification : BehavioralFeature [0..1] (opposite BehavioralFeature::method) Designates a BehavioralFeature that the Behavior implements. The BehavioralFeature must be owned by the BehavioredClassifier that owns the Behavior or be inherited by it. The Parameters of the BehavioralFeature and the implementing Behavior must match. A Behavior does not need to have a specification, in which case it either is the classifierBehavior of a BehavioredClassifier or it can only be invoked by another Behavior of the Classifier. Proposed changes: 1. Don't constrain where behavior must be owned to implement operation. 2. Let the same behavior be a method of more than one Operation. 3. change the rules, how Behavior::context is derived (now it is derived from the chain of the owners, but could be derived from the specification owner or ActivityPartition's represented elements) or make it non-derived. 4. Allow one method only and use redefining Operations instead. Thanks, Nerijus X-Trusted-NM: yes Subject: Re: problems with BehavioralFeature::method From: Nerijus Jankevicius Date: Thu, 1 Aug 2013 18:48:27 +0300 Cc: "sysml-rtf@omg.org (sysml-rtf@omg.org)" , "Lonnie VanZandt (lvanzandt@nomagic.com)" To: "Rouquette, Nicolas F (313K)" , Robert Karban X-Mailer: Apple Mail (2.1085) X-Virus-Scanned: amavisd-new at omg.org Nicolas, With current metamodel, we can't do many things Sandy's book or Robert's cookbook suggests: 1. can't own behaviors in separate package (having Structure, Behaviors packages) 2. behaviors owned in packages have no context even if they are allocated to blocks. 3. we can't create Operations for all allocated behaviors, as a) they are not owned in Block, b) if same behavior is allocated to more than one block, it can't be use as method of two operations. Nerijus On Aug 1, 2013, at 6:36 PM, Rouquette, Nicolas F (313K) wrote: Nerijus, Relax.. The solution is to use the "Block-Specific Type" technique that I developed at JPL. Here's an example: Here, I want to use a state machine, SM1, as the method of two operations: A::op1() and B::op1(). Without specialization, you'd be correct . I'd have to choose one or the other but not both. That's a good thing! With specialization, the model is conceptually correct . that is, "A.op1 . SM1", a specialization of SM1, represents semantically the specific behaviored classifier specifying the method of A::op1(). If you read Conrad's "Ontological Behavior Modeling" paper, you'll eventually realize that modeling behavior is no different than modeling structure. In either case, context matters. The notion of "part" makes sense ontologically if it represented using a "PropertySpecificType" (invented in SysML!) We're just applying this technique to contextualize everything. It makes many "contextualization"-related problems simpler . No need for NestedConnectorEnd, InvocationOnNestedPortAction, ElementPropertyPath, etc.. Because everything is, by definition, contextualized such that each part plays ontologically a unique role for its owning classifier context. - Nicolas. From: Nerijus Jankevicius Date: Thursday, August 1, 2013 8:20 AM To: "uml25-ftf@omg.org" , "sysml-rtf@omg.org" Cc: "Lonnie VanZandt (lvanzandt@nomagic.com)" Subject: problems with BehavioralFeature::method Hello, We are experiencing problems while trying to support "functional allocations" - building behavioral/functional models separately from structural designs and reusing functions in alternative structural designs. The UML metamodel problems: 1. Behavior can't be owned "outside" Classifier owning the operation and used as it's method (so not behavior libraries are possible). 2. Behaviors can't be reused, cause it may have only one Operation ([0..1]) as specification (no reuse in alternative designs are possible) 3. Operation may have multiple methods ([0..*]) - redefining behaviors in subtypes. As a result, operation in super class is modified every time new behavior implements an operation and depends on subtypes, which is not acceptable. Clarifications and possible spec corrections are highly appreciated. UML 2.5 beta spec says: . method : Behavior [0..*] (opposite Behavior::specification) A Behavior that implements the BehavioralFeature. There may be at most one Behavior for a particular pairing of a Classifier (as owner of the Behavior) and a BehavioralFeature (as specification of the Behavior). . specification : BehavioralFeature [0..1] (opposite BehavioralFeature::method) Designates a BehavioralFeature that the Behavior implements. The BehavioralFeature must be owned by the BehavioredClassifier that owns the Behavior or be inherited by it. The Parameters of the BehavioralFeature and the implementing Behavior must match. A Behavior does not need to have a specification, in which case it either is the classifierBehavior of a BehavioredClassifier or it can only be invoked by another Behavior of the Classifier. Proposed changes: 1. Don't constrain where behavior must be owned to implement operation. 2. Let the same behavior be a method of more than one Operation. 3. change the rules, how Behavior::context is derived (now it is derived from the chain of the owners, but could be derived from the specification owner or ActivityPartition's represented elements) or make it non-derived. 4. Allow one method only and use redefining Operations instead. Thanks, Nerijus From: "Rouquette, Nicolas F (313K)" To: Nerijus Jankevicius , Robert Karban CC: "sysml-rtf@omg.org (sysml-rtf@omg.org)" , "Lonnie VanZandt (lvanzandt@nomagic.com)" Subject: Re: problems with BehavioralFeature::method Thread-Topic: problems with BehavioralFeature::method Thread-Index: AQHOjsrzUCpkaqcKd0yrorN53Gd4GpmAfByAgAB4xoD//5zAgA== Date: Thu, 1 Aug 2013 16:53:14 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Nerijus, See below. From: Nerijus Jankevicius Date: Thursday, August 1, 2013 8:48 AM To: Nicolas Rouquette , Robert Karban Cc: "sysml-rtf@omg.org" , "Lonnie VanZandt (lvanzandt@nomagic.com)" Subject: Re: problems with BehavioralFeature::method Nicolas, With current metamodel, we can't do many things Sandy's book or Robert's cookbook suggests: 1. can't own behaviors in separate package (having Structure, Behaviors packages) It is possible: - Package-owned Behaviors cannot be ownedBehaviors of BehavioredClassifiers. - A specialization of a Package-owned Behavior can be an ownedBehavior of a BehavioredClassifier. 2. behaviors owned in packages have no context even if they are allocated to blocks. Again, I'm suggesting to specialize Package-owned Behaviors as a way of "allocating" or "mapping" them as contextualized ownedBehaviors of a BehavioredClassifier where they can be the specification of an operation. 3. we can't create Operations for all allocated behaviors, as a) they are not owned in Block, b) if same behavior is allocated to more than one block, it can't be use as method of two operations. Yes you can, as I've described above. Nicolas. Nerijus On Aug 1, 2013, at 6:36 PM, Rouquette, Nicolas F (313K) wrote: Nerijus, Relax.. The ssolution is to use the "Block-Specific Type" technique that I developed at JPL. Here's an example: Here, I want to use a state machine, SM1, as the method of two operations: A::op1() and B::op1(). Without specialization, you'd be correct . I'd have to choose one or the other but not both. That's a good thing! With specialization, the model is conceptually correct . that is, "A.op1 . SM1", ;, a specialization of SM1, represents semantically the specific behaviored classifier specifying the method of A::op1(). If you read Conrad's "Ontological Behavior Modeling" paper, you'll eventually realize that modeling behavior is no different than modeling structure. In either case, context matters. The notion of "part" makes sense ontologically if it represented using a "PropertySpecificType" (invented in SysML!) We're just applying this technique to contextualize everything. It makes many "contextualization"-related problems simpler . No need for NestedConnectorEnnd, InvocationOnNestedPortAction, ElementPropertyPath, etc.. Because everything is, by definition, contextualizedd such that each part plays ontologically a unique role for its owning classifier context. - Nicolas. From: Nerijus Jankevicius Date: Thursday, August 1, 2013 8:20 AM To: "uml25-ftf@omg.org" , "sysml-rtf@omg.org" Cc: "Lonnie VanZandt (lvanzandt@nomagic.com)" Subject: problems with BehavioralFeature::method Hello, We are experiencing problems while trying to support "functional allocations" - building behavioral/functional models separately from structural designs and reusing functions in alternative structural designs. The UML metamodel problems: 1. Behavior can't be owned "outside" Classifier owning the operation and used as it's method (so not behavior libraries are possible). 2. Behaviors can't be reused, cause it may have only one Operation ([0..1]) as specification (no reuse in alternative designs are possible) 3. Operation may have multiple methods ([0..*]) - redefining behaviors in subtypes. As a result, operation in super class is modified every time new behavior implements an operation and depends on subtypes, which is not acceptable. Clarifications and possible spec corrections are highly appreciated. UML 2.5 beta spec says: . method : Behavior [0..*] (opposite Behavior::specification) A Behavior that implements the BehavioralFeature. There may be at most one Behavior for a particular pairing of a Classifier (as owner of the Behavior) and a BehavioralFeature (as specification of the Behavior). . specification : BehavioralFeature [0..1] (opposite BehavioralFeature::method) Designates a BehavioralFeature that the Behavior implements. The BehavioralFeature must be owned by the BehavioredClassifier that owns the Behavior or be inherited by it. The Parameters of the BehavioralFeature and the implementing Behavior must match. A Behavior does not need to have a specification, in which case it either is the classifierBehavior of a BehavioredClassifier or it can only be invoked by another Behavior of the Classifier. Proposed changes: 1. Don't constrain where behavior must be owned to implement operation. 2. Let the same behavior be a method of more than one Operation. 3. change the rules, how Behavior::context is derived (now it is derived from the chain of the owners, but could be derived from the specification owner or ActivityPartition's represented elements) or make it non-derived. 4. Allow one method only and use redefining Operations instead. Thanks, Nerijus From: "Rouquette, Nicolas F (313K)" To: "Delligatti, Lenny" , Nerijus Jankevicius CC: "Lonnie VanZandt (lvanzandt@nomagic.com)" , "Robert Karban" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , "uml25-ftf@omg.org" Subject: Re: problems with BehavioralFeature::method Thread-Topic: problems with BehavioralFeature::method Thread-Index: AQHOjsrzUCpkaqcKd0yrorN53Gd4GpmAfByAgAB7RAD//6ItgA== Date: Thu, 1 Aug 2013 17:21:35 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org You're correct Lenny and for that, I sincerely apologize to you Nerijus. I over-reacted to the direction Nerijus' syntactic argument about the rigidity of the UML metamodel. UML does support the flexibility of reusing the same definition of uncontextualized Behavior as the specification of multiple methods. One possibility involves specializing and contextualizing that Behavior. In hindsight, that's all I should have said. - Nicolas. From: , Lenny Date: Thursday, August 1, 2013 8:57 AM To: Nicolas Rouquette Cc: "Lonnie VanZandt (lvanzandt@nomagic.com)" , Robert Karban , Nerijus Jankevicius , "sysml-rtf@omg.org" , "uml25-ftf@omg.org" Subject: RE: problems with BehavioralFeature::method Nicolas, Beginning an e-mail with .Relax. is generally not an effective way to make your audience receptive to your message. I mention this relatively minor faux pas now because it.s part of a larger pattern of abrasive communications from you over the past few years. We all recognize your extraordinary expertise in this subject. Reciprocally recognize our expertise as well.whether relative differences exist or not. When one of us raises a concern, please address it in a way that doesn.t sound condescending. You would want us to do the same for you. Thank you for the work you do and the insights you share. I always value them. Sincerely, Lenny Lenny Delligatti, M.S., OCUP, OCSMP Advanced OMG Certified Systems Modeling Professional OMG Certified UML Professional Senior Systems Engineer, NASA Mission Control System Lockheed Martin (IS&GS-Civil Programs) (281) 853-3726 lenny.delligatti@lmco.com OCUP Advanced (resized2) OCSMP Advanced (resized2) .Though evil can.t be eliminated, it can be overwhelmed. For each act of evil and good that you observe in the world, perform an act of good with equal or greater impact.. From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, August 01, 2013 10:36 AM To: Nerijus Jankevicius; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Lonnie VanZandt (lvanzandt@nomagic.com); Robert Karban Subject: EXTERNAL: Re: problems with BehavioralFeature::method Nerijus, Relax.. The solution is to use the "Block-Specific Type" technique that I developed at JPL. Here's an example: Here, I want to use a state machine, SM1, as the method of two operations: A::op1() and B::op1(). Without specialization, you'd be correct . I'd have to choose one or the other but not both. That's a good thing! With specialization, the model is conceptually correct . that is, "A.op1 . SM1", a specialization of SM1, represents semantically the specific behaviored classifier specifying the method of A::op1(). If you read Conrad's "Ontological Behavior Modeling" paper, you'll eventually realize that modeling behavior is no different than modeling structure. In either case, context matters. The notion of "part" makes sense ontologically if it represented using a "PropertySpecificType" (invented in SysML!) We're just applying this technique to contextualize everything. It makes many "contextualization"-related problems simpler . No need for NestedConnectorEnd, InvocationOnNestedPortAction, ElementPropertyPath, etc.. Because everything is, by definition, contextualized such that each part plays ontologically a unique role for its owning classifier context. - Nicolas. From: Nerijus Jankevicius Date: Thursday, August 1, 2013 8:20 AM To: "uml25-ftf@omg.org" , "sysml-rtf@omg.org" Cc: "Lonnie VanZandt (lvanzandt@nomagic.com)" Subject: problems with BehavioralFeature::method Hello, We are experiencing problems while trying to support "functional allocations" - building behavioral/functional models separately from structural designs and reusing functions in alternative structural designs. The UML metamodel problems: 1. Behavior can't be owned "outside" Classifier owning the operation and used as it's method (so not behavior libraries are possible). 2. Behaviors can't be reused, cause it may have only one Operation ([0..1]) as specification (no reuse in alternative designs are possible) 3. Operation may have multiple methods ([0..*]) - redefining behaviors in subtypes. As a result, operation in super class is modified every time new behavior implements an operation and depends on subtypes, which is not acceptable. Clarifications and possible spec corrections are highly appreciated. UML 2.5 beta spec says: · method : Behavior [0..*] (opposite Behavior::specification) A Behavior that implements the BehavioralFeature. There may be at most one Behavior for a particular pairing of a Classifier (as owner of the Behavior) and a BehavioralFeature (as specification of the Behavior). · specification : BehavioralFeature [0..1] (opposite BehavioralFeature::method) Designates a BehavioralFeature that the Behavior implements. The BehavioralFeature must be owned by the BehavioredClassifier that owns the Behavior or be inherited by it. The Parameters of the BehavioralFeature and the implementing Behavior must match. A Behavior does not need to have a specification, in which case it either is the classifierBehavior of a BehavioredClassifier or it can only be invoked by another Behavior of the Classifier. Proposed changes: 1. Don't constrain where behavior must be owned to implement operation. 2. Let the same behavior be a method of more than one Operation. 3. change the rules, how Behavior::context is derived (now it is derived from the chain of the owners, but could be derived from the specification owner or ActivityPartition's represented elements) or make it non-derived. 4. Allow one method only and use redefining Operations instead. Thanks, Nerijus image001.jpg image002.jpg image003.png From: "Delp, Christopher L (313K)" To: Nerijus Jankevicius , "Rouquette, Nicolas F (313K)" , Robert Karban CC: "sysml-rtf@omg.org (sysml-rtf@omg.org)" , "Lonnie VanZandt (lvanzandt@nomagic.com)" Subject: RE: problems with BehavioralFeature::method Thread-Topic: problems with BehavioralFeature::method Thread-Index: AQHOjsrztc/+abRC4USCxzXigfbrJ5mA8XYAgAADbID//47mwA== Date: Thu, 1 Aug 2013 17:37:07 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] X-Source-Sender: Christopher.L.Delp@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org I think Nick is saying that with BST . you can redefine them in aa local context. Its more overhead . but it alllows a separate reusable definition with specific implementations in the implementation context. From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Thursday, August 01, 2013 8:48 AM To: Rouquette, Nicolas F (313K); Robert Karban Cc: sysml-rtf@omg.org (sysml-rtf@omg.org); Lonnie VanZandt (lvanzandt@nomagic.com) Subject: Re: problems with BehavioralFeature::method Nicolas, With current metamodel, we can't do many things Sandy's book or Robert's cookbook suggests: 1. can't own behaviors in separate package (having Structure, Behaviors packages) 2. behaviors owned in packages have no context even if they are allocated to blocks. 3. we can't create Operations for all allocated behaviors, as a) they are not owned in Block, b) if same behavior is allocated to more than one block, it can't be use as method of two operations. Nerijus On Aug 1, 2013, at 6:36 PM, Rouquette, Nicolas F (313K) wrote: Nerijus, Relax.. The solution is to use the "Block-Specific Type" technique that I developed at JPL. Here's an example: Here, I want to use a state machine, SM1, as the method of two operations: A::op1() and B::op1(). Without specialization, you'd be correct . I'd have to choose one or the other but not both. That's a good thing! With specialization, the model is conceptually correct . that is, "A.op1 . SM1", a specializatzation of SM1, represents semantically the specific behaviored classifier specifying the method of A::op1(). If you read Conrad's "Ontological Behavior Modeling" paper, you'll eventually realize that modeling behavior is no different than modeling structure. In either case, context matters. The notion of "part" makes sense ontologically if it represented using a "PropertySpecificType" (invented in SysML!) We're just applying this technique to contextualize everything. It makes many "contextualization"-related problems simpler . No need for NestedConnecttorEnd, InvocationOnNestedPortAction, ElementPropertyPath, etc.. Because everything is, by definition, contextuualized such that each part plays ontologically a unique role for its owning classifier context. - Nicolas. From: Nerijus Jankevicius Date: Thursday, August 1, 2013 8:20 AM To: "uml25-ftf@omg.org" , "sysml-rtf@omg.org" Cc: "Lonnie VanZandt (lvanzandt@nomagic.com)" Subject: problems with BehavioralFeature::method Hello, We are experiencing problems while trying to support "functional allocations" - building behavioral/functional models separately from structural designs and reusing functions in alternative structural designs. The UML metamodel problems: 1. Behavior can't be owned "outside" Classifier owning the operation and used as it's method (so not behavior libraries are possible). 2. Behaviors can't be reused, cause it may have only one Operation ([0..1]) as specification (no reuse in alternative designs are possible) 3. Operation may have multiple methods ([0..*]) - redefining behaviors in subtypes. As a result, operation in super class is modified every time new behavior implements an operation and depends on subtypes, which is not acceptable. Clarifications and possible spec corrections are highly appreciated. UML 2.5 beta spec says: · method : Behavior [0..*] (opposite Behavior::specification) A Behavior that implements the BehavioralFeature. There may be at most one Behavior for a particular pairing of a Classifier (as owner of the Behavior) and a BehavioralFeature (as specification of the Behavior). · specification : BehavioralFeature [0..1] (opposite BehavioralFeature::method) Designates a BehavioralFeature that the Behavior implements. The BehavioralFeature must be owned by the BehavioredClassifier that owns the Behavior or be inherited by it. The Parameters of the BehavioralFeature and the implementing Behavior must match. A Behavior does not need to have a specification, in which case it either is the classifierBehavior of a BehavioredClassifier or it can only be invoked by another Behavior of the Classifier. Proposed changes: 1. Don't constrain where behavior must be owned to implement operation. 2. Let the same behavior be a method of more than one Operation. 3. change the rules, how Behavior::context is derived (now it is derived from the chain of the owners, but could be derived from the specification owner or ActivityPartition's represented elements) or make it non-derived. 4. Allow one method only and use redefining Operations instead. Thanks, Nerijus From: "Wendland, Marc-Florian" To: "Rouquette, Nicolas F (313K)" , "Delligatti, Lenny" , Nerijus Jankevicius CC: "Lonnie VanZandt (lvanzandt@nomagic.com)" , "Robert Karban" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , "uml25-ftf@omg.org" Subject: AW: problems with BehavioralFeature::method Thread-Topic: problems with BehavioralFeature::method Thread-Index: AQHOjsrXd+lxjZBf1kuR9CUhea3NIJmAWpYAgAAF6gCAABeIgIABbrTA Date: Fri, 2 Aug 2013 13:25:11 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [195.37.77.169] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean X-cloud-security-sender: marc-florian.wendland@fokus.fraunhofer.de X-cloud-security-recipient: uml25-ftf@omg.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate12-dus with 576C02421A X-cloud-security-connect: pluto.fokus.fraunhofer.de[195.37.77.164], TLS=, IP=195.37.77.164 X-cloud-security: scantime:.4888 X-Virus-Scanned: amavisd-new at omg.org Hi all, back to the content of Nerijus. mail: I must admit I like most of what Nerijus requested. In my opinion the constraint that the Behavior method of an BehavioralFeature must be contained in the context of the BehavioralFeature is indeed too restrictive on modeling level. The idea Nicolas presented is a nice workaround (I have not considered before), but the model gets polluted with redundant information just for the sake of contextualization. However, it resembles too much OOP languages, for my liking. At that level of abstraction I actually will not care where the Behavior I.d like to use as method for a BehavioralFeature is contained. Actually, I.m certain is not relevant at all, where it is contained. As soon as I reference a Behavior as method, it will be implicitly contextualized in the scope of the respective classifier. So, I.d would like to see a more flexible (and less redundant) solution similar to what Nerijus suggested. Just my two cents. Regards, Marc-Florian Von: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Gesendet: Donnerstag, 1. August 2013 19:22 An: Delligatti, Lenny; Nerijus Jankevicius Cc: Lonnie VanZandt (lvanzandt@nomagic.com); Robert Karban; sysml-rtf@omg.org (sysml-rtf@omg.org); uml25-ftf@omg.org Betreff: Re: problems with BehavioralFeature::method You're correct Lenny and for that, I sincerely apologize to you Nerijus. I over-reacted to the direction Nerijus' syntactic argument about the rigidity of the UML metamodel. UML does support the flexibility of reusing the same definition of uncontextualized Behavior as the specification of multiple methods. One possibility involves specializing and contextualizing that Behavior. In hindsight, that's all I should have said. - Nicolas. From: , Lenny Date: Thursday, August 1, 2013 8:57 AM To: Nicolas Rouquette Cc: "Lonnie VanZandt (lvanzandt@nomagic.com)" , Robert Karban , Nerijus Jankevicius , "sysml-rtf@omg.org" , "uml25-ftf@omg.org" Subject: RE: problems with BehavioralFeature::method Nicolas, Beginning an e-mail with .Relax. is generally not an effective way to make your audience receptive to your message. I mention this relatively minor faux pas now because it.s part of a larger pattern of abrasive communications from you over the past few years. We all recognize your extraordinary expertise in this subject. Reciprocally recognize our expertise as well.whether relative differences exist or not. When one of us raises a concern, please address it in a way that doesn.t sound condescending. You would want us to do the same for you. Thank you for the work you do and the insights you share. I always value them. Sincerely, Lenny Lenny Delligatti, M.S., OCUP, OCSMP Advanced OMG Certified Systems Modeling Professional OMG Certified UML Professional Senior Systems Engineer, NASA Mission Control System Lockheed Martin (IS&GS-Civil Programs) (281) 853-3726 lenny.delligatti@lmco.com OCUP Advanced (resized2) OCSMP Advanced (resized2) .Though evil can.t be eliminated, it can be overwhelmed. For each act of evil and good that you observe in the world, perform an act of good with equal or greater impact.. From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, August 01, 2013 10:36 AM To: Nerijus Jankevicius; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Lonnie VanZandt (lvanzandt@nomagic.com); Robert Karban Subject: EXTERNAL: Re: problems with BehavioralFeature::method Nerijus, Relax.. The solution is to use the "Block-Specific Type" technique that I developed at JPL. Here's an example: Here, I want to use a state machine, SM1, as the method of two operations: A::op1() and B::op1(). Without specialization, you'd be correct . I'd have to choose one or the other but not both. That's a good thing! With specialization, the model is conceptually correct . that is, "A.op1 . SM1", a specialization of SM1, represents semantically the specific behaviored classifier specifying the method of A::op1(). If you read Conrad's "Ontological Behavior Modeling" paper, you'll eventually realize that modeling behavior is no different than modeling structure. In either case, context matters. The notion of "part" makes sense ontologically if it represented using a "PropertySpecificType" (invented in SysML!) We're just applying this technique to contextualize everything. It makes many "contextualization"-related problems simpler . No need for NestedConnectorEnd, InvocationOnNestedPortAction, ElementPropertyPath, etc.. Because everything is, by definition, contextualized such that each part plays ontologically a unique role for its owning classifier context. - Nicolas. From: Nerijus Jankevicius Date: Thursday, August 1, 2013 8:20 AM To: "uml25-ftf@omg.org" , "sysml-rtf@omg.org" Cc: "Lonnie VanZandt (lvanzandt@nomagic.com)" Subject: problems with BehavioralFeature::method Hello, We are experiencing problems while trying to support "functional allocations" - building behavioral/functional models separately from structural designs and reusing functions in alternative structural designs. The UML metamodel problems: 1. Behavior can't be owned "outside" Classifier owning the operation and used as it's method (so not behavior libraries are possible). 2. Behaviors can't be reused, cause it may have only one Operation ([0..1]) as specification (no reuse in alternative designs are possible) 3. Operation may have multiple methods ([0..*]) - redefining behaviors in subtypes. As a result, operation in super class is modified every time new behavior implements an operation and depends on subtypes, which is not acceptable. Clarifications and possible spec corrections are highly appreciated. UML 2.5 beta spec says: · method : Behavior [0..*] (opposite Behavior::specification) A Behavior that implements the BehavioralFeature. There may be at most one Behavior for a particular pairing of a Classifier (as owner of the Behavior) and a BehavioralFeature (as specification of the Behavior). · specification : BehavioralFeature [0..1] (opposite BehavioralFeature::method) Designates a BehavioralFeature that the Behavior implements. The BehavioralFeature must be owned by the BehavioredClassifier that owns the Behavior or be inherited by it. The Parameters of the BehavioralFeature and the implementing Behavior must match. A Behavior does not need to have a specification, in which case it either is the classifierBehavior of a BehavioredClassifier or it can only be invoked by another Behavior of the Classifier. Proposed changes: 1. Don't constrain where behavior must be owned to implement operation. 2. Let the same behavior be a method of more than one Operation. 3. change the rules, how Behavior::context is derived (now it is derived from the chain of the owners, but could be derived from the specification owner or ActivityPartition's represented elements) or make it non-derived. 4. Allow one method only and use redefining Operations instead. Thanks, Nerijus From: "Rouquette, Nicolas F (313K)" To: "Wendland, Marc-Florian" , "Delligatti, Lenny" , Nerijus Jankevicius CC: "Lonnie VanZandt (lvanzandt@nomagic.com)" , "Robert Karban" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , "uml25-ftf@omg.org" Subject: Re: AW: problems with BehavioralFeature::method Thread-Topic: AW: problems with BehavioralFeature::method Thread-Index: AQHOjsrzUCpkaqcKd0yrorN53Gd4GpmAfByAgAB7RAD//6ItgIABxaOA//+WiwA= Date: Fri, 2 Aug 2013 14:07:45 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Marc-Florian, Can you provide a compelling example for what you're asking for? - Nicolas. From: , Marc-Florian Date: Friday, August 2, 2013 6:25 AM To: Nicolas Rouquette , "Delligatti, Lenny" , Nerijus Jankevicius Cc: "Lonnie VanZandt (lvanzandt@nomagic.com)" , Robert Karban , "sysml-rtf@omg.org" , "uml25-ftf@omg.org" Subject: AW: problems with BehavioralFeature::method Hi all, back to the content of Nerijus. mail: I must admit I like most of what Nerijus requested. In my opinion the constraint that the Behavior method of an BehavioralFeature must be contained in the context of the BehavioralFeature is indeed too restrictive on modeling level. The idea Nicolas presented is a nice workaround (I have not considered before), but the model gets polluted with redundant information just for the sake of contextualization. However, it resembles too much OOP languages, for my liking. At that level of abstraction I actually will not care where the Behavior I.d like to use as method for a BehavioralFeature is contained. Actually, I.m certain is not relevant at all, where it is contained. As soon as I reference a Behavior as method, it will be implicitly contextualized in the scope of the respective classifier. So, I.d would like to see a more flexible (and less redundant) solution similar to what Nerijus suggested. Just my two cents. Regards, Marc-Florian Von: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Gesendet: Donnerstag, 1. August 2013 19:22 An: Delligatti, Lenny; Nerijus Jankevicius Cc: Lonnie VanZandt (lvanzandt@nomagic.com); Robert Karban; sysml-rtf@omg.org (sysml-rtf@omg.org); uml25-ftf@omg.org Betreff: Re: problems with BehavioralFeature::method You're correct Lenny and for that, I sincerely apologize to you Nerijus. I over-reacted to the direction Nerijus' syntactic argument about the rigidity of the UML metamodel. UML does support the flexibility of reusing the same definition of uncontextualized Behavior as the specification of multiple methods. One possibility involves specializing and contextualizing that Behavior. In hindsight, that's all I should have said. - Nicolas. From: , Lenny Date: Thursday, August 1, 2013 8:57 AM To: Nicolas Rouquette Cc: "Lonnie VanZandt (lvanzandt@nomagic.com)" , Robert Karban , Nerijus Jankevicius , "sysml-rtf@omg.org" , "uml25-ftf@omg.org" Subject: RE: problems with BehavioralFeature::method Nicolas, Beginning an e-mail with .Relax. is generally not an effective way to make your audience receptive to your message. I mention this relatively minor faux pas now because it.s part of a larger pattern of abrasive communications from you over the past few years. We all recognize your extraordinary expertise in this subject. Reciprocally recognize our expertise as well.whether relative differences exist or not. When one of us raises a concern, please address it in a way that doesn.t sound condescending. You would want us to do the same for you. Thank you for the work you do and the insights you share. I always value them. Sincerely, Lenny Lenny Delligatti, M.S., OCUP, OCSMP Advanced OMG Certified Systems Modeling Professional OMG Certified UML Professional Senior Systems Engineer, NASA Mission Control System Lockheed Martin (IS&GS-Civil Programs) (281) 853-3726 lenny.delligatti@lmco.com OCUP Advanced (resized2) OCSMP Advanced (resized2) .Though evil can.t be eliminated, it can be overwhelmed. For each act of evil and good that you observe in the world, perform an act of good with equal or greater impact.. From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, August 01, 2013 10:36 AM To: Nerijus Jankevicius; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Lonnie VanZandt (lvanzandt@nomagic.com); Robert Karban Subject: EXTERNAL: Re: problems with BehavioralFeature::method Nerijus, Relax.. The solution is to use the "Block-Specific Type" technique that I developed at JPL. Here's an example: Here, I want to use a state machine, SM1, as the method of two operations: A::op1() and B::op1(). Without specialization, you'd be correct . I'd have to choose one or the other but not both. That's a good thing! With specialization, the model is conceptually correct . that is, "A.op1 . SM1", a specialization of SM1, represents semantically the specific behaviored classifier specifying the method of A::op1(). If you read Conrad's "Ontological Behavior Modeling" paper, you'll eventually realize that modeling behavior is no different than modeling structure. In either case, context matters. The notion of "part" makes sense ontologically if it represented using a "PropertySpecificType" (invented in SysML!) We're just applying this technique to contextualize everything. It makes many "contextualization"-related problems simpler . No need for NestedConnectorEnd, InvocationOnNestedPortAction, ElementPropertyPath, etc.. Because everything is, by definition, contextualized such that each part plays ontologically a unique role for its owning classifier context. - Nicolas. From: Nerijus Jankevicius Date: Thursday, August 1, 2013 8:20 AM To: "uml25-ftf@omg.org" , "sysml-rtf@omg.org" Cc: "Lonnie VanZandt (lvanzandt@nomagic.com)" Subject: problems with BehavioralFeature::method Hello, We are experiencing problems while trying to support "functional allocations" - building behavioral/functional models separately from structural designs and reusing functions in alternative structural designs. The UML metamodel problems: 1. Behavior can't be owned "outside" Classifier owning the operation and used as it's method (so not behavior libraries are possible). 2. Behaviors can't be reused, cause it may have only one Operation ([0..1]) as specification (no reuse in alternative designs are possible) 3. Operation may have multiple methods ([0..*]) - redefining behaviors in subtypes. As a result, operation in super class is modified every time new behavior implements an operation and depends on subtypes, which is not acceptable. Clarifications and possible spec corrections are highly appreciated. UML 2.5 beta spec says: · method : Behavior [0..*] (opposite Behavior::specification) A Behavior that implements the BehavioralFeature. There may be at most one Behavior for a particular pairing of a Classifier (as owner of the Behavior) and a BehavioralFeature (as specification of the Behavior). · specification : BehavioralFeature [0..1] (opposite BehavioralFeature::method) Designates a BehavioralFeature that the Behavior implements. The BehavioralFeature must be owned by the BehavioredClassifier that owns the Behavior or be inherited by it. The Parameters of the BehavioralFeature and the implementing Behavior must match. A Behavior does not need to have a specification, in which case it either is the classifierBehavior of a BehavioredClassifier or it can only be invoked by another Behavior of the Classifier. Proposed changes: 1. Don't constrain where behavior must be owned to implement operation. 2. Let the same behavior be a method of more than one Operation. 3. change the rules, how Behavior::context is derived (now it is derived from the chain of the owners, but could be derived from the specification owner or ActivityPartition's represented elements) or make it non-derived. 4. Allow one method only and use redefining Operations instead. Thanks, Nerijus image0011.jpg image0021.jpg image0031.png X-Trusted-NM: yes Subject: Re: AW: problems with BehavioralFeature::method From: Nerijus Jankevicius Date: Fri, 2 Aug 2013 17:11:33 +0300 Cc: "Wendland, Marc-Florian" , "Delligatti, Lenny" , "Lonnie VanZandt (lvanzandt@nomagic.com)" , "Robert Karban" , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , "uml25-ftf@omg.org" To: "Rouquette, Nicolas F (313K)" X-Mailer: Apple Mail (2.1085) X-Virus-Scanned: amavisd-new at omg.org Nicolas, The main request is to allow using Behavior B owned in package P as a method of Operation op() of Class C owned in package P1. Nerijus On Aug 2, 2013, at 5:07 PM, Rouquette, Nicolas F (313K) wrote: Marc-Florian, Can you provide a compelling example for what you're asking for? - Nicolas. From: , Marc-Florian Date: Friday, August 2, 2013 6:25 AM To: Nicolas Rouquette , "Delligatti, Lenny" , Nerijus Jankevicius Cc: "Lonnie VanZandt (lvanzandt@nomagic.com)" , Robert Karban , "sysml-rtf@omg.org" , "uml25-ftf@omg.org" Subject: AW: problems with BehavioralFeature::method Hi all, back to the content of Nerijus. mail: I must admit I like most of what Nerijus requested. In my opinion the constraint that the Behavior method of an BehavioralFeature must be contained in the context of the BehavioralFeature is indeed too restrictive on modeling level. The idea Nicolas presented is a nice workaround (I have not considered before), but the model gets polluted with redundant information just for the sake of contextualization. However, it resembles too much OOP languages, for my liking. At that level of abstraction I actually will not care where the Behavior I.d like to use as method for a BehavioralFeature is contained. Actually, I.m certain is not relevant at all, where it is contained. As soon as I reference a Behavior as method, it will be implicitly contextualized in the scope of the respective classifier. So, I.d would like to see a more flexible (and less redundant) solution similar to what Nerijus suggested. Just my two cents. Regards, Marc-Florian Von: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Gesendet: Donnerstag, 1. August 2013 19:22 An: Delligatti, Lenny; Nerijus Jankevicius Cc: Lonnie VanZandt (lvanzandt@nomagic.com); Robert Karban; sysml-rtf@omg.org (sysml-rtf@omg.org); uml25-ftf@omg.org Betreff: Re: problems with BehavioralFeature::method You're correct Lenny and for that, I sincerely apologize to you Nerijus. I over-reacted to the direction Nerijus' syntactic argument about the rigidity of the UML metamodel. UML does support the flexibility of reusing the same definition of uncontextualized Behavior as the specification of multiple methods. One possibility involves specializing and contextualizing that Behavior. In hindsight, that's all I should have said. - Nicolas. From: , Lenny Date: Thursday, August 1, 2013 8:57 AM To: Nicolas Rouquette Cc: "Lonnie VanZandt (lvanzandt@nomagic.com)" , Robert Karban , Nerijus Jankevicius , "sysml-rtf@omg.org" , "uml25-ftf@omg.org" Subject: RE: problems with BehavioralFeature::method Nicolas, Beginning an e-mail with .Relax. is generally not an effective way to make your audience receptive to your message. I mention this relatively minor faux pas now because it.s part of a larger pattern of abrasive communications from you over the past few years. We all recognize your extraordinary expertise in this subject. Reciprocally recognize our expertise as well.whether relative differences exist or not. When one of us raises a concern, please address it in a way that doesn.t sound condescending. You would want us to do the same for you. Thank you for the work you do and the insights you share. I always value them. Sincerely, Lenny Lenny Delligatti, M.S., OCUP, OCSMP Advanced OMG Certified Systems Modeling Professional OMG Certified UML Professional Senior Systems Engineer, NASA Mission Control System Lockheed Martin (IS&GS-Civil Programs) (281) 853-3726 lenny.delligatti@lmco.com .Though evil can.t be eliminated, it can be overwhelmed. For each act of evil and good that you observe in the world, perform an act of good with equal or greater impact.. From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, August 01, 2013 10:36 AM To: Nerijus Jankevicius; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Lonnie VanZandt (lvanzandt@nomagic.com); Robert Karban Subject: EXTERNAL: Re: problems with BehavioralFeature::method Nerijus, Relax.. The solution is to use the "Block-Specific Type" technique that I developed at JPL. Here's an example: Here, I want to use a state machine, SM1, as the method of two operations: A::op1() and B::op1(). Without specialization, you'd be correct . I'd have to choose one or the other but not both. That's a good thing! With specialization, the model is conceptually correct . that is, "A.op1 . SM1", a specialization of SM1, represents semantically the specific behaviored classifier specifying the method of A::op1(). If you read Conrad's "Ontological Behavior Modeling" paper, you'll eventually realize that modeling behavior is no different than modeling structure. In either case, context matters. The notion of "part" makes sense ontologically if it represented using a "PropertySpecificType" (invented in SysML!) We're just applying this technique to contextualize everything. It makes many "contextualization"-related problems simpler . No need for NestedConnectorEnd, InvocationOnNestedPortAction, ElementPropertyPath, etc.. Because everything is, by definition, contextualized such that each part plays ontologically a unique role for its owning classifier context. - Nicolas. From: Nerijus Jankevicius Date: Thursday, August 1, 2013 8:20 AM To: "uml25-ftf@omg.org" , "sysml-rtf@omg.org" Cc: "Lonnie VanZandt (lvanzandt@nomagic.com)" Subject: problems with BehavioralFeature::method Hello, We are experiencing problems while trying to support "functional allocations" - building behavioral/functional models separately from structural designs and reusing functions in alternative structural designs. The UML metamodel problems: 1. Behavior can't be owned "outside" Classifier owning the operation and used as it's method (so not behavior libraries are possible). 2. Behaviors can't be reused, cause it may have only one Operation ([0..1]) as specification (no reuse in alternative designs are possible) 3. Operation may have multiple methods ([0..*]) - redefining behaviors in subtypes. As a result, operation in super class is modified every time new behavior implements an operation and depends on subtypes, which is not acceptable. Clarifications and possible spec corrections are highly appreciated. UML 2.5 beta spec says: · method : Behavior [0..*] (opposite Behavior::specification) A Behavior that implements the BehavioralFeature. There may be at most one Behavior for a particular pairing of a Classifier (as owner of the Behavior) and a BehavioralFeature (as specification of the Behavior). · specification : BehavioralFeature [0..1] (opposite BehavioralFeature::method) Designates a BehavioralFeature that the Behavior implements. The BehavioralFeature must be owned by the BehavioredClassifier that owns the Behavior or be inherited by it. The Parameters of the BehavioralFeature and the implementing Behavior must match. A Behavior does not need to have a specification, in which case it either is the classifierBehavior of a BehavioredClassifier or it can only be invoked by another Behavior of the Classifier. Proposed changes: 1. Don't constrain where behavior must be owned to implement operation. 2. Let the same behavior be a method of more than one Operation. 3. change the rules, how Behavior::context is derived (now it is derived from the chain of the owners, but could be derived from the specification owner or ActivityPartition's represented elements) or make it non-derived. 4. Allow one method only and use redefining Operations instead. Thanks, Nerijus From: "Rouquette, Nicolas F (313K)" To: Nerijus Jankevicius CC: "Wendland, Marc-Florian" , "Delligatti, Lenny" , "Lonnie VanZandt (lvanzandt@nomagic.com)" , Robert Karban , "sysml-rtf@omg.org (sysml-rtf@omg.org)" , "uml25-ftf@omg.org" Subject: Re: AW: problems with BehavioralFeature::method Thread-Topic: AW: problems with BehavioralFeature::method Thread-Index: AQHOjsrzUCpkaqcKd0yrorN53Gd4GpmAfByAgAB7RAD//6ItgIABxaOA//+WiwCAAHZpgP//mQuA Date: Fri, 2 Aug 2013 15:03:04 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Nerijus, Is B completely agnostic of C? That is, are you assuming/expecting that B makes no reference to any structural feature of C? If yes, then is what you're asking functionally equivalent to defining a trivial behavior as the method of op() that invokes B? - Nicolas. From: Nerijus Jankevicius Date: Friday, August 2, 2013 7:11 AM To: Nicolas Rouquette Cc: "Wendland, Marc-Florian" , "Delligatti, Lenny" , "Lonnie VanZandt (lvanzandt@nomagic.com)" , Robert Karban , "sysml-rtf@omg.org" , "uml25-ftf@omg.org" Subject: Re: AW: problems with BehavioralFeature::method Nicolas, The main request is to allow using Behavior B owned in package P as a method of Operation op() of Class C owned in package P1. Nerijus On Aug 2, 2013, at 5:07 PM, Rouquette, Nicolas F (313K) wrote: Marc-Florian, Can you provide a compelling example for what you're asking for? - Nicolas. From: , Marc-Florian Date: Friday, August 2, 2013 6:25 AM To: Nicolas Rouquette , "Delligatti, Lenny" , Nerijus Jankevicius Cc: "Lonnie VanZandt (lvanzandt@nomagic.com)" , Robert Karban , "sysml-rtf@omg.org" , "uml25-ftf@omg.org" Subject: AW: problems with BehavioralFeature::method Hi all, back to the content of Nerijus. mail: I must admit I like most of what Nerijus requested. In my opinion the constraint that the Behavior method of an BehavioralFeature must be contained in the context of the BehavioralFeature is indeed too restrictive on modeling level. The idea Nicolas presented is a nice workaround (I have not considered before), but the model gets polluted with redundant information just for the sake of contextualization. However, it resembles too much OOP languages, for my liking. At that level of abstraction I actually will not care where the Behavior I.d like to use as method for a BehavioralFeature is contained. Actually, I.m certain is not relevant at all, where it is contained. As soon as I reference a Behavior as method, it will be implicitly contextualized in the scope of the respective classifier. So, I.d would like to see a more flexible (and less redundant) solution similar to what Nerijus suggested. Just my two cents. Regards, Marc-Florian Von: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Gesendet: Donnerstag, 1. August 2013 19:22 An: Delligatti, Lenny; Nerijus Jankevicius Cc: Lonnie VanZandt (lvanzandt@nomagic.com); Robert Karban; sysml-rtf@omg.org (sysml-rtf@omg.org); uml25-ftf@omg.org Betreff: Re: problems with BehavioralFeature::method You're correct Lenny and for that, I sincerely apologize to you Nerijus. I over-reacted to the direction Nerijus' syntactic argument about the rigidity of the UML metamodel. UML does support the flexibility of reusing the same definition of uncontextualized Behavior as the specification of multiple methods. One possibility involves specializing and contextualizing that Behavior. In hindsight, that's all I should have said. - Nicolas. From: , Lenny Date: Thursday, August 1, 2013 8:57 AM To: Nicolas Rouquette Cc: "Lonnie VanZandt (lvanzandt@nomagic.com)" , Robert Karban , Nerijus Jankevicius , "sysml-rtf@omg.org" , "uml25-ftf@omg.org" Subject: RE: problems with BehavioralFeature::method Nicolas, Beginning an e-mail with .Relax. is generally not an effective way to make your audience receptive to your message. I mention this relatively minor faux pas now because it.s part of a larger pattern of abrasive communications from you over the past few years. We all recognize your extraordinary expertise in this subject. Reciprocally recognize our expertise as well.whether relative differences exist or not. When one of us raises a concern, please address it in a way that doesn.t sound condescending. You would want us to do the same for you. Thank you for the work you do and the insights you share. I always value them. Sincerely, Lenny Lenny Delligatti, M.S., OCUP, OCSMP Advanced OMG Certified Systems Modeling Professional OMG Certified UML Professional Senior Systems Engineer, NASA Mission Control System Lockheed Martin (IS&GS-Civil Programs) (281) 853-3726 lenny.delligatti@lmco.com .Though evil can.t be eliminated, it can be overwhelmed. For each act of evil and good that you observe in the world, perform an act of good with equal or greater impact.. From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, August 01, 2013 10:36 AM To: Nerijus Jankevicius; uml25-ftf@omg.org; sysml-rtf@omg.org (sysml-rtf@omg.org) Cc: Lonnie VanZandt (lvanzandt@nomagic.com); Robert Karban Subject: EXTERNAL: Re: problems with BehavioralFeature::method Nerijus, Relax.. The solution is to use the "Block-Specific Type" technique that I developed at JPL. Here's an example: Here, I want to use a state machine, SM1, as the method of two operations: A::op1() and B::op1(). Without specialization, you'd be correct . I'd have to choose one or the other but not both. That's a good thing! With specialization, the model is conceptually correct . that is, "A.op1 . SM1", a specialization of SM1, represents semantically the specific behaviored classifier specifying the method of A::op1(). If you read Conrad's "Ontological Behavior Modeling" paper, you'll eventually realize that modeling behavior is no different than modeling structure. In either case, context matters. The notion of "part" makes sense ontologically if it represented using a "PropertySpecificType" (invented in SysML!) We're just applying this technique to contextualize everything. It makes many "contextualization"-related problems simpler . No need for NestedConnectorEnd, InvocationOnNestedPortAction, ElementPropertyPath, etc.. Because everything is, by definition, contextualized such that each part plays ontologically a unique role for its owning classifier context. - Nicolas. From: Nerijus Jankevicius Date: Thursday, August 1, 2013 8:20 AM To: "uml25-ftf@omg.org" , "sysml-rtf@omg.org" Cc: "Lonnie VanZandt (lvanzandt@nomagic.com)" Subject: problems with BehavioralFeature::method Hello, We are experiencing problems while trying to support "functional allocations" - building behavioral/functional models separately from structural designs and reusing functions in alternative structural designs. The UML metamodel problems: 1. Behavior can't be owned "outside" Classifier owning the operation and used as it's method (so not behavior libraries are possible). 2. Behaviors can't be reused, cause it may have only one Operation ([0..1]) as specification (no reuse in alternative designs are possible) 3. Operation may have multiple methods ([0..*]) - redefining behaviors in subtypes. As a result, operation in super class is modified every time new behavior implements an operation and depends on subtypes, which is not acceptable. Clarifications and possible spec corrections are highly appreciated. UML 2.5 beta spec says: · method : Behavior [0..*] (opposite Behavior::specification) A Behavior that implements the BehavioralFeature. There may be at most one Behavior for a particular pairing of a Classifier (as owner of the Behavior) and a BehavioralFeature (as specification of the Behavior). · specification : BehavioralFeature [0..1] (opposite BehavioralFeature::method) Designates a BehavioralFeature that the Behavior implements. The BehavioralFeature must be owned by the BehavioredClassifier that owns the Behavior or be inherited by it. The Parameters of the BehavioralFeature and the implementing Behavior must match. A Behavior does not need to have a specification, in which case it either is the classifierBehavior of a BehavioredClassifier or it can only be invoked by another Behavior of the Classifier. Proposed changes: 1. Don't constrain where behavior must be owned to implement operation. 2. Let the same behavior be a method of more than one Operation. 3. change the rules, how Behavior::context is derived (now it is derived from the chain of the owners, but could be derived from the specification owner or ActivityPartition's represented elements) or make it non-derived. 4. Allow one method only and use redefining Operations instead. Thanks, Nerijus