EPP follows the same principles of module and encapsulation as the PMP since it is the same plugin abstraction layer. Monte Carlo algorithm operates on a high level so that it randomize a setup (event), compute result for event, repeat desired number of times and collect a total result. This is very similar to how SEAMCAT operates on the highest level.
Notice that once an EPP is installed in SEAMCAT it can be configured for any scenario possible. It is therefore bad practice, when programming an EPP to assume anything about the scenario (e.g. the victim system is of a specific type). A re-usable EPP must be implemented in full generality assuming nothing about the scenario, and if something specific is required from the scenario, provide the necessary validation during the consistency check (e.g. if an EPP only works for a generic victim system - it should emit a warning during the consistency check phase allowing the user to abort the simulation).
An EPP has access to the scenario i.e. the complete setup of the simulation. Also it can access its defined input parameters. Interestingly it has an iterator where it can access the event results. An iterator is a Java construct that allows you to ask if it has more elements and get the next element – also this construct can be used in a for-loop. The interface of EPP shows that one must return a type ResultTypes. This is a container for all the results produced by the EPP.
In SEAMCAT, we have immutable state, and therefore, it does not matter at what time different components access it. All will read the same regardless of the interleaving. Suppose the person object was mutable, i.e. the name property could be changed. If there were several parallel threads that could access the same person object it would be really difficult to know what person.getName() would return. Null? "John", "Joe"?. For immutable state, time does not matter, parallel processing is possible.