Issue 15112: Inheriting Allocations (sysml-rtf) Source: (Mr. Sanford A. Friedenthal, ) Nature: Uncategorized Issue Severity: Summary: The allocated stereotype includes properties «allocatedTo» and «allocatedFrom». Since these properties are stereotype properties, they are not inherited by the classifiers that they are applied to. A constraint could be applied to either the allocate or allocated stereotype which would impose that it is automatically applied to all subclasses of the classifier. The issue to be resolved is whether a subclass of a classifier with «allocatedTo» and/or «allocatedFrom» properties should inherit those properties Resolution: Defer Postponed to the next RTF Revised Text: Actions taken: December 22, 2009: received issue January 3, 2017: Deferred April 6, 2017: closed issue Discussion: This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred End of Annotations:===== te: Tue, 02 Mar 2010 15:22:25 -0500 From: "Friedenthal, Sanford" Subject: Issue: inheriting allocations To: Juergen Boldt Cc: "sysml-rtf@omg.org" , "BERNARD, Yves" , Burkhart Roger M , "Chonoles, Michael J" , Nerijus Jankevicius , Alan Moore , "Rouquette, Nicolas F (316A)" , Bran Selic , Fredrick A Steiner , Tim Weilkiens Thread-Topic: Issue: inheriting allocations Thread-Index: Acp8Wb+BOSY4IL4BTaOA96PjnnE2KA95keFw Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Juergen Thanks for the follow-up. Please file the refined the issue below for Inheriting Allocations. I have also attached the follow-up dialogue that resulted from circulating this issue among the SysML RTF. Some of the contributors to this are included in the distribution above. Sandy From: Juergen Boldt [mailto:juergen@omg.org] Sent: Tuesday, March 02, 2010 2:20 PM To: Friedenthal, Sanford Subject: Re: inheriting allocations issue? -Juergen _____________________________________________ Title: Inheriting Allocations Source: Lockheed Martin (Mr. Sanford A. Friedenthal, sanford.friedenthal@lmco.com) Summary: There are times when it is desired that a model element that is allocated to a block or other classifier can be inherited by its subclass. In the Figure below, this would result in A0 being allocated to B1 in addition to B0. The allocated stereotype includes properties «allocatedTo» and «allocatedFrom». Since these properties are stereotype properties, they are not inherited by the classifiers that they are applied to. A constraint could be applied to either the allocate or allocated stereotype which would impose that it is automatically applied to all subclasses of the classifier. The issue to be resolved is whether a subclass of a classifier with «allocatedTo» and/or «allocatedFrom» properties should inherit those properties. RESPONSES TO THIS ISSUE INCLUDED BELOW From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, December 22, 2009 9:38 AM To: Chonoles, Michael J; Nerijus Jankevicius; Korff, Andreas Cc: sysml-rtf@omg.org Subject: RE: inheriting allocations I'm not sure. I've lost the overview about the stereotype issues. In a nutshell I think we need some kind of inheritance of stereotypes and stereotype attributes (tagged values) for user models. I have no concrete idea how to do that. But I'm sure that there is no easy solution. From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, December 22, 2009 8:48 AM To: Nerijus Jankevicius; Korff, Andreas Cc: sysml-rtf@omg.org Subject: RE: inheriting allocations Nerijus, yes, tags are not inherited. In SysML we have many constraints that force that subclassifiers have the same stereotype applied. In this case we need a similar constraint. However I'm not satisfied with such a solution. It's a workaround for a more fundamental issue. Tim From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Tuesday, December 22, 2009 8:13 AM To: Korff, Andreas; Tim Weilkiens Cc: sysml-rtf@omg.org Subject: Re: inheriting allocations Andreas, You are not right. Tags are not inherited, as they are in different metalevel, they are "metaproperties" not user defined properties. The tag "allocatedTo" is equal to any other metaproperty, let's say "name" or "isAbstract" of the Classifier. Names are not inherited, isn't it? Also, Element knows nothing about applied stereotype and tagged values in UML. Model of applied stereotypes and tagged values is independent, UML model has no references to this data. It is even serialized separately, in different format than regular UML model. The only solution with Allocations could be, if NamedElement's "clientDependency" and "supplierDependency" subsets "members" of the Namespace, so owned Dependencies will be inherited. But this is UML change. In SysML we may say that allocations on super type means allocations of subtypes also. Maybe it is enough? Nerijus From: Korff, Andreas [mailto:andreas.korff@artisansoftwaretools.com] Sent: Tuesday, December 22, 2009 5:37 AM To: Tim Weilkiens Cc: sysml-rtf@omg.org Subject: AW: inheriting allocations Hi Tim, The derived tag definitions allocatedFrom and allocatedTo in <> are NamedElements, thus they can be inherited. If we define the mechanism in the way that elements connected using an <> dependency get the <> stereotype and therefore the tag definitions allocatedTo and allocatedFrom, these tags can be inherited. From a tool point of view, the shown tag values need to refer not only to the elements connected using the <> dependency, but also all superclass connectivity using the <> dependency. Does this make sense? Kind regards, Andreas From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, December 16, 2009 5:21 PM To: Nerijus Jankevicius; Tim Weilkiens; Chonoles, Michael J; BERNARD, Yves; Friedenthal, Sanford; sysml-rtf@omg.org; Fredrick A Steiner; Alan Moore Cc: Burkhart Roger M; Bran Selic Subject: Re: inheriting allocations Note that we have to thread carefully with this. There are two orthogonal concerns: inheriting dependency client/suppliers via proper subsetting of Namespace::member as Nerijus is suggesting refactoring dependency such that the clientDependency end is owned by the association (A_clientDependency_client in the metamodel) instead of NamedElement as Nerijus mentioned being an issue in the context of specifying dependencies to elements defined in a shared, read-only resource. Technically, I think both changes can be done as long as we carefully check that all associations involved are properly specialized (i.e., subsetting should apply to both ends and the association whose ends are subsetting the ends of another should be a specialization of the later association). However, we will have to clarify somewhere two things: dependency on OCL 2.1 We will need to align SysML 1.3 to OCL 2.1 if we want backwards compatibility with expression of the kind NamedElement.clientDependency to work after the ownership of .clientDependency. moves to A_clientDependency_client. OCL 2.1 specifically provides access to properties using the dot notation regardless of their ownership. Read only elements with mutable derived properties Independently of these changes, we may need to clarify explicitly that even if a NamedElement is defined in a read-only resource, then the results of querying this element for dependencies may vary according to dependency relationships defined outside of that read-only resource. I.e., the results of querying NamedElement.clientDependency on a read-only NamedElement will be able to vary whereas they cannot vary in the current state of affairs because NamedElement owns the .clientDependency. property. - Nicolas. From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, December 16, 2009 2:18 PM To: Chonoles, Michael J; Tim Weilkiens; BERNARD, Yves; Friedenthal, Sanford; sysml-rtf@omg.org; Fredrick A Steiner; Alan Moore Cc: Burkhart Roger M Subject: Re: inheriting allocations I like Tim.s suggestion. If <> is applied to a kind of classifier (e.g., Block), then we could add constraints to effectively inherit the values of the derived /allocatedFrom & /allocatedTo tag values from the <> stereotype of its generalization parents. It is really unfortunate that there isn.t a normative syntax for accessing the stereotypes applied on an element or for accessing the specializations of a classifier. - Nicolas. From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Wednesday, December 16, 2009 12:36 PM To: Nerijus Jankevicius Cc: Tim Weilkiens; Chonoles, Michael J; BERNARD, Yves; Friedenthal, Sanford; sysml-rtf@omg.org; Fredrick A Steiner; Alan Moore; Burkhart Roger M Subject: Re: inheriting allocations On Wed, Dec 16, 2009 at 11:24 AM, Nerijus Jankevicius wrote: It seems Bran Celic is not right, InterfaceRealizations are not inherited also, as interfaceRealization: InterfaceRealization [*] subsets Element::ownedElement only, but not members. I stand corrected. Good spot, Nerijus. A related problem spotted by Michael is the misleading text in section 7.3.20, which specifically says that what is inherited are "features" rather than members. It is done for some reasons in UseCase: include : Include[*] References the Include relationships owned by this use case. (Subsets Namespace.ownedMember) extend : Extend[*] References the Extend relationships owned by this use case. (Subsets and Namespace.ownedMember) So, include and extend are by some unclear reasons different than other relations. I take credit for this since I did that bit in the metamodel, but, to be honest, I cannot recall why I did it differently. Parameters of the Behavior subsets ownedMember, so are inherited, but it is not clear how it works, how inherited parameters are merged , as both are ordered. Nor is it clear for qualifiers, since they are properties of properties, so they are not directly members of a classifier. This whole thing needs to be cleaned up. Cheers...Bran From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Wednesday, December 16, 2009 11:24 AM To: Tim Weilkiens; Chonoles, Michael J; BERNARD, Yves; Friedenthal, Sanford; sysml-rtf@omg.org; Fredrick A Steiner; Alan Moore Cc: Burkhart Roger M; Bran Selic Subject: Re: inheriting allocations Tim and others, Below is precise explanation how it works in UML metamodel: UML says that only "members" of the namespace which are not private are inherited. The query inheritableMembers() gives all of the members of a classifier that may be inherited in one of its descendants, subject to whatever visibility restrictions apply. Classifier::inheritableMembers(c: Classifier): Set(NamedElement); pre: c.allParents()->includes(self) inheritableMembers = member->select(m | c.hasVisibilityOf(m)) So, attributes and operations (features) are members as they subset "ownedMembers" or "members". Constraints are inherited also, because Namespace::ownedRule: Constraint[*] subsets Namespace::ownedMember. It seems Bran Celic is not right, InterfaceRealizations are not inherited also, as interfaceRealization: InterfaceRealization [*] subsets Element::ownedElement only, but not members. Classifier:generalization: Generalization[*] Subsets Element::ownedElement, so is not inherited. Also, Generalization is not NamedElement, so it can't subset members even if we would like to do that. The clientDependency or supplierDepency of the NamedElement does not subset members, so Dependencies are not inherited. It could be easily fixed, as Dependency is NamedElement and "supplierDependency" and "clientDependency" could subset Namespace::members. It is done for some reasons in UseCase: include : Include[*] References the Include relationships owned by this use case. (Subsets Namespace.ownedMember) extend : Extend[*] References the Extend relationships owned by this use case. (Subsets and Namespace.ownedMember) So, include and extend are by some unclear reasons different than other relations. Parameters of the Behavior subsets ownedMember, so are inherited, but it is not clear how it works, how inherited parameters are merged , as both are ordered. Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: Tim Weilkiens To: Chonoles, Michael J ; BERNARD, Yves ; Friedenthal, Sanford ; sysml-rtf@omg.org ; Fredrick A Steiner ; Alan Moore Cc: Burkhart Roger M Sent: Wednesday, December 16, 2009 5:28 PM Subject: RE: inheriting allocations I think we still have the same problem. An allocation is not inherited. It is not in the namespace of the classifier. Or do I miss something? From: Chonoles, Michael J Sent: Monday, December 14, 2009 2:24 PM To: Chonoles, Michael J; Tim Weilkiens; BERNARD, Yves; Friedenthal, Sanford; sysml-rtf@omg.org; Fredrick A Steiner; Alan Moore Cc: Burkhart Roger M Subject: RE: inheriting allocations I was wrong, while general dependencies cannot be inherited, NamedElements can. So that part is good. From: Chonoles, Michael J Sent: Monday, December 14, 2009 1:04 PM To: Tim Weilkiens; BERNARD, Yves; Friedenthal, Sanford; sysml-rtf@omg.org; Fredrick A Steiner; Alan Moore Cc: Burkhart Roger M Subject: RE: inheriting allocations Even if you can make the stereotype be inherited, I.m not sure you can inherit dependencies; they are neither features nor constraints. Now, if we implement them as associations it will be physically possible to inherit them, but I don.t believe the UML metamodel supports this. I actually asked the UML 2.4 RTF to confirm that this is true. I.ll pass along the results, when I get them Michael From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, December 14, 2009 6:17 AM To: Tim Weilkiens; Friedenthal, Sanford; sysml-rtf@omg.org; Fredrick A Steiner; Alan Moore Cc: Burkhart Roger M Subject: RE: inheriting allocations Tim, Of course you can write it, but how to to have it actually formalized? If this constriant is added to the Allocated stereotype, it can anly be checked for the class it is applied to and that class has no visibility on its subclasses, except if I'm wrong. Yves From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Monday, December 14, 2009 5:59 AM To: BERNARD, Yves; Friedenthal, Sanford; sysml-rtf@omg.org; Fredrick A Steiner; Alan Moore Cc: Burkhart Roger M Subject: RE: inheriting allocations Sandy, we've defined the constraint that subclasses must apply same stereotypes as the superclass. I think we need something like this: Any classifier which specializes a classifier with stereotype Allocated must also have the stereotype Allocated applied. The values of the derived stereotype attributes could be derived from the superclass. Tim From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, December 14, 2009 4:56 AM To: Friedenthal, Sanford; sysml-rtf@omg.org; Fredrick A Steiner; Alan Moore Cc: Burkhart Roger M Subject: RE: inheriting allocations Sandy, Some comments: First about the usage of an allocation relationship between a behavior and a block: I wonder what is the exact semantic of such an allocation compared to ownedBehavior and classifierBehavior properties of a Block and how to ensure the constitency? Note that ownedBehaviors are inherited by subclasses. I do not believe that it's possible to constrain a stereotype to be applied on subclasses of a class where this stereotype is applied. More, I understand that it is not the <> stereotype that you would like to enforce but the <> relationship. Yves _____________________________________________ From: Friedenthal, Sanford Sent: Sunday, December 13, 2009 8:07 PM To: sysml-rtf@omg.org; 'Fredrick A Steiner'; 'Alan Moore' Cc: 'Burkhart Roger M' Subject: inheriting allocations SysML RTF, Rick, Alan We had a brief discussion at the SysML v1.3 RTF last Monday in Long Beach regarding the ability to inherit allocations. I said I would write up an issue on this. Any comments. Is this worth filing? Sandy Sanford Friedenthal Lockheed Martin Title: Inheriting Allocations Source: Lockheed Martin (Mr. Sanford A. Friedenthal, sanford.friedenthal@lmco.com) Summary: There are times when it is desired that a model element that is allocated to a block or other classifier can be inherited by its subclass. In the Figure below, this would result in A0 being allocated to B1 in addition to B0. The allocated stereotype includes properties «allocatedTo» and «allocatedFrom». Since these properties are stereotype properties, they are not inherited by the classifiers that they are applied to. (As a note, a constraint could be applied to the allocated stereotype which would impose that it is automatically applied to all subclasses of the classifier that it is applied to Microsoft Visio Drawing 1.jpg Microsoft Visio Drawing 2.jpg