<commit_before>---

Copyright 2013 Mentor Graphics Corp.  All Rights Reserved.

---

# Incorrect Verifier behavior when starting multiple instances of identical configuration
### xtUML Project Design Note


1. Abstract
-----------
Currently when multiple instances are started from an identical configuration
the instances are not all being executed properly.   This issue is raised to
investigate and resolve this problem.

2. History
----------

3. Document References
----------------------
[1] ClearQuest DEI dts0100949572
[2] https://github.com/xtuml/doc/issues/73
[3] ClearQuest DEI dts0101007748 - Multiple class entries in session session
    explorer when multiple component instances are launched.

4. Background
-------------
When Verifier is started with multiple instances of an identical configuration, 
calls towards realized components are routed to the wrong instance 
(java object) when they are invoked from a delegated port of an intermediate 
nested component. 

In such situations all invocations on the VIEC interface will be invoked on 
same instance of the realized component (same java object) regardless of the 
fact that several configuration instances are started. 

Verifier must assure that calls made in one configuration instance are 
correctly propagated to the instance of the realized component which belongs to 
that configuration instance and not to the other one.

5. Requirements
---------------
5.1 When multiple instances of the same configuration are executed in verifier,
    each of these instances shall be treated as independent execution units.


6. Analysis
-----------
The raiser attributed this problem to incorrect binding of VIEC realized java
classes. However investigation documented in the CQ issue[1] established that
the same behavior can be shown in a fully modeled context. The issue comment
speculated that the problem with the wiring or dynamic componet instance
resolution. More detailed investigation shows that it is indeed the start up
wiring process that is defective.

6.1 Locus of defect
Since the models which show this issue used nested components with delegation,
it was assumed that delegation behavior was defective. Investigation shows
that in fact it is normal Satisfaction instances which are being miswired.

The problem code lies in BPDebugTarget. There are two methods in this class
that locate components for wiring during Verifier startup. These methods are
getProviderTargetFor() and getRequirerTargetFor(). Both methods take a
NonRootModelElement argument which is assumed to be either a Satisfaction or
a Delegation instance.

These methods are very similar as might be expected from their names. They both
show the same defect. The methods first look for the Interface Reference to be
wired, and then search for the component instances associated with that
reference by using the following traversal:

select any comp_instance related by iref->CL_IC[R4700]->I_EXE[R2963];

NOTE: This traversal is written in java rather than action langauge, but the
traversal is easier to read written as OAL.

The defect lies in the second step of the traversal. R2963 is a one to many in
the direction traversed. When session launches multiple instances of a
component which nests other components, the same component reference maps to
multiple component instances. The select any traversal chooses the first
component instance found, which explains exatcly the behavior seen in the
issue.

7. Design
---------
The required fix is to find the one component instance which is in the
inter-set found by:

select many comp_instance related by iref->CL_IC[R4700]->I_EXE[R2963];

(Note: _many_)

and:

select many children related by parent->I_CIN[R2974]->I_EXE[R2974];

This inter-set is always guaranteed to contain a single component, even whe
multiple instances of the same nested components are launched, because each
Interface Reference is unique within a given Component, and each parent
Component Instance contains only one Component Instance for each nested
Component.

In order for this fix to be applied, the parent component must be added as
an argument to the two methods concerned. When top level components are
launched, the parent component is null, in which case the previously
defective traversal is used. This is robust in this one case, because only
nested components can have multiple instantiations. Hence in the top level
case, R2963 will always yield a single instance.

The final proposed pseudo code is as follows:

```
Component Instance result;
if not_empty parent
  select many candidates related by iref->CL_IC[R4700]->I_EXE[R2963];
  select many children related by parent->I_CIN[R2974]->I_EXE[R2974];  
  for each child in children
    if candidates contains child
      result = child;
      break;
    end if;
  end for;
else
  select any result related by iref->CL_IC[R4700]->I_EXE[R2963];
end if;
```

The modified code includes some additional internal error reporting to detect
future assumption failures in this area, though none are expected after this
change.

8. Design Comments
------------------
It was noted during testing that the Session Explorer incorrectly shows three
class instances under the test package for each component. There should only
be one for each component. An issue [3] is raised to track this defect.

9. Work Required
----------------
Implement the above pseudo code as java in the getProviderTargetFor() and
getRequirerTargetFor() methods. Modify the wireChannel() and wireChannels()
methods which call the two modified methods so that they supply the parent
Component Instance as an argument.

10. Unit Test
------------
10.1 Verify that calls from multiple instances of the same configuration are 
     routed correctly.
_- Import the Bugs_testbed.zip as an existing project 
   (from \\wv\dfs\bridgepoint\field_data\dts0100949572)
_- Fix the Java build path to correspond to the core.jar plugin in your install
_- Launch the "withoutDelegationToNested" debug launch configuration in Verifier
_- In Session Explorer execute all 3 instances of 
   withoutDelegationToNested::Bugs_testbed::library::CompA::portOne::ifOne::start 
   in sequence
_- Correct output in Console is shown:
   Simulation started.
   User invoked interface message: start
   CompRealized::init called on instance(1) with parameter instId = 1
   User invoked interface message: start
   CompRealized::init called on instance(2) with parameter instId = 2
   User invoked interface message: start
   CompRealized::init called on instance(3) with parameter instId = 3
_- Terminate the Verifier session

_- Launch the "withDelegationToNested" debug launch configuration in Verifier
_- In Session Explorer execute all 3 instances of 
   withDelegationToNested::Bugs_testbed::library::CompA::portOne::ifOne::start in sequence
   
_R CORRECT output in Console is shown:
   
   Simulation started.
   User invoked interface message: start
   CompRealized::init called on instance(1) with parameter instId = 1
   User invoked interface message: start
   CompRealized::init called on instance(2) with parameter instId = 2
   User invoked interface message: start
   CompRealized::init called on instance(3) with parameter instId = 3
   
_R Different instance of realized component is used in each component 
   configuration.



To Reproduce: see [1].

End
---
<commit_msg>Job:dts0100992921GH #73 Address review obs.<commit_after>---

Copyright 2013 Mentor Graphics Corp.  All Rights Reserved.

---

# Incorrect Verifier behavior when starting multiple instances of identical configuration
### xtUML Project Design Note


1. Abstract
-----------
Currently when multiple instances are started from an identical configuration
the instances are not all being executed properly.   This issue is raised to
investigate and resolve this problem.

2. History
----------

3. Document References
----------------------
[1] ClearQuest DEI dts0100949572

[2] https://github.com/xtuml/doc/issues/73

[3] ClearQuest DEI dts0101007748 - Multiple class entries in session session
    explorer when multiple component instances are launched.

4. Background
-------------
When Verifier is started with multiple instances of an identical configuration, 
calls towards realized components are routed to the wrong instance 
(java object) when they are invoked from a delegated port of an intermediate 
nested component. 

In such situations all invocations on the VIEC interface will be invoked on 
same instance of the realized component (same java object) regardless of the 
fact that several configuration instances are started. 

Verifier must assure that calls made in one configuration instance are 
correctly propagated to the instance of the realized component which belongs to 
that configuration instance and not to the other one.

5. Requirements
---------------
5.1 When multiple instances of the same configuration are executed in verifier,
    each of these instances shall be treated as independent execution units.


6. Analysis
-----------
The raiser attributed this problem to incorrect binding of VIEC realized java
classes. However investigation documented in the CQ issue[1] established that
the same behavior can be shown in a fully modeled context. The issue comment
speculated that the problem is with the wiring or dynamic componet instance
resolution. More detailed investigation shows that it is indeed the start up
wiring process that is defective.

6.1 Locus of defect
Since the models which show this issue used nested components with delegation,
it was assumed that delegation behavior was defective. Investigation shows
that in fact it is normal Satisfaction instances which are being miswired.

The problem code lies in BPDebugTarget. There are two methods in this class
that locate components for wiring during Verifier startup. These methods are
getProviderTargetFor() and getRequirerTargetFor(). Both methods take a
NonRootModelElement argument which is assumed to be either a Satisfaction or
a Delegation instance.

These methods are very similar as might be expected from their names. They both
show the same defect. The methods first look for the Interface Reference to be
wired, and then search for the component instances associated with that
reference by using the following traversal:

```
select any comp_instance related by iref->CL_IC[R4700]->I_EXE[R2963];
```

NOTE: This traversal is written in java rather than action langauge, but the
traversal is easier to read written as OAL.

The defect lies in the second step of the traversal. R2963 is a one to many in
the direction traversed. When session launches multiple instances of a
component which nests other components, the same component reference maps to
multiple component instances. The select any traversal chooses the first
component instance found, which explains exatcly the behavior seen in the
issue.

7. Design
---------
The required fix is to find the one component instance which is in the
inter-set found by:
```
select many comp_instance related by iref->CL_IC[R4700]->I_EXE[R2963];
```
(Note: _many_)

and:
```
select many children related by parent->I_CIN[R2974]->I_EXE[R2974];
```
This inter-set is always guaranteed to contain a single component, even whe
multiple instances of the same nested components are launched, because each
Interface Reference is unique within a given Component, and each parent
Component Instance contains only one Component Instance for each nested
Component.

In order for this fix to be applied, the parent component must be added as
an argument to the two methods concerned. When top level components are
launched, the parent component is null, in which case the previously
defective traversal is used. This is robust in this one case, because only
nested components can have multiple instantiations. Hence in the top level
case, R2963 will always yield a single instance.

The final proposed pseudo code is as follows:

```
Component Instance result;
if not_empty parent
  select many candidates related by iref->CL_IC[R4700]->I_EXE[R2963];
  select many children related by parent->I_CIN[R2974]->I_EXE[R2975];  
  for each child in children
    if candidates contains child
      result = child;
      break;
    end if;
  end for;
else
  select any result related by iref->CL_IC[R4700]->I_EXE[R2963];
end if;
```

The modified code includes some additional internal error reporting to detect
future assumption failures in this area, though none are expected after this
change.

8. Design Comments
------------------
It was noted during testing that the Session Explorer incorrectly shows three
class instances under the test package for each component. There should only
be one for each component. An issue [3] is raised to track this defect.

9. Work Required
----------------
Implement the above pseudo code as java in the getProviderTargetFor() and
getRequirerTargetFor() methods. Modify the wireChannel() and wireChannels()
methods which call the two modified methods so that they supply the parent
Component Instance as an argument.

10. Unit Test
------------
10.1 Verify that calls from multiple instances of the same configuration are 
     routed correctly.
```
_- Import the Bugs_testbed.zip as an existing project 
   (from \\wv\dfs\bridgepoint\field_data\dts0100949572)
_- Fix the Java build path to correspond to the core.jar plugin in your install
_- Launch the "withoutDelegationToNested" debug launch configuration in Verifier
_- In Session Explorer execute all 3 instances of 
   withoutDelegationToNested::Bugs_testbed::library::CompA::portOne::ifOne::start 
   in sequence
_- Correct output in Console is shown:
   Simulation started.
   User invoked interface message: start
   CompRealized::init called on instance(1) with parameter instId = 1
   User invoked interface message: start
   CompRealized::init called on instance(2) with parameter instId = 2
   User invoked interface message: start
   CompRealized::init called on instance(3) with parameter instId = 3
_- Terminate the Verifier session

_- Launch the "withDelegationToNested" debug launch configuration in Verifier
_- In Session Explorer execute all 3 instances of 
   withDelegationToNested::Bugs_testbed::library::CompA::portOne::ifOne::start in sequence
   
_R CORRECT output in Console is shown:
   
   Simulation started.
   User invoked interface message: start
   CompRealized::init called on instance(1) with parameter instId = 1
   User invoked interface message: start
   CompRealized::init called on instance(2) with parameter instId = 2
   User invoked interface message: start
   CompRealized::init called on instance(3) with parameter instId = 3
   
_R Different instance of realized component is used in each component 
   configuration.
```

End
---
{'fraction_non_alphanumeric': 0.058795669824086606, 'fraction_numerical': 0.018335588633288227, 'mean_word_length': 4.171798460461861, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 27, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4735478', 'n_tokens_mistral': 3785, 'n_tokens_neox': 3560, 'n_words': 1975}