Issue 5989: Performance Profile Loads need tags for throughput
Issue 5990: PAstep needs tags for message size
Issue 5998: defining different UML extenssions
Issue 6000: concepts that are redundant in schedulability and performance sub-profiles
Issue 8701: Page: 3-38
Issue 5989: Performance Profile Loads need tags for throughput (uml-scheduling-rtf)
Click here for this issue's archive.
Source: Carleton University (Dr. Murray Woodside, cmw(at)sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:
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.
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.
On page 3-38, the table for stereotype <<GRMrelease>>, there are two "method" base class