Persistent State Service Avatar
  1. OMG Specification

Persistent State Service — Open Issues

  • Acronym: PSS
  • Issues Count: 53
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
PSSM11-26 RTC steps of Test Junction 005 PSSM 1.0 open
PSSM11-25 Graphical notation of junction and choice pseudostates PSSM 1.0 open
PSSM11-24 Incorrect RTC step in Entering 010 PSSM 1.0 open
PSSM11-23 Purpose of Test Event 001 might not be fulfilled PSSM 1.0 open
PSSM11-22 Order of transitions in RTC steps PSSM 1.0 open
PSSM11-21 Atomicity of transition, entry behavior and state completion PSSM 1.0 open
PSSM11-20 Missing alternative trace for orthogonal region in Test Transition 011-D PSSM 1.0 open
PSSM11-19 Inconsistent behavior in Test Transition 011-C PSSM 1.0 open
PSSM11-18 Partial trace in Test Transition 011-A PSSM 1.0 open
PSSM11-17 Start event is missing in Tests Transition 007 and Event 017-B PSSM 1.0 open
PSSM11-16 Checking the completion of doActivity PSSM 1.0 open
PSSM11-15 DoActivity alternative traces are missing in Test Behavior 004 PSSM 1.0 open
PSSM11-14 DoActivity can cause deadlock in Test Behavior 003-B PSSM 1.0 open
PSSM11-13 Mismatch of operation name in figure and text: register vs. registerCompletionEvent PSSM 1.0 open
PSSM11-12 Wrong multiplicity of DoActivityContextObject.doActivityEventAccepter PSSM 1.0 open
PSSM11-11 Clarification needed for abortion in Test Behavior 003-A PSSM 1.0 open
PSSM11-10 Typo in Figure 9.116 (TransitionExecutionAlgorithmTest) PSSM 1.0 open
PSSM11-9 Error in alternative traces of 9.3.3.11 Transition 017 PSSM 1.0 open
PSSM11-8 Typo in description of generated trace for 9.3.3.11 Transition 017 PSSM 1.0 open
PSSM11-7 Wrong figure references in some of the test cases PSSM 1.0 open
PSSM11-5 Notation for entry, do and exit behaviors is wrong PSSM 1.0b1 open
PSSM11-4 PSSM implementation shall conform to bUML PSSM 1.0b1 open
PSSM11-3 Tests that send multiple signals are not correct PSSM 1.0b1 open
PSSM11-2 Classifier behavior of the SemanticTest class refers to TestCase stereotype PSSM 1.0b1 open
PSSM11-1 LocalTransitionActivation exit source unclear PSSM 1.0b1 open
PSS-47 Eliminate PID_DA definition PSS 1.0b1 open
PSS-46 PDS_DA::DAObjectID PSS 1.0b1 open
PSS-45 PDS_DA DDL should exclude type Any PSS 1.0b1 open
PSS-44 SD interface PSS 1.0b1 open
PSS-48 Support for DAObject interface PSS 1.0b1 open
PSS-43 PO::delete and POM::delete PSS 1.0b1 open
PSS-42 PO::store/restore PSS 1.0b1 open
PSS-41 PO::disconnect and POM::disconnect parameters PSS 1.0b1 open
PSS-40 PO::connect and POM::connect exception needed PSS 1.0b1 open
PSS-37 PIDFactory::create_PID* definitions PSS 1.0b1 open
PSS-36 PID derivation PSS 1.0b1 open
PSS-39 PO::p attribute should be readonly PSS 1.0b1 open
PSS-38 Returning PDS from PO::connect PSS 1.0b1 open
PSS-33 PID attributes should be readonly PSS 1.0b1 open
PSS-32 PID additional attributes PSS 1.0b1 open
PSS-31 Factory interface should be specified PSS 1.0b1 open
PSS-30 Issue POS 2.0 RFP PSS 1.0b1 open
PSS-35 Typo in PID section PSS 1.0b1 open
PSS-34 PID vs. OID definition PSS 1.0b1 open
PSS2-8 PSDL Grammar problems: Page 3-33 PSS 1.0 open
PSS2-7 PSDL Grammar problems: Page 3-31 PSS 1.0 open
PSS2-9 PSDL Grammar problems: Page 3-28 PSS 1.0 open
PSS2-10 Unable to find the refrence to the ConnectorRegistry from the appendix A.1 PSS 1.0 open
PSS2-3 existence of a ConnectorRegistry in the CosPeristentState module PSS 1.0 open
PSS2-5 PSS FTF: Sequence should be added in the PSDL state types PSS 1.0 open
PSS2-2 The connectorRegistry interface is removed from spec. but still used PSS 1.0 open
PSS2-4 PSDL Grammar problems: Page 3-33 PSS 1.0 open
PSS2-6 PSDL Grammar problems: Page 3-29 PSS 1.0 open

Issues Descriptions

RTC steps of Test Junction 005

  • Key: PSSM11-26
  • Status: open  
  • Source: Budapest University of Technology and Economics ( Mr. Marton Elekes)
  • Summary:

    The RTC steps table of Test Junction 005 should contain a Continue event at the last place in steps 2-4.

    In RTC step 4 the event pool should be reversed and it should be a trivial RTC step to discard CE(S1.2) as the note suggests: "The completion event occurrence generated for S1.2 is lost, since the state has no completion transition available".

  • Reported: PSSM 1.0 — Fri, 28 Jul 2023 09:41 GMT
  • Updated: Fri, 28 Jul 2023 15:43 GMT

Graphical notation of junction and choice pseudostates

  • Key: PSSM11-25
  • Status: open  
  • Source: Budapest University of Technology and Economics ( Mr. Marton Elekes)
  • Summary:

    The graphical notation is unusual in the following cases:

    • The filled triangles in Figs. 9.65 and 9.66 (lower symbol) are supposed to be choice pseudostates.
    • The upper symbol, a circle segment in Fig. 9.66 should be a junction pseudostate.

    UML defines the graphical symbols as follows: a junction is represented by a small filled circle, a choice Pseudostate is shown as a diamond-shaped symbol.

    This problem is also present in Junction tests.

  • Reported: PSSM 1.0 — Fri, 28 Jul 2023 09:39 GMT
  • Updated: Fri, 28 Jul 2023 15:43 GMT

Incorrect RTC step in Entering 010

  • Key: PSSM11-24
  • Status: open  
  • Source: Budapest University of Technology and Economics ( Mr. Marton Elekes)
  • Summary:

    The 3rd RTC step should not contain T1.1 as fired transition since it is not present in the generated trace and the note says "the initial pseudo state and its outgoing transition are not traversed".

  • Reported: PSSM 1.0 — Thu, 27 Jul 2023 08:34 GMT
  • Updated: Fri, 28 Jul 2023 15:42 GMT

Purpose of Test Event 001 might not be fulfilled

  • Key: PSSM11-23
  • Status: open  
  • Source: Budapest University of Technology and Economics ( Mr. Marton Elekes)
  • Summary:

    The purpose of Test Event 001 is to show that, upon creation, the tested state machine immediately starts its execution.

    The expected execution trace only contains a single part, the exit behavior of the initial state wait. The outgoing transition T2 (triggered by Start event) is not included in the trace, nor is the received Start event. Therefore I am not sure that the test could actually verify that the execution was started immediately and the exit behavior was executed when the state exited, and not earlier since only the exit behavior prints to the trace.

    Another concern is that the test cannot verify that the initial compound transition is executed during initialization (requirement Event 001, p. 243), since initial transition T1 does not print to the trace.

  • Reported: PSSM 1.0 — Thu, 27 Jul 2023 08:31 GMT
  • Updated: Fri, 28 Jul 2023 15:42 GMT

Order of transitions in RTC steps

  • Key: PSSM11-22
  • Status: open  
  • Source: Budapest University of Technology and Economics ( Mr. Marton Elekes)
  • Summary:

    Is the order of transitions significant in the Fired transition(s) column of RTC steps?

    E.g., in Test Fork 001 the 3rd RTC step fires [T2(T3.1, T3, T4)]. The transitions here are not sorted alphabetically, which suggests the order matters. However, the trace shows a different execution order of transition effects: T3(effect), ..., T3.1(effect), ..., T4(effect), ...
    The orders of fired transitions and the trace also differ in Test Entering 011.

    On the contrary, in the following tests the fired transition order matters and it determines the order of:

    • transition effects in Fork 002,
    • entry behaviors in Entry 002-B, Terminate 001 and Terminate 002.

    It would be beneficial to clarify whether the order in the column is relevant, and if not, sort the transitions alphabetically.

  • Reported: PSSM 1.0 — Thu, 27 Jul 2023 08:30 GMT
  • Updated: Fri, 28 Jul 2023 15:41 GMT

Atomicity of transition, entry behavior and state completion

  • Key: PSSM11-21
  • Status: open  
  • Source: Budapest University of Technology and Economics ( Mr. Marton Elekes)
  • Summary:

    Do the following steps form a single atomic step: firing a transition, the target state's entry behavior then completion?

    E.g., in Test Transition 019 the 6th RTC step simultaneously fires T1.2 and T2.2 transitions from [S1[S1.1, S2.1]] configuration.
    The traces show that which one of the parallel transitions (T1.2, T2.2) is fired first determines which target state (S1.2, S2.2) completes and puts completion event into the event pool first, because all traces are either:

    • ..., T1.2(effect), ..., T2.2(effect), T1.3(effect), T2.3(effect) or
    • ..., T2.2(effect), ..., T1.2(effect), T2.3(effect), T1.3(effect).

    This would imply that all of the following is an atomic step and they cannot overlap with their counterparts in the other region: transition effect, entering the target state, state completion, putting CE(target) into the event pool. This rule is never mentioned in PSSM and it contradicts Test Entering 011 where ..., S1.2(entry), ..., S1.1(entry), ... trace order and CE(S1.1), CE(S1.2) completion event order are present.

    I think the traces should be all the possible 12 execution order of this activity diagram.

    This means that currently these 6 traces are missing, where the order of the last two effects is switched:

    • S1.1(exit)::T1.2(effect)::S2.1(exit)::T2.2(effect)::T2.3(effect)::T1.3(effect)
    • S1.1(exit)::S2.1(exit)::T1.2(effect)::T2.2(effect)::T2.3(effect)::T1.3(effect)
    • S1.1(exit)::S2.1(exit)::T2.2(effect)::T1.2(effect)::T1.3(effect)::T2.3(effect)
    • S2.1(exit)::S1.1(exit)::T2.2(effect)::T1.2(effect)::T1.3(effect)::T2.3(effect)
    • S2.1(exit)::S1.1(exit)::T1.2(effect)::T2.2(effect)::T2.3(effect)::T1.3(effect)
    • S2.1(exit)::T2.2(effect)::S1.1(exit)::T1.2(effect)::T1.3(effect)::T2.3(effect)

    The atomicity problem is also present in:

    • Entry 002-B, where fired transition order determines the order of entry behaviors and the order of CEs in the event pool,
    • Terminate 001 and Terminate 002, where RTC steps transition order determines the order of entry behaviors and completion events.
  • Reported: PSSM 1.0 — Thu, 27 Jul 2023 08:28 GMT
  • Updated: Fri, 28 Jul 2023 15:40 GMT

Missing alternative trace for orthogonal region in Test Transition 011-D

  • Key: PSSM11-20
  • Status: open  
  • Source: Budapest University of Technology and Economics ( Mr. Marton Elekes)
  • Summary:

    In Test Transition 011-D the entry behavior of states S1.1 and S2.1 in the two regions should be concurrent, therefore the following two alternative traces are missing:

    • S2.1(entry)::S1.1(entry)::T3(effect)::S1.1(exit)::S2.1(exit)::S1(exit)
    • S2.1(entry)::S1.1(entry)::T3(effect)::S2.1(exit)::S1.1(exit)::S1(exit)
  • Reported: PSSM 1.0 — Thu, 27 Jul 2023 08:25 GMT
  • Updated: Fri, 28 Jul 2023 15:40 GMT

Inconsistent behavior in Test Transition 011-C

  • Key: PSSM11-19
  • Status: open  
  • Source: Budapest University of Technology and Economics ( Mr. Marton Elekes)
  • Summary:

    State S1.2 in Fig. 9.16. has an entry behavior that prints S1.2(exit) to the trace. It should print S1.2(entry).
    This problem is also present in the test suite XMI.

  • Reported: PSSM 1.0 — Thu, 27 Jul 2023 08:24 GMT
  • Updated: Fri, 28 Jul 2023 15:40 GMT

Partial trace in Test Transition 011-A

  • Key: PSSM11-18
  • Status: open  
  • Source: Budapest University of Technology and Economics ( Mr. Marton Elekes)
  • Summary:

    S1(exit) is missing from the end of the trace in Transition 011-A. (It is executed after T1.4 and before T3 transitions, which do not print to the trace.)
    The whole trace should be the following: S1.1(entry)::S1.1(exit)::T1.3(effect)::S1.2(entry)::S1(exit)

  • Reported: PSSM 1.0 — Thu, 27 Jul 2023 08:22 GMT
  • Updated: Fri, 28 Jul 2023 15:39 GMT

Start event is missing in Tests Transition 007 and Event 017-B

  • Key: PSSM11-17
  • Status: open  
  • Source: Budapest University of Technology and Economics ( Mr. Marton Elekes)
  • Summary:

    Start event is missing from Received event occurrence(s) of Test Transition 007 and Event 017-B. It should be listed there since the SemanticTest class always sends Start signal to the target (and the tester) (PSSM p. 61).

  • Reported: PSSM 1.0 — Thu, 27 Jul 2023 08:20 GMT
  • Updated: Fri, 28 Jul 2023 15:39 GMT

Checking the completion of doActivity

  • Key: PSSM11-16
  • Status: open  
  • Source: Budapest University of Technology and Economics ( Dr. Zoltan Micskei)
  • Summary:

    Currently the specification says: "Completion occurs when, after a run-to-completion step, there are no more event accepter registered for the doActivity with its DoActivityContextObjectActivation".

    However, cannot a long-running action still be executing even when there is no accepter registered?

    For example:

    init -> fork -> accept -> join -> final
    -> action with computation

    The accept can accept an event and move to the join (run-to-completion step performed for the doActivity), but the action with computation can still be running on its own thread (according to the Threading Model section in the fUML specification). What guarantees that there are no more concurrent parts still executing when there is no accepter registered (there is no "default" accepter for a doActivity as far as I understand).

  • Reported: PSSM 1.0 — Wed, 19 Jul 2023 09:23 GMT
  • Updated: Fri, 28 Jul 2023 15:34 GMT

DoActivity alternative traces are missing in Test Behavior 004

  • Key: PSSM11-15
  • Status: open  
  • Source: Budapest University of Technology and Economics ( Ármin Zavada)
  • Summary:

    Two alternative execution of test Behavior 003-B is missing. Since "a doActivity Behavior ... is executed on its own thread of execution" (PSSM p. 39), slow doActivity execution is possible.

    If the doActivity is running slowly, dispatching AnotherSignal and the internal transition might come first. The resulting trace is: S1(entry), T3(effect), S1(doActivityPartI), S1(doActivityPartII).

    If the doActivity is running even more slowly, dispatching and discarding Continue event can precede firing accept(Continue) AcceptEventAction in the doActivity to register EventAccepter. This results in a deadlock. In this case a possible trace is the following: S1(entry), T3(effect), Continue event dispatched and discarded, S1(doActivityPartI), accept(Continue) in doActivity registers EventAccepter, deadlock. See similar issue of Test Behavior 003-B.

    Another related issue: testEnd effect of transition T4 is missing from Figure 9.10.

  • Reported: PSSM 1.0 — Tue, 18 Jul 2023 10:49 GMT
  • Updated: Tue, 18 Jul 2023 18:17 GMT

DoActivity can cause deadlock in Test Behavior 003-B

  • Key: PSSM11-14
  • Status: open  
  • Source: Budapest University of Technology and Economics ( Ármin Zavada)
  • Summary:

    An alternative execution of test Behavior 003-B is missing. Since "a doActivity Behavior ... is executed on its own thread of execution" (PSSM p. 39), slow doActivity accepter registration is possible, i.e., Continue event is received earlier than the accept(Continue) AcceptEventAction in the doActivity is fired to register EventAccepter. In this case the Continue event is discarded in the lack of a matching accepter, then the doActivity and thereby the whole state machine wait for a new Continue event indefinitely, which results in a deadlock.
    The following trace describes the sequence of events: S1(entry), Continue event dispatched and discarded, S1(doActivityPartI), accept(Continue) in doActivity registers EventAccepter, deadlock.

  • Reported: PSSM 1.0 — Tue, 18 Jul 2023 10:49 GMT
  • Updated: Tue, 18 Jul 2023 18:17 GMT

Mismatch of operation name in figure and text: register vs. registerCompletionEvent

  • Key: PSSM11-13
  • Status: open  
  • Source: Budapest University of Technology and Economics ( Dr. Zoltan Micskei)
  • Summary:

    For SM_ObjectActivation the figure (Figure 8.4) displays that it has a register( in completionEventOccurrence: CompletionEventOccurrence [1]) operation.
    However, the text below refers to a registerCompletionEvent operation ("The registerCompletionEvent operation is used to add").
    The semantics xmi also contains register as an operation name. However, registerCompletionEvent might be a better name, as it is similar to the registerDeferredEvent operation name.

  • Reported: PSSM 1.0 — Fri, 24 Mar 2023 08:24 GMT
  • Updated: Fri, 31 Mar 2023 19:08 GMT

Wrong multiplicity of DoActivityContextObject.doActivityEventAccepter

  • Key: PSSM11-12
  • Status: open  
  • Source: Budapest University of Technology and Economics ( Mr. Marton Elekes)
  • Summary:

    Figure 8.9 (doActivity Behavior Execution) shows that a DoActivityContextObject has exactly 1 DoActivityExecutionEventAccepter.

    This multiplicity should be unlimited since

    • a doActivity can register multiple EventAccepters, ("While a doActivity Behavior is executing, it may need to register EventAccepters for specific EventOccurrences.")
    • which are encapsulated into DoActivityExecutionEventAccepters, and ("When an executing doActivity Behavior registers an EventAcceptor ..., it is wrapped in a DoActivityEventAccepter...")
    • a DoActivityExecutionEventAccepter encapsulates only a single EventAccepter (1 encapsulatedAccepter in the figure).

    The text uses two names for the same class, DoActivityExecutionEventAccepter and DoActivityEventAccepter.

  • Reported: PSSM 1.0 — Thu, 21 Jul 2022 10:35 GMT
  • Updated: Wed, 24 Aug 2022 16:05 GMT

Clarification needed for abortion in Test Behavior 003-A

  • Key: PSSM11-11
  • Status: open  
  • Source: mit.bme.hu ( Zoltan Micskei)
  • Summary:

    Test Behavior 003-A describes a scenario, where the doActivity is aborted. There are no alternative traces specified, only the one, where the doActivity is aborted after printing S1(doActivityPartI) and waiting for the Continue signal.

    Why is there no alternative trace listed, where the doActivity is aborted before executing the printing of S1(doActivityPartI)? From the current test it seems that the doActivity can be aborted only when it is waiting for a signal. However, Test Event 017-B and Terminate 002​ explicitly lists traces where the doActivity is aborted before printing anything or completing its initial first RTC step.

    The Received event occurrence part lists "AnotherSignal – received when in configuration S1". From this, it seems to me that AnotherSignal can be processed any time and S1 can be exited before executing any part of the doActivity.

    Moreover:
    1) It would be helpful to clarify abortion e.g. in 8.5.5 StateActivation exit. In which phases of its execution can the doActivity aborted? At the boundaries of RTC steps? Or even inside an RTC step?
    2) A possible test case to showcase these questions could be the following. One simple state with a doActivity, entering the state is triggered by Start, exiting is triggered by Continue. The doActivity has two WriteStructuralFeatureAction, that writes 1 and 2 to an integer value owned by the statemachine, which is initialy 0 (there is neither timing or waiting in the doActivity). Received events are Start, Continue. List of traces could show, whether the doActivity can be aborted in such ways, that in the end the integer is 0, 1 or 2.

  • Reported: PSSM 1.0 — Fri, 25 Sep 2020 07:56 GMT
  • Updated: Thu, 1 Oct 2020 16:51 GMT

Typo in Figure 9.116 (TransitionExecutionAlgorithmTest)

  • Key: PSSM11-10
  • Status: open  
  • Source: mit.bme.hu ( Zoltan Micskei)
  • Summary:

    In S1: "/do Activity exit" shoud be "/exit Activity exit"

  • Reported: PSSM 1.0 — Fri, 25 Sep 2020 07:31 GMT
  • Updated: Thu, 1 Oct 2020 16:51 GMT

Error in alternative traces of 9.3.3.11 Transition 017

  • Key: PSSM11-9
  • Status: open  
  • Source: mit.bme.hu ( Zoltan Micskei)
  • Summary:

    The alternative execution traces part lists the following traces:
    "2. T2(effect)::S1(entry)::T2.2(effect)::T3.2(effect)::S3.1(doActivity)::T3.1.2(effect)
    3. T2(effect)::S1(entry)::T2.2(effect)::T3.2(effect)::T3.1.2(effect)::S3.1(doActivity)"

    I think these traces are not valid. T3.2 is triggered by the completion event of S3.1. However, as per "StateActivation completion" on page 37, "The StateActivation can only generate a CompletionEventOccurrence when all RegionActivations for Regions of the composite state have completed and the doActivity Behavior has completed.". Therefore T3.2(effect) cannot be printed before S3.1(doActivity).

    The precedence relations are the followings. T2 -> S1; S1 -> T2.2; S1 -> S1(do); S1 -> T3.1.2, S1(do) -> T3.2, T3.1.2 -> T3.2

    The full list of valid traces are the followings (some of them are missing from the current list)

    T2 S1 T2.2 T3.1.2 S3.1(do) T3.2
    T2 S1 T2.2 S3.1(do) T3.1.2 T3.2
    T2 S1 T3.1.2 T2.2 S3.1(do) T3.2
    T2 S1 T3.1.2 S3.1(do) T2.2 T3.2
    T2 S1 T3.1.2 S3.1(do) T3.2 T2.2
    T2 S1 S3.1(do) T2.2 T3.1.2 T3.2
    T2 S1 S3.1(do) T3.1.2 T2.2 T3.2
    T2 S1 S3.1(do) T3.1.2 T3.2 T2.2

  • Reported: PSSM 1.0 — Fri, 25 Sep 2020 07:28 GMT
  • Updated: Thu, 1 Oct 2020 16:51 GMT

Typo in description of generated trace for 9.3.3.11 Transition 017

  • Key: PSSM11-8
  • Status: open  
  • Source: mit.bme.hu ( Zoltan Micskei)
  • Summary:

    "T3.1.2 is triggered by the dispatching of CE(S3.1.2)" -> CE(S3.1.1)

    There is no S3.1.2 in the state machine. The RTS steps part correctly refers to [CE(S3.1.1)] in the event pool.

  • Reported: PSSM 1.0 — Fri, 25 Sep 2020 06:59 GMT
  • Updated: Thu, 1 Oct 2020 16:50 GMT

Wrong figure references in some of the test cases

  • Key: PSSM11-7
  • Status: open  
  • Source: mit.bme.hu ( Zoltan Micskei)
  • Summary:

    The text of some of the test cases reference wrong figures. For example:

    • 9.3.3.9 Transition 015 (page 86): "The doActivity for state S1 state is exactly the same as the one presented in Figure 9.8.". The doActivity in Figure 9.8 contains an accepts and prints doActivityPartI and doActivityPartII. According to the PSSM test suite xml, the doActivity for Transition 015 just prints "S1(doActivity)" and does not contain any accept.
    • 9.3.6.3 Exiting 002 (page 132):
    • “The state machine that is executed for this test is presented in Figure 9.8.” it is Figure 9.48.
    • “The doActivity behavior of S1 has exactly the same behavior as the one presented in Figure 9.37” it is Figure 9.8.
  • Reported: PSSM 1.0 — Fri, 25 Sep 2020 06:51 GMT
  • Updated: Thu, 1 Oct 2020 16:50 GMT

Notation for entry, do and exit behaviors is wrong

  • Key: PSSM11-5
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The correct notation is for example:

    entry/Activity entry

    All the diagrams in PSSM show instead

    /entry Activity entry

    This is confusing and should get changed.
    Also the text in all examples of the UML specification is left justified. It is not mentioned as a requirement, but I think most tools follow this convention. In the PSSM specification the text is centered. I suggest to change it to left justified.
    The effect of Transitions is notated with a colon:

    /Activity: effect.

    I think that should also be consistent. Either remove the colon, or use it with state behaviors as well.
    As an additional suggestion: In most cases it is not relevant for the test case, that an activity is called. The string "Activity" could be left out to keep the diagram less cluttered.

  • Reported: PSSM 1.0b1 — Tue, 3 Apr 2018 15:31 GMT
  • Updated: Mon, 1 Apr 2019 18:41 GMT

PSSM implementation shall conform to bUML

  • Key: PSSM11-4
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Jeremie Tatibouet)
  • Summary:

    The behavioral part of the PSSM semantic model is specified using Java syntax. The subset of Java that is used does not always conform to the mapping rules defined in Annex A of fUML between Java and Activities.

    Examples:

    1. Usage of index starting from 0 instead of 1 in StateActivation::hasCompleted operation.
    2. Constructor call with arguments in StateMachineEventAccepter::accept operation.
    3. Usage of an iterative for loop instead a parallel for loop in StateActivation::enterRegion operation.
  • Reported: PSSM 1.0b1 — Thu, 13 Apr 2017 13:02 GMT
  • Updated: Mon, 1 Apr 2019 18:41 GMT

Tests that send multiple signals are not correct

  • Key: PSSM11-3
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Any test in the PSSM test suite with a test driver that sends multiple signals to the model being tested may not currently be properly allowing all possible execution traces. This is because itt cannot, in general, be presumed that event occurrences are received in the order they are sent, even if they are all sent from the same thread. This was always true in fUML (per the statement of “the semantics of inter-object communications mechanisms” in subclause 2.4 of the spec), but it is completely, formally clear in fUML 1.3, in which EventOccurrence is an active class, such that all event occurrences are sent concurrently with each other.

    For example, consider test Transition 007 (described in subclause 9.3.3.2 of the PSSM beta spec). The tester behavior for this test sequentially sends three signal instances: AnotherSignal, Continue and Continue again. However, while these signals are sent sequentially, there is no guarantee they will be received by the tested state machine in the same order. For example, one of the Continue signal instances could be received before the AnotherSignal instance, which would cause the state machine (as shown in Fig. 9.12) to take transition T3 to S2 and never get to S3.

    Rather than try to capture all the possible traces that should be allowed by the such tests a s currently modeled, it would be better to modify the tests so that they should only produce the trace that is currently suspected. This can be done by having the state machine under test send signals back to the tester, in order to coordinate the sending of sequential signals. For example, in the case of Transition 007, the state machine could send signals back to the tester as part of the doTraversial behaviors for transitions T1 and T2. The test behavior would then have to include accept event actions in order to wait between the send signal actions. (Of course, to allow the test to send signals back to the tester, either the Tester/Target association in the test architecture would need to be made bidirectional, or some signaling mechanism would need to be provided through the SemanticTest class.)

  • Reported: PSSM 1.0b1 — Tue, 5 Dec 2017 23:11 GMT
  • Updated: Mon, 1 Apr 2019 18:41 GMT

Classifier behavior of the SemanticTest class refers to TestCase stereotype

  • Key: PSSM11-2
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Section 9.2.2.2.3 states: "The classifier behavior of a semantic test has the TestCase stereotype applied."

    The source of the TestCase stereotype is not mentioned. Presumably, it is UTP, but the relationship of PSSM and UTP is not further described except a list of definitions from the UTP specification including Test Case on page 61.

    The test case stereotype requires a return parameter of type VerdictKind. That is not implemented by PSSM.

    Regarding the general OMG requirement for OMG specifications to reuse other specifications if possible, I propose to integrate the test case stereotype including the verdict concept from UTP.

  • Reported: PSSM 1.0b1 — Wed, 13 Feb 2019 15:15 GMT
  • Updated: Tue, 19 Feb 2019 14:38 GMT

LocalTransitionActivation exit source unclear

  • Key: PSSM11-1
  • Status: open  
  • Source: steelbreeze.net ( David Mesquita-Morris)
  • Summary:

    The text for the semantics of exiting the source of a local transition appears incomplete; the first paragraph provides a condition under which the source cannot be exited, but if that condition is not met, does not describe how the source should be exited.

  • Reported: PSSM 1.0b1 — Wed, 19 Dec 2018 09:53 GMT
  • Updated: Mon, 14 Jan 2019 20:31 GMT

Eliminate PID_DA definition

  • Key: PSS-47
  • Legacy Issue Number: 43
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The definition for the PID_DA should be eliminated and the old attribute moved to the base PID definition. This will provide an invariant and abstract representation for all persistence state.

  • Reported: PSS 1.0b1 — Wed, 3 Jul 1996 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:10 GMT

PDS_DA::DAObjectID

  • Key: PSS-46
  • Legacy Issue Number: 42
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: typedef string DAObjectID should be typedef sequence<octet> DAObjectID. This will allow more flexibility in the PDS_DA implementation without breaking any functionality.

  • Reported: PSS 1.0b1 — Wed, 3 Jul 1996 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:10 GMT

PDS_DA DDL should exclude type Any

  • Key: PSS-45
  • Legacy Issue Number: 41
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The inclusion of type Any in object definitions should be eliminated, because it makes schema evolution completely unmanageable.

  • Reported: PSS 1.0b1 — Wed, 3 Jul 1996 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:10 GMT

SD interface

  • Key: PSS-44
  • Legacy Issue Number: 40
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It is unclear how SD object implementations get intially connected to the POS implementation.

  • Reported: PSS 1.0b1 — Wed, 3 Jul 1996 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:10 GMT

Support for DAObject interface

  • Key: PSS-48
  • Legacy Issue Number: 44
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: pg. 5-24, paragraph 1, section 5.10.2 states that "a data object is not require to support this interface." If so, there is not a way to free the storage for a data object or generate a PID.

  • Reported: PSS 1.0b1 — Wed, 3 Jul 1996 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:10 GMT

PO::delete and POM::delete

  • Key: PSS-43
  • Legacy Issue Number: 39
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The delete operation should not have a PID parameter – what does it mean if the PID specified is not the currently connected PID?

  • Reported: PSS 1.0b1 — Wed, 3 Jul 1996 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:10 GMT

PO::store/restore

  • Key: PSS-42
  • Legacy Issue Number: 38
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Because para. 3, pg. 5-12 states that a PO can only have a single connection at a time, all behavior of these operations would need to be provided by the POM, which is difficult to do interoperably.

  • Reported: PSS 1.0b1 — Wed, 3 Jul 1996 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:10 GMT

PO::disconnect and POM::disconnect parameters

  • Key: PSS-41
  • Legacy Issue Number: 37
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The PID parameter is extraneous, as the specification states that a PO can only have a single connection at a time.

  • Reported: PSS 1.0b1 — Wed, 3 Jul 1996 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:10 GMT

PO::connect and POM::connect exception needed

  • Key: PSS-40
  • Legacy Issue Number: 36
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: An exception is needed to inform of an invalid connection (DDL type, protocol, etc.).

  • Reported: PSS 1.0b1 — Wed, 3 Jul 1996 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:10 GMT

PIDFactory::create_PID* definitions

  • Key: PSS-37
  • Legacy Issue Number: 33
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The definition should not contain "...key that identifies a particular PID implementation." Overall these definitions contains a lot of confusion about PID identity.

  • Reported: PSS 1.0b1 — Wed, 3 Jul 1996 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:10 GMT

PID derivation

  • Key: PSS-36
  • Legacy Issue Number: 32
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The PID interface derivation usage in the PID_DA and other examples in the specification limit the ability of the protocol to be decoupled from the datastore as intended.

  • Reported: PSS 1.0b1 — Wed, 3 Jul 1996 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:10 GMT

PO::p attribute should be readonly

  • Key: PSS-39
  • Legacy Issue Number: 35
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: This attribute should simply reflect the currently connected PID, to avoid placing an additional burden on the PO implementation which is not needed.

  • Reported: PSS 1.0b1 — Wed, 3 Jul 1996 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:10 GMT

Returning PDS from PO::connect

  • Key: PSS-38
  • Legacy Issue Number: 34
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The PDS reference should not be returned from the PO::connect operation, as this creates a number of implementation problems.

  • Reported: PSS 1.0b1 — Wed, 3 Jul 1996 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:10 GMT

PID attributes should be readonly

  • Key: PSS-33
  • Legacy Issue Number: 29
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Attributes of the PID interface should be readonly and only settable through their initial creation by the PIDFactory and the service implementation.

  • Reported: PSS 1.0b1 — Wed, 3 Jul 1996 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:10 GMT

PID additional attributes

  • Key: PSS-32
  • Legacy Issue Number: 28
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The PID should add attributes for the Datastore object reference and an opaque PersistentStateIdentifier. This allows maximum flexibility without the need to subclass the PID interface.

  • Reported: PSS 1.0b1 — Wed, 3 Jul 1996 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:10 GMT

Factory interface should be specified

  • Key: PSS-31
  • Legacy Issue Number: 27
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The Factory interfaces should be specified for all service component interfaces to provide for integration with the Lifecycle Service.

  • Reported: PSS 1.0b1 — Wed, 3 Jul 1996 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:10 GMT

Issue POS 2.0 RFP

  • Key: PSS-30
  • Legacy Issue Number: 26
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: TRC has found several issues that cannot be addressed within this forum and which would need to be addressed in a new POS 2.0 spec.

  • Reported: PSS 1.0b1 — Wed, 3 Jul 1996 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:10 GMT

Typo in PID section

  • Key: PSS-35
  • Legacy Issue Number: 31
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: pg. 5-9, paragraph 6, remove extra p from "the ppersistent object..."

  • Reported: PSS 1.0b1 — Wed, 3 Jul 1996 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:10 GMT

PID vs. OID definition

  • Key: PSS-34
  • Legacy Issue Number: 30
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The last sentence of para. 4 on pg. 5-9 is not implementable. How is the new storage allocation and location determined?

  • Reported: PSS 1.0b1 — Wed, 3 Jul 1996 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:10 GMT

PSDL Grammar problems: Page 3-33

  • Key: PSS2-8
  • Legacy Issue Number: 5504
  • Status: open  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    paragraph 3.2.5.6 : There is two mistakes : "abstract_storagehome" and
    "abstract""storagehome" are referenced instead of "abstract
    storagehome

  • Reported: PSS 1.0 — Mon, 15 Jul 2002 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:09 GMT

PSDL Grammar problems: Page 3-31

  • Key: PSS2-7
  • Legacy Issue Number: 5503
  • Status: open  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    paragraph 3.2.5.1 : the production <abstract_storage_type_member> refers
    to
    <abstract_storage_type_dcl> which is defined in production 10 as
    <psdl_state_dcl>.
    Pick one or the other and changes references as required

  • Reported: PSS 1.0 — Mon, 15 Jul 2002 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:09 GMT

PSDL Grammar problems: Page 3-28

  • Key: PSS2-9
  • Legacy Issue Number: 5501
  • Status: open  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    Production 19 : "abstract_storagehome" is not correct. Replace it with
    "abstract storagehome".

  • Reported: PSS 1.0 — Mon, 15 Jul 2002 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:09 GMT

Unable to find the refrence to the ConnectorRegistry from the appendix A.1

  • Key: PSS2-10
  • Legacy Issue Number: 4801
  • Status: open  
  • Source: Anonymous
  • Summary:

    Chapter 1.5 mentions the ConnectorRegistry object. From the code sample I assume that it should be part of the CosPersistentState module. Hoveever, I am unable to find the refrence to the ConnectorRegistry from the appendix A.1, "Complete IDL" (shouldn't it be "Complete PSDL" instead?)

    the ConnectorRegistry is present also in the appendix B, "Example: An Implementation of the Naming Service"

  • Reported: PSS 1.0 — Fri, 4 Jan 2002 05:00 GMT
  • Updated: Sat, 7 Mar 2015 06:09 GMT

existence of a ConnectorRegistry in the CosPeristentState module

  • Key: PSS2-3
  • Legacy Issue Number: 7968
  • Status: open  
  • Source: EsotericSystems, Inc. ( David Knox)
  • Summary:

    The referenced page cites the existence of a ConnectorRegistry in the CosPeristentState module. But there is no such interface in the IDL. Perhaps I've missed something?

  • Reported: PSS 1.0 — Fri, 3 Dec 2004 05:00 GMT
  • Updated: Sat, 7 Mar 2015 06:09 GMT

PSS FTF: Sequence should be added in the PSDL state types

  • Key: PSS2-5
  • Legacy Issue Number: 6698
  • Status: open  
  • Source: National Lab, Distributed Process, China ( Deng Bo)
  • Summary:

    In the PSDL state type grammar, the state member can't be a sequence type as the following text:
    formal/02-06-05 on page 3-8
    <psdl_state_type_spec> ::= <base_type_spec>

    <string_type>
    <wide_string_type>
    <abstract_storagetype_ref_type>
    <scoped_name>
    ...
    <scoped_name> must denote a previously declared [abstract or local] interface,
    struct, union, type, [abstract] valuetype, or a previously defined abstract storagetype.
    ...

    It's very useful if the sequence type be a state member, which is currently not possible.

    Resolution:

    Replace the following text in formal/02-06-05 on page 3-8
    <psdl_state_type_spec> ::= <base_type_spec>

    <string_type>
    <wide_string_type>
    <abstract_storagetype_ref_type>
    <scoped_name>

    with
    <psdl_state_type_spec> ::= <base_type_spec>

    <sequence_type>
    <string_type>
    <wide_string_type>
    <abstract_storagetype_ref_type>
    <scoped_name>
  • Reported: PSS 1.0 — Tue, 16 Dec 2003 05:00 GMT
  • Updated: Sat, 7 Mar 2015 06:09 GMT

The connectorRegistry interface is removed from spec. but still used

  • Key: PSS2-2
  • Legacy Issue Number: 6683
  • Status: open  
  • Source: National Lab, Distributed Process, China ( Deng Bo)
  • Summary:

    1. formal/02-09-06 on page 1-6 import org.omg.*; CORBA.ORB myOrb = CORBA.ORB.init(); CosPersistentState.ConnectorRegistry connectorRegistry = CosPersistentState.ConnectorRegistryHelper.narrow( myOrb.resolve_initial_references("PSS") ); CosPersistentState.Connector connector = connectorRegistry.find_connector(""); ... 2. formal/02-09-06 on page B-6 public class NamingServer { public static void main(String[] args)

    { // initializes ORB CORBA.ORB myOrb = CORBA.ORB.init(args); // get connector registry CosPersistentState.ConnectorRegistry registry = CosPersistentState.ConnectorRegistryHelper. narrow( myOrb.resolve_initial_references("PSS") ); // get connector ... }

    Resolution:

    1. Remove the following text in formal/02-09-06 on page 1-6

    CosPersistentState.ConnectorRegistry connectorRegistry = CosPersistentState.ConnectorRegistryHelper.narrow( myOrb.resolve_initial_references("PSS") ); CosPersistentState.Connector connector = connectorRegistry.find_connector("");

    2. Remove the following text in formal/02-09-06 on page B-6

    // get connector registry CosPersistentState.ConnectorRegistry registry = CosPersistentState.ConnectorRegistryHelper. narrow( myOrb.resolve_initial_references("PSS") );

  • Reported: PSS 1.0 — Sat, 6 Dec 2003 05:00 GMT
  • Updated: Sat, 7 Mar 2015 06:09 GMT

PSDL Grammar problems: Page 3-33

  • Key: PSS2-4
  • Legacy Issue Number: 5505
  • Status: open  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    paragraph 3.2.6.4 : The <absract_storagehome_header> is not correctly
    defined.
    The production [<primary_key_dcl>] is missing. Add it.

  • Reported: PSS 1.0 — Mon, 15 Jul 2002 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:09 GMT

PSDL Grammar problems: Page 3-29

  • Key: PSS2-6
  • Legacy Issue Number: 5502
  • Status: open  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    Production 27 : a double quote is missing : {" instead of "{". Add the
    double quote.
    Production 45 : an underscore is missing in the name of the rule.
    Replace <abstract storagehome_name> with <abstract_storagehome_name>
    Production 48: there is a redundancy : square brackets are not
    useful.Remove them

  • Reported: PSS 1.0 — Mon, 15 Jul 2002 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:09 GMT