Issue 11770: [Alloc: Profile (marte-ftf) Source: Fundacion Tecnalia Research and Innovation (Mr. Huascar Espinoza Ph.D., Huascar.Espinoza(at)tecnalia.com) Nature: Enhancement Severity: Critical Summary: [Alloc: Profile] The MARTE allocation concept aimed to refine the SysML allocation concept. Furthermore, it seems that the idea was to not be dependent on SysML by re-defining the same concepts in the MARTE context. For this reason, MARTE uses the same names for the generic stereotypes (<<allocated>> and <<allocate>>). However, there is a limitation in the MARTE <<allocated>> stereotype that does not allow modelers to have the same capabilities. More precisely, when using the <<allocated>> stereotype, we cannot refers to the target and source ends. We are forced to use the more specialized stereotypes: <<ApplicationAllocationEnd>> and <<ExecutionPlatformAllocationEnd>>, which is not always practical (the annotation process requires to pollute the target model) or is not always what modelers want to allocate (physical-logical allocation, or others support by SysML). So, I’d suggest to add properties: /allocatedFrom:NamedElement[*] and /allocatedTo:NamedElement[*] for the stereotype: <<Allocated>. Resolution: Add the proposed property in the stereotype Allocated to maintain compatibility with SysML. Replace Figure 12.3 and the description text accordingly. If the property allocatedTo and allocatedFrom are already defined in the stereotype Allocated, they need not be redefined in the specialized stereotypes (ApplicationAllocationEnd and ExecutionPlatformExecutionEnd). Thus, these two stereotypes can be replaced by a mere attribute of type AllocationEndKind. All figures where either the stereotype ExecutionPlatformExecutionEnd or ApplicationAllocationEnd were displayed have been replaced by a new Figure with the new notation. No concept is introduced or removed. It is just a different lighter way to implement the domain model so as to be consistently compatible with the SysML allocation. The revised text assumes that resolution 12214 will be resolved by referring to sources of an allocation as clients and to targets as suppliers. Revised Text: In section 12.3.1, page 139, replace Figure 12.3 by: Remove sections 12.3.2.6 and 12.3.2.8. Associations § None By: Associations § /allocatedTo: Allocated [*] The named elements that are suppliers of an "allocate" whose client is extended by this stereotype. This property is the union of all suppliers to which this instance is the client. This association is derived from any "allocate" dependency § /allocatedFrom: Allocated [*] The named elements that are clients of an "allocate" whose supplier is extended by this stereotype. The allocatedFrom elements are not necessarily derived from the same "allocate" dependency. A given element can be the supplier of several application model elements, each of which is allocated using a separate "allocate" dependency. The association is derived from any "allocate" dependency. In page 143, insert a new section (12.3.2.5) between the two sections "AllocationNature" (12.3.2.4) and "AllocationKind" (formerly 12.3.2.5) to describe the newly introduced enumeration AllocationEndKind: 12.3.2.5. AllocationEndKind (from Alloc) AllocationEndKind is an enumeration type that differentiates the application allocation end from the execution platform allocation end. Literals § undef should be used when no differentiation is to be made on the nature of the allocation end. It could be either an application allocation end or an execution allocation end or something else (as in SysML, where no distinction is made). § application identifies an allocation end as being on the application side of the allocation. This allocation end must be the source (the client) of an allocate dependency. § executionPlatform identifies an allocation end as being on the execution platform side of the allocation. This allocation end must be the target (the supplier) of an allocate dependency. § both identifies an allocation end as being both on the application and the execution platform side of the allocation. This allocation must be the source (the client) of an allocate dependency and the target (the supplier) of an (another) allocate dependency. In section 12.4.1, page 146, replace Figure 12.7 by: In section 12.4.2, page 147, replace Figure 12.8 by: Actions taken: December 7, 2007: received issue February 17, 2010: closed issue Discussion: see ptc/2008-06-05 for revised text/figures End of Annotations:===== m: webmaster@omg.org Date: 07 Dec 2007 08:24:55 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Dr. Huascar Espinoza Company: CEA LIST mailFrom: huascar.espinoza@cea.fr Notification: Yes Specification: UML Profile for MARTE Section: Allocation FormalNumber: ptc/07-08-04 Version: Beta 1 RevisionDate: 08/04/07 Page: 84 Nature: Enhancement Severity: Critical HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; InfoPath.1) Description [Alloc: Profile] The MARTE allocation concept aimed to refine the SysML allocation concept. Furthermore, it seems that the idea was to not be dependent on SysML by re-defining the same concepts in the MARTE context. For this reason, MARTE uses the same names for the generic stereotypes (<> and <>). However, there is a limitation in the MARTE <> stereotype that does not allow modelers to have the same capabilities. More precisely, when using the <> stereotype, we cannot refers to the target and source ends. We are forced to use the more specialized stereotypes: <> and <>, which is not always practical (the annotation process requires to pollute the target model) or is not always what modelers want to allocate (physical-logical allocation, or others support by SysML). So, I.d suggest to add properties: /allocatedFrom:NamedElement[*] and /allocatedTo:NamedElement[*] for the stereotype: <.