Need to say for each association in the domain models, how they map
to UML with the SPT profile applied.

Often in the early stages of analysis, an the active objects, rather than
their internal operations are treated as the schedulable entity. In order to
support this mode of analysis, the stereotypes associated to schedulable
entities, SAtrigger and SAresponse, must include in their base types all
relevant classifiers and Instance

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.

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!!

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

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.

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

The stereotype given in the stereotype column for PAopenLoad is PAclosedLoad

see below

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

see below

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

closed, no change

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

see below

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.

see below