Use Case: Using Symbolic Analysis in Problem Solving

Let’s describe a situation where a TCP/IP-server, acting as a class Server, does not start. All the necessary initial knowledge pertaining to the TCP/IP server consists of that the communication is done with the object ServerSocket. The user can employ the initial knowledge about the implemented modifications, the history of the software and earlier errors in many different ways, in order to locate the problem as efficiently as possibly.

A general rule for isolating the problem using symbolic analysis is as follows:

In the knowledge level the user creates a hypothesis about a relation between the symptom and its possible cause. If the function doesn’t start at all the user may assume that the problem is either a state problem or a control flow problem between the main and the focus.

The user confirms the hypothesis that the problem can only occur when the program is started from the main method (skill action).

In the rule level, the user validates the paths and, in the skill level, the invocations.

In the skill level the user validates all the conditions and their relevancy. The user inspects the control paths that are close to the target and in the end of the output tape, because it may be assumed that the problem is one of the last conditions of the simulation (unless a totally erroneous logic path has been selected).

In this particular case the process can be divided into iterative phases as follows:

1. Problem Recognition:

The failure is located into an application, which is responsible for TCP/IP communication. The process and code for creating a ServerSocket object should be found there.

2. Problem Formulation:

It is found that there is only a main method in the application. Thus, it is selected as the start element. The formulation is then to investigate the flow between it (main) and the target element, the ServerSocket instantiation.

Locating the ServerSocket is a search activity that requires skill knowledge to identify the possible invocations (skill action).

The object ServerSocket is the selected target (problem object), the focused element. All possible input paths leading to it are found (KnowledgeAction).

3. Problem Analysis:

When the start and the target are fixed, a complete query can be made from the main to creating the object ServerSocket. This is simulated and the output tape is created.

If an object is not created, then the problem should be in the selected sequence.

The assignments are checked (variable port etc).

The user finds that the only things that can have influence in the variable port are the command line and the variable DEFAULT_PORT.

The value for DEFAULT_PORT is checked.

In this particular case, a problem is found in the side effect element, considering the value of the variable DEFAULT_PORT.

4. Change Specification:

The modification should be done to the area of the variable port. It can be written in several ways. Evaluating the best way can be done by means of impact analysis, by using forward chaining theorems for the current model in order to minimize the number of impacts.

Unit Testing:

After the modification, the same code area with the new code is inspected again. The correction can be read from the simulation output tape without going through problem formulation or preliminary analysis.

In these cases where the elements that have been modified to form complex logic between their environments a theorem prover can be used for showing that the newer version uses valid control paths. Inspecting side effects is not necessary if there are no changes in the references. Instead, in regression testing all test cases are exhaustively checked.