Omg issue Number

Disposition: Resolved

OMG Issue No: 11891

Title: {title of the issue}

Source:

Carleton University (Dr. Dorina C. Petriu, [e-mail])

Summary:

Incorrect cross-reference to chapter number on Page 309, third paragraph:

“The performance domain employs and extends the Generic Quantitative Analysis Modeling (GQAM) domain of Chapter 17.”

GQAM is in chapter 15.

Resolution:

{Replace 17 by 15}

Revised Text:

Old text p 309 para 3:

“The performance domain employs and extends the Generic Quantitative Analysis Modeling (GQAM) domain of Chapter 17.”
New text:

“The performance domain employs and extends the Generic Quantitative Analysis Modeling (GQAM) domain of Chapter 15.”

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 11892

Title: {title of the issue}

Source:

Carleton University (Dr. Dorina C. Petriu, [e-mail])

Summary:

Incorrect cross-reference to Figure

Resolution:

{Correct}

Revised Text:

(1) Page 325: “In Figure 17.8, the blockingTime ...” - should refer to Figure 17.9.

No Change: Already corrected in issue 11649, edit item E9
(2) Page 326 the first paragraph: “In Figure 17.9 a simple sequence is annotated”- should refer to Figure 17.10

No Change: Already corrected in issue 11649, edit item E11

(3)P331 Last paragraph
Old text: Figure 17.15 and Figure 17.16 show the deployment...
New text: - Figure 17.16 and 17.17 show the deployment...

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 11707

Title: Consider providing a tabular notation for Allocation constraints

Source:

INRIA (Dr. Frederic Mallet, [e-mail])

Summary:

Consider providing a tabular notation (as in SysML) to ease the setting of allocations and their implied constraints when the source and the target are in diagrams too far apart or in allocation activity groups.

Resolution:

Add an example of a possible table that contains NFP constraints relative to an allocation activity groups.

Revised Text:

In section 12.4.3, page 148, add the following text after Figure 12.9:

The table below illustrates how to complete the allocation information of Figure 12.9 to represent the cost:

	P1	P2
inpC	4 ms	6 ms
oper1	10 ms
oper2	10 ms	8 ms
outW	4 ms
outZ		6 ms

We use the standard notation for NFP Constraints, either the simplify version or the full tuple notation. Several constraints can be put in the same cell or a different table can be done for each different constraint. Any kind of NFP contraints can be specified (time, power consumption …).

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 11770

Title: [Alloc: Profile

Source:

Commissariat a l Energie Atomique-CEA/LIST (Mr. Huascar Espinoza, [e-mail])

Summary:

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: <.

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:

Disposition: Resolved