Issues for UML Profile for Scheduling 1.1 Revision Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 5987: PAstep should apply to more model elements
Issue 5988: PAoccurrence has wrong type
Issue 5989: Performance Profile Loads need tags for throughput
Issue 5990: PAstep needs tags for message size
Issue 5998: defining different UML extenssions
Issue 5999: Extensions should be minimized in order to clarify resulting model
Issue 6000: concepts that are redundant in schedulability and performance sub-profiles
Issue 6271: : error in the table describing the stereotype «GRMrelease»
Issue 6272: section 8.2.2.3
Issue 8701: Page: 3-38

Issue 5987: PAstep should apply to more model elements (uml-scheduling-rtf)

The PAstep stereotype should apply also to Action and ActionExecution
(similar to 
SAaction). This is needed for modeling.


        - In fact the software sense of PAstep and SAaction are identical
for steps 
which are primitive (not decomposed into a sub-scenario). Thus the
stereotype should 
perhaps apply to Transition as well.

Agreed. Easy fix with no backward compatibility issues

In the PAopenLoad stereotype, the tag PAoccurrence attribute name should not
be 
population, but a name standing for arrival pattern. 
OpenWorkload::arrivalPattern would do.  

The PAclosedLoad and PAopenLoad stereotypes should both have tags for
throughput 
in [responses/unit_time]. The PAresource stereotype has already a
PAthroughput tag 
of type Real, so this would be suitable. 


A more appropriate type for Throughput would be desirable.


        - PAperfValue is suitable for describing delay, and time between
events, but 
not a rate.
        
        - RTarrivalPattern type is good for describing event sequences, but
it 
assumes that the event pattern is imposed on the system. Throughput is
usually a 
result, and often we don't know its pattern but only the mean rate.
        
        - A full treatment of throughput might have to treat traffic
variability and 
self-similarity!!

This seems to require a new feature, hence a new RFP

There are no tags for message size, which is really important when the
messages are 
transmitted over a communication network. For a synchronous message, there
are in 
fact two message sizes: one for the request and the other for the reply. 


       - As the UML messages are stereotyped as PAStep, an easy fix would be
to add 
two tags to a step, PAinSize and PAoutSize of type Integer, to describe the
size of 
the data needed as input for the step, and the size of the results produced
by the 
step. Most steps would not need these tags. 

This seems to require a new feature, hence a new RFP

1 - when defining the different UML extenssions (stereotypes/tagged
> values) proposed ;in the context of the SPT profile, some of the
> extenssions may be applied on different UML base class, but without having
> everttime the same semantics. So the clear semantics of every extenssion
> attached a given UML base class should be clarified every time it is
> reuqired, that is to say every time there atre possible ambiguities

This requires significant rework much of which will have to be redone for the 2.0 version of the profile. Hence, it is better to resolve the issue in 2.0.

2 - the name of extessions should be minimized in order to clarify
> resulting model. I propose to omit the prefix of every extenssion and to
> use the oncept of namespace in case of possible naming conflict. Moreover
> Package name describing the various sub-profile should be also reduced

This is a major change in terms of backward compatibility issues and beyond the scope of an RTF.

3 - There are concepts that are redundant in both schedulability and
> performance sub-profiles. The spt profile should have an additionnal
> package factorizing these concepts. Moreover as one of the SPT use cases
> ensures also modelling of real-time systems, this new package should be
> dedicated to offer the users UML extenssions required to model real-time
> aspects of application without any purpouse of validation, performance,
> schedulability analysis ... , just modelling for example for code
> generation.

This requires significant rework much of which will have to be redone for the 2.0 version of the profile. Hence, it is better to resolve the issue in 2.0.

p4-37 : error in the table describing the stereotype «GRMrelease»
should be «GRMacquire» instead of «GRMrelease»

The stereotype given in the stereotype column for PAopenLoad is PAclosedLoad

On page 3-38, the table for stereotype <<GRMrelease>>, there are two "method" base class