UML Profile for Schedulability, Performance, & Time Avatar
  1. OMG Specification

UML Profile for Schedulability, Performance, & Time — Open Issues

  • Acronym: SPTP
  • Issues Count: 39
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
SPTP11-1 General issue SPTP 1.0b1 open
SPTP11-2 Support high-level schedulability analysis SPTP 1.0 open
SPTP-187 RTCurrent SPTP 1.0b1 open
SPTP-188 The distributed thread id must be available in all interception points SPTP 1.0b1 open
SPTP-186 The RTC1 document needs to be integrated with the RTC2 document SPTP 1.0b1 open
SPTP-185 problem for some schedulers using Portable Interceptors for scheduling pts. SPTP 1.0b1 open
SPTP-184 VoidData should be documented SPTP 1.0b1 open
SPTP-181 get the thread id from a distributable thread instance SPTP 1.0b1 open
SPTP-182 In section 5.5.2, the semantics for scheduling_policies should be discussed SPTP 1.0b1 open
SPTP-183 In section 5.2.7.2, "scheduling policy" should be "scheduling parameter SPTP 1.0b1 open
SPTP-180 Spawn SPTP 1.0b1 open
SPTP-179 Rename stereotype from <> to <> SPTP 1.0b1 open
SPTP11-5 defining different UML extenssions SPTP 1.0 open
SPTP11-3 Performance Profile Loads need tags for throughput SPTP 1.0 open
SPTP11-4 PAstep needs tags for message size SPTP 1.0 open
SPTP11-6 concepts that are redundant in schedulability and performance sub-profiles SPTP 1.0 open
SPTP-26 Fig 5-5 Timed Action should inherit from Action Execution SPTP 1.0b1 open
SPTP-24 Section 5, figure 5-5. SPTP 1.0b1 open
SPTP-25 Section 5, Page 5-13 first lines. SPTP 1.0b1 open
SPTP-23 <> SPTP 1.0b1 open
SPTP-22 <> SPTP 1.0b1 open
SPTP-19 time/frequency definitions SPTP 1.0b1 open
SPTP-18 OrderedTimeSets SPTP 1.0b1 open
SPTP-20 suggest inclusion of <> stereotype (inherited from < SPTP 1.0b1 open
SPTP-21 TVL notation SPTP 1.0b1 open
SPTP-17 Frequency SPTP 1.0b1 open
SPTP-15 The concept of scenario SPTP 1.0b1 open
SPTP-16 there could be a better, more complete RTtimeValue (p90+) SPTP 1.0b1 open
SPTP-14 Repetition counts SPTP 1.0b1 open
SPTP-13 more abstract demand unit needed SPTP 1.0b1 open
SPTP-12 Page 8-20, PaextOpValue SPTP 1.0b1 open
SPTP-9 concepts that already exists in UML SPTP 1.0b1 open
SPTP-8 SA Profile issue SPTP 1.0b1 open
SPTP-11 Page 4-36, "GRMAcquire" (issue 2) SPTP 1.0b1 open
SPTP-10 The different profiles do not pay special attention to identify well-formed SPTP 1.0b1 open
SPTP-7 p. 99: SPTP 1.0b1 open
SPTP-6 Section 6.2.2 UML Extensions, page 103 SPTP 1.0b1 open
SPTP-4 Chap. 5, p. 47 and following (4.2.1 Modeling Realization Relationships) SPTP 1.0b1 open
SPTP-5 concepts introduced can be redundant with UML SPTP 1.0b1 open

Issues Descriptions

General issue

  • Key: SPTP11-1
  • Legacy Issue Number: 5875
  • Status: open  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

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

  • Reported: SPTP 1.0b1 — Fri, 28 Feb 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Support high-level schedulability analysis

  • Key: SPTP11-2
  • Legacy Issue Number: 5919
  • Status: open  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    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

  • Reported: SPTP 1.0 — Tue, 29 Apr 2003 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

RTCurrent

  • Key: SPTP-187
  • Legacy Issue Number: 5761
  • Status: open  
  • Source: Objective Interface Systems ( Bill Beckwith)
  • Summary:

    The RTC1 document needs to assert that RTCurrent must be correct
    in various interception points (in order for Dynamic Scheduling
    to work).

  • Reported: SPTP 1.0b1 — Tue, 12 Nov 2002 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:25 GMT

The distributed thread id must be available in all interception points

  • Key: SPTP-188
  • Legacy Issue Number: 5762
  • Status: open  
  • Source: Objective Interface Systems ( Bill Beckwith)
  • Summary:

    The distributed thread id must be available in all interception points.

  • Reported: SPTP 1.0b1 — Tue, 12 Nov 2002 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:25 GMT

The RTC1 document needs to be integrated with the RTC2 document

  • Key: SPTP-186
  • Legacy Issue Number: 5760
  • Status: open  
  • Source: Objective Interface Systems ( Bill Beckwith)
  • Summary:

    The RTC1 document needs to be integrated with the RTC2 document

  • Reported: SPTP 1.0b1 — Tue, 12 Nov 2002 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:25 GMT

problem for some schedulers using Portable Interceptors for scheduling pts.

  • Key: SPTP-185
  • Legacy Issue Number: 5759
  • Status: open  
  • Source: Objective Interface Systems ( Bill Beckwith)
  • Summary:

    There is a potential problem for some schedulers in using
    Portable Interceptors for scheduling points. PICurrent can't
    be updated in receive_reply.

  • Reported: SPTP 1.0b1 — Tue, 12 Nov 2002 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:25 GMT

VoidData should be documented

  • Key: SPTP-184
  • Legacy Issue Number: 5758
  • Status: open  
  • Source: Objective Interface Systems ( Bill Beckwith)
  • Summary:

    VoidData should be documented

  • Reported: SPTP 1.0b1 — Tue, 12 Nov 2002 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:25 GMT

get the thread id from a distributable thread instance

  • Key: SPTP-181
  • Legacy Issue Number: 5755
  • Status: open  
  • Source: Objective Interface Systems ( Bill Beckwith)
  • Summary:

    It should be possible to get the thread id from a
    distributable thread instance

  • Reported: SPTP 1.0b1 — Tue, 12 Nov 2002 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:25 GMT

In section 5.5.2, the semantics for scheduling_policies should be discussed

  • Key: SPTP-182
  • Legacy Issue Number: 5756
  • Status: open  
  • Source: Objective Interface Systems ( Bill Beckwith)
  • Summary:

    In section 5.5.2, the semantics for scheduling_policies should be discussed

  • Reported: SPTP 1.0b1 — Tue, 12 Nov 2002 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:25 GMT

In section 5.2.7.2, "scheduling policy" should be "scheduling parameter

  • Key: SPTP-183
  • Legacy Issue Number: 5757
  • Status: open  
  • Source: Objective Interface Systems ( Bill Beckwith)
  • Summary:

    In section 5.2.7.2, "scheduling policy" should be "scheduling parameter

  • Reported: SPTP 1.0b1 — Tue, 12 Nov 2002 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:25 GMT

Spawn

  • Key: SPTP-180
  • Legacy Issue Number: 5754
  • Status: open  
  • Source: Objective Interface Systems ( Bill Beckwith)
  • Summary:

    Spawn should discuss the initial execution state of the
    newly created distributable thread

  • Reported: SPTP 1.0b1 — Tue, 12 Nov 2002 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:25 GMT

Rename stereotype from <> to <>

  • Key: SPTP-179
  • Legacy Issue Number: 5645
  • Status: open  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    There is a stereotype called<<SAschedulable>> and a tag
    definition called SAschedulable in the SAprofile package - to avoid
    potential problems with name clashes (UML is unclear whether this is
    allowed) the stereotype should be renamed <<SAschedRes>>.

  • Reported: SPTP 1.0b1 — Thu, 19 Sep 2002 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:25 GMT

defining different UML extenssions

  • Key: SPTP11-5
  • Legacy Issue Number: 5998
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    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

  • Reported: SPTP 1.0 — Fri, 18 Jul 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Performance Profile Loads need tags for throughput

  • Key: SPTP11-3
  • Legacy Issue Number: 5989
  • Status: open  
  • Source: Carleton University ( Murray Woodside)
  • 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!!
  • Reported: SPTP 1.0 — Thu, 3 Jul 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

PAstep needs tags for message size

  • Key: SPTP11-4
  • Legacy Issue Number: 5990
  • Status: open  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    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.
  • Reported: SPTP 1.0 — Thu, 3 Jul 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

concepts that are redundant in schedulability and performance sub-profiles

  • Key: SPTP11-6
  • Legacy Issue Number: 6000
  • Status: open  
  • Source: CEA ( Gerard Sebastien)
  • Summary:

    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.

  • Reported: SPTP 1.0 — Fri, 18 Jul 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fig 5-5 Timed Action should inherit from Action Execution

  • Key: SPTP-26
  • Legacy Issue Number: 5720
  • Status: open  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    Fig 5-5 Timed Action should inherit from Action Execution - this would allow
    it to have predecessors and successors and requiredQoS as well as Scenario
    properties (because Action Execution inherits from Scenario)
    Julio Medina [medinajl@unican.es]

  • Reported: SPTP 1.0b1 — Thu, 24 Oct 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 5, figure 5-5.

  • Key: SPTP-24
  • Legacy Issue Number: 5711
  • Status: open  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    Some scheduling analysis techniques use more than one duration time in the description of actions (one action, specially SAction that inherits TimedAction, can have associated more than one duration and this can provide different scheduling analysis results).

  • Reported: SPTP 1.0b1 — Thu, 24 Oct 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 5, Page 5-13 first lines.

  • Key: SPTP-25
  • Legacy Issue Number: 5712
  • Status: open  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    The definition of duration looks like an “execution time” definition, not like a “computation time” definition, that is the role of this attribute in analysis metamodels. Suggest the following definition: "the time interval of execution capacity used by the action"

  • Reported: SPTP 1.0b1 — Thu, 24 Oct 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

<>

  • Key: SPTP-23
  • Legacy Issue Number: 5704
  • Status: open  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    <<SAschedRes>>: why this stereotype isn't inherited from
    <<CRconcurrent>>? As I could understand from the documentation, they
    represent the same thing: "a unit of concurrent execution, such as a
    task, a process, or a thread". Therefore, I believe it should also
    include the tag CRmain.

  • Reported: SPTP 1.0b1 — Thu, 24 Oct 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

<>

  • Key: SPTP-22
  • Legacy Issue Number: 5703
  • Status: open  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    <<CRsync>>: we suggest the inclusion of a new tagged valued called
    CRcallTimeout. It would represent the maximum waiting time from the
    calling object. For example, this would be useful to model the RT-CORBA
    Messaging:: RELATIVE_RT_TIMEOUT_POLICY_TYPE attribute. Like in 1.2, the
    could be a timeout handler associated with, for example, a stereotype
    named RTcallTimeoutHandler (see attached item 3 in (Leandro Diagrams.doc)).

  • Reported: SPTP 1.0b1 — Thu, 24 Oct 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

time/frequency definitions

  • Key: SPTP-19
  • Legacy Issue Number: 5319
  • Status: open  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    "The general timing specification (GTS) semantically is a general set of
    points in time. The purpose of the GTS is to specify the complex timing of
    events and actions (mainly in orders and scheduling systems.) The GTS also
    supports the cyclical validity patterns that may exist for certain kinds of
    information, such as phone numbers (evening, daytime)...
    The GTS data type has the following aspects:
    · GTS as a general set of points in time (SET<TS>). From this aspect GTS
    answers whether any given point in time falls in the schedule described by
    the GTS value.
    · GTS as the combination of multiple periodic intervals of time. This aspect
    describes how both simple and complex repeat-patterns are specified with the
    GTS.
    · GTS as a generator of a sequence of intervals of point in time
    (LIST<IVL<TS>>). From this aspect, GTS can generate all occurrence intervals
    of an event or action, or all validity periods for a fact.
    · GTS as an expression-syntax defined for a calendar. This aspect is the GTS
    literal form.

    In all cases the GTS is defined as a set of point in time (SET<TS>). Using
    the set operations, union,
    intersection and difference, more complex sets of time can be constructed
    from simpler ones. Ultimately the building blocks from which all GTS values
    are constructed are interval, periodic interval, and event-related periodic
    interval. The construction of the GTS can be specified in the literal
    form...

    I've recently passed part of the HL7 data type spec to Bran Selic,

    I arguing for using this opportunity to develop a more broadly useful and
    powerful time

    [BTW, I'd personally enumerate the days of the week with Sunday first, not
    last]

  • Reported: SPTP 1.0b1 — Wed, 22 May 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

OrderedTimeSets

  • Key: SPTP-18
  • Legacy Issue Number: 5318
  • Status: open  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    "3) OrderedTimeSets: While I did some ordered time for the purpose of
    schedule. I believe that a more robust OrderedTimeSet may be needed for the
    concepts of observations. The special case of a OrderedTimeSet with 2
    elements becomes the basis for Duration."

  • Reported: SPTP 1.0b1 — Wed, 22 May 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

suggest inclusion of <> stereotype (inherited from <
  • Key: SPTP-20
  • Legacy Issue Number: 5699
  • Status: open  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    "As actions can have a limited time budget, they should include a
    deadline. Therefore, I suggest the inclusion of the <<RTtimedAction>>
    stereotype (inherited from <<RTaction>>), which would represent an
    action with a deadline (tag RTdeadline - also new) and a timeout
    exception handler (tag RTtimeoutException). A motivation for adding this
    new element is that, in general, modeling such restrictions is more
    complex than programming it using ORC APIs! Another benefit is that the
    exception caused by the deadline violation would be explicitly
    associated with the stereotype. Please take a look at item 1 in the
    attached file (Leandro Diagrams.doc)."

  • Reported: SPTP 1.0b1 — Thu, 24 Oct 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT


TVL notation

  • Key: SPTP-21
  • Legacy Issue Number: 5700
  • Status: open  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    "TVL notation: I could observe the absence of expressiveness to
    indicate a condition to finish the event generation (e.g. in the TMO one
    can say ""generate events from 10am to 10:50am""):
    ""for t = from 10am to 10:50am
    every 30min
    start-during (t, t+5min) finish-by t+10min"", i.e.:

    {""start-during (10am, 10:05am) finish-by 10:10am"", ""start-during (10:30am, 10:35am) finish-by 10:40am""}

    ."

  • Reported: SPTP 1.0b1 — Thu, 24 Oct 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Frequency

  • Key: SPTP-17
  • Legacy Issue Number: 5317
  • Status: open  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    "2) Frequency. While the probabilistic definitions are included (and
    necessary), there are many other instances of repeatable events that need to
    be described e.g., Every Third Monday, the 15th of the month, twice a day.
    (or a really hard one, every Easter). Though you may feel that these events
    are out of scope, they are important in any sort of scheduler, and are
    necessary to ensure that the low-level time definitions scale up. It would
    not be good to use incompatible time/frequency expressions at different
    scale."

  • Reported: SPTP 1.0b1 — Wed, 22 May 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The concept of scenario

  • Key: SPTP-15
  • Legacy Issue Number: 5315
  • Status: open  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    The concept of scenario is limited to an ordered set of steps. It needs to accomodate scenario structure, such as a graph with connectors such as OR-form/join, and probabilities of forks. This kind of structure is also needed in the sequence diagram, so maybe the same solution can be used for both.

  • Reported: SPTP 1.0b1 — Wed, 22 May 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

there could be a better, more complete RTtimeValue (p90+)

  • Key: SPTP-16
  • Legacy Issue Number: 5316
  • Status: open  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    "1) I believe that there could be a better, more complete RTtimeValue (p90+).
    While the included format does handle many situations it is not sufficiently
    general. For example, it could handle several other common time designators,
    e.g., time zones (EST, GMT, PDT,...), Julian Date, and (the un-related)
    Julian Calendar, approximates times, and to support diversity, non Gregorian
    calendars."

  • Reported: SPTP 1.0b1 — Wed, 22 May 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Repetition counts

  • Key: SPTP-14
  • Legacy Issue Number: 5314
  • Status: open  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    Repetition counts on messages need to be RTtimeString rather than integers, to allow for more general behaviour. For instance in sending an image frame, the number of packets sent is not a fixed number, but depends on compression... so an RTtimeString could give the distribution or average number.

  • Reported: SPTP 1.0b1 — Wed, 22 May 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

more abstract demand unit needed

  • Key: SPTP-13
  • Legacy Issue Number: 5313
  • Status: open  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    CPU demands are represented as time values... this is useful for limited studies, but a more abstract demand unit, that can be scaled to different platforms, which give greater modeling power. There is no obvious unit for this... the definition of execution demands could be relaxed so it can be any units. Call it demand instead of execution time.

  • Reported: SPTP 1.0b1 — Wed, 22 May 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 8-20, PaextOpValue

  • Key: SPTP-12
  • Legacy Issue Number: 5290
  • Status: open  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    PaextOpValue is a complex tagged value that seems to iterate over a set of operation and provide information about those operations. Wouldn't it be better to introduce a stereotype of operation and add <integer> and <time-value> to that? We would then either add a tag from "Pastep" to this new stereotype or use an existing UML relationship.

  • Reported: SPTP 1.0b1 — Mon, 13 May 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

concepts that already exists in UML

  • Key: SPTP-9
  • Legacy Issue Number: 5078
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    We think it is not possible to forget some concepts that already exists in UML and that are very closed to some of the previous one. More precisely I think about three following issues:
    1.       The isActive meta-attribute of the Class meta-class è Active/passive object which are particular case of active/passive resource; So, according to me they are specialization of the stereotype <<GRMactiveRessource>>.
    2.       The concurrency meta-attribute of the Operation meta-class which is a kind of concurrency policy on operations;
    3.       The isQuery meta-Attribute of BehavioralFeature may be connected to the Service concept.
    4.       Both stereotypes <<Thread>> and <<Process>> of the Classifier meta-class I deem that they are outside the scope of UML core and could be placed in the RT profile. There are indeed specialization of the stereotype <<GRMactiveResource>>.
    To conclude, we think that the links between this profile and UML meta-model is not so simple. Today we have no precise solution. One way to proceed could be to remove from UML all concepts pertaining to concurrency and put them in the concurrency profile for UML è to remove isActive, concurrency and isQuery meta-attributes and <<Thread>> , <<Process>> stereotypes;

  • Reported: SPTP 1.0b1 — Wed, 20 Mar 2002 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

SA Profile issue

  • Key: SPTP-8
  • Legacy Issue Number: 5050
  • Status: open  
  • Source: Anonymous
  • Summary:

    Activity diagrams are an interesting solution for the description of behaviors. This notation restricted (we cannot include loops and the fork join pseudo states must be used in cobegin-coend sequences) can represent the same types of responses used in some scheduling analysis methods [6,5,7,3]. They can be used to describe the behavior of Operations and this will describe the response associated to messages and stimulus. This is useful to describe sequences of actions that use different types of resources, and these actions could be executed in sequence, parallel or selection. If we have the sequence of a collaboration diagram DD1 ope1 -> DD1.1 ope2 -> DD1.2 ope3, and the operations are described with the activity diagrams like ((action1 || action2) | action3) -> action4 (|| represents the parallel execution, | the selection, and actioni are action states that can be stereotyped as SAStep), we can substitute the operation message or stimuli by their activity diagram, and create an event response based on the combination of both types of behavior description. These notations are useful to represent complex behaviors of operations and messages and to optimize the evaluation of jitters

  • Reported: SPTP 1.0b1 — Wed, 20 Mar 2002 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 4-36, "GRMAcquire" (issue 2)

  • Key: SPTP-11
  • Legacy Issue Number: 5275
  • Status: open  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    Shouldn't the services referenced by GRMexclServ have a stereotype to say that they're exclusive - we used to have one GRMExclusive but this appears to have been removed.

  • Reported: SPTP 1.0b1 — Mon, 13 May 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The different profiles do not pay special attention to identify well-formed

  • Key: SPTP-10
  • Legacy Issue Number: 5085
  • Status: open  
  • Source: Universidad Politecnica de Madrid ( Miguel de Miguel)
  • Summary:

    The different profiles do not pay special attention to identify well-formed rules. Each stereotype has a set of rules, but they are not OCL constraints. The rules pay attention to the consistence of the stereotypes and their tagged values, but there are not consistence rules of complete models (e.g. the workload elements in performance models must have associated some steps that must be identified in the context of the model, and this identification depends on the mapping).

  • Reported: SPTP 1.0b1 — Wed, 20 Mar 2002 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

p. 99:

  • Key: SPTP-7
  • Legacy Issue Number: 5049
  • Status: open  
  • Source: Anonymous
  • Summary:

    "In the domain view point describing the concurrency feature, two specific kinds of service are introduced: DeferredService and ImmediateService. I propose to add:
    IgnoredService
    A kind of service instance that is ignored if the receiving object is not able to handle it when it receives it.
    RejectedService
    A kind of service instance that is rejected if the receiving object is not able to handle it when it receives it. The rejection of a call will also raise an exception that can be catch either by the sender of the stimuli or by the system itself."

  • Reported: SPTP 1.0b1 — Wed, 20 Mar 2002 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 6.2.2 UML Extensions, page 103

  • Key: SPTP-6
  • Legacy Issue Number: 5048
  • Status: open  
  • Source: U.S. Army Cecom-CSE ( Tom Wheeler)
  • Summary:

    The proposed <<CRConcurrent>> stereotype appears to overlap concepts found in UML active classes and objects yet there is no discussion of their relationships. Recommend such a discussion be included.

  • Reported: SPTP 1.0b1 — Wed, 20 Mar 2002 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chap. 5, p. 47 and following (4.2.1 Modeling Realization Relationships)

  • Key: SPTP-4
  • Legacy Issue Number: 5035
  • Status: open  
  • Source: Esterel Technologies ( Jean-Paul Rigault)
  • Summary:

    The distinction between Refinement and Realization becomes less and less clear to
    me. I understand the logical difference between presenting the same model with vari-ous
    levels of details (refinement) and setting a bridge between two different models,
    one realizing/implementing/deploying the other (realization). However, as far as the
    modeling elements and their relationships are concerned, the mechanisms seem to be
    identical and the frontier often appears fuzzy.
    This trouble and confusion is apparent in the submission itself since one category of
    realization may well be considered as refinement (replacement, p. 51), as indicated by
    the authors themselves. The argument that hardware and software are still different
    entities is not completely convincing to make it a realization: indeed the hardware
    manipulates (although under different forms) the same information as the software, at
    run-time.
    Another question: why restrict replacement to the deploy mapping and to a relation-ship
    between hardware and software? Is not «code» a form of replacement?
    • I was also expecting a general notation for representing the Realization (or Realiza-tion/
    Refinement) relationship in UML. This is only sketched in the document (p. 48)
    but far from expressing the whole richness. The following characteristics seem of
    interest to me:

    • multiplicity, both on client and supplier sides
    • conjunction or disjunction
    • exclusivity or not
    • "optionality" or "mandatority"
    • static or dynamic nature of the relationship and of all the above characteristics
    • combination of functionalities (additive, replacement...)
      I am not sure that the simple distinction between require on the one hand and inclu-sive
      and exclusive (static or dynamic) on the other hand (p. 50) is sufficient to repre-sent
      all the useful and significant cases.
      However, I am already late to send this review so I have no time to elaborate more on
      this, but I would be pleased to discussed it with anybody, if this is found interesting.
      Of course, this submission might not be the place to set up a general model of Real-ization/
      Refinement.
  • Reported: SPTP 1.0b1 — Wed, 20 Mar 2002 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

concepts introduced can be redundant with UML

  • Key: SPTP-5
  • Legacy Issue Number: 5047
  • Status: open  
  • Source: Anonymous
  • Summary:

    Other concepts introduced can be redundant with UML modeling elements or attributes; for example SynchronousInvoke and AsynchronousInvoke are redundant with attributes of methods and operation attributes in UML metamodels

  • Reported: SPTP 1.0b1 — Wed, 20 Mar 2002 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT