Psychoanalytically Inspired Decision Unit

The design for the framework implementation ARSi11 is straight forward. Each module in the final functional model (\cp Figure \ref{fig:model:functional:fullmodel}) has its corresponding class. Only one container that creates and processes the class instances exists. In the previous version - ARSi10 - a hierarchical approach was used. Analogous to the top-down design, several layers of containers were introduced. For example, the psychic apparatus contained an instance of the class Id - which contained instances of several other classes again. This leads to an overloaded design. In the implementation the abstraction levels served only two purposes: Creating the sub levels and passing the data between the instances. These tasks can be served by a single container class without any loss of functionality. Moreover, the reduction of classes and interfaces involved adds clarity to the design.

Fig. 1: Decision Unit

Figure 1 sketches the principal design. Class Psychoanalysis - a specialization of the abstract class BaseDecisionUnit - has four purposes. First, the communication with the body via the decision unit interfaces is done before and after the data has been processed. Second, the class PsychicApparatus is created and with it all modules and memory related instances. Third, a processor is instantiated. Its task is to process all modules in the appropriate sequence. Finally, different versions of the psychoanalytically inspired decision unit can be instantiated by this class. Currently, ARSi10 and ARSi11 exist and can be used.

The information storage class KnowledgeBaseHandler is a facade-class to the implementation of the psychoanalytically inspired memory described by Zeilinger in [pp 88--109, Zeilinger2010]. The class ShortTermMemory provides access to the short term memory. Analogous, BlockedContentStorage provides access to the special purpose memory which stores memory contents blocked by the defense mechanisms.

The 44 classes representing the functional modules (F01--F66((The full names of the classes are reduced to their unique identifier prefix to not occlude the diagram.))) are all derived from the abstract base class ModuleBase. It provides a structure which all module classes should implement. Each module class has to implement interfaces for sending and receiving data as defined by the interfaces in the final functional model. The methods for receiving data have to make a deep copy of the incoming objects and lists to avoid side effects. Each module class has to implement three different process methods: A dummy implementation which forwards the incoming data where appropriate. An empty data package is forwarded otherwise. A development version which is used during implementation and testing has to be added. The third process method contains the final version. If this method is present, its functionality is equivalent to its definition in Section \ref{sec:model:full}. Using a configuration file, each class can be configured to use any of these three versions. This design decision helps for example examining changes of the model. Finally, sending is centralized by class ModuleBase. A module class has to implement all sending methods according to the included interfaces. These methods are called by send method which is triggered by the processor class described above. Upon creation, each module class is given reference pointers to the various data base classes as necessary.

An important design decision is to add all functional modules to the composition list of Class PsychicApparatus. Although it can be argued that the classes representing modules assigned to the body - F01, F02, F10, F11, F12, F31, F32, F39 and F40 - are not part of the psychic apparatus, they are deliberately included into it in ARSi11. As the simulator provides high-level symbolic information on the environment and the bodily systems and accepts high-level commands for actuator control, these classes are added for the sake of completeness in this implementation. For this reason, and to avoid unnecessary added levels of classes in the implementation, the body related classes are not put into a separate container class.

Fig. 2: Module Communication

All module classes have been drawn without their interfaces in Figure 2. Due to the large number of classes and interfaces, the UML would be occluded by details and not be readable any more. In Figure 2, a subset of the module classes and their interfaces are shown. The shown concept is the same for all 44 classes. The Module E40 gets its data from E39 via Interface I1.8 and sends the processed data to Module E41 via Interface I1.9. The class corresponding to Module E40 - E40_NeurosymbolizationOfLibido - implements two interfaces: I1_8_recv and I1_9_send. According to the definition of Interface I1_9_send, a member method called send_I1_9 has to be implemented. The task of this function is to call its counterpart - Method recv_I1_9 in Class E41_Libidostasis as defined by the Interface I1_9_recv - and to pass on the data. As described above, the task of Method recv_I1_9 is to make a deep copy of the incoming data and to store it until the Method process of Class E41_Libidostasis is called the next time. Analogous, the communication between Class E41_Libidostasis and E43_SeparationIntoPartialSexualDrives via Interface I1.10 is implemented. The same design is used to communicate between classes which control a buffer (eg Class LibidoBuffer) and the classes corresponding to functional modules (eg E41_Libidostasis and E45_Libido-Discharge).

The task of the class Processor is to call the classes E01 to E47 in a pre-defined order. Each entry represents a class and the call of its Method process. The steps of this execution sequence are arranged in eleven groups. Each group represents a part of the final functional model. For example, the five classes E6, E7, E9, E19, and E36 are forming the cluster "Defense mechanisms." The formed groups follow more or less the partition of the intermediate model. It differs in the modules which were introduced in the step from the intermediate to the final model.

The presented simulation platform ARSIN world with its ARSIN agent together with the framework to use different control architectures meets the requirements defined at the beginning of this chapter. Although not all parts are fully implemented yet - for example, reproduction and communication are missing - they provide an environment to evaluate the presented model with focus on the newly introduced functionalities. In the next chapter, the evaluation of the concepts with this simulator is executed.