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.

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.

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.

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

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

"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.

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.

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.

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.

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.)

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.

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.

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.

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

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

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

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.

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

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.

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

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

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

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.

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

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

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

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.

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

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.

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

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

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

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

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

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"

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?

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>

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>

with
<psdl_state_type_spec> ::= <base_type_spec>

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)

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") );

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

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