A case study: the European Example

The recommended reading for this case study is Pissanetzky(2012b).


This article contains an extensive and fully detailed case study on object-oriented analysis, design, and refactoring, based on a publicly available Java program that simulates a local area network (LAN, also known as a token ring. See also here), and is used in many European universities for teaching purposes. The example covers much of the spectrum of topics discussed in this paper. The Java program includes several classes and extensions, each with several methods. An execution trace is first generated and then “dismembered” by application of function E-1. This process involves several steps, and is done manually because tools for converting Java code to causal set format are not yet available. Several intermediate files are generated, and they are all available. The process completely eliminates all structures existing in the Java code, and obliterates all order or organization from it, leaving only the causal relations found in the code. The result of the process is a causal set with 33 elements and 55 precedence relations, and nothing else.


Once the causal set becomes available, causal logic (CL) is applied to it. The output is a scale-free hierarchical network of blocks, with 3 levels in this case. The blocks and hierarchy are compared with the corresponding man-generated entities in the original Java program, and found to agree. Given the hierarchy, the conversion to an automatically generated Java program is easy and can be fully automated, but is omitted because code is not yet available. All files generated in the course of the process are available as supplementary material.


A case study is an analysis in depth of a particular example, designed to help the reader experience the theory at work. It should not be too complex, or too simplistic, but it must be the right size to demonstrate how the various parts of the process fit and function together. This case study sheds some light not only on issues of self-programming, but also on more general issues concerning general AI. The questions addressed involve the ability of CL to self-organize code, to create meaning by developing a meaningful object-oriented model of the system without human intervention and eventually to generate an OO program in an OO programming language, and how do the CL-generated classes compare with the corresponding human-generated classes. The aim of the effort is to examine the applicability of CL to self-programming, and, for the long term, supporting a new type of software development environment (SDE) capable of automating tasks such as acquiring information about a specific problem, refactoring and integrating code, and translating between programming languages.



The local area network (LAN) consists of several stations, three in this case, interconnected by serial transmission lines. Each station has two message buffers, one for input, and one for output, connected by a parallel bus. The incoming line is connected to the input buffer, and the outgoing line to the output buffer. A station can create a message and copy it to its output buffer, from where it is transmitted to the input buffer of the next station in the ring. Upon receiving the message, and depending on its source and destination, a station takes appropriate action, such as print and destroy it or send it to the next station.


The supplementary files used in this case study are listed below. Please view text files in a non-proportional font such as Lucida Console.


EEOriginalJavaCode.txtThis is the original Java code for the software model of the LAN. It contains several classes, some of them with extensions. Class Message represents the message, with source, destination, and contents. Class Station is a generic station with the basic behavior to accept() a message in its input buffer and send() it to its output buffer for transmission. Classes NetworkTester, PrintServer, and WorkStation extend Station and override some methods to accommodate the special behaviors. The Main program, which has been omitted, constructs the various objects and directs networkTester, and object of class NetworkTester, to send a message to itself.


EEExecutionTrace.txt. There are 3 stations in this LAN, and each can send a message to itself or to any of the other two. For the purpose of this case study, it will suffice to consider only one of the 9 cases, the case where the station of class NetworkTester sends a message to itself. The application of function E-1 to the original Java code begins in this file. The first step is to completely eliminate all the object-oriented structures from the original Java code, and to generate the corresponding execution trace. The file gives the resulting trace, where full names have been used for all variables, resulting on the elimination of the class structure.


It is also the purpose of this step to confuse the reader as much as possible by forcing him/her to completely lose track of any sense of meaning. This is done intentionally, the goal being to emphasize the property of causal logic to generate its own meaning from causality alone, without relying on any previously existing meaning. The resulting artificially-generated meaning is compared with the man-made meaning present in the Java program at the end of the exercise. There are 33 variables in the trace. To achieve the confusion goal, and at the same time produce short names suitable for our purpose, I have renamed all variables with strings consisting of one or two digits in the range 0 to 32. They do not function as numbers, just as names, and I have followed an arbitrary order in the renaming. The new names are also given in this file. In addition, precedence relations have been generated from the expressions in the trace, and are also given in the file. For example, variable "workStation.inBuffer.source" has been renamed "12", and is preceded by variable "11", which is "networkTester.outBuffer.source." Variable 12 cannot be calculated unless variable 11 has been calculated before. There are 33 elements and 55 different precedence relations in total.

EELevel1CausalSet.txt  The resulting 33 element, 55 precedence relations causal set is given in this file. This concludes the process of application of function E-1, and begins the process of application of function E, which is the causal logic (CL).  The causal set is the only information passed from the first process to the second, and it is passed as data. The process of application of function E is fixed. It will not change. It is always the same, irrespective of any particular problem that is being solved. This is the feature that makes causal logic a universal logic.


EELevel1Permutations.txt  The first step of causal logic, the application of function E, is to identify the symmetry existing in the causal set of the previous file. This is achieved by a search process that minimizes the action functional, and finds those legal permutations of the causal set that have the least value of the functional. A set with 33 elements can have as many as 33! ~ 8.7 x 1036 permutations. Most of them are illegal, but even then, the number of legal permutations is enormously large. This is a great combinatorial explosion. The minimization of the functional resolves the combinatorial explosion, and at the same time provides a representation of the symmetry of the causal set, suitable for deriving the invariant behaviors. The correct way to perform this step is to construct the massively parallel neural network described in Section 4.3 of the recommended reading, where neurons correspond to elements of the causal set and connections to precedence relations. It is possible to implement the hardware on an FPGA or a GPGPU, conveniently programmed. This has to be done only once and for all, because causal logic is fixed. In this case, it would suffice to have a network with only 33 neurons, all of them working at the same time, locally minimizing their individual contributions to the functional. However, such hardware is not yet available. The minimization had to be performed on my personal computer. The result is the set of 596 least-action permutations given in the file. These are all the permutations I was able to find. I believe, but cannot be sure, that these are all the least-action permutations that exist for this problem. Anyway, they are sufficient for our demonstration purpose. They represent the symmetry of the causal set accurately enough.


EETheHierarchy.txt  This file presents the invariant block system corresponding to the 596 permutations that represent the symmetry of the causal set. Calculating a block system is a standard procedure in Group Theory, and will not be expanded here. Software is available. This block system contains 14 blocks. The reader can verify that the same block system is valid for all 596 permutations listed in the preceding file, that's why it is a block system, because it is invariant under the permutations.


The induction and encapsulation of the 55 precedence relations from level 1, into the block system of level 1, results in 18 inter-block precedence relations, and 9 intra-block (encapsulated) precedence relations. All these relations are also given and explained in the file. The block system of level 1 gives rise to the causal for level 2, which has 14 elements and 18 relations, and is given in the file. The same procedure described above must now be repeated for this new causal set, but will not be described in detail. In this case, there are only 2 least-action permutations, which give rise to 2 blocks in level 2, P and Q, and only one precedence relation. These 2 blocks become the 2 elements of the causal set for level 3, which has only 1 block and no relations, making level 4 the top level of the hierarchy. All this information is explained and summarized in the file.


This concludes the application of causal logic. The only task that remains is the interpretation of the meaning of the results and their comparison with the original man-made meaning in the Java program. This is done in the next file for level 2.


EEInterpretationOfLevel2  This is the final file of the European Example. It contains the comparison of the artificially generated meaning from the hierarchy of the previous file, and the "natural" man-made meaning that appears in the Java code. The comparison is extensively explained in this file and found to be successful, at least within the limitations of the available resources.


The argument can be made that ``all those features are there because we put them there in the first place.'' Of course. This is the essence of the notion about the origin of algorithms. Causality “puts the features there,” then the minimization of the action functional organizes them functionally, and the result is the invariant behavior, the algorithm. Function is acquired, not created. Organization and meaning are what is created. And they are created from causality alone.