Clarify legacy code questions

[tdauth]

Clarify if we need the following parts from the legacy code and how they were used:

• The execution counter for the total number an action has been executed StateGraph.actionExecutionCounter? The execution counter for the number an action has been executed from a certain state StateGraph.executionCounter? Both execution counters weren't used except for verifications in unit tests and to get the never explored actions (which we can also just store in a field). So basically, we don't really need these counters. However, it could be interesting for the visualization or analysis of the NFA to see how often actions are repeated by the GA etc.
• Blacklisted and whitelisted components? They were used to filter all available actions when getting a state. See Environment. Since we provide no getState with a ExecutingTestContext, we do expect in our getState and executeActions the filtering to be already done. So it would have to be done from the client side not this API.
• Getting a state by an execution context only? Should never be called if the filtering is not done in this API (see above).
• StateGraph.getRandomAction and StateGraph.getRandomActions? getRandomActions seems to get all never explored actions from a state and to add all explored actions which means it simply gets all actions (confusing method name). StateGraph.getRandomAction chooses one from StateGraph.getRandomActions and randomizes it with the method Action.randomize which has to be implemented by the concrete action type. getRandomAction is required by Monkey Testing. getRandomActions is used to produce a random action and directly by the ML module only when there are no unexplored actions where also getTransitions().keySet() could have been used directly. Therefore, only make getRandomAction public for Monkey Testing.
• StateGraphListener with a method called whenever a transition was added. It was only used by MonkeyTestingModel to update the information about the progress in the GUI. We know that when we execute executeAction there will be a new transition. Therefore, the information is already given for the calling client.
• StateGraph.unknownUIState and UnknownState. The method unknownUIState is only used for ActionStateSequenceOld when cloning.
• StateGraph.groundState and GroundState. Its purpose is to identify a state graph without transmitting the whole state graph in form of a UUID. StateGraph.getGroundState is only used to get the execution date and to create the ExitState and UnknownState. Every state stores its corresponding GroundState. It is then used in ActionStateSequenceOld and when converting it to ActionSequence.
• PrimitivesPool
• StateGraph.exitState and ExitState was created in the constructor when there was a groundState although no transition led to it?
• AbstractState.canPossiblyExecuteActionSequence and AbstractState.canPossiblyExecuteAction.
• StateGraph used MD5 hash values to compare states and use keys. Better performance than comparing their descriptors?
• StateGraph.getAllNeverExploredActions has to be supoorted for chromosomes to generate new test cases. Store it globally. Otherwise, we would have to collect it from all states etc. like in the legacy code -> bad performance.
• StateGraph.getAllExploredActions was only used in the registered transitionAdded to show in the GUI how many actions have been executed by Monkey Testing. Is not hard to support as global variable in the state machine.

[beatngu13]

More open questions:

• What is AmbigueState for? From the Javadoc:

  The StateGraph does not capture internal system state, only on current screens visible displayed state. It is possible that the result of an action depends on the invisible internal state. Thus for our state graph this means we got multiple following states (or an ambigue state) for actions.

• How to avoid "same" actions being executed multiple times? For instance: It would be possible to execute multiple text insertions into the very same field but with different strings (e.g. a, aa, aaa, …). According to the used state definiton, which includes all data, this would always result in a new state. How did the legacy implementation avoid this situation?

[beatngu13]

What is AmbigueState for?

Via @tdauth: For situations where the same action from a particular state leads to different target states, similar to a NFA (see Wikipedia example). As stated in the Javadoc, we only capture data visible through the GUI and not the entire program state. Therefore, to model may be nondeterministic. AmbigueState simply encloses the list of possible target states.